Need help testing on physical device

Hello

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.

playdate-20221113-201224

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)

Runs just fine! Dropbox - test.mov - Simplify your life

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

2 Likes

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.

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

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

trace.txt.zip (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
Game.pdx.zip (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:
trace.txt.zip (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.
Game.pdx.zip (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:
trace.txt.zip (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
Game.pdx.zip (297.5 KB)