Very nice and easy customisation! I cannot wait to test the loader and add Python script support
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ā¦
How about Pokitto games instead? Iām looking forward to that platformer youāre working on.
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ā¦
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. 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.
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.
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.