PypeBros wrote:What would the implication of an (accidental) extra call to irqInit() in that regards ? Iiuc, irqInit() is now part of the system initialisation code that is called before main(), right ? shouldn't it become a library-internal function to avoid chaos ?
Currently none of the interrupt handlers installed by the libnds startup code will work if you do that. I toyed with making it an internal function but there are situations where I want to override the startup initialisation and work with something a bit more bare metal.
I will give a more in-depth look at hbmenu and see to what extent it fits my needs. So far, having programs that were capable of retrieving an updated version of themselves and launch that version proved to be superior for comfortable development against uploading the .nds through a general-purpose program, come back to whatever menu and boot the uploaded program.
That's an interesting approach. I have a background in commercial game dev though so I've been used to uploading code to a devkit or debug station using tools made for that purpose. DSlink is part of the way towards something similar & I have plans to make it a lot better. Generally I tend towards avoiding specific development related features/code in games I'm working on - they take memory that may be needed by the game and add complexity which may have a detrimental effect on the game. Not that your approach is particularly awful, just something I might think about and then discard. If you already know there's an updated version of your binary then why bother with pulling from the DS when you can just as easily push from your dev box?
Maybe it will help you understanding the why (regardless of whether it's actually a good idea) if i tell you I am actually working on a sprite editor, a map editor and a game engine together that I prefer to keep as separate binaries so that they remain (imho) manageable projects.
Having sprite & map editors that run on the DS can be useful for getting colors right or even simply editing on the move. I'd probably integrate the sprite and map editors rather than having separate tools and maybe even keep them in the final game as a feature. Something that would probably be more useful would be overlays which I want to find the time to look at in the future.
How do you need to modify libnds for that?
I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions
Feel relieved: I have well understood that there is no such thing like "devkitpro-r32" outside of my own /home/pype/DS directory, and that's why I precisely pointed out the dswifi and libnds versions I use. Sorry if some of my posts made you think otherwise. I somehow do the software packaging into DS/dkp-r32 when I install all the latest version of the libraries together with dka-r32. I hope I'm not too much misunderstanding the way devkitPro project works when I assume that those libraries will work together better than if I upgrade libnds while keeping my old dswifi and randomly deciding to pick an intermediate libfat release.
Yeah, it's generally best to use the latest versions of the libraries and tools - they're mostly independent but there can be some issues caused by using random versions which haven't been tested together or where libfat/dswifi/maxmod have been updated for changes in libnds. libnds sometimes also depends on modifications made to devkitARM.
It's probably worth noting that devkitARM isn't specifically a DS toolchain but has been designed to be as generic as possible to allow writing code for a sizeable variety of ARM based machines and experimenter boards. I've been using it recently to play with code for the Cortex chip in SmartFusion FPGAs.
PS: sorry, I've found hbmenu quite easily, but where (or what) is dslink ? All I do found is information about a SLOT-1 linker (I already have a R4, and it was hard enough to acquire).
DSlink was the wifi uploader I created for sending code to a DSi -
http://davejmurphy.com/dsi-mode-homebrew-anyone/ It needs a bit more work to be generally useful but quite a few people have told me they're now using it as their default boot code for dev on DS. Right now it's closed source but that will change in the future - there are a few parts of the current source that should be integrated into libnds.
PypeBros wrote:WinterMute wrote:I'm also disappointed to see that you're still labouring under the misapprehension that devkitPro has versions - we're a toolchain vendor, not a software package.
That being said, the project could use some clearer presentation of the motivation, what we do / what we don't do, who could use what. E.g.
https://sourceforge.net/projects/devkitpro/files/ throws me tons of possible things to download, and at first glance, I wondered whether libogc would be an ogg/vorbis player, got surprised that the defaultArm failed to locate maxmod, etc. A quick reference sheet with one-line-per-console indicating which library is mandatory / recommended (useful for some examples, for instance) / not available / pointless (such as devkitppc for DS, obviously) for developing on some system could be a valuable hint for newcomers ... and respawning elders
The recommended way to install the toolchains on windows is using the devkitPro installer/updater which is linked from every update post in the announcements section. I also link to the getting started section on the wiki for devkitPPC/devkitARM as appropriate which lists the libraries.
Having said that, there is obviously a need for better documentation and more guides on DS programming - the rest of the consoles we program for too. The wiki needs a plan for population, I'm still not 100% sure on how best to present the wealth of information there is available. Any suggestions are much appreciated.
The motivation behind devkitPro was once to put together a halfway decent toolchain to mess around with GBA programming. Somewhere along the way that's mutated into making console homebrew as accessible as we possibly can.