SDL1 open issues

@Capehill

I aslo made same kind of test case for SDL2, and it works fine an on win32, and on aos4. There is :



I.e. same kind of logic and code for set 1 pixel transapent cursor, and it works with sdl2 on both plaforms. Difference only that in SDL2 test case i fill whole window by red color (thore "render" parts), but that no related imho.

In other words problem only on os4 and only with SDL1..

@kas1e

SDL2 uses true color pointers, a different way of creating them.

Found another bug in SDL1 backend: https://github.com/adtools/os4sdl/blob ... amigaos4/SDL_os4wm.c#L211 According to web documentation, height parameter comes before width and this is reversed in SDL1 code.

@Capehill
Interesting.. Just swaped height with width, and it did fix garbage in the grafx (horray!), but, os4 test case from post#20 show nothing as well (while should show 4 dots). What mean there still something wrong can be .. Btw, even with original AllocVecTags(4*h+4 it is like this (i mean like those changes make no differences, not in grafx2, not in test case).

@Capehill
While plaing around with another port where i can see distorted mouse, i found probably another major bug of SDL1. If you have time, maybe you can check if you can reproduce it as well

Problem is: latest SDL1 sources when builds with "make -f Makefile.amigaos4", build all the stuff with enabled pthreads support. Then, if we will make any kind of code which use Mix_OpenAudio from SDL_Mixer, let's say something like "Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT, 2, 1024)"; then app just froze and nothing happens.

Last what can be seen from snoopy log, is that SDL thread starts, and OpenDevice("timer.device") doing ok and then nothing.

If i just grab sdl1 user archive from os4depot (which builded without pthreads, that can be seen in the libsdl.a itself, there almost no references to pthreads), then all works fine, Mix_OpenAudio didn't fail.

Also if i just re-configure latest SDL1 code, with --disable-pthreads, and compile libsdl.a , it also works fine on the same code.

For sake of tests, you may try for example or just this piece of code:



Or, a bit more intersting one:
http://lazyfoo.net/downloads/index.php?file=SDLTut_lesson11

@kas1e

I don't remember even howto build SDL1 (it was 2015 last time). I didn't configure it, that much I recall.

But why do want to complicate matters by using pthreads? SDL1 has its native thread code and I was hoping to add similar thing into SDL2.

Does it work any better if you call Mix_CloseAudio before SDL_Quit?

@Capehill

Quote:

You can or just do "make -f Makefile.amigaos4" (and then it will build SDL1 with pthreads). Or, you can reconfigure it from scratch. On crosscompiler cygwin i do it like this:
./configure --build=i686-pc-cygwin --host=ppc-amigaos --disable-shared --enable-static --disable-pthreads


Quote:

Its not that i want to compilcate things, it just i point out that something wrong in SDL1, specially when you build it as intendent (i.e. with "make -f Makefile.amigaos4") :)

Quote:

Its just hangs on Mix_Open, and nothing works after, i.e. you can't call any other functions. But once i recomplie SDL1 without pthread (i.e without wrong default), then it all works. I just want to point on that bug, as probably or we need to get rid of pthreads in default build for sdl1, or, that to be fixed (if :) ).

@kas1e

Makefile.amigaos4 fails for me, there is a compiler error related to thread code ("abstime" or something?). Have you modified the source?

Yesterday I tried to just "make" the project but in the linking phase there is a ton of warnings. SO is finished but it seems to crash on SDL_GetTicks() always. Strange. I'm pretty sure this worked in, er, 2015.

Now I'm trying configure + make route (natively).

@Capehill
Quote:
If you on native, you probably need to run all that "makefile.amgiaos4" from "sh" (same as those ./configure;make). If you don't already :)

I use both ways on crosscompiler.

Quote:

Its because when you run "make" it just use basic makefile which looks more heavy and probably too old for.

@Capehill
Should we commit your fix from post #22 to repo on adtools ? Visually fix from post #18 made no differences, but #22 did. At least in grafx2 and gigalomania_sdl1 your fix from #22 did the trick. And while my last test case show that there is still some differences with win32 in compare, it still better as it now.

Also, is any of us able to close tickets in adtools repo ?:) Many of them can be closed already.

@kas1e

I think the memory allocation bit is important too. If we allocate too little, AmigaOS might read/write invalid memory. But now I'm confused. Consider the example with 16 lines of data: http://wiki.amigaos.net/wiki/Intuition_Pointer

I can understand the 18 lines, the upper and lower parts are for the system. But what is this 4 more "control words" that make total amount of 40 words (20 lines!)? I am not seeing this in the coded example, and unfortunately there is no dynamic allocation. Quote:

"The pointer in the example, a standard busy pointer, is sixteen lines high and sixteen pixels wide. Currently, all sprites are two bit planes deep, with one word of data for each line of each plane. The example sprite image consists of 36 words (2 planes * 18 lines = 36 words). Add to this the four reserved words of control information for a total of 40 words of data. See the example below for the complete data definition."

***

One possibility would be to create pointer like SDL2 backend does.

@kas1e

I got finally a half-working .so built with makefile.amigaos4. There is a missing timespec definition in my SDK (same thing happened with SDL2). Makes me wonder how you have solved this? Are you using some modified SDK perhaps?

But there was a NULL pointer crash somewhere in backend during SDL_Delay(). Trying to investigate some day.

@Capehil
Damn, missed somehow your answer in that topic yesterday !

Quote:

I build and use only static version (for tests is much more better and easy than shared one), dunno through if it relevant, but ! What i found is that in the common/include/pthread.h, i have that:



Dunno when and for what i do so, maybe exactly because of issues you point out on.. That from other side can point out on issues i have when build it with enabled pthread (when makefile.amigaos4 is used).

Damn we need to sort all that crap out, and clean it a bit from all shit (there is even few very old tickets about). Probably better working on version which is placed on adtools page ?

@kas1e

I have pushed some fixes and hacks to my fork. I'm trying to figure out the DSI with .so, it surely didn't happen in 2015...

@Capehill
If you build it with makefile.amigaos4 , then it mean "pthreads" in use, what mean that there is will be bugs about which i told in previous posts in some other thread (i.e. SDL_Mixer hangs, etc).

@kas1e

After debugging .so (built with provided Makefile), it doesn't seem to call library constructors which seem to explain DSIs. However, it calls destructors. Static library calls constructors. This is a strange issue, any idea what might block the constructors? _INIT* functions exist as T symbols, similar to destructors (_EXIT*). Compiler (GCC 4.2.4 used) should be placing the calls as far as I undertand it, but is there any other component playing a part here?

@Capehill
Maybe something with PIC_CFLAGS = -fPIC -DPIC ?

You want firstly fix shared object's build ? It probably also will fail with pthreads on SDL_Mixer, same as static one, but to be seen..

@Capehill
Btw, i am working on some huge port, which is use SDL1 as window manager, and can use renderers as OpenGL (so no go for limited minigl) and Ogles2. Sadly that project have no support for SDL2 at moment (when we have ogles2 support), but, maybe it possible to build SDL1 not with MiniGL, but with Ogles2 instead ?

I think its unpossible to build with both at the same time of course, but even if it possible to make version with ogles2 instead of minigl, that can give huge boost to all SDL1 apps.

Or maybe something like minigl as default (SDL_OPENGL flag a it was), but if user specify something like: SDL_OPEGLES2, then we can use it for OGLES renderer. I.e.:
screen = SDL_SetVideoMode( 0, 0, 16, SDL_OPENGLES | SDL_ FULLSCREEN );

Even some hack way, or whatever .. all i need just ability to have SDL1 window manager, and use ogles2 renderer to it. As you already add it to SDL2, maybe it will be not big problem to add to SDL1 it as well ? I will be very happy to test, to debug, and to help with. In end of all of this we may have some very good and fast ports.

@kas1e

It should be easier to port game code to SDL2, compared to adding OGLES support to SDL1.

Build scripts would need to be able to detect OGLES2 and then some logic for loading the correct library (no idea what is the way with SDL1), load the GL functions etc. It's true that some code could be reused from SDL2.

OpenGL 1.x and OGLES2 have a different set of features and functions. Legacy OpenGL renderer should be ported to OGLES2 as well.

@Capehill
Quote:
Its not game , but engine, on which based lots of good games. And authors of engine sure someday will add SDL2 support, but just when... again waiting years :)

Quote:

Not sure what you mean here , as OGLES2 can work without OpenGL at all (that why i think about adding it to SDL1, without that dated MiniGL). At least i do not know how it done on other platforms, maybe on windows opengles based on opengl as wrapper, but in our case Daniel done it as standalone, and not rely on OpenGL (but you know it of course:) )

Or you mean, that we need wrapper over Ogles2 , so to have full OpenGL2 ? Sure, that would be cool, but then, no one will write it and it huge job. All the opensource variants of such wrappers are unfinished, untested and buggy (at least that what i understand when checking those 2 variants, one was dropper eyars ago, another one in unfinished-buggy state). And even if we will have such wrapper, then it still mean to do changes in SDL1, again..

In other words, i trying to find a way, how i can use Ogles2 with sdl1, without involving of minigl. I read on google, that for some devices such port of SDL1 was done, i.e. where ogles2 only present, it was "harmattan port of SDL1.2", but at moment find no source of it to look at..

@Capehill
After thinking a while, i think there can be few ways to archive what i want (to use that engine with ogles2):

a). waiting when then their engine will have SDL2 (can take years as usuall)
b). trying to add ogles2 support to our SDL1 (hard as you say).
c). trying to write my native-os manager for engine, so avoid anything SDL or co, just pure native manager, which will open intuition window, and to which rendering from ogles2 will happens.
d). myself rewrite their SDl1 to SDL2, in hope that there will be no issues in SDL2 in terms of ogles :) But even if, then it can be good test case.