Optimize SDL blitting routine

@Capehill

HWSURFACES should be in VRAM, and should be used when composting images, HWSURFACES (in VRAM) should not be used when plotting pixels, so this sounds like not optimized code.

when locking and plotting pixels you should use SWSURFACES (in RAM).

Here is very good reason to hurry up SDL2

Freeablo, remake of Diablo engine.

http://freegamer.blogspot.fi/2014/04/ ... t-diablo-source-weve.html

@thread

Tested Mame SDL. More fast.

Some info in the sdl window:

WARNING: SDL_GetVideoInfo() for driver <OS4> is broken.
You should set SDLMAME_DESKTOPDIM to your desktop size.
e.g. export SDLMAME_DESKTOPDIM=800x600
Assuming 1024x768 now!

I think that it renders in 1024x768 but it's scaled. Btw, it's faster.

Tested a modified version of Arkanoid (Michael T.). I added in game background scrolling with large bitmaps (3 1800, 1050), and it's faster (playable now in 32 bit 800x600).

About mame and other games don't know if they should be recompiled.
Btw, there is a large room for improvements.

SDL scaling routines, can be substituted with the Composited version too?

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

Hello,
After a lot of tests I am completely disconcerting.
All games emulators or do you speak at home using composite rendering, complete failure of all my tests.
Even better I go further, removing the libSDL1.2.so and continues to run the emulator (I mean SDL_MAME) so that means it does not take advantage of the lib Shared object.
Bermuda no difference with the new or the old lib
I tried to include in the new lib like nothing finalburn no difference there.
What I think needs to be done:
Here to source code that exploits the function and be sure it works properly, then expand our testing our games and rework it all
What do you think ??

@HunoPPC

Please copy the .so first so SObj, then try to clear appdir and reboot.

Try Supertux game enabling the FPS counter.

I get 37 fps here with my Sam440 ep 667 mhz.

thank you I know how to do, what I mean is that most games or emulators which you speak will need .so dependence because they are statically compile. how does it to win fps if you do not use the new composite function ?? Please explain me
Best regards
HunoPPC

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

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

@Capehill

"Unfortunately both SuperTux and Abe seems to be statically linked."

Don't know why, but are really fast.

I recompiled the libraries using GCC 4.9.1

Moreover, as said previously i modified the Arkanoid source to add large moving backgrounds that are "blitted" while moving the mouse, playing at 32 bit color depth at 800x600, while previously i was able to play (slowly) only at 640x480. Now the speed is acceptable at 800x600x32.

There is certainly a speed increase.

*Done other tests with Arkanoid. The speed is lower than expected. Using HW surfaces the redraw is slow, in the order of 10 rows of pixel at time.

Btw, as said previously above the speed is increased in the SDL game i've tested.

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

@AmigaBlitter

Please test avec this and return me your evolution
i have added my tests include on the archive on GPmark
launch GPmark.exe and wait
I have added 16 bits with HARDWARE SURFACE on SDL and linked the .so for no static lib
Enjoy now
Best regards
PS: it's possible added new code for your personal tests

www.clubevolution4.com/Test-HW-Surface.lha

@HunoPPC
From my X1000
http://www.indiego.rocks/file/downloa ... 06956d614798c1e8ceb8ad560

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.

@Capehill

Quote:
Unfortunately Bermuda Syndrome doesn't feature an FPS display.
And it's already fast with the HWSURFACE in place (at least no one ever mentioned any slowdowns).

Would the game's display speed profit from your beta lib if it's compiled with SWSURFACE instead?

@Raziel

It's strange if there compiler switch for that.
The game developer should know when to use what where,
HWSURFACES should be used when the program is compositing bitmaps(surface) on top other bitmaps(surfaces)., SWSURFACEs when there is pixel plotting in side bitmap(surface). so it should depend on what is going on inside the game, not something you enable or disable.

@LiveForIt

Oh, you misunderstood, there is no compiler switch for that.

There is only one single instance of HWSURFACE used in the whole source at all, which could be changed to SWSURFACE, that's why i asked if there would be a speed enhancement if i'd compile such a version.
(and if such a version would profit from that beta sobj)
Quote:

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

@Capehill

Thank you for the clarification

@Capehill

Check your PM for the link of the modified Arkanoid game.