 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| User | Post |
| Zeld Posts: 36/53 |
Making level editors and that sort of thing would probably be best kept with focus on the N64 version. However, from what I can understand about the N64 and NDS processors, reprogramming SM64DS with innovative assembly hacks would be much easier than on the N64.
Not sure if that matters much, since assembly hacking usually comes after editor making...or like, during editor making. Ah, whatever. |
| HyperHacker Posts: 4832/5072 |
I know the DS version's physics and envrionment work a bit differently. This should be fairly obvious already simply because the game feels a bit different and some slopes seem a bit more slippery, but bugs also allow you to verify. In some levels (possibly only Bob-omb Battlefield) you can shoot out of a cannon, aimed such that you hit a fence at just the right time, and you'll fly waaaaaaaay into the air. When this happens you're actually high enough that you can move outside of the level (use the map) so when you come down, you miss it entirely and die - you're above the invisible barriers that keep you from falling out of the world. In the N64 version this would never happen; you can use codes to fly up into the air, or force swimming (which for some reason starts you miles above the castle), and no matter how high you go you will never be able to pass these barriers. Walk-through-wall codes and at least one bug do allow you to get outside of them, but depending where you are, either the game freezes or you lose your hat and die, rather than simply falling and dying. |
| FreeDOS + Posts: 1188/1312 |
If the same level formats are used, why not? We could effectively have an editing application for both games if it's true; just support both compression formats. and with Nintendo DS, you don't have to worry about offsets, the filesystem used in most (all?) commercial games takes care of that for you. |
| Riku Posts: 1800/1823 |
I'm not sure we should look forward to hacking the DS version until we've mastered the 64.
I mean, we're closer and closer to further development, and looking to the DS editing now seems kind of... unrealistic. Not saying its impossible, but why begin something when we're barely in the doors to SM64 hacking? |
| Ailure Posts: 2512/2602 |
You must say that they did a good job porting it though. Super Mario 64 DS graphics looks better the original in some aspects, such as less overly bright colours and much nicer textures. Although then the orginal SM64 was quite simple even for a N64 game that didn't use the expansion RAM thing.
Nintendo have reused level formats in the past, they did in SMAS for example. There's nothing wrong with that really, especially if the remake tries to be accurate to the original, though SM64DS is probably the remake that differs the most from the original so far. |
| Yoronosuku Posts: 1161/1239 |
The sound engine used is also identical to the original, right down to internal names. I have a feeling that a lot of direct porting was involved. |
| FreeDOS + Posts: 1185/1312 |
Originally posted by Alice Well, they're usually distributed as cartridges themselves  Oh, you mean illegal copies, yeah, they're usually just bit-for-bit copies of the ROM; just like CD-ROM images (often misleadingly called "ISO", which carries two major misconceptions).
I've heard that Super Mario 64 DS uses the same level format as the original, when you uncompress it. I'm not sure about it, but it doesn't seem unlikely. Oh, and how do you know the code is cleaner, do you have the source code? Because the game itself doesn't show it; has as many bugs as the original. |
| HyperHacker Posts: 4828/5072 |
Well yes and no. DS ROMs do have a file system, but are probably distributed mostly as images of the cartridge (I've never downloaded one, so I don't know for sure). Just like ISOs are a single file, but are in fact just an image of a disc which presumably contains a filesystem. A program like ndstool can break it up into individual files and back again; these files have names and directory structures just like any other filesystem.
N64 games didn't have any form of filesystem; the term "MIO0 file" is somewhat misleading in this regard. They contain no directory structure, filenames, etc. MIO0 "files", when in the ROM, are just blocks of data like everything else; the only difference is they have a distinct header that allows one to easily locate them and copy them into separate files. The lack of a directory structure means you can't just scan a list, extract them with detailed names, screw around with them, and put them back in. You have to scan the entire ROM for instances of "MIO0", test the next 12 bytes to see if it's a valid MIO0 header, and extract it with some made up name (typically the ROM address it's found at). Also, the games reference them by ROM address, so you will have to update pointers to them if you aren't reinserting them in the same location. |
| Guy Perfect Posts: 436/451 |
DS ROMs are single files, but they include a header with a file table pointing to offsets in the ROM and associates them with filenames. Other things in the magical header include various checksums, game name, game icon (for the boot screen), etc. |
| Zeld Posts: 33/53 |
Easy? That sounds like an assembly hack, buddy. If I were able to debug an NDS, it might still be easy, but that's because I'm familiar with ARM. Even then it wouldn't just be "easy". I don't expect it to be, at least. I mean, even if there's just a simple modifier byte between the different types of jumps and a bit flag for who can wall jump, you wouldn't be able to find the addresses without reading a little assembly.
I think I may have downloaded this ROM. I don't recall it being in separate files. Maybe I didn't download it, but even if I haven't, the NDS ROMs I have downloaded all came in one piece. Does that mean the site I'm getting my ROMs from fails or something?  |
| iGod Posts: 40/40 |
I think a first, easy hack would be to give Luigi Yoshi's float kick and the wall jump, but reduce his speed. |
| Ailure Posts: 2507/2602 |
Originally posted by ztiksThough of course, trial and error gets more painful to do and you can't really use debugging tools on the real thing as well as on a emulator.Originally posted by jensthecomposer But there's always people out there who have enough patience to hack anyway. 
Heh, wouldn't the filesystem thing make it easier to hack? Since it's easier to figure out what files does what, than having everything as a giant blob. |
| Yoronosuku Posts: 1155/1239 |
The original was in seperate files....just MI0 files. The filesystem bit is true though... |
| Kyoufu Kawa Posts: 1334/1353 |
Originally posted by Raccoon SamAnd in seperate files too. In a file system, unlike the original. |
| Tanks Posts: 456/596 |
Originally posted by iGod That's all you can say 
How about start hacking it and show us what you can do since you came up with the idea... |
| iGod Posts: 39/40 |
Yep, flash carts are awesome. |
| Raccoon Sam Posts: 979/1040 |
As far as I know, the compression used is LZ77. |
| Simon Belmont Posts: 1510/1773 |
Originally posted by jensthecomposer It isn't unheard of you know. Alot of people use flash carts or SD cards to play games on their DS, also. |
| jensthecomposer Posts: 152/154 |
Hacking a game, we still can't emulate?? |
| iGod Posts: 37/40 |
I was playing SM64DS when I though about some thing : It's the same game, with a cleaner code, better graphics, and more features.So i made this board so new hacking progress would not mix with the Original game thread.
Now, who has messed with the ROM's code? |
