Posts for Khaz

1 2 3 4 5
Posted: 9/21/2014 11:45 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Alright... I've noted this at the end of the submission description. I wasn't able to get the ending again right away so I'm not going to hold my breath. I think my time would be more constructively spent looking at the glitch itself anyways, now that I have enough examples to hopefully learn something. I would like the next submission to have a working ending, it's a shame to have it end the way it does... In the meantime, to be totally honest, I just need a bit of a break from this game.
Posted: 9/21/2014 9:39 PM
(Edited: 9/22/2014 11:29 PM)
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Sooooo, I hate to rain on my own parade here but I've just found out that you actually can sustain the short-cycle trick on the Ortah boss and save about 11-13 seconds... Feel free to watch: [Obsolete Video Removed] It takes some delicate setup. The wall on the right side of the room is not actually flat - it's wider at the bottom than at the top, and widens out in maybe two or three increments as you go down. What you need to do first (and why you can't go into it immediately) is lure the Joker up a bit so that he's in line with the further-out wall, so that after you hit him against it you can then walk behind him by walking lower. For whatever reason, being behind him while he's against the wall at his key decision-making frame (the moment he spins up to full height from the ground) will keep him from flying away horizontally like normal and he will try to attack again. With a bit of manipulation to keep him using the right attacks, and a lot of just-barely-possible positioning, you can keep smacking him into the wall long enough to finish the fight. I would very much like to include this development in my submission here but as previously discussed, getting the ending once again could take an hour or all month.... As such I'm not sure whether I ought to cancel it right now.
Posted: 9/20/2014 4:05 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Hahahaha, not planning it. I tried to play Drakkhen back in the day, I really, really tried but I just couldn't get through it. Maybe someday. Now that I look around I'm really surprised that nobody seems to have even attempted a TAS of it yet. It seems more well known than Dragon View to me, if only for being a terrible game. Sounds like ideal TAS material! I might just look into that. >.> I still think I'd rather do a 100% run of this game first, finish what I started.
Posted: 9/20/2014 3:20 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
So in my experience, I believe I have seen a warp that kept the ending intact twice (after the early runs I did that were very, very slow). Both times it looked exactly the same as PJ's original one, ie/ this screen: Every time I've achieved the ending through a different-looking glitch, the end cutscene has been broken. HOWEVER, it's worth noting that on the most recent run, I got this same exact screen a couple times only to have it crash instead of entering the series of glitched events like before. My best guess to how it works is that you need to have the RAM-destroying loop working within a specific area, such that it can overwrite the loop counter to end the loop early but NOT wreck some other essential variables that it assumes are set correctly when you reach the ending (which seems extremely unlikely). Alternately, perhaps the loop can be set up to end quickly naturally and all that's needed is to preserve a specifc block of memory. Either that or the one specific glitch progression we found earlier actually sets some numbers how they need to be prior to jumping to the ending, which could make the working ending almost impossible to reproduce. Either way, my experience is that it can take a solid week of daily grinding at the ending to achieve one ending, and that ending has maaybe a 33-50% chance of working right at the absolute best. I really can't say until I finally understand how the ending is called and what addresses that end cutscene relies on.... As far as warping to the ending scene directly, I've never seen it happen. My guess is that we can get the ending pretty easily because it is treated as a standard "event" call, which fits since it always seems to come after a series of other events (specifically, that noise you hear at 51:52 seems to happen before every warp). I'm guessing that the rest of the ending is designed to play as one whole block and skipping into the middle of it would be nearly impossible. I would very much like to end this run with an intact ending but as far as I know I may have broken whatever was necessary for that with my new route.
Posted: 9/18/2014 3:01 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
I might just be interested in contributing to an Intellivision emulator. I'm curious to know more about the situation though. Is it still not being worked on? The page Mothrayas linked says it's "licensed as MIT"... Does that mean MIT owns the emulator? Do you guys have all the documentation you'd need to build an emulator lying around? I couldn't find anything too specific, and I've also heard it said that while the existing emulators seem to run the games fine they fail many tests on the "MTE 201 Test Cartridge", which has me curious. I wish I could find one of those cartridges.
Posted: 9/17/2014 11:16 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
That does sound like exactly what I'm looking for, yes. It would save a lot of time and effort on this. Thanks for looking into it! If there's any way I could help out let me know.
Posted: 9/17/2014 10:52 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Alright, in that case... Here's a savestate from right before the ending of Dragon View (U). To see what I mean, walk through the door to the left then press something to try to advance the text. Bizhawk should crash after a few seconds. (small chance it'll get stuck in a loop instead, if so just retry) If there's something more I can do to help debug this I'd be glad to try. EDIT: What I mean by "crashing" is that the program is frozen. So I guess what I'm asking is if there's any way to force Bizhawk to recover from that scenario, because it doesn't respond to any input.
Posted: 9/17/2014 9:50 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Okay, I'm trying to test it in higan_v094 right now. It doesn't seem to have movie support and I can't figure out where it saves its savestates. Does anyone know if they're compatible with BizHawk savestates? It would be nice not to have to manually play the whole run all over again just to test it... EDIT: It appears to save it in C:\Users\[username]\Emulation\Super Famicom\Game #. Nnnnnnnghhhh I hate that the "Users" directory exists. And I guess bizhawk savestates and higan savestates are incompatible. Alright, doing it manually....
Posted: 9/17/2014 9:19 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
I am more familiar with NES hardware to be honest, I was referring to I guess "undocumented" opcodes such as the "KIL" ones that will cause the processor to stop. I was under the impression that some of those existed for the SNES processor too but I am probably mistaken. I find good information on the 65812/65c812 and the SNES in general to be irritatingly hard to come by.
Posted: 9/17/2014 8:55 PM
Post subject: Crash Handling (SNES)
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
I just wanted to ask about this... The TAS I'm working on requires me to run Bizhawk into a crash literally thousands of times. While knowing about the existence of Autoload and some recent patches has sped this process up considerably, I just have to ask about the one remaining obstacle. Is it possible to make Bizhawk handle a program-induced crash, rather than crash itself? I understand that there exist invalid opcodes that would cause the 65c812 to come to a halt, among other conditions that could cause such a thing. This isn't nagging you to fix anything but rather just a question: Can this handling be done, somehow informing the user of the crash and then allowing them to carry on? Or is the core problem (ha, pun) that accurate emulation also includes accurate crashing, and Bizhawk is required to crash with it?
Posted: 9/14/2014 5:07 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
That map is absolutely beautiful for 396kb, I really didn't think that was possible. Thank you very much for all the help and explanation! I really appreciate it!
Posted: 9/14/2014 2:37 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Again, really good compression. I tried some messing around with TruePNG myself on the slightly-updated version of the map I sent to vgmaps and got very close but slightly less nice results, probably because I used MSPaint to do the resizing (I tried gimp too but it didn't seem to do any better). I find it interesting that the dithering seems to preserve one small specific purple spot in the bottom left corner, where all the other versions it's basically gray. I don't really know what dithering is supposed to do but I guess it's that. In my opinion the 256-colour-quarter-resolution-bicubic-dithered option seems to look the best and keep the scenery markers reasonably legible while staying within the size I'd need. Also - I reached the end of my new TAS! I have spent a couple days now testing various tweaks in the last few rooms trying to get a successful ending but no luck. What disturbs me is how I keep seeing certain patterns recurring even after the most extensive changes I can make in the final rooms. Strictly speaking I don't think I've seen the exact same glitch twice, but almost every single attempt I've hit a mostly orange-and-white checkerboard pattern for several of the torch-flicker values, which I don't remember seeing hardly at all in previous runs. I've managed to get a series of glitched events vaguely similar to the working warp a couple times but it always ends in a crash so far. I've tried searching traces of the moment after the final input for addresses we've focused on before like 7EBB46, the where-you-last-walked-up-a-screen-in-town address, but I haven't found it. I'm thinking I may have changed something vital to the early progression of the glitch but as always, there's a hundred things it could be. I keep trying to look at a trace of it myself but I keep getting lost... I'll keep testing but I'm not sure whether I should just post up what I have as a WIP or what. I don't really want to spoil it all for the actual submission but I can't know how much longer it'll be until I get it to work. In the meantime here's a savestate if anyone wants to have a look at the glitch after the new TAS.
Posted: 9/8/2014 10:28 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Personally, I find glitches like this one almost as entertaining as the game itself. While I understand the reasons for rejecting this, is it possible some kind of category could be created for this sort of thing? I'm thinking along the lines of a known glitch encyclopedia, to document them as a curiousity? TASVideos is likely not the appropriate home for it to begin with but I nonetheless think such a thing should exist...
Posted: 9/8/2014 8:52 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
I never opened the menu on the world map on any previous warping run. I'm presuming it probably writes to some different addresses that wouldn't be there if you only open it inside, but generally speaking this run is going to be so different I'm not relying on anything I think I know about the glitch. Essentially I'm just getting to that room as fast as possible, where I will brute force it and pray. When I was playing around with the unused room numbers and such a while ago, I noticed that I'd get warped to the ending somewhat frequently after a bunch of glitching around. I'm working on the assumption that any given unpredictable glitch in this game has some chance of arriving at the ending, meaning odds are good that I'll be able to manipulate at least one working ending by tweaking just Ortah, or even just the final fight. If nothing else I should check if the RNG address $A5 appears in the glitch, because that alone would give you more possibilities than I could test in a year... I could be wrong and hit a dead end but at least I'll have a much faster and more entertaining run to show for it, and maybe we'll finally have enough data to pin down a cause. If I get desperate I'll probably just put out an open call for help testing the ending and give anyone who gets it to work 50% credit for the run or something.
Posted: 9/7/2014 8:26 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Hey, sorry for the delay but I wanted to thank you guys for the input. The map is on vgmaps.com now. Unfortunately 1MB is still too big but that's some impressive compression, I may be able to use it later. Thanks again! Fun thing I learned today: If you open the menu while you're walking down out of a town to the world map, it will skip the perspective-change and you'll emerge facing the entrance you came out of. Don't think that'll be very useful since it takes about 200 frames to open the menu, but you never know. Walking backwards around the world map is faster sometimes. 16 23 minutes in and I've already saved two and a half minutes 3:45. I sincerely hope it will glitch properly when I'm done... EDIT: Scratch that it came in useful immediately. If you need to access the menu anyway I think that's the best time to do it
Posted: 8/13/2014 12:21 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Well, I was thinking more in the sense of somewhere people will find it if they're looking for such a map. I have it uploaded and a link but anyone who wants to see it will just have to find me I guess... Hit an unpleasant roadblock in the TAS just now too. It appears that you can't manipulate the green bug enemies in the random encounter in the swamp to drop two hearts at once. I know that other enemies in the game in the same basic drop category (2 drops, pink jade) will frequently drop two hearts but I've been killing them for hours now and it hasn't happened once. I guess every enemy has their own loot table? Either way, that one thing could end up costing me a lot of time... What will make things even more annoying for the rest of the run is I've just noticed you can't influence your drop with controller input while you're still in a sword technique animation, and given that almost all combat from here on is sword techniques that's going to be painful. My entire strategy this time is relying on some very specific enemy drops.
Posted: 8/12/2014 9:41 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Soooo just asking, but does anyone know of anywhere that might be a suitable/useful place to host that map I made? I was going for GameFAQs but they don't allow anything over ~400kb and I can't possibly compress this to anything under about 1MB without it looking like absolute crap. Unless somebody is better than me at image compression and has suggestions to get it lower without it looking so miserable... I would really rather not have all that work just be for my personal reference.
Posted: 8/8/2014 8:49 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Thank you! I'm glad it was worth all the effort. http://www.pictureshack.us/images/54539_FINISHEDWORLDMAPHALF.png An update, much improved. The markers are more visible now but the downside is they sometimes overlap and in general are centered about one pixel southeast of where they should be maybe. I'm calling it good enough. And yes, there are two different kinds of walls in game for different kinds of regions. Dunno why they needed that. EDIT: The FAQ I mentioned is up now: http://www.gamefaqs.com/snes/588294-dragon-view/faqs/69745 I guess "FAQ" is the wrong name for it. This is like a "questions that were never asked".
Posted: 8/8/2014 2:03 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
HERE: http://www.pictureshack.us/images/42305_WORLDMAP1.png Turns out the only real solution was to reprogram excel to draw and assemble the entire thing itself all at once. It took five hours. That's why you just get this crappy-looking preliminary for now. Things that need fixing: -roads and such that are the wrong colour for their region (mostly yellow) -region backgrounds -more visible/distinct scenery markers -tiles that cover multiple regions having a grey layer over half (eg/ snowfield) -possibly add some icons for major things like towns? -??????? If you've played this game and would like some input on how this map looks when it finally gets posted now'd be a good time! The good news is I can get back to TASing now.
Posted: 8/7/2014 2:19 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Thanks for the support! I'm definitely going to get started on a 100% run soon, but I'm already halfway through a vast improvement on my last one so I want to finish that first. In the meantime, forget all the map business I've been ranting about for the last page. It was pretty simple in the end - sets of compressed coordinates defining everything's location. I have a new FAQ pending on gameFAQs that explains it all a lot more concisely. The only thing I can't do is assemble a bunch of square .pngs into a larger square to make an actual world map image. I even wrote a script to do it but it seems I chose the wrong software or something, it just doesn't work. I have literally everything else down but that and after all this I am noooot doing it manually 1024 times. If anybody wants to have some fun though I can send you an excel spreadsheet that draws any map tile or "object" in the game straight from the hexadecimal ROM data.
Posted: 8/4/2014 9:18 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
I completely forgot a while back that I'd seen it reading from another important spot, $97d118. I looked into that and I understand things a bit better now. In the "Tile Set" data I posted before, the first "Size" byte defines a number of bytes at the start of the data set that are used separately. Turns out these are used to do another lookup exactly the same way as we got to the Tileset from the world map. So, -One byte taken from tile data -Multiplied by two, used to index read two bytes from $97DC08 -Those bytes get used as an index to read from $97D118 In the same way as last time I assembled this up into what I'm calling an "Object" table. You can see it here: http://www.mediafire.com/view/4iyy7ewdev2jv1i/WorldMapObjectset.txt Unlike the tile table from before, only the second "Size" byte seems to actually relate to the size of the data. The first one gets stored and used a long while later for something I haven't worked out yet. In any case, the Data in this new table is read by the program two bytes at a time in a loop, using the second "Size" byte as a counter. Since luckily there are a few tiles in the game that have only these special object bytes and none of the data I saw used in my last post, I took a look at a few in game. For example, tile 05 northwest of Galys Pass, just before the 3-way intersection to the swamp. The tile's data looks like this: 
TILE 05 - Index 82 00
Size 03 00
Data 0d 22 d1

OBJ 0D - Index 92 00
Size 01 05
Data 3d 00 43 00 80 3d 80 43 57 27

OBJ 22 - Index 70 01
Size 07 03
Data 80 80 00 80 00 00

OBJ D1 - Index dc 08
Size 02 07
Data 48 2c 46 35 4c 38 57 38 5f 30 5e 26 53 24
What it looks like in-game: -A straight wall from the northwest corner to the southeast corner of the tile -A road with uneven edges from the north-center to the east-center of the tile -A small lakesouthwest of the road at approximately 0D40X, 22B0Y (ie/ 0140X, 00B0Y relative to the tile coordinates). It seems to be the same shape and size as some generic brown patches you commonly see on the ground. What's interesting to note is that there's no trees or other similar scenery. What I think this means is that major landscape features like walls and roads and water all come from a standard set of 256 represented by those single bytes at the start of the tile data. The REST of the tile data, each one-byte-two-byte pair must be a piece of scenery. I bet if I went out and picked a tile at random and counted every last bush and rock in it it would add up. I'm guessing a one-byte identity with a two-byte location? The location would have to be compressed to every two increments at least... Just keeping you all updated on the off chance someone tries to help with something I already figured out.
Posted: 8/3/2014 6:40 PM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
So you get your one byte tile number from the master map, then you use that to lookup a two-byte index from $97cf18 that corresponds to the location of that tile in the actual tile list, which starts at $9796d6. The first thing it does with that two-byte index is reads the first two bytes at that offset. These seem to define the size of the data that follows because they get used to define how the rest is read: -Reads one byte from ($9796d6 + index) and adds #$02 -Adds the index to the result and stores in $0008 -Reads one byte from ($9796d7 + index) (ie/ the next one) -Adds $0008 to that and stores in $000a Then it adds (byte2 - 1) to $0008, THEN it adds (byte2 - 1) * 2 to $000a So finally: $0008 = (index from $97cf18) + 2 + byte1 + (byte2 - 1) $000a = (index from $97cf18) + 2 + byte1 + byte2 + ((byte2 - 1) * 2) (The +2's just to account for the 2 "size bytes") And then it uses those to actually start reading from the tile in $9796d6, like so: ($0013 starts as byte2) -Read One Byte from $9796d6, X where X is $0008 -Decrement $0008 -Read Two Bytes from $9796d6, X where X is $000a -Decrement $000a -Decrement $000a -Decrement $0013 and branch (repeat) if not zero This doesn't seem to cover all the data for each tile though. The tile data itself starting at $9796d6 looks like this: 
TILE 00 - Index 0000
Size	0100
Data	00

TILE 01 - Index 0003
Size	0100
Data	01

TILE 02 - Index 0006
Size	01 00
Data	02

TILE 03 - Index 0009
Size	03 0a
Data	04 05 83 00 00 01 00 00 01 00 01 01 00 0a 3b 13
       49 23 3a 29 37 2c 46 4b 3a 4b 47 5d 4c 6d 46 77
       3a 00 01 01 00 00 00 01 00 00 01 29 37 23 3a 4b
       3a 77 3a 0a 3b 2c 46 6d 46 4b 47 13 49 5d 4c

TILE 04 - Index 004a
Size	06 08
Data	01 ef 71 bf cf b2 0b 0b 0b 0d 0d 0d 0d 0d 17 6e
       18 63 1f 5d 2b 31 2c 4e 2f 45 33 37 3a 4d 0d 0d
       0d 0d 0d 0b 0b 0b 2b 31 33 37 2f 45 3a 4d 2c 4e
       1f 5d 18 63 17 6e

TILE 05 - Index 0082
Size	03 00
Data	0d 22 d1

TILE 06 - Index 0087
Size	06 09
Data	d9 07 46 45 3a db 00 01 00 00 01 00 00 00 01 36
       4c 38 29 3b 11 3c 7e 46 1e 46 34 46 5e 48 07 49
       6b 00 00 01 01 00 00 00 01 00 48 07 3b 11 46 1e
       38 29 46 34 36 4c 46 5e 49 6b 3c 7e

TILE 07 - Index 00c5
My best guess is that each tile is a repeating pattern that gets extended out to $0200 by $0200. Some basic ones are uniform and so only require one byte of data. It seems a logical way to compress things I guess but I'm really not understanding how to translate it to standard X Y coordinates at the moment. I don't know what the values mean either and knowing that might help, but if I got it all plotted out on a map first it would be simple to derive what they mean... This is one piece away from solved... EDIT: Here's the full tile data formatted as above if anyone's interested. http://www.mediafire.com/view/oil53kbljctrdc3/WorldMapTileset.txt I believe the first "Size" byte corresponds to how many bytes there are at the beginning of the "Data" section that aren't part of the normal one-byte-two-byte scanning it does later. I don't know what they're for.
Posted: 8/3/2014 5:07 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
AHA 
80a4eb lda $1c14     [801c14] A:00a2 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdiZC V: 48 H: 154
80a4ee and #$fe00             A:2006 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizC V: 48 H: 188
80a4f1 sta $00       [000000] A:2000 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizC V: 48 H: 206
80a4f3 bpl $a4fa     [80a4fa] A:2000 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizC V: 48 H: 234
80a4fa xba                    A:2000 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizC V: 48 H: 252
80a4fb lsr a                  A:0020 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizC V: 48 H: 270
80a4fc sta $04       [000004] A:0010 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 282
80a4fe lda $1c16     [801c16] A:0010 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 310
80a501 and #$fe00             A:2859 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 344
80a504 sta $02       [000002] A:2800 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 362
80a506 bpl $a511     [80a511] A:2800 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 390
80a511 lsr a                  A:2800 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 408
80a512 lsr a                  A:1400 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 420
80a513 lsr a                  A:0a00 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 432
80a514 lsr a                  A:0500 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 444
80a515 clc                    A:0280 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 456
80a516 adc $04       [000004] A:0280 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 468
80a518 sta $04       [000004] A:0290 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 496
80a51a and #$00ff             A:0290 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 524
80a51d sep #$20               A:0090 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 582
80a51f lda $190b     [80190b] A:0090 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H: 600
80a522 tax                    A:0060 X:0184 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H: 626
80a523 lda $a6f0,x   [80a750] A:0060 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H: 638
80a526 sta $10       [000010] A:0002 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H: 668
80a528 stz $11       [000011] A:0002 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H: 688
80a52a lda #$00               A:0002 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H: 708
80a52c sta $1a88,y   [801a88] A:0000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H: 720
80a52f rep #$20               A:0000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H: 752
80a531 lda $04       [000004] A:0000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdiZc V: 48 H: 770
80a533 sta $06       [000006] A:0290 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 798
80a535 lda $00       [000000] A:0290 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 826
80a537 sta $1a89,y   [801a89] A:2000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 854
80a53a lda $02       [000002] A:2000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 894
80a53c sta $1a8b,y   [801a8b] A:2800 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 922
80a53f and #$00ff             A:2800 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 48 H: 962
80a542 sep #$20               A:0000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvmxdiZc V: 48 H: 980
80a544 lda $10       [000010] A:0000 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H: 998
80a546 asl a                  A:0002 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H:1018
80a547 asl a                  A:0004 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H:1030
80a548 adc $11       [000011] A:0008 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H:1042
80a54a tax                    A:0008 X:0060 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H:1062
80a54b lda $a770,x   [80a778] A:0008 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 48 H:1074
80a54e sta $12       [000012] A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1104
80a550 bit #$01               A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1244
80a552 beq $a568     [80a568] A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1256
80a568 bit #$02               A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1274
80a56a beq $a580     [80a580] A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1286
80a580 bit #$04               A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1304
80a582 beq $a59e     [80a59e] A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1316
80a59e bit #$08               A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1334
80a5a0 beq $a5ba     [80a5ba] A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 48 H:1346
80a5ba lda $1a8a,y   [801a8a] A:0000 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 49 H:   0
80a5bd bmi $a5cc     [80a5cc] A:0020 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 49 H:  32
80a5bf bit #$40               A:0020 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 49 H:  44
80a5c1 bne $a5c3     [80a5c3] A:0020 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 49 H:  56
80a5c3 lda $1a8c,y   [801a8c] A:0020 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 49 H:  68
80a5c6 bmi $a5cc     [80a5cc] A:0028 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 49 H: 100
80a5c8 bit #$40               A:0028 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 49 H: 112
80a5ca beq $a5d7     [80a5d7] A:0028 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 49 H: 124
80a5d7 ldx $06       [000006] A:0028 X:0008 Y:0000 S:1ffb D:0000 DB:80 nvMxdiZc V: 49 H: 142
80a5d9 lda $9792d6,x [979566] A:0028 X:0290 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 49 H: 170
80a5dd rep #$20               A:00c3 X:0290 Y:0000 S:1ffb D:0000 DB:80 NvMxdizc V: 49 H: 200
80a5df asl a                  A:00c3 X:0290 Y:0000 S:1ffb D:0000 DB:80 Nvmxdizc V: 49 H: 218
80a5e0 tax                    A:0186 X:0290 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 49 H: 230
80a5e1 lda $97cf18,x [97d09e] A:0186 X:0186 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 49 H: 242
80a5e5 tax                    A:27f2 X:0186 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 49 H: 278
80a5e6 sta $1a86,y   [801a86] A:27f2 X:27f2 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 49 H: 290
80a5e9 and #$00ff             A:27f2 X:27f2 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 49 H: 330
80a5ec sep #$20               A:00f2 X:27f2 Y:0000 S:1ffb D:0000 DB:80 nvmxdizc V: 49 H: 348
80a5ee jsr $a87a     [80a87a] A:00f2 X:27f2 Y:0000 S:1ffb D:0000 DB:80 nvMxdizc V: 49 H: 366
80a87a lda $9796d7,x [97bec9] A:00f2 X:27f2 Y:0000 S:1ff9 D:0000 DB:80 nvMxdizc V: 49 H: 406
80a87e sta $1a88,y   [801a88] A:0007 X:27f2 Y:0000 S:1ff9 D:0000 DB:80 nvMxdizc V: 49 H: 436
This is where it loads the map tile numbers from the map in rom. $1c14 is your X position and $1c16 is your Y position. It first cuts out the right 9 bits of each to give your tile coordinates, then manipulates the X coordinate so each tile is an increment of $0001, and the Y so each tile is an increment of $0020. Then it adds them together and uses that later as an index to read a byte from $9792d6. This one byte must represent the contents of those coordinates. After that it multiplies it by two and uses it as an index to take 16 bits from $97cf18. So each one byte tile number from before corresponds to a two byte "tile number" that gets stored in $1a86 like I mentioned in my last post. Afterward that long tile number also gets used to read a byte from $9796d7, the result of which is stored in $1a88, the other half of what I called the current "tile number" before. I don't know what that's about yet. This means the world map really is only 40x40, despite that you can walk all the way out to FFxFF - it's just reading the table wrong out of bounds. Furthermore I actually can map out the grid of tile numbers now, I just have to finish tracking down what they represent. Hopefully I can at least see some obvious patterns at first glance that confirm what I've determined so far. EDIT: Map confirmed: http://www.mediafire.com/convkey/c532/h6p4662119z1tm1fg.jpg http://www.mediafire.com/convkey/c22b/xk6c02apatanl5afg.jpg
Posted: 8/3/2014 12:07 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
Looks like a solid route! I plan to save at the guy in the Landslide, since I think he's the only save point that's literally directly on the way. I don't forsee many places where HP and MP will be a problem when you can manipulate drops. I'm also curious if there might be any more efficient way to handle the 100 fight grind than just doing it all at once. Since you spend time between each encounter chasing down the next one, it would make sense for TAS purposes to try to manipulate a whole bunch in a line on the way to where you're going anyway. I know it's happened to me before that I've hit a seemingly never-ending string of encounters all on the same line, maybe I can provoke it. Anyways! Still on the subject of the map. I think the game handles it in tiles that are $0200 x $0200. I've found a few key spots in memory again: $1A8A / $1A8C Current Tile Coordinates $1B0A / $1B0C Next X Tile Coordinates (Tile to East or West depending on orientation & position) $1B8A / $1B8C Next Y Tile Coordinates (Tile to North or South depending on orientation & position) $1C0A / $1C0C Next XY Tile Coordinates (Tile to NE, NW, SE, SW to complete a square with other 3) And I belieeeve, not sure, that each one of those sets of coordinates is immediately preceeded by some kind of four byte "tile number" that defines what's at that location. I haven't worked out details yet The tiles seem to only be for the landscape like walls, trees, water, etc... But the actual map entry/exit points are somewhat separate from that. So, if you freeze those "tile numbers" for all current and next tiles in a clear area, you can walk through all the normal walls and it will infinitely appear to be the same spot, but map entry/exit points will still appear at their real coordinates. If you freeze both them and the coordinate addresses I listed above, though, it appears the game will load that one four-tile block, and the rest of the world will just be blank. I think. And what I said before about reading from the ROM: In general it seems to be reading a lot of data indexed by the same "tile number" value from $9796d6, $9796d7 and $9796d8... as in offsets within the same table, but still dunno what any of it means yet. I know I should just give up and get back to TASing...... bleh... I'm so burnt out on this but it's basically the last missing piece before I have all the information I need to prevent wasting entire minutes of travel on a 100% run.
Posted: 8/2/2014 1:13 AM
Quote
Khaz
Experienced Forum User, Published Author, Player (53)
Joined: 11/20/2013
Posts: 103
I'd definitely be interested in seeing that route if you don't mind, that could be helpful. Knowing the RNG source should hopefully make manipulating those random encounters really easy to TAS, actually. What are your thoughts on the map markers specifically for 100%? Most I think are a one-time chance to get a permanent marker on your map, so it sounds like something that would be included to me. Back on the subject of this map stuff... I've really been trying to find where and how it's stored in the rom, because if I can get that down we could finally have an accurate map showing all the obstacles and out of bounds regions and all, it would help a lot for TASing but mostly I'm just extremely curious to see it. Trying to decode what's going on through traces is ridiculous though... I think I've found at least part of the map in some tables in rom at $97dc08, $9796d8 and $97d118. -The program reads a value from the table in $97dc08, shifts the bits left then moves it to X -That X value is then the index to take a value from the table starting at $9796d8 -That value is used as an index to read from the table starting at $97d118, and the program takes 16 bytes starting at that address. I'm thinking it must be stored as some set of standard tiles it references but I can't track down how it's arranged yet. I did find out a lot of related stuff though: $1900 is your region code (00 to 09) and how the game renders everything around you depends on it. $1909's your orientation which must be an even number, $1907 becomes 1 when you collide with things (sometimes?), $1906 represents what direction you were trying to go when you collided. When you collide, it still moves you forward but then just moves you back the same amount on the same angle. $038B triggers the warp star effect when it's not zero. Haven't figured out how to control where you end up though. $1C14 / $1C15 is your X position and $1C16 / $1C17 is your Y position. In general, what you see on screen is coming from the area of $1A10-1E00ish, you can screw with it to make things look different but it doesn't change the map. I have the means to extract the bytes from the rom and rearrange them however is needed to form a coherent picture, but I can't make any more real progress determining the structure. Does anyone have any experience maybe how it's done in similar games, that could give me an idea?
1 2 3 4 5