Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The color was blue so as to not stand out too much; changing it to red becomes too distracting and draws too much attention to the HUD as opposed to the game. For the timers: I can see adding an option to show it in seconds:frames, but I can't see it becoming the standard: when you are playing frame-by-frame, it is more useful to know that the invincibility will last (say) 200 frames than 3 seconds 20 frames.
Adding the display for perfect rings is a nice touch, I can see that being useful.
The problem of the input display area is that it may conflict with S3&K's multiple bosses.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The other ones get hacked as well; there are several threads about hacking the more modern games on the Sonic communities. Some of the factors that lead to the Genesis games being hacked more often are: (a) they are better understood, (ß) they are classics and (3) they have so many more restrictions due to hardware limitations that it takes more skill to do it.
Some would also say that it is because they are better than those for all the other systems...
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The problem you ask is harder than you think -- it depends on how much angular momentum is lost during collapse. If you assume no angular momentum is lost, you can get an upper bound. The issue then becomes that stars are messy -- they are not solid rotating spheres with uniform densities, so computing angular momentum accurately is difficult.
Assuming the Sun is a solid sphere with uniform density, we can estimate its angular momentum; it could be wrong by more than one order of magnitude. The estimate uses the following formulas:
I = (2/5)*m*r^2
L = Iωω = v/rI is the moment of inertia of a solid rotating sphere of uniform density, m is the mass, r is the radius and ω is the angular velocity. Since we are interested on the angular momentum per unit mass (to compute the radius of the ring singularity), we want this:
A = L/m = (2/5)*r^2*v/r = (2/5)*r*v
so we can compute the singularity radius A/c. I will leave the number plugging to you.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Here is the complete TAS map pack for this game (44.6 MiB). It includes the maps from TSC, plus the ones I made using Gens-map hack, all with solidity information added from dumped images generated by the SonLVL level editor (plus heavy ImageMagick/bash trickery to automatically recolor and resize the solidity). Where it makes sense, I made one map per solidity path. Only has the single-player levels; I may do the 2p mode levels as a separate file later.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
The units seem to match. (The unit of angular momentum seems to be kg·m2s−1, so if we divide that by the mass and the unit of c, ie. m/s, we end up with just meters.) However, I'm having trouble understanding how the angular momentum of a rotating body is calculated.
[snip]
This doesn't sound right to me. If dealing with the rotation speed of a black hole would be impossible, then wouldn't it likewise be impossible to calculate the Kerr metric in the first place, since it deals with a rotating black hole? I don't quite understand.
For a black hole, it is one of the parameters of the solution: a variable you plug in, very much like the mass of all black holes or the charge in a Reissner–Nordström or Kerr-Newmann black hole.
For other bodies, preferrably non-black holes, it is more complicated:
Warp wrote:
Wikipedia cites the formula for the angular momentum of a single particle to be the cross-product of its distance from the center and its linear momentum. While this gives the angular momentum of one single point-like particle, how do you calculate the angular momentum of a(n almost) spherical object?
In the classical (nonrelativistic) world, the angular momentum is a vector that can be decomposed into two components: the "intrinsic" or "spin" angular momentum (which is the part of angular momentum strictly about the object's center of mass) and the object's orbital angular momentum (which the part of the angular momentum strictly about an external reference point). The orbital angular momentum is usually computed by calculating the total and spin angular momentum and subtracting the latter from the former.
Both are computed by integrals: given a mass density rho(x,t), a position x, a velocity density v(x,t), using xcm(t) to denote the center of mass and O(t) to denote the point about which the object is orbiting, then the total angular momentum is:
L(t) = integral over all space of (rho(x,t) * cross(x - O(t), v(x,t))
while the spin angular momentum is
S(t) = integral over all space of (rho(x,t) * cross(x - xcm(t), v(x,t))
In relativity, you can't represent the angular momentum by a vector: the cross product is representable as a vector only in 1, 3 and 7 dimensions (this being related to the fact that the only normed division algebras with imaginary units are the complex, quaternion and octonion algebras), and you need to use a tensor to represent it in spaces with dimensions other than those.
In relativity, the mass density is not a good candidate for use in the definition of angular momentum due to lack of invariance when changing coordinates; the stress-energy-momentum tensor is used instead. This gives a 3-tensor density which, when integrated, gives an asymmetric rank 2 tensor for angular momentum. The tensor integrals involved aren't over all space-time, but over a space-like slice of space-time -- basically, you select a observer and integrate over the set of all points he considers simultaneous. Spin, orbital and total angular momentum are all defined in an analogous way to the non-relativistic case, with spin being now related to the center of energy-momentum instead.
Warp wrote:
(Thinking about it, since angular momentum deals with vectors, and the total angular momentum of a spherical object would be sum of the angular momentums of all of its points... wouldn't they sum up to be zero?)
Nope: the cross product makes sure of that: all points rotating about a given point will have an angular momentum pointing in the same direction if they are rotating in the same direction.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
I will start with the easier question: if the black hole is a rotating uncharged black hole with mass M and angular momentum per unit mass A then the radius of the ring singularity is A/c. From that, you can infer the diameter of the ring. Although to be honest, things aren't really as simple as I made them seem to be: this is coordinate radius; how it relates to what is usually meant by "radius" is hard to say, as the geometry within the disk is not exactly euclidean.
As for the rotational speed of the singularity: there is no good way to answer this question: saying "pie" is probably as good an answer as anything else.
The issue here is that we are dealing with a singularity -- the coordinates fail at these points and, being an intrinsic singularity, means that all coordinate systems will exhibit this failure. The coordinates are not the ones that fail -- the equations of GR also fail there (they are, in fact, what causes the failure of the coordinate systems). The singularity is off-limits for GR, plain and simple.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
It is correct: it is a rotating ring singularity. The event horizon and static limit are oblate spheroids in the coordinate system where the singularity disk is a "point", so they remain more-or-less that shape.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Once I finish the updated newgame+ and update the Sonic + Tails any%, I will try out the Tails any%. I have been wanting to do it for a while now, what with several Tails-only tricks available.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The real reason for selecting timelike geodesics as the trajectories of massive particles in relativity is that they are the ones that ensure that such particles move at subluminal speeds in space. From this choice, you get for "free" that massive particles cannot ever either accelerate to luminal or superluminal speeds (in space), nor double back in time.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
Btw, this is another thing that puzzles me. What causes everything to traverse on the time axis, and why cannot we move freely on the time axis in the same way as we can on the other spatial axes (ie. why can't be freely move faster or slower in time, or even backwards)?
I will base the answer in Relativity; it is the only theory that has anything to say in the matter thus far.
As I mentioned earlier, the universal limiting speed (the speed of light) changes the structure of space-time. This change is in both geometry and topology; but the bit that is relevant is that it allows the definition of a space-time "distance" function that is the same for all observers (whether inertial or not).
This "distance" function (called "interval" in relativity) splits geodesics (and "forced" geodesics too) in 3 classes -- timelike, spacelike and null (or lightlike).
A geodesic [its velocity vector] can never change its class: if a geodesic [velocity] is timelike, it will always be timelike; likewise if it is spacelike or null. This is a theorem of differential geometry, being a purely geometric effect.
Moreover, any spacelike vector can be turned into any other spacelike vector by a rotation (in space-time) and a change in scale; but for timelike vectors, this is only true if both vectors point to the same general direction ("future" or "past"). This is a consequence of the above: the timelike vector would need to become spacelike or null (or both) along the way to change from pointing to the future to pointing to the past, which is impossible.
In relativity, massive particles are assumed to move in timelike geodesics, while light moves in lightlike geodesics. This assigns a nonzero timelike speed vector to all massive particles, which forces them to move in time.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Tub wrote:
We're all in agreement that the most accurate emulator should be used if possible. The question is, what're we gonna do when a TAS on an older emulator is submitted? Instant-reject?
I would say 'yes' to instant-reject, with a small caveat.
Ideally, it should go along these lines: an announcement has to be made at a certain date clearly stating that, starting from that day, only the new emulator version will be accepted or the movie will be rejected. The announcement will also grant one exception -- everyone that was already working on a TAS on the older version may get grandfathered if they meet certain conditions.
For example, the conditions could be:
At least one recent public WIP from before the announcement;
said WIP must be of good quality (publication quality, or very close to it) and it must comprise of either at least half of the game (for shorter games), or it must be at least (say) 10-20 minutes (for longer games such as RPGs);
the TAS must be finished within a year of the cutoff announcement.
Failing to meet the conditions will lead to an instant-reject. Allowing a TASer to show a private WIP to an admin might also be grounds for an exception, but that would be up to the admins.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
And how exactly do you know that light has zero rest mass? After all, classical electromagnetism predicts that light with energy E has momentum with magnitude p = E/c; in Newtonian physics, momentum is p = mv, which means light has momentum p = mc hence mass m = p/c = E/c^2. Having mass, light is attracted by gravitational fields, as well as generating its own field. This is consistent with what I talked about earlier about the possibility of treating gravity as curvature of space-time in Newtonian gravity -- Élie Cartan was the first to show this when he did just such a model.
When you move to relativity, the theory basically demands that light has zero rest mass; one reason being that the energy E, momentum p and rest mass m of a massive body are related by the equation E^2 = (pc)^2 + (mc^2)^2. The relationship between E and p for light (p = E/c) is still valid (being a consequence of Maxwell equations, and not of Newtonian mechanics); the two relationships are the same if the rest mass of light is zero. Hence, the rest mass of light being zero is a prediction of relativity -- one which can't really be directly measured because there is no rest frame in which to measure the rest mass of light.
Moreover, when you move to GR, light will also respond to gravitational fields (being the curvature of space-time), as well as generating its own field (because it has energy and momentum, which are the sources of gravity in GR).
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
Is this what causes time to pass at different speeds at different altitudes?
It is a factor, yes, but the real cause of that phenomenon is the universal limiting speed (which induces the space-time distance).
Gravity being the curvature of space-time (instead of just space) causes other things more directly: for example, it is the cause of the factor of 2 difference in the gravitational lensing between Newtonian gravity and GR.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The visualization is correct, with the caveat that it is space-time, not space, that curves.
The maximum speed c is what differentiates between Newtonian gravity and GR: you can talk about Newtonian gravity as curvature of space-time just as you can for GR. The fact that GR (or SR, for that matter) has a universal speed limit just gives a different structure for space-time, for example by allowing one to define a (pseudo-)distance function in space-time that gives observer-independent "distances", something which is impossible in Newtonian space-time: you can define a distance between different points at the same time or between the same point at different times, but not between two different points at two different times. Being able to define such a space-time distance is important: it is basically what allows a universal limiting speed to be possible.
And an important nitpick: geodesics are not the shortest path between two points, but the extremal paths. In ordinary Euclidean space, these two mean the same thing; but in space-time, things get tricky: paths followed by normal particles are actually the paths with the longest "distance" (lapse of proper time) between the two points ("timelike geodesics"); for more "spatial" separations, it is the shortest "distance" (proper distance) between the two points ("spacelike geodesics"); and for light, it is zero ("null geodesics" or "light-like geodesics").
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
Anyways, what I do not understand is why the geodesics are different for objects moving at different speeds. For instance, if I throw an object horizontally at 1 m/s it will follow a drastically different geodesic than if I had thrown it at 2 m/s.
The best way to think about it visually is this: speed in space-time is analogous to an angle in an Euclidean space (strictly speaking, it is the rapidity -- the hyperbolic arctangent of speed -- which is analogous to an angle); a Lorentz transformation is exactly analogous to a rotation in Euclidean space (but since space-time is hyperbolic, it would have to be an imaginary angle).
You can visualize this easily using the surface of a sphere (Misner, Thorne and Wheeler use an apple in Gravitation, but the result is the same). In case 1, you have unit speed in one direction; if no forces act on you (other than those that constrain you to move on the surface of the sphere), you will travel in a great circle (great circles are the geodesics of a sphere).
In case 2, you have unit speed at an angle to case 1. You will still travel along a great circle, but it is a different one. If the direction of the first great circle is "time" and the direction orthogonal to it is "space", the angle from the first great circle is related to your spatial speed (how much you move in space per unit time); different spatial speeds, different geodesics.
Tub wrote:
Warp wrote:
If I understand correctly, according to the theory gravity is not caused by a spooky force, but it's in fact a result of the geometry of space-time:
I think that's still open.
That answer is utterly wrong (and irrelevant for the question) given Warp's exact words; I highlighted the key terms in Warp's post which show this.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
First: I managed to pull off the glitch in the last booster; but it is slower than doing it on the previous booster since it requires going to the left enough so that the spindashes push the camera far enough to unload the booster.
As for spindashing while under the effects of the anti-gravity/slope glitch:
For starters, the anti-gravity/slope glitch works like this: Sonic (or Tails or Knuckles) keeps the 'standing on object' flag set because of a coding error on an object. Moreover, the same coding error will usually leave the "interact" byte (the last object Sonic stood on) intact during the glitch either. This causes all the effects we are used to.
The 'standing on object' flag is bit 3 of byte $FFB022 (for Sonic in S1 or S2); if putting a memory watch on this byte as a hex value, the flag is set in the following cases: $XF, $FE, $XD, $XC, $XB, $XA, $X9, $X8 (with X = any hex digit).
The "interact" byte is byte at $FFB03D (for Sonic in S2), and it is an index into the object table -- multiply it by $40, add $FFB000, and you have the RAM address of the object in question.
In order to start charging a spindash, Sonic needs to (a) not already be spindashing (duh) and (b) be in the ducking animation.
Now I list what conditions need to be true to be able to get into the ducking animation. I look only at the conditions relevant to the case at hand -- the 'standing on object' flag being set.
If bit 7 of the status byte* of the "interact" object is set, Sonic can duck; otherwise:
if Sonic is at the edge of the "interact" object**, he loses balance and can't duck;
otherwise, Sonic can duck.
* The status byte is the byte at offset $22 from the start of the object's RAM.
** Remember that the "interact" object byte is not cleared (and in the cases when it is cleared, Sonic's object data will be used instead). This means that any object that happens to be placed in the same location indicated by the "interact" object will be used to determine whether or not Sonic can duck.
When the object is deleted, its entire SST is set to zero; this is why Sonic displays the "off-balance" animation -- the object is now effectively at position (0,0) and has 0 width and 0 height, meaning Sonic is considered to be at its edge (the check to see if Sonic is past its edge is done from the object code, so Sonic's code doesn't second guess it).
So the summary: you want to manipulate the object placement so that Sonic thinks he is standing on this object; you will then be able to spindash.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The glitch is triggered by having the booster get unloaded while Sonic is still standing on it. Calling the booster's X position by "x_pos", this happens (x_pos & 0xFF80) - (Camera_X & 0xFF80) > 0x280 (in an unsigned comparison). The next-to-last booster can be made to cross this threshold with a spindash as you do it, but the last one can't; notice how Sonic isn't ejected from the booster when you trigger the glitch.
By the way: after the first spindash on the booster, you can immediately charge another (starting at, say, 58019) to use just as the booster vanishes. You can then immediately jump and keep higher than normal running speed down the tunnel.
I will try to figure out the conditions to be able to spindash later today and post back.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
feos wrote:
Where I can get the source code? Where is that option there?
Here is the source. The options you want are in the "hackdefs.h" file; uncomment this line:
//#define SONICCAMHACK // enables camhack (see Sonic offscreen) in sonic games, and hitbox/solidity display
There are two other uncommented lines that disable hitbox and solidity display, so by only uncommenting the line I told you you get the camhack without them. Also, S2 is selected by default (you need to compile a different version for each game). Then compile it; there are instructions somewhere.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
werster wrote:
Plus I'm wondering if there is a way to skip the ending cutscene, prolly not but I thought I may as well inform people who know what to do with it.
There isn't: the entire cutscene is controlled by the Tornado's code, even the transition to the Death Egg. In order to trigger the transition, you need the Tornado to be in an internal state that can only be reached by going through the cutscene.
