Gameboy Advance Development by Example: Drawing and Moving Sprites | Hacker News Reader

Gameboy Advance Development by Example: Drawing and Moving Sprites

kylehalladay.com

136 pointskhalladay21 comments

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 have one nitpick here:

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

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.

0: https://github.com/lattera/glibc/blob/master/string/memcpy.c...

I'd imagine that the GBA's memcpy works in a similar way.

In the tutorial, Kyle already aligns the array to 4 bytes, so using ints instead of chars really isn't doing much.

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

Last time I checked, the movs variants were microcoded slow path; you used SSE to get the fastest memcpy.

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

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.

Although, evidently ARM chips have an optimized code path for 4 byte aligned data: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... , I'm not sure if that would apply in this case or not?

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.

It's all weird. For example, GBA's VRAM doesn't even support byte access. You can only read and write 16 bits at a time.

For memory copies you'd use DMA controller anyway.

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.

Not "Unix-like", but Contiki 1 got ported: https://github.com/adamdunkels/contiki-1.x/tree/master/conti...

If I recall correctly, there was some work done on getting Linux running on the GBA. I think DSLinux started with that.

Yeah, there was this: http://www.kernelthread.com/publications/gbaunix/

It's of course severely limited due to the small amount of memory and lack of an MMU.

Enjoyable to see the youngsters discovering MOBs all over again. :-)

https://www.c64-wiki.com/wiki/Sprite

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!

I think the Tonc tutorials, which are linked to in the articles, go through all that.

Cool to see the follow-up based on feedback so quickly.

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.

Reply on news.ycombinator.com