Graphics questions

[turd grasper]

Hi. I'm trying to hack The Flintstones - The Surprise at Dinosaur Peak and I've run into a problem. I'm using Tile Layer Pro to edit graphics and I've changed a lot, but there seem to be graphics that I'm not able to access. Since I can't reach these graphics with Tile Layer Pro, I'd like to know if I can access them with something else. I've read that Nesticle allows you to edit tiles in the emulator, but I can't seem to get it working. Are there any programs that have similar capabilities to Nesticle or can anyone help me get Nesticle working?

The game I'm trying to edit came out in 1993 and I'm wondering if maybe the reason I can't access the graphics is that it uses a technology or graphical format that wasn't standard to earlier games.

Thanks a lot.

[Maximum Potion]

They're probably compressed. Unless you can find some game specific documentation or utility, I doubt you'll be able to change them.

[turd grasper]

That's kind of unfortunate. Thanks for telling me though, I appreciate that.

[InVerse]

If you're using Windows XP or newer, regular Nesticle won't work unless you use DOS Box or another similar emulator. (In short, you emulate an old version of DOS and then run Nesticle within it.)

However, Nesticle95 (aka Nesticle for Windows) does work in Windows XP (I have no way of testing it in Vista or 7.) without any special requirements.

Here's the catch, though. In order to edit graphics using Nesticle, the ROM you want to edit has to contain VROM, which many games do not. How can you tell if a particular ROM has VROM? Open the ROM in Nesticle and select Write VROM. If you get a message saying "$K VROM WRITTEN TO $ROM" then you have a ROM with VROM. If you get a message saying "VROM DOES NOT EXIST" then, obviously, your ROM doesn't have VROM. (VROM was stored on a particular chip within the cartridge, so it's not something you can simply add to a ROM without doing some major league programming.) (Also, there's probably a method of determining if a ROM contains VROM or not by examining the header, but I don't know what to look for, myself.)

Now, on a happy note, I've already looked into Surprise At Dinosaur Peak and it does, in fact, contain VROM. If you want to try hacking those graphics with Nesticle, I suggest searching out Hacking Your Way To Super-Stardom With The NESticle Emulator by Astrocreep 2000 (aka AC2K). It's over 10 years old, but is probably one of the few documents that actually cover editing VROM with Nesticle.

It seems a bit odd (but certainly not impossible) that certain graphics would be compressed while others are not. Glancing at the ROM in TLP, I would be quite surprised if there was any compression in use. My guess is that whatever you're wanting to hack is probably just scrambled up enough to make it difficult to locate within the ROM. Of course, I could be wrong. Crack smoking seems to be a routine habit amongst video game programmers and it wouldn't be the strangest thing I've ever seen. (That would probably be the compression scheme I once hacked that actually took up more space than if the text was just left uncompressed to begin with.)

[Isildur]

(That would probably be the compression scheme I once hacked that actually took up more space than if the text was just left uncompressed to begin with.)

That's really odd. Was the game's decompression code perhaps originally optimized to decompress text in some other language (which of course would have different frequent character sequences), and perhaps when they translated the game's text to a new language for a foreign release, they changed the text but didn't bother to change the decompression algorithm's dictionary to take advantage of frequently recurring strings in the new language?

[Maximum Potion]

It seems a bit odd (but certainly not impossible) that certain graphics would be compressed while others are not.

I've seen it a few times before. Most notably in pokémon, the 151 pokémon + the different trainers are compressed.

[InVerse]

That's really odd. Was the game's decompression code perhaps originally optimized to decompress text in some other language (which of course would have different frequent character sequences), and perhaps when they translated the game's text to a new language for a foreign release, they changed the text but didn't bother to change the decompression algorithm's dictionary to take advantage of frequently recurring strings in the new language?

My theory is that the programmer was attempting to learn DTE and wasn't actually interested in conserving space. I base this on the fact that the DTE pairs consist of the text in the order it appears in the game, with a couple of pairs actually being used more than once. Also, said DTE was only utilized in the credits, all of the in-game text was completely uncompressed.

[turd grasper]

Thanks a lot for the replies, you all have been extremely helpful. I managed to get nesticle running and I'm working on the graphics through its tile editor. Also, to InVerse, yes, I am fairly positive that the sprites I'm looking for are compressed. I have edited every single sprite on the tile sheet and there are still a huge amount of graphics that have not changed. In fact, what's strangest is that only certain parts of the same sprite are accessible at all. I have Fred Flintstone running around with half a shirt on because only half of his sprite is on the tile sheet.

But yeah, thanks a lot, I really appreciate the help all of you.

[Isildur]

It seems a bit odd (but certainly not impossible) that certain graphics would be compressed while others are not.

That just reminded me-- I recall that when looking through the Chrono Trigger snes rom, I didn't see any non-compressed enemy graphics (other than Magus) but all the party members' sprites were not compressed.

[Reaper man]

From what I recall, the 16 bit sonic games had compressed and non compressed graphics.

[Shadow]

I have Fred Flintstone running around with half a shirt on because only half of his sprite is on the tile sheet.

But yeah, thanks a lot, I really appreciate the help all of you.

!!!

You say you see only half of his sprite? Well then the graphics are in multiple layers.
Okay. I assume that the "other" half is rendered the same way as the manipulated one. If that's true then you should be able to calculate the missing part. Well, sounds too easy, right? Give it a try.
You have to write down the missing pixels. Each pixel has corresponding hex value. Please don't forget "transparent" pixels. The sequence you receive can be found in the rom. If not there could be a compression. Then you have to find out which one was used.

Like all graphics there is a beginning and end of the sprite box. The usual formats are 16x16 or 32x32 pixel. So in the end you can look for complete graphic blocks.

In my active times I used the now clearly outdated "SNESEDIT" for everything. It was useful to find sprites in 1 Bit, 2 Bit, 4 Bit, 8 Bit modes.
I think programs nowadays can handle these modes by default.