@Capehill
Quote:


Yes, that is how initialisation done before we do call to that failing code:



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:

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.

Hi everyone,

Is it normal that The joypad doesn't work with CannonBall (Last SDL2 version) ?

Thanks

@pseudaxos

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:

http://kas1e.mikendezign.com/aos4/sdl2/iconify_icon_first.jpg

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 :

http://kas1e.mikendezign.com/aos4/sdl2/iconify_icon_not_first.jpg

See there icon placed to some other place.

@kas1e

1) Does the icon appear in the snapshot position after the 2nd iconification? If it does, isn't it a correct behavior then?

2) Does the icon have X/Y coordinates before / after snapshot?

From earlier discussion on iconification topic, I get the impression that DiskObject parameters may have some impact on where the icon lands.

@Capehill
Quote:

Can you explain that one more a bit plz ?

Quote:

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) ?

@kas1e

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().

@Capehill
Quote:

By changing X/Y to 0,0 ? (if it possible to change in DiskObject strcture at all ?)

@Capehill, kas1e

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.

@kas1e

If it works, why not. Could you write a ticket?

@Capehill
Yeah, done, #75

@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 ?

@kas1e

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.

@Capehill
Quote:

Tested : just crashed in ogles2.library :)

Quote:

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.

@kas1e

Yes, MiniGL works. Problem was my own hacked MiniGL build. Daniel's 2.23 works OK. Sorry about confusion.

I'm not seeing the ogles2 crash myself though.

@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:



100% reproducable

@kas1e
@Capehill
EDIT: nonsene, forget it :P

@Daytona675x

There was some static analyzer fix recently, dunno if it could be related: https://github.com/AmigaPorts/SDL/comm ... d0bce56aa1c8f5b25b81124ab

So kas1e: you could try to build the master and retest. My testdraw2 binary predates the above fix.

@Capehill
Nope, with latest master still the same. Once batching is set, then crash.

Tested with ogles2.library v2.5 , then with batching there is no crash, but it also didn't work either, just grey window.