11 March 2016 - Forum Rules
Started by Xenesis, December 07, 2014, 09:22:22 PM
Quote from: henke37 on December 08, 2014, 06:50:37 AMStrange, pretty much all ds games use the provided runtime that includes easy to use file I/O functionality.Anyway, which game in question are you talking about?
Quote from: FAST6191 on December 08, 2014, 07:23:11 AMHmm, there are plenty of games, including several Nintendo first party with NSMB being one of the more notable, that use file order/fileID rather than general names (in SDK parlance I think it was the fast file open function rather than standard file open and tends to see ndstool* rebuilt stuff break, hence tools like Nitro Explorer), and a few libraries (most notably the rad video one) do their own file handling, however I have not really heard of one described like that before. Mind you most people do not tend to investigate the file handler at any real level**, and if this is a Lua using/interpreted language game or one of those games that have their own archive format/filesystem on top of the standard one then who knows.If it is just that hardcoded ID stuff then I would say pick a tool like Nitro Explorer and spare yourself the aggravation of doing things here.*so ndstool, dslazy, dsbuff and possibly crystaltile2's rebuild functionality.**realistically the only people that ever would have would have been those hacking DS games to work on GBA slot/slot 2 flash carts (so later 2009 for the very last stuff people did), and as those never quite got around to sorting the rad video using games then even there they might have been lacking a bit.Afraid the only time I looked into these in depth was when we did not have a good DLDI based ROM dumper (so possibly 2006 or at latest early 2007) as the few occasions I do proper tracing work I tend to have the in game handler work well enough for my needs. I have done plenty with the DS file system itself, up to and including thinking about abusing the overlay system as a kind of file loader, but not really the hardware side of things so I would just be reading gbatek back to you at this point.Depending upon what you are doing you might get something from https://github.com/Dirbaio/NSMBCR/tree/master/source , particularly https://github.com/Dirbaio/NSMBCR/blob/master/source/soundThread.cpp and https://github.com/Dirbaio/NSMBCR/blob/master/source/wavplayer.cpp and you will also want to read http://nsmbhd.net/thread/1281-how-asm-hacks-are-setup-tutorial/The idea was that as the nitroSDK for the DS would remove library functionality if it was not used (in this case wave like strm support) if the game did not use it then Dirbaio added back in some wave streaming support. However that ends up compiled at some level so not ideal by any means.Also are you using the file system or sitting outside it? If you are going outside it then I would say make sure to change the size value in the header just in case someone tries to trim the patched ROM. I know they shouldn't do it but for the sake of changing a couple of bytes in a known location...
Quote from: henke37 on December 08, 2014, 11:30:11 AMOverlays are dynamically loaded.
Page created in 0.059 seconds with 19 queries.