Hi there!
Is there a common solution in SDL to do a fast scrolling of a large
picture?
Well… SDL_BlitSurface() 
For instance:
I have a screen of 640480. My background have a picture of this height
and width. And on this scren are moving sprites.
If I have a picture of 1280480, how can I simply and very fast make it
scroll on screen? I think in all case I will always need to do a
BlitSurface on the whole screen no? And this is slow…
Well, it is slow on targets that don’t support system RAM -> VRAM DMA
blits, and there’s nothing much to do about that, short of fixing the
drivers…
However, there are a few things to keep in mind:
* Make sure that all graphics is in the screen pixel format.
(Use SDL_DisplayFormat().)
* DO NOT read from video RAM! Writing to VRAM with the CPU is
slow, but reading is *ridiculously* slow - even on the
fastest AGP cards. (Not that this applies to real VRAM - not
the the screen buffer, if it's a software surface.)
* Note that alpha blending is a read-modify-write operation.
(And see previous point.)
* AFAIK, it's possible on many targets to keep all surfaces in
VRAM, and then blit using VRAM->VRAM DMA. However, 2D APIs
(and thus SDL) rarely support anything beyond colorkey blits,
so it won't work with alpha blending.
* Use RLE encoding (SDL_RLEACCEL) for alpha blended and
colorkeyed graphics! It speeds up software blitting a great
deal.
I was trying to find an idea by moving the “pixels” property of some
surface but I didn’t succeed to find a good solution…
You’re not likely to get it any faster than SDL’s blitting code, even if
you code it in SIMD (MMX, KNI, AltiVec,…) asm code. The problem is not
the blitting itself, but on-the-fly pixel format conversion (fixable) and
slow CPU access to VRAM.
In general, the easiest and fastest way is to construct each frame
entirely in software, in a software surface, and then blit it into
display. This way, you reduce the impact of overdraw and
read-modify-write style operations (such as alpha blending), as all work
is done in the relatively fast system RAM.
One way to do it is to open the screen with the SDL_SWSURFACE flag, and
then use SDL_Flip() to do the blitting.
However, a better solution would be triple buffering with a software
"work" surface. SDL doesn’t inherently support this, but you can
implement it using (SDL_DOUBLEBUF | SDL_HWSURFACE), and a “work” surface
of your own. That is, you render everything into your own surface instead
of into the screen surface, and then flip by blitting the work surface
into the (VRAM) back buffer, and then SDL_Flip(), to switch the back and
display surfaces. This should give you the retrace synced flips (where
available) of ardware pageflipping, as well as the software rendering
performance of system RAM.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Sunday 23 September 2001 04:54, Ninj wrote:
But I have some questions relating to