want to alter the puck in Blades Of Steel - can't find it

Hello !

I guess some people here know the hockey-game Blades of Steel (Konami). If you don't, it's not important and you might still help us.

For an artistic project of some person I know, he needs to have the puck graphic modified.

We already tried to use classic softwares for sprite extractions ( Tile layer pro, tile molester), but, despite having spent hours trying and staring and enjoying a nice tapestry/world of 4-colors pixels, we haven't been able to spot it .

It just doesn't seem to be there....
That puzzles me. I see no reason for the puck not to be in the sprites section of the rom. We can see and modify easily the letters, numbers.
It fits without trouble in a 8x8 square, it is heavily used during the game and moving around and interacting a lot with the game, IMHO it *must* be a sprite.

My questions :

* Am I wrong in my assumptions (I guess I am...), and more importantly why ?
* How could we spot it ?
* How could we modify it ?

He is no nes hacker, and neither do I, but I may happily implement any solution involving programming (like a python script) in order to spot it out of the .nes rom .

There are some screenshots attached, two of the game,






and the puck itself.

According to NesCartDB, Blades of Steel uses CHR RAM. This means the ROM doesn't really have a "sprite section"; instead, the sprite graphics are copied from the main program section to video memory before being used. Some of the tricks that can be done with CHR RAM include compression of tile data, which lets everything fit in the 1 Mbit ROM, and obfuscation of tile data, which makes it harder for Chinese and Russian pirates to rip evidence of their infringement out of the game.

Yes, it's a sprite but the graphics in BoS are RLE compressed. I happened to take a look at this game a year ago.

You can use a Python tool from http://thefox.aspekt.fi/graveduck.py to decompress the tiles. You'll then need to apply the modifications, compress the tiles again, and put them back into the ROM. (I have slightly modified the linked Python script to fix a couple of bugs in the original.)

Since I was bored, I even took the time to find the file offset in which the gameplay sprites are, it's 49171. So you can use the following command to decompress the tiles:

Owww !

Thank you very much for the clues !

We thought that the gibberish we saw was somehow some code put in the graphic section. So it was compressed graphics.

I'll keep you informed on our progression.

This topic inspired me to finally create the wiki page about tile compression that I promised four years ago.

It worked extremely fine !

Thank you very much thefox and Nesdev community !


@thefox


How did you find the offset ?
We're now trying to find the title-screen tiles, I suspect they may be compressed too; not sure though.
I might also use my boredtime to find them

I can spare you the trouble, I already found the title screen tile offset when previously re'ing this game, it's 65932.

The way I found these was by looking at the (unpacked) tile memory in an emulator's PPU memory viewer, took some 4-5 byte pattern from there and searched for it in an hex editor. Then used some educated guesses to find out where the compressed data begins.

An even easier way (that requires 6502 asm knowledge, though) would probably be to set a breakpoint on reads from any compressed tile data, use that to locate the tile decompression routine, and set a breakpoint there. Then look at what parameters get passed to the routine.

Err. WOW ! ^^

I just can't find words to thank you again.



very clever.

I was about to generate possible patterns by looking at a screenshot, take a 8x8 square, and generate all combinations of the 3 different colours involved and then lot of work , and so on. xD



I'm curious, which ones ? spec of some sort ?

I just looked at the compressed data in hex editor and tried to match it up with the data in the PPU memory viewer based on how the compression algorithm works. Yet another way would be to take some decompressed tiles from the PPU memory viewer, compress them manually (or with graveduck), and then search for that compressed pattern in a hex editor.

mmok, I could definitely use the latter approach if I have to find other tiles (if there are still some of them you don't know where they are )

Which PPU viewer do you use (or emulator that provides that) ?

FCEUX and Nintendulator both work fine for that.

Just keep in mind that these techniques might not work with all compression formats... most RLE variants are simple enough that you can still find sections of the original data untouched in the compressed stream, but other forms of compression might make the data completely unrecognizable.

The simplicity of RLE also makes it easy for you to manually compress some data in order to look for its offset in the ROM, but other algorithms might be able to compress the same data in different ways, or even be too complex to simulate by hand.

The most effective method is indeed to use breakpoints and step through the decompression routine(s) to see where the data is being read from, and what kinds of transformations are being applied to it.