Need help testing on physical device


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. (260.8 KB)

Runs just fine! Dropbox - - Simplify your life

The only problem I ran into is the graphics are kind of hard to make out at that size.


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. (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.

Some numbers for you:

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.

1 Like

Thanks for the number, they help a lot.

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. (259.1 KB)

No difference that I can tell. Here's a sampler trace while it's doing the slower downward walk, maybe useful? (1.6 KB)

1 Like

Yeah, that was very useful, it looks like I sent the wrong build…
Sorry, I meant to send this one (259.7 KB)

Looks like setup time on this one is much better but then it's a bit slower during game play:

startup time: 2 seconds
beginning idle: 63 fps
moving right: 15 fps
top-right idle: 56 fps
moving down: 18 fps

Here's a sampler trace from the "moving right" step: (947 Bytes)

1 Like

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. (260.2 KB)

yep, this one looks like it's back to the performance of the first one, without the setup stall

startup: fast enough, didn't measure :slight_smile:
initial idle: 77 fps
move right: 29 fps
top-right idle: 66 fps
move down: 23 fps

Sample from the slower "move down" phase: (1.1 KB)

1 Like

Thank you so much for the help. As I have said this is a worst-case scenario, so this should hopefully be good enough for now.

1 Like

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
playdate-20221118-132457 (297.5 KB)

Hi, I’m still looking for some one that could test the latest build. Any help would be really appreciated

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.


1 Like

Thanks so much for testing! Glad to see that it’s working.

I had the fps unlocked as I wanted to see how much wiggle room I have with the fps, but I will probably lock it at 30 for the future.

Can’t believe I didn’t catch that bug, but it’s fixed now.