 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Megaman 4 Hack Released! |
 |  |  |
| Pages: 1 2 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66  Posts: 470/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| Okay, so Protoman replacing Megaman is out of the question. I suppose I could still make a great MM3 hack if I just rearranged the bosses in levels... How's this? The MM2 bosses are found in MM3 after you beat the 8 MM3 bosses, right? I could take the MM2 bosses and replace the MM3 bosses in their own levels, and take the icons from MM2 and replace the MM3 icons with those. That way you would have to pick a whole new order to play the 8 levels. Since MM3 loads sprite graphics differently than MM4, it would be possible to do this. Good idea? It also makes for a good storyline. Once you unlock the 4 Dark Levels, you'd have to fight the MM3 bosses anyway. I like this idea. BTW, I can't get a Debugger on my home computer because they're in .rar format, not .zip format. I can't unzip .rar files. I can get the Hex editor, though, but it would be pretty useless if I didn't know what byte did what... |
|||
Kagerato Goomba Level: 9 Posts: 10/25 EXP: 2655 For next: 507 Since: 08-08-04 Since last post: 382 days Last activity: 29 days |
| ||
| For ZIP, RAR, 7Z, TAR, and some other formats, I recommend 7-Zip. It's free and it's functional. http://www.7-zip.org/ As for the idea, it's all right. I think it would be a bit weird to play megaman 2 and then 3 in sequence, if that were the case in the original game. Anyway, I'm not one to put down a decent idea without having a much better one, so I'll leave it at that. Remember that long post describing the method of finding the palette indexes just a little while back? I decided to test it out for fun. And for the benefit of all, I recorded the actual process steps. -- BEGIN -- The first significant thing I did after loading Megaman 4 was open the PPU Viewer window. It's a very useful add-on that's only present in FCE Ultra debug, not the original FCEU. My most immediate discovery, and one that could likely be figured out by anyone who sat down for a moment to think about it, is that all the fancy color shifts in the intro, along with those vertical-travelling horizontal bars of color, and right down to Megaman's green charge glow, are all accomplished by changing the PPU's palette indexes [the indexes are at the bottom of the PPU Viewer window; hover the mouse over one to get its actual byte value]. After all, it would be too much work (and too much space) to have separate tiles for all the variations. FCE Ultra debug also has a nifty little feature which allows you to not only set breakpoints on CPU addresses, but also PPU addresses. I set a PPU write breakpoint on $3F00 after selecting Drill Man's stage but before the fancy color cycling was finished. That led me to... The main loop that does the palette writing to the PPU image and sprite palettes (via $2007), located at $7C0A0 in the ROM itself (very close to the beginning of the last PRG bank; this bank is probably left loaded by the game at all times since the procedure was not mirrored anywhere else). To find it, I just wrote down the bytes that make up the routine in sequential order and queried the ROM using a find function in a hex editor. Though note that this loop is only a section of the whole procedure. $C09F: BD 00 06 LDA $0600,X $C0A2: 8D 07 20 STA $2007 $C0A5: E8 INX $C0A6: 88 DEY $C0A7: D0 F6 BNE $C09F As you can see, basically all this loop does is load the palette indexes from a section of ram (if I hadn't known what $0600 referred to in the CPU memory map, I would have looked it up [yoshi's doc]), specifically the one that begins at $0600. The loop exits when Y reaches zero (that would cause the Z processor flag to become set, and the branch if not equal instruction only branches when Z is unset). The Y index is setup in an earlier part of the procedure (before the loop, not shown) to be #$20 [32 decimal]. That way the loop can write all 32 indexes, 16 for the image palette and 16 for the sprite palette (even though at least two, and possibly more, of those indexes will be the same). Since it writes image before sprite, there's no need to worry about the mirroring. What's this all mean? Well, the most important conclusion to draw is that this is not the procedure we want, nor the loop we want. If this procedure is loading the palette indexes from RAM, they've already been taken from ROM beforehand. We want the procedure that executed beforehand, loading the indexes from ROM and sticking them into $0600 and the addresses directly following. So, how do we track that one down? If new breakpoint came to mind, good job. For the next step, I set a write CPU breakpoint on the address $0600. We want to know where $0600 is being written; where are these values stored in $0600 and beyond coming from? Since this new information essentially makes us look for something completely new, I went ahead and exited the debugger, closed the game, and restarted from RESET. After getting back to the select screen, picking Drill Man, and then setting the $0600 CPU write breakpoint just before the bars-of-color palette animation is finished, the debugger stops on a new procedure. The relevant part of it looks like this: $C462: A0 1F LDY #$1F $C464: B9 20 06 LDA $0620,Y @ $0620 = #$0F $C467: 99 00 06 STA $0600,Y @ $0600 = #$0F $C46A: 88 DEY $C46B: 10 F7 BPL $C464 A short look at this tells us that the values being stored at $0600 [CPU] (and therefore being used to write $3F00 [PPU]) are being taken directly from $0620. The accumulator loads the value from $0620 and then immediately dumps it into place #$20 bytes earlier. Seems like a wild goose chase, huh? Where will it end? Even I don't know (though by the time this is posted, I will  .New breakpoint. Catch writes on CPU $0620, and let's take it from the top. We need to continue to be careful with our breakpoints. We know that the game is using completely different palette indexes for doing its animations, including the one just before the stage is drawn. We might catch the wrong procedure if we set the breakpoint too early. A recommendation: Have the debugger window open beforehand. Play to right where you want to be (in this case, just before the stage is actually drawn and just before the fadeout finishes). As activity continues in the background, you can hit 'Step Into' with the right timing to nail the precise position. This will freeze the gameplay and allow you to set the breakpoint with much higher accuracy. Once the breakpoint is in place, go ahead and hit run to execute all the way to where the breakpoint fires. Whee, yet another new procedure. After using our arrows to look up at the section of the procedure which already executed, the majority of the procedure comes into view: $C611: AA TAX $C612: A0 00 LDY #$00 $C614: BD 90 B5 LDA $B590,X @ $B590 = #$0F $C617: 99 20 06 STA $0620,Y @ $0620 = #$0F $C61A: C0 04 CPY #$04 $C61C: B0 0E BCS $C62C $C61E: BD A0 B5 LDA $B5A0,X @ $B5A0 = #$00 $C621: 99 F0 06 STA $06F0,Y @ $06F0 = #$00 $C624: A9 00 LDA #$00 $C626: 99 F4 06 STA $06F4,Y @ $06F4 = #$00 $C629: 99 F8 06 STA $06F8,Y @ $06F8 = #$00 $C62C: C0 08 CPY #$08 $C62E: B0 06 BCS $C636 $C630: B9 53 C8 LDA $C853,Y @ $C853 = #$0F $C633: 99 30 06 STA $0630,Y @ $0630 = #$0F $C636: E8 INX $C637: C8 INY In short, $B590 is where the values at $0620, and therefore $0600 and $3F00 [PPU] are coming from for the stage. $BF90 [CPU] is not a RAM address, register, or reserved/expansion space. Judging by our CPU memory map, we know this is a ROM address. It's quite far into the first loaded PRG ROM bank. What's with all the other stuff? Well, Megaman 4 apparently creates the logical separation of image and sprite palettes in the ROM. Therefore, it has to load them from two separate addresses as well. Not only that, but it divides the sprite palettes into two eight-byte chunks (grand total: three addresses). It's starting to get too complicated for the scope of this tutorial. Therefore, I think it's best if I just list my findings: the ROM addresses of where the palette indexes used on Drill Man's stage are originally loaded from. $455A0 - all 16 bytes of the image indexes for Drill Man's stage $7C863 - the first eight bytes of the sprite indexes $51932 - the last eight bytes of the sprite indexes For those interested in the full explanation of how I got these, though: I traced the code as I demonstrated until I finally came to a dead end where the data is directly loaded from ROM and saved temporarily into the appropriate $06xx RAM location, like the one you see in the procedure. Then I used FCEU's "Seek To" function to go to the memory position where the indexes were loaded. (After all, the data has to be in the memory map currently if it's being loaded by the CPU.) This location is in one of possibly many PRG banks in the ROM. To find out which one, I copied out a good long string of bytes [24 seemed to work well enough], and then searched for that same string in the ROM. I had to do this three times to get all three addresses; and I varied the breakpoint a bit each time. For the first address, I was watching writes to $0620; for the second, $0630-$0637; for the third; $0638-$063F. Note that this seemingly-enormous debugging method was necessary in order to get completely unique addresses. We could have just used the PPU Viewer to write down the indexes from Drill Man's stage. However, if we searched all 32 indexes at once, we would have gotten 0 results (due to the segmentation of the storage). If we had searched just the image indexes, 2 results would have come up. But then trial and error modification would be necessary to find which one belongs to Drill Man's stage. And we wouldn't know where the sprite indexes had been loaded from, either. In games where the same palette indexes are stored in the ROM many times, using the debugger ends up being much faster than individually doing trial and error on every last instance. Also, keep in mind that Megaman 4 is a relatively sane game. Some games could store their palette indexes in the ROM as unknown formats -- using compression is highly unlikely but not impossible. Then the only way to track down the data would be to trace to the procedure that translates the ROM data into the actual indexes. Using the PPU Viewer could not work because you wouldn't have any idea of what the format was ahead of time (unless you already had done thorough tracing/debugging on the game). A little bit more info on those ROM addresses, and some screenshots follows. The image palette indexes seem to be used entirely for the stage/level itself. More significantly, they're independent of other stages. Which means by changing Drill Man's indexes, you don't affect Dive, Toad, etc. Good news there.  The second address, is common and applies to all stages. The second offset partly (entirely?) controls megaman's face, body, and energy bar colors. Some of these colors are also used for enemies, I believe (but only some enemies). If you change megaman's body color, it will only hold for as long as you don't charge his shot. The routine that does the funny glow for the charge shot will overwrite your changes.   The third offset is, fortunately, stage-specific like the first. It controls colors used for some (I believe most) enemies.  -- END -- Have fun  (edited by Kagerato on 08-11-04 03:24 PM) |
|||
|
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66 Posts: 475/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| Uh, these posts are a little hard to read from start to finish, but... thanks for the link and I'll be sure to get that debugger on my PC ASAP. I tested something on MM3. I replaced the origonal bosses with the MM2 bosses found in the 4 Dark Levels. And it works VERY well! Though it's a little weird that you can get Needle Cannon from defeating Heat Man, or Top Spin from defeating Crash Man, I could actually use that oddity to my advantage by devising a unique storyline to the hack. Simple. Rescue the MM3 bosses from the clutches of the MM2 bosses! But then I could go a little further into things and place the MM3 bosses in the Dark Levels... two in one room. I believe if that happened, they'd share the same boss meter and defeating one would defeat both bosses at the same time. I decided to make a hack using these techniques. I've even changed the title screen to say "Wily Boss Mode" instead of "3". I'd show you a screenshot, but I don't have one with me right now. I will soon. Schwa, over and out. |
|||
|
Kagerato Goomba Level: 9 Posts: 11/25 EXP: 2655 For next: 507 Since: 08-08-04 Since last post: 382 days Last activity: 29 days |
| ||
| -- introduction -- After working with the broader view for a while, I decided to go ahead and track down the exact problem for the fade-in animation on Drill Man's stage. Using the PPU Viewer and playing through the stage, it became obvious that only three of the sixteen image indexes were being changed for the animation. I noted their position and then, using my earlier findings, equated them to the RAM addresses $0629, $062A, and $062B. After setting a write CPU breakpoint on this range, I quickly found the procedure that does the animation. The animation is gradual in four steps. Each time a different set of indexes is written to the PPU's palette indexes. -- first change -- $0629-$062B are written with the bytes from $B94E-$B950 [CPU memory]. This data is at $B94E and the subsequent addresses during the time the first set of writes occur: #$07, #$0F, #$0F, #$29, #$21, #$25, #$30, #$32, #$0F, #$39, #$25, #$21, #$16, #$07, #$0F, #$26 This first sequence of bytes is located only at $4195E in the ROM. -- second change -- $0629-$062B are written with the bytes from $B95A-$B95C [CPU memory]. This data is at $B95A and the subsequent addresses during the time the second set of writes occur: #$16, #$07, #$0F, #$26, #$16, #$06, #$37, #$26, #$16, #$11, #$01, #$17, #$11, #$01, #$18 This second sequence of bytes is located only at $4196A in the ROM. -- third change -- $0629-$062B are written with the bytes from $B95D-$B95F [CPU memory]. This data is at $B95D and the subsequent addresses during the time the third set of writes occur: #$26, #$16, #$06, #$37, #$26, #$16, #$11, #$01, #$17, #$11, #$01, #$18, #$11, #$01, #$27 This third sequence of bytes is located only at $4196D in the ROM. -- fourth change -- $0629-$062B are written with the bytes from $B960-$B962 [CPU memory]. This data is at $B960 and the subsequent addresses during the time fourth set of writes occur: #$37, #$26, #$16, #$11, #$01, #$17, #$11, #$01, #$18, #$11, #$01, #$27, #$11, #$01, #$28 This sequence of bytes is located only at $41970 in the ROM. -- conclusion -- To correct the fade-in animation for the rock faces in Drill Man's stage, these ROM addresses must be given new values (palette indexes): $4195E-$41960 $4196A-$4196C $4196D-$4196F $41970-$41972 The first range is the only odd one. The last three all follow directly after one another. Choose your indexes using an image which displays the NES palette as a table of indexes, such as the one on TFG's page. (http://tfg.panicus.org/files/docs/nes_pal_fast.html) |
|||
|
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66 Posts: 506/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| Listen, Kagerato, you're exteremly smart-- now I need your help. I'm trying to change Megaman's colors in MM2. Tell me exactly what I do to make it work. I'm so frustrated right now... I have the debugger AND the Hex Editor, and I don't have any clue as to how they work. The debugger keeps freezing the emulator each time I try to write a breakpoint. Leave out no details. Thank you. |
|||
|
Kagerato Goomba Level: 9 Posts: 12/25 EXP: 2655 For next: 507 Since: 08-08-04 Since last post: 382 days Last activity: 29 days |
| ||
| It's exactly the same theory. That's why I went through the whole process with Megaman 4; to demonstrate how it's possible to debug using very little information and get precisely what is needed out of it. Recall that all I knew when I began with the fourth game is where PPU RAM holds the palette indexes ($3F00 - $3F1F). I placed a PPU breakpoint on the first index and started from there. That lead me back through the code, following writes to the RAM addresses I saw until I stumbled upon the initial load instructions from the ROM. I've already explained in great detail the physical method, and now the theory as well (which is fortunately much shorter). You'll have to clarify if you want something else. As for 'freezing' the emulator, you're not being specific enough. Breakpoints are supposed to freeze the emulator; that's their exact purpose. A breakpoint stops execution of code based on one or more factors. In FCEUd, the factor is generally that a CPU or PPU address has been read or written (or is about to be read or written). If you set a breakpoint while the game is running and that breakpoint is about to fire, or is continously firing, according to what the game is doing, then it will stop execution immediately. That is to be expected -- breakpoints are tools, they're not perfect. It's up to the programmer to use them effectively. You've got to use new methods to out-think the problem. For example, various palette animations you see on stages are caused by writing new palette indexes to particular sets of colors in the image palette. The palette indexes can only be correctly (properly) written during VBLANK -- the time between the electron gun completing a frame and beginning to draw the next (it has to reset from the bottom scanline to the top scanline, which takes relatively much longer than HBLANK). Otherwise, much garbage would be drawn to the screen. If the animations are continuous (and therefore never-ending), the palette index writing procedure is firing on every VBLANK that occurs while the stage (and/or appropriate screens) are loaded. VBLANK is a non-maskable interrupt (you cannot disable it; it always interrupts the running program code under any circumstances) and it also happens sixty times per second on an NTSC NES (60 full frames need to be drawn for every second). Now let's complicate the situation. Say that we really couldn't give a **** about that flashy palette animation. What we want to know is when and how some enemies are given new colors (or, perhaps, new enemies appear and have different colors) during the stage's lifetime. There are two ways to solve the problem. One, we change our breakpoint to better match the scenario. $3F00 is the first image index; the range $3F00 to $3F0F represents the set of indexes which may potentially be written by our flashy palette animation that's always happening. $3F10 to $3F1F , on the other hand, represents the potential range for changing sprite colors. By shifting the breakpoint's range, we may be able to avoid the constant palette animation entirely. Unfortunately, there is some more complexity to the matter. Remember the palette mirroring? When the image indexes are written, the corresponding sprite indexes are going to adopt their colors. In order to get everything correct before VBLANK is finished, the palette animation's procedure is very likely going to write all the sprite indexes with their proper values as well. It makes for cleaner code and much less likelihood of error (after all, they shall not be written outside of VBLANK -- that's heresy). So, does changing the breakpoint really help? It might help slightly, especially if the sprite indexes are written in a separate procedure running inside VBLANK. But all you will be able to find out from that procedure is the RAM address which they are copied over from -- it's not going to load them straight from the ROM (imagine how many ROM reads per second that would be, ugh). From there, it is possible to continue tracing by using the newfound RAM address. There is a second method, as I mentioned earlier. It simplifies things a good deal by taking the irrelevant information out of the picture. You can probably guess what it is: use another stage, one that doesn't have any flashy palette animations. This will very likely eliminate your massive number of palette index writes, and sometimes eliminate them entirely (if there's nothing; no enemies, no megaman effects, no background nothing on screen to be palette animated). By vastly reducing the number of writes, the necessary precision becomes much reduced and you generally end up weeding through less code. Well, I can only hope that will infuse a bit of different, new thinking. For your sake and mine, please make all further questions as specific as possible. It helps a lot to tell exactly what you've tried, the steps you've taken, et cetera as well. |
|||
Omega45889 Panser Level: 30  Posts: 169/335 EXP: 148978 For next: 16891 Since: 03-22-04 From: Vancouver Canada Since last post: 5 days Last activity: 6 hours |
| ||
| Schwa, you dont need a hex editor, or debugger to modify the pallets. All you got to do is go here http://desnet.fobby.net/index.php?page=utilities&id=4 visine, located at that url, supports the editing of mega man's palettes. Simply press the W key when editing MM2 and a Mega Man Palette Editor pops up, allowing you to edit all of MM's palettes (one for each weapon) If your interested in a chart of all the colors for the NES, one can be found here http://desnet.fobby.net/doc/AoRH.html#sIV section IV in that document has a nifty little table of all of the NES' 64 colors. the guy who made it should be given a medal. Lol, hope that helps. |
|||
|
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66 Posts: 513/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| WHAT!!? I should have thought of that! I thought the W button would change the color of the attacks, not Megaman himself... Well, I guess it's back to work for me. I suppose you're wondering why I want to change Megaman's colors, huh? I'll get some screenshots soon. I hope to God that this works... |
|||
|
Kagerato Goomba Level: 9 Posts: 13/25 EXP: 2655 For next: 507 Since: 08-08-04 Since last post: 382 days Last activity: 29 days |
| ||
| visine is a rather powerful editor. Not too suprising that it already has the internal palette addresses, and the ability to modify them. Come to think of it, you sure MegaFLE doesn't have a similar feature? In any case, I hope all those posts I wrote don't go entirely to waste. |
|||
|
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66 Posts: 514/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| Oh, no. I'll still use them as references. I've always wanted to learn how to edit the hex values for roms, not just for palettes, but anything. Look what I did to Megaman in Megaman 2. *big smirk* I'm making MM2 where you play as Bass. He's a character that appeared in MM7, and the Japan-only Rockman & Forte. I gave Bass the auto-fire ability, but it was too easy to beat enemies, so I changed his shooting back to normal. I think I'm going to make his jump a little higher instead, which is okay to do since I'm going to be changing the levels anyhow. Also, Bass starts out with lower HP and Weapon energy, exactly 1/3 less. His max HP is still the same, but it makes you have to search for energy at the beginning of the level. Tell me your opinions. |
|||
|
Dylan Devil Trumpets and Angel Trombones ~ Level: 54  Posts: 772/1407 EXP: 1181697 For next: 52173 Since: 06-19-04 From: Ottawa, Canada. Since last post: 1 day Last activity: 6 hours |
| ||
Cool, Schwa. Thats the first I've seen of an 8-bit Bass, but you did a nice edit.  |
|||
Googie Surarok Level: 39  Posts: 128/624 EXP: 380784 For next: 23987 Since: 03-15-04 From: Corona Queens New York Since last post: 3 hours Last activity: 3 hours |
| ||
| Sorry to break the news to you Schwa, but it's been done. Sivak Drac made a hack called The Adventures of Bass 2 (MM2 Hack) http://www.geocities.com/lordsivak/Bass2.html Now if you were to rip those Bass sprites into MM3 & make new levels for MM3, you can bring a dead hack back to life. http://www.geocities.com/lordsivak/Bass3.html I hope that you'll consider it cause I really liked the way you hack MM4 I can imagine MM3. |
|||
|
Chaos Force Panser Level: 29 Posts: 170/332 EXP: 147860 For next: 25 Since: 03-15-04 Since last post: 21 days Last activity: 4 hours |
| ||
Actually, it's the 3rd NES Bass that I know of. The first two were made by Vagla and Sivak Drac. Vagla's was based off of Bass from Rockman: Battle & Fighters for neo Geo Pocket, but due to size constraints, it obviously couldn't be identical. Sivak Drac's is an edit of the Mega Man sprite  Also, it might be useful for you to tinker with how frames are actually built. Here's some data that Vagla found that should prove helpful: ----- Mega Man 2 Frame Data (by Vagla) 2874C - Data for the first frame (Mega Man's standstill frame). Format is as follows: First byte: Number of tiles in the current frame. Second byte: Frame pattern ID All following bytes: the rest of the data is as long as the 'number of tiles in the current frame' byte multiplied by 2, since each tile in a frame takes 2 bytes. The first byte for a tile is the tile ID, and the second byte is the attribute byte (y mirroring, x mirroring, background priorities, palette). It's really simple; just go toy with it. Basically, 2 header bytes for each frame, one saying how many tiles and the other saying which frame pattern to use, and then pairs of bytes for each tile. So what's a frame pattern? A frame pattern tells the game where each tile on a frame goes. The first frame has 10 tiles, each in a different location, so the frame pattern tells it where to put each of those 10 tiles in relation to each other. This byte is useful because you can reuse frame patterns. For example, Mega Man's first 3 frames use the same frame pattern because they're all so similar (Standstill frame, Standstill + blinking frame, Standstill + taking a small step forward frame). That same frame pattern is also used for many 1x1 tile frames, such as your default weapon, health items, and weapon energy items. Simple as that. 2AAC6 - Data for the first frame pattern. This data might be a bit confusing at first, but it's actually pretty simple. All the data is is pairs of yy and xx coordinates saying where each tile in a frame will be. There is no data seperating individual frame patterns, so it's only tile coordinate data. So, for the first frame pattern, the first 20 bytes will define how those 10 tiles for Mega Man's first three frames are arranged. FCFC is the yyxx set for MM's middle, and then it goes to his feat (04F4). You add more to to the yy set to make the tile lower, subtract from it to make it higher, add to the xx to make it more to the right, and subtract from the xx to make it more to the left. Simple as that. (edited by Chaos Force on 08-15-04 08:20 PM) |
|||
|
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66 Posts: 518/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| NOOOOOOO!!! It's too friggin awesome! I loooooose! Well, looks like my MM2 hack's dead. I can't put him in Megaman 3 because the graphics are stored too oddly. I can't find some of the graphics used to draw Megaman while he's running. He's missing the back of his helmet when I place the tiles on the arranger. *sigh* Maybe I shouldn't hack another Megaman game for a while. I mean, there's TONS of Rom hacking programs out there, along with the roms to go with them. Megaman is cool, but so are a lot of other vg characters... Sonic the Hedgehog being the ultimate, all-time #1 game. I have a Sonic 1 editor, but it's glitchy... Folks, this Bass info is kinda harsh. I need a little time to sort this out. Do you really, really want me to hack MM3? It won't be that great, actually... I don't know any hex editing, all I know how to do is use the level editor well. I know it's a powerful editor, but... *sigh again* I feel trapped. I thought I had this great idea to put Bass in MM2, then I find that someone already put him in there. It made me sad... I worked so hard on those tiles... I guess giving up is the coward's way out. I'll hack MM3 next, but it won't be ultra-fancy like my MM2 screenshots or any of that... It'll probably be as good as my MM4 hack. Sound good? |
|||
|
Kagerato Goomba Level: 9 Posts: 14/25 EXP: 2655 For next: 507 Since: 08-08-04 Since last post: 382 days Last activity: 29 days |
| ||
| Your situation gives some good insight into how I feel a good deal of the time, Schwa. Always do what you think is best. If your thinking proved to be flawed, at least you will have learned something. If you like Megaman III and have enthusiasm for the game, that's what you should work with. You may find later on that your feelings become muddled; that's the way our minds work. Try to reconcile what you feel you should do with what you logically reason you should do. A very difficult task, in any case. |
|||
|
Schwa Green Birdo The Embodyment of Good, infused with the Living Assets "Alpha Psibeam!" (echo effects) Level: 66 Posts: 529/2214 EXP: 2457091 For next: 4760 Since: 04-25-04 From: Spanaway, WA Since last post: 1 day Last activity: 13 hours |
| ||
| I feel better now. I started working on MM3 this morning, and Needle Man's level already looks like it'll be 10 times better than it's origonal. You have more possibilities with MM3, since the graphics for enemies are stored more conviently. Rather than only being able to use level-specific enemies, I can use enemies from any level I want, wherever I want. Much more freedom. I'll have screenshots soon, but won't put them in this thread because it's a MM4 thread. See ya later. Edit: Okay, I finished Needle Man, opened Magnet Man and all I got was an entire level full of glitched up, destoryed graphics. Not a trace of any Magnet Man graphics remained. Lovely. Had to revert the MM3 Rom to it's origional state, and I probably won't be hacking Roms for a while as I found something a little more interesting. Enjoy my finished MM4 hack, folks, because a new hack won't be released in the near future. (edited by Schwa on 08-18-04 02:35 PM) |
| Pages: 1 2 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Megaman 4 Hack Released! |
| | |
