 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,509,537 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-02-24 01:45 AM |
|
| Guest: Register | Login | |||
| Main - Posts by NetSplit |
| NetSplit |
| ||
|
Level: 32 Posts: 61/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
If you have the original ROM with the 0-1 issue, you could try making an IPS patch for your hack and then applying that IPS to a known-good version of the ROM. Assuming the level data and such is the in the same location in both ROMs, this method should work fine. |
| NetSplit |
| ||
|
Level: 32 Posts: 62/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Insectduel: To be honest, I'm not a big fan of what you're doing with the hack. You're just putting simple ponytails onto the heads of various characters; seems minimal and doesn't really benefit the game at all, in my opinion. I'm a bit conservative when it comes to that sort of thing, though, so don't let my opinion stop you if that's really what you want to do.
Regarding sprite frame data, Mega Man 1's frame data is very hard to work with. I added a splash graphic to the game, since MM1 is the only NES Mega Man game without a splash graphic when entering water, and it turned out to be rather difficult to add in the animation and frames for it. Even small, simple edits, or adding a frame of animation, or whatever, can be very difficult or impossible without some compromises. Because the ROM is so small, they had to share a lot of data between sprites, so editing one thing will likely edit other things, as well. In addition, the format is incredibly confusing and convoluted; I'm pretty certain I don't even have all the data for it. Here's what's in my notes about frame and animation data, but note that I didn't write these with the intention of publishing them, so don't expect any of it to be 100% accurate. [Terminology, as best I can remember from when I wrote the following notes: A frame is a collection of tiles. A frame pointer is a pointer that points to the data for a frame. If an animation references frame #$13, for example, the game will look at pointer #$13 and grab the data from there. A frame pattern is a collection of y/x off-setting coordinates for those tiles, indicating the location of the corresponding tile relative to the sprite's coordinates. A frame pattern ID (if I recall correctly) tells the game which set of y/x patterns to use for a tile. There isn't enough space for every tile to have its own pattern (a pair of bytes), so instead each tile has a (1 byte) frame pattern ID which references one of 256 pairs of bytes. This is one of the most irritating parts of editing frames in MM1. An animation is a collection of frames and a speed at which to display those frames.] Sprite Frame data: $18010 - Frame pointers for the first set of frame data (non-enemy data?)? $182BA - Table of pointers indexed by frame pattern index saying where at $19D82 to grab frame pattern ID $1834A-18449- Sprite frame pattern Y data. Each byte is an off-setting coordinate for one tile. Indexed by pattern ID $1844A-18549- Sprite frame pattern X data. Each byte is an off-setting coordinate for one tile. Indexed by pattern ID $18660 - Frame pointers for the second set of frame data (enemy data?)? $18780 - Enemy animation pointers (based on sprite ID) $18816 - Sprite frame data 1. First byte is number of tiles. Second is sprite frame data index to use for this frame. Then come 2-byte sets, each being a tile ID and its attributes. $1959E - Sprite frame data 2. For enemies, maybe? $19D82 - Table of frame pattern IDs. One ID per tile of a frame $1A291 - Animation table: High nybble of the first byte determines the number of frames. Low nybble determines delay between frames. The following bytes are frame IDs. Fiddle around with that and perhaps it'll help. If you have questions, feel free to ask, though I don't know how much help I'll be able to be. It's been nearly 2 years since I've worked on MM1 frame data. Good luck. |
| NetSplit |
| ||
|
Level: 32 Posts: 63/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Posted by CKY-2K What the fuck is wrong with you? You always spout so much shit. Just because there happens to actually be a decent number of Mega Man hacks lately, you bitch about it? This is a series that receives very little attention by non-Japanese hackers (ignoring significantly shitty hacks, of which there are a few) despite the excellent tools available. Maybe you should start bitching about the games that really are overhacked and becoming very stale, instead. Or better yet, STOP BITCHING. Consider making posts that are more contributive than the shit I often see from you. I'm growing tired of your overly-negative outbursts. I don't feel bad about writing this post; I've seen enough of these sorts of posts from you and started writing up enough responses that I decided it's finally time to actually say something. Knock it the fuck off. Regarding the hack, I've never seen it before. There's a large number of Japanese Rockman hacks, most of which are pretty decent. I'd actually be interested in seeing more of them, since I'm sure the majority of them don't catch our attention over here. Those Japanese hackers are definitely hardcore. Does anyone know of any less-known Japanese hacks that are worth playing? |
| NetSplit |
| ||
|
Level: 32 Posts: 64/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I've got a Mega Man 1 hack in the works, myself, but all the work I've had lately in college and the sheer size of the project have kept me from working on it and being motivated. Perhaps I'll be more willing this summer, assuming product testing doesn't keep me from wanting to ever play a video game ever again. 
Are there any good Rockman 1 hacks around? I've still not seen any Mega Man 1 hacks that I think are really worth playing, and I only know of one especially good Rockman 1 hack (Rockman 2000, I think it's called. Kuwata made it). It's a shame, really, as it's my favorite of the NES Mega Man games. |
| NetSplit |
| ||
|
Level: 32 Posts: 65/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Posted by Insectduel Not true. Prior to then, Kent Hansen's MegaEdit was around, albeit difficult to find and incredibly limited. It can edit most (but not all) screens in the game, and that's it; no sprites, scrolling, stats, etc. visine and Rock & Roll made the game far more hackable, though. |
| NetSplit |
| ||
|
Level: 32 Posts: 66/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Interesting screenshots. In some ways I'm impressed, in some I'm amused, and in yet others I'm irritated. Why must so many Mega Man hacks be crossovers, and most specifically SMB1 crossovers? This is the third one I've seen recently that's done this, and it bothers me to no end. Can't people make a hack that tries to be an actual Mega Man game?
The amusing part is the use of the MM2 intro graphics for a stage. My (slowly developing) MM1 hack uses this graphic set, as well, and I've seen it done a few times before. Guess I should find another graphic set to rip instead for more variety.
Aside from that, though, the hack at least looks quality. Your graphic rips all look pretty nice; I'm speaking specifically about the Blizzard Man stage graphics. I know it's hard to pull off decent rips from MM3+ because of the different TSA format in those games. The minute amount of stage design shown in the shots looks decent; I see no major pitfalls or major signs that there might be pitfalls elsewhere. I should note, though, that in the Blizzard Man screenshot, the first mountain looks pretty odd because the right side of the mountain cuts off behind the mainground. Perhaps a repositioning of the second mountain might improve matters. Also, I suggest a little bit more work should go into the title screen; currently, it looks like a mish-mash. The BEGIN! text also looks out of place (partially because it's off-center). I recommend removing that text and eliminating the wait time between when you press start and when the boss select screen shows up. It shouldn't be too hard to do this using FCEUXD. I'd give you the ROM address for the timer, but I apparently neglected to put it in my notes when I found it a couple years ago. Good luck on the hack.  |
| NetSplit |
| ||
|
Level: 32 Posts: 67/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
As I actually expect to have this hack done in a reasonable amount of time (read: I expect to release it in completed form someday), here are some shots of what I've been doing to Battle City for my hack, Battle Nation:
This shows the player starting in stage 3. This is the first time through the game, not the second, so there wouldn't normally be 4 enemies spawning at once, but as you get further in the game, enemies spawn faster until there's no delay. This is demonstrating having 4 tanks spawn in at once using my new spawn format, which defines 8 locations per stage for where enemy tanks are allowed to spawn. It picks from this list randomly (though not randomly enough, in my opinion. I might look into that). 
This shows stage 2, similarly to the shot above. Of note is the item that's already there; when the player starts a stage, there is one item available, placed at one of two locations (which may be the same). Items are the grenade, stopwatch, shovel, and shield; I've disabled the extra man item and the star (upgrade) item. The starting item stays throughout the stage and is sort of like a POW block, to use in case of need. 
These images show the new upgrade system; shoot the flashing tank, get an instant upgrade. I intend to make the window of opportunity limited by making the tank stop flashing within a set period of time. Furthermore, the number of tanks and even specific tanks that flash can be defined by the game designer; my new enemy format achieves complete freedom with regard to enemies (shield status, item status, tank type all definable on a per-tank basis). All 8 tanks may be used as enemies, and all work properly. Also worth noting is the rubble system I included, so now destroyed walls leave behind rubble. Furthermore, I'm removing the score system (tanks no longer display a score when destroyed and the score calculation screen has been disabled) in favor of a kills system; your kills will be tracked (kills with the grenade will not be counted!) and you get an extra man at every 50 kills. I intend to release information with the hack on how to use it as a base for new hacks. I'll probably also talk with Quarrel's programmer at some point to see if he'll add support for hacking my version of the ROM. Edit: Suggestions are welcome. |
| NetSplit |
| ||
|
Level: 32 Posts: 68/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
So far as I know, the only thing Rock & Roll checks regarding your ROM is ROM size (and possibly some header information? Doubtful), so this doesn't mean your ROM is bad. This indicates that it simply can't find your ini file. There should be a folder where the editor is called Data. In this folder should be a file called Mega Man (U).ini (there's also a Mega Man (E).ini, and if you ever make heavy changes to the ROM (assembly-related), you can make your own custom ini, like I have). If it's not there, redownload the editor, as the zip will surely contain the ini.
Hope that helps. |
| NetSplit |
| ||
|
Level: 32 Posts: 69/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Early warning: You're going to need a hex editor. But don't worry; they're not scary. If you don't know how to use one, ask and I or someone will help you. Otherwise, this post is everything you'll need. I tried to explain everything (even the technical stuff, if you're interested) so that you'll understand it without too much prior knowledge, but I assume you know how to use a hex editor and know about addresses and such. Read on.
The .ini file does nothing to your ROM; the various ini's are in charge of telling the editor where certain data is. The advantages to an ini file (as opposed to having no ini file, and thus all of the data is hard-coded into the editor) are that it makes the data available with minimal effort for anyone who's willing to wade through the ini for it and it makes the editor more flexible, so if you were to hack the game so that a level is at one location rather than another (which, in fact, I've done) or something of that sort, you can just modify the ini file and the editor will continue to work with the ROM. My point is, editing that in the .ini does absolutely nothing. What you want is the palette cycle sprite, which is sprite #$32. You'll see that it's placed at the beginning of Fire Man's stage; it initiates the palette animation. If used in Fire Man's stage, it uses the palette cycle for the lava, whereas it will use the Wily2 palette cycle that is used at the Mega Man clone boss if you use it in any other stage. I assume you want to preserve the clone's palette animation, so if you simply change $1F3E6 in a header ROM from #$03 (Fire Man's stage) to #$06 (Wily1), then Wily1 will be set as the exception stage for the palette animation rather than Fire Man's stage. If you're interested more in how this works, #$32 is a sprite object, so if you check the sprite AI (every sprite has some sort of AI in the code, and they all come in a conveniently organized section of the ROM), there's code for #$32 at $1F3CD. If you go through this code a bit, you'll come across this (of which the first two lines are the main ones we care about): 0001F3D3: A5 31 lda CurrentStage ;Load the current stage to the A register 0001F3D5: C9 03 cmp #$03 ;Compare it to #$03 (Fire Man) 0001F3D7: F0 05 beq + ;If Fire Man's stage, branch ahead 0001F3D9: 18 clc 0001F3DA: 98 tya 0001F3DB: 69 05 adc #$05 ;Not Fire Man's stage, so add #$05 to the palette address 0001F3DD: A8 tay + 0001F3DE: A2 00 ldx #$00 ;Make X = 0. - 0001F3E0: B9 F2 F3 lda Object32_paletteTable,y ;Load from the table + Y. Y starts at 0 or 5. 0001F3E3: 9D DD 03 sta BGPalettes + $D,x 0001F3E6: C8 iny ;Increment X 0001F3E7: E8 inx ;Increment Y 0001F3E8: E0 03 cpx #$03 ;Compare X to 3 0001F3EA: D0 F4 bne - ;If it's not 3, go back Object32_paletteTable: .byte $26, $16, $06, $26, $16 ;FireMan palette cycle .byte $21, $25, $2A, $21, $25 ;Elsewhere (Wily2) colors Hopefully this hasn't made your eyes glaze over or anything. The short, simple explanation is that you care about the VERY start of this code. The code loads the current stage and then compares it to Fire Man. You want to compare it to Wily1. The order of stages is Cut, Ice, Bomb, Fire, Elec, Guts, Wily1, Wily2, Wily3, Wily4, [Wily5/Title], Ending (valued #$00 through #$0B, respectively). Thus, you change the #$03 to #$06. Pretty simple. Also worth noting is that table. The Fire Man palette stuff is in that table there, which is located at $1F402. But this code also tells us that $1F407 is the location of the palette data for the non-exception stage (so the MM clone battle's palette cycle), because it's $1F402 + 5 (we add 5 if it's not Fire Man's stage). Hope that helped. Got questions? Please ask. Edit: Fixed a typo in the address of the byte in question. |
| NetSplit |
| ||
|
Level: 32 Posts: 70/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I had meant to type 1F3E6. Sorry about that. If you look at the code I posted, you'll see that #$03 at $1F3D6; that's the one we're editing. We add #$10 for the header in the .nes ROM, so the address winds up being $1F3E6. |
| NetSplit |
| ||
|
Level: 32 Posts: 71/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
If you have any other questions, just ask. I probably know most everything about the stuff you'd want to edit. |
| NetSplit |
| ||
|
Level: 32 Posts: 72/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
If you stick the data for the ending into the ini, then the editor should support it. You'd have to change the number of levels to 11 rather than 10 and put in the various bits of necessary info for level 11, but it SHOULD work. Note that the latter 6 levels share data with the former 6 levels, so the ending shares with Guts Man. All of the data for the ending comes after the data for Guts Man in his block, which is the 14010-1500F block.
The title screen uses a unique format that you wouldn't be able to edit in Rock & Roll; it's nothing like a level. If you did add level support for Wily5/title, though, you'd be able to see the 5 or so unused screens for Wily5 that are there. They're pretty ugly because no graphics fit them, but the design is clearly unused screens. |
| NetSplit |
| ||
|
Level: 32 Posts: 73/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
The ending doesn't use special objects or enemy data, so there's no offset to give. If the editor requires something, just point it to an FF for the enemy data (FF terminates enemy data). For the special object data, I'm less sure what to tell you; the first byte says how many objects there are, and then each object is 6 bytes. The final object must be 01FF00000000. Pointing the editor to a 00 might work, though, since it'll (hopefully) tell it there are 0 objects. |
| NetSplit |
| ||
|
Level: 32 Posts: 74/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
If you change the text back, does it go back to normal?
You may have messed with one of the text control codes that come at the beginning and end of lines of text. Just be careful with changing those values. I've not looked into them, so I don't know their format. It looks like there's a #$22 in every one; I recommend not changing that byte. I don't remember what it has to do with, but I think I saw stuff like that elsewhere with drawing to the screen. Might be address-related. |
| NetSplit |
| ||
|
Level: 32 Posts: 75/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
You can still change it a lot, but be mindful of those codes. If you fiddle with them a bit, you'll probably be able to figure out the format enough to have a lot of freedom with your text editing. |
| NetSplit |
| ||
|
Level: 32 Posts: 76/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
The ending is an exception stage and disregards special object and enemy data, so far as I know. The enemy data pointers are located at 1A462. There are a total of 11 pointers: 1 for each of the 10 used stages and 1 for Wily5 (I argue that the game was originally going to have 11 stages. There probably wasn't enough space for everything required by another stage (boss AI, for example)). The ending would be pointer 12, but there is no pointer 12; the enemy data starts immediately after the 11th pointer. The enemy data could all be shifted over by 2 bytes, though, and a 12th pointer could be added.
If you really want enemies in your ending, I could look into how to get them to work. There's only one A531C90B and, even more telling, only one C90B (A531 = load current stage, C90B = compare to #$0B. #$0B = ending stage ID), so getting the enemies working would require figuring out where the enemy loading code is and jumping to it rather than just killing off a comparison. It's probably doable. Why do you want enemies in the ending? |
| NetSplit |
| ||
|
Level: 32 Posts: 77/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
The code you're interested in is this:
Basically, you just need to be doing all the energy calculation stuff at $A725 rather than later on; the calculation code is currently run AFTER the weapon is already launched, I think. If using the weapon will give you a negative Meters,X value, then RTS. This will make it so that you can't use a weapon if the the current energy is less than the consumption. Or, if you want a weapon with a consumption of, say, 3 to fire when you have 2 energy, then just zero the energy instead of letting it become negative. If this is how you'd prefer to do it, then all you need to do is this:
|
| NetSplit |
| ||
|
Level: 32 Posts: 78/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I figure it'd probably be pretty difficult to achieve that. One of the problems is randomness; it's likely that the variable that determine randomness won't always be the same every time the ending is reached, and the vertical movement of those foothold enemies is random. I suppose you could set the randomness variables to specific values at the beginning, but even then, MM1 doesn't seem conducive to this sort of setting because Mega Man doesn't slide on any surfaces like Mario does. You'd have to hit him a lot and properly, and make good use of non-random foothold enemies and moving platforms (of the sort in Guts' stage) |
| NetSplit |
| ||
|
Level: 32 Posts: 79/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I justed looked at the Footholder code and it uses the random function. The random function returns a random value between 0 and the value passed to it based on the random seed. The seed is written with this code:
So no, it's based on the frame counter, not MM's movements. On the plus side, though, setting the frame counter and random seed to 0 at the start of the ending sequence should make it act the same every time through. And I had thought that Mega Man would be standing still. It makes more sense if he's running, but the game's lack of slopes would make it difficult to move Mega Man upward after he's fallen any distance. The footholders are too thin to be useful, since Mega Man would run off of them before they raise him much. |
| NetSplit |
| ||
|
Level: 32 Posts: 80/178 EXP: 188115 Next: 18327 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Well, when you're invincible, your collision with sprites that can hurt you is disabled, so you no longer collide with the footholders and thus fall through them. I tested the moving platforms and found that you don't fall through those; it's likely because they don't hurt you.
I don't like to use sprite platforms all that much in MM1 because of that bug and because you drop like a rock if you fall off of them. There's also a bug with the footholders where the sprite flags for the shots that they fire are reversed, so the shots go in the wrong directions; the shot fired from the left moves right, and from the right moves left. If the platform is moving down, this can lower Mega Man into the shots before they've moved away from the platform, causing him to get hit and fall to his death. Those footholders were both a terrible idea and very poorly implemented. The gravity issue can also be fixed; I've done it before, but don't remember how. I'm sure I could figure it out again.
As for the sun, I don't know anything about it. It's not normal enemy data or anything like that, so I really don't know. I'll be looking into it at some point, since I want change the ending pretty heavily for my hack, if I ever get that far. Perhaps I'll check it out soon. |
| Main - Posts by NetSplit |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 32, rows: 64/64, time: 0.224 seconds. |