int dblbuf = 0;
if ((SDL_GL_GetAttribute(SDL_GL_DOUBLEBUFFER, &dblbuf) == -1) || (!dblbuf)) {
fprintf(stderr, "Failed to get a double-buffered context.\n");
SDL_Quit();
return false;
}
As you can see, before call we have "int dblbuf = 0;".
What is strange, is that it happens only with minigl build. With gl4es build it didn't happens (but, gl4es in my hacked SDL its just replaced minigl parts mostly, through some functions a bit different).
Also the fact that the same code works on all other platforms (win32,linux, etc) make me think it can be something in our SDL.
Quote:
2) what is the error, SDL_GL_GetAttribute returning negative or dblfbuf being zero?
Being zero.
I may try to create simple test case from the code above, and do check it on win32 for example to see how it reacts.
Do you remember that it worked earlier? My memory is fuzzy here.
Does last SDL2 version mean the latest OS4Depot version or the latest 2.0.9 RC?
2.0.8 non-debug version has a bug which prevents AmigaInput joysticks being enumerated by SDL. So, if you are using the OS4Depot version, 1) try with the latest RC version from github, or 2) rename the debug version of shared object and try again with that.
At some point OS4Depot 2.0.8 version will be replaced with 2.0.9 release, I hope.
@Capehill Found intersting bug-feature of iconification.
Problem is: if you have snapshoot icon of sdl2 app not very close to the left border of wb window, then when you press iconify it will be placed not in the next free slot, but on some other place on workbench (place always different, depend where you snapshot in wb window your sdl2 app icon).
See what i mean :
That one allright , when i press iconification (and icon placed in the wb window as first one) it iconfies to next free slot:
And that one, when i move icon in wb window to some other place , snapshot it (only then, its snapshooting which make it behave strange) and press iconify :
1) Does the icon appear in the snapshot position after the 2nd iconification? If it does, isn't it a correct behavior then?
Can you explain that one more a bit plz ?
Quote:
2) Does the icon have X/Y coordinates before / after snapshot?
Yes of course it have x/y coordinates after snapshot.
And i found some more info: If icon after snapshooting have X more than 78 (i do not know why exactly that value), then, it didn't show ups in the next free slot by Y, but start to showup at top, close to RAM Disk icon. The more i increase X by snappshot the icon, the more iconified icon moves right on the workbench screen.
So it depend exactly on what X value icon have relative to the WB window in which it opened.
Same happens with Y value, if Y value start to be bigger , then icon after iconification placed down a lot.
Dunno if it should be like this ? I somehow think that does not matter where your icons placed in the WB window : when you do iconify, it just should be in the next free slot doesn't not matter what (imho) ?
Edited by kas1e on 2019/4/6 12:40:53 Edited by kas1e on 2019/4/6 12:41:38
By 1) question I meant that if you snapshot when your icon is for example in (100, 100) coordinate, will the icon appear in (100, 100) position always after that, or some place?
I tried to test this by borrowing the Notepad icon. If I iconify the Notepad application itself, it will appear in the first free location. But if I iconify a testapp that uses Notepad's icon, it will iconify to the position that is stored in the icon. So the behaviour between Notepad and test application is different.
So if we want to ignore icon's position, I guess we have to modify the DiskObject somehow before calling AddAppIcon().
If you use a program icon for iconification purposes, you should set the do_CurrentX and do_CurrentY fields in the icon's DiskObject structure to the value of NO_ICON_POSITION. Unless you call PutDiskObject() with the modified DiskObject as parameter, no change will be made to the actual icon on disk, and the icon's original X/Y coordinates will be preserved.
Programs that save their settings as icon tooltypes and, at the same time, use the program icon for iconification purposes, should clone the icon's DiskObject via DupDiskObject(), and only use the clone (with do_CurrentX and do_CurrentY set to NO_ICON_POSITION) for iconification.
@Trixie Thanks ! That " do_CurrentX and do_CurrentY fields in the icon's DiskObject structure to the value of NO_ICON_POSITION" probabaly is way to go in our case.
@Capehill What you think ? Seems sane enough for us, so we will be independed on X/Y of icon in WB windowses and all will going to the next free slot on main wb screen.
@Capehill Daniel also fix your issues about --renderer opengles2 , and i do test 2.6 beta of ogles library : yeah, testdraw2 works now. Through, with minigl it give 850 fps, with --renderer opengles2 it give 35 fps :) Like something slowing it down heavy. Or maybe it just switches internally to the software mode by some reassons ?
Because when i run it like "testdraw --renderer opengles2" it open window, then close it, and open again, like switch to something else.
On serial through it says that opening ogles2 context and all fine.
Wasn't test case somehow modified which may slow that testcase down in 30 times ?
By default renderer batching is not enabled (this is a new thing, added after official 2.0.9 I think) and this hurts at least the opengles2 renderer. Without patching, each primitive is drawn separately by glDrawArrays.
So, please try:
setenv SDL_RENDER_BATCHING 1
should be 5x faster. Still doesn't beat graphics.library but we are just starting to optimize. For example, as Daniel pointed out earlier, there is glPointSize which is not needed in most (non-point) scenarios. So there might be various optimization possibilities. I think SDL_RenderCopy(Ex) speed is what matters most.
Now, need to debug the rest of drawing.
EDIT: ogles2.library 2.6 is another super fast fix release from Daniel and fixed also testdraw2 for me. Thanks.
@kas1e For me testdraw2 --renderer opengl didn't actually work. I think opengl renderer broke at some point after 2.0.8 release. SDL2 keeps changing and it's sometimes difficult to keep up with them. EDIT2: my bad, it works after all.
But, again, all these "renderer stuff" is about 2D API and we have a pretty good "compositing" backend.
By default renderer batching is not enabled (this is a new thing, added after official 2.0.9 I think) and this hurts at least the opengles2 renderer. Without patching, each primitive is drawn separately by glDrawArrays.
So, please try:
setenv SDL_RENDER_BATCHING 1
Tested : just crashed in ogles2.library :)
Quote:
For me testdraw2 --renderer opengl didn't actually work. I think opengl renderer broke at some point after 2.0.8 release. SDL2 keeps changing and it's sometimes difficult to keep up with them.
But, again, all these "renderer stuff" is about 2D API and we have a pretty good "compositing" backend.
I only tested your testdraw2 binary from bugreport on matnis , and that one for sure works with "--renderer opengl" and giving 410fps for me on minigl.library 2.20.
@Capehill As your testdraw2 from mantis are statically builded, it can't be because of sobjes of anything of that sort .. I only do that setenv about batching, and run testdraw2 --renderer opengles2, and:
Crash log for task "testdraw2"
Generated by GrimReaper 53.19
Crash occured in module ogles2.library at address 0x7F956044
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
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
