[killer dagger]

What I mean is... Is it a binary file or a text file,etc (which I know it's not)

[Disch]

it's a binary file.

It literally is just a dump/recording of all the 0's and 1's as they appeared on the ROM chips in SNES cartridges.

[henke37]

Or at least, that's what people think. In reality the emulator needs to know a little more about the data. Like say, how to map it into memory and what special chips the game cart had.

And that's ignoring the mangling that some copiers did.

[Disch]

Or at least, that's what people think.

Pretty sure that's all it is.

SNES ROMs don't have headers like NES ROMs do (or if they do, they're typically ignored), and there's no other data in the file.  Anything about mapping is inferred through analyzing the ROM data -- either by CRC or by probing the in-ROM description block.

[KingMike]

Official released SNES games had an official header format developed by Nintendo. Most of the time, emulators can use that information to tell how to run a game.
(though byuu has found that isn't accurate 100% of the time, which is why higan uses separate header files)

[killer dagger]

Ok, can someone give me a start or something on how I would make the background of the first level appear on a panel in visual basic 2010? I google everywhere and I can't find any source that would help me make a editor!

[Tirlititi]

Swing a magic staff. That's what we all do here.

[Disch]

I don't want to sound like a downer... but this is the kind of thing where... "if you have to ask how to do it, you probably can't do it".

I would say don't try to jump right into displaying levels.. and instead start with smaller things to get some basics down.  Once you understand the basics more clearly, then it will gradually become clear how to deal with level data.

Loading things like enemy stats, or even string data is easier than level data.  So maybe start there.

Then maybe try loading some graphics from the ROM and displaying those.

Then after that it should become clear what kind of work dealing with level data will entail.


It's hard to give real details without knowing what game you're working with.

[tero]

Ok, can someone give me a start or something on how I would make the background of the first level appear on a panel in visual basic 2010? I google everywhere and I can't find any source that would help me make a editor!

Firstly, you probably won't be able to get away with using Visual Basic to do this; you need a more solid understanding of programming in general to be able to do this. Making the background of the first level appear is probably not even the hardest part.

The process would probably go:
 1. Getting the Tile Map in individual images so they can be rendered individually side by side using a PictureBox (Horrible method, don't get me started).
 2. Coding the display mechanism, which will have to grab level data from inside the ROM itself (complex) or by using a configuration or level file that is separate.
 3. User Input coding, you need to be able to get mouse events and keyboard events to do things, then store the modified data in an array or List<>.
 4. Saving, would require knowledge in file formats (I/O) and probably if you want functionality within the ROM itself, you need extensive knowledge about how to insert the level data into there.

So, in other words: Study study study!!

[killer dagger]

I'm trying to study, study, study. But I could try smaller stuff first... Ok now How do I add the graphics to a panel box. I got an Idea how to do all of it but, I really don't know how to say type it out in the code. I'm sorry if I'm a pain of the ass though.

[Disch]

I don't know VB or .net well enough to guide you through that end of it... but you'll need pixel-level control of the image (that is, you'll need to be able to set the color of individual pixels).

From there, you'll need 2 things from the ROM:

1)  The graphics
2)  The palettes


The graphics are stored as bitplanes, so you'll probably use 2-4 bytes to generate a row of 8 pixels, where each pixel has a value between 0-15

You then use that value as an index to the palette to get the actual RGB color to output.



But again it's hard to get into specifics without knowing what game you're working on.  You still haven't said.



(Also, don't mind what tero said about VB -- you can absolutely do this kind of thing in VB)

[Jorpho]

Ok now How do I add the graphics to a panel box.

I'm not sure how a "panel box" works, but your first step should be worrying about how to write the graphics to an image file (like BMP or PNG).

I got an Idea how to do all of it but, I really don't know how to say type it out in the code. I'm sorry if I'm a pain of the ass though.

Yes, coding is hard.

[GHANMI]

You could do simple experimentation stuff.

Changing text. Changing length of text. Editing graphics. Editing the timer value. Your starting values for HP / Lives / Timer. That first enemy in the level.
You try to figure out what those bytes in the hex editor do, and what happens if you change them.
Which one affects what thing.
Some people do RAM/ROM maps documenting extensively the memory this way (you might want to try looking for cheat codes if you want to familiarize yourself with this in an enjoyable fashion - you might even stumble on a forgotten debug routine that does nifty stuff!)
Some of it is experimentation. Some is figured out better by studying assembly routines while the game executes code on the fly (like, how the game builds the levels.. though it's not really required often)

This might sound crazy, but you could find yourself enjoying this so much you end up recreating a tilemap by hand, byte-by-byte (I'm this crazy, but probably not alone in this).
Of course, doing stuff by hand is tiresome. So when you figure out the way the game stores stuff well enough you can do it by hand and your experiments are successful, you can later code some tool to automate that process for you.

If you want none of the fun of the experimentation part and just the C++ tool, then you need some sort of magic wand to achieve that effect.

[killer dagger]

thank you everyone for helping and guiding me I will try all of your ideals to figure this out but one more thing is a the data in a rom is store in a database?

[Disch]

is a the data in a rom is store in a database?

Nope.

The way the data is stored varies from game to game.

There are a few formats for some data (like graphics) that persist between games, but for the most part each game does everything differently.

[killer dagger]

ok why don't we practice on something small like this:



how would I add lives into super mario world, how would I do this! 
than when we do this togather I can post this as a example in the documents to help other people with visual basic

[Disch]

Before you can write an editor to hack a ROM, you must first know how to hack a ROM yourself.  I would suggest you figure out how to do this by hand (with a hex editor) first.  Then once you can do it that way, it should be obvious how to write an editor to do it.


Do you mean the number of lives the player starts with?

IIRC you start that game with 5 lives.  This means that more than likely, there is a '05' byte that exists in the ROM to determine the number of starting lives.  You'd need to figure out which byte that is.  This can be done several different ways.

- Use a file corruption tool to change all '05's in a portion of the ROM to some other value, then run the game to see if the number of lives changes.  Then narrow the range down appropriately until you figure out exactly which byte determines how many lives you start with.

or

- Do a CPU trace and examine the in-game code to find out where/how the program is setting the starting lives (I don't recommend this as it's probably overkill for this small hack -- and would be particularly difficult for a newbie)

or

- Since everything about SMW is pretty much already discovered, look at an existing source (like this page:  http://www.smwcentral.net/?p=map&type=rom ) to find that the starting lives is at offset 0x02025 in a headered ROM.




Once you find this value... changing it "by hand" means getting a hex editor (I really like HxD:  http://mh-nexus.de/en/hxd/ ), going to the desired offset, and changing the value.

Making an editor that changes this value involves opening the file (as binary, not as text), seeking to the desired offset, reading the byte (if you want to display it's original value), or writing it (if you want to change it), then closing the file.

[killer dagger]

I got the ideal how to do it or how it works but I don't know how to code it out I need a source code or a example

[henke37]

Code: [Select]

function changeStartingLives(rom:ByteArray,startingLives:uint):void {
rom.position=0x02025;
rom.writeUnsignedInt(startingLives);
}

[Seihen]

Code: [Select]

function changeStartingLives(rom:ByteArray,startingLives:uint):void {
rom.position=0x02025;
rom.writeUnsignedInt(startingLives);
}

Just out of curiosity, but is there any reason why we're using integers? I admit I haven't taken a look at the Mario World code, but I was thinking that 10 lives would be represented by A and not by 10. Then again, since the max number of lives is 99, I guess it'd make sense that they just represented it that way...