SDL1 open issues

@Capehill

Done

Simon

@Raziel

OS4Depot requires e-mail when submitting, but there is a checkbox for hiding the address from public.

@Rigo

Thanks again.

@Capehill
Tried today to rebuild some very old piece of sdl1 app, some diskamg engine (i.e. play music, read articles, ability to flip pages, etc), and found issue:

If i build everything with very old SDL1 from 2012 times (i.e. that one which was long time official one), then everything looks correctly.

If i build with latest new sdl1 (that one from os4depot), then i have issues: i move mouse (textured one) and mouse pointer leave trailings of itself. If i tried to flip pages , they also didn't flips, and everything stays like it first page (like no swap buffers happens when need it , or no erasing, etc).

See video below of how it looks like. The same 1:1 source code, just first run its binary compiled with old (2012) sdl1 , and second run (starting from 0:40 on video) its second binary compiled from same source , but linked with last release of SDL1.

https://youtu.be/rd2EzDXy3u4

I well understand that its all a bit vague , but maybe you alrady have a clue where to look at :) It also can be that issue and with code itself, just with old SDL1 it wasn't materialized, dunno. Or maybe it still new SDL1 bug.

Can of course also upload related SDL code for brief check.

@Capehill
Started comparing different sdl versions, and for now found that with the version from adtools page (that one from which we start all bug-fixes at begining, etc) there no such bugs.

Then i tried release 1.2.15 RC 1 , from github, and bug already there. So it's something in the middle. Will try to roll back commits to see when issues starts.

To note , diskmag didn't use OpenGL here, pure SDL.


EDIT: i seems to find out when problems starts : when was compositing support added. But i need to recheck twice to be sure.

@kas1e

It would be useful to see the source code. Especially how surfaces are created and used.

@Capehill
Rechecked few times to be sure , and yes, its all happens when compositing support was added.

This commit:
https://github.com/AmigaPorts/SDL/comm ... d51457cd1565b6a1ae274072f

Once i rever that one back, all start to work.

I grab only SDL related sources of app and put it to archive there:
http://kas1e.mikendezign.com/aos4/sdl1/sdl1_newbug.zip

SDL_System.cpp , there is what all starts (at top there SDLSystem::SDLSystem) where initialisation, setvideomode, etc. Also there SDLSystem::init_display, where surfaces setup, etc.

Will try to check in meantime what change exactly cause that issue, but its something from above commit in SDL_os4surface.c (but where else, mostly that file was touched there :) ).

I tried to setup in that SDL_os4surface.c accelerated = 0 instead of 1, also os4video_device->hidden->haveCompositing = FALSE instead of TRUE : no luck. Bug disappear only when i full replace SDL_os4surface.c with previous version where no compositing was added. I.e. it can be not compositing itself, but maybe some function's changes,etc

@Capehill
Found !

It wasn't compositing at all, and it wasn't even SDL_os4surface.c !

Its SDL_os4utils.c

If you check adtools repo, there was some ifdefs to disable reporting of some masking, i.e. there is how it was (see #if 0 commeting outs with comments about p96 can't usefully works with):



So, in commit about adding of compositing, those #if 0 was deleted (probabaly in hope that if we get rid of p96 calls, then there should't be any issues to remove those ifdefs).

Once i put them back, all start to works and bug disappear.

I even download very latest SDL1 code (that one from github, one on which we now with latest sources), and just doing it like this:



I.e. comminting the same parts as it was before, and all working too with latest sdl1.

I of course can find out which one exactly cause issues in my case, but probably better will be to understand why there is issues at all, and maybe we should or put those commented outs back, or maybe somewhere inside SDL some code which check those reports made false assumptions.

@kas1e

First of all, thanks for searching for the issue. Example code used only SW surface(s), so it would have been surprising if it would have ended somewhere in the composite code path.

I can't recall the exact reason why #ifdefs were removed but I think they were required for compositing to work, since compositing uses the alpha channel. Removing alpha channel might also break compositing but I haven't tested this.

It can be that there has to be some condition ("if accelerated alpha surface" or something) for alpha channel report.

Can I get the complete code, or will you do the rest of debugging (surface properties and such)?

@Capehill
Yes of course will prepare whole archive. Just i need to upload it with ready to use .dat file, so you only will have needs to build source, and replace .exe in distrib. If not today, then tomorrow for sure

@Capehill
Sended you PM with source code and instructions of how to build/use it all. If you need any more help, plz ask ! I of course workarounded it already, but will be good to understand wtf and fix it.

ps. there lately was some new SDL1 fixes in main repo, seems they prepared for SDL1.2.16 release.

@kas1e

Did some investigation and it seems that with the older SDL library, main video surface has surface.format.Amask 0 (which makes sense in light of your experiments) while with the compositing one Amask is non-zero. Demo engine creates another surface using SDL_DisplayFormat, called "current" and it appears that this one has SRCALPHA flag set with the newer library which breaks the rendering. Doing SDL_SetAlpha(current, 0, 0) in engine code cures the rendering by removing SRCALPHA flag.

Forcing Amask to 0 on this line: https://github.com/AmigaPorts/SDL/blob ... aos4/SDL_os4video.c#L1274 should remove Amask from the main video surface and thus also cure the issue. Could you confirm?

@Capehill
Yes, setting hidden->screenSdlFormat.Amask to 0 in that SDL_ReallocFormat() fix it too.

If it didn't broke anything else (like compositing), will be good to add it to our repo of course )

Thanks for fast fix !

@kas1e

Alpha issue might still need more testing and investigation.

I tried to merge the 1.2.16 changes, sadly whole configure script is now in conflict. I wonder would it be possible to insert OS4 changes into configure.in and regenerate configure from that? Or just ignore it and create a ticket so that people know about it.

@Capehill

Quote:

Is makefile.amigaos4 still works ? If so, then we can just skip those issues with configure scripts. Imho, 1.2.16 version is probabaly if not latest one from 1.2.x , but pretty close to it. So even if we will keep only "make -f makefile.amigaos4" way, it will be not worse for sure, and will not give us any issues in future. Imho of course.

@Capehill
I working on port of IrrLicht engine: http://irrlicht.sourceforge.net/ and currently it can be build only with SDL1. While port is working, found 2 issues with it, maybe you can be of any help there.

Issue #1:

When any binary compiled with Irrlicht's "isWindowActive()" function check, then our window always stays black, till i not move mouse cursor inside of the window. Like our window is not active (while it is). On win32 it of course works as expected.

See the usuall rendering loop:



Once i remove that "if (device->isWindowActive())" , it renders then from the begining. But what for sure, is that window is active after running. Just seems Irrlicht's isWindowActive() fail by some reassons. There is source of it:




And those WindowHasFocus and WindowMinimized , handled as SDL_Events, like this:



So maybe something there fail on our side ?


Issue #2:

On amigaos4 initialising/deinitialising engine more than 2 times from the same binary , cause SDL1 to be not able to reinitialize video modes , and i just have for second time:

"Unable to initialize SDL!: No available video device"

I create simple test case for that bug:



So on win32 , it just runs second window second time and all fine, but on os4, window from first init open/closes, and then second never come up, as i have "Unable to initialize SDL!: No available video device". But it should , from programm point of view we just init/deinit SDL, nothing else..

I can made archive with those 2 simple test-cases working (with sources, and necessary lib to just compile it easy), so you can check it too if you want to. Issues happens even with software renderer, so it just about out SDL1.

PS. There is full source related to SDL in Irrlicht (1 file), which probabaly can help to understand why both issues happens:

https://gitlab.com/pgimeno/irrlicht-mi ... rrlicht/CIrrDeviceSDL.cpp

@kas1e

1) Could you debug whether the issue is focus or minimized state?

2) Issue is probably Irrlicht itself: https://gitlab.com/pgimeno/irrlicht-mi ... cht/CIrrDeviceSDL.cpp#L85 Have you added __amigaos4__ specific putenv here?

On the 2nd try, SDL has probably tried to open "x11" video device and got a nullptr: https://github.com/AmigaPorts/SDL/blob ... rc/video/SDL_video.c#L521

@Capehill
Quote:

Damn !:) Once i was able to find it and back at amigans to write about, you pretty well got it just by checking the source ! For me it was "cut-cut" work part by part until i realise that its indeed SDL_putenv("SDL_VIDEODRIVER=x11"); which cause issue.

At moment i tried to put there :



But that didn't help, still same crash. I assume it just maybe not "amigaos4", but "AmigaOS4" , or "Amiga" or so ?


For the first issue, yeah, will debug it now.

@kas1e

Try "OS4" - https://github.com/AmigaPorts/SDL/blob ... gaos4/SDL_os4video.c#L222

Dunno why Irrlicht even does this. In emergency you could just skip whole putenv business.

@Capehill
Quote:

Yeah, i just read that its should be avoided, but used for debugging purposes (dunno which ones exactly), just fear that maybe they use it for something which i can overlook.

And yep, OS4 works too, thanks !

Will try to debug first issue now

@Capehill
Digging more in first issue, and found that for win32 tests i didn't use SDL device before , i use direct win32 one:

https://gitlab.com/pgimeno/irrlicht-mi ... licht/CIrrDeviceWin32.cpp

So, once i rebuild irrlicht for win32 with SDL instead, it have the same issue !

I.e. its not amigaos4 only, but same on win32, which mean that this is bug in irrlicht then. I can think that it can be intendent if it reacts the same and with win32 direct device, but as with win32 its all fine, but different with SDL, then probabaly SDL one need to be fixed in irrlicht itself.

I anyway added printfs to SDL_ACTIVEEVENT case, and when we run binarys, then we have set SDL_APPMOUSEFOCUS, but didn't have set SDL_APPINPUTFOCUS and SDL_APPACTIVE.

Probabaly to fix that, all what is need it add some code when sdl initialised, and window open, make it active not only for SDL_APPMOUSEFOCUS, but also for SDL_APPINPUTFOCUS ?