Which is super interesting! In theory, this little gadget could run a game with at least the scope of Chrono Trigger for the SNES, let alone a game like Symphony of the Night for the PS1. However, specs aren't everything, and I was curious where the performance bottlenecks and challenges may exist when creating games on Playdate.
Understandably, part of the appeal of the Playdate is its limitations! I'm asking this question to set expectations, become more familiar with the hardware, and know what challenges come down to coding efficiently, and what challenges are simply not possible.
For example, one challenge I'm aware of is the display. Being 1-bit and e-ink is an intentionally playful characteristic, and I've read that the display's refresh rate averages at 30fps, which is a solid clip. However, I'm curious if a game like Sonic the Hedgehog (fast scrolling, high-speed physics, blast processing) can run on Playdate, assuming my C coding chops can keep up? Or are the display's limitations going to come into play when working with fast-scrolling tiles and numerous sprites?
The screen doesn't really have strong limitation and can run at 50Hz. Technically the screen can go even higher than 50Hz for partial screen refresh.
It is however very difficult to compare the Playdate with the consoles you mentioned because the Playdate doesn't have special hardware to handle rendering. Consoles like the SNES, GBA or genesis are specialised to display tilemap and sprite on the hardware level, they technically do not have framebuffers. Consoles like the DS or PS1 have a frame buffer but with some GPU that can render polygons and sprite in the frame buffer in parallel to the CPU (The DS is even more complicated than that, but that's a different story).
On the Playdate all the rendering is done on the CPU. The SDK provides a sprite system that makes sure to render only part of the screen that will change and prevent overdraw. So even if the CPU is way more powerful than any of the consoles you mentioned, it has to handle much more, rendering, audio, etc.
The advantage is that you are not forced to use the sprite engine from the SDK and come up with your own rendering adapted to your specific game. Though it has to be said that this sprite system from the SDK is very well optimised and very versatile.
The general bottleneck is simply how much has to be rendered. So how much of the screen has to be redraw during each frame (you can see that in the Simulator with the option Highlight Screen Update) and how many sprites has to be tracked and how big they are.
I’ve been reading through the documentation and all of the posts in this forum. Lots of great insight and advice for optimizing, particularly via leaning harder into the sprite engine to alleviate the CPU (i.e. pre-rendering as much a possible, avoiding multiple complex computations, caching everywhere).
I’m tooling around with a JRPG, and I think I’ll have a lot of fun testing how many idle animations I can have running at once in battle sequences. Fun to look at older games and see what tricks they came up with for similar limitations.