 |
| 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. |
| Acmlm's Board - I3 Archive - ROM Hacking - An idea for ROM hacking |
New poll |  |  |
| Pages: 1 2 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Legendre Micro-Goomba                Since: 04-30-06 Last post: 6573 days Last view: 6573 days |
| ||
| Hi,
Here's an idea I've been thinking about which could really push the envelope in ROM hacking quite a bit. A protocol to get the emulator itself in on the action. The hacked ROM would have instructions to the emulator imbedded in a header, or somewhere else appropriate. Instructions like, "check (some memory offset) for updates". Then, at various times during gameplay, numbers would be written to that memory, at which point an emulator programmed to accomodate the protocol would respond appropriately. By putting appropriate numbers in that memory location, the ROM would effectively give "commands" to the emulator which could totally transcend what the ROM alone could do. For example, the ROM itself could include a number of .ips-patch type databanks, and could tell the emulator, "ok, at this time, apply this patch to me". With this sort of power, imagine what you could do. The drawback would obviously be that the game would only work correctly on emulators which support the protocol. How feasible would this be? I hope this generates some discussion and thought... Anyway, thanks for reading! |
|||
Stifu     Since: 11-18-05 From: Your mom's bed Last post: 6290 days Last view: 6288 days |
| ||
| I have no idea how feasible this idea is, but personally, I'd rather have ROM hacks work on real hardware... Also, emulators are everchanging, which doesn't help having a stable base for what you want to do. | |||
Dragonsbrethren   440  Since: 12-01-05 From: New Jersey Last post: 6475 days Last view: 6475 days |
| ||
| *Waits for Disch to show up*
What's the point of making a ROM hack if it's not even going to run on the hardware? That defeats the entire purpose, for me at least. |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6573 days Last view: 6573 days |
| ||
You guys actually upload hacked ROMs back onto cartridges and play them on the original systems? Wow, I had no idea.. that is very hardcore! I wish I could come over to your house and play Super Demo World on your SNES 
How does that even work? Do you overwrite cartridges or is it possible to buy blank ones? For, say, SNES. The protocol idea is only an idea. I always play hacked ROMs on emulators and it seems to me that the idea should be to make the changes by whatever means necessary. For example lets say you want to increase the number of party members in Chrono Trigger (by which I mean, people you can choose to be in your 3 person team). Geiger insists this is "impossible", well, it's technically possible since anything is in theory possible, but doing it with just ASM hacking would probably be harder than reprogramming CT from scratch. But with a protocol like I suggested, it would suddenly be realizable. Anyway, where can I read about this uploading hacked ROMs onto actual cartridges business? That is totally awesome! |
|||
|
C:/xkas bio.asm Compiled ASM code  Since: 11-17-05 Last post: 6289 days Last view: 6288 days |
| ||
| the main problem with your idea is that it is basicaly a lot of trouble for something you can do directly in the ROM ASM insted | |||
Squash Monster Bouncy Since: 11-18-05 From: Right next to myself. Last post: 6296 days Last view: 6289 days |
| ||
| The problem isn't that you can do it in ASM instead, and the problem isn't that you can't put it on the real system anymore.
The problem is that when you do something like that, you're not ROM hacking anymore. If you're going to use the limits of your computer rather than the limits of the system, why are you programming for that system? Why not just program for the computer? |
|||
|
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6290 days Last view: 6288 days |
| ||
| Legendre:
Flash cartridges can be bought there: http://www.tototek.com And here's a page about various SNES dumpers: http://www.emucamp.com/red/SNES/index.shtml The main problem with both SNES dumpers and flash carts: special chip games don't work, or a work around is needed (like having a real cart that has the needed chip). There are pages on the net that list pretty much all of the SNES games that use a special chip... Try to look for it if interested. |
|||
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6568 days Last view: 6568 days |
| ||
| I agree with all the reasons for opposing such an idea.
What people have to remember is that emulators are emulators. They're not game development tools. If you want to slap a game together, there are plenty of game dev tools available. And they all have far fewer restrictions than the limits imposed by the SNES and its emulators. |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6573 days Last view: 6573 days |
| ||
| Hey Stifu,
Thanks for those links, that really blew my mind and made my day!! How many of you guys do that, and how many just play hacked ROMs on emulator? Well, that pretty well shoots my idea full of holes. I still think it'd be cool to use the emulator's power to go beyond 255 kinds of items on FF3, or even mix games entirely (put a mario kart level in SMW), but not that much point if alot of people play using the actual hardware. Ah well, thanks for enlightening me. I know a guy who would really love one of these copier things for his birthday |
|||
|
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6290 days Last view: 6288 days |
| ||
| I doubt many of us have that kind of hardware, and even so, people aren't likely to use that kind of stuff for all the hacks... But only for hacks they know they like, or that they made themselves.
I have a Game Station (some kind of SNES with a CD-drive), but it's too annoying to use. I was thinking of buying a Game Doctor SF7 at some point, but changed my mind... (I'm working on a Super Mario Kart hack, and the game uses a special chip... So I need an add on to make the thing work, and tototek didn't have those anymore last time I checked) |
|||
BMF54123 Since: 11-18-05 From: MOOGLES Last post: 6288 days Last view: 6288 days |
| ||
| Personally, I don't have a problem with adding such features to a hack, provided it still works properly--and looks/sounds good--on real hardware. This obviously means you'd have to include some code that checks a hardware register for a certain value (one that always returns the same value on real hardware, but a different one in the modified emulator) and activates or deactivates the extra features accordingly.
I've been toying with the idea of adding a CD soundtrack (or perhaps MOD, using the BASS DLL) to Super Mario Odyssey, but my lack of C++/x86 ASM programming experience has prevented it from becoming much more than an idea. I recall some group a few years back added an MP3 soundtrack to one of the Golden Axe games using a modified version of MAME, and I don't believe there was a huge outcry over that. AFAIK, it still used the original ROMs, and thus still worked properly on real hardware. My idea wouldn't be much different. I realize there are plenty of game dev tools available, but what's the point in recreating SMW from scratch in an entirely different language if all I really want to do is add a soundtrack? (edited by BMF54123 on 04-30-06 05:34 PM) |
|||
Keitaro Mole Since: 11-18-05 From: Massachusetts Last post: 6446 days Last view: 6446 days |
| ||
But HOW exactly would that still work on the real system? As I recall, the SNES didn't have a CD-ROM drive (well, not just as I recall. It -dosn't-  ), and the SPC700 isn't remotly powerfull enough to handle CDA-esque audio...even if the game itself as a ROM works on the hardware, why have features at all designed only for the PC? The thing I find the absolute most fun abut ROM-Hacking is still making things work great within the absolute limits of the game hardware. Otherwise, as others have said, theres no point in hacking for that system, just make a game for your computer  |
|||
|
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6568 days Last view: 6568 days |
| ||
| Blah... BMF. This whole idea is preposterous.
I'm reminded of my XTREME Graphics NES demo -- you know, that gag I did a while back to poke fun at custom .pal file requirements in hacks. (Unfortunately the links in the thread have since gone bad -- so the gag won't be as funny anymore. But it basically was a special build of an NES emu which loaded and displayed PNG graphics which were appended to the end of the .nes file). Of course my tone with the gag is completely sarcastic. But to think you're proposing the exact same thing... only seriously... I dunno... it almost makes me want to hang my head in dismay. EDIT - To address something else you said, BMF:
This is just the thing that seperates your average ROM hacker from your average programmer. When you have the C++/whatever experience and ability... the whole "why even bother with the SNES at all" angle really sinks in. Building your own PC game based on an existing emu+ROM (which is really what you're doing -- at that point it's no longer ROM hacking) doesn't make much sense when you can build anything else you want. (edited by Disch on 04-30-06 06:54 PM) (edited by Disch on 04-30-06 06:58 PM) |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6573 days Last view: 6573 days |
| ||
| Here is a hypothetical example of something you could do by "thinking outside the ROM". Battle mode on Final Fantasy III. Fight your friends over the internet using your characters from the actual game (so this would be contained within the game proper, maybe at the Colloseum).
You could do this by creating a powerful protocol in an open source emulator like zsnes, or you could program FF3 entirely from first principles, which would take years no matter how good you are (after all, it's not like Squaresoft had one single person create it in the first place, and you have an even harder job since you want to duplicate it exactly). If you took the former option and created the protocol, it would still not be a one-sitting job, but it would be handleable, and when you were done, you could very easily apply it to other games. Doing this with pure ASM hacking would be a task of Herculean proportions. I'm not trying to argue everyone should start work on a protocol, I still concede you guys did a great job of showing me the light I'm just trying to say there can be a middle ground between changing box types in SMW and programming an original, SNES quality game from thin air.. |
|||
|
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6568 days Last view: 6568 days |
| ||
I'll bite
Originally posted by Legendre This is the point at which your idea goes awry. Programming a feature into an emulator isn't any easier than programming it into the ROM (provided you know what you're doing in either case). And I can only assume that by a "powerful protocol" you're expecting C/C++ to offer some miraculous solution to any gaming problem. Of course... that's not the case at all. The reality of the situation is... all you could really do in an emu in this case is put in netplay support. Which is already in existing emulators.
What you're proposing is INCREDIBLY game specific and would not be easily applied to ANY game. It would already be a great deal of work modifying FF3us to work this way -- AND modifying the emu to look for special case actions within FF3us. It would be equal amounts of work for every other game you want to "enhance". For something more generic -- like BMF's idea of background music -- that could be something that could be applied to several games without a ton of work involved each time. But this example is incredibly specific to FF3us.
I'm going to go out on a limb here and say you don't have any programming experience, so you don't really know how much work either route would be to take. The short answer is: asm is not any easier or harder than C/C++. They're all just programming languages. They all work the same. The only real difference is syntax. If you forsee this outrageously impossible task in asm -- it will be just as outrageously impossible in C/C++.
I think the best route to take for something like this example would be to just do a normal asm hack with FF3us and make a 2 player vs. fight. You could then use an emulators existing netplay support to play online, and you wouldn't have to do anything that would require any special emulator features. Trying to do something game-specific like this in an emulator is probably actually more difficult than just hacking the game in the usual fashion. And I can't imagine any situation where you'd have this effect and have the original ROM unmodified -- so either way you're going to have to make sustantial changes to the ROM. |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6573 days Last view: 6573 days |
| ||
| You've caught me red-handed about ASM experience, I have relatively little. I do have over a decade's experience in higher level languages, so that probably biases me in favor of an outside approach. Am I really THAT far deluded about ASM difficulty? I see people put SM3 bricks and icy fireballs into SMW and I am highly impressed, because it was done all in ASM with no sourcecode, but you seem to be trivializing this.
I'm honestly not trying to be a smartass, just trying to get clarification. Are you saying major surgical ROM changes, like adding a 2 player vs. mode to FF3, are doable in practice with pure ASM? (Bear in mind that FF3 actually has a very little-known 2 player feature, but it isn't vs. mode, rather it lets P2 control one half of the party-- so making a vs. mode would involve dealing with this too, either ripping it out completely or disabling it during the vs. mode) Originally posted by Disch Sorry, I think I gave the wrong impression in an attempt to keep things brief. I'm not talking about a protocol which is specifically shaped around FF3 but one with enough generic power to allow the following sort of scheme: - When certain battle is about to start, and the ROM communicates a command to the emulator, the emulator quickly applies an .ips-type chunk of data imbedded in the ROM, which changes the enemy monster's graphics to make it look like the formation controlled by the human opponent. At this point also the monster is set to have no AI attacks. - Similar event on the other side of the connection. Thus, behind the scenes, each human player's ROM treats that human as the party and the other human as a monster. - As each player enters commands, the commands are communicated between emulators and the emulators respond according to instructions contained in a high level script imbedded in the ROM. This script causes the "monster" (ie the enemy human's formation) to do the appropriate attack. This scheme has nothing specific about FF3. It needs: 1. A way for the ROM to tell the Emu to apply a patch in realtime; 2. A way for emulators to communicate; 3. A generic script language with enough power over the ROM to get monsters to perform given attacks. Once the protocol had the above 3 features, the rough "scheme" would easily generalize across games. All this machinery would be a little time consuming to do, but not overwhelmingly difficult. It seems to me that accomplishing the same sort of things for a single game in raw ASM would be far, far harder by contrast. But, like you point out, I am not a master of ASM
One thing I am having trouble understanding is, if ASM really is as easy as you are saying, how come most ROMHacks, codewise, are fairly minor? Not counting graphics/text/level editing, they usually only have small actual engine modifications. I'm not trying to trivialize all the great work everyone's done (which, let me say, really is impressive!!!), I'm just trying to reconcile your claims that major surgical changes to specific games in raw ASM are easier than creating a generic protocol in sourcecode. Please forgive me for making this post so long |
|||
|
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6568 days Last view: 6568 days |
| ||
Originally posted by Legendre Yes. Assembly is not difficult at all if you have existing programming fundamentals. All the concepts that apply to higher level languages apply just the same to assembly. If you understand variables, pointers, and basic programming fundamentals -- you can easily pick up any assembly language.
Well I don't mean to downplay the effort hacks like that take. While they do take a great deal of dedication and understanding -- they're hardly godly feats. With time and the proper tools (debuggers, traceloggers, RAM viewers) -- you will be able to isolate key areas in RAM and label them. Once you understand what is what in RAM, you can understand what the assembly is doing. So while you go in with having a big slop of uncommented, unlabeled would-be source... with time you'll be able to understand it as easily as any commented code. It just takes a little longer.
Not only am I saying it's doable. I'm saying it's far more practical than your suggestion. Yes you'll have to work around the existing 2 player mode. Yes it will require a lot of code removal, rewriting, and other crap. Yes it would be a big job. But yes -- it's very doable.
Well see what you're doing here is bringing it all back into the ROM anyway. "applying an .ips-type chunk" -- why not just have all that data right in the ROM from the get-go? Why not have that .ips chunk applies all the time? There's no need for an extra feature for selective IPS patching -- it doesn't make any sense. It would have the same effect to bypass a game's JMP instruction and have it jump somewhere else depending on X circumstances.
This is where things get INSANE complicated. You're basically suggesting that two emulators should stay in sync... while running DIFFERENT ROMs. I don't want to get into the details on why this is an incredibly difficult if not impossible feat. I mean it's hard enough for them to stay in sync running the same two ROMs identically. I can't tell you how many times I've netplayed with people only to have the game desync and ruin (though they probably got better about that in more recent versions of the emu). This one point of your plan definately won't work. I can't really explain how without getting into long and drawn out explainations of what emulators do and how clueless they really are. Besides... this is cart before the horse. You're proposing a two-player option -- but you're not going with the obvious solution of just putting in a second player. I dont' know why you think it'd be easier to have a net-play system built into FF3 -- but I can tell you right now it would be a nightmare.
I guess the emu-end portion isn't FF3 specific now that I understand it better. But let's look at your 3 requirements here: 1) As I mentioned before -- this is pointless. There's absolutely no reason to have a patch applied part of the time (unless it's user controlled or something). If you don't want the game to run X code --- just change it so it will jump to Y code instead. It's a suprisingly simple change in the ROM. All you need is free space (which, as I understand it, isn't hard to get on SNES games). 2) current netplay features in emus already supply this, but they only send button presses to the other emulator. 3) there's no reason to have a script and a VM for that script when the emu is already emulating a FULL ASSEMBLY LANGUAGE. Just use that assembly. Odds are it will be 10000x more powerful than any half-ass script you could come up with -- it's already supported in every emulator -- and the stuff you write with it can be placed seamlessly into the ROM.
The same reason there are a lot of programmers, but very few homebrew games popping up. Plus -- I know from my own experience -- when I acquired the skills to extensively hack games, I realized how silly it was, since it was far less restrictive and much easier to just do homebrew stuff instead of trying to work around someone else's code and work with insane system restrictions (I was working with the NES -- very very limited capabilities). I would wager most people with advanced skills just don't bother with ROM hacking any more. |
|||
|
Glyphodon Since: 11-18-05 Last post: 6329 days Last view: 6309 days |
| ||
| There's already a way for two emulators to communicate with each other. It's called zbattle.net.
ZSNES and SNES9x both have forms of netplay. That's SNES multiplayer like it's supposed to be used, through the 1 and 2 player ports. No incompatibilities are introduced and you can use the feature along with many existing SNES games. That's how it's done: make a feature that will be widely used, tested, and enjoyed. Don't make a feature for a couple of homebrew games that won't work in other emulators. Basically, I think Disch had it about right: Originally posted by Disch I wish Solar Soundtrack were here. It could put an end to this madness. Oh, and on a side note, BMF, if you ever decided to start a project written in C or whatever with only 3/4 the detail of SMO, it would be still be awesome. (I'd say half, but that's really pushing it.) |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6289 days Last view: 6289 days |
| ||
| I agree that emulators should try to emulate the hardware as close as possible and not add special features that aren't present on hardware, but with two exceptions:
1) If you add this feature to hardware, then there's no problem with adding it to emulators too. What I mean is just hacking ZSnes to allow ROMs to play CD audio files is cheating, but if you were to actually build a CD-ROM drive add-on for SNES so that this can be done on the real thing, then adding support for that to an emulator wouldn't be a problem. (So long as you post information so everyone can do it.) Although it'd still be best not to make your hacks require this add-on, as not everyone can solder or has spare parts. 2) Using emulator-only features for debugging is fine. Many emulators are capable of single-stepping execution, printing debug messages or halting as instructed by the ROM, etc. When your game depends on something that isn't there on the real system, that's one thing, but using extra features solely to debug is another thing entirely. Hell, the hardware most games are developed on has features not present on retail units. (Debugging DSes have double RAM and some other fancy features; most CD-based systems have hard disks or similar, etc.)
So to summarize: Adding extra features to debug: OK. Adding extra features that can be added to real hardware: OK. Adding extra features that aren't on a real system that your game depends on: Bad! Although in regard to BMF's music idea, with a lot of hacking, the SPC700 and an ordinary SNES can play near-CD-quality music IIRC. Just not from a CD. Although adding a CD-ROM drive to a SNES would be awesome... hmm... (edited by HyperMackerel on 04-30-06 11:11 PM) |
|||
MathOnNapkins 1100  In SPC700 HELL Since: 11-18-05 Last post: 6288 days Last view: 6288 days |
| ||
You know the SNES has an I/O port... hop to it.  |
| Pages: 1 2 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - An idea for ROM hacking |
| |
