[Suggestion]Future of PokittoLib - v2.0

Not necessarily, we can just pick one that acts as a middle ground and say “if in doubt, use this”.

The difference between the types of PRNG are their data ranges, the cheapness of implementations and the quality of the randomness they produce.

A linear congruential generator gives pretty poor quality random numbers, but LCGs usually suffice for basic games and they’re really cheap.

A mersenne twister gives really good quality random numbers, but they require a lot of memory in exchange for that quality.

rand has no guarantees as to its quality. It could be something better than a mersenne twister, it could be something worse than an LCG. Technically it could probably just return 4; every time.

The code could look something like this:

const int seed = Pokitto::getRandomSeed<int>();

Or this:

using SeedType = typename std::knuth_b::result_type;
const SeedType seed = Pokitto::getRandomSeed<SeedType>();
std::knuth_b engine = std::knuth_b(seed);

Or if we went a step further:

std::knuth_b engine = Pokitto::createRandomlySeededEngine<std::knuth_b>();

Where createRandomlySeededEngine is implemented as something like:

template< typename EngineType >
EngineType createRandomlySeededEngine(void)
  using SeedType = typename EngineType::result_type;
  return EngineType(getRandomSeed<SeedType>());

I think for now the best thing to do is just pool ideas and make a wishlist of features.

What about using STL’s random generation facilities?

That’s what I’m talking about.
Where do you think I plucked std::knuth_b from?

Essentially what I’m saying is:
We provide the seed, other libraries (like the stdlib) provide the PRNG.

(By the way, that’s the C++ standard library (stdlib), not the STL.)

OK! It’s just that I was kind of seeing some kind of reimplementation of it haha didn’t occur to me that you where reusing it (Still a lot to learn about the standard library and c++ in general, didn’t knew about knuth_b for example)

(Oh, yes, I still got that bad habit of naming STL the whole standard library haha I’m sorry for that)

1 Like

As a rule of thumb, anything prefixed with std:: is probably from the stdlib.

The only exceptions to that are template specialisations of stdlib functions (e.g. custom std::swap implementations) and people doing things they probably shouldn’t be doing for some reason or another.
The std namespace is sacred :P.

The best way to learn it is to either sit down and read through all the headers on en.cppreference (or in your case maybe the ones in fr.cppreference?) one by one, or to attempt to write your own implementation of various stdlib facilities.

Anyway, what do you think of the “provide a seed function and let other people choose the PRNG” idea?

I’m not ignorant enough to not know about the std:: namespace haha and yeah, I never extend it and also consider it sacred.

I’m discovering them as soon as I need something that looks like “standard” enough (e.g. std::chrono recently!). I’m not spending time reading all headers just for the sake of reading them, that’s a bad method of learning for my brain haha (no association or use = no recollection of them). Practice gives me opportunities to use new stuff everyday, as long as I remain open to the question “does the std lib implement something that could help me?”


In the new API could be possibile to add upPressed in a similar way we already have upReleased for all the buttons?
I found quite odd this function is missing and you need to use Buttons::pressed(BTN_UP); instead

1 Like

Have look at how I handle buttons in my games, I think it’s much better and can detect newpress, held and released.


I do like the ability to detect when a button has been held for a number of frames, but I must admit I think the Pokitto could use an equivalent of Arduboy’s justPressed and justReleased.

Edge triggering feels more natural.


You’ve just reminded me.

A number of the Buttons functions return uint8_t when bool would make more sense.
uint8_t makes sense for the ones that return the amount of time a button has been held for, but bool makes more sense for the pressed/released variants.

In fact it might be best to divide the buttons API into a simple version that only does pressed, released, justPressed and justReleased (i.e. edge triggered variants) that are all bool oriented, and the more complicated version that counts the number of frames a button is held for and can do more advanced precision timing.

Either way I think we also need to have an enum class for the button types instead of using uint8_t. e.g.

enum class Button
  Left = 0, Up = 1, Right = 2, Down = 3,  A = 4, B = 5, C = 6,

constexpr const std::size_t ButtonCount = 7;

Then the current Buttons::pressed(BTN_UP) becomes Buttons::pressed(Button::Up) and Buttons::pressed(10) becomes illegal.

Would the PokittoLib V2 have to stay using C++03 to be compatible with mbed online?

im going to assume so since we still have no way to compile on all platforms

I thought that would be the case.
That means desiging an improved API is going to be 100 times harder.

no constexpr,
no explicit conversion operators,
no enum class,
no nullptr,
no automatic type deduction,
no delegating constructors,
no range based for loop,
no template aliases,
no varaidic templates,
no explicit defaulted and deleteed constructors,
no long long int,
no static_assert,
and that annoying double right angle bracket issue.

1 Like

Does it have to be the same way on all platforms? Which are the problematic ones?

mac side has no working toolchain so far and raspberry pi. im not sure how desktop linux is going
we where trying to go platformio to unify but it seems there some limitations for debuging and still a total pain to get working

one of the problems is theres to many dependancies for some versions of the toolchain, which end up being points of failure. also im not sure but the mbed cli is still using the c++03

my hope is to just have a standalone command line program like a gcc, then we can just deal with a makefile on everything aside from windows

I got linux desktop working like this: I exported a project from the mbed ide, got arm-none-eabi-g++ (I think it’s in ubuntu’s apt) removed a few wrappers from the makefile and added the checksum. Now I just run make.

1 Like

You should post that makefile.

If we could get that running with Code::Blocks or Visual Studio then we could have an offline IDE that everyone can use.

(And then I can try to design some bits to be included in the new API without having to worry about avoiding all the useful C++11 features.)

1 Like

Here it is.

Edit: it might also be good to look into this: https://community.nxp.com/thread/388993


It will be really useful to implement the methods to retrieve how much RAM and CPU usage for Pokitto.
Now there are only some empty placeholder derived from GB

static uint8_t getCpuLoad();
static uint16_t getFreeRam();

Don’t know if hardware debugger can retrieve this kind of information too?

Not sure where to put this, but I got the linker script to calculate the checksum so it’s not necessary to run an extra step with external tools during the build.

The following files are in PokittoLib/mbed-pokitto/targets/cmsis/TARGET-NXP/TARGET_LPC11U6X/TOOLCHAIN_GCC_ARM/TARGET_LPC11U68 which is what’s used when you export for Make-GCC-ARM.

LPC11U68.ld - add this near the end, before the last }

    PROVIDE(__valid_user_code_checksum = 0 - (
    				       _vStackTop +
				       (ResetISR + 1) +                        // The reset handler
				       (NMI_Handler + 1) +                     // The NMI handler
				       (HardFault_Handler + 1)               // The hard fault handler
    ) );

Now just declare __valid_user_code_checksum and add it to the table in startup_LPC11U68.cpp:

extern void __valid_user_code_checksum(void); // pretend it's a function

void (* const g_pfnVectors[])(void) = {
	// Core Level - CM0
    &_vStackTop,                     // The initial stack pointer
    ResetISR,                        // The reset handler
    NMI_Handler,                     // The NMI handler
    HardFault_Handler,               // The hard fault handler
    0,                               // Reserved
    0,                               // Reserved
    0,                               // Reserved
    __valid_user_code_checksum,      // <-- good stuff
    0,                               // Reserved
    0,                               // Reserved
    0,                               // Reserved
    SVC_Handler,                     // SVCall handler

Before you can build, remember to patch the Makefile. Simply replace LD_FLAGS := ... with:

LD_FLAGS :=-Wl,--gc-sections -Wl,--wrap,main -Wl,--wrap,_memalign_r -Wl,-n --specs=nano.specs -mcpu=cortex-m0plus -mthumb 

To build, get the toolchain for your OS (Windows/Linux/MacOS) here.

If you’re on Ubuntu, don’t use the old ARM GCC in APT. Extract the gz2 file somewhere, put softlinks in your path to the files in the bin folder (eg, ln extracted/bin/arm-none-eabi-gcc /usr/bin/arm-none-eabi-gcc -s) and you’re set.

Now just run make.