Yes, that is what i meant, but they don't do anything speed wise when i use e.g. compositing.
But i remember now that you told me the other day that it might not be used by the application because only some specific drawing is sped up, can't remember what they were exactly.
Blitting operations can be faster. But if application doesn't draw using https://wiki.libsdl.org/SDL_RenderCopy (or Ex variant), then there is no impact.
A game that has a sprite sheet (SDL_Texture) should benefit.
An emulator that writes memory byte at time instead of blitting, probably won't. Still, if that emulator draws a framebuffer texture of, say, 320*200, this texture could be scaled, rotated, blended or filtered almost for "free", using compositing or OpenGL.
Regarding Q3, If I understand correctly, there should be a Q3 makefile-level switch for choosing the GL. Or, code could try to look for CVA extension with or without 's'.
Yeah, seems we both misunderstood :)
What i trying to say, is that if anyone will try to compile from your repo SDL2 version of Q3 for amigaos4, but not for minigl then he will have issues, because your minigl fix, are done as "#ifdef __amigaos4__", which mean ANY amigaos4 build will remove "s" and end.
For example , if one will compile it over any other GL realisation than MiniGL where no extra "s" for CVA. In all those cases, hardcore "#ifdef __amigaos4__" as you have now are non-go, as will make things works wrong. It is only fix for minigl, so there should be something like "#ifdef __amiaos4__ && __minigl__" , or something, instead of just "#ifdef __amigaos4__" :)
Quote:
Regarding SDL2 renderer hint, I'm not sure which problem you want to solve by using that hint?
Just thinking about way how to build SDL2 with all renderers + gl4es, and how to choice it later instead of minigl.
Quote:
What benefit gl4es will bring when used as a (2D) renderer, over pure GLES2? As I understand it, gl4es is meant to wrap OpenGL 1.x (MiniGL) calls with OGLES2 ones, but why not use directly OGLES2?
GL4ES its not only wrap of OpenGL1.x calls, it is also wrap OpenGL2.0, OpenGL2.1 and some of OpenGL3.x, and translate it to OGLES2.
I.e. many SDL1/SDL2 apps use OpenGL, but not just OpenGL1.x, but OpenGL 2.x, 3.x, etc. And GL4ES for us, it is that OpenGL 2.x, etc which we always want.
We can't "just use OGLES2", because almost none real live and opensouce apps/games use it, they use instead OpenGL2.x and more. And , yes, of course better was to port just MESA over warpdnova, so to have full OpenGL driver working over Warp3dnova, and to not make such combinations like "gl4es->ogles2->warp3dnova", but it was too big task, and instead they choice OGLES2, which, is limited subset of OpenGL2.x/etc for mobile devices.
In other words, we have OPENGLES2 not because its better, than full reall OpenGL, it is smaller and worse, just was real to do in our limited resources and time. And so, as result we still need full OpenGL2.x and more, which, gl4es do for us over ogles2.
And if we have in SDL1/SDL2 minigl support only , we limited to OpenGL1.5, if we use GL4ES we can build apps which use OpenGL1.x, OpenGL2.x, and some of OpenGL3.x, with all that shaders support and stuff.
Quote:
If you want to force opening the correct GL library for OpenGL context instead of, it has to happen by some other means. Please refer to readme document how to select between MiniGL and OGLES2 context. At the moment I don't know what is OpenGL version that gles4 supports - that's one thing that might be used.
Probabaly you miss the point of GL4ES.. It is OpenGL2.x and more for us, which can works only over OGLES2/Warp3DNOVA.
What i ask, is how we can integrate GL4ES together with other renderers, so when one will have needs, he can just choice it.
Quote:
Is gl4es a static library, shared or both?
At moment it is static link library, and it can be .so as well, just i do not worry about .so at moment.
Quote:
Have you added configure support for gl4es?
At moment its pure list of objects to compile, like a small makefile.
Quote:
In other words, how to recognize SDL_os4gl4es.c should be compiled?
just compile it in any case without needs to recognize ?
Quote:
It sounds difficult, because if SDL2 library starts to require symbols from gl4es, then there has to be 3-4 different SDL2 binaries (nightmare). Versions for sdl.a, sdl.so, sdl.a with gl4es.a, sdl.so with gl4es.so.
For build gl4es version of SDL1/2 i just add include of GL4ES includes, and that all. Only on linking stage of final apps, i add -lgl4es to link with linker lib.
I mean, for me it looks like this: We add 2 new files to compilation process , they compiles, injects inside of libsdl2.a , and that all. When programmer want gl4es he will choice it (need to think how, that i why i think about SDL_HINT), and on linking add -lgl4es together with -lsdl, and that all.
Or you fear about conflicts of the same GL functions in libsdl .a from both minigl and gl4es compiled at the same time ? But imho that no problems, those ones will be choice, which are connected to choicen renderer from sdl app.
>At moment it is static link library, and it can be .so
Having a GL4ES.library would be more AmigaOS friendly (and evolutive...) It can be as simple as having only 2 functions in the .library OpenGL4ES(); CloseGL4ES();
Still regarding Q3, I was trying to say that Q3 code can be fixed so that it tries to look for either functions, with or without 's'. If it finds one, then good. If none, then there is no CVA implementation and Q3 has to live with that.
"Just thinking about way how to build SDL2 with all renderers + gl4es, and how to choice it later instead of minigl."
If you want to be able to select both MiniGL or gl4es for SDL_Renderer, you need to provide a symbol that describes it, like https://github.com/AmigaPorts/SDL/blob ... c/render/SDL_render.c#L78 . Maybe one of the existing OpenGL renderers can be extended, or duplicated. But I still don't see the value over unwrapped OGLES2 renderer. This is not about application code, this is about SDL internal 2D renderer implementation. When renderer is used, all drawing happens using SDL calls: https://wiki.libsdl.org/CategoryRender . If you are porting a Quake, you simply don't use the SDL_Renderer. You create OpenGL context and command that.
"I.e. many SDL1/SDL2 apps use OpenGL, but not just OpenGL1.x, but OpenGL 2.x, 3.x, etc. And GL4ES for us, it is that OpenGL 2.x, etc which we always want."
Again, SDL_Renderer is something different. It's an abstraction higher that OpenGL: application doesn't make glCalls. You seem to be talking about OpenGL context creation instead of. SDL renderer hint is about choosing a desired renderer backend: it could be a Direct3D one, or compositing. Can gl4es match the compositing speed in 2D?
Choosing the OpenGL context happens currently by setting the appropriate version numbers. It could happen via hint system, but not by https://wiki.libsdl.org/SDL_HINT_RENDER_DRIVER , it's for 2D.
"just compile it in any case without needs to recognize ?"
I have to worry about people building SDL. That's why configure script should sniff around whether gl4es exist or not, similarly than for OGLES2. Not all people have OGLES2 headers but some want to build SDL.
Still regarding Q3, I was trying to say that Q3 code can be fixed so that it tries to look for either functions, with or without 's'. If it finds one, then good. If none, then there is no CVA implementation and Q3 has to live with that.
Seeing your change in q3-sdl2 repo, i understand now what you mean. It works that way too, thanks!
Quote:
If you want to be able to select both MiniGL or gl4es for SDL_Renderer, you need to provide a symbol that describes it, like https://github.com/AmigaPorts/SDL/blob ... c/render/SDL_render.c#L78 . Maybe one of the existing OpenGL renderers can be extended, or duplicated. But I still don't see the value over unwrapped OGLES2 renderer. This is not about application code, this is about SDL internal 2D renderer implementation. When renderer is used, all drawing happens using SDL calls: https://wiki.libsdl.org/CategoryRender . If you are porting a Quake, you simply don't use the SDL_Renderer. You create OpenGL context and command that.
Ok, got it. When i all the time mean "renderers" i just mean contexts then. I of course do not need any new rendereres, all i want, is to add support of gl4es (i.e. creating of opengl context via gl4es instead of minigl and instead of directly ogles2 which sdl2 have now). Just to have it in SDL2 repo, so it will always be there, works, and code can be checked not only by me.
Quote:
Again, SDL_Renderer is something different. It's an abstraction higher that OpenGL: application doesn't make glCalls. You seem to be talking about OpenGL context creation instead of. SDL renderer hint is about choosing a desired renderer backend: it could be a Direct3D one, or compositing.
Yeah, i of course mean opengl context creation, and usage of it with glCalls from SDL app.
Quote:
Can gl4es match the compositing speed in 2D?
Dunno. Its the same as MiniGL in all aspects, just works through ogles2/warp3dnova, and provide us with opengl2.1 instead of opengl1.5 as in minigl (+ give ability to use shaders and all that stuff).
Quote:
Choosing the OpenGL context happens currently by setting the appropriate version numbers. It could happen via hint system, but not by https://wiki.libsdl.org/SDL_HINT_RENDER_DRIVER , it's for 2D.
So, that just mean, that we can add 2 files SDL_os4gl4es.c and SDL_os4gl4es.h, and later from the SDL app, via setting appropriate version number to change gl4es instead of minigl ?
Quote:
I have to worry about people building SDL. That's why configure script should sniff around whether gl4es exist or not, similarly than for OGLES2. Not all people have OGLES2 headers but some want to build SDL.
Sure that mean that gl4es headers should be inside of SDL repo as well. By that way, support of it will be compiled in, and anyone who will have needs for will use it, anyone who don't will not.
You already have includes for OGLES2 anyway (which not eveyone have), so having gl4es ones will be kind of the same (right ?)
I mean it will make libsdl.a or libsdl2.a be fatter for about some bytes only, and will have no impact on anyone who don't have ogles2/warpdnova, all will be the same for them. Just when developers will want to use gl4es instead of minigl, they will add in their sdl app that call to change version number or how it can be, and on linking stage will add libgl4es.a
It's all will like the same ogles2 support you have in, just with some modifications, and there will be needs to choice it from SDL app the same as one choice ogles2 context creationg instead of minigl.
I of course can just create separate builds of sdl1 and sdl2, with compiles in support of gl4es instead of minigl , so SDL apps will have no needs to be changed at all (by calling that call which will do choice which opengl context to create), but that mean that code will be not in repo , and bugs which i keep will keeps forever )
@Capehill Yep.. While thinking more about it, maybe we can just go that way: add gl4es code, but in makefile add option where we choice what realisation of opengl to compile in.
I.e "make opengl=minigl", and "make opengl=gl4es". If specify nothing - then minigl as well.
Also releases can be the same as it now, just developers who need gl4es will download and build it ourself, or i can made releases with gl4es independent.. By that way there will be no needs to touch original code of ported sdl app.
Anyway, i see you implement some minigl based hack via ifdef amigaos4, and want to ask you : is it possible to add minigl flag, and doing those minigl based hacks like " ifdef amigaos4 and minigl" ?
@Capehill I have some VRAM leaks in all SDL2 stuff (that include opengl ones as well), but all of them do not do any call to SDL_DestroyRenderer(). So probabaly linux/windows take care about unfreed vram, and doing it for them.
Question is : are SDL_DestroyRenderer is necessary to use and when opengl in no use, and when in use ? For example, in one game, i found that kind of code:
if ( screen )
{
SDL_DestroyWindow(screen);
screen = NULL;
}
if ( renderer )
{
#ifdef APPLE
SDL_DestroyRenderer(renderer);
#else
SDL_GL_DeleteContext(renderer);
#endif
renderer = NULL;
}
if ( mainsurface )
{
SDL_FreeSurface(mainsurface);
mainsurface = NULL;
}
TTF_Quit();
SDL_Quit();
So, for APPLE they do call SDL_DestroyRenderer(renderer);, but _dont_ call SDL_GL_DeleteContext(renderer);. For others , instead only SDL_GL_DeleteContext(renderer); is called, but not SDL_DestroyRenderer(renderer).
What is correct way for us ? And should we allways in any case use SDL_DestroyRenderer() and does not matter if it opengl or not ?
As i understand that, if one create renderer with:
Quote:
if ((renderer = SDL_CreateRenderer(screen, -1, 0)) == NULL)
Then there should be used SDL_DestroyRenderer. But if one create renderer like this:
Quote:
if ((renderer = SDL_GL_CreateContext(screen)) == NULL)
Then there should be no needs to call SDL_DestroyRenderer, but just SDL_GL_DeleteContext(renderer);
In our case (i mean on os4), i still have VRAM leaks even if context created with SDL_GL_CreateContext and removed via SDL_GL_DeleteContext().
Regarding MiniGL workaround, maybe a function pointer check would be better solution. Anyway, that change was really targeted for MiniGL. As been discussed, there is a proper renderer backend for OGLES2.
SDL renderer should not be mixed with OpenGL context. I don't know what is going on with that APPLE stuff here. Perhaps a misguided developer or some SDL bug.
How exactly the application in question draws stuff?
When you create a renderer, you also must destroy it. When you create a context, you also destroy. Leaking something seems quite common in open source projects, including SDL test programs...
If you have a VRAM leak, check that all textures are free'd.
Also if you are using the latest possible SDL2, it's not been tested by me at least.
Regarding MiniGL workaround, maybe a function pointer check would be better solution. Anyway, that change was really targeted for MiniGL. As been discussed, there is a proper renderer backend for OGLES2.
But i am not about OGLES2, i am about GL4ES. Its totally different, just it working over ogles2.library, but its OpenGL2.0 , not OGLES2 from SDL point of view. Its the same as if we will have NEWGL , which will be version of 2.0 , and which we need to add to SDL.
And now, when we have in the SDL amigaos4 ifdefs , in the place where opengl is used , it will be taken and for minigl, and for NEWGL, which is wrong, and that why i ask about if there is any minigl specific changed done in sdl, they will be good to be ifdefed not for general amigaos4, but for amigaos4+minigl, as there can be amigaos4+newgl, amigaos4+gl4es (not ogles2) , amigaos4+any_other_gl_someday, etc.
Quote:
SDL renderer should not be mixed with OpenGL context. I don't know what is going on with that APPLE stuff here. Perhaps a misguided developer or some SDL bug.
In that code, they for APPLE do create renderer via SDL_CreateRenderer() and on exit destroy renderer via SDL_DestroyRender(). But for all other oses (win32, linuxes, etc), they create renderer via SDL_GL_CreateContext (so they didn't use any SDL_CreateRenderer call), and destory it on exit via SDL_GL_DestroyContext.
By which it seems that there no needs to call SDL_DestroyRenderer, if renderer wasn't created via SDL_CreateRender. Right ?
Quote:
Also if you are using the latest possible SDL2, it's not been tested by me at least.
@Capehill Btw, latest SDL2 also can't be compiled over last public SDK53.30 it has same undefs to MAX_DOS_PATH and to MAX_DOS_FILENAME in the SDL_os4video.c.
Also SDL_os4opengles.c need to be changed a bit, as seems your includes for ogles2.library is outdated: with latest public one, Daniel change aglCreateContextTags() to aglCreateContextTags2() for newly compiled code (see "2" at end).
Regarding that strange Apple stuff: was it so that Apple is deprecating OpenGL in favor of their proprietary API? Perhaps the hack is related to that and developer provides alternative video implementation for Apple?
Anyway, the code looks confusing. SDL_GL_CreateContext() doesn't create any renderer, it creates an OpenGL context.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
