I’d like some suggestion for books or documentation focused on developing for low spec platforms.
Something to discover all the smart tricks used by 8bit generation developers, facing the same constraints (low ram, limited cpu) we have to face developing Pokitto, or any any other embedded device.
2 Likes
‘Smart’ is relative.
Some ‘smart tricks’ come with big caveats and can end up shooting the author in the foot.
That said, it’s not a book but here’s the internet’s ‘Bible’ of bit manipulation ‘hacks’:
https://graphics.stanford.edu/~seander/bithacks.html
Note that a lot of these are dependant on 32-bit or 64-bit word size (fortunately the Pokitto has a 32-bit word size), and some might only work on an x86 CPU.
And as an added bonus, if you’re ever planning to write anything chess-like or anything played with pieces on a grid then you might want to look into bitboards:
Again not a book, but still useful.
And of course, there’s its cousin, which is almost always useful, even on fast modern computers,
the bit array/bit set.
I actually used one of these on a desktop program once because I wanted to check that a hash function I wrote was bijective and I was running out of RAM using a typical 1 byte per bool approach.
(I don’t tend to read programming books, depending on the subject matter they can end up being outdated before they’re even published. That and I don’t have the money or the room.)
2 Likes
One I really liked was Tricks of the Game Programming Gurus. The original one, for DOS.
I know you were asking for 8-bit CPUs, but programming the Pokitto is, in some ways, more like programming for that (just a CPU directly manipulating the framebuffer) than something like the Gameboy (which had a whole bunch of extra support hardware around the CPU).
3 Likes
The Graphics Gems books have graphics related algorithms. There is also a code repository for them: http://www.realtimerendering.com/resources/GraphicsGems/
3 Likes
Some of that code is so old it’s written in pre-ansi C.
I.e. the kind that allows function parameters to be written like so:
int Box_Sphere_Intersect( n, Bmin, Bmax, C, r, mode )
int n; /* The dimension of the space. */
float Bmin[]; /* The minimum of the box for each axis. */
float Bmax[]; /* The maximum of the box for each axis. */
float C[]; /* The sphere center in n-space. */
float r; /* The radius of the sphere. */
int mode; /* Selects hollow or solid. */
{
Not to say it’s not useful, just that some of it could potentially be written in a better way.
(And of course, what was fast on the CPUs of the late 80s might not be the fastest technique on a modern CPU.)
The author also seems to have a rather… obscure sense of humour.
While I think of it, I just want to point out that even among embedded systems what’s fast on one chip might not be fast on another.
For example,
AVR chips have no barrel shifter so bit shifting is actually relatively expensive on systems using AVR chips.
Fortunately ARM-based chips (like the Cortex-M0+ used by the Pokitto) don’t have that problem.
1 Like
First of all thanks everyone for the great suggestions! I’m still looking through everything suggested.
That’s really sound not so smart 
Agree, its seems also like an ancient art or artisan ability not so easy to catch. I just stumble on this nice article and the feeling is the same.
As example, Internet is full on platform tutorial using Unity/Game Maker and other framework with physic capabilities. But bit shifting the player position value to get tile modulo (hope to have been clear), is something nobody use anymore.
I’d like to find more of this old tricks used int the old games gems.
1 Like
This is one of the reasons I don’t like Unity and Game Maker.
They’re fine if you just want to churn out a game,
but they hide a lot of what’s actually going on and they make it really easy to write bad/buggy code,
so they’re not good tools for learning.
(If programming were carpentry then a lot of Unity/GameMaker code would be equivalent to someone badly nailing and gluing bits of wood together instead of using a proper join, like a dovetail joint.)
If you mean using & to perform a modulo operation (e.g. x & 7 instead of x % 8) then the reason you don’t see that much these days is because the compiler will make those sorts of optimisations for you.
The same applies to things like multiplying by powers of two (e.g. x * 4 becomes x << 2).
But in other cases, like people using std::array<bool, size> instead of std::bitset<size>, usually it’s either because people aren’t aware of the alternative or because they’re writing for desktop so they assume that they’ve got RAM to burn.
(Usually it’s the latter. People tend to think “Even laptops have 8GB these days”, and they don’t stop to think “Actually, that 8GB has to be shared by every process currently running on the computer…”.)
(In the case of C++, std::vector<bool> is specialised so it actually only uses 1 bit per bool.)
It’s also worth noting that with some techniques there’s often a tradeoff between speed and size.
Packing 1 bit per bool is better for space, but on some systems reading/writing an individual bit can often be slightly more expensive than reading/writing a full byte.
Most of the time it isn’t important,
but if it’s being done in a loop then it could soon mount up to a large slowdown.
2 Likes