This is probably nothing, but it's worth pointing out in case there is some crazy thing that's useful resulting from this. Video: https://www.twitch.tv/videos/157318168?t=23m40s
I have the following codes active:
02030E3C:00000000
02030E40:00000000
02030E44:7FFFFFFF
02030E48:7FFFFFFF
I know this causes weirdness on the world map, but I've never seen it cause huge weirdness like this before.
Basically, accessing certain doors OOB will black out the screen and the game will start writing values to the games memory. It basically filled up a lot of the 02000000-02000300 section as well as writing a ton of sprite data (tracked by the nonzero tile thing in my script, lower the number = more sprite data). Eventually the game will load the room I was supposed to end up in.
The values of memory written change depending on the coordinates of the door I access (not the destination of the door) and solves the puzzles in the game as you would expect with values written to those addresses.
I'm wondering why this bizarre behavior is having, and whether there's any idea as to how this may be replicated without the camera lock codes.
@Link:
QuoteSorry. Unless you've got a time machine, that content is unavailable.
Whoops, fixed!
Umm.. that is interesting.
Current discoveries:
-The Code must be enabled. (A manual hex edit is not enough.) Or well, maybe you could get perfect timing, but I'm talking about what's practical for quick testing.
-You do not have to go Out-of-Bounds / no Retreat Glitch needed.... simply going through a door is enough. (Like the one at 260:1)
Going to guess that there's nothing abusable here, and the same memory area gets used for something else during room transition. (Although, not really sure what exactly is here, so just a hunch given the way these sections work... That being available memory to use for anything you might want since there's a pointer list at 0x03000000... (e.g. 02030000-0203FFFF, as well as a section in IRAM) ... But most other data end up always being what they are. Especially if you don't count the individual tables/stuff in map code.)
Could it be related to the split map table for jupiter lighthouse?
Okay... Progress Update - It is something with the screen min/max numbers....
* Today, I decide to do research using VBA-SDL-H.
* Puts a breakpoint write on 02030E44 for 8 bytes so I can keep changing them back to 0x7FFFFFFF manually. (Don't worry, it's simple if you use the Up arrow (keyboard button) in the Console window.)
*Puts a breakpoint write on 02000090 ... so I can research what's going on.
Breakpoint found. (Usually in the set flag function, so I exit that function to see what called it.)
02009422 ...coming straight from map code! Yay!
...
Hmm... 0200A78C = Literally look at that section grow! (I know that some of that data includes flag indexes as well.)
Haven't looked, but I'm thinking it's possible that the entries listed here may be based on whether they are in the map region you're in. (Well, based on the min/max screen set.)
I think the entries are about the cracks in the floor. (Flags are set for those... probably to determine if it should crack itself or make you fall through. ... and likely may also help determine the graphics used or something?)
Thing is... unless you can load a room with an improper screen size, I can't figure out how this would be abuseable.