@Raziel

Yeah, I saw the Cygwin thread. At the moment I am preferring native compiler, it just feels more comfortable environment for me.

Will there be a new release?

@Raziel

Which compiler you using? I think my older GCC didn't warn about commas. I need to switch to GCC 5 now.

@tommysammy

Nice. I get 700 FPS for RenderCopy on Sam440 (M9).

@kas1e

Thank you!


@all

Both developer and user archives (r119) can be now downloaded on the project page: https://sourceforge.net/projects/sdl2-amigaos4/

SDL2 has been tested mostly on Sam440 system so probably some problems can appear. Issues can be reported here and on the project page.

User archive contains a simple graphical benchmark. Please post your results here.

Today I have removed dependency to libdl because there is no dlfcn.h header and libdl.a in the current SDK. Currently, to link SDL2 app, only "-lSDL2 -lpthread" is needed, with or without -use-dynld.

If it's true that dynapi cannot work with our shared object then it can be disabled and custom implementation removed too.

There were also changes to configure script, to get libSDL2.so done and to get sdl2-config prepared in a way I believe it should be. Please let me know if something is broken.

@broadblues

Well, personally I try to use dynamic linking whenever possible. One good reason is that for example SDL1 used LGPL license.

https://plus.google.com/+RyanGordon/posts/TB8UfnDYu4U

@kas1e

Old thread, but I think I have hit the same issue.

I have a binary with statically linked libSDL2.a. SDL2 offers an option to load another libSDL2 dynamically so that the functionality of the original can be overridden. This works when binary is dynamically linked to libSDL2.so (libSDL2.so loading another libSDL2.so), but with statical linking, it grims and stack points to libc.so (NewlibCall).

Is there a correct way to make "static lib loading a dynamic lib" work? I tried to link binary with -Wl,--export-dynamic but it didn't help.

There is one issue I would like to see solved before beta release: that's libtool refusing to build a shared object due to -no-undefined.

It's possible to just remove -no-undefined but that also means modifying of makefile.in and configure.in. So if anybody knows how this _should_ be fixed, it could make release sooner, and perhaps less hacky.

@all

My warmest thanks for all the support! Work continues whenever time allows...

@AmigaBlitter

Fixed keyboard events, testing needed :)

I have setup a git project for the Zod Engine. Maybe we get the network endian fixed eventually. SDL2 port might make sense too (compositing).

https://github.com/capehill/zodengine

@kas1e

Each renderer has a bunch of tags. SDL2 picks up a matching renderer (for example, first one with "acceleration"). We can decide which renderer is checked first, OpenGL or compositing.

Developer can also give renderer name as a hint: https://wiki.libsdl.org/SDL_HINT_RENDER_DRIVER?highlight=%28\bCategoryDefine\b%29|%28CategoryHints%29

Currently compositing renderer is called "compositing". Is that ok?

@kas1e

There are many different SDL applications so a general speedup is hard to do.

With SDL1 blitting opaque HWSURFACEs is already accelerated.

If you are looking for alpha blitting speedup, you could try my fork of SDL1. In fullscreen mode HWSURFACEs are blitted using compositing. So if you have a bunch of HWSURFACEs waiting to be blitted, this is the way to go.

But if the application plots the pixels (surface->pixels) by CPU, there is very little that can be done. It depends how fast your CPU can write RAM or VRAM.

@Lio

Somebody should fix the network code because it ignores endianness totally. This is a boring job. Maybe sometime after SDL2? No promises though. Without fix, you would be only able to play with big-endian players.

Speed is something where SDL1 with compositing might help a bit. OpenGL renderer is problematic. It draws in immediate mode and uses non-supported texture sizes. No big gains here if I remember correctly.

So I guess this is somewhere in my todo list. But I can start a github project if somebody wants to help.

https://github.com/Croteam-official/Serious-Engine

This might be portable, as far as I understand it doesn't require OpenGL shaders.

r81 tries to fix fullscreen toggling issues.

I might start compositing renderer next week as there isn't much else to do with SDL2 port...well OpenGL code needs probably some work (context attributes and bitmap depth) but it can be used.

Mouse cursors are missing too. And window backfill hooks. And those asm optimized converters are also not merged yet.

@BSzili

Texture update takes 15-20 ms for the same 800*600*32 texture. These time figures are from SDL_GetTicks().

Tried to alter texture filtering and blend mode but no visible change. Unless there is something with the texture format, I don't know can anything be done on the SDL_render_gl.c side.

@AmigaBlitter

Today I built Starfighter project and can confirm the slowness, fullscreen issue and potentially some keyboard issue.

Game was faster in SW mode, especially with 32-bit workbench (game uses internally 32-bit surfaces). To my surprise HW mode doesn't seem to suffer from texture updating, but a whopping 250 milliseconds is spent during glBegin/glEnd. Possibly the large texture (800*600*4) is the culprit here, because when I decreased the resolution to 400*300, drawing became something like 60 ms so it looks linear. But 250 ms is really slow. I tried vertex array with glDrawElements but it wasn't faster. After all, it's only 2 triangles drawn here. Next step would be to profile MiniGL but it will take some hours. You could decrease the in-game resolution but unfortunately game uses hardcoded magic values here and there. Nasty. Still, maybe you can replace all "800" with screenWidth and "600" with screenHeight and then just use a smaller reso like 640*480.

Regarding fullscreen mode, probably desktop mode fullscreen is not sensibly implemented or something, have to do some more testing.

Regarding keyboard, either game uses really exotic controls or there is some mapping issue in SDL. I had a hard time figuring out the controls. And I couldn't bother reading the code :)

Regarding CODE, once again it:

a) doesn't destroy renderer
b) doesn't destroy texture
c) doesn't free the screen surface

So all these are leaked during the exit.

Some of the found issues are now also in the official bugtracker, for example:

https://bugzilla.libsdl.org/show_bug.cgi?id=3290
https://bugzilla.libsdl.org/show_bug.cgi?id=3291
https://bugzilla.libsdl.org/show_bug.cgi?id=3292

TODO: report SDL test suite issues.