 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,435,635 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-19-24 11:27 AM |
|
| Guest: Register | Login | |||
| Main - Posts by Trax |
| Trax |
| ||
 Yellow Stalfos Level: 71 Posts: 845/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
That's right, .dat stands for data, which means it's a file that contains data...
Noooo? Really? Well, yes... It's up to you to find a .dat file with a data structure that the program understands... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 846/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Dang, people really don't get it, or what? |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 847/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Posted by Arbe Hmmm, look who's talking... Arbe must be the kind of guy who goes absolutely nuts and cynic when he doesn't understand something... Life is hard... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 848/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
I presume disassemblers for the NES are different from disassemblers for the Sega... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 849/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
I made a video of some of the tweaks and ASM Hacks I could pull off with Zelda II: The Adventure of Link. I master the ROM's structure quite well, and I managed to make enemies a lot more challenging. Some modifications are simple variable tweaks, while some others involve ASM code written from scratch. If you think the original Zelda II is hard, then this kind of enemy hack will be considered extremely difficult to handle. You must compare this video to the original game to really see the differences in how enemies move and attack...
My main objective is to make the enemies less predictable, by adding or reinforcing the randomization factor... Details of the tweaks: Myu: moves faster, its routines are mixed with those of Bit/Bot. Bit: moves faster. Bot: jumps higher and farther, both X/Y velocities are randomized. Moa: its routine is hard to tweak coherently, so I just made it to not freeze when it's hit. Ache: moves faster overall and goes down earlier when closing in. Acheman: this one has code written from scratch. Moves faster since Ache and Acheman share some code. Shoots three fireballs, either high or low, at random. Attack delays are shortened. Bubble generator: each bubble has its speed randomized. Rock generator: in the video, speed was simply increased, but I could randomize just as easily as with the raising bubbles generator. Red Deeler: move faster overall, horizontally and up/down its rope. Blue Deeler: same as Red Deeler, and jumps higher and farther on ground, randomized. Bago Bago: speed increase, generated at a higher rate, and 100% chance to shoot a rock at Link when flying up. Red Octorok: jumps at random heights, and the walking Octorok moves faster. Orange Moblin: moves faster, higher and randomized X/Y velocities of spears. Red Moblin: this was more tricky because there's a lot of shared code. Keeps a greater distance from Link. Blue Moblin: just a mix of Red and Orange Moblin. Orange Daira: moves faster when approaching Link and attacks at a higher rate. Red Daira: moves faster and axes are thrown at higher velocity. Goriya: this one is another tricky routine. Boomerangs move faster, fly farther, and come back faster. Lowder: move faster overall, and reaction time to turn around is shortened a lot. Moby generator: instead of going straight down, it moves diagonally first. Speed increased. Megmet: jumping height increased and randomized, X velocity increased. Geldarm: stays shrinked for a much shorter time and restretches faster. Dumb Moblin: generation rate increased, speed increased and randomized. There are many things that need improvement or adustments, but I think the potential is quite interesting overall. The routines are mixed between similar enemies, so it makes it hard to modify a single enemy. Modifying one enemy can cause unwanted changes to another... Another problem arises with enemies that span over more than one world. These enemies' routines (Myu, Bit/Bot, Ache, Moa, Deeler, Octorok, Bago Bago) are stored in Bank 7, which is loaded permanently during gameplay. However, Bank 7 is tightly packed: no more than 75 unused bytes. This means you have to create code in multiple banks for the same enemy. Not doing so will cause the game to crash when one of these enemies appear on screen... Comments and ideas are welcome... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 850/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Games I'm most familiar with tend to become too easy over time, although I can recognize that Zelda II is relatively hard if you compare to the games of its time, or the other games of the Zelda series. That said, it's a natural tendency to create a hack relative to one's own skills. Of course, there are elements in the video that I find a bit too hard myself. That's one of the things that gets easily underestimated in the hacking ROM world. When you make many things harder in the same game, the difficulty accumulates and you end up with something annoying instead of truly challenging and fun...
I plan to make these tweaks a part of a future hack, although it's not cast into concrete, far from it. I'll probably trade off speed for randomization, for example. I think one thing that annoyed many players in Zelda II was repetitiveness. By making enemies more random, it adds to the fun factor... I plan to make random encounters more random as well. For example, if you hit a demon on grass in the overworld, the area you end up in scrolling side view will be chosen at random from a few possible areas of that type. Basically, you have 7 possible terrain types where you can get random fights: desert, grass, forest, swamp, graveyard, road and lava. Each of these have 4 different areas throughout Hyrule: northwest, southwest, northeast and southeast. And each area have two modes: weak and strong. This means 56 different areas for the entire game. Looks pretty good from afar, but when you've been through your 17th encounter in the same swamp, you get tired of it. If you can randomize from, say, 4 possible areas for each region, type and mode, you crank up to 224 possible encounters. Looks much better... RetroRain, if you want the game to become easier, then you could just use the same variables as I did, and use them to slow down enemies and such... MathOnNapkins, the idea of using the Cartridge RAM is a nice one, indeed. That would definitely remove the problem of enemies seen in multiple worlds. Cartridge RAM is 0x2000 bytes, located between 0x6000 and 0x7FFF. The Cartridge RAM structure is weird, the unused space is not simply set to 00 or FF, I know there are already many things there, like enemy bits and attributes, and some code as well. But finding unused spots should be fairly easy to do... RetroRain, I agree completely with you, the continue feature of this game was a failure, in my opinion. I guess it would not be that hard to correct. And by using a byte of the Cartridge RAM, the last place visited could even be saved between resets. By the way, the game is not broken if you forget something important in a temple. For a temple to turn into stone, you need to get the item in it and place the crystal. I'm not sure exactly what would be the point in going back to a temple when it's finished. Except maybe to get a key there... The code for temple turning into stone is located at 0x479B in the ROM (add 0x10 because of the header) for West Hyrule (and probably the same relative offset for East Hyrule), and it simply checks if you have the corresponding item (Candle, Glove, etc.) and the corresponding crystal placed. Every time the overworld map is loaded, the routine is called to change the data as required. If you want to avoid this check altogether and always have the possibility to revisit palaces, it's simple: go to 0x479B, and change A2 for 60. Done! You can also turn palaces into anything you want. Go to 0x47BF and replace 0B by anything between 00 and 0F. Done! |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 851/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
The values are stored this way because of how the individual bit values are processed in the code. In ASM, you typically have something like that:
Then loop 3 more times. The code doesn't work, but you get the idea. In the end, the palettes codes (0-3) are stored in reverse order relative to how the bytes are stored because you start with the 2 least significant bits... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 852/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
That's right, and the great thing with it is that there is unused space right after the routine that controls how the overworld is modified... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 853/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
It depends how your tiles are layered down. My answers follow my experience with Arkanoid, in which the palettes cannot be changed on a "per-tile" basis. In the case of SMB3 overworld map, it's almost only background tiles; the sprites are Mario/Luigi, Koopas, Spades, Flying Boat, etc. I'm not sure how sprites palettes work exactly, but background ones follow the principle explained by KP9000 initially...
One byte in these data tables covers the palette indexes (0-3) for 16 tiles (2x2x2x2). To define a full screen, which is 32x30 tiles, you need 60 bytes. If your map is more than one screen wide, then I guess the table is longer, but I'm not sure... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 854/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Okay, the title may be a little confusing, I just didn't know how to formulate it succinctly. I set view counters (visible or not) in most of my pages, but naturally I visit the pages very often myself for testing purposes or updating, etc. What kind of mechanism would you suggest to make the counter NOT go up by 1 when I am visiting my own page? |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 855/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Seems good, thanks. Although I must check if my IP changes, since it's dynamically attributed... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 856/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Sorry, not working. The game crashes just as I'm about to enter the first stage... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 857/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
I think it's because many people prefer to stay on safe ground and use the available data to immediately create something working instead of going head on into an unknown ROM...
But yes, that's right, development seems to converge to a handful of games these times... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 858/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Yet, we still need rules that smell good... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 859/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Datacrystal's goal is more centered around ROM data mapping. Trying to integrate every possible ASM hack discovery over time would be called "clutter" at best. If you want to share your personal testing and code snippets, use your own server and upload the text files there... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 860/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
The point is, RHDN and Data Crystal don't share the same goal... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 861/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Okay, it's a big bump, but it's relevant...
I finally documented enough data to display and modify the two Bases levels Boss rooms correctly. Enemy data is in the same table as the other rooms, but they have their own set of level data, tile mappings and palette codes, located somewhere else in the ROM. I added a button to flip between normal graphics and "alternate" graphics, so that boss rooms are displayed correctly. Since I work using a memory buffer similar to the PPU buffer (0x2000 bytes), it would be complicated to try to display both normal and boss rooms at the same time in the editor matrix. It's not a big deal whatsoever... Screenshot of the editor in "normal graphics" mode, showing level 2: 
And the same level in "alternate graphics" mode: 
I'm still looking for data regarding boss load in outdoor levels. In this case, graphics data is the thing to be looking for. The game seems to gradually replace some of the PPU graphics with those for the boss, 1 or 2 sections before the actual boss appears on screen. You can see the process in action if you increase the "Load Boss" byte by 1. This byte is in the level's headers, offset 0x08. In other words, for level 1 boss, go to 0xB321 (add 0x10) in the ROM, and replace 0B by 0C... As usual, if you can find any useful information, let us know here... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 862/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
I could finally try the first level. Thanks Googie...
I hate hacks that are designed so you can't actually finish a level because you don't meet specific unreproducible conditions. Or is it just me who can't find the lone block that lets me pass through the pipe with annoying black thingies? Apparently, you need a leaf. No leaf, you're fucked. And that's just the 1st level, mind you... There must be a total of somewhere around 70-80 levels in Mario 3. I mean, games don't need to be gradually more difficult, but generally speaking, it's considered good practice. With first levels like that, I lose interest quite fast. I can imagine how it could be in the more difficult levels, following this pattern... Other than that, the levels look quite similar to the original ones. That's a common syndrome, usually due to the approach used with the editor. You take the original ROM, you open the first level, and there you go, move the objects a bit, change the shapes, add or remove blocks. In the end, you get something that looks like an alternative reality more than a completely different world... |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 863/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Something's been ticking my mind for awhile, especially about the "stacking". I heard more than once that you should stack up your objects somewhere near the beginning of the levels so you preserve the correct order. And it seems that you can't add or remove objects. Is it a limitation of the editor or just a lack of knowledge regarding how the levels are structured in the ROM? |
| Trax |
| ||
|
Yellow Stalfos Level: 71 Posts: 864/1145 EXP: 3034070 Next: 133044 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
Definitely much better... |
| Main - Posts by Trax |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 138, rows: 170/170, time: 0.227 seconds. |