NoSpam - Discussion with Powerful

Main Forum

  Threads Index  

Dear Thyme, from now on, let's keep all our discussion under a single topic (this).
This is to avoid yo-yoing up and down on threads.
Last discussion was about SDL, OpenGL, SDL_Net and porting to Android, iOS, MACOS and Linux.

So, please, share your progress here.

I still have lots of ideas to propose, if you're interested, which I'll share as you're done with this.

By the way, let's KISS and post under a single, easier to follow, discussion.

Powerful - 2017-09-02 02:47:59

Your Response:          

I think something like porting to Qt deserves to have a thread of its own same as porting to SDL. I think some attempt should be made to categorise subjects but one should allow for any subject to evolve into another in a forum. Strictly keeping to a subject can prevent interesting ideas from coming to the surface.

thyme - 2017-09-09 14:55:31 in reply to Powerful 2017-09-02 02:47:59

Your Response:          

Yes, you're absolutely right. Just wanted to keep everything clean, never meant to enforce anyone to stick to a specific subject (I thought about this "grouping" after the 3rd separate thread about the same thing - more or less)

Powerful - 2017-09-13 02:06:18 in reply to thyme 2017-09-09 14:55:31

Your Response:          

No worries Powerful.
After getting a simple example of SDL and OpenGL to compile, I was surprised to find that the SDL was not being used for graphics. After some searching of mixing OpenGL and SDL for graphics, I came across a number of comments saying not to do this as this will create problems.

I also found it said that 2d games can be written using OpenGL ES by using textured 2d quads and that this is an efficient way of doing it because the hardware is well utilised.
None of this exactly clarified my concern however of whether the pixels end up getting distorted, so I tried this simple example of a grid:

I modified it so that rectangles in the grid are only 1 pixel in size. I was able to verify all the pixels looked right by taking a screenshot and zooming in with a paint program. Perhaps I was not able to detect any distortion because the quads are exactly the right size to match the pixels and because no matrix is applied to the quads in the pipeline.

thyme - 2017-09-15 13:39:49 in reply to Powerful 2017-09-13 02:06:18

Your Response:          

So, did you create a raster grid out of quads?
If so, a more efficient way to deal with 2d graphics is using Allegro gl.
I'm unsure about portability by the way.

Powerful - 2017-09-15 15:31:45 in reply to thyme 2017-09-15 13:39:49

Your Response:          

Isn't the link I gave to the texture_mapping_and_pixel_manipulation example (which compiles) a raster grid?

Where is it claimed Allegro is more efficient to do 2d than using 2d textured rectangles with OpenGL?
On the Allegro home page ( is states the graphical primitive drawing support is done via OpenGL or Direct3D
Does this mean the 2d is done via OpenGL functions?

Old OpenGL has a glDrawPixels function (I published an example of this in 2009) but this function is not included in the OpenGL ES standard.
Perhaps this is because it is obsolete I wonder. What is the difference between a textured 2d rectangle and a rectangle on the screen? What is there to say the hardware has to do this any differently?

thyme - 2017-09-19 19:37:35 in reply to Powerful 2017-09-15 15:31:45

Your Response:          

Well, it isn't. I just guessed it's more efficient because it manipulates the screen as it were a pixel grid (a bitmap). Other than this, I had no experience with Allegro and I don't know if it's actually better than SDL.
Yes, Allegro does (from of version 5) use OpenGL or DirectX for screen drawing, but I don't know its internals.

As far as I know, the main difference is Allegro manipulates all of its 2
D as if it were a bitmap, while SDL, I don't know.

Powerful - 2017-09-20 07:07:56 in reply to thyme 2017-09-19 19:37:35

Your Response:          

SDL and OpenGL let you do all the pixel manipulation by working with a bitmap without directly writing to the video ram.
Years ago I would have assumed it is more efficient to directly write to the video ram but in this age of programmable shaders I am not so sure, as there is more to take into account. For example if having direct access to the inner workings results in the hardware waiting for the CPU to update something then it may be more efficient for the CPU to wait.
I have not done any testing to see which is the most efficient way to do a 2d layer over the top of a 3d scene but I would rather wait for the problem to assert itself before I spend a lot of time trying to fix it especially when there are a number of known issues that would greatly benefit from further optimisation. So long as there are no noticeable glitches for the occasional 2d updates I will be happy.
Since publishing my Qt port, my time has been spent replacing some of the Qt functions I have been using with native OpenGL functions so that seamless is not dependent on the Qt platform to use OpenGL which allows me to do most of the porting and testing with Visual Studio 2017.

thyme - 2017-09-23 17:43:05 in reply to Powerful 2017-09-20 07:07:56

Your Response:          

I agree on the point about mixing 2d and 3d, and so with pretty much everything else as it builds on that.
In fact, I totally forgot you'd have to do both and this is the main thing.
I also had a deeper look at Qt, I found it to be surprisingly easy compared to "traditional" c++/opengl.

Powerful - 2017-09-23 18:17:19 in reply to thyme 2017-09-23 17:43:05

Your Response:          


Main Forum


[3d Modelling Software] [Tutorials] [Forum] [Features] [Download] [Gallery] [FAQ] [Worlds] [Avatars] [Links] [Thyme]