[Draft] Pokitto Frequently Asked Questions (FAQ)


#1

Pokitto Frequently Asked Questions (FAQ)

Software and programming

How can I speed up the coding-testing cycle?

Add to the My_settings.h file:
#define PROJ_DEVELOPER_MODE 1

That disables the startup screen and removes the launcher start query delay.

How can I check if my program crash is caused by a stack overflow?

Add to your code:
CheckStack();

The CheckStack() function executes very quickly and checks if you are near the limit to overflow the stack. If the limit is near it will show the red Pokitto Crash Screen. Note that currently it does not take into account any dynamic memory allocations. Most of the code in Pokitto do not use dynamic allocation.

How can I add a FPS counter to my program?

Add to the My_settings.h file:
#define PROJ_SHOW_FPS_COUNTER
That will automatically show a FPS counter on the left side of the screen.

If you want to show your own UI for the FPS counter, you can alternatively add:
#define PROJ_USE_FPS_COUNTER
Then you can show the counter by yourself like this:

Pokitto::Core::display.print(0, 0, Pokitto::Core::fps_counter);  

What kind of “PROJ” macros are there?

Here are the list of known “PROJ” macros with one line explanation. For more detailed info you can search in the forum or throw a question.

  • PROJ_HIRES: Uses the screen mode: 220x176 with 4 colors ( otherwise uses 110x88 with 16 colors)
  • PROJ_MODE13: Enables the screen mode: 110x88, 256 colors.
  • PROJ_MODE15: Enables the screen mode: 220x176, 16 colors.
  • PROJ_FPS: Sets the FPS limit.
  • PROJ_SHOW_FPS_COUNTER: Shows the FPS counter on the left side of the Pokitto screen.
  • PROJ_USE_FPS_COUNTER: Enables you to draw your own FPS counter.
  • PROJ_STARTUPLOGO: Shows the Pokitto startup logo (defined by default).
  • PROJ_DEVELOPER_MODE: Starts the program immediately without any startup screens.
  • PROJ_ENABLE_SOUND: Enables audio. Needed, if any kind of audio is wanted.
  • PROJ_STREAMING_MUSIC: Enables streaming of audio, E.g. reading sampled music from a wav-file.
  • PROJ_ENABLE_SYNTH: Enables synthesized music, e.g. tracker music.
  • PROJ_AUD_FREQ: The frequency of the audio output, e.g. 8000 or 44000 (Hz).

How to fast deploy compiled bin to Pokitto (Windows)

Once your project is offline compiled with EmBitz there’s an easy way to transfer to Pokitto.
Inside PokittoLib\build folder you can find an handy _copy.bat file. It will open a cmd prompt where you can drag and drop your .bin file. It will take care to delete the the old firmware.bin from Pokitto in CRP_Disabled mode, and copy your new file.

How to make the compiler to optimize for speed on HW?

Make sure the -O3 option is used in the compiler. Also check that no other option, e.g.-Os, is used. The latter option overrides the former. Note: To be sure, check from the PokittoEmBitz.ebp
that -O3 is used, even if in the EmBitz UI it seems to be so.

Hardware

Misc


#2

Please add your own items to the topmost post of this topic. Even tiny tips can be very useful for the beginners and for more experienced coders too. So keep the bar of adding new items low.

The FAQ is meant for quick tips. For the longer instructions, please make a tutorial or an own forum topic to the correct category.


#3

Is this intended as a programming-related FAQ or anything?

If it is anything then I would be very very grateful if everyone who has had problems understanding how to get started would suggest for entry level topics / questions


#4

Lets put everything there and split later if needed.


#5

Are the PROJ_ macros documented anywhere?


#6

Not that I know.


#7

Added to FAQ: “What kind of “PROJ” macros are there?”


#8

maybe add a line to mention that there should be #define in front of it ?


#9

For me as newcomer, timing/pacing was a a little complex. Untill I discovered Pokitto used the

mygame.setFrameRate(20); //set correct framerate

as timing.

Could be in question form like:

Why is my gameobject moving way too fast ?

  • Pokitto paces all code inside the if (mygame.update()) {depending on the set framerate, everything outside that is run at the highest speed possible for Pokitto.

#10

I think that’s getting into the grounds of “How to write C++”,
and I think the FAQ should stick to Pokitto-specific issues, lest things like "you can use type aliases so you don’t have to remember long names, e.g. using ShortType = SomeStupidlyLongTypeNameTM;" slip in.

Personally I’d object to restricting the framerate as a means of controlling timing.

It’s more difficult but doing timing with methods that are independent of the framerate makes your code more able to cope with changes and a higher workload.

That’s the kind of question to be asking at the forums rather than looking at the FAQ for.
There are lots of different causes and solutions.
For example, using float for coordinates and making the object move a fraction of a pixel at a time might be a good solution in some cases.

That probably is a valid point to point either in the FAQ or a starter guide somewhere.

I’m not sure what heading it would best belong under though.


#11

I would use fixed point numbers instead. Using floats without FPU can be sluggish.


#12

I find it varies depending on the operations being used and the platform in question. For the Pokitto though, it’s plausible that fixed points would be better since the Cortex has a barrel shifter (as far as I’m aware) so it can handle the operations quite efficiently.

Incendentally I know a good library for that :P


#13

Waiting a Pokitto tailored tutorial on that.


#14

It will run on the Pokitto, it just needs a few changes beforehand - a few include changes in Details.h.
The library itself is very easy to use as long as you understand fixed points first.
After that you can just use the types as if they were integers or floats, all the appropriate arithmetic and comparison operators are overloaded (except modulo because that doesn’t really make sense for non-integers).

Anyway, I digress.


#15

The question (why is my gameobject moving way too fast?) was intended to point out that inside the mygame.update everything is updated on a set rate.

I understand there are more ways to determine speeds/movement but for me as a beginner, this was a big help in updating stuff. I learned this from looking at other examples, so it is used by others as well.

I did read about DeltaTiming, and I might use that someday but at this moment it is still too much for me to build into a game.


#16

That’s indeed a good solution in this type of application. IMO having a delta time approach is something essential on different platform (multithread, multicore, lot of different hardware).
Anyway I agree is something more related to a basic view on how Pokitto Lib is structured, the kind of TIPS already posted seems to head towards more in depth aspects of programming.

Maybe a good starting point for another thread?


#17

My point is that the fact doesn’t really match the question.

A better question would be “What does Pokitto::Core::update do?” or “Why do I need Pokitto::Core::update?”.

Its simplest form delta time is quite easy (assume millis() is some function returning the number of milliseconds since system startup as an int): here.

It gets more difficult when you need it to be more accurate and account for weird circumstances like slowdown, but in most cases you don’t need to worry about those and the simple approach will suffice.

(Granted, floats can be an issue depending on the complexity of the program, but I’ve seen games written for AVR chips that go OTT with floats, so I’m convinced the Pokitto would probably handle them alright in most cases.)