Question for the performance experts

Pancho
Unregistered
 
Post: #1
Hello everyone,

I am currently working on a game which uses a lot of high quality graphics and sounds and there is a lot of movement. Right now we are trying to increase performance to the maximum. It is a 2D game with a lot of sprites and someone suggested doing separate threads for each sprite or group of sprites so that the time they are being drawn is minimized. My question is: Is this feasible, and if so, where can I get information on how to do it ?

Thank you very much,

Franco
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #2
drawing each sprite in a seperate thread would be counter performance... It would yield way for more things to possibly interrupt drawing your sprites as fast as possible
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
If you want the fastest possible drawing, you should use OpenGL. I'd think that you should be able to pull 20-30FPS on a Rage128 using OpenGL for anything that's even remotely playable using 2D graphics calls on the same hardware.

If you don't want to do that, QuickDraw's CopyBits will be next best.

Multi-threading won't gain you anything here, I wouldn't think. You'll spend more time trying to make sure your threads aren't drawing to the same place at the same time, and figuring out when they're done so you can combine your results, and more memory on extra buffers... I'd pick this as a recipe for disaster, in fact.
Quote this message in a reply
henryj
Unregistered
 
Post: #4
Even if you could do this it wouldn't reduce the time it takes to draw the sprites, only the time you spend waiting for them to finish drawing and there are way easier ways to get around this.

Have you profiled your code? If not, go away and don't come back until you haveSmile

If you have, what does it say?
Quote this message in a reply
zzajin
Unregistered
 
Post: #5
There was some talk on slashdot about multithreading recently. I found links found on this page worth reading.


http://developers.slashdot.org/comments....id=4631553
Quote this message in a reply
Pancho
Unregistered
 
Post: #6
Quote:Originally posted by henryj
Even if you could do this it wouldn't reduce the time it takes to draw the sprites, only the time you spend waiting for them to finish drawing and there are way easier ways to get around this.



REALLY ? Please tell me.
After profiling the code I found that the bottlenecks are found 1) where it renders the next frame in the backbuffer and 2) where it copies the backbuffer onto the screen.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
So the first obvious thing to try is to render only the bits that have changed into the back buffer, and to blit only the bits of the back buffer that have changed to the screen.

Precisely how you choose to do this is up to you, but a search for "Dirty Rect Blitting" on Google might turn up some useful stuff.
Quote this message in a reply
Pancho
Unregistered
 
Post: #8
Quote:Originally posted by OneSadCookie
So the first obvious thing to try is to render only the bits that have changed into the back buffer, and to blit only the bits of the back buffer that have changed to the screen.

Precisely how you choose to do this is up to you, but a search for "Dirty Rect Blitting" on Google might turn up some useful stuff.


Thanks for the info but I am already using dirty rects. When I run the program with only one medium size sprite (a small skidoo ), it crosses the screen really fast with exactly the speed we would like to have for the game (we can always make it slower for fast machines but we cant make it faster for slower machines) but then I add 30 snowflakes falling and performance is reduced by 25%. I still need to add about 20 other sprites of different sizes. Then I have to add userinputs, game logic and sounds.

Open GL is out of the question because we need to make it work on OS 7.6. I am running out of ideas and the situation is starting to become hopeless.

Any help will be greatly appretiated.

Thanks,

Pancho
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #9
What sort of performance are you after, and what sort of screen size are you trying to blit to?

I'll also volunteer to take a look at your source (under NDA Wink) if you want to go that far.

Sounds like you're going to be seriously lucky to get even close to playable on the sort of machines that are still running 7.6, though!
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #10
I'm building a sprite engine myself and have tried most of the approaches mentioned. I've found that on my 500Mhz Powerbook G3 (8MB RageMob), 2D in Quartz is not feasible at any kind of decent frame rates. The absolute fastest I pulled with quartz was by drawing prescaled/clipped dirty rects to the window graphicscontext directly; with 30 32px by 32px by 32bpp sprites using the NSCompositeCopy op in a 640x480 window, I got barely 30fps with all the sprites moving.

OpenGL is really the only way to go for MacOSX. With my unoptimized openglview implementation I can easily do the same feat in an 800x600 window with 60 sprites with transparency running at 120fps.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
henryj
Unregistered
 
Post: #11
Go here and learn...

http://www.idevgames.com/forum/showthrea...eadid=1386

aleph0 knows what he's talking about.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Adding lots of static shapes in Chipmunk - performance question TomorrowPlusX 3 7,300 Jul 11, 2011 01:39 PM
Last Post: Skorche