Getting around display lists.

[Jessie]

I'm working on optimizing Dosbox to use OpenGL ES and unfortunatly their GL renderer relys heavily on display lists which are not avalible in OpenGL ES. I have gotten the code down to a mere 4 errors, but I was wondering if anyone knew of a library out there that I could just drop in a .cpp or a .h file and not have to spend my time re-writing display lists to a modern renderer? I have already put about 10 hours into this project and don't wish to invest too much more.

[OtherCrashOverride]

I took a look a the source code here http://sourceforge.net/p/dosbox/code-0/ ... dlmain.cpp and all they are doing is storing a single quad in a display list and calling it to draw that. You can replace that functionality with a call to glDrawTex{sifx}OES instead of calling the display list.

OpenGLES1.1 on Raspberry Pi reports it supports this extension.
http://www.khronos.org/registry/gles/ex ... exture.txt

[Jessie]

I took a look a the source code here http://sourceforge.net/p/dosbox/code-0/ ... dlmain.cpp and all they are doing is storing a single quad in a display list and calling it to draw that. You can replace that functionality with a call to glDrawTex{sifx}OES instead of calling the display list.

OpenGLES1.1 on Raspberry Pi reports it supports this extension.
http://www.khronos.org/registry/gles/ex ... exture.txt

I already replaced the quads with triangle fans. I will look into your links. Thanks.

[Pickle]

Using opengl in way dosbox uses it will not help much and may actually be slower.

Problem is the every frame your going to be recreating a texture. This is very slow since the GPU has to work and transfer from system memory.

[Jessie]

Using opengl in way dosbox uses it will not help much and may actually be slower.

Problem is the every frame your going to be recreating a texture. This is very slow since the GPU has to work and transfer from system memory.

According to the dosbox team quite a sizable amount of time is taken rendering the screen. I still haven't gotten an OpenGL render workin mostly due to other thing taking time in life. What in particular makes you think it would be slow? To me the worst case is that it will run at the same speed as software and if the upscale filters were re written in gl then there would be a good speed up. The real speed up would occur if someone fixed the SDL libraries for the pi. But I'm not that smart so it won't be me.

I guess overclocking the snot out of the device and running in "simple" mode will be as good as it gets for a while.

[Pickle]

Dosbox emulation draws to a local frame buffer in memory, it then will create a new texture based on this frame data. I think this means a copy occurs copying the data from the memory CPU slice to the GPU memory slice.
Then the GPU is told to draw a quad with the texture over the size of the screen. So then it has read the texture from system memory.
The GPU draws this and then transfers the result back into the framebuffer, which then can be shown on the screen.

So I dont want to be the stopper on your work, but just be aware it may not be the result you want.
I did the same technique for a different application and on a different platform. It wasnt any faster.
I think it basically comes down to the extra frame copies.