Optimize SDL blitting routine

Hello,

doesn anyone know if there's a way to optimize the SDL 1.2 blittling routines?

Using 32 bit mode is slow even in 640x480 if there are a certain number of blitting operations.
Could be possible to substitute at least the blitting part using the compositing? This probably would imply the conversion of an SDL surface to an amiga surface. What do you think about?

Without having any idea how SDL works, I'd say: Sure, that's possible!

@Deniil

SDL uses his own surface:

https://wiki.libsdl.org/SDL_Surface

Having this info about the SDL surface, a very fast way to convert the SDL surface to an Amiga surface, then blit via compositing.

@AmigaBlitter

Looks like normal bitmaps. Compositing should be able to handle most of these formats I presume. At this time there is probably some incompatibility between the surfaces most SDL programs use and Amiga, so a software conversion has to be run before the bitmap is blitted.

I don't know where this conversion happens. Maybe there is a manual copy/conversion from SDL to an Amiga bitmap somewhere that is actually unnecessary, but added for maximum platform independence. It would probably be possible to use a blitting function here for most cases, or maybe even skip this step completely, just put it on a composition bitmap and off it goes. Don't know the abstraction inside SDL, but it's probably quite high so lots of conversions and layers needed to go through.

@Deniil

Hi,

in the SDL_os4Surface.c seems that almost the conversions are made:



there are other routines too.

The sdl_os4blit contains assembly routine for copy from an 8-bit paletted surface to a 16/24/32 bit surface

Please check how Alain Thellier managed to redirect rendering from SDL to compositing here : http://os4depot.net/index.php?functio ... action/abbayedesmorts.lha

Hopefully he sees this thread and comes to explain what he did

@K-L

This one doesn´t use SDL at all... it´s more after "CompositePOC" (Aminet). The concept used there is not very SDL-ish, and I think that compositing could be used in SDL in very few points (blitting incl. alpha channel, for example. But not with RLE surfaces etc.)

@whose

Quote:
Even if it is only needed with alpha blitting (& maybe blitting with 2D transforms), implementing it could make a big difference. If a game uses alpha blitting to render almost everything, then accelerating that function becomes critical. From memory, lack of HW accelerated alpha blitting was a key performance killer for several SDL games.

As an aside, the Quake III engine renders pretty much everything using glDrawElementsTriangles() with arrays of triangles whose vertices are in tri-strip order (and uses compiled vertex arrays where possible). That makes this one particular draw function and mode performance critical for that engine. Indeed, I've read that ATI implemented driver optimizations specifically for Quake III based on the above.

Hans

@Hans

I don´t know the implementation details of the SDL alpha blit function, but I would think that it blits rectangles.

AbbayeDesMortes uses the vertex mode of CompositeTags() (as I do in my several test programs *hint* ), that´s why I think that it isn´t very SDL-ish...

@whose
Quote:
If SDL doesn't support 2D rotation & other transformations, then that should make implementing HW acceleration easier.

Quote:
Not sure what you mean here. The one question that matters is if CompositeTags() can do what SDL's alpha blitting is supposed to do. So long as SDL doesn't use a premultiplied alpha, then I'd expect that the answer is: yes, it can.

Hans

Hello

I agree "Abbaye des morts" currently dont use SDL at all
SDL calls in original sources have been replaced with AmigaOS equivalent for the Amiga port
So there is now a function for drawing rectangular "sprite" that works the same ways as SDL but use CompositeTags
>uses the vertex mode of CompositeTags()
Yes but that is not a problem as it used to draw a rectangular "sprite" but let you the freedom to rotate/resize it if needed (like CompositePoc)

Alain Thellier

Here's a function where to look at, as well as the other functions present in the SDL_os4utils.c

I am working with experimental SDL 1.2 library which uses compositing for alpha blits. It currently works in fullscreen only (with SDL_HWSURFACE). Colorkey emulation is planned via alpha channel.

Hans: SDL1 transparent blitting operations are per-pixel alpha, per-surface alpha and color key, and there is no scaling/rotation. SDL2 seems to be a different beast.

@Hans

Quote:

I do not get the big deal, already support 2D rotation in my Allegro implementation, its pretty simple.

@AmigaBlitter

One more thing: if both source surface and display surface are SDL_HWSURFACE (== BMF_DISPLAYABLE), SDL (opaque) blitting is HW accelerated. IIRC this is currently only possible in fullscreen.

@Capehill

Thank you. Very interesting.

I was trying to do the same (not with the alpha part, btw).
Actually i was about to substitute all the old IP96 using the IGraphics part of the new SDK.

Btw, thank you.

Please tell me if i can help even with the tests

@Capehill

I'm happy to read SDL is improving.

@Capehill

Any news on your compositing implementation for SDL 1.2?

Thank you

I have just moved house so unfortunately no progress during the last 2 weeks. Today I have unpacked my OS4 machines so experiment should continue.

Meanwhile, what kind of blitting project did you have? Alpha used? What are your source and destination surface specs?

Hi,

sorry for the late reply.

It's a sort of of multiple sprite blitting and the usage of a particle system. Yes, alpha is used. Source and destination surfaces are SDL surface, 32 bit.