Posts for marzojr


marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
So, after trying a while to obtain the SOZ2 level wrap, I decided to go another route. I hacked a save state to give me the perfect position and speed to get a level wrap. You end up on the loopback area, on the place corresponding to where the first push switch you encounter on the level (just right of the first sandfall). With the version I made, the level wrap put me inside the floor under the switch. This allows me to go under to the position corresponding to the area with the giant ring in Knuckles' path, which puts me more-or-less on the right Y position for the boss. I can also use the slope at the left to go up, or fall to its left to go further down. I had to fall, and move quite a bit to the left on the loopback area in order to be teleported to the boss arena, and even then it took a while for the camera to catch up I managed to crash the game several times in the process of getting to the correct position. So at least in theory, the level wrap is possible and leads to the desired results. Time now to investigate if the positioning required is at all possible.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
My typo was actually in that I eliminated LRZ1 level wrap, but LBZ2 is also eliminated because of the different method Amy uses. I had not considered the resets when moving to BizHawk; that would indeed be a big benefit. The downside would be having to use the slower level wrap in LBZ1 to get wheel glitch, or maybe fight from the top corner of the boss arena. Either option would probably be slower, but skipping LBZ2 (boss) and the transition cutscene will more than make up for the lost time. The wheel glitch is currently not being used in the TASes (except T any%) because it is slower than the other methods in use; maybe if it can be used to save enough more time in the second act than it wastes in the first, then it could become viable. Worth a shot anyway. In S3&K, they added a check to forcibly enable zipping when the angle is a multiple of 90 degrees; zipping is normally disabled when you are not moving mostly horizontally. This prevents the S3 floor/ceiling entrances by running down/up a vertical wall into a floor/ceiling.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
We can get enough speed for a level wrap with those inputs (need at least 11777 if x = 46:0 is reached, I managed to reach 12259 without issues); the problem is positioning. We need to be able to reach position 266 with a speed of at least 11777 (and not a lot more). So far, I have managed to get to position 261 with the necessary speed, which just bumps into the wall. After looking at how it is done, I managed to eliminate the LRZ2 level wrap from T run, he cannot do it. Also, now that I saw the technique, I agree that the AIZ1 zip will be easily doable, Tails can just set it up and drop Sonic into the floor. It is not at all what I have for SLZ1 in TiS1, which requires careful speed management to be possible. Will look into the other suggestions.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I know about the S+T stair clips by halting momentum; T solo can do them as well, and I have one lined up for T in S1 on SLZ1 that I have been procrastinating about implementing for years. I did not think it was possible in that spot, because the hyper dash has some very useful properties for entering terrain that are not easy to replicate. Can you share a gmv for SOZ2 movie so I can take a peek at the inputs? The Amy movie only goes to the middle of MGZ1, I think you picked the wrong one. But if Amy does it with down+A, Tails is boned either way.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
About S+T: AIZ1 zip after the fire is sadly not possible without HS: you can't get far enough in it to hit the spikes and stop without being too high to be ejected out of the floor. Though now that I think about it, it might be possible to push Tails into the floor of the flamer area and zip him out to give Sonic a push. That is a nice route for CNZ2, I had missed that. SOZ2 is not possible to level wrap; it has a 16-pixel wide column of solid tiles at the very start, followed by a wide gap without any terrain. You would need a speed of more than 32 pixels/frame, meaning zipping on a downward slope and jumping, which is not available. I don't think that DEZ2 level wrap will be faster for S+T than what is already present in the run. You still need to wait for the stairs to extend so you can enter the terrain, and there is nothing to bump into to quickly halt momentum. But it might be possible to stop Sonic in a higher position in the extending stairs, so that Tails can drop him more quickly (i.e., climbing "up" less) due to not having to move the camera. For T any%: Amy can do the LBZ2 level wrap? Is there an easy movie available? I need to check, but I think that she can do it because her standing height is higher than Tails'. If this is the case, then Tails can't do it. DEZ2 level wrap: ah, I forgot, Tails can likely do it earlier, in the first stairs. Nice catch. Out of curiosity, which OS are you on? I am currently on Windows, so I was thinking of maybe moving the runs to use Bizhawk instead of Gens. Although to be fair, changing from an inaccurate emulator to another slightly less inaccurate emulator is not much of a win, as far as I am concerned...
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
/delurk I have been seeing all the new tech for the game, and thinking of coming back into it to update the S+T any%, HS+T newgame+, and T any% runs. I can see the following (potential?) improvements: S+T any%:
  • Break second loop in AIZ1 to skip the tree;
  • MGZ1 level wrap into skip;
  • CNZ1 level wrap using spindash into spikes instead of lookup+drop into spikes; also maybe using T to make barrel bob up and down while Sonic spindashes through;
  • ICZ2 boss skip;
  • MHZ2 early capsule hit?
  • FBZ1 level wrap in starting area using Tails;
  • SOZ1 new level wrap using slope at start;
  • SOZ2 wall entrances through loops, maybe slide skip;
  • LRZ1 new level wrap right at the start;
  • DEZ1 gravity skip, maybe?
HS+T newgame+:
  • Improve second loop break in AIZ1 to skip the tree (avoids using a hyper flash and losing speed);
  • MGZ1 level wrap into skip;
  • CNZ1 S+T any% level wrap is probably faster now;
  • ICZ2 boss skip;
  • MHZ2 early capsule hit?
  • FBZ1 level wrap in starting area using Tails;
  • SOZ1 new level wrap using slope at start;
  • SOZ2 last wall entrances through loop might save time;
  • LRZ1 new level wrap right at the start.
For T any%, it is slim pickings:
  • MGZ1 level wrap into skip;
  • ICZ2 boss skip;
  • SOZ2 wall entrances through loops;
  • LRZ1 new level wrap right at the start might be possible.
Have I missed any? And any takers to help me optimize, considering how rusty I probably am?
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
mike89 wrote:
Something completely off the wall for the more technically inclined: a friend of mine was doing a S3&K speedrun and... this happened: https://www.twitch.tv/videos/348033969?t=00h40m18s That link should jump to the relevant part, but the whole run is included for context. Basically, with no emeralds, the runner enters a special stage, is placed in the hidden special stage 8, and then is gifted all seven Chaos Emeralds upon exiting. You'd think after 24 years I'd have a handle on this game, but yet again I am utterly bewildered.
Note that after this he lost his shield and did insta-shield with more than 50 rings without transforming into super. So the "gaining all emeralds" is probably a graphical glitch in the results screen. It does match with legends about the 8th special stage giving all emeralds, and a similar occurrence might be the root of these legends. I am curious what caused the 8th stage to show up, though. This points to memory corruption (and maybe the all-emeralds display as well); but it could have happened at any point in the run, though.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Falling has nothing to do with the crash, it is just hitting the badnik on some frames. The cause is well understood (there is even a guide on how to fix it). Sadly, there is zero ACE potential.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
As WST said, there is no change in direction. When you spindash, the camera moves back to where it was 30 frames ago, then it steps 2 frames at a time until returning to the current frame. If this is enough to scroll the object offscreen, then Sonic will just go through the object: most objects do not check collisions with Sonic when they are offscreen. Some hacks clear the position buffer when you spindash, so that the camera locks in place instead of scrolling back.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
marzojr wrote:
Timing comes from timing of some instructions being slightly wrong,
Actually, now thati think of it, the source of timing differences vs real hardware is most likely ROM refresh, DRAM refresh, 68k<->z80 bus contention, and 68k stalls when the VDP FIFO is Full. ROM refresh is ready to emulate (2 cycles delay of the 68k when it accesses ROM every 126/130 cycles alternating), but neither Gens nor GPGX emulate it. DRAM refresh is complicated and less understood; it is also forced to occur in lockstep with VRAM refresh when a DMA os going on. Outside of DMA, It can add 0, 1, 2, or 3 cycles every 130 or so cycles depending on when it happens. Again, neither emulator does this. The VDP FIFO full stalls depend on accurate emulation of the VDP and FIFO. GPGX emulates the FIFO (kind of) and stalls, Gens emulates neither. 68k<->z80 bus contention causes delays on 68k or z80, depending on relative timing. This is probably the hardest to emulate because it requires perfect emulation of 68k, z80, and VDP down to bus access timings, as well as emulating ROM and DRAM refresh. Of all available emulators, only Blast'Em comes close to emulating all this correctly.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Note that what I said is specific to Sonic games: they don't do anything tricky with the hardware, and are relatively easy to emulate well. The closest these games come to doing anything tricky is the waterline in some of S3&K's levels (e.g., AIZ1/2) to prevent CRAM dots from showing up on real hardware. This isn't an issue on Gens or GPGX, since neither emulate it.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Evil_3D wrote:
Can explain the "accuracy" differences between Gens and Bizhawk in a genesis Sonic game please?
For Sonic games, this is mostly timing and the fact that Gens did not emulate address errors. Timing comes from timing of some instructions being slightly wrong, as well as DMA speed being slightly off. This can cause differences in lag in gens vs real hardware. It can also remove some edge cases that happen in real hardware (such as the crash you can get in LZ1 if you roll at the end of the level). There are more inaccuracies in Gens, but they are not relevant for Sonic games. The non-emulation of address errors may cause the game to keep running ina glitched state instead of crashing. This is relevant for any ACE glitch. But to be honest, BizHawk does not have perfect timing either, so some things are wrong on it compared to real hardware as well.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Here is how the glitch works: when you enter the boss arena, 7 objects are created and their RAM addresses are stored (as words) starting on $FFFFA808. So $FFFFA808, $FFFFA80A, $FFFFA80C, etc. The first two objects are the wood bars that hold the spikes; the other five are the spikes. They are moved by the background deformation routine for MGZ2 when the boss arena is activated. Now, the list is set only when the objects are created. If the object is destroyed, it will still be on the list. The deformation routine does not check if the object has been destroyed, and will happily move the deleted object around, or any other object that happens to be allocated on the same slot. These objects are freed some time after defeating Eggman. This happens when word @ $FFFFEEC6 is set to nonzero, which sets byte @ $FFFFEED3 to zero, after which the objects delete themselves. But this is mostly irrelevant. As far as I can tell, all of this is essentially on a timer. The only relevant actions is when to enter the arena, how to manipulate the slot used by the capsule, and how fast to break the capsule; everything else depends only on how fast you kill the boss. So add RAM watches for the 7 words starting at $FFFFA808 (in hex). For each of those values, prepend 'FFFF' and add a RAM watch for the hex longword at the resulting location. You want any of these to be $8672A, the code pointer for the capsule, when it spawns. Since everything is essentially on a timer, the only thing that I could really do to improve it is make Tails break the capsule faster; here is a video with the capsule being destroyed on the first frame possible. As it turns out, by manipulating when I entered the arena, I needed only to hold right with Sonic to manipulate the capsule to a favorable slot. So: same in-game time, tiny real time gains, compared to Evil_3D's version.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Evil_3D wrote:
This is a new MHZ2 boss strat, moving Tails to hit robotnik off-screens save some time in the auto scrolling section, and with some slot manipulation with dust particles you can let spawn the capsule buttom inside the boss fight, I don't have the tech details, but I think marzo can explaint the process better and get a more optimized fight
Nice work. I will look over the video and the disassembly over the weekend and see what comes out.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Danfun64 wrote:
THAT BEING SAID, some things are broken in this build (hiding original hud and skipping boring stuff), so general use is not recommended.
Those features only work reliably for the original games; for hacks, it is a crapshoot. If it is not working on the originals, then please create an issue in GitHub .
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
It is not possible to trigger the level select screen with the audio glitch: the entirety of the sound code is executed by the z80 coprocessor running from it's dedicated RAM, and reading ROM banks for track/sfx data and PCM samples. Any crashes are confined to the z80, and do not propagate back to the main cpu, which is required to trigger the level select. S3D uses a 16-bit integer for storing ring count, which means either 32767 or 65535 rings. Which case depends on which class of comparison instructions are used, signed or unsigned; but it does not matter because I think there is a hard cap long before that (but I'd have to check to make sure). I doubt you will find anything on this route, though.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I did explain just a couple posts above how the walk-on-water object despawning was the key to the quick transition, you just forgot about it.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Evil_3D wrote:
No sir, no vacations for you, I want HCZ2 and the run synced tomorrow or I will summon Supreme Calamitas in your house :D BTW, I don't care if Sonic dies if we can save some in-game time seconds in the level the explanation of the glitch is written in the previous pages by marzo, maybe aroung 50~65 I don't remember correctly, or betwhen pages 13~20 by a HHS' reply
I have it better explained somewhere, I will put it here when I have time to dig it up. But the gist of the matter is to despawns the walk-on-water object by moving far enough offscreen, then create breaking dust at the right times, and manipulate the camera X position so that: 1) the walk-on-water object slot is filled with braking dust when you hit the last starpost; 2) the braking dust despawns on that same frame; 3) the camera is far enough left that you hit the starpost that the boss does not down on that frame. When all of that happens, the boss will spawn on the walk-on-water object slot. After the boss is defeated, it becomes an object that changes the screen boundary for the act transition. When the score tally triggers, and act 2 loads, the walk-on-water object is forcibly reloaded on its original object slot, replacing the screen boundary changer, so the screen remains locked during the transition.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
That is correct, and also applies to Sonic (or Knuckles, or 1P Tails): when the address at $FFFFB042 (player 1) or $FFFFB08C (player 2) correspond to an object whose x position and width include the corresponding character's x position, he is able to stand without balancing. The game does not check y position, so this allows characters affected by slope glitch to stand without balancing and spindash. However, most objects in S3&K don't load of they are too far away vertically. By the way, I made a correction to my previous message, and the correction is mentioned in this post: I had previously gives the RAM address where the object Sonic is standing on, not the address for Tails.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Tails generally depends whenever he is offscreen and the is a change in the code pointer (object id in S2) of the object he is standing on. This applies to slope glitch because the game considers him to be standing on something. There is a bug in the check in S3&K: only the top half of the code pointer is checked. So Tails didn't always despawns when he should. More specifically: word at $FFFFB042$FFFFB08C is the address of the object Tails is interacting with; the longword at the object's address is is code pointer. But since the check is bugged, it looks only at the word at the object's address. The word at $FFFFF700 is the top word of the code pointer of the last object that Tails interacted with, according to his CPU control code. Every frame it is compared to the word mentioned in the previous paragraph. If Tails is onscreen, then the word at $FFFFF700 is updated; otherwise, Tails despawns. Edit: fixed address.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
For what is worth: I have been refreshing up a bit on the subject (it had been years since I last studied this, having left physics for computer science) and while the core of the subject matter was still intact, the more subtle aspects were completely missing. I now see where I was wrong, and I concede the point entirely. I also would like to apologise for acting like an a$$. I always had a tendency to act this way, and it seems to be getting worse with age despite my efforts to suppress it...
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
To quote a movie: amazing, everything you just said is wrong. Except maybe for the first line, but you are applying it to the wrong person; so I will give it partial credit. By what you said above, it is evident to me that you lack anything being a basic grasp of differential geometry. This i assessment comes from the last two paragraphs you wrote, in particular, but the second half of the third paragraph is also telling. You also failed to appreciate that Newton-Cartan theory does not have a metric; it has a connection (Christoffel symbols/covariant derivative), but no space-time metric. While writing my other reply, there was a much longer post that ended up being scraped because it was a bit of a rant and I thought it might not have been necessary. I now see I was wrong. Diffeomorphism invariance is not a property only of the EFE. The entire theory, and all equations that come from it, have this property. It was called "principle of general covariance" by Einstein; and it basically boils down to a requirement that the laws of physics must be written in terms of geometric objects (scalars, vectors, tensors) so that they (the equations) will have the same form on all coordinate systems (and yes, I am aware of the distinction between active diffeomorphisms and passive diffeomorphisms; they don't matter here). This principle had come under fire since 1917 (at least) because many authors felt it had no real content - because any physical theory can be written in such a way. You can read about this on any graduate-level textbook on GR, or on lecture notes for such a course. For example, check Sean Carroll's (https://ned.ipac.caltech.edu/level5/March01/Carroll3/Carroll5.html). Now comes the part were it is a bit of a rant: usual formulations of Newtonian mechanics and SR are not written correctly: they are written assuming a certain class of coordinates, inertial frames, and lack things that would make them lose diffeomorphism invariance. Specifically, they do not make use of covariant derivatives, and they do not use a general metric. This additionally includes not making distinctions between vectors and 1-forms, and etc, in Newtonian mechanics. When you correct these deficiencies, you get versions of Newtonian mechanics and SR whose laws are the same on all coordinate systems. Newton-Cartan theory is one of these. The laws for corrected SR match the versions used by GR, by the way, except that the metric is not a solution of the EFE, but is ultimately obtained by doing coordinate transformations from a Minkowski metric. The usual rules for "lifting" laws from SR to GR (partial derivatives to covariant derivatives, etc) are not needed with a proper formulation of SR because they should have been baked into SR instead.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
p4wn3r wrote:
marzojr wrote:
That is exactly backwards: any theory can be written in diffeomorphically invariant form: there is even a formulation of Newtonian mechanics (plus Newtonian gravity) written in such a form, and this one is valid (i.e., had the same form) on all reference frames. As a bonus, gravity is even related to the curvature of space-time in this theory as well (FYI, this version of Newtonian gravity is a lot more complex than I am letting on).
Please provide a reference for this statement, and forward me the specific theory you have in mind.
When you ask for a reference, do you mean the part about it being possible to write any theory being in diffeomorphically invariant form, or the part about the formulation of Newtonian mechanics + gravity in diffeomorfism invariant form? Assuming the latter: I did have a theory in mind, it is called 'Newton-Cartan theory'. It was first developed by Élie Cartan, a french mathematician, and published in the early 1920s; it has the distinction of being the first non-relativistic diffeomorphism-invariant theory of gravity. In this theory, spacetime is non-metric (you have a spatial metric, and you have universal time, but it is not possible to define a spacetime metric), a non-metric connection which yields a nonzero Riemann tensor, and this connection is compatible with the spatial metric. There is a good summary in Misner, Thorne, Wheeler (Gravitation), chapter 12.
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
p4wn3r wrote:
I don't agree with this (popular) viewpoint. Every theory can be cast in a way that it's true on an arbitrary frame. For example, pick Newtonian mechanics in an inertial frame and evaluate the path an object will take. Now, go to any other frame and change the theory so that you have forces that make the object follow the same path and, boom, you have exactly the same results without making reference to inertial frames. What GR says is simply that the equations should be "pretty" (i.e. diffeomorphically invariant), if you drop that requirement you can derive any theory that you want.
That is exactly backwards: any theory can be written in diffeomorphically invariant form: there is even a formulation of Newtonian mechanics (plus Newtonian gravity) written in such a form, and this one is valid (i.e., had the same form) on all reference frames. As a bonus, gravity is even related to the curvature of space-time in this theory as well (FYI, this version of Newtonian gravity is a lot more complex than I am letting on). So this is not a requirement of GR in the sense that it does not constrain the theory in any meaningful way.
p4wn3r wrote:
I think GR is better defined by the fact that, unlike other physical theories, the geometry where interactions take place is also dynamical (space-time can store and release energy, etc.).
This is a much better point: but it is also false (as mentioned above).
Marzo Junior
marzojr
He/Him
Experienced Forum User, Experienced player, Published Author (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
It is a bit trickier than that. In Newtonian mechanics and special relativity, the definition of an inertial frame of reference is, strictly speaking, circular: the laws of physics are defined in terms of inertial frames, and the inertial frames are defined in terms of the laws of physics. Saying things about accelerometers and rotation just displace the problem, but it is still there. In general relativity, things are slightly better: it states that the laws of physics are the same for all reference frames, and defines a local inertial frame to be a freely falling reference frame.
Marzo Junior