Micro Platformer - Simple Platforming Engine in 100 Lines of Code

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).

2 Likes

We will get you to 30fps don’t worry

2 Likes

I have over 30 fps by using two layers of scrolling tiles (background and foreground) using the normal buffered 110x88x16 color mode. Thought, you need to be prepared to do some inner loop optimization to achieve that in the buffered mode.

1 Like

That sound good!
Please show the code now :grin:

1 Like

Here is a video of scrollling two layers.

30 fps, 110x88x16 colors, buffered mode.

5 Likes

Can you share the code, please :wink:

I assume this will be obvious once we see the code, but what is “buffered mode”?

1 Like

I am going to try some more optimizations and I will release the code after that. Btw. I am using a text and font bitmaps as a “tile map” in the foreground layer :wink:

A buffered mode (the other alternative is a direct screen mode) is how majority of the drawing on Pokitto is done. The bitmaps are drawn to the screen buffer first and then the whole buffer is copied to the LCD HW ( on Update()).

2 Likes

I see a Pokitto demo scene happening…

4 Likes

25 posts were split to a new topic: Improving FPS

I decided to split some of the conversation out into another thread because it had started to deviate too much from discussing/helping the platformer engine.

3 Likes