 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,484,460 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-26-24 01:40 AM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 3 guests | 1 bot |
| Thread preview |
| Zynk |
| ||
|
Posts: 207/209
|
That did it! Thank you very much!
Changed $CC33 to $FFFF Posted by Quick Curly |
| Quick Curly |
| ||
|
Posts: 1440/1443
|
Okay, thank you for the clarification. When you said in your first post that you used Mega FLE X to change the palette IDs of the background, I interpreted that as you simply saying you changed the actual palette, and not the attributes, which is why I couldn't replicate your issue by only focusing on the palette. I also didn't try looking for the attributes yet since I didn't have all the specific details of anything else you might have potentially modified.
Again, these findings are from using the (U) version of the game. By focusing on a PPU write to $218E for a value of 10 (the tile ID of the top-left of Proto Man), the Debugger froze at $C2B0 (0x3C2C0 in the ROM file). The previous line of code, $C2AD, showed that a value of 10 was retrieved from $0783 in CPU memory. So, I set a new write breakpoint for $0783 for when a value of 10 is stored there. After returning to the beginning point, the Debugger snapped at $8B15 (0x2EB25 in the ROM file). The previous line of code, $8B12, showed that a value of 10 was retrieved from $8E92 (0x2EEA2 in the ROM file). 
The range of 0x2EE9F-0x2EEC0 (0x22 bytes in hex) is the data for Proto Man's tiles, as well as the attribute value for $23DB (to use the fourth quarter of the palette for Proto Man's graphics). After I modified 0x2EEBE from CC to FF, the background on the left side of the display box for Proto Man started to use the fourth quarter of the palette (03) instead of the first quarter (00). 
CC in hexadecimal is 11001100 in binary. FF in hexadecimal is 11111111 in binary. Each attribute value covers a 64x64 area, made up of 2 16x16 blocks, or 4 8x8 tiles, in the following order with respect to its binary value: 33221100
So, a value of CC means the 0 and 2 8x8 sections use the first quarter of the background palette (00 in hex, 00 in binary), and the 1 and 3 8x8 sections use the fourth quarter of the background palette (03 in hex, 11 in binary). By modifying 0x2EEBF from 33 to FF, the right side of the display box started to use the fourth quarter of the palette as well. This is the attribute value for $23DC in PPU memory. 33 in hexadecimal is 00110011 in binary. The 0 and 2 8x8 sections use the fourth quarter of the background palette for the right side of Proto Man, and the 1 and 3 8x8 sections use the first quarter of the background palette for the background display on the right side of the display box. The ROM offsets could be different depending on your version, but check this area of the ROM file first, and check to see what these attribute values are on your end. If they're FF, try changing them back to the original values as shown in the first image, and then test those changes to see what happens. |
| Zynk |
| ||
|
Posts: 206/209
|
Thanks for the reply QC. I edited the stage select screen with Mega FLE X, like I mentioned in my previous post.
-I did not change the stage select screen palettes at 0x2ebb0. The offsets of the color attributes (00,1,02,03) of the stage select screen at 0x1f170-1f1a8 for the bakground tiles, and the mugshots of Megaman and the 8 robot masters at 0x1f1a9-1f1ce, Protoman's mugshot attribute and the tiles by his sides are not in that offsets.  |
| Quick Curly |
| ||
|
Posts: 1439/1443
|
Hi, Zynk. I tried to look at Mega Man V to see what I could find. Is your ROM the (J) version or the (U) version? I used the (U) version, so the specific RAM and ROM addresses might not be accurate or helpful.
$006E in CPU memory is used to keep track of the levels cleared. By manually setting it to a value of FF before I started a new game, all of the levels were cleared, and then Mega Man in the middle became Proto Man due to code at $8AF1 in CPU memory (0x2EB01 in the ROM file) that checks the value at $006E and compares it to a value of FF. The palette for the background and sprites is at 0x2EBB0-0x2EBCF (0x20 bytes in hex) in the ROM file. I modified 0x2EBB3 from 11 to 04 before starting a new game for visual testing purposes. The background area around Proto Man was purple like the rest of the background, and remained purple even after switching the current selection back and forth between the other stage select options. 
Therefore, I couldn't exactly replicate your issue, so I'm unsure of what the issue on your side of things could be, whether it was a result of using the editor to modify the palette, or from another modification. Sometimes game-specific editors are known to modify additional bytes against your knowledge and will. I recall mentions in the past about a Zelda editor for one of the games doing something like that. I'm unfamiliar with Mega Man editors and any potential quirks they might have, if any. My assumption is that the attributes of the background on the left and right sides of Proto Man could have been modified differently than the rest of the background, and for some reason, it didn't occur on my end. If I was using the incorrect version of the game, differences between versions could also be a potential reason why I produced different results. Perhaps additional information and/or direct assistance is necessary for critical discoveries and success. Maybe someone with more direct Mega Man experience has some additional ideas and insight. Hopefully we can all eventually figure this out. Best of luck. You can do it. |
| Zynk |
| ||
|
Posts: 205/209
|
Anyone know how to change the blye parts around Protoman's portrait? I used Mega FLE X to change the palette IDs of the background.
 |
| reset |
| ||
|
Posts: 1/1
|
Posted by SOPHIA Hi Sophia. Would there be anyway that the Mega Man X2 rom of yours could be made available? I had noticed you used to have a link to your gameplay of it but it isn't up anymore. If there is a playthrough or any accessibility I think that would be awesome! |
| BenoitRen |
| ||
|
Posts: 1/2
|
This question isn't about hacking a Mega Man game, but it's closely related.
Thanks to the existing disassembly of the first Mega Man game, I've figured out how the physics work. To reverse engineer the other games, I've used FCEUX to do my own research. However, that means that for Mega Man 3 onwards, I've only able to make educated guesses. For the first Mega Man, the logic is as follows: -If Mega Man is in an uncontrollable state (transforming, throwing, hit), it checks which of those states it is in, and reacts accordingly. After that, joypad input is cleared, and it executes Not_Climbing. -If Mega Man is climbing a ladder, go to LadderHandler. -Check if there's a ladder touching Mega Man. If there is, react accordingly, and, save for a special case, go to LadderHandler. -Now that it's determined that Mega Man isn't climbing, execute Not_Climbing. This means checking if he's about to run, if he's running, etc. Note that LadderHandler leads back here, as well. -Handle horizontal movement. -Refresh the CurrentTileState value, which is used in determining if a ladder is nearby. -If Mega Man is climbing, and no ladders are near, make him fall. -Check if Mega Man is exiting the screen. -Handle vertical movement. -Check if A is pressed, and make Mega Man jump if possible. Somewhere in the middle it's checked if Mega Man is shooting, but I don't remember where exactly. What does Mega Man 3's logic look like? I'm especially interested in how it handles ladders, because it seems to have new special rules for them. In particular, the game helps Mega Man on a ladder if he hits his head next to a ladder that is enclosed by solid blocks. |
| Insectduel |
| ||
|
Posts: 1069/1069
|
Ah cool! I never knew other unused areas other than 33960-33DFF which I actually use for the X/Y data which is used pacifically for Break Man since I want to remodel the sprite and not overwrite Proto Man which uses the same sprite ID for X/Y. Yeah that kinda surprised me when I did it the first time only to find out that you need to edit both left and right sprites for each sprite ID.
Based on my hack, I have to play and scan the entire game using a debugging tool emulator to see if there are unused sprite ID's for X/Y data. Turns out there are few unused ID's I can use other than the bosses that won't be used in the game like Gamma, Snake Boss, Kamegoro Maker and Giant Mets just enough to insert the X/Y data in freely. Replayed the game with the new Break Man modded sprite and there are no mess up sprites in all of the levels. I am going to remodel every robot master from scratch. From Doc Robots which came first to the Robot Masters using both Tile ID and X/Y data. However, editing sprite collisions such as bumping into walls or hitting the floor requires to edit their AI data based on a specific RAM code may take some time. |
| kuja killer |
| ||
|
Posts: 613/628
|
this is based on megaman 3 improvement 2.0 (and above)
--------------------------- This area is mostly used by bosses and mid-bosses 293B0-29DFF - free unused data where you place your X/Y tile data at 29EC2-F0F (low byte of pointer) / 29FC2-2A00F (high byte of pointer) --------------------------- 33960-33DFF - free unused data for X/Y tile data there's really not anything unused here unfortantely. There's a few spots like 33EAE-33EB3 --- FAE/FB3 but that's it. --------------------------- I'd recommend using the pointers from the 28000-29FFF area mentioned first above. I dont really remember exactly how it works though, about how to use the 28xxx area cause it's really stupid that you need both "left" and "right" copies for the x/y's -- mm4 and 5 only used 1 set which was alot easier. |
| Insectduel |
| ||
|
Posts: 1068/1069
|
In Mega Man 3, are there any unused sprite ID's for the X and Y positions? I feel that every one of them is used so any sprite edited from the X and Y positions will mess some of the sprites up. Let's say you use Capcom Sprite Assembler for Mega Man 3 and you are on the $36000 bank, you edit F0 thinking that it's unused in the entry but in the actual game you corrupt one of Doc Robot's sprite which is at the $2A000 bank. The X and Y positions is located around x33010.
I am in the final progress of my upcoming hack and it's the hardest part of hacking Mega Man games. |
| rcpd2236 |
| ||
|
Posts: 1/1
|
Hi everyone, first post here.
To cut a long story short, I've been trying to (slowly) hack away at Mega Man 1. When I mean slowly I mean I'm at the conceptual and planning stages, and minor hacks to test enemy placement, pacing and tilesets. And I got to *that* stage... I was looking at Gutsman's stage, particularly the lifts and at the annotated disassembly. I know the values for the three lifts; however I'm having a problem trying to figure out how the game determines the lift "breaks" (when the platform goes down and back up again). I know I can edit the LiftIndex byte and make, say, the 2nd lift behave like the 1st one but while it doesn't "break" like the first it's placed at the same X coordinates. Any help? Thank in advance! |
| Synthetekh |
| ||
|
Posts: 193/239
|
Don't know if you still need this, but here's the solution I found to run MegaFLE X.
I have to register the dll files. Putting them in the same folder as the exe or system32 didn't work. When you register them with the OS they can be in any folder, but will only work in that registered location unless you re-register them elsewhere. --- 1. Run cmd.exe as Administrator 2. In Cmd Prompt move to the Directory where COMCT232.OCX is located 3. At the command prompt Enter: "RegSvr32 COMCT232.OCX" 4. Repeat Steps 2 & 3 for 'comctl32.ocx' (MSVBVM60.DLL also comes with MegaFLE X but doesn't seem needed). |
| Insectduel |
| ||
|
Posts: 1067/1069
|
For people that has problems with MegaFLE X, do you put certain .dll files the same folder as the editor or system file? Try run as administrator by right clicking on it. I got trouble at first. |
| EggplantPimp |
| ||
|
Posts: 370/378
|
I'll have to try it again after I'm done with my house chores.  |
| Kuumba |
| ||
|
Posts: 7/7
|
Eggplant is Mega File X and your rom on the same drive ? that was a issue that I ran into when I first started messing around with it |
| EggplantPimp |
| ||
|
Posts: 369/378
|
I'm having hard time with Mega FLE X, when I want to open Mega Man IV, the editor won't open it, is there something I need to get? |
| Ness |
| ||
|
Posts: 38/38
|
Okay, here is what the previous post was about, small hacks that make the charge shot charging sound fade out instead of looping forever for MM4, 5 and 6:
http://www.romhacking.net/hacks/5072/ http://www.romhacking.net/hacks/5066/ http://www.romhacking.net/hacks/5067/ The MM5 one was initially a small part of my previous hacks but since I decided to give the charge shot sound the same treatment for 4 and 6, I thought I'd release a standalone version of the 5 one as well. The point is, the MM5 and 6 ones should be compatible with the vast majority of hacks out there. The MM4 one probably less but should still be compatible with quite a lot of hacks. Fun facts: - MM6's sound system seems to identical to the one in MM5, down to the sound instruments. It looks like sound definitions can be copy pasted pretty much as is from one game to the next and will sound the same. I doubt the same can be said for musics but I haven't checked. - The looping of the sound in MM4 is actually handled by code. I wonder if they did that due to all the sounds that can cancel it? |
| Ness |
| ||
|
Posts: 35/38
|
I need help with MM4's sound system, please.
I can't seem to make sense out of the Sound Effect Address Table. With help from documentation, I found the Address Table starting at 3C010+A43 Then, by substracting 8000 and adding the Sound Bank offset, you're supposed to get the ROM address of sounds, but I can't make it match. Yet, this system worked flawlessly when I edited sounds in MM5. Example: - Charge shot charging looping sound, is sound id 27. - In the table starting at 3CA53, that leads me 3CAA1-3CAA2 which reads CF 2B - That CF 2B seems to be correct as changing it to another sound address like CE 48 does indeed change the charge shot looping sound into another sound However, if I do the math to get the ROM address out of CF2B, no matter what I do it never matches the address of the Charge Shot looping sound which I had previously found manually, which is at 3CD09. That 3CD09 seems to be correct as editing the bytes starting from there will indeed edit the charge shot sound. Feels like I'm missing a tool to translate CF2B to a Rom address and that it doesn't work like in MM5 andd like the documentation says, does anyone know? or is it something else that I got wrong? Thank you Edit: Okay the documentation actually had the solution. The charge shot sound def is at 3AF3B and not 3CD09 and the conversion from C2FB to 3AF3B is quite simple (3A010 + 2FB); I wish I knew why modifying 3CD09 modified the sound of the charge shot then, I'm still running blind regarding MM4. |
| Kuumba |
| ||
|
Posts: 6/7
|
oooo , I thinkhe might be referring to the image numbers or something , but yeah it's not very clear but I think there's a sprite viewer on his website and Misty the creator of Rockman Deus Ex machina has some sprite related info on his website (archive) . So I would just recommend looking at that |
| fabiansummers |
| ||
|
Posts: 20/20
|
It's the one that supposedly has the sprite dara. I just don't know how to interpret the numbers in it. |
| The full thread can be viewed here. |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 31, rows: 62/62, time: 0.013 seconds. |
