Pokitto is on the way, what games should I make?

It’s on the Pokitto now!

4 Likes

There’s no settings file with this.
What screen mode does it use?
Is it lores mode? (110x88 16 colour)

Nevermind, I found the screenmode option buried part way down the code.
I find it odd that this code would compile without a My_settings.h file.


Also, for the record, using small datatypes like uint8_t and uint16_t is probably more expensive on ARM because ARM needs extra instructions to truncate its 32 bit registers after performing arithmetic.

1 Like

The settings file is there somewhere, just not in the repo. I still don’t know how it works exactly, will look at that tomorrow :slight_smile:

Interesting, I’m still used to it from Arduboy, I’ll reconsider this. Is there a way to see how much RAM is occupied with global variables, like with Arduino?

EDIT: Just to make it clear, it’s not complete yet. Probably will be tomorrow though.

I guessed as much.

It makes sense to use e.g. uint8_t for arrays when you only need a small range of values because that saves memory, but for things like counters you probably want larger values.

For things like counters, you can use unsigned int as long as you aren’t dependent on underflow/overflow.
If you want your code to be optimal when ported to Arduboy then you might want to opt for uint_fast8_t instead (it’s a bit of a mouthful, so you might want to do using ufast8_t = uint_fast8_t; if you’re lazy).

Some of your types would be best off being replaced with size_t, for the sake of correctness.
size_t's definition is essentially:

size_t can store the maximum size of a theoretically possible object of any type (including array)

so it’s the type you should always prefer to use for array indexing and sizes.
(Obligatory SO answer.)

(It doesn’t really apply to your code, but while I think of it, there’s a related issue where many people attempt to cast a pointer into an int when the proper type is either uintptr_t or intptr_t.)

When using VSCode+PlatformIO, it’s printed out on the terminal:

Archiving .pioenvs\lpc11u68\lib70d\libArduboy2.a
Linking .pioenvs\lpc11u68\firmware.elf
Checking size .pioenvs\lpc11u68\firmware.elf
Building .pioenvs\lpc11u68\firmware.bin
Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [===       ]  35.0% (used 12900 bytes from 36864 bytes)
PROGRAM: [=         ]  14.1% (used 36900 bytes from 262144 bytes)
========================= [SUCCESS] Took 18.27 seconds =========================

I’m pretty sure EmBitz tells you as well, but I have no clue about Code::Blocks.

If I’d realised that I wouldn’t have started making a derived version :P

1 Like

Nice! Thank you @Pharap :slight_smile:


I have additional questions, such as

  • Does the MCU have an FP unit or is it again only emulated in SW? I suppose it’s only SW as I couldn’t see any FP block in the MCU diagrams when I looked, but I am a complete noob here and may as well be wrong.
  • How do I handle program memory vs RAM? On Arduboy there’s the PROGMEM modifier (I also found out the hard way that I can’t simply directly assign a value from a PROGMEM marked variable, I have to use a special function). How does it work here?
  • Are there any restrictions on C++ language? Is the standard library supported in whole? Or only C lib again?

I am aware the answers are probably to be found around the website here, but I suppose they’re buried in the tutorials for complete beginners. I’d be really really glad if you, or any other of you nice gurus here, could make the

Pokitto programming specifics for those who already know C++

article, in order to have it all in one place. I’d be eternally grateful :innocent:

I honestly have no idea.

I’ll leave that one to @jonne to answer.

I believe (don’t quote me on this) that actually the progmem isn’t really progmem, it’s simulated with flash memory (or possibly write protected) and consequently there’s no special instruction for reading from progmem like there is on the AVR, which means you don’t need a special macro for either reading progmem or putting a variable into progmem.

From what I’ve heard the compiler tries to stick anything marked const or constexpr in progmem, and I’m guessing it will possibly try to put other things in progmem following the same rules as a compiler compiling for desktop would for trying to decide what it can put in the ‘constant data’ section of an executable.

So in other words, don’t worry about it too much and just mark anything you don’t change as const (which I try to do anyway - using const on your variables signals to other code readers that you don’t change that variable at any point).

(Not directly related, but you might be interested in single static assignment form, a technique used by compliers such as GCC to determine which variables are truly const and to do reaching definition analysis.)

Full C++11 (and later). Full standard library.
(Unsurprisingly I am immensely happy about this :P)

You can even use dynamic allocation as long as you don’t overdo it.
If you do though, I’d suggest using smart pointers (unless you find them to have a measurable significant negative impact on speed or size).

Not quite the same but I wrote a C++11 for C++03 programmers (which I didn’t get around to finishing because C++11 was a massive update to the language).

If you’re already experienced with C++ then I can’t think of much more that you’d need to know than:

  • What’s the chip like? - The chip is a 32 bit ARM chip
  • What’s the ISA like? - The instruction set is the 16-bit Thumb instruction set without full 32-bit ARM instructions (and it’s documented here and here)
  • Is the stdlib available? - Yes, completely
  • Whether there’s an FPU? - Don’t know
  • What’s the API like? - Documented here
  • What are the other APIs like? - Documented here, very C++, many classes (and even a few templates)
1 Like

No FP in this mcu

2 Likes

Progmem is an AVR-specific workaround. In this (and other mbeds and actually pretty much everything else) all you need is const

1 Like

Yeah, I know, I know :blush:

Its a good idea tho.

Please add to the to-do list.

1 Like

Thanks for the answers :slight_smile:

I’ve added a compiled bin of the 2048 game to the above linked repo, could maybe some of you reading this playtest it a bit so that I can release it “officially”? I’m playing it right now, seems kind of okay.

out

3 Likes

Also started playing around with my raycasting lib :slight_smile:

out

Spent last two hours looking for an annoying bug, it’s finally kinda working except for the fisheye distortion.

5 Likes

The fisheye is a common problem in raycasters. IIRC You can fix it by using sin() function.

3 Likes

I remember dealing with this but can’t remember the solution right away. Will try the sin function, but first I need to remember what the problem is.

Actually it’s a nice effect though, isn’t it? :smiley: Could be optionally left in.

1 Like

The problem is probably that the ray is casted from the single point, the observer. So even if z-coordinate is the same, the distance is bigger for objects further left or right that objects in the middle.

The cos function indeed fixed it, thanks for the tip.

out2

There are two things to keep in mind:

  1. Don’t cast the rays with constant angle step – this creates a kind of “panorama” view. The rays need to be cast through the view plane, which implies non-constant angle step. (This I knew about.)
  2. If you want to display the walls as straight (not fisheye) you have to multiply the distance by cos(angle) as you said. (Not exactly sure why yet, let me think about it.)
3 Likes

common aesthetic* you mean

Sure, but isn’t this also the case with our eyes and cameras? Why don’t these have the fisheye effect?

your eyes are not planes

cameras also have lenses

1 Like

But cameras have planar CCDs.

yep but they have optics in front of the ccd