Sprites vs Images

Hi, I recently came across Playdate and was immediately intrigued (just got one on the way) and would like to ask about the difference between using sprites vs images. I've come across info here on the forum that using images is faster than using sprites, but I don't want to believe it's that black and white, so I'd be interested to hear what the community has to say. Are you using sprites or images? Is there any recommendation when it's better to use images instead of sprites? I've read that if there are many moving objects in the game, it's better to use images, but I'd be interested in your real world experience. I'm also wondering if it's possible to use a combination of sprites and images without having to clear the screen (I assume that then the sprites have to be redrawn as well, and thus lose the advantage of only being redrawn when there is a change to them).

Thanks for the replies

Indeed, it's not that black and white.

In a nutshell:

images

  • perhaps more straight forward
  • drawing mostly managed by you
  • full screen redrawn every update
  • as much processing overhead as your code dictates

sprites

  • perhaps more complicated
  • drawing mostly managed by system
  • partial redraw every update (only dirty rows)
  • some processing overhead

You can use a sprite background (basically a big sprite the size of the screen that is drawn before other sprites) and draw to that to get a combination of images and sprites. This is what pretty much all sprite games will do. The benefit is that dirty rows are still tracked and partial redraw/refresh will still happen.

There's more to it, but the "best" approach will vary based on your game.

Both have a performance limit, but worry about that when you hit it.

2 Likes

Thanks, I've tried both variants and the images seem a bit more predictable to me. I also tried using the sprite background and managed to achieve a partial screen redraw with all the game objects being images, but then I had a problem there when I tried to stop rendering the background (changing it was no problem). But that's probably a skill issue, according to the documentation I suppose I could have used sprite.removeAll() and then call that setBackgroundDrawingCallback again as needed.

I think the easiest would be to have a flag to draw or not draw the background, and when you stop drawing it you might need to mark the whole screen as dirty one time.

Good luck with your game!

I choose images or sprites depending on the surviving concept I'm making.

I tried to do as you advise and managed to get it to work with partial redrawing of images and showing/hiding sprite backgrounds. Interestingly though, this change had a very positive, almost hard to believe effect on FPS, depending on how much is happening on the screen. When I use only images and gfx.clear(), the game stays at 50 FPS, but as soon as I switched to a combination of sprite background and images, the game reports 99 FPS. I'm only testing this in the simulator for now, since my Playdate will arrive in about 2 weeks, but I have the simulator set to throttle Lua's performance as well as limit the malloc pool to 16MB.

Thanks for the wishes, for now I'm just experimenting with minigames to get familiar with the SDK. I must say that so far I find it quite comfortable to work with.

Right! But be aware that's the Simulator.

Always try on hardware device to see real FPS.

But generally if your main loop isn't CPU bound, you'll be screen update bound, then here's a rough guide.

Dirty Rows @ FPS

  • 240 rows @ 50fps
  • 175 rows @ 60fps
  • 75 rows @ 200fps

Oh cool, but the guide applies only to the Simulator right?

No, guide figures apply only to hardware.

  • Daily Driver at 60fps
  • KOATARI the game I'm currently working on runs at 100fps

Use setRefreshRate(50) to limit on device. To go higher you would need to use setRefreshRate(0) and write your own limiter (which is what I did).

(Simulator will run at a gazillion FPS.)

I see, and do you use Lua or C? And did you choose sprites or images for the KOATARI game?

  • Lua
  • Sprites + Sprite Background

Just to restate that if you use images and/or are redrawing the full screen every update, then you can't do partial redraw, and so will be limited to 50fps.

Thanks, I understand. For now, I'm starting work on another minigame that will be based on sprites only, so I'll get the hang of it.

I would have a question about images and rotations though, specifically image:drawRotated(x, y, angle, [scale, [yscale]]). The documentation says that this function will draw an image centered on the x, y point. But I couldn't get it to rotate the image anywhere other than from the center. Is there any way to do this without having to manually move x and y to simulate rotation from a point other than the center? I tried using affine transform, that worked, but when I called the affineTransform:rotate, it appended the angle to the rotation instead of overwriting it.

I've not used that function. So, you're best to start a new topic with some small test code to reproduce the issue.

1 Like