400 sprites
Blitz3D Forums/Blitz3D Programming/400 sprites
| ||
| Well, I haven't been here in a while, but BlitzMonkeys seems down for the count, so. I ran into a little... Not necessarily problem, but CONCERN, in my game today. Long story short, there are ball-shaped enemies in this game which, at the moment, split into eight mini-versions of themselves when destroyed. Well, after destroying a tightly packed test group of 50, I of course had the resulting 400 mini-enemies... And my framerate proceeded to drop to about... Oh, 1 frame per five or so seconds. System specs are a 1GHz Atom, 2GB of RAM and 224MB video memory, if you're interested. Now, about these enemies. This game I'm making is rendered in 3D, but only uses 2D imagery, i.e. everything in it is flat geometry and sprites. So we're just talking 400 small sprites, not complex meshes or anything. Another thing to know is what the logic was for each of these mini-enemies. Basically, all they do is follow the player using AlignToVector(). I used a little MilliSecs() tracking and confirmed that the entire logic update for all 400 mini-enemies took no longer than 2ms. Yet another detail is that they all have collision statements. Basically, they're set for sphere-to-polygon collision with the level walls, and sphere-to-sphere collision with each other. I also noticed that the framerate didn't immediately drop to ungodly depths. It struggled at first, but actually dropped steadily over the next few seconds. Since the enemies were all created at once, I don't really see any reason that the framerate should go any lower than its initial speed, at the time of their creation. As another check, I took a MilliSecs() check on the core function. Basically, everything my 3D programs do gets packed into a single function which I call Core(). All logic, control, EVERYTHING, happens in the CORE, apart from UpdateWorld() and RenderWorld(). The entire time for the CORE updates was less than 10ms. Around 6~8ms, to be specific. So, what I'm asking is basically this. Is it too much to hope for Blitz to handle 400 multi-collision sprites? Is there perhaps some quirk or cumulative bug in the tweening code (I'm using the Mark Sibly blend from the "castle.bb" demo) that I don't know about? Or should I be looking for something else going wrong? |
| ||
| What video adapter do you have in the system? Atom CPU's are pretty slow in the first place (a 1.6GHz atom is slower than a 1.6GHz Celeron, albeit it uses much less electricity so they're popular in netbooks), but depending on the size and number of the sprites you're drawing the video acceleration (or lack thereoff) can also make a huge difference in rendering speed. Most netbooks have pretty crappy video hardware -- again, to safe battery life... You may want to create a small demo for people to download so you could see how many FPS it runs in other machines. It could very well be that yours is just underpowered for the job you want it to do... |
| ||
| Well, same results in my desktop, which is a 3GHz Athlon 5200+ x2, and a 256MB Radeon X1300 (yeah, not great, but not terrible. XD) Maybe I'll post something testable later and see what happens, if I can mod it enough to cut it down to brass tacks for benchmarking... XD The thing I'm most confused about is why the framerate dropped over time instead of just going down and staying there... |
| ||
| Is it the sprites or the collisions? If you can turn off the collisions try that and see how long each frame takes to render. If it is still slow then try changing the sprites to quad surfaces thingies (sorry, can't remember the proper term). You also may be using up texture memory if you are creating the sprites the wrong way (I don't remember which is which, but there are posts about it if you search.) If it IS collisions then you may want to try implementing a quadrant collision system - splitting the screen into smaller squares (large enough to hold one sprite) and then only collision check things that are in the sprite's current square and each adjacent square. (and perhaps more depending on if the sprite moved from one square to another) |
| ||
| ... quad surfaces thingies (sorry, can't remember the proper term). Yeah, quads is what I call 'em. I use them a lot, actually, so much so that I ended up just making a quick CreateQuad() function. XD You also may be using up texture memory if you are creating the sprites the wrong way (I don't remember which is which... I think that'd be using LoadSprite() for every one, which would create multiple instances of the same texture. Don't worry, I'm not; they're all made using CreateSprite(), then EntityTexture() is called during their update loop. If it IS collisions then you may want to try implementing a quadrant collision system... Yeah, I'll prolly just return to my old standby, EntityDistance(). The map collisions can be altered too if need be, since the map data is stored in an array. I'll see what comes up. So far no one's said anything about exceeding the practical limits of Blitz3D - like I did in my earliest draft of the game, wherein every tile of the 200x200 map was an individual sprite - so I'll sniff around in the code and see what else I can come up with. Gawd, y'know, I'm getting rather disheartened these days. I mean, 3D programming is great and fun, but... Most of the time now it seems like every time I add a single line of code, something else breaks. It's starting to become more complicated than it's worth. T_T |
| ||
I did 6,000,000 Googles: It ran like a slug super-glued to a road (with a nail belted through him - just to be sure he is secure) - but it looked great. |
| ||
| I did 6,000,000 Googles: Okay... Moving... On... >.> Well, problem identified. It is indeed being triggered by the collisions, but the actual cause of the problem is definitely the tweening code. If UpdateWorld() takes longer than the maximum time to maintain logic at 60FPS - so basically, 16ms max - it causes a cumulative slowdown, dragging the program down into the mud. I need a break right now; my head's spinning, especially with all the problems I've had to fix of late. However, I do at least know what the problem is, so a solution is on the horizon. Phew. Oh, final note, to xlsior: I don't usually like bragging, but hey, I love Evie (my netbook), so. XD I am pleased to report that, sans collisions, she can update over SIX hundred of said sprites with absolutely no problem, running at the silky smooth sixty. In fact, she often amazes me with just how much she CAN do, considering she is "just" a netbook. Someday soon I'm gonna see what kind of benchmarks Portal gets on her. :D |
   |