[keithisgood]

Hamburglar becomes a dragon? Wow he's serious now! XD

Yeah, I felt that the last level deserved a decent antagonist. Since it takes place in a lava-filled cave, who better than a dragon?

[Vanya]

Who is the Engineer? Kinda looks like radio host George Noory.

[keithisgood]

The Engineer is based on an actor's portrayal of a famous scientist; in the context of the game, The Engineer builds tricks for the Wizard.

[darkanx]

The Engineer is based on an actor's portrayal of a famous scientist; in the context of the game, The Engineer builds tricks for the Wizard.

Famous scientist? Am I right again in thinking... pre-cancer Walter White from Breaking Bad? X3  I thought that the minute I saw him, but Walter usually wears glasses, so didn't make a post asking. If so, you are doing a fantastic job with 8bit caricatures.

[keithisgood]

While it would be awesome for Walter to make an appearance, the Engineer is based on Nikola Tesla (as played by David Bowie in The Prestige). Source pic here: http://serbianna.com/blogs/savich/wp-content/uploads/2012/08/tesla1.jpg
September 28, 2012, 09:35:18 am - (Auto Merged - Double Posts are not allowed before 7 days.)More before and after artwork, this time a larger portrait of Hamburglar becoming the Dragon:


The graphics are done, so now comes the real work in figuring out the text compression.

Anyone with skill in this area would be greatly appreciated.

[MegaManJuno]

The Engineer is based on an actor's portrayal of a famous scientist; in the context of the game, The Engineer builds tricks for the Wizard.

I'm guessing Tesla (a la The Prestige)?

Edit: Nevermind... helps to read the full thread first. I see now that my assumption was correct.

[Vanya]

If that's supposed to be Tesla then his face needs to be more gaunt.

The Dragon looks great.

[keithisgood]

I realize it's not the greatest take on Tesla, but I figured I'll go with it for now, and once I figure out how to change text without learning copious amounts of ASM, I may go back and re-touch some graphics.
The sprite version looks a bit more Tesla-ish:




Right now I'm staring at the FCEUX Debugger like teenage me stared at the female body: very excited but absolutely zero clue how to work it.
October 06, 2012, 10:36:26 am - (Auto Merged - Double Posts are not allowed before 7 days.)Okay, so messing with FCEUX's debugger, I've discovered the following:

*All Cutscene text is loaded into RAM between addresses $6905 and $74C4
*Large chunks of Dialogue text are loaded into RAM starting at $6905, depending on which sprite you talk to.
*When Text is being written to the screen, each letter's tile data is called from RAM address $0343

I'm trying to figure out how to change the text called into RAM. I set a Write Breakpoint for $6DDB (the RAM address for the R in Ronald--the game's first text). It returned me the following debugger data:

07:E478:A5 A5     LDA $00A5 = #$52
07:E47A:91 9B     STA ($9B),Y @ $6DDB = #$52

$52 is the RAM value used for R, so this is the correct code. So, now I've got the end of the string, so to say, how do I follow this back to the ROM so as to change $52 (R) to $57 (W)? I realize this is probably to then find out how 52 is loaded into $00A5, but that RAM address seems to be a catch all for storing data. I set a breakpoint there and spent half an hour hitting RUN repeatedly without any of the game text loading. Is there a better way to see how 52 gets into $00A5 other than the FCEUX debugger?

[snarfblam]

It looks like it's copying from a buffer for decompression. Try using the trace logger. Log to a file, and when you break on the write to $6DDB, open up the trace log, and search backwards for writes to $A5. That should help you find the decompression routine, which should help you find the compressed text.

[keithisgood]

Thanks. I'm still getting the hang of FCEUX's various tools.

[Dwedit]

Wanna tell Gregg Tavares about that hack?  His website is at http://games.greggman.com/

[keithisgood]

Yeah, i'd actually used his article regarding the making of M.C. Kids to verify the text was indeed compressed. His post wondering why M.C. Kids was so poorly received is one of the reasons I took up this project; I figured the reason was all the blatant McDonalds product placement.   
 
I'd actually considered e-mailing him to ask what the text compression scheme was, but if I do e-mail him, it'll probably be after I'm done.

[Dwedit]

I'd guess something like Huffman, so it's probably not byte-aligned.

[keithisgood]

The more I dig in, it seems the less I know. I'm guessing from here on out, the progress with this is going to be measured in months rather than days while I learn enough about ASM to make the needed text changes.

[Trax]

I've played this game a few times in the past, and was always repulsed by the McDonald's theme. I gave it another, more serious try, and it's actually not bad. The controls are fluid, and I like the idea of finding hidden cards and the gravity reversal. By the way, Keithisgood, your replacement graphics are looking good...

I took a look at the code in the vicinity of 1E478, but nothing specific comes to mind. Do we have an idea of the location of the compressed text in the ROM?

[keithisgood]

Unfortunately I have zero clue at this point. I've tried to follow the thread back from the RAM loading with very little success thusfar. A few more work projects are sapping away free time, so I haven't had much time to crack the compression.

I agree fully the game is much, much better than most give it credit for. Solid controls and varied gameplay. For some reason, I feel like Mack should have some ledges cut into his high-top. couldn't figure out how to get the sprite right, though.

[DarkReaper]

Ive never played the original, but once you finish cleaning it up it warrants atleast a try 

[keithisgood]

Thanks. It's actually a very fun game.

[snarfblam]

Do we have an idea of the location of the compressed text in the ROM?

I hope I'm not explaining anything that's already figured out, but it looks like a block of compressed text is stored in the ballpark of $4AB0 in the rom (headered), banked to $AAA0. I'm not sure exactly where it starts.

Text is decompressed to ASCII. It is converted to pattern numbers after it is decompressed. Definitely not byte aligned, but one of the first things I noticed was changing one bit of the compressed text changes one bit of the decompressed text.

I had been watching how modifying the compressed text changes what shows up on the nametable, which is in retrospect obviously wrong since the pattern table isn't arranged by ASCII. So don't do that. It helped once I realized I should have been monitoring how changing compressed text affects the decompressed-text-buffer (kind of a pain in FCEU).

Looks like there are nine bits per character. It's generally hard to find the bits and pieces of text because, as mentioned, they aren't byte aligned. I found the "is " in "Ronald was showing off his Magic" at 4AB5. Each character took up eight bits, followed by an extra bit. I would guess the extra bit indicates whether there are more characters in a group (of what, I'm not sure). 4B2D is " in t" from "picnic in the meadow". That one confuses me a bit more. I can clearly make out and easily modify the mentioned letters in the stream. I can also modify some bits of the following "h", but there is no "0110 1000" in the stream so I'm not clear on what's going on there.

So that's definitely something. I think it would help a lot to get input from somebody with experience with text compression. For now I already have Ronald McDonald burned into my retinas, so I'm calling it a night.

[keithisgood]

That's miles beyond where I've gotten so far!  Although I don't have experience with compression schemes, I'll take a look at it once I finish work.