SDL1 open issues

@kas1e

Filesystem may need porting but smart_ptr and format likely not. SuperTux uses OpenGL or SDL Renderer. I didn't look further but I suppose it can be compiled without OpenGL if necessary.

You can check the serial log after HW_SURFACEs have been enabled: https://github.com/capehill/os4sdl/blo ... os4/SDL_os4surface.c#L414

wrong thread, sorry

@Capehill
Based on your expirience with SDL, how hard it will be to add OpenGLE2 support to SDL1 ? I mean what need to be done for, some lots of new code ? Is it "only" about creating video/amigaos4/SDL_os4gles.c taken SDL_os4gl.c as example ?

@kas1e

How do yo plan to select the library? IIRC there is no hint subsystem or version attributes in SDL1. You could use a flag maybe.

It's not necessarily very hard but code can get more messy. It would be a good idea to refactor the code a bit at the same time, use separate files etc.

But SDL1 is a dead horse. I would rather port application to SDL2.

@Capehill
For us on aos4 when we port things, its still most if time sdl1 :( imagine rewrite 20 apps from sdl1 to sdl2 just to make a port of some game :)

But yeah, if choice to where spend resources, then sdl2 for sure

@Capehil
Need some help :) I want to try to add GL4ES to the SDL1 (so to try to port some SDL1/opengl apps to see how it will behave).

And question is: how to do it all right and easy, without much problems. Even currently enough to have only gl4es instead of minigl, no problems for local tests.

gl4es is just a static link library, + standard mesa's GL/gl.h include + #include <proto/ogles2.h>. But no need to open ogles library, it is all handled inside of gl4es already.

I see there:
https://github.com/capehill/os4sdl/blo ... ideo/amigaos4/SDL_os4gl.c

os4video_GL_Init - that one understandable, can swap on ogles2
os4video_GL_Term - that one too
os4video_GL_GetAttribute - that one can keep as it
os4video_GL_MakeCurrent - can keep as it
os4video_GL_SwapBuffers - can keep as it


But then, os4video_GL_GetProcAddress() and os4video_GL_LoadLibrary() - are it need it for me if it not amiga library ?

I also found https://github.com/capehill/os4sdl/blo ... migaos4/SDL_os4_wrapper.c

There is list of not implemented/implemented functions , that probably also do not need ?

In other words, is it enough to just fast hack SDL_os4gl.c, or its all tied into SDL more deeply ?

Of course will be cool to add it somehow "normal", i.e. to have and minigl, and gl4es , and or in SDL progs add a flag, or, instead, at compiler-runtime do use something like --os4opengl=minigl or --os4opengl=gl4es (or if add later opengles2), --os4opengl=ogles2

EDIT: Damn, there is also amigaos4/SDL_os4video.c which need adapting from minigl to gl4es :(

EDIT2:

Hm, minigl have that (from SDL_os4gl.c):

Quote:

While OGLES context didn't have those front/back buffers, but whole thing in os4gl.c based on them. For example in os4video_GL_SwapBuffers that all used.

@kas1e

I would create another backend file for gl4es and choose that at compile time, or via some switch/flag later. For example SDL might fallback to MiniGL if it cannot open OGLES2 context.

You need to be able to get function addresses, it's an SDL feature. You need the ProcAddress mechanism. If gl4es has it internally you may not need a wrapper table then.

If you link gl4es statically, then there cannot be .so with this feature and this must be considered with license of ported application, SDL1 and gl4es. gl4es license looks liberal, SDL1 is LGPL, application licenses depend.

Heading for work now, might read some code during weekend...

@Capehill
Thanks for insign !

With help of gl4es author i just hack gl4es support into sdl1:



You can see there in console behind output from gl4es debug.

That whay i do:

1. completely remove content of SDL_os4_wrapper.c (so 0 bytes), and then it didn't include all those SDL_os4_notimplemented_funcs.t and SDL_os4_notimplemented_table.t

2. in the SDL_os4video.h, at end of SDL_PrivateVideoData structure replaced struct GLContextIFace *IGL; on void *IGL; (so for ogles2 context)

3. in the SDL_os4video.c , in the os4video_AllocateOpenGLBuffers() , commented out:

Quote:

4. And new SDL_os4gl.c:



Through, that only sme hack, and probably nothing else except test-cases will works. As you see i delete there everything, keep only simple main things so to check if it works, and it is.

We just need to think now how to implement it all in normal way. I think fallback to minigl will be wrong, as it all can runs, looks wrong, and everyone who have no ogles2 will think that app/game broken. Better "sorry, its is only for ogles2".

As for how it all handle : from one side, compile everything in, is good and then choice by flag. But then, need to touch SDL code then all the time to add that flag. From another side, if we do not want to touch sdl code, and choice what to make inbuild in SDL, then.. then there will be different link libs, like libsdl_mgl.a, libsdl_gl4es.a , libsdl_ogles2.a which dunno, kind of suck too..

@Capehill
And something still seems wrong somewhere about SDL_GetTicks() when builded with "make -f makefile.amigaos4"

For sake of tests i then just re-downloaded https://github.com/capehill/os4sdl , latest master build. Then "makefile -f makefile.amigaos4". And once i port any game which have SDL_GetTicks() in , it always crashes on it.
I.e. its even without GL4ES changes i do.

Through, some simpler test cases (like SDLgears, which do use SDL_GetTicks() too : works).

I also tried to rebuild it with (just in case, as i remember that works before):

Quote:

It builds fine too, but then, the same crashes in SDL_GetTicks() :(

I then build prove-to-be-working-in-past version from adtools repo (via the same ./configure line), and it works ! No crashes in SDL_GetTicks()! Apply GL4ES changes: still works.

So..

That mean, is that we do broke it or when do changes in terms of removing of pthreads support (not remove it fully?), or when update to 1.2.15 , or when change configure scripts.

@kas1e

Need references to crashing code. Most likely timer initialization wasn't done properly. As I wrote earlier in this thread, there was suddenly a problem with .so where library constructor functions were not called at all(!). So I just call the constructors manually from SDL_Init. I hope your code called SDL_Init..

@Capehill
Quote:
You mean stack trace ? Or packed/ready-to-build source code ?

Quote:

Of course :) Its 2 games i tested which i already ported over old versions of SDL1, and which works, they for now just crashes in SDL_GetTicks().

In one game it called like this:

Quote:

In another one it called like this:

Quote:

Both games didn't crashes on version from adtools when builded via configure;make with --disabled-pthreads.

@kas1e

Minimal problematic source code would be the best. Can you make some of the tests crash, for example? Last time I tried, they worked 99% OK.

@Capehill
If minimal is possible :) Simple test case with SDL_GetTicks() works, but when it used in the games, then crashes. Once i rebuild it against version on adtools, then no crash.

I may try to reduce games code step by step, and then will have small test case, but it will take time.

Need more information. Stack trace and source code would be a start.

I made a test program that calls SDL_GetTicks()/SDL_Delay() combo in a loop and can't make it crash, static or shared.

Maybe its related to threads.

@Capehill
Quote:

Very very possible. As simple test-apps didn't crash , only games. And its about threading which was removed/workorounded after adtools version => very possible that its threads.

@kas1e

Pthreads were only removed in the native makefile. Configure+make build did already use native threads years ago.

Maybe you could add some serial debug here:

https://github.com/capehill/os4sdl/blo ... igaos4/SDL_systimer.c#L51

Print ITimer pointer before using it. Optionally add NULL pointer check around code.

@Capehill
Quote:

To clear it up a bit:
-- your version builded with native makefile => crash
-- your version builded with conigure/make/disabled pthreads =>crash
-- adtools version builded with native makefile => crash
-- adtools version builded with conigure/make/disabled pthreads => WORKS

Quote:

Yes, will do so.

@Capehil
Ok, i just do:



And have:

Quote:

Probably there no needs for crashlog, as ITimer is just null ?

When i build adtools vesion with ./cofnigure;make and --disabled-pthreads, then, doing the same prinfs in the same place, give me pointer address and all works fine.

Question is: why it works only in adtool's version, and only when build with ./configure;make --disabled-pthreads, and not, when build with native makefile, or even with ./configure;make, but without disabling of pthreads.

As configuring process make no changes in os4 source files, but only to SDL_Config.h and related to sdl non_os4 files, then it imho somewhere some flag, or ifdef, or kind of missed/skipped/sets wrong.

Sure there is bug anyway, as it just didn't works with pthreads at all, but for first need to understand what is differences between build of your version and adtools version, when they both builds with configure;make --disabled-pthreads, but adtools one works, and your one are not.

@Capehill
After just searching in whole .h files on the word "THREAD" (case sensetive) , and to compare them with your version, and with version from adtools, i can see that SDL_thread.h a bit different, as well as SDL_thread.c. But swapping them from adtools version over to your one, didn't fix problem, and ITimer still 0x0.

Then i just checked SDL_os4timer.c files, and they really different. In your one all is "simple" , without any INIT , without any:

Quote:

While adtools's version have that.

For sake of tests i just swap out SDL_os4timer.c from adtools over our one , then do change in the SDL.c os4timer_init on os4timer_Init (as it in adtools version like this). Recompile, build, run : Pointer here !

So, something happens when refacturing and changes was done in the os4timer related code since adtools version.

@kas1e

It's Autolib (-lauto) which gets the interface for ITimer on your behalf. Otherwise you have to get it yourself. I have not checked any of those source files you listed. But one of those init functions handles it most likely. Or in some of the makefiles the Autolib is enabled and in some of them it's missing.

With libraries:


With devices: