Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / I'm getting really bad performance in my game (2D Sidescroller)

Author
Message
Marth Koopa
16
Years of Service
User Offline
Joined: 23rd Apr 2008
Location:
Posted: 9th Oct 2009 08:49
Is there a more performance-friendly method to move piles of sprites around? When I try and make a scrolling effect(like a Mega Man game), the game slows to a crawl when all of the sprites start moving. This shouldn't happen on a Phenom II X3 710 + Radeon HD 4670 DDR3 + 2gb DDR2 RAM... the graphics are on par with a NES game, and I'm pretty sure those specs are a trillion times more powerful than a NES

I'm trying to move 768(16x16, 3 sets) 32x32 images. Performance is fine when only the player sprite and his collision boxes are moving (constant 60FPS). Screen dimensions are 512x512, windowed mode.

Collision detection is only run on sprites near the player, that helped a little bit rather than running collision on all the sprites on the screen...

Any tips to get better performance? I'm all out of ideas
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 9th Oct 2009 16:33
use images instead of sprites for as many of the things as you can, if it doesnt need collision or some of the methods that sprites provide, make it an image, that will help alot. Pasting an image to the screen is cheaper than GDK sprites being rendered.

768 sprites is quite alot though to be moving all at once, perhaps you could split your movement of them and collision of them up into timed chunks, so you would only be updating them once every XX amount of game loops. you would need to experiment with the exact value though as it would be a balance to get the right performance.

Try using different image formats to make the sprites with, that is something that will also help, I would try DDS as my first choice(if you arent already lol)

Good luck, if you wanted to you could provide screenies or code samples of the sprite routines it might help give a better idea to people of what you are doing and how it could be improved.

If it ain't broke.... DONT FIX IT !!!
Marth Koopa
16
Years of Service
User Offline
Joined: 23rd Apr 2008
Location:
Posted: 10th Oct 2009 01:50
Switching form TGA to DDS seemed to have helped a little. Any specific mode I should use? (DXT1? DXT5?). I'll look into using images for non-colliding tiles.

I don't know what you mean by splitting up the movement... don't I need them all to move at the same time in the same loop so it looks right?

I also tried hiding sprites that are off screen, then showing them when they get back in view, but that didn't seem to do much.

Here's the function I use to move a "map" (each map is assigned to a cell on a sort of imaginary grid, example: map 0,0 is in the very bottom left corner and map 1,0 is to the right of that one, each map is 16x16 tiles, tiles are 32x32 pixels). Moving just 3 maps together is very sluggish, I would like to be able to do more than 3 without a FPS hit.



This code is used to call the move map code and makes a screen scrolling effect (sprite #1 is the player). It's a lot like 8-bit Mega Man games if you've ever played those. The pright and pleft values are used to check if the "camera" should stop moving in that direction.

Marth Koopa
16
Years of Service
User Offline
Joined: 23rd Apr 2008
Location:
Posted: 10th Oct 2009 08:00
Alright! Performance is excellent now after making all background and no-collision tiles images instead of sprites(took far more code overhauling than I thought it would )

Thank you sir.

Though now I'm still curious about the DDS texture format and which option is best for 2D games. Right now I'm using DXT1. What are the differences in the other modes, DXT2-5 and those other ones (ATI something).
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 10th Oct 2009 13:20
Using images instead of sprites is a good idea. Hiding sprites which are off the screen won't help at all, maybe it even increases the load because then you need to call "make visible" every loop for every visible sprite.

You can gain performance if you reduce the number of sprites by re-using them. You can modify the game engine to create only as many sprites as are needed to display the currently visible screen. Sprites which scroll off-screen will be "recycled" and used to display the visible images. I have recently written such a solution for the Dark GDK coding challenge and it was not that difficult to do. I've posted the code today in that thread if you are interested. It's not necessary though, if you have already overhauled the code to use images.

Login to post a reply

Server time is: 2024-10-01 14:29:13
Your offset time is: 2024-10-01 14:29:13