 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,511,844 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-02-24 10:14 AM |
|
| Guest: Register | Login | |||
| Main - Posts by NetSplit |
| NetSplit |
| ||
|
Level: 32 Posts: 161/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I'm not entirely sure from your post, but your problem is just making the rope be a ladder, not changing the scroll direction, right?
Each level can only have 4 different kinds of background properties out of a total of 6 (air, solid, ladder, spike, ice, water. Fireman uses a 7th, but it acts as air). If you're using the Rock and Roll editor, you can change which ones your current stage uses with the Tools -> Level Properties menu. Guts Man doesn't use ladders by default, but it actually only uses 3 types normally, so you can make the 4th type be ladders and then set your rope to use that. |
| NetSplit |
| ||
|
Level: 32 Posts: 162/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
When you enter a boss room, the game makes the screen flash briefly using a separate palette that you haven't set up to use colors similar to your standard stage palette. My notes say that stage palettes are at $xxCB0, so I'd guess the palette you need to edit is somewhere between $14CB0-14D0F. I haven't messed with Rock and Roll much in a while, so I don't know if it supports editing this palette, so you may have to do it in a hex editor.
Actually, I just did a quick check (played to Guts Man, checked the palettes, and did a search) and found that it is the 16 bytes of background palette at $14CD0 that are used for the flashing. Just change them to work with your stage's palette and you're good. If you want the correct flashing effect to stay, you'll probably want to leave the first 4 bytes as 0F302010. For the checkpoints, you must have moved the checkpoint such that it drops Mega Man at a coordinate that doesn't end in 4. The low nybble has to be 4 or you'll get that behavior. You can easily fix that with the table at $1C52A, where there are sets of 12 entries for the start, mid, and end points. The entry order is cut, ice, bomb, fire, elec, guts, wily1-4, unused (wily5), and unused (ending). Just find the Bomb Man stage checkpoint you moved and make it end in 4 and it should work fine. Also, in that video, be careful around 1:47, since the way you set up the stage makes it so someone could conceivably scroll onto that screen too low, which would cause them to get stuck in the floor, zip to the right, and die in the pit, which is a cheap death and probably not what you intended. |
| NetSplit |
| ||
|
Level: 32 Posts: 163/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Posted by Zieldak You can disable the flashing effect by changing $1532D to EA EA. I figured this out by watching for reads to the flashing palette (happens at the start of a stage), watching for reads to the RAM copy of the flashing palette, finding the routine that was responsible for the flashing, looking at how it generally gets called in bisqwit's disassembly and finding the value at $37 for controlling it, and then watching for writes to $37 right before the flashing began. Googie: I noticed in your video that your ropes end in solid objects, which I generally advise people to avoid because of the crazy behavior you get when you climb to the top of those ladders, but given the theme of your hack, there doesn't seem to me to be a reasonable way around the problem. So, I developed a small change that should hopefully fix the problem; I haven't tested it thoroughly, but it seems to work for me without any obvious bugs, at least.
I haven't done too much testing, but this looks like it works. I don't intend to support this assembly hack in the future, but if you find a problem with it, I might be willing to take a look. The problem is that this delves into internals that I'm not at all familiar with, so I had to fumble around a bit to arrive at this. The assembly:
Note that the bulk of this is in free space I chose in the same bank. If this conflicts with other custom code (free space is limited), you can move the stuff at $17F86 (that code is position-independent) and update the jump at $15861 to point to the new location. |
| NetSplit |
| ||
|
Level: 32 Posts: 164/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
If you can be more specific, I can help out. This shouldn't be very hard to fix. |
| NetSplit |
| ||
|
Level: 32 Posts: 165/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
For the gutsblock thing, I'm not really sure what's going on there, but Rock n Roll probably messed up that data somehow when you tried to delete the blocks. If you post the special object data for your stage, located from $10E10-10EAF, I can take a look at it. I may also need to know what screen the boss room is on (how far into the stage it is, not its unique ID).
As for your issue with the game crashing when you're climbing the ladder after a checkpoint, that implies that one of your checkpoint settings is done incorrectly. My guess is that you changed the number of sprites before and after the boss checkpoint and the game is trying to use an invalid sprite whose AI causes a crash. When you do things like change the length of corridors, add or remove corridors, or change the number of sprites before the end of the screen a checkpoint occurs on, you absolutely must change the data that I describe in this post (which has all the data) and this post (which has further explanation). Checkpoint bugs are one of the most common bugs I see in Mega Man 1 hacks and it's because people never ever update that data to work with their changes. Even if you're just editing enemies and keeping the same number in the stage overall, it's very likely you still need to update checkpoint data. If the bug only occurs after you start at a checkpoint, that's a pretty solid sign that this data isn't right. Zieldak: The level data region is only long enough to hold 32 unique screens, so editing beyond that will overwrite other data used by the same level. I'm a little perplexed by the chunk of data immediately after the level data region, though; it's 64 bytes (enough for one full screen) that I don't see used in Bisqwit's disassembly, and I don't have it in my notes, either. There's something there, but whether it's used for anything is a total mystery to me. |
| NetSplit |
| ||
|
Level: 32 Posts: 166/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Zieldak: Like I just posted in Googie's thread, you have to keep your checkpoint data synced up with your changes to scrolling and enemy data. This is covered in this post. It sounds like you just shortened the 3 screen corridor to 1 screen, but because you didn't change the table at $15422 that contains the last screen in the corridor, the game will ignore that change when starting at the checkpoint in that corridor. Either update that table or change $150F7 to 4CF690 in order to ignore that table entirely and use a correct value that is automatically calculated, instead. Depending on what all you've changed, you might have to do more than just adjust that table, but this will probably get you at least part of the way there. If it's a bug that happens only after you've started at a checkpoint, you almost certainly need to change one of the checkpoint tables. |
| NetSplit |
| ||
|
Level: 32 Posts: 167/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
There's a 6 byte table at $1C15E that contains the index of the special object that is removed upon beating each of the #$3B bosses. The indices are multiples of 6 because objects are 6 bytes long. The first object is 0, the second is 6, etc. |
| NetSplit |
| ||
|
Level: 32 Posts: 168/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Insectduel: Put a read breadkpoint on the special object data location, start a stage to break on the code that copies that data into RAM, and trigger that code in the checkpoint handling routine (which you can track down using breakpoints on checkpoint data). I highly suggest looking through bisqwit's disassembly on the matter, as well; he refers to special objects in there as "actives".
Zieldak: I think you'd benefit from looking at Bisqwit's disassembly to see how some of this stuff is usually done in the standard ROM. Your many many lines of code for getting 6 data values could be done with a table, which are used all throughout the existing code, or perhaps some clever tricks based on what data you're using. Here, you have the 6 bosses appear on consecutive screens in their ID order, starting on screen #$1D, so you could get the boss ID for a #$3B object by just subtracting #$1D from the screen number. You also need to be very careful with modifying code; your jump at $BDB8, for example, jumps into the middle of an instruction, which (while sometimes a legitimate tactic) is probably not what you want. Your code at the end is also pretty nonsensical; I assume you're trying to load the values like you would with a table, but the mechanism you're trying to use for doing it is a mystery to me and surely will not work the way you imagine it. LDY will set or clear the zero flag, so loading any of those values will cause the BEQ to never be taken, and it's unclear if you want to be able to fall through from one section to the next or what. Generally, if you have code that is repeated over and over with tiny differences, you can probably wrap that up into something small with a gain in space and maybe even performance. |
| NetSplit |
| ||
|
Level: 32 Posts: 169/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I understand what you're doing now. Yes, you want to use the same number in all of those places with your LDA because the current screen is in a fixed address. However, that address is not $20; $20 is related to the current scroll location, and while it'll probably get you a similar result, you should actually be using $1B. You can find that value in the diassembly by looking for where bisqwit sets the label equal to a value near the top of the file.
If you moved Wily by 2 screens, try moving the 63 63 values at $CD72 in the same direction by 2 bytes. |
| NetSplit |
| ||
|
Level: 32 Posts: 170/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Making the black at the bottom be foreground is not a correct solution. Backgrounds on the NES are not drawn in front of or behind sprites; instead, sprite tiles carry with them a priority that makes them be drawn in front of or behind the background. If you made the black a non-transparent color and made the ship be drawn behind backgrounds, it would also be drawn behind the buildings, which is certainly not what you want.
There are two correct solutions here that preserve the black bar. You can turn off sprites entirely starting after the last non-black scanline, but the timing for this may be difficult and it's possible you could get some onscreen glitchiness. Or, you can place 8 sprite tiles on each row of the black section with a draw priority higher than the ship so that the ship isn't drawn on those rows. Note, however, that many emulators allow the user to turn off this 'feature', which would negate your work, so the first solution is probably more likely to work. For reference, Zelda 1 uses the 8 tile trick to make Link invisible when walking through north or south dungeon doors, and that emulator feature breaks this trick. If the number of tiles you need for this is too much, you could do just one row and change how the ship comes onscreen (having its tiles not be drawn if they're below that row, so it appears row by row), or you could cut the required tiles in half by switching to 8x16 sprite mode. Edit: Fixed an omitted word. |
| NetSplit |
| ||
|
Level: 32 Posts: 171/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
mickevincent: No, that's not what I was saying. Every single sprite tile onscreen has a priority bit that indicates if it's foreground or background. My point is that this is a property of the sprite, not the background, so while you can make the black bar at the bottom be non-transparent and make each tile of Wily's ship be drawn behind the background, they will also be drawn behind the buildings. There's no way to properly do the transition from background to foreground smoothly in this case because there is no ~8-pixel tall background segment that is transparent-only in which to do the transition.
What you're thinking of is in-game tile properties, where the game checks to see what tiles Mega Man is colliding with and does the appropriate behavior, which may be setting Mega Man's entire sprite to be background instead of foreground. There probably isn't any background collision in this cutscene, though, and the problem I describe above still affects it. |
| NetSplit |
| ||
|
Level: 32 Posts: 172/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Posted by mickevincent Assuming you mean that values in the $200-$2FF page are getting moved around rapidly while the game is running, this is meant to constantly change sprite drawing priority. The NES can only draw up to 8 tiles on a single scanline; all other tiles on the same line won't be drawn on the screen. Rapidly rearranging the tiles in memory will change the order in which they're drawn and produce flicker if that limit is exceeded. Flicker is generally a better solution than having the same tiles not be drawn frame after frame. This strategy isn't universal; while the Mega Man games do it, I think Bubble Bobble doesn't, so you can get some sprites fully obscured by others on the same scanline. Another reason to do flicker is because the order of the sprite tiles determines whether a sprite appears in front of or behind another sprite. Shuffling sprite data will make sprites flicker if they're drawn on top of each other, while keeping it stationary will make tiles consistently appear in front or behind others. Also, to add to infidelity's earlier explanation, the byte that controls the palette of a sprite tile also controls its mirroring (x and y) and it's background priority (drawn in front of or behind the background). Edit: But I think you may be saying that the tile you added visibly flickers onscreen, while the rest do not. I'm not sure what you're doing or not doing that would be causing that. |
| NetSplit |
| ||
|
Level: 32 Posts: 173/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
When you beat a #$3B boss, the game removes a special object at a specific index, allowing you to exit the room. The table containing these indices is located at $1C15E in the headered ROM for both US and J versions. The values are multiples of 6, since special objects are 6 in size, and the order is the typical cut/ice/bomb/fire/elec/guts. You'll need to adjust these values if you add or remove objects before the #$3B bosses. |
| NetSplit |
| ||
|
Level: 32 Posts: 174/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I don't know all that much about Mega Man 2, but it's heavily based on Mega Man 1 and the checkpoints have a lot in common. In Mega Man 1, there is a table of which enemy index to start on for a given checkpoint. The way enemies are loaded is that they keep an index of the next enemy slot on the right and the left and check only those enemy slots when you scroll right and left. When an enemy enters or leaves the screen, it adjusts the indices accordingly. This is why if you put enemies out of order (a lower index enemy to the right of a higher index enemy), the higher index enemy doesn't load until the lower index one has come onscreen.
When you start at any checkpoint (start/mid/end), the game sets the indices based on a value in a table. If this value is wrong, then as soon as you move, the game will load everything between the current index and where the index should be. I think the problem in your hack is caused by this value being too high; as soon as you move left, it loads every sprite from the end of the stage to the start. I haven't looked in an editor, but I assume the dragon boss is a sprite, which is why the boss loads as though you're at the end of the stage. I dug around and found that the byte you're looking for is at $3B1F in the US ROM. I haven't tested it, but the data looks identical in the Japanese ROM, so it should work there, too. This byte is part of a table that actually starts at $3B1C. Each level bank contains one of these tables at the same offset, and I assume there are 8 (one for each of the first 8 stages). The index is the checkpoint number, so the first 3 bytes are the start, mid, and endpoints of that stage (the first byte should always be #$00). The next 2 bytes are for the Wily stage checkpoints. Because data is shared between the stages, the starting index for the Wily stage enemy data is not #$00. You'll need to adjust it to the appropriate value, whatever it is. That will depend on your hack. You might be able to figure it out by counting the sprites in the corresponding stage, or you could look in the enemy data table if you know where it is and see at what index the first Wily 1 enemy is. Hopefully that helps. If you'd find it useful, I'm happy to post how I figured this out. |
| NetSplit |
| ||
|
Level: 32 Posts: 175/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I haven't tested this much, but at offset $3470 in each level bank are sprite graphic sets for the bank. Each entry is #$12 bytes in size. The first 12 bytes of that are pairs of bytes for each row of the set, and the next 6 bytes are the palette data for that set. At offset $343C is a table of which of these sets to use for each corridor. These values are all multiples of #$12. |
| NetSplit |
| ||
|
Level: 32 Posts: 176/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I'd honestly prefer to not see any more of these multicart hacks. Particularly if they're utilizing MMC5 hardware, they encourage people to harvest rare cartridges, both individually and in larger-scale "production" runs, which drives up prices and depletes a limited resource. The one major feature these hacks add to these games is only really useful on real hardware, further encouraging this behavior.
If making more multicart hacks is really that important, I suggest sticking with a more conventional mapper that works flawlessly on flash cartridges or has brand new reproduction boards available, such as MMC3. That said, I'd rather see people spending their limited time and energy on making something new and interesting or substantially improving an existing game, not pasting several together into a single ROM and probably introducing new bugs in the process. Regarding other patching formats, there exist ones which can move data around in a target file instead of containing the values of all bytes that differ. xdelta is one such format. However, I don't know if any are able to take multiple source files to produce a single destination file, which is really what you want for this sort of project to avoid distributing one or more entire copyrighted works. |
| NetSplit |
| ||
|
Level: 32 Posts: 177/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
When you're doing a code dump on the forums, can you explain where in the ROM you intend the code to go and how the code is different from what you're replacing? Your code has no comments and little context, so even for technical people like myself, it's not clear what its purpose is supposed to be or if it's even at all correct. |
| NetSplit |
| |||
|
Level: 32 Posts: 178/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Your update helped enough that I was able to look into this now, but I should probably be more specific about what I was looking for. In particular, things you should probably include when posting a block of code are what game it's for (we're talking about both SMB and Zelda here. Is it both?), what it is (bankswitching routine), where it's located ($FFAC in several banks for Zelda, or give the actual file address if relevant), what bug you're fixing, what's wrong with the original code, and what your fix does to solve that. I haven't been able to figure out the answers to those last 3 points yet.
This code looks pretty crazy to me in general, so I decided to look into it. First, I don't know what you think your change fixes, but it should have no effect. STA doesn't change processor flags, so there's no reason to PHP before and PLP after. Second, the pushes originally present in this function are all totally unnecessary. One can have a fully equivalent function without them:
The register writes also seemed a little strange to me, so I looked up the MMC5 documentation. Looking at Legend of Link, this game runs in PRG mode 1 ($5100 == 1), which has two 16 KB banks. These are configured through registers $5115 (PRG bank 1) and $5117 (PRG bank 3). In mode 1, register $5114 is completely ignored, so there's no reason to be writing it in this function. These registers also only take one write, but this function writes to each twice, so the effect of the first write is lost. Finally, in mode 1, the lowest bit of the write is ignored, so there's no reason to be OR'ing by 1. That means this is a totally equivalent function:
Further still, I can't find any reference to a register $A001 in the documentation. I have no clue what this is intended to do, and removing the write to it doesn't seem to cause any noticeable problems in the emulators I've tried. This function should probably just be:
All-Stars is probably similar, but could be more complex because the different games it has to run may have different requirements. Edit: Assuming the value being passed in is always a constant, that constant could be changed to already be shifted left by 1 and OR'ed by #$80. Then the JSR to this function could be replaced with just the STA $5115. No need to call a bankswitch function at all. |
| Main - Posts by NetSplit |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 33, rows: 63/63, time: 0.251 seconds. |
But wathever I writes to $200-2ff is flickering. I see that it wants to write f8 to many of those places. But the place were mega man is stored is also flickering in the ram, but mega man himself doesnt flicker. I dont get why.