Building Animanatee problem

[strat]

I thought about adding an image-loading feature to Animanatee so it will display on the background layer and you can draw over it on the onion layer. Before analyzing the code, I wanted to make sure it would readily build on Release 41. It would build after removing the -fno-fpu option and changing 'diropen' to 'opendir' (Things that have been covered on here already), but it's 301k and just crashes on the hardware while the binary released by Dekutree is 277k and works. But those are the only changes to the source - should they account for the bad build?

[elhobbs]

It depends on how old the toolkit was used to build it. Make sure irqinit is not called on arm9 and that it is not using custom FIFO code. Also if there is any asm then the functions will need a .type identifier. Those are just the ones I off the top of my head.

[strat]

Well, it builds just fine on an older release of devkit so I'll stick with that.

[Izhido]

A pity. We generally support only the latest release of the toolchains; by sticking to an older release, you will find it's going to become harder and harder to get questions answered about your choice of tools.

Let me encourage you to do a more thorough analysis in the code you're working on; you might be surprised to find things that were originally tolerated on older versions, but that are no longer legal in the latest release.

[strat]

Well, I found something. In GameInit() from Game.c, an array of pointers, gGameGlobals.uncompLayer was accessed before the pointers were initialized with malloc. Having fixed that, Animanatee will start up like normal after building with release 41 (before nothing would show up) only now it crashes when attempting to draw with the stylus. As a bonus, it also boots on Desmume (No build would start on an emulator, even from an older devkit) and crashes at the same place.

There's still at least one more bug to find before this will build correctly. And I still don't understand how the older devkit built something that would bypass the null pointer.

[strat]

Now it turns out the drawing code fails because the buffer for the undo image is not allocated. On DrawMenu.c ln 113 it attempts to allocate menuVars.undoUncompLayer and returns a null pointer (Confirmed with a console debug). I've been searching the forum and Google for clues as to why malloc is failing and it must be an alignment problem? Maybe I'll resort to statically allocating all the arrays.

[elhobbs]

it may be the simplest reason of all - not enough free memory. the ds only has 4 MB of memory for code and data.

sometimes you can squeak past these issues on the ds when you are updating an older project by reodering mallocs so that big objects are allocated before any little objects - it helps with fragmentation. the newer newlib and libnds are a little bigger than previous versions. I would imagine statically declaring them would have much the same effect.

[strat]

DekuTree64 wrapped the malloc and free calls in functions that keep track of how many bytes are allocated, and where the app crashes there should only be 256 kB used up. Also, the linker will yell at you if memory is statically used up, right?

This might be worth trying out (Use the Wayback machine for his own site)
http://www.gamasutra.com/view/feature/1 ... hp?print=1

[elhobbs]

yes, the linker will complain if the static data is too big. do you know how much memory it is trying to allocate when it fails? it could be a corrupt/bad/unreasonable value.