@kas1e

I was testing the behaviour with SDL examples (graywin: pressing SPACE warps the mouse to center).

@Capehill
Interseting, indeed "graywin" for sure works. But my test i post before, i.e. that one:



Didn't (while works on win32). Strange ..

@kas1e

It might be because backend hasn't handled events and window flags are not updated. SDL doesn't know that window is active before SDL_PollEvent.

@Capehill
Found some issue with makefile.amigaos4 which you may want to change:

1). CFLAGS = -ggdb -O2 -Wall

So it should be for first -gstabs for debug build, and for second, it should't be in CFLAGS, or it always in, even with release mode, which make library be much fatter.

2). -gstabs should be added only when we build debug mode

In other words right block at top of makefile should be like this:



I.e. when one want debug build, he uncomment that string, and have and debug output from sdl, and -gstabs for stack traces , etc. And when one want release mode, then it builds without eveyrthing to speed things up and to remove debug alltogether.

With that, we have just 500kb of size of static libSDL.a in release mode, instead of almost 4mb in debug mode.

@Capehill
And seems found another bug with opengl-resizing in sdl1, this time it seems not related to PREALLOC fix (because i tried and old adtools version, and our new version with latest fix, etc). It just when you resize it again the same white. I didn't tried through previous fix with prealloc, will check too.

There is source code and binary for test:
http://kas1e.mikendezign.com/aos4/sdl1/lesson32.lha

It is nehe's lesson32.

Compile line are:

g++ -athread=native -Wno-write-strings lesson32.cpp -o lesson32 -lsdl_mixer -lmodplug -lmikmod -lflac -lsmpeg -lvorbisfile -lvorbis -logg -lsdl -lgl -lpthread

Just compile , run and try to resize.

@Capehill
I think i found why it fail to resize :

I have my screenmode as 32 bit in workbench.
Now, when we call from test case above:
bpp = videoInfo->vfmt->BitsPerPixel;
It correctly return 32 as it is.

Then, next line are:

surface = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, bpp, videoFlags );

And that one fail to resize properly. But once i change bpp to "16" manually, then resizing start to work.

It also can be that this whole SDL example just done wrong. But from other side while it should fail to resize if bpp differs, expectually, when originally it renders fine, and only fail after resizing.

@Capehill
Found another little-non-important issue : at least in SDL1 , when we come back from iconification, the window is not active by default, while probabaly should be (?) At least one expect it to be active as all other amiga apps made ourself active after un-iconification

@kas1e

[The -g flag]

I disagree with you about the -g flag. Stripping is supposed to remove the debug symbols so if file size is an issue, then just strip the binary (or shared object) before release.

But I can change -ggdb to -gstabs. Please create a ticket.


[Iconification]

Reproduced, please create a ticket. SDL2 seems OK.


[NeHe #32]

What is on the serial? EDIT: wait, found the binary, will try myself. EDIT2: so it doesn't have debug but looking at its source, there are 2 calls to SDL_SetVideoMode and the main one uses "bpp" for depth and the second one uses "16" so there is the likely problem.

@Capehill
Created 2 tickets about 2 first issues.

Quote:

Do not remember if i build it with debug sdl1 or not, but in case i didn't you can compile it from there:

https://github.com/gamedev-net/nehe-op ... /master/linuxsdl/lesson32

Quote:

Right .. Those nehe's examples never was good , most of developers says that they quite offten badly writen and should be avoided, but most of the time they works :) And maybe that SDL version done not by Nehe itself , which is not excuse of course, its just buggy code of example as was expected :)

Thanks !

@capehill
Checked your new fixes, and both last issues fixed. Thanks :)

When porting freedroidRPG and linking against the latest libSDL (1.2.15), I'm getting no transparency in the game's menu.

Problem: https://i.imgur.com/D68EOWg.png
How it should look: http://os4depot.net/filedata/snapshot/9499_1_snap.jpg

Any ideas? Note these pics are from 2 different versions of the game. So just take the 2nd one as an example of how it should look.

Edit: Clarification about which exact libSDL version has the issue.

@Mick
By latest SDL1 you mean that one on os4depot, or that one which you builds from sources from https://github.com/AmigaPorts/SDL/tree/SDL-1.2 ?

@kas1e

1.2.15 from https://github.com/AmigaPorts/SDL/releases

@Mick
Yeah, that one which on os4depot. Since that there was lots of fixes, include fixes of bmp/png loading, alpha channels and stuff. So very well it may deal with issue already. Want me to build a latest static lib of sdl1 for you so you can test ?

Yes please.

@Mick

Static, non-debug version:

http://kas1e.mikendezign.com/aos4/sdl1/libSDL_2019_10_05.zip

That solved it, thanks.

@Capehill
Maybe you aware about: is SDL_SetGamma and/or SDL_SetGammaRamp works on our side in SDL1 ?

@kas1e

No, I haven't heard about any gamma adjustment functionality in AmigaOS.

@Capehill
Do you mean that should be done on the OS level, not software-implemented in SDL ?

Btw, found another little issue when fixing irrlicht : this time its about SDL_ListModes() and maybe togeter with SDL_GetVideoInfo().

Issue is (long story):

When you create a window/fullscreen via SetVideoMode where you provide bitdepth as anything you don't have (let's say "24"), then, while all creates well, SDL_ListModes() will fail to list video modes (that expected, as if you don't have 24 bit modes what it will list). So that are expected, and it the same for win32 too.

I.e. that kind of code are fail on both win32 and amigaos4:



So that is fine and expected to be like this.

But then, to make SDL_ListMode works even if we have set "24" in the SetVideoMode, we set manually pixel format to 32 , and then it should works. And it works on win32 and on linux, but fail on our side. There is that failing on os4 testcase:



As you can see there i just set manually 32 bit to format before calling SDL_ListModes(). And that fail.

It can be that SDL_ListModes() fail to parse pixelFormat properly ?

I checked SDL_GetVideoInfo() call right after i call SetVideoMode, and in both case and on win32 and on os4 it return 24, as expected. But then, when i set pixelFormat.BitsPerPixel to 32, it then works on win32 when i call SDL_ListModes(&pixelFormat, SDL_FULLSCREEN);, but didn't on os4.

So my bet that there can be one of 2 issues:

1. just first argument of SDL_ListModes or do not parsed correctly

2. it is parsed correclty, but there maybe some "compare" , like if bits in 1st arg of pixelformat in the SDL_ListVideo mode do not equal to the bits used in the SetVideoMode call , then we fail (while should't). At least that prove while for example if we set in test case "16" to the SetVideoMode, but still keep 32 for SDL_ListModes it fail, but when we set 16 on both places , it works. Or if we have 32 in both places it works. But if SetVideoMode have one bits, and ListModes ask to list modes with other bits : then we fail.

While of course we should't fail , as we ask to list modes of bits we ask. And it works like this on win32 and linux, so probabaly that is bug on our side.