Extensible Loader


It depends on what you’re doing.

The 3DS menu relies on icons for 90% of things:

(The big “System Settings” is actually a billboard sprite in a 3D render.)

To solve the issue of not having an icon, you could programmatically generate one from the file name somehow.

But obviously if you wanted an in-depth file navigator then no, icons wouldn’t be enough.

That’s a fair point.
It depends how much text is needed.

I think rather than a single standard palette there should be at least some flexibility.

If we go for a 4-colour palette, have two of the colours fixed as black and white and have the other 2 colours be selectable.

If we got for a 16-colour palette, standardise roughly what the colours should be, but not the exact shade.

The main reason for this is because I think we should be able to customise the palette to have different ‘desktop themes’ for the loader. :P

For example, if we went down the 16-colour route, we could say the 16 colours are the EGA colours as standard, but people could customise them as they pleased.
You could easily map the EGA colours to pico-8 or the 16 minecraft colours and have everything still look nice, or even to 16 tones of grey if you really wanted to.

Or again, back to the suggestion of 4 colours fixed and 12 colours variable.

(Note: colours not adjusted to RGB565 format.)


I think the problem is partly that we should decide if the new loader is a file manager or a launcher application. It cannot be both, if we want it to be usable. Like in Android, there is a separate file manager app. We can demand that pop-programs must have an icon. Python and GBemu are harder as game files / scripts cannot embed icons, but that can be solved also.

There could also be a separate window for bare binaries, with no icons. That would be presented as a list of filenames.

In the pop window, I think we also need to reserve a row at the bottom of the screen for a text. There would be the name of the currently selected game. If thinking about the 4x3 grid above, the icons could be smaller, or there can be a 4x2 grid of icons, to leave room for text at the bottom.

One idea still. There could be e.g. default GB icons visible in the same grid, but each has two or three first letters of the name layered over the icon. That would help to identify the game until it gets the focus and the name is visible in the bottom row.

Edit: the horizontal text area in the bottom of the screen could be in the hi-res, 2-bit mode, to make the text more readable. The icon grid is in the lo-res 4-bit mode.


Sounds good to me


One thing I thought would be cool is if we could some how incorporate a logo for the language each game is written in.

Whether it was on the game sprite or next to the file in the browser.

PythonIcon CppIcon

Just an idea.
(I’m better at logos than actual art it seems :P).


And if greyscale isn’t your thing, here they are using PICO-8, EGA, Minecraft and EGA (alternate blue) respectively:

PythonIconColour CppIconColour

Honestly, I think I’m warming towards EGA more with that extra blue.

(Either that or we take the best colours from EGA and PICO-8 and create a new palette… or I just swap the lightest blue and the medium blue… the colour that doesn’t match in any of the palettes could be transparent I guess.)

I’m not entirely convinced with that.
Most desktop operating systems execute programs from the file manager.
I think part of the reason Android has them separate is because it’s targeted at non-technical people (i.e. there’s a lot of things you can’t do without ‘jailbreaking’ it).

Any idea what PSP & PSVita do for comparison?

Just stick a wrapper around them, or include some kind of ‘manifest’/‘configuration’ file?

I think that would be more effort and more memory hungry than just having a ‘no icon’ icon.
Especially if we can find a way to do procedurally generated icons in roughly the same space/time it takes to load an icon.

I concur.


For the main menu (the “desktop”) I’m alright with 100% icons.

I like the procedural icons idea for other things. I’ll look into it.

The “built-in” palette can be modified easily… but the games’ icons will be made with a certain palette in mind, so some standard is necessary.

Sounds good to me ²

I find the Pico-8 palette too saturated and would much prefer something closer to the Commodore 64’s. Being able to switch from one to the other would be great.

Does this make sense if there are separate file browsers for pop, gameboy and python games?
Rationale being that different file types might best be displayed differently.

I’m definitely not trying to make a file manager. I just want to navigate to a file and open it.

The latest game disk has 100 games. Finding a specific game in a list that long takes a while.
On android you can group apps on the desktop. Android also has a search feature, which I don’t think would work well in our case.

I’m not worried about making groups and moving games from one place to the other. That can be done on a PC well enough.

I also don’t want to impose any specific structure. One user might like to have their games separated by author, another might like to have “favorites”, “new”, “wip”, “demos”, etc.

Separating pops and bins into different windows is a possible solution.


Maybe there’s a way of interpreting the file name as a Lindenmeyer System and using that to generate an image somehow?

Again, just throwing an idea out there.

There’s also an Identicon.js, you’ll probably make more sense of that than I will:

Like I say, we could designate certain colours and allow themes to vary the tone/shade/saturation.

Really there’s so many possibilities that I think we might just have to trial a handful of things and poll to see what people like.

I think the fundamental decision to make that will guide everything else is:
Should multiple icons be shown in full colour, or should only the selected item be coloured and the other icons greyed out somehow?

If we do the latter, there’s more flexibility (e.g. we can do the 4-fixed, 12-variable thing, or 8-fixed or 8-variable).

One possibility with the former is 4 colours per palette, have one fixed palette and 3 variable palettes so you can have up to 3 icons on-screen at once.

The commodore 64 looks a bit drained of colour to me, and a bit heavy on the browns.

Does there necessarily need to be separate browsers?
I would have thought it would be possible for ‘pop’, ‘bin’ and ‘python’ to each have a function for displaying info about the file and for loading the file.

So as long as you don’t handle too many different types at once, you might be able to fit them all in memory.
But it depends how much memory is available I guess.

Otherwise I guess they could be incorporated into the file browser icons or something.


Just take the file hash and use it as a random seed and you can interpret it in any way you want. But maybe the procedural icon could hint some useful info, such as file size or something?

Nice idea with the identicons BTW.


I’ve implemented L-Systems before… it would be a fun project in itself, maybe for a future release.

@drummyfish also posted a link to an interesting generator, but python is gibberish to me. :stuck_out_tongue:

Maybe something like this would be more appropriate for a gaming device?

I agree, but themes will probably not want to deviate too far from the standard palette or things will look weird.

The 4-fixed 12-variable palette would be incompatible with themes (unless a lot more code is involved), so the choice could be reworded as: should the colors of an icon be determined by the user (the theme he chose) or by the games’ creators?

Normally, in other contexts, icons are controlled entirely by their creators.
But being able to customise colors is one of the things that sets the Pokitto apart, so giving more control to the user makes sense. Icons would then be made with a common palette (pico8 seems to be the more popular one) and the theme would let the user adjust hue and saturation to taste.

Nope. It’s just the way I was implementing it, but that can still be changed.


There’s really a million plus one algorithms for generating nice images from a random number, just google procedural generation.

I like this! How about images of Pokitto in various colours, face expressions, hats and so on?

EDIT: mockup:



I concur with this. I like to see the Ui in full (4-bit) glory.


Little Pokittos look fantastic!


One, quite weird, idea still: Have a special screen mode so that:

  • in the grid of 4x3, the icons are lo-res, 4-bit
  • the three 8-pixel high horizontal stripes are hi-res, 1-bit. For program names.

Best of both worlds(?). We get 16-color icons, hi-res text, and still low memory usage.


I also would rather not have this as a feature of the loader. It could be made as a stand-alone application for Pokitto if someone wants it as a feature.

I like it, the ‘Pepto’ C64 palette is closes to the actual hardware, yes, the C64 palette is a bit muddy, but it does have decent greys, in a pinch any small image would look fine.

Very nice idea. it gets my vote!

It works fine for my qbert clone, I think the effect works really well. Most people might not even notice that something fishy is going on either. I assume the text lines would be movable in whatever theme method is agreed upon?


Horizontal movement is trivial. Vertical movement needs to be supported by the screen mode, but is not hard to do either.


@jonne: what do we do about version numbers?

Can we use the high-byte to identify the loader and the lower 3 bytes for version numbers? The official loader is 0x00000005 and mine would be 0x01000001. The pokitto lib would allow updates regardless of the lower 3 bytes if the high byte is different, so it would be possible to switch from the official to custom loaders and back.

Or do you have something else in mind?


A file hash would be more expensive than using the file name.
More importantly the icon would change if the binary was updated, so I’m not sure that’s desirable.

Was it RoboHash? I considered posting that but avoided doing so because of its pythonness (and because I couldn’t tell if it was using other images as a base).

I also found one involving foxes but couldn’t find the source code for it.

If you do want to look at python code, maybe @Hanski could help?

Unless either the 4 ‘fixed colours’ were actually theme colours,
or there were 4 fixed, 4 theme and 8 variable or something.

I’m not a fan of the Pico 8 palette.
I’d prefer a fusion of the EGA/CGA pallete and the Minecraft pallete:

But really I don’t think we’ll be able to tell what’s best until we actually make some icons and do them in different paletes.

If it can be done, I would prefer this.

I don’t know what you mean by ‘closest to the hardware’.


Most c64 palettes out there were created by people looking at their TV, so they vary greatly depending on the colour setting of the TV. Pepto created his(?) Palette by looking at the actual hardware, as the C64 palette was not in any way software based, it was created with resistors and such. Link.

As for all of the theme and palette talk, would it really by so bad to have a fixed 16 colours? Wouldn’t bother me.


I’d use the hash of the file name as a seed, as the name itself wouldn’t be a valid L-System.

It was the opensource implementation of random-art.

Robohash appears to have sets of images that it mixes and layers using a PRNG. That technique could be good for a random Pokitto generator as it would allow artists to expand the set (or create new sets entirely) without having to touch the code.

We can have various techniques implemented as separate widgets and let the user decide which style he prefers. For the first release i’ll just do the simplest thing that comes to mind and let that serve as a template so others can experiment also.

Regardless of the technique, I’d use a hash of the filename and store the resulting image in a cache directory so the icons don’t have to be regenerated all the time.


Why not?

An integer is a sequence of bits, a string is a sequence of characters (represented as a sequence of bytes, which in turn are sequences of bits).

It depends on what rules you define.

(Not that hashing is a bad idea - it at least has the benefit of forcing strings of multiple length into a value of a fixed length.)

I understand most of the source code because I’m used to working with expression trees.
(In fact, last week I wrote a mini compiler.)

No idea what a ‘well’ or a ‘tent’ is supposed to be though.

The idea is to generate expression trees that describe an image.

I’m going to go out on a limb and say that might be a bit too memory hungry or complex.
Trees are rarely fun to implement in non-functional languages.

If the trees are binary trees then you can get away with doing a flat array trick to avoid needing excessive amounts of dynamic allocation,
but the logic still isn’t particularly fun to work with.

I had a feeling it would be something like that.

Hrm, I suppose so.

The simplest thing would be to just use a ‘no image available’ image.
The next simplest would be an image of the first letter of the file name, capitalised.

Sounds reasonable. Using plain old std::hash should be fine.


About time we made the poll:


drummyfish_c64pal pokitto_c64pal grid_c64pal


drummyfish_p8pal pokitto_p8pal grid_p8pal


drummyfish_pharapal pokitto_pharapal grid_pharapal

  • A
  • B
  • C

0 voters