It is currently Fri Dec 15, 2017 11:04 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Sun Feb 28, 2016 5:43 pm 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 547
Location: United States
Here's a simple request. I have a sprite with tiles I want to assign an existing palette to.

Here's the sprite I want to change:
Attachment:
hogan_gang.png
hogan_gang.png [ 1.19 KiB | Viewed 1876 times ]


Into this:
Attachment:
hogan_dk.png
hogan_dk.png [ 1.19 KiB | Viewed 1876 times ]

(where are the spoiler tags?!)

Anyway, the problem I have is that only one of the tiles uses white in its palette and I need the two tiles surrounding it and the tile above it to share the same palette:
Attachment:
hogan_tiles.png
hogan_tiles.png [ 1012 Bytes | Viewed 1876 times ]


The palettes are shared by other sprites, so altering them will ruin the other sprites that I've already worked on. :(

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 6:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
You'll have to debug the game to find out how this information is stored. A good starting point would be to see where in the OAM the relevant sprites are, and then set up a breakpoint for these specific slots in the shadow OAM (the page in RAM that gets copied to OAM by a sprite DMA).

Then, by looking at the code, you'll be able to see how the OAM entries are formed, and where sprie attributes and pattern indices come from. Hopefully it will be something straightforward, uncompressed data straight off the ROM, but it could also be coming from RAM, meaning it has been previously decompressed from ROM, in which case you'd have to set a breakpoint for that memory range, and keep going until you find where this data comes from.


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 7:38 pm 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 547
Location: United States
In FCEUXD SP, I found that changing the value in address 021A changes the palette to the tile on the left (one of the ones I need), but I hit a roadblock in trying to find the breakpoints.

I entered a 'write' breakpoint with address 021A with the condition "A == #22" (the value I think it normally is), but when the debugger comes back up, I can't find the address it loads from. :?

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 8:12 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5898
Location: Canada
Try using breakpoint in combination with trace log.

e.g. breakpoint on change to some RAM address, start running until breakpoint is hit, save the trace.

From there you can read the trace backward from the end to find where the data came from.


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 8:20 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Isn't FCEUXD SP old as fuck? Not that it matters here, I'm only saying there's hardly any reason to use that since FCEUX, which is slightly less outdated, has the same debugging features. Or is there anything I'm missing?


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 8:30 pm 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 547
Location: United States
tokumaru wrote:
Isn't FCEUXD SP old as fuck? Not that it matters here, I'm only saying there's hardly any reason to use that since FCEUX, which is slightly less outdated, has the same debugging features. Or is there anything I'm missing?

If there's a much better, up to date program, let me know.

rainwarrior wrote:
Try using breakpoint in combination with trace log.

e.g. breakpoint on change to some RAM address, start running until breakpoint is hit, save the trace.

From there you can read the trace backward from the end to find where the data came from.


Okay, I don't know how to do that. I see the Trace Logger, but I don't know how to read the data that comes from that.

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 9:13 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19347
Location: NE Indiana, USA (NTSC)
Jedi QuestMaster wrote:
tokumaru wrote:
Isn't FCEUXD SP old as fuck?

If there's a much better, up to date program, let me know.

Does the same behavior occur in version 2.2.2?


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 9:31 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5898
Location: Canada
Jedi QuestMaster wrote:
Okay, I don't know how to do that. I see the Trace Logger, but I don't know how to read the data that comes from that.

A trace log is a just a list of instructions that were executed, in the order that they happened.

Also on each line is some other data representing the current state, e.g. value currently in A/X/Y registers, status flags, etc.


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 9:55 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Jedi QuestMaster wrote:
If there's a much better, up to date program, let me know.

Like I said, FCEUX. Tepples linked to the latest version, which I believe is about 6 years newer than the latest FCEUXD SP.

Quote:
Okay, I don't know how to do that. I see the Trace Logger, but I don't know how to read the data that comes from that.

Open the CPU debugger an pause the CPU (click "step into"). Now open the trace logger and select "log to file" (I find it easier to use a proper text reader to view the fine than that awkward window), then click the "start logging" button. Now go back to the CPU debugger and set up the breakpoint for $0200-$02ff and click "run". I clicked "run" a few more times to catch a few writes to the OAM, so I could get a better overview of the process. Once you think you have enough just stop logging and open the file in a text editor. The are messages indicating where the breakpoints happened. I just did this and noticed a few things about Hogan's Alley:

1 - The X and Y coordinates come directly from a table, probably reused for all characters, and offsets are added to them so the sprites can move around the screen. The resulting Y coordinate is then decremented by 1, probably to compensate for sprites being delayed by 1 scanline.
2 - The attributes are read from ROM through a pointer at memory location $12. This pointer is probably changed for each character, so you have to see where it points to when the game is drawing the character you want to change and that will probably be the table you're looking for.
3 - The tile index also comes from the table pointed by $12, but it's read beforehand and goes through some processing before being written to the final location. Some values appear to have special meanings too (maybe things like "end of line"?).

So yeah, pay attention to $12 and try to see where it points to when the character you want to change is being processed. There you'll probably find a table of alternating tile indices and attributes.


Top
 Profile  
 
PostPosted: Sun Feb 28, 2016 10:01 pm 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 547
Location: United States
tokumaru wrote:
Jedi QuestMaster wrote:
2 - The attributes are read from ROM through a pointer at memory location $12. This pointer is probably changed for each character, so you have to see where it points to when the game is drawing the character you want to change and that will probably be the table you're looking for.

Ooh! Thanks. I'll go do this tomorrow after work, it's getting late.

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
PostPosted: Mon Feb 29, 2016 10:39 pm 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 547
Location: United States
I still can't figure out what's going on:

I found that memory addresses 0212, 021A, and 0222 affect the tiles I want to modify, but they all lead me to $0093, and so does 021E, which uses the palette I want to change the others to!

What is this sorcery?

Edit: Oh God! I think I found it.

Double Edit: I did it!
Attachment:
dk_color.png
dk_color.png [ 1.18 KiB | Viewed 1719 times ]


(by the way, that was my lame attempt at making a DK with the default colors. Now I just need to reinsert my old tiles)

Thanks everyone!

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
PostPosted: Wed Mar 02, 2016 5:56 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Jedi QuestMaster wrote:
Edit: Oh God! I think I found it.

Double Edit: I did it!
Attachment:
dk_color.png


(by the way, that was my lame attempt at making a DK with the default colors. Now I just need to reinsert my old tiles)

Thanks everyone!

Care to share?


Top
 Profile  
 
PostPosted: Thu Mar 03, 2016 1:03 pm 
Offline
User avatar

Joined: Thu Sep 07, 2006 1:08 pm
Posts: 547
Location: United States
Myask wrote:
Care to share?


Sure! https://www.youtube.com/watch?v=KzF1qbLpD9w

If you're talking about how I found the source address, I had to find what was modifying $0093 by values 01 and 02. I hit 'step into' until I found one, went to the address in rom, and was happy to find that changing it did what I was looking for. But... I saw that changing one tile would also change subsequent tiles next to it that shared the same palette, but I've played that game before and was able to configure it the way I needed (& with exactly the same number of bytes, thankfully).

_________________
Ruling the World One Bean™ at a Time...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group