Author
|
Topic: how do change sprite colors in these games? (Read 2 times)
|
gracik
Guest
|
 |
« on: February 01, 2009, 12:50:47 am » |
|
how would i be able to change the color of the spirtes in mutant league football (sega) or in The Ignition Factor (snes) ?
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #1 on: February 01, 2009, 01:02:17 am » |
|
That depends.
If the colors you want to use are already used by the sprite, then all you have to do is open up the ROM in the tile editor of your choice (woe be unto you if the graphics are compressed - that's a tutorial for another time, and another skill level for that matter) and edit the sprites to use the color scheme you want. You can change the editor's palette from the default colors to something matching the sprite's in-game palette, if you like.
If they're not, you'll have to hack the palette. (The upside of this is that you can change the colors even if the graphics data is compressed.)
I don't know of any Genesis emulators with debugging functions off the top of my head, but in the case of a SNES ROM, the data you're looking for is in CGRAM. You can find this data in a savestate using VSNES. Once you've found the data corresponding to the palette you want to hack, you can search for it in the ROM using a hex editor.
IIRC, SNES palette data is stored in 555 little-endian format - that is, least-significant byte first, five bits per color. I might be wrong about the endianness, though.
|
|
|
|
|
gracik
Guest
|
|
« Reply #2 on: February 01, 2009, 01:10:38 am » |
|
well mutant league football can't be viewed in tile editor, so its compressed right? im checking the other game i mentioned at the moment.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #3 on: February 01, 2009, 01:40:14 am » |
|
Are you viewing the ROM in Genesis format (4bpp linear)? Also, be aware that the graphics won't look exactly as they do in the game: they'll be displayed using the editor's default palette, since the program has no way of knowing where the palette data in the ROM is.
|
|
|
|
|
gracik
Guest
|
|
« Reply #4 on: February 01, 2009, 01:54:07 am » |
|
I mean that tile editor won't open mutant league football at all. I noticed how the graphics looked when I opened up
Ignition factor in it. But it's sort of hard to make out that perticular games graphics in tile editor.
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #5 on: February 01, 2009, 02:09:24 am » |
|
Which tile editor are you using? TLP and Tile Molester are probably the most popular/common/useful ones.
|
|
|
|
|
InVerse
Guest
|
|
« Reply #6 on: February 01, 2009, 10:34:27 am » |
|
Is your ROM in .bin format? If it's in .smd format, you'll need to convert it to a .bin before the graphics will be viewable.
|
|
|
|
|
gracik
Guest
|
|
« Reply #7 on: February 01, 2009, 12:54:07 pm » |
|
Its in .bin format and the program i'm using is tile editor pro.
|
|
|
|
|
InVerse
Guest
|
|
« Reply #8 on: February 01, 2009, 01:38:24 pm » |
|
I just glanced at Mutant League Football in Tile Molester and the graphics seem to be uncompressed to me. Just switch to the 4BPP Linear codec and scroll down to 0xF200. I've never heard of Tile Editor Pro, are you sure you don't mean Tile Layer Pro?
|
|
|
|
|
Moulinoski
Guest
|
|
« Reply #9 on: February 01, 2009, 02:10:25 pm » |
|
IIRC, SNES palette data is stored in 555 little-endian format - that is, least-significant byte first, five bits per color. I might be wrong about the endianness, though.
I asked myself "What's a least-significant byte?" and so I googled it and found this: In computing, the least significant bit (lsb) is the bit position in a binary integer giving the units value, that is, determining whether the number is even or odd. The lsb is sometimes referred to as the right-most bit, due to the convention in positional notation of writing less significant digits further to the right. It is analogous to the least significant digit of a decimal integer, which is the digit in the ones (right-most) position.[1]
In referencing specific bits within a binary number, it is common to assign each bit a bit number, ranging from zero upwards to one less than the number of bits in the number. However, the order used for this assignment may be in either direction (see Endianness). Both orderings are used (in different contexts), which is why "lsb" is often used to designate the units bit instead of a bit number, which has the potential for confusion.
By extension, the least significant bits (plural) are the bits of the number closest to, and including, the lsb.
The least significant bits have the useful property of changing rapidly if the number changes even slightly. For example, if 1 (binary 00000001) is added to 3 (binary 00000011), the result will be 4 (binary 00000100) and three of the least significant bits will change (011 to 100). By contrast, the three most significant bits stay unchanged (000 to 000).
Least significant bits are frequently employed in pseudorandom number generators, hash functions and checksums.
LSB, in all capitals, can also stand for "Least Significant Byte". The meaning is parallel to the above: it is the byte (or octet) in that position of a multi-byte number which has the least potential value. But I kinda still don't understand too well (the bolded part, which I guess is the relevant part) As for Endianness (which I also did not know what it is), is it basically like "an address" of some sort? I don't mean to steal the thread but this is really new terminology to me, though... And it may help the OP. |
|
|
|
|
Ryusui
Guest
|
|
« Reply #10 on: February 01, 2009, 02:38:38 pm » |
|
Yeah, endianness is one of those things that had me confused for a while, but I think I've got it straight now. ^_^;
The terminology comes from Gulliver's Travels, where in Lilliput there's a great big political schism over which end of the egg should be broken first. There's the Little-Endians, who believe the small end should be broken first (a doctrine established after someone hurt his finger opening the big end), and the Big-Endian rebels, who the Little-Endians really do not like.
Now that I've got that wholly irrelevant explanation out of the way, what we're referring to is not eggs, but numbers. In big-endian format, numbers are stored with the Most Significant Byte, or MSB (the big end), first. This is more intuitive for human-readability, since this means that $DEADBEEF is stored in that order (that is, if you look at it in the ROM or an emulator's memory viewer, it will appear as DE AD BE EF) but not so much for computers, where reading the data in the opposite order - little-endian - makes more sense. In little-endian format, the MSB is stored last and the Least Significant Byte, or LSB (the little end) is stored first. So $DEADBEEF appears in the ROM and memory viewers as EF BE AD DE.
|
|
|
|
|
GenoBlast
Guest
|
|
« Reply #11 on: February 01, 2009, 03:18:32 pm » |
|
That's interesting about the origin of the term! I never knew that. As for the explanation, I think I can explain it in simpler terms: - Big-Endian is the way we normally read numbers. The biggest digit is on the left.
- When you see "65500" you know that the first digit (6) is the biggest digit, which in this case is the ten-thousands place.
- When you see "FF DC", the first byte is the biggest byte, which in this case is the 0x100's (or 256's) place. So it equals 65500.
- Little-Endian is written the opposite way. The littlest digit is on the left. For hex, this means the bytes are in backwards order.
- When you see "FF DC", the first byte is the smallest byte (the ones place). So it equals 56575.
- "00 55 AA FF" in Little-Endian would be "FF AA 55 00" in Big-Endian. It equals 4289352960.
|
|
|
|
|
Moulinoski
Guest
|
|
« Reply #12 on: February 01, 2009, 03:40:06 pm » |
|
I've seen this type of "0x100" thing before. So that's just another notation?
I get the endian thing alot more now though. And bytes are written in doubles? (like one byte can be FF, 55, whatever; even something like EF or 3A?)
Thanks!
|
|
|
|
|
Ryusui
Guest
|
|
« Reply #13 on: February 01, 2009, 03:42:51 pm » |
|
Yes, bytes are written in doubles. There's a reason why hex is used as opposed to plain decimal: the highest 2-digit hex number, FF, happens to be the highest possible value for a single byte (255).
|
|
|
|
|
creaothceann
Guest
|
|
« Reply #14 on: February 01, 2009, 07:06:49 pm » |
|
I've seen this type of "0x100" thing before. So that's just another notation?
It's how hexadecimal notation is done in programming languages. "0x?" = C/C++ and the like "$?" = Pascal, some assemblers "%?" = URLs (e.g. %20 = ASCII character 32 = " ") "?h" = ASM code ("?b" would be binary) See http://en.wikipedia.org/wiki/Hexadecimal for more. IMO big-endian is only useful when you want to read values directly in a hex editor's data display, and a decent hex editor should also have a data interpreter. |
|
|
|
|
|
RHDN Forum Archive
