I meant the calculating part.
To make it truly generic (so you can use any number of screenmodes) requires template code like the code I posted above.
Actually reusing a buffer is easy as long as you keep track of the details. Just bear in mind how much memory you’re using.
Anyway, “how to achieve multiple screenmodes” is a bit off topic until it’s decided if that should be a job for the library or for an extension.
This thread is about deciding what’s best for the library.
yes my bad, though this brings up a point on how much the library has to do under the hood
currently the update loop is drawing the screen but we could give the user control over when to draw and in what mode
to go back on topic if we started work on pokittolib2 we could break compatibility completely and fix and streamline allot of things
Another suggestion for if we go ahead with PokittoLib V2.
Perhaps move the Arduino stuff into a separate part of the library that has to be manually included.
A number of the Arduino facilities clash with the C++ stdlib facilities because they’ve been designed for an environment that doesn’t have the stdlib. Notably
It makes sense that the Arduino facilities should be something you have to add on top of the regular library for porting Arduino projects rather than something native Pokitto projects should have to choose to disable manually.
Essentially an Arduino port could do:
Or something similar.
And you’d no longer have to do:
For regular Pokitto projects.
Doing this would also allow some of the more lightweight stdlib facilities like the
utility headers to be used in the library itself to simplify some of the code used.
Agreed. I am going to start this evolution soon.
I don’t know if this has been discussed or hasn’t been done because it’s a lot of work, but it would make things easier for people using the lib for the first time if the template settings file had all the options in it, commented. Changing settings would be done by uncommenting a line.
// uncomment to hide the startup logo
// #define PROJ_STARTUPLOGO 0
// uncomment to disable sound
// #define PROJ_ENABLE_SOUND 0
One of the recent questions reminded me of another issue.
Instead of having the Pokitto try to seed the random number generator with
srand, it would be better to provide functions that can be used to generate an almost random initial seed that users can then feed into a random number engine of their choosing.
That way they can pick any of the engines from C++'s
random header or the bog-standard
rand from C.
(Dependency inversion in action!)
The source could be the RTC, an unconnected pin or something else.
It feels like we need to do a hole redesign on the system, not allot of code would remain it be good to figure out all the optimizations and plan this out before actually implentation no?
About rng do we need multiple? Idk what the advantage is from doing or own one over c or standard library one?
Bieng compliant with standard makes it easier for people to use the language on other platforms, but idk
We have code that works that we can use as a base for the new code rather than starting from scratch.
The changes should be focused more on the API, which bits work, which bits don’t work and which bits people find confusing or not as useful.
Though I agree we should spend time planning it before implementing it. Making sure we consider different eventualities will help to prevent needing future changes.
There are several advantages.
Firstly by only providing a seed we give people the freedom to choose the PRNG that they want to use.
This means people who don’t need high quality randomness can choose a fast, simple PRNG and people who do need high quality randomness can choose a slower, stronger PRNG system.
Sticking with C’s
srand like we currently are locks users into a particular implementation which may be wholly unsuitable for their need.
Furthermore, by only providing the seed and not the PRNG, we don’t have to make any promises about the quality of the random numbers.
We only have to verify the quality of the seed we provide, after that the onus is on the end user to chose a PRNG that suits their needs.
We don’t have to ‘be compliant’ with the standard.
We would be giving the library users the freedom to chose any PRNG they want, not just the ones from the C++ library, but any that merely require a seed of a certain size.
This is a case of less is more:
less work for library developers, more freedom for the end users.
sure i get that but would having multiple rng just make people more confused i think
idk it has to be very clear wich is for what but i have no idea how to approach that since i dont even know what the difference really gives or wich to pick
anyway how to we correctly and clearly manige this planning?
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>();
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>();
createRandomlySeededEngine is implemented as something like:
template< typename EngineType >
using SeedType = typename EngineType::result_type;
I think for now the best thing to do is just pool ideas and make a wishlist of features.
That’s what I’m talking about.
Where do you think I plucked
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)
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.
std namespace is sacred
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
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
Edge triggering feels more natural.
You’ve just reminded me.
A number of the
Buttons functions return
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
In fact it might be best to divide the buttons API into a simple version that only does
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
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(10) becomes illegal.
Would the PokittoLib V2 have to stay using C++03 to be compatible with mbed online?