[Suggestion]Future of PokittoLib - v2.0

You’d be willing to sacrifice the hardware debugging aspect due to the cost issues?

(Though I suspect we could get hardware debugging working on another system.)

No, we could abandon the mbed online compiler

You could still debug in any GCC offline compiler

I am in favour of abandoning mbed online (at least until their clock hits 2011).

I think most people here own a Github account anyway, so hosting code wouldn’t be an issue.

@dreamer was working on getting PlatformIO working a while back,
but it’s unclear if they managed it.

We have @FManga’s makefile as a base to work with,
we just need someone who can adapt it to work.

I’ve added a library to PlatformIO before, that much is easy, but setting up a compilation target will be more difficult.

A very minimalistic Core shouldn’t be hampered by C++98… but ditching mbed changes things completely.

Platformio works with makefiles? Or does “adapt it to work” actually mean rewrite it for some other build system? :stuck_out_tongue:

13 posts were merged into an existing topic: Using PlatformIO for compilation

The other day I sat down and thought about the buttons API and I’ve come up with a few ideas for improving it.

Firstly, I think it would be good to scrap all the aBtn()/aHeld()/aReleased() functions.
There’s a lot of them and I honestly think they muddy the waters and confuse the API rather than being useful.
(If they are still needed they could be included on a different class that acts as an adaptor.)

For the main API, I have two suggestions that differ mainly in wording.

Option 1:

class Buttons
{
public:
	// Manually called to update the button state.
	// Typically called once per frame/once per logic update.
	void update(void);
	
	// True if the button has just been pressed
	// (i.e. true for one update only)
	bool isPressed(Button button);
	
	// True if the button has just been released
	// (i.e. true for one update only)
	bool isReleased(Button button);
	
	// True if the button is currently pressed.
	// (i.e. true for multiple updates)
	bool isHeld(Button button);
	
	// True if the button is currently released.
	// (i.e. true for multiple updates)
	// Equivalent to !isHeld(button)
	bool isNotHeld(Button button);
};

Option2:

class Buttons
{
public:
	// Manually called to update the button state.
	// Typically called once per frame/once per logic update.
	void update(void);
	
	// True if the button is currently pressed.
	// (i.e. true for multiple updates)
	bool isPressed(Button button);
	
	// True if the button is currently released.
	// (i.e. true for multiple updates)
	// Equivalent to !isPressed(button)
	bool isReleased(Button button);
	
	// True if the button has just been pressed
	// (i.e. true for one update only)
	bool justPressed(Button button);
	
	// True if the button has just been released
	// (i.e. true for one update only)
	bool justReleased(Button button);
};

The timing aspect would still exist, but I think it should be an optional extra because most games can function on the minimal API.
I’m not sure if the timed API should be an adaptor class or a part of the main buttons class that can be enabled, but I’ll present it as an adaptor for now.

class ButtonTiming
{
public:
		
	// True if the button is has been held for the given number of updates.
	// Is true once and won't be true again until the button is released.
	bool isHeldOnce(Button button, uint16_t numberOfUpdates);
		
	// True if the button is has been held for the given number of updates.
	// Can be true multiple times until the button is released.
	bool isHeldRepeat(Button button, uint16_t numberOfUpdates);
	
	// Returns the number of updates that the button has been held for.
	uint16_t updatesHeld(Button button);
};

It may also be possible to develop an API that uses actual time instead of the number of updates.
I chose to use the terminology ‘number of updates’ rather than ‘number of frames’ because it’s entirely possible that update might be called more than once per frame.


As an extra thing, it might be a good idea to provide a pure virtual button class based on these interfaces with a concrete implementation handling the buttons.

Then if people want to attempt multiplayer games (e.g. through use of a bluetooth/wifi/serial hat) they could create an alternate implementation that would have the wired/wireless multiplayer link as its back-end.

This would allow the programmer to program their game objects to respond to a single interface but automatically allow them to respond to both real button presses and to input from a wired/wireless link.
Liskov substitution in action.

This might be better to have in a different library though, if the main library’s aim is to be kept small and simple.

1 Like

Here’s an untested draft of a simplified Buttons API:

Very much an early draft still, hence the lack of the timed functionality and currently no way to select the polling version rather than the interrupt version.

1 Like

@FManga :

Your checksum trick did not work in EmBitz:

c:/program files (x86)/embitz/1.11/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe:Pokitto/mbed-pokitto/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/TOOLCHAIN_GCC_ARM/TARGET_LPC11U68/LPC11U68.ld:238: syntax error

I had to revert that back to normal, as I do not have time to investigate

Yeah, I saw the PR. Looks like the embitz version of ld doesn’t like comments (// The reset handler).
Should I remove them and send another PR?
I don’t have embitz here, so I can’t test :stuck_out_tongue:

1 Like

Yes please !! (Do you ever sleep in Brazil?)

2 Likes

The PSP has a folder for saved data and a folder for games. Each game has its own folder inside of each. Applying that to this, maybe the saved data folder is public, but game folders are private? The author of the game can have it save to either the game folder or to the public savedata area.

I’ll make a note to look into it.

Having a separate shared folder and private folder per game sort of makes sense.

If we went with that though, I think it would make sense to store metadata about a game in the shared folder and make it so both the shared and private folders are only writable by the game that owns them, but the shared folder for each game is visible to all games.

That would mean the shared folder could function as a way of signalling the presence of a game so people can do cool tricks like adding special ‘DLC’ if you’ve played both games.
(Like how TF2 gives you cool hats if you preorder other games.)

I attempted to get the PokittoLib compiling in Code::Blocks today.

Via manual editing I managed to get within 50 errors of compiling.
Via @fmanga’s makefile I got “recipe for target all failed”.

It’s a start I guess.

The ARM hardware target you mean ?

Yep, trying to compile the actual ARM-targetting code through Code Blocks using the same compiler EmBitz uses.

Down to just one error: “unrecognized command lin option ‘-mwindows’”.

Never mind, solved that one.

1 Like

Instead of doing v2.0 as a clean-slate rewrite that would take a lot of unavailable time and energy… how about we simply introduce the concept of “interfaces” to v1.0 and gradually move the code out of the core?
The screen modes would still be in core, but if reduced to just 4 (Modes 0, 1, 2, 13) it’s not so bad.
Interfaces would then be responsible for providing adaptors for Gamebuino/Arduboy compatability, and PokittoStarter.
You might have noticed that tiled mode is absent from the list of modes I mentioned above. Instead of trying to figure out what an ideal tile mode is supposed to be, I propose we rename what we have now to better reflect what it is: a mode with no framebuffer. Following the advice that “easy things should be easy, and hard things should be possible”, mode zero becomes simply the low-level mode that allows more direct access to the LCD. Tile-based engines of differing styles and restrictions can build on top of that in an interface or a separate library. This way it also becomes the logical mode to use for things that don’t need a built-in framebuffer (Gameboy/SegaVMU/Bitsy).

One problem left to solve is text: how can something that uses mode 0 provide its own text-rendering so that the existing print functions continue working? And how do we fix the FPS printer in all the modes without breaking optimizations in the process?

I have already fixed the FPS printer for the optimized mode 2. Same way it can be done for all the buffered modes, i.e. skip copying top 8 scanlines. I did not notice any difference in real FPS value, with or without the FPS printer ( because the value is rounded to an integer).

I was just thinking about the screen modes today. I did a quick test and although I can’t quite get a recreation of mode1 working correctly, the idea is there.
Basically, merge all of the buffered screen modes into 1 single mode.
Like this
mixMode.bin (67.2 KB)
Press ‘A’ to cycle through standard mode 13, mode 1 (not fully working) and a new mode based on the c64 wide pixel mode, with 110x176x16.

That way, people can change screen mode at run time to have say, a hi-res lo-colour title screen and lo-res hi-colour gameplay or whatever.