Extensible Loader


Very nice and easy customisation! I cannot wait to test the loader and add Python script support :wink:


The problem isn’t the burden of having to check,
the problem is what happens when you don’t and the pointer is null.

I learnt the word ‘segfault’ very early in my C++ career :P
(Not that ‘segfault’ applies to ARM, but it’s still nasal demon territory.)

Function pointers or std::function?

If it’s just function pointers, member functions won’t be an option, member function pointers are fundamentally different beasts.

(I’m assuming Widget::Widget is supposed to be a constructor?)

If I knew more about the innards of the existing file system I’d have a go myself.
Unfortunately there’s about 2-3 different file systems in use in PokittoLib so I have no clue which is capable of what.


Directory navigation, long file names, flashing: done.
Now to implement support for progress bars…


Function pointers, as I intend to call APIs from code that isn’t C++.
Member pointers can either be wrapped (void update(){ instance.update(); }) or declared static.


How did you manage to speed up the flashing so much?


The game I flashed in the video is small so it flashes quickly.
I haven’t done a speed comparison yet, so I don’t know how it compares to the original loader.



How can I offer you a beer or two?


Very good progress! Maybe we soon see game icons too… :slight_smile:


How about Pokitto games instead? I’m looking forward to that platformer you’re working on. :wink:

Icons are a chicken and egg problem: none of the games have icons because they weren’t needed yet. Now that I need them, there aren’t any.
I’m thinking that for the first release I could use a full screenshot instead, since that is easier to make.


What dimensions are they? I’ll put together icons for my games over the weekend…

[edit] How are these…
sensitive_icon pokittaire_icon pokittris_icon


I can make those work with these:

But, unless we settle on a common palette (pico-8?), we probably can’t do something like this:

I’m OK either way, but we have to decide which restriction we prefer: only one icon on screen at a time or a standard 16-color palette?


Some alternatives:

  • Use the palette of the selected image, but grey the other images out
    • Optional: have 2-4 colours fixed (e.g. black, white, two greys) and 12-14 colours settable per image
  • Use the palette of the selected image, and just let the other images use incorrect colours
  • A standard palette for small icons and a custom palette for enlarged icons
  • A standard 4-colour palette :P


I actually like the “4-colour palette” option as text would look much better in mode 1.

We could go for all of the above alternatives and the tool used to make pop files would generate all the necessary images.


I think a standard 16-color palette is just fine for icons. I would like to see mostly icons and pictures instead of texts in the UI. Besides, if 16 colors was enough for the mighty Commodore 64 that shall be enough for us too.:wink: Thought the Pico-8 palette might be better.


So would I. The problem is text is unavoidable because of directories and games that don’t have icons.


You could still have a default “No icon” icon. :wink:


Yes, but you can’t have icons instead of text.
Imagine something like this where a bunch of icons are just pictures of a gameboy. :stuck_out_tongue:


Can’t the loader display a part of the file name for the text?

And I think it’s possible to extract a game name from a rom if I remember right?( Would work only for the game on ROMs, I know)


Yes, but that goes back to the point I was trying to make: text is unavoidable.


Oh yes sorry. I think I missed that part.