Editor, Expert player (2480)
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
I kept running towards dead ends in my Genesis projects, so I decided to try some SNES stuff for a change. This game is called Musya and it's said to be a bad Castlevania clone. There are a few things that could be improved, but I'm not going to continue doing this unless someone really really wants to. Here is the file: www.freewebs.com/aqfaq/musya-wip.smv ROM: Musya (U) [!] Emulator: latest Snes9x (I used WIP timing)
Joined: 6/4/2005
Posts: 130
Location: Ontario, Canada
Good gravy man, our new threads were 2 seconds apart! And I don't know what time it is in Finland but here it's 7:20 in the morning!
Aran_Jaeger
He/Him
Banned User
Joined: 10/29/2014
Posts: 176
Location: Bavaria, Germany
Here's some experimental data that was obtained via memory search (by me). In the following, when I refer to memory addresses, the indicator ''0x'' for a number corresponding to a memory address was left out for brevity, and most of the memory addresses are listed in order from small to large. Memory addresses are generally refered to them being represented as 1 byte and unsigned unless specified otherwise. I hope from the context it should be clear which numbers are refered to as decimal numbers (any number other than memory addresses) and which as memory addresses (or otherwise hex values which should be indicated with the pre-fix ''0x''). In particular, values of memory addresses are refered to as decimal numbers. I tried to (for the most part) order the addresses by their size and have an empty line between each 2 in the text neighboured statements about memory addresses whenever there exists at least 1 address between the 2 corresponding addresses in these statements. Any claim of the sorts ''x is (exactly) or behaves as y'' is meant as observation based on experimental sample data. ----- Addresses of the form 7E.... : - - - Imoto (the protagonist character) related addresses: Some addresses around 0B49 seem to be related to Itomo's attacks. 1004 seems to be Imoto's absolute x-position in pixels. 1006 seems to be Imoto's screen-dependent y-position in pixels. 1008 seems to be Imoto's screen-dependent x-position in pixels. 100A seems to indicate the direction Imoto currently faces as follows (0 - Imoto is facing left, 1 - Imoto is facing right). 100E seems to be some Imoto pose indicator as follows: 1 - Imoto is crouched or midair (jumping or falling from a ledge, without attacking), 2 - Imoto is standing (and facing either direction), repeating sequence of 2,3,2,4 - Imoto is walking forwards, sequence 2,5,6,5,2 of values - Imoto is spear punching, sequence 2,5,11,5,2 of values - Imoto is spear punching midair (during a jump or while falling from a ledge), sequence 8,7,8,7 of values - Imoto spear punching while crouched, slowly oscillating between 1 and 9 - Imoto is crouchwalking, 10 - Imoto is midair and downwards spear-punching, 12 - Imoto is using the spear-spinning attack midair, 13 - Imoto is using the spear-spinning attack on ground. (And there's most likely more cases to distinguish here.) 1010 seems to indicate if Imoto is crouching as follows (0 - otherwise, 8 - Imoto is crouching). 1015 seems to be some timer for Imoto's spear punch animation. 1016 seems to be some general timer for Imoto's animation. 1017 and 1018 seem to be related to Imoto's crouchwalk animation. 101A seems to be Imoto's current number of health points, and the (first obtainable) full-screen attack's damage seems to be determined by it as ''the same value + 1''. 101B seems to be the maximum of the health points that Imoto can carry. 101D seems to be an absolute Imoto y-position in pixels (of his bottom part?). 101F seems to be a (screen-dependent?) Imoto x-position in pixels (of his right side?). 1021 seems to be Imoto's absolute y-position in pixels (of his top part?). 1023 seems to be Imoto's absolute x-position in pixels. 1025 and 1026 seem to be frame counters for the duration of how long Imoto currently is in air during a jump before he lands. 1028 seems to indicate if Imoto currently is on ground as follows (0 - Imoto is on ground, 1 - Imoto is in the air during a jump). 1029 seems to indicate if Imoto currently is attacking as follows: 0 - Imoto is not attacking, 1 - Imoto is attacking with spear punch at any direction and on floor aswell as during a jump, 2 - Imoto is attacking with spear-spinning. 102A seems to indicate the direction of Imoto's last jump as follows: 1 - the jump was straight up or Imoto changed the direction of that jump (only doable after reaching its peak), 2 - the jump was to the right, 3 - the jump was to the left. 102B seems to be an indicator for to what direction Imoto moved at last as follows (0 - Imoto moved to the right, 1 - Imoto moved to the left). 102E seems to be the current number of lightning full-screen attack scroll ammunition (the first, left-most scroll in the list). 103C seems to be the countdown for Imoto's invulnerability frames (or could be a timer for the delay until Imoto's "aohhw" hurt-noise occurs). 1038 seems to indicate Imoto's last jump type as follows (182 - the jump was a low jump, 225 - the jump was a high jump). - - - Enemies related addresses for X=4, X=8, X=C: 10X0 seems to indicate if the 1st enemy slot is active/occupied/used as follows (0 - otherwise, 208 - 1st enemy slot is active). -- |10X2 seems to be the 1st enemy's absolute y-position in pixels. |10X3 seems to be the 1st enemy's y-position in (the number of) screens. |10X4 seems to be the 1st enemy's absolute x-position in pixels. |10X5 seems to be the 1st enemy's x-position in (the number of) screens. -- |10X6 seems to be the 1st enemy's screen-dependent y-position in pixels. |10X7 seems to be the 1st enemy's y-position in (the number of) screens, (but might also indicate if the 1st enemy slot is active). |10X8 seems to be the 1st enemy's screen-dependent x-position in pixels. |10X9 seems to be the 1st enemy's x-position in (the number of) screens. -- 10XE seems to be the state of the 1st enemy's sprite animation. 10(X+1)2 seems to be the 1st enemy's y-speed in pixels. 10(X+1)3 seems to be the 1st enemy's x-speed in pixels (except that when it has the value 1, it means 0 sideways speed, so there seems to be a shift in the assignment of speeds). 10(X+1)5 seems to be the state of the 1st enemy's sprite animation. 10(X+1)9 seems to control the flickering of the 1st enemy's sprite (if it changes at all or not). 10(X+1)A seems to be the 1st enemy's current number of health points (which seems to include the 1st boss). -- |10(X+1)D seems to be the 1st enemy's (bottom part's?) absolute y-position in pixels. |10(X+1)E seems to be the 1st enemy's (bottom part's?) y-position in (the number of) screens. -- |10(X+1)F seems to be the 1st enemy's (right part's?) absolute x-position in pixels. |10(X+2)0 seems to be the 1st enemy's (right part's?) x-position in (the number of) screens. -- |10(X+2)1 seems to be the 1st enemy's (top part's?) absolute y-position in pixels. |10(X+2)2 seems to be the 1st enemy's (top part's?) y-position in (the number of) screens. -- |10(X+2)3 seems to be the 1st enemy's (left part's?) absolute x-position in pixels. |10(X+2)4 seems to be the 1st enemy's (left part's?) x-position in (the number of) screens. -- 10(X+2)5 seems to indicate if the 1st enemy is currently active. - - - And analogous for the next cases with Y=0 and Y=4: 11Y0 seems to indicate if the 1st enemy slot is active/occupied/used as follows (0 - otherwise, 208 - 1st enemy slot is active). -- |11Y2 seems to be the 1st enemy's absolute y-position in pixels. |11Y3 seems to be the 1st enemy's y-position in (the number of) screens. |11Y4 seems to be the 1st enemy's absolute x-position in pixels. |11Y5 seems to be the 1st enemy's x-position in (the number of) screens. -- |11Y6 seems to be the 1st enemy's screen-dependent y-position in pixels. |11Y7 seems to be the 1st enemy's y-position in (the number of) screens, (but might also indicate if the 1st enemy slot is active). |11Y8 seems to be the 1st enemy's screen-dependent x-position in pixels. |11Y9 seems to be the 1st enemy's x-position in (the number of) screens. -- 11YE seems to be the state of the 1st enemy's sprite animation. 11(Y+1)2 seems to be the 1st enemy's y-speed in pixels. 11(Y+1)3 seems to be the 1st enemy's x-speed in pixels (except that when it has the value 1, it means 0 sideways speed, so there seems to be a shift in the assignment of speeds). 11(Y+1)5 seems to be the state of the 1st enemy's sprite animation. 11(Y+1)9 seems to control the flickering of the 1st enemy's sprite (if it changes at all or not). 11(Y+1)A seems to be the 1st enemy's current number of health points (which seems to include the 1st boss). -- |11(Y+1)D seems to be the 1st enemy's (bottom part's?) absolute y-position in pixels. |11(Y+1)E seems to be the 1st enemy's (bottom part's?) y-position in (the number of) screens. -- |11(Y+1)F seems to be the 1st enemy's (right part's?) absolute x-position in pixels. |11(Y+2)0 seems to be the 1st enemy's (right part's?) x-position in (the number of) screens. -- |11(Y+2)1 seems to be the 1st enemy's (top part's?) absolute y-position in pixels. |11(Y+2)2 seems to be the 1st enemy's (top part's?) y-position in (the number of) screens. -- |11(Y+2)3 seems to be the 1st enemy's (left part's?) absolute x-position in pixels. |11(Y+2)4 seems to be the 1st enemy's (left part's?) x-position in (the number of) screens. -- 11(Y+2)5 seems to indicate if the 1st enemy is currently active. - - - 1000 - 103F seems to be a range of memory addresses that are related to Imoto. 1040 - 107F seems to be a range of memory addresses that are related to the 1st enemy. 1080 - 10BF seems to be a range of memory addresses that are related to the 2nd enemy. 10C0 - 10FF seems to be a range of memory addresses that are related to the 3rd enemy. 1100 - 113F seems to be a range of memory addresses that are related to the 4th enemy. 1140 - 117F seems to be a range of memory addresses that are related to the 5th enemy. (...?) It seems that there only exist about up to 5 or to 7 enemies at the same time. Apparently the 5 enemy address ranges don't keep track of all enemies, since the blue travelling flames seem to be ignored, and the eggs that the flying heads spit out before one encounters the 1st boss probably too. - - - Screen related addresses: 1508 seems to be the screen's x-position in pixels that counts down when Hagane moves to the right (and does full loops). 1509 seems to decrement (by 1) after every finished loop that the address 1508 does while the screen moves to the right (and increments accordingly if the screen moves back to the left). ----- lsnes addresses (with Base 0 and Size 0): 48, 50, 52, 54, 58, 865 (with Base and Size 0) seem to be some counters for the numbers of uses of different instruments' notes. 8258409 seems to be some slow timer that increments (by 1) every time the frame counter finishes a loop and loops back from 63 back to 0. 8258408 seems to be some frame counter that sometimes doesn't increment (by 1) but then in such cases counts up by 2 for the next frame. 8261722 seems to keep track of the number of health points of the 1st boss. 8259768 seems to keep track of the 1st enemy's x-position in pixels. 8261667 seems to be Imoto's back's x-position in pixels (depending on what direction Imoto currently is facing). 8261636 seems to be Imoto's center's x-position in pixels (possibly depending on what direction Imoto currently is facing). 8261663 seems to be Imoto's front's x-position in pixels (depending on what direction Imoto currently is facing). 8261640 seems to be Imoto's screen-dependent x-position in pixels. These addresses here probably coincide with some addresses further above. - - - List of things for which addresses might exist: - current amount of score points - number of remaining Imoto lifes - current game mode (differentiating the 2 types in which the game can be paused, aswell as the unpaused case) - current (and maybe maximum) ammunition counts for all the other full-screen attack scrolls - indicator for when a full-screen attack is currently active/used - hitbox widths and heights (of actual body-boxes, maybe again with top-, bottom-, left-, and right-part, aswell as screen-dependent or absolute, but also sprites) aswell as the current (movement) direction for Hagane, enemies, and their projectiles - - - Some observations: Mashing inputs during load times seems to have no influence. It seems that holding forwards to walk (if I remember correctly, it is 1 pixel per frame) is as fast as holding forwards and down to crawl forwards. A simple forwards jump (with or without early horizontal spear attack) seems to not lose any time over walking either (provided one doesn't land in crouched pose, and maybe only when the height of the ground at beginning and end of the jump is the same, or the height difference is part of a specific set of possible options that don't cause frames of Imoto's movement stopping, since when Imoto lands and isn't right away positioned at the height of the ground so that the ground slopes would push him up to, then this process takes 1 frame). A highjump stays in place for 1 frame (when Imoto lands) if Imoto lands in the crouched pose, or if Imoto did a horizontal spear attack (shortly) before landing. It seems that there's no way to do any kind of ''armpumps'' (as in twitching or switching rapidly between poses) to push the character further while jumping/walking. During a high jump, one can spam sideways spear attacks without having to stay in place, and Imoto can also switch spear attack directions during jumps rapidly. Imoto can also do a crouched jump to have a different body-box midair. When enemy sprites (at least the flames at beginning) move around, then one can see some vertical transparent lines that the sprites pass (at around every tile coloumn's borderline probably), due to some brightness change in the sprite pixels of the enemies. In stage 1-1, Imoto's x-position stops for 1 frame when he lands at the very beginning, and it seems that every time that Imoto falls off a platform and lands in the crouch pose, there is 1 frame of sideways movement delay. In the water cave before the 1st boss, there is an item that (once it is obtained) takes long to finish an animation during which gameplay stops (and is most likely not worth obtaining for any of its intended purposes), and it has 3 different effects, depending on RNG: Either all health is restored, or a full screen attack appears that clears the screen from enemies, or Imoto is invulnerable for roughly 30 seconds to a minute. At the 1st boss, the full-screen lightning attack should be very well worth it with the high damage that it can deal if one gets there with a high number of health points. Apparently Imoto can carry at least up to 4 full-screen lightning attack scroll ammunition at the same time. The full-screen lightning attack should be very well worth it with the high damage that it can deal if one gets there with a high number of health points. 2 full-screen attack scrolls are close to the path, and 2 are further away (in the 1st part of the stage). Considering that the 1st boss has 19 invulnerability frames (meaning one can hit it only every 20 frames normally), and that the time that the full-screen attack costs is worth about 6 to 7 normal attacks means in the maximum Imoto health points case for 17 damage that there would be about 10*20 frames = 3 seconds & 20frames to 11*20 frames = 3 seconds and 40 frames of time to get each scroll for them to be worth it at the 1st boss fight. This most likely means that the top scroll should be worth getting but the far bottom left one in the cave not (for the 1st boss fight). Apparently, the 1st boss's AI (as in the future movement and attacks that it will execute) depends on previous L,R Y, B button inputs, their number and maybe also the duration of them being pressed (if it was odd or even). And apparently, for this AI, the game checks frames from far earlier aswell and even inputs during lag frames, but seemingly not controller 2 inputs. After the boss is dead, there's a short delay (which apparently cannot be avoided with inputs) for every health point that Imoto gains back, which needs to be minimized aswell, and the time delay for every missing Imoto health point is 8 frames it seems. (The last 4 stages are basically a repetition of the first 4 stages in the game, which should make some approaches and inputs recycle-able.) - - - Some further information about the game can be found on GameFAQ: https://gamefaqs.gamespot.com/snes/588505-musya/faqs/29316 As with the English version, the title screen has a choice between "Begin" (Hajimekara) and "Cont." (inue) (Tsuzukikara). Selecting continue will go to the password screen. Passwords in Musya are obtained by losing all of the lives and going to the Game Over screen, which presents a choice between "Cont." (Tsuzukeru) and "End" (Owaru). Choosing "End" reveals the password for the level in which Imoto (Jinrai in the Japanese version) died in. When the user decides to exit from that screen, he returns to the title screen. For the english version, there's level passwords like this MWTV Level 2 KVSW Level 3 KVMW Level 4 RQNJ Level 5 VKX4 Level 6 NZ1N Level 7 Z66F Level 8 and are as follows for the japanese version: MITA Level 2 KASI Level 3 KAMI Level 4 RENJ Level 5 AKU4 (The Japanese numeral for 4 is used) Level 6 NO1N (The Japanese numeral for 1 is used) Level 7 O66F (The Japanese numeral for 6 is used) Level 8 - - - My furthest WIP of the U.S.A. version so far is the following (and it still contains some sporadic lag frames aswell as frames of Imoto stopping shortly when he lands, which should both be further reducable): https://cdn.discordapp.com/attachments/218520158963105792/449767522984525834/Musya_3_scrolls_WIP.lsmv For comparison, this here was a slower initial approach (which gets 1 less scroll than the above WIP, by skipping the very 1st scroll from the above approach): https://cdn.discordapp.com/attachments/218520158963105792/449768444238495746/Musya_TAS.lsmv Here's a movie file to document an occurence in which Imoto passes through a flame (around frame 5058) without getting hit: https://cdn.discordapp.com/attachments/218520158963105792/449765893279318016/passing_through_a_flame_at_5058_without_getting_hit.lsmv Other than this, here's the lsnes RAM watch that I'm using: https://cdn.discordapp.com/attachments/218520158963105792/449698645831450674/Musya_RAM_Watch.lwch
collect, analyse, categorise. "Mathematics - When tool-assisted skills are just not enough" ;) Don't want to be taking up so much space adding to posts, but might be worth mentioning and letting others know for what games 1) already some TAS work has been done (ordered in decreasing amount, relative to a game completion) by me and 2) I am (in decreasing order) planning/considering to TAS them. Those would majorly be SNES games (if not, it will be indicated in the list) I'm focusing on. 1) Spanky's Quest; On the Ball/Cameltry; Musya; Super R-Type; Plok; Sutte Hakkun; The Wizard of Oz; Battletoads Doubledragon; Super Ghouls'n Ghosts; Firepower 2000; Brain Lord; Warios Woods; Super Turrican; The Humans. 2) Secret Command (SEGA); Star Force (NES); Hyperzone; Aladdin; R-Type 3; Power Blade 2 (NES); Super Turrican 2; First Samurai. (last updated: 18.03.2018)
Player (37)
Joined: 2/16/2012
Posts: 282
Some additional info: -JP version and US version differ in how jumps operate. They still cover essentially the same distance, but US jumps rise faster, remain at the top longer, and fall faster. JP jumps are more "normal" with how a jump should actually operate with respect to physics. This matters mostly for positioning. -There's a bug with damage and deaths. I don't have the addresses right now, but there are at least two weapon-related values: weapon level and damage. Damage is a function of weapon level, but maxes out at 2 or 3. Weapon level alters the animation and range. However, on a death, the game goes through a routine that effectively does this: weapon_level--; damage = weapon_level; Since weapon level maxes out at 6, and damage is normally at most 2, this can give a substantial damage attack boost. It has the caveat of needing a higher weapon level to be effective though. The current RTA runs use this bug starting at the Mudman boss.