Oh, so you were already assuming the surface was on video memory? Because I was thinking it was going from RAM to vRAM. hence much slower.
Oh, yes! The I/O bus is much slower than the 51.2 GB/s (well, on a
normal computer, there’s some crazy PCI Express v3.0 32x buses that
are extremely fast, but you then probably hit the limits of the main
memory bandwidth), so you don’t even think about the video card
memory bandwidth when doing main RAM to video RAM transfers. 
i dont know… after all each blit, on the lower level, is actually repeating memory copies for each pixel(assuming a 32 bit depth on a 32bit machine). so the fewer pixels the better.
True, but when telling the video card to do VRAM to VRAM blits, that
has to go through a command buffer that is generally not optimized for
high volumes, so there’s a cost to each command, and there’s a
breaking point where you’re better off just blitting the whole thing
(or at least, in some bigger chunks).
In principle you’re right, though, fewer pixels is better.
Also, you were mentioning RLE earlier, if I’m not mistaken, most video
cards nowadays use texture compression, which usually gets a similar
effect. That’s also one of the reasons why locking surfaces is
something you want to avoid, because on those modern cards, it will
not only wait for the GPU to be done with it, but also needs to
uncompress it somewhere (all wasted if you were going to overwrite it
completely!), then recompress it when you unlock the surface. That
“somewhere” is also often main memory, so it also goes over the I/O
bus twice! Another reason why the “old DOS ways” are quite wrong
nowadays.
actually it would have the same number of branches (if i understood correctly what you mean), when I do dirty rectangles i have to copy the BG, and then blit it on the previous position of the moving sprite. Then I blit the actual sprite at the new position. This last blit is already colorkeyed(otherwise I would blit only the sides that moved and exposed the BG, like I said previously), the idea is to do the same with the first blit.
The catch though is that its a little trickier, because i would have to use a ‘negative mask’ of the sprite… and the way im seeing with SDL, i would need an actual blit of the whole BG rect to a new surface, then paste the mask to it, and only then pass it to the video card… and though this can save data going to the card, it could be done in a direct blit if I could ‘modify’ the colorkey code of SDL, and use the ‘negative mask’ at the AND phase… SDL could have a blit with a mask parameter
What I mean by more branches is that for every pixel, you add a
“should I get it from surface A or surface B”. I was mistaken, though,
it’s no worse than a colorkeyed blit, with the added twist of the
colorkey not just saying “don’t blit this pixel”, but rather “get this
pixel from the background instead”. You don’t really need a separate
“negative mask”, the colorkey could be used for this purpose, no?
I’m not sure if that’s an operation commonly available on GPUs,
though, so while you could definitely do something like that in main
memory (using the CPU, so no acceleration, you’re on your own, but you
have full flexibility), I’m not sure you would do it easily with
everything in video memory.
But if everything is in video memory, I wouldn’t care. You could
reblit the entire background, then blit every sprite on every
frame, and you could still be close to 1000 frames per second on my
GeForce 8800 (ok, maybe just 500, still plenty).
I understand what you mean by the “two rectangles on each side”, you
were thinking of a moving sprite. With everything in video memory, I
think I’d just blit the background at the sprite old location, and
blit the sprite at its new location, and that’d be plenty fast (if you
don’t have many sprites, possibly in the 10000 fps range,
theoretically, but I’m sure something else would be the limiter, of
course!), without trying to optimize the details.
I don’t want to sound too much like Bill Gates, but 10000 frames per
seconds REALLY ought to be enough for everyone. ;-)On Sat, Jan 31, 2009 at 7:10 PM, Antonio Marcos wrote:
–
probably because I dont know whats this number crunching doing… but I dont get whats the point of DMA if the whole data have still to go through the gpu…
