It’s on the Pokitto now!
It’s on the Pokitto now!
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.
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
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
Nice! Thank you @Pharap
I have additional questions, such as
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?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
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:
No FP in this mcu
Progmem is an AVR-specific workaround. In this (and other mbeds and actually pretty much everything else) all you need is const
Yeah, I know, I know
Its a good idea tho.
Please add to the to-do list.
Thanks for the answers
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.
Also started playing around with my raycasting lib
Spent last two hours looking for an annoying bug, it’s finally kinda working except for the fisheye distortion.
The fisheye is a common problem in raycasters. IIRC You can fix it by using sin() function.
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? Could be optionally left in.
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.
There are two things to keep in mind:
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
But cameras have planar CCDs.
yep but they have optics in front of the ccd