Faster DisplayTranslucideSprite?

THCM · Post by **THCM** » Thu Jan 12, 2006 6:13 pm

Hi!

Any Idea how to speed up this command? I can't use StartSpecialFX() because of a very large maximum Screensize and I'm drawing all my objects on one big sprite which will be blitted to the screen when it's filled. If found out, that it's faster to load the sprite to the system memory using #PB_Sprite_Memory, but it's slower for all normal sprite commands. I only need to draw 1 sprite with 60x60 pixels in 32bit and the framrate drops from 60 to 30 fps. Perhaps some fast mmx assembly could help?

@Fred: How fast are you're handmade drawing routines?

Thx!

Post by **Fred** » Thu Jan 12, 2006 7:56 pm

You should really consider sprite3d() for this. The routine is fast, but the bottleneck is the videomem->systemmem and systemmem->videomem access. May be some MMX will help, but it's not obvious.

THCM · Post by **THCM** » Thu Jan 12, 2006 11:35 pm

Thx for the fast reply. Is it possible to display sprite3d sprites onto another sprite?

What I don't understand is, that my game runs at about 450 fps. When I display only 1 60x60 DisplayTranslucideSprite() from the main memory the framerate drops to 240 fps and when I display 2 60x60 sprites (1 from main memory and 1 from video memory) my frame rate drops to 55 fps. How is that possible? The data rate to blit 1 sprite 60 times a second is less than 1 MB! per second. Even in the old days of pmode vesa coding I could blit far more than 80 mb/s to the graphics card. Reading from the graphics card was awfully slow.

Isn't there another way except sprite3d (Linux doesn't support)a way to speed things up? I only need to fade out an animated sprite.

Post by **Fred** » Fri Jan 13, 2006 1:31 am

The problem is than translucidesprite() read the background and then calculate the new pixel value according the current intensity (it mix the source pixels with the destination pixel). That means 1 video read and 1 video write, which isn't fast. May be you can grab a sprite corresponding the background of the translucidesprite() (with the #Memory flag) and then UseBuffer() on this sprite and blit it. I don't have tested it, may be it will work faster.

THCM · Post by **THCM** » Fri Jan 13, 2006 9:29 am

Thx! I'll give it a try!

And here I go with a Feature-Request: DisplayIntensitySprite(#Sprite, x , y, Intensity)
This should be a simple version of DisplayTranslucideSprite. Black 0,0,0 should be transparent, but sprite will not be mixed with the background and so it won't need a slow read to the graphicsmemory. It is not only useful for my game, but also to all simple fade-in or out stuff even screenfades should be possible. The good thing is, that's not to hard to implement for you Fred. Just a little bit of cut&paste

I'll post this also to the feature request forum and I'll keep my fingers crossed.

THCM · Post by **THCM** » Fri Jan 13, 2006 2:08 pm

@Fred: With the help of your tip I found the fastest possible way with a very small, but still noticeable, performance hit. This is what I do at the moment:

1. Create a dummy sprite (60x60) in the main memory
2. Clear it
3. Use DisplayTranslucideSprite with a sprite also from main memory on my dummy sprite
4. Use DisplaySprite to write it to the videomemory

It's nearly the same procedure as your StartSpecialFX, but since I don't care aboute the background I don't need to copy the videomemory to the main memory and I have a much smaller area to copy.

Thx for the help and keep going!

blueznl · Post by **blueznl** » Wed Jan 25, 2006 9:30 am

i'm working on a little thingy and in the end decided to do nothing with sprite3d as i was relying on certain non-3d sprite effects, yes, it caused some slowdown when tested on a p3-733 but still acceptable

tried it on some other hardware, and it turns out it can make quite a difference: (the speed of) copying to and from video memory is very system depending...

THCM · Post by **THCM** » Wed Jan 25, 2006 9:47 am

Yes, you're right, but I couldn't believe, that there is such a large performance drop. My system spec: Amd Athlon X2 4400+ @ 2,7 GHz. Ati Radeon X1800XT, Asus A8N32SLI-Deluxe, 2 GB. I also thougt, that PCIe 16x (should be capable of receiving and sending data at the same time) would be much faster than AGP8x, but now I think there is no noticeable difference. It reminds of the old days, where you had to enable WriteCombining on your own to get faster access to the videomemory. It would be cool if Fred would polish the normal Spritefunctions a little bit.

The StartSpecialFX command is of no use nowadays. The common resolution of 1280x1024x32 is far too much to handle. I think it would be smarter for DisplayTranslucideSprite, if Fred would only copy the area to be altered to the system mem. Do the sprite operations and then use a normal DisplaySprite to the videomemory, which is much faster. I also miss a few simple spritemanipulations like mirror, resize, stretch, brightness adjust etc. or copy a sprite onto an image.

SFSxOI · Post by **SFSxOI** » Fri Feb 03, 2006 2:25 am

@THCM

I find your comment "I also thougt, that PCIe 16x (should be capable of receiving and sending data at the same time) would be much faster than AGP8x" interesting because i've come to the same conclusion.

I have two machines set up right now, one with an AGP 8x and the other with PCIe. Unless the software was specifically designed for PCIe (like the demos from the card manufacturer to showcase a cards attributes) I dont realize any difference between the two.

THCM · Post by **THCM** » Fri Feb 03, 2006 9:17 am

Yep, I think the mainproblem is pushing and popping one long using the cpu at a time.

Dr. Dri · Post by **Dr. Dri** » Fri Feb 03, 2006 10:47 am

THCM wrote:Thx for the fast reply. Is it possible to display sprite3d sprites onto another sprite?

@Fred, you didn't answer
i also asked the same here:
viewtopic.php?t=19020

Dri