How many objects would be reasonable for arduboy to push at 30FPS? I have a game that has roughly 100 moving/colliding on screen objects, and with low hanging optimizations, I can get about 20-30 objects moving around colliding with each other with a decent frame rate. Beyond that I feel like I drop to < 15
Is 100 unrealistic? I can redesign the game to be lower number but larger objects, but this feels like a cop out.
Is there a good example out there of large numbers of objects moving/colliding at a good frame rate? Maybe I can look at the code and get some ideas.
To put it in perspective - I’m making an arduboy version of Robotron.
At level 1, you are looking at 20 enemies, 1 player, and 4 bullets.
The most populated level has 104 enemies, 1 player and 4+ bullets.
I have an alpha done, so now it is optimizing and adding enemy AIs in. I have a solution to the lack of a “twin stick”, but we’ll have to see if people like it.
I’m not quiet ready to share code, (it’s a bit messy currently), but just looking for what others have done or if this is an achievable goal, or I should just redesign for a larger sprite and smaller number of enemies. (currently sprites are around 4x4-5x5 in size, but I might just go 8x8 and reduce the number of enemies - honestly, this might be too small but I don’t have my arduboy in yet so I can’t see what it looks like on the device. )
Some optimizations that are already in place:
- only check collisions on N enemies per frame with the player, not all enemies (dependent on movement speed)
- only check collision on bullets every M frames (dependent on movement speed)
- no trig functions - limited cos/sin lookup table used only.
- moving enemies towards the player just uses the ratio of the difference between player/enemy x_delta or y_delta multiplied by cos_table or sin_table. This is one of the few areas of floating point math (I’m trying to do it all in integer to keep it fast)
But honestly, it feels like just drawing 100 enemies is slow (drawPlusMask). I can turn off my collision code and it is still slow.
I get a HUGE FPS increase by not clearing the screen and doing some bitmap splatting (use drawErase to erase the current sprite then use drawPlusMask to draw it in the new location). This allows me to not have to redraw every enemy, just the ones that move. However, without access to a prior framebuffer, the drawErase function ends up blacking out pixels that should be considered “white” underneath (when there is overlap of enemies). Also the bullets become problematic since they are so fast and would potentially leave behind huge streaks. The bullets might just need more TLC - I think I’m trying to do too much without maintaining enough state (the bullets have a length, but it is determined by old pos -> new pos - I only track 1 set of x,y, so I’m doing math to try to figure out what the old pos was last frame (so 2 frames old)
When I see stuff like Catacombs running so fast, I gotta think, robotron should be possible…but I’ve also worked on this for about 8 hours…so I’m guessing there is a lot more I can do.