@kas1e

As SDL2 is documented to initialize haptic subsystem when SDL_INIT_EVERYTHING is passed, behaviour is probably correct. If someday there is force feedback support in AmigaOS, it can succeed. We could #ifdef HAPTIC out but it would be another hack. Maybe it should be rather documented that SDL_INIT_EVERYTHING fails due to this.

@kas1e

I fixed a buggy test case. "helloworld" is not "official" SDL2 testware, it was written by me.

If you want to see OGLES2 in action, try testgles2 rather. To draw things in OGLES2 you have to create shaders.

EDIT: extending my response.

1) Keep eye on the serial log. It will show useful stuff regarding OpenGL context opening and other things.

2) The proper way of using OpenGL is to load each function. Then it's possible to know does the particular glFunction() actually exist. I made lazy code that just assumed things like glMatrixMode exist. It does, for MiniGL. It does not, for OpenGL ES 2. Take a look at any proper project like ScummVM or ioquake3. Yes they do load and check their GL functions before using them.

@kas1e

Test code should be now fixed in r214. Of course I'm not able to test it 100%.

@kas1e

You are correct, it's my bug. There is no glMatrixMode in OGLES2 of course! For me it fails differently (context creation fails) because I cannot run OGLES2 on my machine.

@kas1e

If you receive a NULL pointer and keep messing with it, things might not work nicely. Anyway, I'm interested to see the results with error checking.

There is no native makefile yet. Configure + make works more or less. There is also a semi-working Cmake but it's not finished (works for me you know).

You can get r213 here http://capehill.kapsi.fi/sdl2/

New public release got delayed due to ScummVM related issues.

@kas1e

You have to check the return values and in case of errors, check SDL_GetError(). If it crashes after those, I will check again.

EDIT: I will check the point 2 meanwhile..
EDIT2: cannot reproduce issue 2, SDL2 r213.

@kas1e

Native makefile works, but had to add one include. I will try to merge the configure at some point but it looks difficult.

@AmigaBlitter

Mostly ScummVM.

@kas1e

After checking the code files it seems that window update code is missing (CIrrDeviceSDL::present). For SW rendering you have at least a couple of options:

1) https://wiki.libsdl.org/SDL_GetWindowS ... 29%7C%28CategoryStruct%29

2) Create renderer, create texture, update texture using surface and finally render texture. This is summarized in SDL2 migration guide as well. https://wiki.libsdl.org/MigrationGuide ... ered_frames_to_the_screen

@kas1e

Legacy OpenGL code (glBegin, glEnd, glMatrixMode etc) shouldn't even compile for OGLES2 because some of the legacy functions have been deprecated. You could study the project a bit, what gl calls are being used. With OGLES2 you need to use an external math library.

I spent some time to update SDL1 to the current level (mostly done, except the configure script, it's a monster). Branch is here: https://github.com/capehill/os4sdl/tree/1.2.15

@kas1e

What I mean that if you have some legacy OpenGL code (for example fixed function pipeline stuff), you have to port it to OpenGL ES 2 because there is no ffp anymore.

By the way, I have modified the makefile.amigaos4 now so that there is no more pthread dependency (it was used only for syscond stuff. IMHO either use it consistently for all concurrency or for none). So now it builds the same source as configured makefile and 90% of test code seems to run. Will fix the rest later, hopefully.

I haven't tested SDL_mixer but at least loopwave works (it hanged before).

@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.

@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?

@kas1e

I haven't had a chance to try your version yet but my old binary is quite slow on Sam440. It seems to draw lots alphablended stuff so if it uses actually SDL_BlitSurface, compositing might help.

@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...

@samo79

A fresh Vim would be really nice! OS4depot version is getting older each day.

@kas1e

http://capehill.kapsi.fi/beret/ I have compiled this game in 2013. Source code was an absolute nightmare.

Seems that some swaps are commented out, I can't remember why.

Check if it is any useful reference.

@kas1e

You cannot make a generic replacement for fread. It fails for structs and arrays. fread cannot know the details of your data.

You have to swallow your pride, make a loop when there are multiple items fread and convert all structs field by field.

Yes, it's annoying, boring and and an ultimate proof that the mankind cannot agree on the simplest things, ever.

@kas1e

You have to byte swap each fread item that is bigger than one byte. For example using something like https://wiki.libsdl.org/SDL_SwapLE32

Assuming sizeof(int) gives 4 :)

Sizeof(Thing) complicates...things. You have to investigate this type and swap all its parts that are bigger than byte.

Sizeof(char) you can leave alone assuming that sizeof(char) is 1 byte.

@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.