 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,487,434 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-26-24 12:42 PM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 2 guests |
| Main - ROM Hacking - Mega Man Powered Up to NES Project | New thread | New reply |
| NetSplit |
| ||
|
Level: 32 Posts: 129/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
You'll need to write a routine that runs only on the title screen that puts the necessary sprite information into sprite RAM (typically 200-2FF). It could be as simple as finding a spot that's only run on the title screen and then loading the values and placing them in the right spots. Doing it a tile at a time without any looping might take up too much space, though; you should be able to condense it down using a loop and a few tables.
I think it's time to start picking up some assembly.  |
| RetroRain |
| ||
 Fuzz Ball Level: 66 Posts: 278/994 EXP: 2438204 Next: 23647 Since: 09-30-07 Last post: 1935 days Last view: 957 days |
This one is better.
How come you made him ice blue like that? 
And I agree with NetSplit. You should do the hard ASM coding first. If you can't do the ASM, then all of this easy stuff is going to waste. That's why I coded my engine for MMFL first, before really getting into the graphics work. ____________________ My YouTube Channel |
| koala_knight |
| ||
 Buzzy Beetle Level: 44 Posts: 164/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
Posted by NetSplit Indeed, my friend, indeed. Learning 6502 ASM was one of the reasons I wanted to do this hack so here I go! It looks like what I need to do in this case is pretty simple, though. I'm thinking that I'm going to need to locate the code for the title screen and insert a jump to my custom code? =) Posted by Logical Operand The first one is a mock up and the ice-blue one is supposed to be a shadowy representation. What do you think of this one? It just needs the face sprite to be inserted:  |
| NetSplit |
| ||
|
Level: 32 Posts: 130/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
I prefer the colors in the old screenshot, and I think you went overboard with the copyrights in the new one (furthermore, I feel that putting a copyright symbol next to your credit on an unauthorized use of someone's intellectual property is bizarre, at best).
If I were you, I'd figure out where the code is for the arrow sprite (#$86) that's onscreen, since that's drawn at the very start and seems to not show up when the title screen begins fading in exclusively because its palette is #$16 (2x palettes appear before 1x, and 1x before 0x). That's a reliable place to put the new code. Find it (easy), jump from there to some free space in the same bank, and put your routine. |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 165/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
Posted by NetSplit That was supposed to be an 'H' in a circle. =P
Now that I know what the sprite number is for the arrow I actually have something to work with! Thanks for the info! =) |
| NetSplit |
| ||
|
Level: 32 Posts: 131/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
Assuming you're using some variant of FCEUXD (you basically need to be for effective assembly hacking on this system) or even (god forbid) NESticle, you can find that arrow tile easily by looking at the sprite pattern tables in the PPU Viewer for it. Anyone with eyesight can find it; it doesn't take any special knowledge. If you wind up having questions, feel free to ask, but definitely give it a shot first and see how far you can go.  |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 167/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
But would the tile number equate to the sprite number in this case? From what I understand the way MM5 works it would have to have unique sprite ID's for every sprite in the game since it basically can use any sprite anywhere...
But then again if I search for the tile ID it should lead me to the same code that calls the sprite anyway, right? I read up on 6502 basics which the same 65c02 basics I already knew minus some opcodes. I do have the latest version of FCEUXD and SP. That's what I was planning to use to find the code I need to hijack. Thanks for the offer! If I run into any difficulties I'll make sure to ask! =) |
| NetSplit |
| ||
|
Level: 32 Posts: 132/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
I don't know much about the later MM games (I've worked primarily with MM1, a lot with MM2, and some with MM6), so I don't know how MM5 handles its sprites. I know MM6 brings a sprite's graphics into the pattern table when it comes across that sprite in a level, but I don't know if that's done in MM5. MM1-3 definitely don't do it.
The issue you're having is differentiating between sprites as in enemies and items (I'll refer to them as objects or enemies from here on out), which have code, stats, animations, and frame data associated with them, and sprites as in the sprite tiles that are displayed onscreen. The enemy one is like an object with all of that information associated with it, and it has its identifier that is used in the enemy data for calling it during a level. A sprite tile is something on the sprite pattern table and has a specific identifier associated with its position on the table. Sprite tiles are built into the NES, while the objects are larger, artificial constructs not inherent to the system itself; you can, and often do, have objects without any actual sprite tiles associated with them (in which case the name 'sprite' really doesn't fit with it), and sprite tiles can often be placed on the screen without any sort of object identifier associated with them. To be more clear, for something like that arrow, I would probably program it so that the title screen routine is constantly drawing this arrow every frame (if necessary for the game) or draws it that first frame and doesn't touch most of it any more. It would store the arrow's tile ID, attributes, x, and y to sprite RAM, and there's other code that handles stuff related to menu selection, input, and all that. If something else is selected, the arrow is moved by drawing it with a different set of coordinates (or just updating the ones already in sprite RAM, if it only has to be drawn once), but it's still directly storing this information into sprite RAM; the arrow itself is not some sort of visual representation of an object with an ID but rather just a tile drawn to the screen. In this case, it's a small routine where the arrow is just a visual marker defined by the routine itself. It specifically uses the sprite tile's ID in the pattern table; there's no call to an object of which the arrow is a part. For an enemy or something of that sort, it's different; often there's a pointer in a table that points to the enemy's AI. The table is indexed according to the enemy IDs, so if you are looking at sprite #$47, you'd grab entry #$47 in the table and use that to get to the AI. Then there's a separate routine that handles the animation for that sprite, where animations are also being pointed to by pointers in a table indexed by the enemy's ID. The animation sets the speed of the sprite animation and which frames to use. Then there's frame data for what sprite tiles make up each frame, what palette they use, and how those tiles are arranged with respect to the enemy's coordinate. Frame data is the sprite tile part of this; it uses the literal sprite tile IDs in the table to identify the specific tiles used (or at least, usually does. I have no idea how it's handled in games where the enemy's graphics are brought into the table when the sprite comes onscreen, like MM6). So for enemies, the sprite you see is just a small part of it, and the whole enemy has an overall ID used to identify all of that. That ID is unrelated to the IDs of the sprite tiles the object uses. That was probably all long, bloated, and unnecessary, but I hope you get the idea from it. Using the sprite tile's ID can get you a lot of useful info in a game. In your case, it gets you the location of a routine, but you could also use it to locate frame data or even follow it backward to other object-related stuff (though that'd probably be a roundabout way of finding it), since it's all connected. You probably only need to deal with object IDs when dealing with sprites during gameplay, though it's important to point out that not all sprites in gameplay are part of objects (the life bars aren't). I hope that helps. |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 168/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
Posted by NetSplit MM5 does, indeed use the same enemy sprite system as MM6. =) Thanks for all of that. It definitely helped clear up some stuff! =) |
| RT-55J |
| ||
|
Armor Guardian Level: 81 Posts: 625/1562 EXP: 4889230 Next: 103619 Since: 02-23-07 From: Wild Side Arcade Last post: 314 days Last view: 55 days |
Posted by koala_knight Keep in mind that MM5 uses CHR-ROM, while MM6 uses CHR-RAM, which means the implementation of the system would be completely different. |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 169/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
Well, I'm only concerned with code used to place things from chr-ROM onto the title screen in MM5. I still haven't found it, BTW. |
| NetSplit |
| ||
|
Level: 32 Posts: 133/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
How are you looking? |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 170/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
I'm using break points in the debugger for reads/writes to RAM addresses. I'm getting the initial addresses from the RAM map at DataCrystal. Is there a better way? |
| NetSplit |
| ||
|
Level: 32 Posts: 134/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
The arrow tile is in sprite RAM, of course. Sprite RAM is at $0200. Find the arrow tile in sprite RAM and set a write breakpoint on it. Load the title screen. Routine found. |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 171/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
--- |
| infidelity |
| ||
|
Fuzz Ball Level: 66 Posts: 70/968 EXP: 2368068 Next: 93783 Since: 05-24-07 Last post: 958 days Last view: 814 days |
NetSplit is saying open your PPU Viewer during the title screen. Look in the window that houses sprite tiles only. Find the arrow, hover your mouse cursor over the tile. Below the window, it will tell you the exact number of the tile.
When you've found the number, goto the title screen of MM5. open fceuxd's hex editor, *View NES Memory* Goto 200-2FF, and find that number. A little advice. Starting at 200, a sprite tiles makeup, is set with 4 bytes. So... 200=X position 201=tile id 202=palette 203=Y position etc etc etc etc When you find the tile used, look at the address the tile is at from the top of your hex editor. add a breakpoint to that address. When the debugger snaps, locate the address it's loading the tile from. Bingo! |
| koala_knight |
| ||
|
Buzzy Beetle Level: 44 Posts: 172/384 EXP: 591242 Next: 20043 Since: 06-01-07 From: Miami Last post: 4126 days Last view: 4113 days |
I tried that. but the value for the arrow doesn't show up in the OAM range in PPU memory. There are 2 tiles in the PPU viewer #$86(wrong color) and #$8F(right color).
I tried looking at the OAM range in NES memory and I did find that $0201 had the value #$86 loaded into it. |
| Trax |
| ||
 Yellow Stalfos Level: 71 Posts: 610/1145 EXP: 3035814 Next: 131300 Since: 07-06-07 From: Québec Last post: 3627 days Last view: 2879 days |
If you want to have the face displayed with skin colors, most likely you'll have to display extra sprite tiles over the background ones, because of the lack of colors in a single tile... |
| infidelity |
| ||
|
Fuzz Ball Level: 66 Posts: 71/968 EXP: 2368068 Next: 93783 Since: 05-24-07 Last post: 958 days Last view: 814 days |
Posted by koala_knight $2ECA7 is where the tile is being loaded from (it's tile 86) I'd suggest running the Code Data Logger from the second you start the rom, and play the shit out of this game, so you can see where there are unused areas to insert whatever you want. |
| NetSplit |
| ||
|
Level: 32 Posts: 135/178 EXP: 188032 Next: 18410 Since: 02-26-07 Last post: 2217 days Last view: 2142 days |
You know, to this day I've still not used that Code/Data Logger. I know it's a handy tool, so I can't really say why that is.. 
I think I was able to clear up many of kk's problems via PM. The tile is drawn using a shared title/boss select screen sprite display routine that loads tiles from a table. Even if the table were moved, it wouldn't be able to fit Mega Man's face for the hack's title screen because the table uses nearly all of its possible space (something like 244 of the possible 256 bytes). By following the RTS, you can get to the title routine that called the sprite drawing routine and modify that code to do a JSR to unused space for drawing MM's face. The problem he seemed to be having was that the sprite drawing routine was used elsewhere, so it's more general than it could have been. koala_knight: Sprite colors are determined by assigning them attributes. The attributes byte, of which there is one per onscreen tile, handles which of the 4 palettes to give the sprite tile (as well as what the tile's background priority is, but that's not relevent to this conversation). This means you can have a sprite tile used multiple times onscreen, but the color of that tile can vary being uses. The color of the arrow in the pattern table doesn't have to match oncreen, but you can right click the table to change the palette it's using in order to get it to look more like how it looks on the screen. Sprite palettes in the table use a gray color for the background rather than black because sprite so often have a black outline, so gray is a more useful color for the transparent background than black (which would match the outline). Maybe I'm misunderstanding your post, but I think this might address your comment. |
| Main - ROM Hacking - Mega Man Powered Up to NES Project | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 92, rows: 131/132, time: 0.021 seconds. |