devkitPro

This is incredibly misleading, new has zero advantages over malloc for standard memory allocation. The difference between malloc and new is that the latter calls constructors for instantiated objects and calls abort by default when memory is exhausted. Not quite what I was meaning. I wasn't ...

If you're just wanting direct access to the sub-engine then it can be done. I've got a test program that uses the main engine for 3D and I've experimented with using banks H and I for the sub-engine (there's just enough RAM there). Try something like: videoSetModeSub(MODE_5_2D); vramSetBankH(VRAM_H ...

If I were a betting man then my money would be on heap (or possibly stack) corruption. Toss in a bit of compiler optimisation and it's not surprising you're getting different results. It's quite likely that the first call to iprintf will push the value you've just assigned to alive onto the stack ...

Excellent - I didn't realise it had been set up to do that. In that case yes, that's a much better way than manually copying.

If you've just installed the devkitpro updater (the obvious download link) then you probably won't have it. You need to download the libnds source code, modify the files and then build it. Not sure if this link will work, but try http://sourceforge.net/project/showfiles.php?group_id=114505&package ...

Never used those functions myself, but you'd probably need to change the line to something like:
(i.e. take the reference to variable test2).

I think all is correct. If I only declare an array for the sprite and another one for pallette all works. But if i declare another array, the sprite is showed bad. Some colors disapears. Yes - but simply loading the palette information into an array isn't enough - you must be using some method to ...

When you declared the palette as u16 palette[256]; you've allocated it on the stack, when you used "new" you've allocating it on the heap. Both approaches should work - but if you're trying to load the palette into palette memory with dmaCopy then it won't work from the stack. It appears that stack ...

There's probably a good reason that passing a constant value worked (C++ function parameter overloading?) but linking with the maths library is normally the right approach anyway. If you're worried about speed then you could investigate the functions in trig_lut.h. You'd either need to use the acos ...

That's probably a good idea - but I don't think that call is actually called from anywhere at the moment. To be honest, there are other potential problems with the DynamicArray implementation. For example, code such as: DynamicArray *NewArray = new DynamicArray; DynamicArrayInit(NewArray, 16 ...