Faster way to do an SDL_BlitSurface

I heard that with memcpy it should be faster, and it seems to be, but
the result is not good. This is what I’m doing:

memcpy (screen->pixels, image->pixels, resWidthresHeightcolorDepth/8);
// /8 because the colorDepth is in bits

instead of:

SDL_BlitSurface(image, NULL, screen, NULL);

And this is the result:
http://img338.imageshack.us/my.php?image=dibujovf9.jpg

That’s supposed to be a 1280x800 screen capture by the way… I really
need to maximize my speed, REALLY, and that line is the one eating most
of my time…

Where did you hear memcpy would be faster?

SDL_BlitSurface is already highly optimised, taking advantage of
various special instructions available on different CPUs. If the SDL
developers found that memcpy could blit faster on a particular
platform, then that’s what they would use.

As for why you are getting a corrupted display, are both surfaces
software surfaces? If not you’ll need to lock hardware ones. Do they
both share the same BitsPerPixel and colour formats? You may find that
converting all surfaces to software can improve performance anyway,
depending on the types of surfaces (alpha blending in particular, and
any pixel manipulation are horribly slow on hardware surfaces).
Another potential time saver would be do blit the large image (which
Im assuming is a background) once, and only re-blit small portions of
it when a sprite moves across the screen. For a static background this
will really help.

Finally however, I will point you to Bob Pendleton’s excellent articles on SDL:
http://www.oreillynet.com/articles/author/1205

There’s some very good information about SDL and blitting in these,
they are well worth the read.

Cheers,
Brian.On 5/4/07, Manuel Garc?a Cabrera wrote:

I heard that with memcpy it should be faster, and it seems to be, but
the result is not good.

Manuel Garc?a Cabrera wrote:

I heard that with memcpy it should be faster
SDL already fallbacks to a memcpy internally when possible.

Stephane

Brian escribi?:

Where did you hear memcpy would be faster?

SDL_BlitSurface is already highly optimised, taking advantage of
various special instructions available on different CPUs. If the SDL
developers found that memcpy could blit faster on a particular
platform, then that’s what they would use.

As for why you are getting a corrupted display, are both surfaces
software surfaces? If not you’ll need to lock hardware ones. Do they
both share the same BitsPerPixel and colour formats? You may find that
converting all surfaces to software can improve performance anyway,
depending on the types of surfaces (alpha blending in particular, and
any pixel manipulation are horribly slow on hardware surfaces).
Another potential time saver would be do blit the large image (which
Im assuming is a background) once, and only re-blit small portions of
it when a sprite moves across the screen. For a static background this
will really help.

Finally however, I will point you to Bob Pendleton’s excellent articles on SDL:
http://www.oreillynet.com/articles/author/1205

There’s some very good information about SDL and blitting in these,
they are well worth the read.

Cheers,
Brian.

I heard that with memcpy it should be faster, and it seems to be, but
the result is not good.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Mmmm, I found out that the BlitSurface isn’t necesarily the one eating
my time… I’ll explain a little bit what I’m displaying: I have an
aplication that captures the screen, XORs with the previous screen
capture and compresses it before writing on a file. It does that as fast
as it can. Ok, when on the Player side, I open the file, read the data
from the file, uncompress it, XOR it and show it.

Ok, now I know that BlitSurface isn’t necesarily eating my time. The
pics I send through the file are 24bit bitmaps. If I do SDL_Init with my
current color depth (that would be 32 bits) the one eating the time is
indeed SDL_BlitSurface. However, if I do the SDL_Init with 24bits as
color depth, the BlitSurface is practically auotomatic (the memcpy works
here too), but the SDL_UpdateRect eats the time now… Even more that
the BlitSurface in the previous case…

Any ideas of what I could to do speed this up?> On 5/4/07, Manuel Garc?a Cabrera <@Manuel_Garcia_Cabrer> wrote:

Mmmm, I found out that the BlitSurface isn’t necesarily the one eating
my time… I’ll explain a little bit what I’m displaying: I have an
aplication that captures the screen, XORs with the previous screen
capture and compresses it before writing on a file. It does that as fast
as it can. Ok, when on the Player side, I open the file, read the data
from the file, uncompress it, XOR it and show it.

Ok, now I know that BlitSurface isn’t necesarily eating my time. The
pics I send through the file are 24bit bitmaps. If I do SDL_Init with my
current color depth (that would be 32 bits) the one eating the time is
indeed SDL_BlitSurface. However, if I do the SDL_Init with 24bits as
color depth, the BlitSurface is practically auotomatic (the memcpy works
here too), but the SDL_UpdateRect eats the time now… Even more that
the BlitSurface in the previous case…

Any ideas of what I could to do speed this up?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I meant SetVideoMode, not Init.

Manuel Garc?a Cabrera ha scritto:

Any ideas of what I could to do speed this up?

are you using SDL_DisplayFormat on every SDL_Surface
you are using ?–
SkunkGuru

SkunkGuru escribi?:

Manuel Garc?a Cabrera ha scritto:

Any ideas of what I could to do speed this up?

are you using SDL_DisplayFormat on every SDL_Surface
you are using ?

When I use that, it takes a bit longer so, no, I’m not.

Manuel Garc?a Cabrera escribi?:

SkunkGuru escribi?:

Manuel Garc?a Cabrera ha scritto:

Any ideas of what I could to do speed this up?

are you using SDL_DisplayFormat on every SDL_Surface
you are using ?

When I use that, it takes a bit longer so, no, I’m not.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I do this:

-SDL_CreatRGBSurfaceFrom (from the pixel data of a bitmap. With this I
get a 24bit SDL_Surface)
-SDL_BlitSurface (I blit the 24bit surface on the SDL_Surface I setted
the Video Mode on)
-SDL_UpdateRect
-SDL_FreeSurface

When I set the Video Mode to 32 bits colorDepth, the blit eats my time,
Update is automatic. When I set it to 24 bits, the blit is automatic but
Update eats my time…

If the bitmaps were 32bit bitmaps would both of them go faster?

If the bitmaps were 32bit bitmaps would both of them go faster?

Yes, that would help alot.

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment