Every time I read about GBA internals I'm still amazed something like Super Monkey Ball Jr (https://www.youtube.com/watch?v=K-AZQKTlUMs) could have been created on that platform...
would love to read a technical making-of of one of these games that pushed the boundaries of their respective target platforms. Anyone got any suggestions?
>I’m using 32 bit integers to store tile data because the GBA is a 32 bit machine at heart, and I’ve found a couple places online that talk about how much faster the GBA hardware is at working with 32 bit integers vs 16 bit ones when possible. Since I have no way of verifying this right now (no timers yet!), this is also a matter of faith for the moment.
This is true if you're doing calculations. However, memcpy works in bytes (logically, anyway) so it wouldn't make any difference for tile data. Storing tile data as ints would complicate things if you ever want to modify any of your tiles.
Nitpicking aside, this is an excellent tutorial. The simplicity of the code makes it easy to understand.
You are definitely right. Tonc has some interesting data (here: http://www.coranac.com/tonc/text/text.htm#tbl-txt-se2) about performance of operations with 16 bit vs 32 bit variables, but none of that information applies to memcpy, and I think I jumped the gun on making as much as possible 32 bit types.
Thanks for catching that! I'll remedy that line later this evening.
To my knowledge, most CPUs operate better on aligned data.
That would apply here, since memcpy most likely uses ints internally. (It should, in any case.) If the data starts out aligned, most reads will also be aligned.
You already take care of the alignment by using __attribute__((aligned(4))) on the declarations of your tiles, so it should all be good as-is.
IDK anything about GBA dev. But on x86_64, memcpy is traditionally implemented by copying 64-bit data until len / 8 == 0, and then copying the remaining bytes[0]. I suppose this is faster because accessing data with the proper cpu alignment is faster.
I'd contend that the in this day and age the most space efficient and fast way to implement memcpy on x86_64 is to "rep movsb", which triggers internal memcpy on the CPU anyway as per Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1 Section 7.3.9.3
That's the most straightforward and simple way, but it might not be the fastest due to the way caches work - look up the old Apple BlockMove() function for an example
Has anyone written a Unix-like OS that runs in a GBA? Maybe you could even build a cartidge with IO (keyboard support) and a simple com port for networking.
You wouldn't really even need to put the keyboard and serial port in the cart. The GBA already has the link cable, which could be used for serial data.
Nice. I have a GBA Micro and a development cartridge taking dust in a box, I might very well jump into this. Do you have a tutorial where you explain how to set up the development environment? Anyway I skimmed your tutorial here and it looks clear and fun!
Thanks! I think the feedback that I got last week on here was very good. Despite my initial desire to stick with the bitmap modes and try some 3Dish stuff, it really didn't make sense to try to learn new hardware by ignoring the most common use case.
