Micro Platformer - Simple Platforming Engine in 100 Lines of Code

Is that true? As I mentioned earlier: an empty hi-res app runs at 19fps with nothing on the screen. But maybe I’m missing something?

@Hanski’s “dirty-rectangle” trick is an old old trick and works. In dirty rectangle, only the “changed” part of the lcd is updated. Easily 40fps in your case.

sprites.bin (48.6 KB)

Also, I’d like to point out, that one of the things that is slowing the hires down significantly, is the indexing of the palette where each pixel value needs to me masked and bitshifted. @FManga already found a solution to that problem by unpacking the palette into unused RAM.

I think what @Hanski is suggesting is to bypass the regular hi-res screen drawing which has an image buffer and clears the screen at a regular interval and use a system where individual sprite objects are used instead of a screen buffer and the sprites are drawn directly when the screen needs to update.

I remember him demonstrating this trick but can’t remember which thread.

But @jonne’s mention of dirty rects is another reasonable solution since it avoids the expensive process of clearing the screen.
(Fun fact: the well-known version of ‘Solitaire’ packaged with older versions of Windows achieves the trick with the cards by not clearing the screenbuffer.)

Sprite system is explained here:

When the palette trick is implemented the FPS will be even more!

1 Like

Oh I see! So with this “sprites” technique, I would probably want to limit the game to single screens at a time (like Legend of Zelda) and avoid side-scrolling or anything like that (hopefully the tiled mode come together soon for that kind of thing).

Giving it a go now…

1 Like

Update 4:

Game is now running at 50FPS on Pokitto Hardware by using the “sprites” technique outlined here:

You can see a video of it running on hardware here:


Right. For scrolling, I would use 110x88 mode to have a good fps. But sprites do not work in that mode.

Looks great! Cannot wait for the actual graphics update :slight_smile:

But… Old 8-bits had one size fits all, there was no other way. You had a tiled screen mode with a fixed tile size, colour depth and even a fixed max number of tiles. The 8-bit era had many many wonderful games that found ways to get a round or enhance this limitation.

I don’t 100% like the idea of artificial limitations on a console (e.g. pico-8) but I think it might be worth considering in this case.

That was because of hardware limitations.
Old consoles handled tiles and sprites in-hardware,
often with processors acting like the precursor to GPUs (notably the PPU of the NES/SNES).

Things like changing z-order, multiple layers and the like are fine if you need them,
but if you don’t need them and you’d rather have the extra memory/processing,
then there should be a way to make that exchange.

Sensitive on Pokitto does also. :slight_smile:

1 Like

@Hanski: Is there any reason why Sprite mode only works in Hi Res mode? I’m finding the 4 color limit a little… limiting, so I am considering switching to Standard Res, but without Sprite Mode, performance is pretty bad.

Am I doing this right?..

    setTileProvider( []( int x, int y )->int{
        return myMap[ x+32*y ]; // tile id at row Y, column X.

It doesn’t seem to show the correct tiles…

The main reasoning for creating a sprite system was to provide more colors with good performance in standard Hi-Res mode, which have only 4 colors.

The 110x88 mode has much better performance because of 1/4 of the number of the pixels compared to HiRes mode, and also drawing functions are highly optimized. Even scrolling should be possible.

1 Like

Looks OK. Is the rest of the code online, somewhere?

Nope, but the only thing I changed from your example is the map and tiles.

Can you send it to me over a PM? I have no idea what’s wrong. :stuck_out_tongue:

That has not been my experience. Simply drawing enough 8*8 bitmaps to cover the screen (in standard def) drops the frame rate to <30fps (closer to 20).

Seems like I’ll need to look into some of these other rendering techniques (dirty rect, tiled, etc) or stick with sprite in Hi Res and just limit myself to 4 colors.

Clarification: I mean that Standard Def does not seem to have the performance required to render an 11x14 gride of 8x8 bitmaps at 30 fps. Hi Def is much worse if not using your Sprites technique (but significantly better if you do use that technique - 50fps in my test)

I am curious. Why do you want the frame rate to be much bigger than e.g. 25 fps in a game?

In general I think 30FPS is considered the minimum accepted refresh rate before quality starts to degrade. For me personally, a response of less than 16ms/60FPS feels sub-par (I’m the kind of person who would rather play at min spec to achieve 60fps, rather than have a better looking game running at 30).

Below 30fps, the game starts to feel unresponsive and choppy for most people (in my experience).