>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
>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.