 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,511,392 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-02-24 08:27 AM |
|
| Guest: Register | Login | |||
| Main - Posts by NetSplit |
| NetSplit |
| ||
|
Level: 32 Posts: 121/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Of course there's interest.  It sounds like it'd be a very cool project, but it's certainly a massive one, as well. Good luck.  |
| NetSplit |
| ||
|
Level: 32 Posts: 122/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
A gold star to anyone who can figure out everything that's different. |
| NetSplit |
| ||
|
Level: 32 Posts: 123/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
You likely never heard of it because it wasn't (to my knowledge) released in the US. There are a lot of hacks for it because it's simple, fun, and has easy data formats. I'm hacking it because it's simple, fun, and has a lot of possibilities for an assembly programmer such as myself. |
| NetSplit |
| ||
|
Level: 32 Posts: 124/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Trax: Pretty observant. Yes, tank upgrades are applied immediately upon destroying flashing tanks (although there's a bug in this currently that I haven't been able to fix yet. You can see it happen at the end of Stage 3). The palette change is due to the new explosion graphic I made (I honestly wish item flashing were still using the old palette, but I can't have both  ). Spawn points are indeed at unique locations per stage instead of always at the same 3, which are at the top by default. There are actually 8 spawn points per stage, but I don't think I use that to its full potential in any of these stages. Points and the point screen have been removed, to be replaced with a kill counter on the gameplay screen that will go 0-49 and give you an extra man every 50th kill. Items are placed in a stage at one of two locations (selected at random). The items are currently randomly selected, but I may make it optional (random or a specific item). The brick debris is a pretty awesome change, in my opinion; it makes blowing stuff up a lot more satisfying.
In addition to those, there's a new enemy format that allows total freedom of enemy placement. I used 7 of the 8 available enemy tanks in this video (rather than only 4 normally used in the game). You can place shields of any amount on any specific tank and set any specific tank as an item carrier. It's pretty liberating, especially compared to the old setup of defining only 4 groups of identical tanks per stage. Then there's the tank spawning. The game will start with 4 tanks at most and a slow spawn speed, but speeds up over time and starts adding in more tanks. Around stage 20, it'll reach this speed (it actually gets a little faster, too) and spawn 6 tanks. In the second quest, the tanks you'll face are going to be even harder, capable of destroying those metal blocks that can only be destroyed by your most upgraded tank shots. The game winds up going a lot faster with this setup and being much harder. Aside from a bug fix or two, that's about all I've done currently. I'm interested in maybe adding more kinds of blocks and more levels, but I'm not sure yet. I might also add a new item to replace one of the two I removed. As for scrolling and shot cancelling, the original had the latter and not the former. The GB version had scrolling because the GB screen is so small. None of the arcade games have scrolling, either, as far as I know. I don't intend to add it in. |
| NetSplit |
| ||
|
Level: 32 Posts: 125/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I almost think Megaman Megaman would be pretty fitting, considering the Japanese name of Mega Man Powered Up. |
| NetSplit |
| ||
|
Level: 32 Posts: 126/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
While the title screen does need to be changed eventually, it's not at all the most vital part of this hack. I recommend starting on the hard and important stuff early on when you're motivated and working on trivial matters later on. Furthermore, if you find that you can't do the hard stuff, then you didn't waste your time on the easy stuff before abandoning the project.
Edit: Lock blocks. |
| NetSplit |
| ||
|
Level: 32 Posts: 127/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I'd leave it as-is except for the Powered Down text. If possible, it'd be neat to see that as something other than normal text. Do you have enough tiles leftover and do a small custom design for it? |
| NetSplit |
| ||
|
Level: 32 Posts: 128/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Kaneco: Welcome to the community. Sorry about the drama; unfortunately, some people aren't here to be constructive. If you wind up making a hack, I'd love to see what you come up with. Feel free to ask questions; there are experts on this forum for most NES MM games (myself for MM1, kuju killer for MM3, infidelity for MM4, Matrixz for MM3-5) who I'm sure would all be willing to help out with whatever MM game you may choose to hack. Personally, I love lending a hand, so don't hesitate to ask.
There are a bunch of good editors for the MM series. Mega Man 1 has Rock and Roll and visine, MM2 has visine, MM3-5 have MegaFLE, and MM6 has sixtans. There are also some Japanese editors available, though I don't know much about them. I can't really say which game is easiest to hack (though I think MM6 is probably the hardest), but I'm sure I speak with extreme bias by saying it has to be Mega Man 1.
Good luck. KP9001: Unfortunately, I'm yet another MM hacker not catering to the casual Mega Man gamers (read: my hacks require a shitload of skill). The hack I'm working on is very hard, but I'm happy to say that it's not difficult for cheap reasons; I'm following my own pretty strict rules on what constitutes a well-designed level. At the very least, Mega Man is known for being a challenging series (MM9 gave me a decent amount of trouble my first time through, which I thought was great), so it's not totally out of place. I share your irritation with hacks that have precognition as an undocumented requirement or require pixel-perfect movement. Balance can be great, and good design habits are key. |
| NetSplit |
| ||
|
Level: 32 Posts: 129/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
You'll need to write a routine that runs only on the title screen that puts the necessary sprite information into sprite RAM (typically 200-2FF). It could be as simple as finding a spot that's only run on the title screen and then loading the values and placing them in the right spots. Doing it a tile at a time without any looping might take up too much space, though; you should be able to condense it down using a loop and a few tables.
I think it's time to start picking up some assembly. |
| NetSplit |
| ||
|
Level: 32 Posts: 130/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I prefer the colors in the old screenshot, and I think you went overboard with the copyrights in the new one (furthermore, I feel that putting a copyright symbol next to your credit on an unauthorized use of someone's intellectual property is bizarre, at best).
If I were you, I'd figure out where the code is for the arrow sprite (#$86) that's onscreen, since that's drawn at the very start and seems to not show up when the title screen begins fading in exclusively because its palette is #$16 (2x palettes appear before 1x, and 1x before 0x). That's a reliable place to put the new code. Find it (easy), jump from there to some free space in the same bank, and put your routine. |
| NetSplit |
| ||
|
Level: 32 Posts: 131/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Assuming you're using some variant of FCEUXD (you basically need to be for effective assembly hacking on this system) or even (god forbid) NESticle, you can find that arrow tile easily by looking at the sprite pattern tables in the PPU Viewer for it. Anyone with eyesight can find it; it doesn't take any special knowledge. If you wind up having questions, feel free to ask, but definitely give it a shot first and see how far you can go. |
| NetSplit |
| ||
|
Level: 32 Posts: 132/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I don't know much about the later MM games (I've worked primarily with MM1, a lot with MM2, and some with MM6), so I don't know how MM5 handles its sprites. I know MM6 brings a sprite's graphics into the pattern table when it comes across that sprite in a level, but I don't know if that's done in MM5. MM1-3 definitely don't do it.
The issue you're having is differentiating between sprites as in enemies and items (I'll refer to them as objects or enemies from here on out), which have code, stats, animations, and frame data associated with them, and sprites as in the sprite tiles that are displayed onscreen. The enemy one is like an object with all of that information associated with it, and it has its identifier that is used in the enemy data for calling it during a level. A sprite tile is something on the sprite pattern table and has a specific identifier associated with its position on the table. Sprite tiles are built into the NES, while the objects are larger, artificial constructs not inherent to the system itself; you can, and often do, have objects without any actual sprite tiles associated with them (in which case the name 'sprite' really doesn't fit with it), and sprite tiles can often be placed on the screen without any sort of object identifier associated with them. To be more clear, for something like that arrow, I would probably program it so that the title screen routine is constantly drawing this arrow every frame (if necessary for the game) or draws it that first frame and doesn't touch most of it any more. It would store the arrow's tile ID, attributes, x, and y to sprite RAM, and there's other code that handles stuff related to menu selection, input, and all that. If something else is selected, the arrow is moved by drawing it with a different set of coordinates (or just updating the ones already in sprite RAM, if it only has to be drawn once), but it's still directly storing this information into sprite RAM; the arrow itself is not some sort of visual representation of an object with an ID but rather just a tile drawn to the screen. In this case, it's a small routine where the arrow is just a visual marker defined by the routine itself. It specifically uses the sprite tile's ID in the pattern table; there's no call to an object of which the arrow is a part. For an enemy or something of that sort, it's different; often there's a pointer in a table that points to the enemy's AI. The table is indexed according to the enemy IDs, so if you are looking at sprite #$47, you'd grab entry #$47 in the table and use that to get to the AI. Then there's a separate routine that handles the animation for that sprite, where animations are also being pointed to by pointers in a table indexed by the enemy's ID. The animation sets the speed of the sprite animation and which frames to use. Then there's frame data for what sprite tiles make up each frame, what palette they use, and how those tiles are arranged with respect to the enemy's coordinate. Frame data is the sprite tile part of this; it uses the literal sprite tile IDs in the table to identify the specific tiles used (or at least, usually does. I have no idea how it's handled in games where the enemy's graphics are brought into the table when the sprite comes onscreen, like MM6). So for enemies, the sprite you see is just a small part of it, and the whole enemy has an overall ID used to identify all of that. That ID is unrelated to the IDs of the sprite tiles the object uses. That was probably all long, bloated, and unnecessary, but I hope you get the idea from it. Using the sprite tile's ID can get you a lot of useful info in a game. In your case, it gets you the location of a routine, but you could also use it to locate frame data or even follow it backward to other object-related stuff (though that'd probably be a roundabout way of finding it), since it's all connected. You probably only need to deal with object IDs when dealing with sprites during gameplay, though it's important to point out that not all sprites in gameplay are part of objects (the life bars aren't). I hope that helps. |
| NetSplit |
| ||
|
Level: 32 Posts: 133/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
How are you looking? |
| NetSplit |
| ||
|
Level: 32 Posts: 134/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
The arrow tile is in sprite RAM, of course. Sprite RAM is at $0200. Find the arrow tile in sprite RAM and set a write breakpoint on it. Load the title screen. Routine found. |
| NetSplit |
| ||
|
Level: 32 Posts: 135/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
You know, to this day I've still not used that Code/Data Logger. I know it's a handy tool, so I can't really say why that is..
I think I was able to clear up many of kk's problems via PM. The tile is drawn using a shared title/boss select screen sprite display routine that loads tiles from a table. Even if the table were moved, it wouldn't be able to fit Mega Man's face for the hack's title screen because the table uses nearly all of its possible space (something like 244 of the possible 256 bytes). By following the RTS, you can get to the title routine that called the sprite drawing routine and modify that code to do a JSR to unused space for drawing MM's face. The problem he seemed to be having was that the sprite drawing routine was used elsewhere, so it's more general than it could have been. koala_knight: Sprite colors are determined by assigning them attributes. The attributes byte, of which there is one per onscreen tile, handles which of the 4 palettes to give the sprite tile (as well as what the tile's background priority is, but that's not relevent to this conversation). This means you can have a sprite tile used multiple times onscreen, but the color of that tile can vary being uses. The color of the arrow in the pattern table doesn't have to match oncreen, but you can right click the table to change the palette it's using in order to get it to look more like how it looks on the screen. Sprite palettes in the table use a gray color for the background rather than black because sprite so often have a black outline, so gray is a more useful color for the transparent background than black (which would match the outline). Maybe I'm misunderstanding your post, but I think this might address your comment. |
| NetSplit |
| ||
|
Level: 32 Posts: 136/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
The problem is that the table contains not only the tile IDs but also the coordinates and attributes. If the coordinates for his face were the same on both screens, then you could reuse the data. They're not, though, so you need to handle it differently. |
| NetSplit |
| ||
|
Level: 32 Posts: 137/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
If you rearranged it so that his face is in the same spot on both screens, then you can move his face at the start of the boss select screen data and make the title screen use those tiles, as well (you'd be shifting some data in that table and changing 1 byte in a routine). But why? Why would you rearrange the screen entirely in order to make a simple assembly hack a little easier?
Just do it whatever way looks best. Adding the face is a trivial change for anyone who knows 6502; regardless of how you decide to arrange the title screen, at least try to figure out how you'd do this hack so you learn something from it to apply to later, more difficult parts of the hack. Hacking the title screen is probably going to be the least of your worries in this project. |
| NetSplit |
| ||
|
Level: 32 Posts: 138/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Yes, let's criticize people who don't speak English as a first language for not having perfect grammar and punctuation. That sounds awesome.
You know, I see nearly unreadable posts by people who speak only English, but people very rarely seem to bitch about that (though they should). Give the guy a break. It's hard to learn a new language. |
| NetSplit |
| ||
|
Level: 32 Posts: 139/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Don't make a patch for this. Maybe it'll be good incentive for people to learn how to mess with hex. It's stupid to supply patches for every little thing, especially with offsets that could overwrite assembly hacks and such in existing Mega Man hacks because it uses the very beginning of the game's limited last-bank free space. Currently, Mega Man 1 editors are limited enough that anyone wanting to do a good hack needs to dabble in hex, if only to fix bugs that editors create. I like helping people out, but I hate this spoon feeding mentality we have when it comes to simple hex edits. If someone can't use a hex editor to plug in values in a ROM at specific addresses for their hack, they probably shouldn't be hacking.
Insectduel: Nice find. I don't think you can do it without eating up some free space, unfortunately, but your routine can be made more efficient, both space and cycle wise. The routine should be A9 1C 20 77 C4 4C 4F C7. Your routine uses an extra JSR and RTS, while doing it with just a jump will get it back on track; the stack only tracks where you came from, not where you're going. Also, to make it more clear for anyone who may want to use this hack:
You can use addresses other than $1FF10, but be sure you change the 00FF ($FF00 in loaded ROM) to accommodate that |
| NetSplit |
| ||
|
Level: 32 Posts: 140/178 EXP: 188120 Next: 18322 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Well, the location of code within the same #$4000 byte bank won't matter, since entire banks are loaded at a time. Therefore, you can use any address from $1C010 to the end of the ROM. The other bank that's loaded on the title screen is bank 5 (Elec Man's bank), so you can use free space in that bank for the code, too. I'd be surprised if you couldn't find free space in that bank, since Elec Man's stage is the only one not split with another stage (Wily stages 1-4 and the ending). You can use extra space in areas like the level or TSA data, among others. Typically, if you can put a routine in a bank other than the last bank, you should, because you can't always do it and want to save that last bank's space for those routines. |
| Main - Posts by NetSplit |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 32, rows: 64/64, time: 0.231 seconds. |