[Game]PokSky WIP

Pokitto Programming Games
, ,
1

Learning some new stuff in C++

New bin with palette punch
sky.bin (61.8 KB)

11 Likes
2

Whoa this looks great so far! Love the explosions. Reminds me a bit of the one tic-80 game you were working on like a year ago the way the background moves.

Also, I think your fps counter might be inaccurate. On hardware it seems to run faster than it reads. Keep it up :smiley:

1 Like
3

Nice use of colour.
The explosions remind me of The Minish Cap.

(Would be nice to see the source too.)

1 Like
4

Beautiful!Cant wait to play it!

1 Like
5

Awesome game.

1 Like
6

Already a year, how the time flyā€¦

Do you have some code to share on how measure FPS? Here mine in the update loop

    Pokitto::Core g;
    Pokitto::Display d;
    //
    d.setCursor(0,0);
    d.print("FPS:");
    d.print(1000/(g.getTime()-t));
    t = g.getTime();

Iā€™ll merge with latest Pokitto library and share as soon as it will be somehow stable. Itā€™s mostly an experiment with basic c++ features, so nothing to learn from it.

Thanks both @Matej and @pjurkovi for the kindly words. I hope to add some basic game play to make it more enjoyable.

1 Like
7

For FPS, itā€™s best to simply increment a counter 1 per frame, and when 1 second has passed, copy this counter to your display variable then reset the counter to 0.

e.g.

currentFrameCount++;
if (g.getTime() - t > 1000)
{
  t = g.getTime();
  lastSecondFrameCount = currentFrameCount;
  currentFrameCount = 0;
}
d.print("FPS: ");
d.print(lastFPSCount);

Also, this code could be adapted to stabilize time by skipping drawing.

1 Like
8

@HomineLudens and @carbonacat

There doesnā€™t seem to be a universal way of calculating FPS.
Thereā€™s a whole page full of methods here on SO:

Seems people do like to use some kind of weighted average algorithm though.

I think ideally youā€™d want to be caching the times to an array (or better yet, a circular buffer/fixed-size queue) and then summing them up until youā€™ve got ~1 secondā€™s worth (Iā€™d say take whichever is closest to a second, even if that means using less data) and then dividing that.

I donā€™t know if any of the ā€˜weighted averageā€™ stuff helps or not, Iā€™m not a particularly good mathematician (though I try).

9

Iā€™ve just been defining ā€œPROJ_USE_FPS_COUNTERā€ and using that. Seems very accurate but takes some proformance hit.

1 Like
10 
currentFrameCount++;
if (g.getTime() - t > 1000)
{
  t = g.getTime();
  lastFPSCount= currentFrameCount; //<< small typo
  currentFrameCount = 0;
}
d.print("FPS: ");
d.print(lastFPSCount);

Give me more or less same result on hardware (more smoothed obviously)

11

How big perf hit you have noticed? That should be quite fast to draw.

12

I canā€™t find that directive. Has it just been added recently?

Found it:

13

Actually,that is a bit old too. In the latest Github it is like this:

// FPS counter
		#ifdef PROJ_USE_FPS_COUNTER
        const uint32_t fpsInterval_ms = 1000*3;

        fps_frameCount++;
        if (now > fps_refreshtime) {
            fps_counter = (1000*fps_frameCount) / (now - fps_refreshtime + fpsInterval_ms);
            fps_refreshtime = now + fpsInterval_ms;
            fps_frameCount = 0;
        }
        #endif

It is also automatically drawn directly on the screen (in Display::update()), not to the console window any more, so it works on hw too.

1 Like
14

Iā€™ve just point to GitHub repo here https://github.com/pokitto/PokittoSim
in Master branch.
Is there any other repo?

15

That is the old one and should not be used any more. Here is the official repo. It is for both the simulator and the HW builds. Or you can use mBed env for the HW builds also.

3 Likes
16

Iā€™ve just update the bin with a modified palette. Now is more similar to my monitor output. I was enough to add some more brightness and contrast to the original palette. I modify on the fly img2pok to allow some tests.
The result is way better then before and more similar to initial gif posted

sky.bin (61.8 KB)

Does anybody study the best way to match monitor and lcd colors? @jonne ?

17

No. Only thing Iā€™ve noticed you need much stronger colors on the lcd. For example, if you have a medium grey and medium brown they are hard to distinguish.

In the old days TV / CRT monitor games were often a sort of ā€œcolor rampā€ of greys, blues or similar + a few contrast colors (strong violets, pink, yellow). Think Xenon Megablast and Amiga Bitmap Brothers games.

Same ramp + opposite color high visibility details strategy works well on the lcd.

1 Like
18

I havenā€™t, but if I had to guess Iā€™d assume that the answer lies in gamma correction, or some variance of gamma correction.

The explanation here is quite decent.
https://www.cambridgeincolour.com/tutorials/gamma-correction.htm

1 Like