I'm working through some design decisions for a game, and at the risk of prematurely optimizing I've started to wonder if I should lean towards using primitives over sprites when applicable. For example—and this is purely hypothetical and I am not actually doing this —if I were to show a hollow square with 4 individual sides, each of which may or may not be drawn depending on the game state, would it be more performant to:
a) Create 4 sprites, one for each side of the square, then add() or remove() as required;
b) Draw 4 lines, one for each side, drawing or not drawing per update() as required;
c) Some other approach to sprites and/or primitives? (Resize a "hidden" sprite to 0x0? Draw it offscreen? Lines for single sides but polygons that look like lines when sides connect? etc etc)
I've read other threads that recommend avoiding hundreds of individual sprites, which makes sense, but I can't find any details on how "heavy" primitives are in comparison. I would assume that they're harder on the CPU but less RAM-intensive? Any details would be greatly appreciated.
I think generally drawing primitives is going to cost a bit more because it needs to do the math to calculate what pixels to draw, where as an image is simply copying pixels from the image.
However, say for example, you end up wanting to rotate your square for whatever reason, you'd be better off using primitives. Or pre-rendering the square at all angles.
This is why the recommendation is not to optimize too early - until you know the full scope of your game.
I'd recommend just testing whatever method is easiest to implement. If it runs fine, you can just stick with it until you discover you need to make more room in your CPU budget.
Playdate does all of its rendering in software. It maintains an off-screen frame buffer containing the pixels for the next image, and once your program says the image is done (and the frame scheduler says it's time to do so), it transfers that image onto the display. Performance, therefore, will revolve around how much computation is needed to produce that off-screen image.
In the square example, it will be less work to explicitly tell the computer which pixels need to be which color than to have it iterate over the pixels of a sprite and check which ones need to be modified. drawRect() would be optimal in this case. If the square is filled, and you're representing it with just one sprite, performance might be similar because it has to iterate over every pixel of the area in both cases.
whaaaaaaa? wow, I'll have to check that out. drawRect() is calling the same line drawing function as drawLine(), only four times instead of once. That's crazy if it's somehow faster
—if I were to show a hollow square with 4 individual sides, each of which may or may not be drawn depending on the game state, would it be more performant to: