I guess it'll make more sense to do a source release if you're able to compile Apple Assault from the source, right ? That's where you'll need devkitpro, the open-source cross-compiling and core-libraries project for homebrew console development ... as it was back in October 2007. Sticking to a working -- but obsolete -- development kit helped me during 3 years to stay focus and work on my tools rather than doing pointless bugfixes, but now it's time to move on. I fear it won't be an easy task, though, as I use a custom ARM7 and so on ... Hopefully, again, the ease of branching with subversion should help a lot.
- gcc 4.5.1 râle sur
char * x = "hello"
et insiste pour qu'on aitconst char* x = "hello"
, histoire que la chaîne (normalement considérée comme une constante) ne puisse pas être altérée par le programme. Dans l'absolu il a raison et c'est facile (mais chaint) à corriger... d'autant (C++ oblige) que le code de la bibliothèque doit lui aussi être recompilé pour bénéficier de l'update :P IPC
n'existe plus ou a été modifié. Je m'en servais pour gérer la mise en veille de la console ... 'faudra trouver autre chose. Plus gênant, mon code custom pour le côté ARM7 devra sans doute être mis à jour lui aussi, et de manière substancielle.- SUB_DISPLAY_CR a été renommé, de même que BGx_CR, BGx_X0 et leur variantes SUB_xxx (pour assurer la cohérence avec GBAtek, ce qui n'est pas plus mal, soit dit en passant). Pas vraiment gênant pour l'exécutable lui-même, mais ça va être pénible pour la mise à jour de mes bibliothèques
L'alternative, c'est de fourguer libnds, libfat et dswifi précompilé dans le "package sources", mais ça me tente tout de suite moins :P
PS: "source setup-r32" parce que j'ai pris l'habitude d'avoir un script shell nommé "setup" à la racine de chaque projet qui configure toutes les variables d'environnements (CLASSPATH, LD_LIBRARY_PATH, CFLAGS, voire même PATH pour utiliser des cross-compilers) ce qui me permet d'utiliser la commande shell
source
pour "activer le mode OMNet++" ou "activer le mode devkitpro". En l'occurence, pour devkitpro, j'ai un setup-rxx
selon que je veux utiliser la release 19, 20, 21 ... ou maintenant 32.
One good news : transmission of input has been abstracted into inputGetAndSend() function from libnds/source/arm7/input.c ... it now uses the FIFO_SYSTEM rather than relying on a "shared area at a well-known location", which is (imho) a good thing as well ...
ReplyDeletekeysCurrent()&KEY_LID should be a possible alternative to IPC->buttons ...
ReplyDeleteWatch out : touchReadXY no longer has the same prototype...
consoleInitDefault is gone, and it looks like it allows me to prepare different console settings... to investigate.
ReplyDeleteexec.cpp made direct use of _io_dldi, which has been modified or somehow disappeared. to investigate as well.
ReplyDeletelibntxm and libppp weren't required to be updated to get a "booting" appleassault ... it's hanging somewhere before letting the game run, though, but I still have music playing.
ReplyDeleteIPC seems to be now __transferRegion :P
ReplyDeleteI spot references to __transferRegion()->buttons in system/initSystem.c, common/libnds_internal.h and arm9/keys.c (in the computation of KEYS_CUR that mixes touch&lid information of the ARM7 with the other keys that are available through the REG_KEYINPUT register on the ARM9)
I see #define transfer (*(__TransferRegion volatile *)(0x02FFF000)), while dkp-r21 used the transfer region @ 0x027FF000. I assume the only difference lies in some caching preference or MPU initial setting ... That would explain why my custom default ARM7 code still works :P
/beetle/hobby/DS/dsgametools/trunk/runMe/arm9/source/exec.cpp:47:24: warning: non-local variable 'const _FAT_disc_interfaces []' uses anonymous type
ReplyDelete/beetle/hobby/DS/dsgametools/trunk/runMe/arm9/source/exec.cpp:288:52: error: could not convert 'fatUnmount(_FAT_disc_interfaces[0].::name)' to 'bool'
I restored the return type of fatUnmount from void to bool.