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.

2D All the way! / many sprites slow down my game

Author
Message
Cybermind
Valued Member
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 5th Oct 2004 05:38
here is my source



and it gets very slow when I have a lot of tiles (sprites), I think it is because I move them all at one time.
Pincho Paxton
22
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 5th Oct 2004 07:52
search for

copy bitmap

Cybermind
Valued Member
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 5th Oct 2004 23:17
are bitmaps faster?
Pincho Paxton
22
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 6th Oct 2004 03:07
Yeah, copying a bitmap is the correct way to scroll a tiled background. Or try a 3D plain.

100% Pure Dave
21
Years of Service
User Offline
Joined: 10th Mar 2004
Location: Perth, Australia
Posted: 13th Oct 2004 14:58
actually u should use paste image, i use the paste image command when building a 2d scene based on tiles and even with a 3 layered map with animated tiles it is extremely fast

Emperor Baal
21
Years of Service
User Offline
Joined: 1st Dec 2003
Location: The Netherlands - Oudenbosch
Posted: 14th Oct 2004 08:33
I noticed there's allmost no difference between paste image and sprite when using darkbasic professional. And believe me, moving a lot of sprites is what I'm doing right now, megaman redemption has a LOT of sprites moving on the map and I still get 600+ FPS.

Agent
20
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 18th Oct 2004 04:51 Edited at: 18th Oct 2004 04:54
Some people's concept of the words 'a lot' can change. To a new programmer, a lot of sprites might be eight or nine. To me, a coder working almost exclusively in 2D my whole career, we're talking about several hundred.

That many sprites does eat DBP alive, but with some clever programming and some efficient logic it can be done with respectable frame rate. My current project displays a minimum of 160 images every cycle and goes up to a maximum of about 400. I'm getting around 80 frames on a below average machine (1.4Ghz Athlon), and with all 400 images visible at the same time it drops to about 70.

Efficient code is the key. Do you really need to move every sprite EVERY cycle? Only touch the ones that have actually moved, and even then you can try working with only a few sprites per cycle. Having the sprites present slows it down a little, but performing actual operations on the sprites slows it down a lot. Ignore the ones you don't need to change on a per cycle basis and only work with the ones which actually require an update.

I will help you with optimised logic. I've had a brief glance over your source. First of all, it looks like you are trying to slap down several tens of thousands of sprites every single cycle. I can't see how it's possible to require that many - if you are using a tilebased map, and it looks like you are, you can't need more than a few hundred at a time, depending on your screen resolution. Why are you placing so many sprites in one hit?

That's the single biggest problem you have with your code.

As best I can tell, you're not even using a tiled background (although it looks like you're trying to - the code is wrong). From where I sit, it appears you are in fact drawing a pixellated background, in which you are setting each individual pixel on the screen every cycle. This is not on

What is the size (in pixels) of the tiles you are using to compose your map? Your screen res is 320x240, so take as an example a tilesize of 10x10. At this res, filling the entire screen with tiles will require 768 images. I expect there's little chance your tiles are so small; more likely they are 32x32 or 64x64, as per generally accepted standard. In this case, you need less than a hundred images to paint the screen.

My first question to you, then, is why are you drawing forty two thousand sprites every cycle (ie, when you hit an arrow key) ?

I'll help you if you tell me the significance of the number 42000, and what size your tiles are.
Emperor Baal
21
Years of Service
User Offline
Joined: 1st Dec 2003
Location: The Netherlands - Oudenbosch
Posted: 18th Oct 2004 09:35 Edited at: 18th Oct 2004 09:36
@Agent

If you were talking about me, you don't have to worry. I use a lot of sprites (60+ at the same time on one screen at least, normally 100 or so) and I use a lot of optimized routines.
I also utilize a time-based system. My game only updates certain "special effect" sprite layers when it's main loop took less than (1 second / 60fps = 16.66ms). Then it will draw a new one and re-sync it.
For collision I use a very heavy optimized routine that checks an array and decides what to do (wall / floor = normal, spike = dead)
For collision against enemies/items I use a list. The enemy sprites start at number 400. So I placed them all in groups of 20: 400-419, 420-439 and I check collision for the group that's the first in the list. When it's done it's placed at the end of the list. This means collision is calculated 20 times each second for 1 group.

Agent
20
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 19th Oct 2004 03:36
Emperor, I was actually talking to Cybermind - he used the term 'a lot' in his question

You use a similar method as I do - using a queue to perform a smaller chunk of operations per cycle, except my system reorders the queue every so often depending on what's on the screen at the time and what actually requires updating (ie, something that isn't moving at that time and is off screen is constantly moved backward in the queue and never reaches the top). Saves even more time
Pincho Paxton
22
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 19th Oct 2004 05:30
That's why I said.......

Copy Bitmap....


You can move 1000 sprites as a bitmap if it's a scroll routine, you get no slowdown. Plus the secret is, you only have to paste 4 of them. The 4 new ones that are about to scroll onto the screen.

Emperor Baal
21
Years of Service
User Offline
Joined: 1st Dec 2003
Location: The Netherlands - Oudenbosch
Posted: 20th Oct 2004 08:31 Edited at: 20th Oct 2004 08:31
Copy bitmap isn't exactly a fast command. When using a 1280x1024 bitmap it won't do any miracles.

And you'll have a wonderfull time animating background tiles/objects

Login to post a reply

Server time is: 2025-05-16 20:30:15
Your offset time is: 2025-05-16 20:30:15