[Game]Pokitto Grand Prix



I don’t understand the details either, never needed them. All you need to know is this rule:

When sampling a signal (picture, sound, video, …) your sampling frequency (resolution, FPS, …) needs to be at least twice as high as the highest frequency in the signal, otherwise artifacts (new frequencies, patterns that weren’t present in the original, that is aliasing) may occur.

Actually now I’m kinda confused about the detail of the resolution – from a pure signal point of view to correctly represent a 24x24 image I think you’d need to sample it as 48x48 (as the theorem says), but I think it only applies if you’re thinking in sin/cos representation of the image. With nearest neighbour sampling I think you can safely display 24x24 image as 24x24 pixels (as we usually do), nothing “bad” can happen (such as hitting the zeros in the video you linked). But displaying it e.g. as 16x16 you’ll now have to downscale the 24x24 to 12x12 (by averaging each 4 neighboring pixels into one – this effectively does the blurring, i.e. low-pass filtering) and sample that.

Too much signal theory now, I guess simply do a few experiments and pick what looks best :smiley:

Weeell I’d be careful about this, deciding which data to drop to keep the result nice can be more difficult than simple extrapolating.


An interesting point of view. I think both have pros and cons. Using T3 will probably make it very visible in the distance where one mipmap ends and the other begins. I will be experimenting both, lets see the results.

We might have. Lets see how it goes.


Yes, that is something I should try.


I didn’t even get that far. They lost me before the 2 mintue mark :P

‘4 neighbouring pixels’ being the Von Neumann neighbourhood?

Perhaps, but simple extrapolating rarely looks good.

To make upsampling look properly good, you usually need a complex algorithm that looks for shapes and patterns, which is usually harder than simply deciding which colours to mix.

I know there’s loads of different algorithms designed for emulators, but most of them I think don’t look very good.

I concur.

I think that for something that’s going to be out ‘in the distance’ retaining the overall shape is more important than retaining the details of the features.

It’s like looking at a distant tree, you can’t always see enough detail to see the shape of the leaves, but you know it’s a tree because of the overall shape of the tree itself.

I think when it comes to scaling that’s all you really can do.
You can theorise as much as you like, but theory is no good without experimenting and testing.


Just think about a sine wave with frequency f, if you sample it a the same frequency f, then all of your samples will have the same value and you will be unable to distinguish it from a constant signal


True, smallest sampling period in a picture (=highest frequency) is actually 2 pixels, not 1, so displaying 24x24 image as 24x24 actually means having twice as high sampling frequency (sampling period is 1). Makes sense now.


I think I suddenly realise the problem with this.

Sound waves are continuous, but bitmaps are discrete.

If you try to treat a bitmap as if it were continuous then you get sharp rises and falls.

Also it’s not just a 2-dimensional ‘wave’, it’s 3 2-dimensional ‘waves’ - one per colour channel.


The P-Zero WIP codes are now in GitHub:


But you can make a bitmap that is continuous. E.g. by blurring the bitmap.


You can, but then things get messy because there are lots of different interpolation methods and you run into the issue of how much blur there can be before the image becomes unrecognisable.

It’s probably less of an issue with photos than sprites.


I know it’s WIP but could you please not forget to add a LICENSE file, pretty please? :slight_smile: It’s always good to add one as soon as the code becomes public.

They’re both the same really, depends on how you think of them – on a computer you always have just discrete samples, with both sound and image, or even 3D data etc. Imagine the pixels not occupying square areas (as we’re used to visualize it when zooming in an image), but rather values at single, infinitely small points in 2D space – this way the image represented by the samples (pixels) can be viewed as completely continuous functions, just as sound. The only difference is that it’s a 2D signal, but everything that works with sound works with image too – equalization, band filtering, representing with only cos functions (probably better to look at tl;dr wiki first) etc.

(It’s extremely interesting to look at the principles and even the math of Fourier transform, first 1D and then 2D – e.g. here – it opens you a completely new way to look at data in terms of frequencies and spectra, and explains a lot of practically used methods such as JPEG compression, denoising, deblurring, sharpening, antialiasing, fast (reducing the big O complexity) filter application thanks to yet another theorems and so on.)


Sure. I blatantly copied LICENSE and README.md (edited) from @Pharap’s Minsweeper project.

@Pharap and @adekto please add the graphics license information to README.md in GitHub (I probably have to give you rights) or put the text here for me to add to GitHub.

The GitHub repository link is in the post above, the branch is “pzero2”, and the file is in “Examples/PzeroDemo\README.md”.

The graphics are in header files, so I have attached a zip of corresponding bmps to help recognizing your work :wink:
all_bmps.zip (66.9 KB)


This is convenient, you have separated the code and the art, so you can simply state that to all files starting with image_ a CC license (I think it was CC-BY-NC) applies, otherwise Apache.


I didn’t even know my Minesweeper was in the PokittoLib examples.
(As far as I’m aware it won’t compile because parts of the API are missing, which I hope to be fixing soon.)

In case you didn’t know, if you use the GitHub UI to add a file and try to name it LICENCE or LICENSE then a button appears offering to add a licence for you and it will take you to a menu where you can choose which licence you want to use.

For the record, although I use Apache 2.0 the most, I don’t have anything against using the MIT or BSD 3-clause licences.
(I’m not too keen on the GPL though.)
Other licences don’t tend to get used as often so I don’t know much about them.

I was going to upload the original .pngs anyway, into a Graphics subfolder, if that’s alright?

It was either CC BY-NC-SA or CC BY-SA:

(I don’t know why, but I’m happier about applying copyleft to art than I am to code.)

Just to check, @Hanski, do you have any preference?

Using CC BY-NC-SA would prevent the game from being sold unless the graphics were replaced,
using CC BY-SA would not stop someone from selling the game or the graphics.


No, I got them from the Minesweeper GitHub page.


Nothing special. Do as you will.


Well, it’s in there anyway.

In that case I’ll go CC BY-NC-SA.
It’s easier to relax permissions than it is to make them stricter.

If @adekto wishes to release his graphics under a separate licence then that can be accounted for.

@Hanski, I’ve got a PR ready with all my graphics and licence info:

(I’ve left adekto out because I don’t know what licence he wants his graphics under.)


just to state it, the graphics(test) i made for this are free to do whatever you want with them, as i consider it public domain, so can incorporate it witout isue

i see theres a game shown with raycasted buildings around, that looks awsome for something openworld


I’d say quite the opposite! In order to drop some restriction you have to find all the authors and get them all to agree, whereas applying a stricter license is something anyone can do alone. What you say may be true if there’s only a single author, but I wouldn’t want people to take this as a general statement. So please excuse this little note :slight_smile:


Making it stricter is harder because you can’t revoke permissions granted by CC licences.

You can always change the CC licence to a less restrictive version,
but once you’ve lifted a restriction you can’t put it back in place again, the licence doesn’t allow it.

So if you think you’re unsure about certain permissions, it’s always better to restrict them, becuase if you change your mind then you can always remove the restriction, but if you’ve already removed it and you change your mind then you can’t put the restriction back in place.


After some experimenting, I have noticed that there looks not to be a single trick which would remove Moire-effect and flickering in distance, at least not without real RGB color mode. Mipmapping itself do not reduce them. Like some people suggested, the best tricks were:

  • Use continuous color shades. Avoid sharp edges in textures that are used to cover large areas.
  • In mipmaps, decrease contrast and blur colors in distance
  • I also used mipmaps to dim colors in distance

Below are examples of reduced Moire/flicker gfx.

image image

The video is coming…