DOSBOx's OpenGL code

[kas1e]

Hi ptitSeb ! :)

Tried to build today DOSBox over gl4es, and have on linking stage that kind of errors:

libgl4es.a(buffers.c.obj): In function `gl4es_glGenBuffers':
buffers.c:(.text+0x1a4c): multiple definition of `glGenBuffersARB'
gui/libgui.a(sdlmain.o):/amiga/dosbox/src/gui/sdlmain.cpp:2881: first defined here
bin/ld: Warning: size of symbol `glGenBuffersARB' changed from 4 in gui/libgui.a(sdlmain.o) to 524 in libgl4es.a(buffers.c.obj)
bin/ld: Warning: type of symbol `glGenBuffersARB' changed from 1 to 2 in libgl4es.a(buffers.c.obj)
libgl4es.a(buffers.c.obj): In function `gl4es_glBindBuffer':
buffers.c:(.text+0x1c58): multiple definition of `glBindBufferARB'
gui/libgui.a(sdlmain.o):/amiga/dosbox/src/gui/sdlmain.cpp:2881: first defined here
bin/ld: Warning: size of symbol `glBindBufferARB' changed from 4 in gui/libgui.a(sdlmain.o) to 756 in libgl4es.a(buffers.c.obj)
bin/ld: Warning: type of symbol `glBindBufferARB' changed from 1 to 2 in libgl4es.a(buffers.c.obj)
libgl4es.a(buffers.c.obj): In function `gl4es_glBufferData':
buffers.c:(.text+0x382c): multiple definition of `glBufferDataARB'
gui/libgui.a(sdlmain.o):/amiga/dosbox/src/gui/sdlmain.cpp:2881: first defined here
bin/ld: Warning: size of symbol `glBufferDataARB' changed from 4 in gui/libgui.a(sdlmain.o) to 1984 in libgl4es.a(buffers.c.obj)
bin/ld: Warning: type of symbol `glBufferDataARB' changed from 1 to 2 in libgl4es.a(buffers.c.obj)
libgl4es.a(buffers.c.obj): In function `gl4es_glDeleteBuffers':
buffers.c:(.text+0x42e4): multiple definition of `glDeleteBuffersARB'
gui/libgui.a(sdlmain.o):/amiga/dosbox/src/gui/sdlmain.cpp:2881: first defined here
bin/ld: Warning: size of symbol `glDeleteBuffersARB' changed from 4 in gui/libgui.a(sdlmain.o) to 1564 in libgl4es.a(buffers.c.obj)
bin/ld: Warning: type of symbol `glDeleteBuffersARB' changed from 1 to 2 in libgl4es.a(buffers.c.obj)
libgl4es.a(buffers.c.obj): In function `gl4es_glMapBuffer':
buffers.c:(.text+0x4900): multiple definition of `glMapBufferARB'
gui/libgui.a(sdlmain.o):/amiga/dosbox/src/gui/sdlmain.cpp:2881: first defined here
bin/ld: Warning: size of symbol `glMapBufferARB' changed from 4 in gui/libgui.a(sdlmain.o) to 316 in libgl4es.a(buffers.c.obj)
bin/ld: Warning: type of symbol `glMapBufferARB' changed from 1 to 2 in libgl4es.a(buffers.c.obj)
libgl4es.a(buffers.c.obj): In function `gl4es_glUnmapBuffer':
buffers.c:(.text+0x4a3c): multiple definition of `glUnmapBufferARB'
gui/libgui.a(sdlmain.o):/amiga/dosbox/src/gui/sdlmain.cpp:2881: first defined here
bin/ld: Warning: size of symbol `glUnmapBufferARB' changed from 4 in gui/libgui.a(sdlmain.o) to 1224 in libgl4es.a(buffers.c.obj)
bin/ld: Warning: type of symbol `glUnmapBufferARB' changed from 1 to 2 in libgl4es.a(buffers.c.obj)

The opengl related code in dosbox are there:

https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/gui/sdlmain.cpp

Is it something which we can't build with gl4es ?

Thanks !

[ptitSeb]

Hi,

This happens because gl4es is linked as a static library.
Only solution will be to comment the relevent part in gl4es.
I can probably add some #ifdef AMIGAOS4 in the code for that (in buffers.c).

[kas1e]

But will those arb functions works with gl4es at all after commenting them out in gl4es ?

[ptitSeb]

Yes it will. They will be still accssible via aglGetProcAddress(...)

I have just pushed the change, try it and you'll see :)

[kas1e]

Yeah, all compiles and links fine too now, but .. sadly there is a massive 50% speed drop if I use OpenGL output instead of pure surface one. Very strange!

If for example with core:normal and output:surface (so software), i have 5 fps in some benchmark, then with opengl output i have just 1.7. With dinamic ppc core i have in the same test 15fps with software surface, and with opengl output 7.5

Sadly, but dunno wtf. Maybe its realted how SDL2 patch done for dosbox and the way how it handle opengl in.

[kas1e]

Strange that its whole CPU thing with output:opengl loading slower. I mean, even just loading some game, not about rendering even.

edit: or maybe our "opengl" renderer in SDL2 suck something..

[ptitSeb]

Well, in Dosbox, OpenGL is only used as a Blitter... So basically, you create a texture, for every dosbox frame, you update that texture, and you simply blit it to the screen. The only advantage of OpenGL is free scaling of the picture... but with the cost of having to update the texture at every frame...

Unless you plan to use shaders (to add CRT effects or things like that), or if your software blitter is super slow, there will be no advantage with using OpenGL rendering.

The only part where it'is interresting to have OpenGL is with 3Dfx emulation. But it's not a standard option, and quite tricky to setup... And only a handfull of games will use it anyway...

[kas1e]

Yeah, I was in the hope to add it just for "scaling of the picture to fullscreen". Didn't expect that much of speed drop, was at least in the hope it will be the same.

[kas1e]

Maybe it's better to implement some 4x and 5x scaling (there already few patches on DOSBox forum), so it can fits to 1920x0180 as well when need.

[kas1e]

Is DosBox "frames" mean only "rendering" frames? I.e. if for example, we will have a black screen, should it be with and without OpenGL the same 1:1? Or, with OpenGL, it still will be slower on 50%?

I probably may try to find some pure ogles2 patches for DOSBox .. I just can't believe that with OpenGL rendering it should be slower on 50% just on a black screen. There definitely something wrong. Maybe SDL2 patch I apply on DOSBox's code doing some unnecessary things which slow things that much, but then, only with OpenGL.

Will try to build also SDL1 version with OpenGL.

[ptitSeb]

You can use GLES2 directly if you want. Not sure it will change much the result.

The only case where gl4es will add some work in a texture update is if the glTexSubImage2D(...) have data in a different format than what the glTexImage2D(...) have create the texture with (because that's not supported in GLES2).

And yeah, the screen can be black, white, with flowers, in each frame the whole screen (most of the time VGA 320x200 with 256 colors with palette) is update in the texture before beeing blitted...

[kas1e]

Damn :) So better to use scalers instead of OpenGL then.

[kas1e]

Checked win32 build of dosbox, and there if i set for output be in software, or in opengl, no FPS drop happens at all.

Probabaly its our driver suck some amiga. Maybe that the issue with no DMA ?

[kas1e]

That one can be closed, as issues, we have with OpenGL rendering in DOSBox probably related to slow texture-loading as we have no DMA support on AmigaOS4 when it comes to RAM<->VRAM transfers.