Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The wall at the top of MGZ2 rises slowly once triggered; if you can trigger it early enough, it will have moved high enough that you can go under it. But you can't zip while it is moving, being inside a wall during that time is fatal.
I don't remember exactly how it works (it has been a few years), and I don't have access to my notes now; but I had figured out the speed of the rising wall, and how to trigger it. I remember that going above the level in a certain range of positions would mistakenly trigger it.
I had to figure it out to understand how to fight Knuckles' boss from above the screen as Sonic+Tails or Tails solo (only Tails solo run ended up using it because I figured out how to skip MGZ2 as Sonic+Tails, and it was faster overall).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
To clarify what I meant: the rule I would use nowadays would require you to turn super or hyper on any level where it is possible to collect 50 rings and you have the required emerald set. I would probably not add bonus levels to the run, and would require in-level rings and big rings.
Now that I think of it, 100% and maximum ring goals complement each other well in that they both require level exploration and this makes the run automatically avoid most of the things people complain about without being too arbitrary. Turning super or hyper on every possible level would even occur automatically (unless you are Sonic and grab a shipped before grabbing 50 rings).
Hmm. So maybe 100% + maximum rings.
Edit: regarding underflows: I did some with ridiculously low speeds (around 4100) for the MZ2 (S1) level wrap with Tails and Knuckles (before the final iterations in the actual runs), and like WST said, it is awful. For what it's worth, raw speed is not the only way to level wrap: you can also level wrap with speeds less than 4097 if using a different process; examples are wheel glitch in CNZ1 and the "super Sonic" glitch in OOZ2 (S2).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I made a post recently on the generic S3&K thread about the difficulty of doing so. TL;DR version is: for every underlying mechanism behind glitches, you would have to ban some instances of it working as intended but not others, as well as banning some pathological cases but not others. There is also the fact that it is a much bigger effort all around because the run is much longer.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
To be fair, I myself have come to consider the "no horizontal underflow" goal choice a bit arbitrary, even in the context of the old 100% Sonic run. Were I to do the run today, I would instead require that Super or Hyper transformation should happen in every stage where it is possible (i.e., there are enough rings). Back then, mike89 was (rightly) very vocal against the rule, because the motivation behind the rule (showing more of the levels) ends up not happening in spite of the rule whenever zips allow skipping parts of the level (or going above the level in other cases).
I did, however, set the precedent, for good or ill.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Hm, I thought I looked to HHS's post in the submission. Anyway:
* For AIZ, this is the post. The transition skip can only be done by Sonic or Sonic+Tails because you need the initial Knuckles cutscene. You should also read my follow-up post.
* For HCZ, this is the post. This can be done by all character combinations, but it will not necessarily be faster.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
r57shell wrote:
Changes of code (commits) itself with comments should be enough.
Otherwise I should for some reason explain technical details. It's too long text.
I don't see this reason.
I can try in short: if Do_VDP_Refresh() was called it was changing VDP_Current_Line. Now it's backed up.
Speaking of changes, might I persuade you to make a pull request for this? I found the added tools amazingly useful.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Nach wrote:
https://dev.tasvideos.org/ has been up for a few years now, but not necessarily has every bug been worked out. If users want to test and create a list of HTTPS-related bugs, we can fix them and then enable it on the main site.
Is there any specific location for posting bugs? Because I already found two: the 'View posts since last visit' link redirects to the normal (non-HTTPS) forums for the search results, and the 'search' link uses the non-HTTPS search form.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
That it forms a spiral can be proven by a geometric argument:
First, a remark: as you iteratively draw new inscribed squares, each new square will have the same geometric center as its predecessor. You only need to prove this for two squares (the outermost and its immediate successor); and it can be proven easily by noting that the diagonal vertices in each square will move the same amount but in opposing directions.
With that out of the way: we can now see that what changes with each successive square is its rotation and scale. Moreover, if at each step you zoom in and rotate counterclockwise so that the last square is a unit unrotated square, you can see that each new square rotates by the same amount, and shrinks by the same scale factor, as the previous square.
So the equations (in polar coordinates) of one of the vertices of the n-th square will be of the form
theta(n) = n*delta+theta_0
rho(n) = (scale^n)/sqrt(2)
Where n is the square number (0 being the outermost), and both delta and scale can be related to the ratio a:b, and theta_0 is the angle for the vertex you want. I will leave the rest as an exercise :-)
Edit: OK, I lied :-p.
Let r = a/b. Since a+b=1, we have that
b(1+a/b)=b(1+r)=1 => b = 1/(1+r)
=> a = r/(1+r)
Let R be the 'scale' factor in rho, above; R is better obtained from the square root of ratios of the areas of the first and second squares. The outer square has area 1; so we just need to compute the area of the inner square. Let c be the side of the inner square; this can be obtained by Pythagoras' theorem:
c^2 = a^2+b^2
Since c^2 is the area of the inner square, then R = c = sqrt(a^2+b^2) = sqrt(1+r^2)/(1+r).
Now to compute 'delta'. 'delta' is the angle subtended by a diagonal from the outer square and a diagonal from the inner square. Since the diagonals are at a 45 degree angle from the sides of the squares, 'delta' also is, equivalently, the angle between the sides of the squares. In our case, this is easier: it is the angle adjacent to b in the right triangle with sides a, b and c. So delta = arctan(a/b) = arctan(r).
Putting it all together:
theta(n) = n*arctan(r)+theta_0
rho(n) = ((sqrt(1+r^2)/(1+r))^n)/sqrt(2)
From this, we obtain:
n(theta) = (theta-theta_0) / arctan(r)
rho(theta) = ((sqrt(1+r^2)/(1+r))^((theta-theta_0) / arctan(r)))/sqrt(2) =
= exp( (theta-theta_0) * (ln(1+r^2)/2 - ln(1+r)) / arctan(r) )/sqrt(2)
Since we are interested in the limit r -> 0, and since exp is regular, we can take the limit of the exponent and substitute back:
lim{r->0} (ln(1+r^2)/2 - ln(1+r)) / arctan(r)
Both numerator (the difference of lns) and the numerator (arctan(r)) approach 0 in the limit; so by L'Hopital,
lim{r->0} (ln(1+r^2)/2 - ln(1+r)) / arctan(r) = lim{r->0} ((r-1)/((1+r)*(1+r^2))) / (1+r^2) =
= lim{r->0} (r-1)/((1+r)*(1+r^2)^2) = -1
So that
lim{r->0} rho(theta) = exp(-(theta-theta_0))/sqrt(2)
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Mitjitsu wrote:
I disagree, terrain ejection is zipping. Just because you can't move fast enough to outrun the screen doesn't mean it's not zipping.
Lets ignore for the moment the fact that you have to ignore what the words even mean to say this.
There are (at least) three problems you still have to deal with:
The Sonic 1 "no zips" run bans zips that eject you at high speeds; terrain ejection does not give you any speed;
Frame 786. This is the frame where every Sonic 1 run dies if you ban terrain ejection;
Zipping and terrain ejection are completely different code paths that run under disjoint sets of circumstances and have different purposes and mechanisms (see below). Sonic 3 even adds a way to disable zipping without disabling terrain ejection (see hollow tree in Angel Island, or the meshes in Flying Battery).
There are also many differences in the way terrain ejection and zipping works:
Terrain ejection only happens on air. Zipping only happens when you are moving on terrain.
Terrain ejection can happen to surfaces that are broadly in the way you are moving towards (if you are moving mostly up, that would be ceilings and walls on either side). Zipping happens to "walls" in the broad direction of travel (so walls if you are moving mostly horizontally, ceilings if you are moving mostly up, and floors if you are moving mostly down).
Terrain ejection is applied after movement routines with the intent to move you out of terrain if the movement routines would have moved you there (so you effectively enter terrain for a few processor cycles before being pushed out). Zipping is applied before movement routines; that is, it detects if you would have entered terrain and takes action before you do.
Terrain ejection gives a one time position shift of up to 32 pixels to move you out of terrain; if you are still inside terrain, you will usually be immediately ejected back to where you started, so it seems like you were never ejected at all; terrain ejection does not always kill your momentum. Zipping modifies your speed by up to 32 pixels opposite the direction you are moving, so that you move to the edge of the wall, and kills your momentum, so you stop there.
Terrain ejection can happen when you have zero speed (in both X and Y). Zipping cannot; you must have a speed of at least 1 subpixel/frame to zip.
Terrain ejection checks several points in Sonic's collision box. Zipping checks a single point ahead of Sonic's collision box, which gets further away the faster you are going.
Terrain ejection generally prevents you from moving left or right when you are completely inside terrain (though you can force ejection in one direction under the right conditions). Zipping is (in)famous for allowing you to move left or right extremely quickly when you are fully inside terrain.
This is off the top of my head; I could go on, but I think this is enough to prove my point.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Twisted Eye wrote:
Hmm, a "100% no horizontal underflow" run that skips at least one boss and zips through entire levels. I am reminded of the "no zips" Sonic 1 run that used zips and got published anyway.
1) this run does not contain horizontal underflow; this is different from zipping, and can be achieved without zipping.
2) that Sonic 1 run does not contain any zips except for unavoidable micro-zips when you bump into walls; terrain ejection is not zipping.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The glitch works like this: in the normal course of things, the FBZ mesh (and the AIZ hollow tree, for that matter) sets the 'standing on object' status flag and an object control flag that disables zipping. The former is standard for objects you can stand on, and it prevents the player from going into a falling state when there is no terrain underneath them; the latter is done so that the object can control how the player moves and not care about walls. The object also puts you on the animation mode for that pseudo-3d rotation when you enter the mesh.
You trigger the glitch by entering this state and causing the object to be unloaded right after. The object does not clean up after itself, so you are left with those bit flags enabled. This is accomplished by scrolling the object offscreen; this happens when you enter the object in forced spin mode (from entering the tunnel offscreen). Also, you are stuck in the pseudo-3d animation now until something clears this mode (not a lot does; an example is super transformation).
When you transform to super state, all object control flags are overwritten to specific values for the super transformation. This prevents movement, terrain collision and object interaction for the duration of super transformation (and is why you can go through objects during super transformation). When the transformation ends, you are left with an all-zero set of object control flags, which disables the no-zip effect.
Sonic being picked up by Tails would likewise lose the effect, as would grabbing handles in FBZ (I think).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
To be fair, they could prevent that easily by assigning an arbitrary (say) 10 seconds for each loading screen, independently of how long it actually takes. This would complicate timing of the run, but it would penalize abusing the loading screen uniformly regardless of how good or bad your computer is.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
If you really must :-p (watch with FFFFB0:0707 PAR code)
It depends on the goals of the run; if you are going for any%, then any glitch you don't use which could save time will increase the odds of the run being rejected. Things get murky past that; Nitsuja once advised me on what he considered the only really meaningful glitch categories:
all glitches allowed;
only glitch that do not teleport you to the end of the level or allow you to skip levels;
glitchless.
I kind of agree with him on that; I think that the no-zips Sonic 1 run is rather arbitrary in what glitches it uses, but it was well received and ended up being published (and yeah, I even helped making it).
In regards to a 100% run, one goal that can be made is to require the use of super form on every level you can achieve it, but it leads to things like the movie above, or to zones like the newgame+ run where I collect the first giant ring, enter terrain in the first possible spot and level wrap immediately after. That is, the letter is obeyed while the spirit is not. And it can be considered arbitrary because of that: the 100% portion is met by collecting all emeralds, and you can still abuse glitches at will.
Sorry for not really answering the question in a way you probably want to; the question is just not that easy...
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I think I will use it, yes; I compared it to the original, and it seems like it is an official hack of it (some instructions are changed to jumps or function calls to new code to render the translated text, which is in previously-unused segments of ROM). The English text is slower, though, so that the WIPs will have to be adjusted.
A status update: I am still working on figuring out the transitions; it led me down to a vastly deeper rabbit hole than I thought it would. I will give more details later, when I have the new version of the script done; but suffice to say, this game is HARD to reverse engineer (but I already know how to automate frame-perfect skips of a lot of "boring" stuff now).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
After watching MegaGWolf playing this game I decided to pick it up.
After trying my hand at it for a bit, I found the RT speedruns and eventually found this thread; and I had settled into the same base route (either debug merchant or 777 gold + the occasional gold bar). I had failed to find some of the movement techniques, with the result that I was losing frames at every turn, so I won't post these WIPs.
So I decided to step back and analyze the game to the death first. Here is a first version of a Lua HUD for Gens, based on a partial in-progress disassembly.
I am still trying to figure out how screen transitions work, so I can automate skipping them; I will also add an auto-climber (I already know the conditions to maximize speed) at some point.
There is also a RNG predictor display, which I made for luck-manipulation purposes back when I was trying the 777 gold route. The predictor shows the next few RNG values (NOT the RNG seeds), and it is clickable. Clicking it will change the RNG seed to match the seed corresponding to the value clicked; this was meant to test the ranges of dropped gold. Unfortunately, there is a LOT of stuff that affects RNG seed, including those spores that the Myconids throw, but it also auto-advances every few frames. So the 777 gold route is going to be HARD.
Oh, and gold is randomly selected when you collect it, which may include god knows how many other calls to the random number function.
A curiosity: this game uses the exact same Rng function as Genesis Sonic games.
Edit: oh, almost forgot: there is a sequence break possible with debug armor and infinite jump: you can skip the fourth zone (the castle with all the conveyor belts) by going behind the city and infinity jumping your way inside the castle. The unassisted speedrun has this skip.
Edit 2: screenshot:
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Ajavalo wrote:
This "no zips" run by Aglar has a clearly defined goal -zipping can be defined without ambiguity- and entertains the public by showing much more of a very broken game.
True enouh: there is a piece of code that gets executed only when zipping, so it can be used as a reference. But if you add a wwatch for it, you will see that there is zipping in the "no zips" run — whenever Sonic is on the ground and hits a wall. In some cases, it is even used to gain a small speed boost — accelerating to almost a pixel/frame opposite to the wall.
This is OK for the run, which uses a definition of "zip" which is a bit more subjective: it requires you to be ejected at "high speeds".
Some glitches are more straightforward to define and can be prohibited by the run's goals: slope glitch is unambiguous (have "standing on object" bit set while not standing on an object), wheel glitch (having "stick to convex surfaces" bit set while not being inside the area of effect of the object that set it), or the "Super Sonic" OOZ glitch.
But then you encounter some grey areas: consider the FBZ1 glitch which disables zipping: you can now run through walls! And while you also get slope glitch, you could get rid of it quickly by standing on another object before leaving the bounds of the source object. You would fulfill the letter of the rule (but maybe not the spirit). But theoretically, we might find a way to trigger only the run-through-walls effect (it is a single status bit). It disables zipping, allowing you to run through walls. Should it be banned on principle?
Moreover, other things can be complained about (and have been): non-zipping terrain ejection (see GHZ2, SBZ2 and SBZ3) and sprite ejection are examples. They were called zipping in the submission thread by some; but they technically are not (different code entirely). Moreover, banning them would make the game unplayable (just by jumping into a ceiling, falling to the ground, or touching a solid sprite at any speed). You can get around this issue by requiring that Sonic must be ejected towards the side he came from.
What about the cases where you can gather enough speed to go through a thin object or terrain entirely? You don't trigger either form of ejection that way. Should these also be banned?
But what about the cases where you get past an object by scrolling it off-screen? There is no sprite ejection in this case either (you generally don't collide with off-screen objects). Ban it too?
Next you have ledge clipping (you escape being ejected) and stair clip (falling throuh terrain) which are cases of clipping throuh terrain by not triggering terrain ejection: banning one without banning the other gets arbitrary, but can be done.
But now you are banning some cases of zipping, but not others; banning some cases of no zipping but not others; banning some cases of terrain ejection, but not others; banning some cases of no terrain ejection but not others; banning some cases of sprite ejection, but not others; banning some cases of no sprite ejection but not others. You now have a mess of rules.
Ajavalo wrote:
The goal of "no zipping, underflows or slope glitch" would certainly bring new life to TASing Sonic 3K, where almost every level is broken by one of those techniques. There are a lot of other techniques to use, with their own great entertainment value.
The issue here is people wanting to do it; it takes a lot of effort to make a glitchy Sonic run; it takes a vastly greater effort to make a glitchless one. And depending on the goals of the run, it may be deemed an arbitrary goal set and be unpublishable.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
FYI, there are bin/cue versions of all SCD regions, including JP. Moreover, the ISO versions need properly named mp3 files or you won't have pcmdigital audio because it is in audio tracks which are not contained in the ISO.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
@JXQ: normally the launchers disable usual physics and run code to move Sonic based on the speed they set. When you enter the tube in a hurt state you keep normal physics and the launcher running physics, so it happens twice. If you activate again, physics will run once more for each activation.
