..

@Capehill
Another issue is probabaly not related to SDL1 itself (or maybe related, just i do not know at moment), and its some strange one.

I found that when i run some game (sdl1/gl4es/etc) in fullscreen mode. When i run it just as it, and enable fps counter, it show me 30 fps for example. And everything is looks just like 30 fps.

Then, when i do "amiga+m", and made by mouse workbench window (or any other window on workbench) to be active, i still have on other screen those 30 fps (as expected), but when i jump back to the game screen again and make it active, this time fps is doubled to 70 and everythng start to looks like its now indeed 70 fps.

Then, any switch back to workbench and making it active, doing game be 30 fps (as exptected as it not active anymore), and swithcing back to game make it 70fps. But not from first time! I.e. when you run it, i can see workbench is not active, and that my game active, but technically like not :)

It seems that when i run game first time (and even if i operate in it, play in it, i.e. its active), something busy happens. Once i made workbench active and then back to the game: fps back to normal.

I may think of course that its game doing something, but "depending on screens" its just amiga-thing, so maybe something on our side ?

Sorry its a bit unclear, and i can't say if it SDL1 or what else , as i can't find any other game/test which can show the same.

I probabaly can do some hack like when game runs, call intuition Lock/Active of workbench, and then back again to game, but that strange anyway..


EDIT:

I think it can be something about the way how SDL initialisation done , maybe only with this game i have some sort of combo of dbl-bufergin / vsync and something else which didn't showups before.

I currently just hack the game's init code like this:



Then it works. Through it still interesting to know why that happens and should't it be fixed in SDL1 or at least to find out why it like this.

@kas1e

Without knowing what a) game, b) SDL1/GL4ES is doing, it's very hard to help.

Is game trying to do some frame capping (SDL_Delay() in game loop)? VSYNCing?

How about this SDL1/GL4ES branch? I don't think I have seen the code lately.

And you have checked the serial line?

@Capehill

Found, that the code of game:



See there:

// inactive - just update less often
if (!irrlichtDevice->isWindowActive() )
{
irrlichtDevice->sleep(10);
}

Check in if windowactive and if not , less update with sleep(10), so exactly to reduce FPS.

I comment out that code, and everything works fine from start :)

So i checked and its just irrlicht's isWindowActive didn't return that it active (proved that by putting printfs inside), while it is. We lately in irrlicht itself fix some thing in that terms with one of remaining authors, and i just forget to add that fix to the irrlicht's code coming with game itself, and so it always return on first run that window is inactive.

But if you didn't point out on "main game loop with delay" i for sure dind't find it, so thank as usuall again :)

Quote:

I will put tomorrow on github just the changed files of SDL1/SDL2 i touch for gl4es (so can be easy seen what is changed exactly). I plan to do it before anyway, so at least that will be reasson :)

@kas1e

Quote:

Serial logs?

@Capehill

There is one from that test case i post :




And that serial log if i change in above test case 24 on 32 in the SetVideoMode call :




As i can see from both logs, it says "Listing 32-bit modes with format=6" when we do call SDL_ListModes, but then it fail on os4 if setvideomode call was with 16 or 24, or anything else but not 32. And when we want to list 32 bit modes after, it by some reasons didn't go till the point when call os4video_MakeResArray().

@Capehill
I still think something wrong with sound initialisation at least in SDL1 (but if SDL2 share the same amigaos4 specific code to initialize audio, then it probabaly have same issue).

Issue, is that once we initialize SDL audio, we always heard some noice-small-micro sound. Like, we didn't clear buffers before and there is some left over. Or like, we set in amigaos4 specific code some "mute" to high, or dunno ..

But visually, every running SDL app which will use sound, have that strange noice-micro-sound.

Can't say currently is it with just SDL_INIT happens or when we init SDL_Mixer or OpenAL, or when .. But what for sure , is that every game / app which use SDL1 with sound, at begining always have that "noice-micro-crack-sound" sound.

I will try to dig in to create a test case.

@kas1e

SDL has some audio test program. But please try first with AHI prefs test sound.

SDL1 should clear the audio buffers before they are passed to the application. SDL2 doesn't and it's mentioned in the migration guide.

@Capehill

Continued the talk about joysticks support in irrlicht with SDL1, is there anything in that code that should make joysticks in SDL1 didn't work?

https://github.com/kas1e/Irrlicht/blob ... rrlicht/CIrrDeviceSDL.cpp

I just tested it with some simple irrlicht test-case, and yeah, joystick didn't work. _IRR_COMPILE_WITH_JOYSTICK_EVENTS_ define of course defines and code inside compiles for sure.

Irrlichts test case says "Joystick support is enabled and 0 joystick(s) are present".

Test case there:

https://github.com/kas1e/Irrlicht/blob ... MouseAndJoystick/main.cpp

@kas1e

Please check first the SDL serial logs. You should see the joystick enumeration going on. "Release" build was fixed in January (so I guess you have the latest code): https://github.com/AmigaPorts/SDL/comm ... d348fc6ae4814657dba0bdc70

@Capehill
Damn! As I use some 2018 repo on top of which I add your fixes (to avoid with every new change add gl4es diffs), I simply not apply that one, as for all 4 gamepads I have none work as should in AmigaOS's amigainput. Just one seems detected, but then when I calibrate it, it always works like "left" pressed, and buttons swapped wrong. Not sure how to deal with that.

Because of that just skipped that fix before.. Will check it all, thanks for pointing out!

@Capehill
Yeah, with that fix it works now! Thanks!

Sounds like we may be getting joystick support on those new releases then 😉

@outrun1978
Probably only in supertuxkart. As seems its only one support joystick properly. Check supertuxkart thread for a link

@Capehill
Probabaly its bug, but libSDL.so for "version" always show
"SDL1_2_15 1.4 (22.01.2018)" (And i found inside of .so the same string for VER$), and does not matter when you build it. As i see versioning and getting date works ok for SDL2, can it be added to SDL1 as well ? (Seems it was before, just didn't works now).

That need it so we will know date of build, to compare things. As for now i found some bug, and it hard to track down to some specific version as since some time any version we build in repo, return that date.

It didn't have automation before: https://github.com/adtools/os4sdl/blob/master/src/SDL.c#L56

Maybe you can try this: https://github.com/AmigaPorts/SDL/pull/127

@Capehill

SDL_LoadObject() has been implemented as #107 in SDL1.

I was only now able to test it, but i'm still getting the same error with 1.2.15 as i got with earlier versions.
Quote:
But maybe i misunderstand what exactly has been implemented?

@Raziel

The last public 1.2.15 release was in June 2019 but the SDL_LoadObject was added in November. To get it today, you need to build the library which is a simple task to do.

1.2.16 RC 1 can be released some day.

@Capehill

I see, thank you

Looking forward to the next release then...

(Trying to find a difference in the shared object crashes...maybe there is one using different SDL versions, doubt it, but worth a shot, i guess)

@Capehill

Tried to build with fix about build dates, and it fail when build static lib, saying:

Quote:

So i added -D__AMIGADATE__="$(AMIGADATE)" also to $(STATIC_OBJDIR), and all builds then and both static and shared libs have correct version now.