 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Geiger's Snes9x Debugger Mark 9 |
 |  |  |
| Pages: 1 2 3 4 5 6 7 8 9 10 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
Geiger Buster Beetle Level: 34  Posts: 290/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
| what do I do if my browser thinks that this is a text file? Is there a specific program I can open it with? Get the 7-zip utility which I linked on the first page. Until then, you should be able to just right-click and save. As for the Mario Kart bugs. It's surely a bug. You need to be more specific. I have already tested Mario Kart and found no problems. I do not have the time to play the game in its entirety. ----T.Geiger |
|||
dan Snap Dragon Level: 43  Posts: 423/782 EXP: 534516 For next: 30530 Since: 03-15-04 Since last post: 20 hours Last activity: 14 hours |
| ||
| I could get Super Mario Kart to start however, for me the debugging console appears, and I have to hit Run to get the game to start. However, I have an entire different problem. The input (specifically the directional keys) do not seem to register at all. I can set the controls up perfectly using the controller dialog, but when it comes to actually using them in-game they don't respond. At first, I thought it was my joypad, but I have the same problem with the keyboard too. | |||
Heian-794 Red Super Koopa Level: 44 Posts: 644/896 EXP: 611014 For next: 271 Since: 06-01-04 From: Kyoto, Japan Since last post: 21 days Last activity: 10 days |
| ||
| Thanks very much, Geiger. Off to download now! | |||
blackhole89 LOLSEALS Moderator of ROM hacking EmuNET IRC network admin Head GM of TwilightRO Level: 47  Posts: 548/971 EXP: 739208 For next: 26995 Since: 03-15-04 From: Dresden/Germany Since last post: 14 hours Last activity: 12 hours |
| ||
| Uh. You really hate ROM headers, don't you. (At least I got really shocked by the hateful dialogue box I received when trying to start an SMW ROM) I never saw anyone launching such a propaganda machinery (I can't find a different term for it) to exterminate 200 bytes of descriptive, useless and mostly non-hindering stuff. |
|||
jman2050 Red Koopa Level: 19 Posts: 77/123 EXP: 33172 For next: 2605 Since: 03-21-04 Since last post: 10 days Last activity: 103 days |
| ||
| Except that it's hindering to the creator of the tool. And really, if it's so useless and non-hindering, what do you need it for anyway? | |||
xZeaLitYx Cheep-cheep Level: 23  Posts: 81/199 EXP: 66932 For next: 791 Since: 04-13-04 Since last post: 1 day Last activity: 3 hours |
| ||
| Guess I'll announce it on the Compendium, though I believe every rom hacker who visits the site also goes here. Exceedingly fine. |
|||
|
Chickenlump Level: 41  Posts: 481/722 EXP: 474192 For next: 5953 Since: 03-15-04 From: Columbia City Indiana Since last post: 3 hours Last activity: 4 min. |
| ||
| One click of a button and no worries about the header. If a person needs to edit pointers and the like, no extra recalculations will be needed. Though I'm not going to condem anyone that feels that they want the dead space, useless bytes on their ROM, I will go ahead and mention that it's kind of pointless to keep complaining or even talking about it in this thread. It's been discussed, repeatedly. It's already been decided, and in the first post, it's been made clear that it's not going to change. Bug reports, feature suggestions, comments on the program itself, and other constructive chatter would probably benefit the program more. |
|||
Lenophis Super Koopa Level: 44  Posts: 369/830 EXP: 584360 For next: 26925 Since: 03-15-04 From: Duluth, MN Since last post: 4 hours Last activity: 3 hours |
| ||
Originally posted by jman2050  Jade accounts for another friggin rom in it's calculations...rom_array[offset + header + other variable] where: offset is the rom location based on a non-header header is $200 if the header is detected, otherwise it's 0 other variable would be anything (like if you are doing calculations in a loop for example) Is that example simple enough to understand?  |
|||
Parasyte Bullet Bill Level: 35  Posts: 293/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
| Here's how I see the header issue: The header is completely unneeded; likewise, removing it is equally unneeded. There is no hinderance with it being there or not. A requirement of removing any header is a hinderance and annoyance to the user. Not only that, but it also serves up a nice helping of confusion. Now about those issues I stated that I would mention. 1) Header removal does not work within compressed files. 2) The main window position is saved, which is nice. The debugger window position is not saved and tends to open right in the way, which is not nice. And without getting into aesthetics (requiring the debugger window to be open at all times, etc.), that's pretty much all of the annoyances I've noticed. Oh, and no offense, by the way. I don't want anyone breaking my balls for pointing out things I do not like. That seems to be the common reaction, these days. "If they don't like it, let's yell at them and tell them how much we don't care. That'll show them!" (edited by Parasyte on 02-13-05 05:12 AM) |
|||
|
Chickenlump Level: 41 Posts: 482/722 EXP: 474192 For next: 5953 Since: 03-15-04 From: Columbia City Indiana Since last post: 3 hours Last activity: 4 min. |
| ||
| Thanks for the article on Interleaving, Geiger. It was very interesting and informative. Quite technical too..heh... The debugging window being open at all times made me kind of leary at first as well, untill I realized that the games didnt' start untill you hit the 'Run' button on the debug window. If the debugging window werent shown all the time, I'm sure some users wouldn't be able to easily figure out how to get the games to start. Perhaps the window could be shown at startup, and closed at will, and reaccessed through a menu in Snes9x... |
|||
|
Geiger Buster Beetle Level: 34 Posts: 291/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
| Header removal does not work within compressed files. Actually, it does work, I just save the file uncompressed. Considering that there could be multiple things in the compressed archive, I decided it would be best to do it that way instead of overwriting or deleting it. The main window position is saved, which is nice. The debugger window position is not saved and tends to open right in the way, which is not nice. Yeah, I need to add in coordinate saving for the debugger and hex editor. requiring the debugger window to be open at all times I thought that one over pretty early on. Basically, I do not see the point in using this version of Snes9x unless you are going to use the debugger. I think it better that the user run regular Snes9x or ZSNES if they just want regular emulation. About the only feature you can actually use without the debugger window is tracing (Num-Div and Num-Mult should still work). Or is there another reason I am not seeing? ---T.Geiger |
|||
|
Lenophis Super Koopa Level: 44 Posts: 371/830 EXP: 584360 For next: 26925 Since: 03-15-04 From: Duluth, MN Since last post: 4 hours Last activity: 3 hours |
| ||
| OK, you probably hate my guts at this point. I'll just use the same attitude that you are currently using, which is "I don't care." But hear me out at least... On one side, you have the rom + header + whatever else there is. The header, as explained before is pretty much useless. That I agree with. So I can very easily see why it should be removed. The whole interleaving thing just seems odd. Although, how it still works based on what I can understand, is beyond me. I can also understand why that should be straightened up. What I don't like, however, is that I don't have the option to choose for myself. You're gonna be the next Bill Gates and FuSoYa if you keep this up. And speaking of Fu, LM has been added to the "you made x thing not usable because of your app." That brings the total up to three. Any other app that looks for the header and requires it is an automatic add. So, here's my lone suggestion for the debugger. Make the removing and de-interleaving an option for the user to choose, that is all. Also, barring the corrupt thing earlier, does the debugger actually write changes and save them back to the rom while emulating? If that is the case, you could add a second buffer/array which would actually be the one you edit and save so it emulates properly. The first will be the "undo" buffer/array so there isn't a chance of corruption. And if a user changed things that badly, maybe a prompt to save upon exit? *shrug* (edited by Lenophis on 02-13-05 08:37 AM) |
|||
|
Parasyte Bullet Bill Level: 35 Posts: 295/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
| Take note of the way in which I mentioned, "requiring the debugger window to be open at all times". It wasn't actually meant to receive any replies. But I guess that's up to you, since I did sort of bring it up. For the saving/potential corruption thing, I figure it should be handled the same way most other file-editing program does. Edit the file contents in memory, and save when the user explicitly commands a save. If it's already handled in that way, forgive me for suggesting it. |
|||
|
Geiger Buster Beetle Level: 34 Posts: 293/460 EXP: 241080 For next: 12571 Since: 03-15-04 From: Indianapolis, IN, USA Since last post: 6 hours Last activity: 6 hours |
| ||
| The whole interleaving thing just seems odd. Although, how it still works based on what I can understand, is beyond me. The article I mentioned a bit back is a good read on the subject. I strongly suggest going over it if you would like to understand what interleaving is all about. But in a nutshell, interleaving just means the ROM data is not in the proper order. does the debugger actually write changes and save them back to the rom while emulating? The edits made in the hex editor are live for the copy of the ROM in memory only. There is a Save ROM button on that window which will save the contents to file. The header removal / deinterleaving is prompted to save immediately. Choosing the wrong deinterleaving method (in the Open ROM dialog) is the item most likely to corrupt your ROM beyond use. That is not to say that the percentage is very high, but it does exist and is something to be wary of (hence my strong warning). ---T.Geiger |
|||
|
jman2050 Red Koopa Level: 19 Posts: 78/123 EXP: 33172 For next: 2605 Since: 03-21-04 Since last post: 10 days Last activity: 103 days |
| ||
| I don't know, perhaps I don't see the point in keeping the header if it is useless anyway. Pressing one button isn't a hinderence like an overly large GUI is, and seems like something very small to complain about. But anyway, besides that... Perhaps you can make the debugging window modular. It can be resized, thus not being a hinderence to those who want to move it out of the way, but it obscures a lot of options. Perhaps make two different possible forms that the debugger can be used in, the current large one and another smaller one with smaller butons and less of a thumbprint. A better implementation if possible would be to seperate different parts of the program into different windows. Tracing functions in one window, debugging options in another window, state viewing in another window, etc. Heck, you could even implement Sleuth's scheme, which basically seperates everything into different tabs. Of course, none of this came up during beta testing because it never occured to me people would complain about the debugging window. It's relatively small anyway, and if you miss something you can scroll up to view the stuff anyway. Heck, just right click->Select all and put it all in a file if you really need all the information there. But I guess some improvements can be made to the GUI. |
|||
|
Chickenlump Level: 41 Posts: 483/722 EXP: 474192 For next: 5953 Since: 03-15-04 From: Columbia City Indiana Since last post: 3 hours Last activity: 4 min. |
| ||
I actually like the idea of splitting the different features into a tabbed interface. Tracing in tab 1, debugging in tab 2, something like that. (I have an unnatural obsession with tabbed interfaces, they just rule...  )Anyone found anything cool yet with this? I just found this, it's Crono's current tech effect byte in memory. I'mma try to find out where it pulls this info from in the rom. It really should be the last bit of tech data for fully editable techs... 7E93F4 - Current Tech Modifier (use cyclone) changing this will cycle through every effect in the game (and there are alot of unused tech effects in here (try 72 with Magus Frog and Crono in the party... Such a cool looking triple tech...if only it weren't so buggy...  ) |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 3254/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Originally posted by Lenophis In LM's case, it's actually good. If it allowed you to use non-headered ROMs, there would be a lot of patch-related confusion with patches not working because you applied it to the wrong version. Even worse if it just added or removed the header automatically - the user probably wouldn't realize it and make a patch using the un-modified ROM as the original, resulting in the entire ROM being contained in the patch file. (Plus, it's gotta be a lot easier to write. Even if it's just "fseek(file,0x12345,SEEK_SET)" instead of "fseek(file,0x12345 + (0x200 * (int)HeaderPresent),SEEK_SET)", that's still more stuff you have to remember.) In an emulator, none of this applies, because presumably anyone smart enough to make something worthy of making a patch out of with the debugger would be smart enough to use the appropriate ROM as the origin if the emulator had added/removed a header (though you should make sure it tells that it's done so), and it doesn't need to do a bunch of random accesses to various bytes, just read/write the entire ROM into an array. (For that matter, it need not add or remove a header at all unless instructed to. Just skip the first 0x200 bytes when saving/loading the ROM if it has one.) |
|||
Ok Impala! Buzzy Beetle Level: 31 Posts: 269/383 EXP: 183070 For next: 2293 Since: 03-16-04 From: The Netherlands Since last post: 4 days Last activity: 23 hours |
| ||
| Ok! Mario Kart bug once again: - Start the game - Choose 50cc mode - Choose a player - Start Mushroom Cup - Voil |
|||
|
Parasyte Bullet Bill Level: 35 Posts: 298/514 EXP: 267348 For next: 12588 Since: 05-25-04 Since last post: 104 days Last activity: 32 days |
| ||
| I don't see how accounting for a header will make programming any more difficult, or the GUI (or any part of the program, for that matter) much larger. You need a read wrapper for SNES ROM mapping. So what's so difficult about adding "+ header" to your read wrapper? (Where 'header' is an integer containing the header size -- 0 or 512) I can also vouch for the Mario Kart bug: badkart.png |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 3275/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
 It looks like the game decompressed all the tracks and shrunk them way down. Weird... |
| Pages: 1 2 3 4 5 6 7 8 9 10 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Geiger's Snes9x Debugger Mark 9 |
| | |
