I have been busy working on my remake of Frogger, and have just received my adafruit PYGAMER. I was so excited at how easy it was to place the game on the device and was eager to play.
When the games starts, the player cannot move very well and keeps moving back and forth. To try and fix this problem, I have commented out various functions within the game to try pinpoint the performance degradation.
I suspected that the ‘on game update’ was the culprit, so I changed that to include a small interval. I also noticed that if I do not place any enemies on the screen, then the player moves fine.
In this version, while the enemies move, the player cannot move well. Instead of placing the enemies back to other side (when hitting a wall), I decided to leave the enemies at the wall. You will notice, that after the enemies no longer move, the player can move again fine.
I am guessing that are a number of issues that might be causing it:
- maybe the way I am looping through arrays
- there are too many sprites
- the player moves each time by following another sprite (hidden due to its z index), and then in each game update I check if it has stopped in order to place it correctly on the screen and to allow the player to move again.
The game works fine within the browser (with every function switched on), and the enemies move fine within the PYGAMER. I have a feeling that how the player moves towards the other sprite is a costly operation and causing the adafruit to slow down (frogging.follow(nextPlayerPosition, froggingSpeed))
Does anyone have an adafruit PYGAMER to test this game?
I hope someone can give me good advice, as I want to finish off the rest with music, animations and scoring.
Just downloaded on my PyGamer, there are 94 sprites, and runs at 11 FPS. Although, the cars and logs don’t keep spawning.
You have made a great game sir.
So, here’s something I noticed:
These hardware devices are going to have a hard time keeping up with 90+ sprites.
You might want to handle the two “halves” of the playfield separately. Start each level with the cars. Once the frog reaches the river bank, remove the cars from the game and spawn the water creatures.
Just a thought to try to minimize the number of sprites that the device needs to track at any one time.
I deliberately stopped spawning the enemies to the other side just to test whether their movement affects the performance. Thank you for your compliment, hopefully I can fix a few things and polish it off with sound, animations and scoring.
I can definitely reduce the number of sprites. I use the colour coded tilemap to decorate the screen, and also add sprites for the waterfall and lava tiles. That way I can have some enemies go under or over and use it for collision detection. I can remove these and just place one at each side, then manually check whether the player has moved past the X position. I want the waterfall to appear over the logs but under the player (over would be also fine) but if having sprites will slow down the game I will just have to remove them. Is there maybe another way to achieve this look without sprites?
You have given me some good ideas which I will try. I realize now that I don’t need to check for collisions of cars when moving over water and vice versa. I didn’t notice the FPS and total sprites, is that always shown next to the controller?
In this version:
I removed the lava and waterfall sprites, and there is no collision detection. You can see in the video, that the movement is still weird; the player moves back and forth trying to follow the ‘nextPlayerPosition’ sprite.
@richard, @jwunderl @darzu
Can I ask for your expertise in finding out what is causing the weird movement? In the browser everything works fine, I guess as it has more processing power. However, on the adafruit PYGAMER, the movement is weird. I suspect that how the player moves towards the ‘nextPlayerPosition’ sprite is causing it. I guess I could use the grid extension and move, but then that doesn’t move with speed. I appreciate if anyone has any good ideas, as I would really like to fix this.
I changed the movement of the player from 100 to 50, and it works much better. The player moves slower but I think it gives the pyfruit more time to recalculate the changes in speed. 75 was almost ok, but the player kept swaying to and from the target position. Also changing the controller.onevent to ‘released’ instead of ‘pressed’ worked better as well. In the end I set the player to move towards a target spite of 60; and that is smooth and works for me.
I can understand what I am trying to achieve is unusual, and only moving 16 pixels at a time towards a target at a certain speed is difficult to calculate. I am really glad that people such as yourself are able to program this, as I would not have a clue. I don’t want to sound that I am too impatient. I am really happy with what you can do with this platform, it is fun and easy to program.