I have been working on a puzzle game and have implemented y-sorting for the rendering of tiles and entities. I have got it working, but I have no idea how it performs on real hardware as I don’t have a playdate yet. If someone could test it out and report the fps, it would be much appreciated.
How to play:
You move around with the d-pad. Throw bombs with A (if you are carrying any, you can also only throw within a radius of 3 tiles). Move where you will throw your bomb by holding down B and using the d-pad. For each step you take the bomb explosion radius will increase, after 4 steps it will explode by itself. Game.pdx.zip (260.8 KB)
Thanks for testing it out! Good to see that it played well.
If you could test out this build as well, it would be really appreciated! I changed the level to a worst-case scenario for the y-sorting. Game.pdx.zip (259.1 KB)
As for the graphics, I wanted the hole map to be always visible that’s the reason for the small size, but I will probably add a camera and double the sprite sizes.
From hitting A in the Launcher, it takes 8 seconds for the game to appear. After that it's idling at around 82 fps. When I move to the right and the stalactites (?) fall, the frame rate drops to 25 fps, then hovers at 72 when the animation is finished. Then when the player moves down it falls to 16, and back up to 56 when the animation finishes. After that it takes around 7 seconds for the level to reload.
Sorry for bothering you so much, but I have one more build I would like for you to test. In this one I redraw the hole column and don’t check for only relevant tiles/entities. I want to see if this works better. Game.pdx.zip (259.1 KB)
Thanks so much! These trace files are really helping.
I have made a new build that uses the first builds tile pruning, but with more optimizations. It should also have the startup time from the second build.
If you aren’t bothered, I would really appreciate it if you could test this one as well. It really helps having it tested on a real device. Game.pdx.zip (260.2 KB)
I have been trying to fix the sprite size problem. I find it important to be able to see the whole level at once (that’s why the size was what it was). I don’t want the puzzles to be hard because you can’t see the whole level.
Therefore I have implemented a camera with the ability to zoom in and out (with the crank), but I’m afraid it won’t perform well on the playdate, as the areas to redraw are bigger and the whole map needs redrawing when zooming/camera position change. I have 2 levels, by completing one it will go to the next. If someone could check it out on both levels it would be much appreciated.
Double press b to move the cursor to the player Game.pdx.zip (297.5 KB)
The framerate seems to be unlocked, which makes fps readout harder to keep track of. Zooming in and out while standing still doesn't seem to affect performance much. The framerate drops for a very short time before returning to 99 fps. This is not actually noticeable in the game though.
During the first level when you are moving and the rocks are falling, the framerate drops to around the mid-30s. I never saw it drop below 30. Being zoomed in or out during this sequence doesn't seem to make much difference, it's still mid-30s (maybe slightly lower while zoomed out). If you zoom out while the rock falling sequence is happening, there does seem to be a short stutter while the zoom is changing.
The framerate in the second level seems better while moving. It drops to 50-ish fps when moving, but quickly recovers to 99. It drops slightly more when the rocks are falling at the end, to 40-ish.
There is a bug with the cursor when moving from a box to a square outside of the level, like a wall. The box cursor offset will not reset which causes artifacts to appear when the cursor is drawn outside of the level.
