@BSzili

Regarding this endian issue...is it somekind of a fundamental issue, where somebody has to fix thousands of lines of code, or some sort of a needle in a haystack case where something has just got wrong and nobody knows where?

If it "just broke" at some point, is it possible to diff the source and try get closer to the problem?

@salass00

Done. Hopefully we get a new SDK this year :) By the way, should there also be a static libdl.a?

I'm using dlfcn.h from the older SDK for now.

@salass00

Thanks for confirmation. If you think libdl.so should be officially supported by the SDK, I can make a BZ entry, if needed.

@BSzili

Unfortunately that doesn't help me to build SDL2 with dynapi support. I found some of my older SDK has dlfcn.h by Hyperion, I wonder was it dropped from the latest SDKs or did I lose it myself.

Regarding dynapi, here is some good info https://plus.google.com/+RyanGordon/posts/TB8UfnDYu4U

Of course we can implement a symbol loader by Elf.library, or just disable dynapi, but this looks like a possibility in a world full of statically-linking developers ;)

@afxgroup, BSzili

Anyone has a recent dlopen/dlsym implementation? I found one from OS4Depot, by Chris Young. Unfortunately it doesn't work out-of-the-box for SDL2. Looks like OS4 ships with another version of libdl.so (it has different symbols than Chris').

@AmigaBlitter

There was about 1 megabyte of VRAM left when I ran Arkanoid. On serial output there was a warning from SDL that CompositeTags() returned 3. I suspect some of the bitmaps are swapped out of VRAM and CompositeTags() falled back to SW.

I propose you fix the memory leaks and try to reduce used VRAM, then retest. If there is still flickering going on but megabytes of VRAM left, I will debug the SDL side.

@AmigaBlitter

Flickering is probably caused by overdraw. Each frame background is drawn and then game elements. Double-buffering should solve it. Can you try?

EDIT: after briefly reading AnimationState.cpp, which creates Background objects with new - where Backgrounds are deleted? If nowhere, they leak VRAM.

@AmigaBlitter

That seems to be in line with my alphablit benchmark. Typically HW alpha blitting is 5-10 times faster than SW.

As I have now GCC5 too, perhaps I can take a look at the remaining problems, excluding the VRAM limitation :) You have to use smaller bitmaps to fight that one.

I have a strange ISI exception when using libSDL build with GCC5. Stack trace points to this line:

https://github.com/capehill/os4sdl/blo ... aos4/SDL_systhread.c#L165

Code never reaches plistInit() function according to serial debug. Looks like it jumps to wrong address instead of? I guess I have to try to investigate the generated code, but perhaps somebody already knows what might be wrong?

(0x5B526C80) 0x6FA0D8A4 [cannot decode symbol]
(0x5B526CB0) Beta41:SObjs/libSDL-1.2.so:_INIT_thread_init()+0xf0 (section 12 @ 0x778)
(0x5B526CD0) native kernel module Kickstart/elf.library.kmod+0x0000552c
(0x5B526D00) native kernel module Kickstart/newlib.library.kmod+0x00001f40
(0x5B526D70) native kernel module Kickstart/newlib.library.kmod+0x00002d14
(0x5B526F10) native kernel module Kickstart/newlib.library.kmod+0x00002ef0
(0x5B526F50) a.out:_start()+0x170 (section 8 @ 0x68C)
(0x5B526F90) native kernel module Kickstart/dos.library.kmod+0x00025c54
(0x5B526FC0) native kernel module Kickstart/kernel+0x00039894
(0x5B526FD0) native kernel module Kickstart/kernel+0x000398dc

@salass00

Wow, this is good news. Thanks everybody involved.

@Raziel

Unfortunately SDL with compositing cannot speed up this kind of drawing, where plotting happens by memory writes.

Compositing can do fast alpha-blending or scaling, but preconditions for HW acceleration is that source and destination bitmaps are in VRAM. (see graphics.library/CompositeTags() documentation)

And limitation for OS4 SDL is that you can only get SDL_HWSURFACEs in fullscreen mode.

So it looks like Bermuda writes to RAM in window mode and VRAM in fullscreen mode.

To summarize, you need a fullscreen videomode allocated with SDL_HWSURFACE, then you need source surfaces that are also allocated with SDL_HWSURFACE. Now, calling SDL_BlitSurface() will call CompositeTags() and operation should be hardware accelerated.

Not sure what is the point here, but GPmark is a CPU2(V)RAM benchmark, it doesn't call SDL_BlitSurface().

If you compile it with -O2, you can double the results on Sam440.

@AmigaBlitter

Please make the Arkanoid binary available. I don't have a native C++11 compiler so I can't compile the code myself.

If possible, add some FPS counter. You can print average FPS with printf() after each "game over" I guess.

Are you sure all your surfaces are HW surfaces? Have you debugged the surface->flags?

@HunoPPC

Sorry but I don't completely follow. So you have linked the new lib, but no any change? Please post link to your rendering code.

As mentioned, there are certain preconditions for compositing.

@AmigaBlitter

Unfortunately both SuperTux and Abe seems to be statically linked.

Please remember, .so with compositing prints to the serial port. You can observe what it is doing by using a terminal connected or Sashimi.

@AmigaBlitter

Does that warning print come from Mame or SDL?

I don't know is there "ldd" command for AOS4, but you can use something like "strings your_binary| grep libSDL" for checking, or serial port/sashimi to check debug prints from the SDL .so.

Which SDL scaling routines you refer to?

@AmigaBlitter

Regarding Bermuda, it doesn't use compositing. It might work faster with SDL_SWSURFACE even, perhaps Raziel want to try it.

If I remember the code correctly, it does:

1) Lock surface
2) poke pixels in VRAM since it's HWSURFACE
3) Unlock

So it does its own "blitting".

Anybody can build his or her own libraries, just clone the repo and type make. It should work.

Regarding static linkage, as far as I know, SDL 1.2 uses LGPL license (SDL2 has more free license?). I think this should be considered when linking statically.

Issues can be now reported also on GitHub page https://github.com/capehill/os4sdl

This is the fork of original. When issues are fixed, I will create a pull request against the original.

First BETA version of libSDL-1.2.so is available. My goal is to get the code to the official GitHub repo as soon as possible, but meanwhile the patch file is included in the archive.

http://capehill.kapsi.fi/sdl/

Good luck and please report the alphatest benchmark (included) results.

PS. Bermuda Syndrome uses CPU to plot the pixels, so no gains there with compositing. Compositing is activated when 16/32-bit (transparent) SDL_HWSURFACEs are drawn using SDL_BlitSurface() call.

@AmigaBlitter

I have to do some "final" testing before public release but it's not that far away, I hope.

By the way: thanks for the heads up, I will check out the Bermuda project. To my disappointment, most SDL games I downloaded, use static linkage, so it's hard to find anything "ready" for testing.