Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
All three of those are standard courses (or part of them) at the university here. (Of course I can't speak for all universities in the world.)
They are standard here in Brazil too; it would take a really piss-poor CS course to not have them (in Brazil, this means a course poor enough that it would not even get certified by the government -- i.e., the diploma you would get from such a course would be worthless).
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
@WST: You have to delete the signpost sparkles or force the creation of new ones. To delete sparkles, you want the game to be paused whenever the byte at $FFFFFE0F ends in a 0, 4, 8 or C (hexadecimal); to create new ones, you want the game to be unpaused in those frames.
@TheYogWog: I think the newgame+ RA with S+T (without hyper) would be most interesting as it would be most different from the K RA. But even better is that you can use the savestate used in the published newgame+ run: this saves you the trouble of making the verification movie and generating the savestate in a consistent way.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
True wrote:
Not even. Default values at power-up are not guaranteed but will likely favor a "blank" value (usually 0x00 in SRAMs) - so this is likely unattainable in practice. Also this is probably a debug code that could be poked by the debugger that was left in.
Not quite: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.164.6432
Note that SRAM is random, but not entirely random -- some bits favor zero some favor one, some are neutral and therefore random. Given a specific chip, a given initial power on state might not be realizable, even if it is on another, because of the skewed bits.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
More specifically, the boss appears because MGZ1 and MGZ2 share the same code for dynamic level events. You normally can't get to the location where the boss will load in act 1 (you have to go past the boss arena, which locks the camera too far left), so the original developers didn't realize their mistake; but if you can get to the loopback area (say, by going under the boss arena to prevent the camera from locking), you can get there. And once there, the boss will spawn and lock the camera, which pushes you inside the wall.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The fact that you are seeing all 3 of them mean you should update your emulator. You want to leave PSG high quality OFF, the others on. They make no difference in synch, but PSG hih quality sounds nothing like real hardware.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Yeah... I could go on, but decided to give up. Voting "no", the mistakes are too obvious and grating (to me, at least).
Edit: Hm. Watching the "& Knuckles" part, it feels like a different person TASed it.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
WST wrote:
Waduh… A year ago I would exclaim “this is suboptimal!” or something… But now I’m a bit more indifferent and perfectionist than before…
I'll do it for you: it is suboptimal. One has to look no further than AIZ1, and compare it to this public WIP by WST to see how nearly 4 seconds are lost.
Edit: Wasn't AIZ2 also faster by glitch gliding through spikes instead of panning the camera down? I am almost 100% certain it was, but my memory may be playing tricks on me.
Edit 2: This is painful; in MGZ1, there is no excuse not to enter the diagonal spring, then drop down levels inside the wall. Instead, he goes around the long way, losing seconds.
Edit 3: And he didn't even drop down levels to zip under the boss, but instead ducked down to pan the camera. ARGH.
Edit 4: Also missed the CNZ1 level wrap...
Edit 5: Nowhere near optimal but still beats his IceCap level... (mind you, that was a quick and dirty attempt I made way back then -- I didn't optimize it at all).
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Technically, the "Proper Aspect Ratio in low-res mode" is there for a reason — old CRT TVs would stretch the image to fill the width. Without the stretching, the image looks distorted, as games were designed with this stretching in mind. I imagine that disabling the option is good for preserving the pixels of the original data, however.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
In the normal resolution mode (H40), the original console "only" allowed 80 sprite pieces to be displayed on-screen, 20 sprite pieces per scanline and 320 pixels in sprites per scanline. With the sprite limit turned on, Gens emulates the first two limits, if not, it does not; Gens never emulates the limit of pixels per scanline. In any event, The correct setting for the option is "on".
The Genesis also had a lower resolution mode, the H32 mode (256 pixels of horizontal resolution), whose the limits were smaller (50 sprite pieces on-screen, 16 per scanline and 256 pixels per scanline).
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
p4wn3r wrote:
Doesn't look much harder. You just have to put phi-w*t instead of phi here:
That is indeed a popular way of doind it; it also happens to be wrong: it does not result in Superman's frame, far from it. You can Google for "Trocheris-Takeno transformation" and "modified Trocheris-Takeno transformation" for two alternative ways of moving to a rotating frame, as well as for references and critiques of the transformation you give. Trust me, correctly handling rotating reference frames is still an open research question, it is not simple.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Superman's reference frame will indeed be constantly changing; but this is irrelevant since I performed the calculation in an inertial frame. SincenI computed the rate of change of Superman's clock compared to that of an inertial frame (Superman's proper time versus Earth's proper time) the result is an invariant – it does not depend on which reference frame is used to compute this value. Had I tried to work on Superman's reference frame, I would have to deal with countless issues – for example, Superman's frame will undergo Thomas precession, and he will experience a breakdown in simultaneity (see Bobo's post) – which would make the problem much harder.
But the ultimate conclusion would be the same – his observed "time dilation" and "space contraction" will not be different than if he were moving with constant velocity.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Actually, the Silver Age Superman (upon which the 1978 film was based) could fly forwards and backwards in time at will; flying around the Earth and reversing time was the way the filmmakers decided to use to explain what was going on (and given how many people misunderstood the scene, they clearly failed in this regard...). So the only ridiculous part is the fact that he had this power in the comics to begin with, not the fact that he used it in the film.
Anyway: assuming that, on the Earth's reference frame, Superman is moving in circular orbits of constant speed around the equator (supplying whatever acceleration to keep moving in this orbit by his own power), and ignoring the effect of gravity for the sake of simplicity, we can compute how much proper time elapses for Superman. Using spherical coordinates, his motion as seen from Earth's reference frame is given by
r(t) = constant
theta(t) = pi/2
phi(t) = v * t / r
Plugging that into the line element for spherical coordinates in space-time, we have that
[c * d(tau)/dt]^2 = c^2 - (dr/dt)^2 - [r * d(tetha)/dt]^2 - [r * sin(theta) * d(phi)/dt]^2 = c^2 - v^2
where tau is Superman's proper time. Rearranging, we get the normal "gamma" factor:
d(tau)/dt = sqrt[1 - (v/c)^2]
So without gravity, he would just get his normal time dilation for speed. Which is expected: acceleration does not directly affect proper time in SR, it only indirectly affects it because it affects velocity; but in circular motion with constant speed, the velocity only changes direction.
The next question would be: if you factor in gravity, how are things changed? Ignoring Earth's rotation (I can deal with it later), the line element would end up being
[c * d(tau)/dt]^2 = (1 - rs / r) * c^2 - [r * d(phi)/dt]^2 = (1 - rs / r) * c^2 - v^2
or
d(tau)/dt = sqrt[1 - (v/c)^2 - rs / r]
where rs = 2 * G * M / c^2 is the Schwarzschild radius of the Earth; that is, rs = 0.00887 m. You still have to divide it by the radius of Superman's orbit, which will be greater than 6400 km -- meaning the effect of gravity will be tiny given the high speed you game for Superman. The terms involving Earth's angular momentum would be about an order of magnitude or more smaller than the term with the Schwarzschild radius, so we don't need to pay much attention to them.
I can give however many details are desired for the derivation of the equations above; I just went more for the results in this post.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
TheYogWog wrote:
For 1, the glide glitch almost works but for some reason I get pushed directly back up onto the step instead of going through it. I don't know why I can glide glitch through the top step, but not the bottom one? As for the stairs glitch, it probably won't work because the ceiling of the corridor to the left of the stairs is so low that it messes up the timing of the jump.
Knuckles uses a different collision routine while gliding: this specific routine does not have the code path that allows falling through terrain ("stair clip"). Without this code path, the game recognizes that you are inside terrain and ejects you back up. Note also that the wall on the top step is thinner (as the step is thicker); ejection generally goes walls first, then up or down out of the wall (depending on the relative vertical to horizontal speed). This becomes especially relevant given that terrain ejection is limited to 16 pixels, and this wall is thinner than that.
TheYogWog wrote:
For 3, I know it's possible to glide glitch through very thin floors, however I'm not sure this floor is thin enough.
My theory regarding glide-glitching through floors is that it has the same cause as glide-glitching through objects -- it is a combination of factors that include perfect positioning (less so for objects), the additional 2 pixels/frame boost you gain when you are moving down and start gliding, plus the fact that when you stop gliding, Knuckles' collision box reverts from the smaller size used in gliding to his standing collision box without adjusting his Y position to compensate. The latter factor causes Knuckles "feet" to go down (19-10) = 9 pixels; if you were falling at a speed of at least 5 pixels/frame when you activate glide, you get boosted to 7 pixels/frame which then cause Knuckles to drop a full 16 pixels in the next frame as you stop gliding; with perfect positioning, you can get past "thin" floors which are that high. There is an additional constraint in that you need to activate glide 2 frames before you would hit the floor, and release it on the next, so these figures give a ballpark. With more speed, you may be able to fall through thicker floors; the issue is just getting enough speed -- I estimate you would need to be moving at least 13 pixels/frame to be able to glitch there (3328 subpixels/frame), and you need to fall for over 387 pixels to gather this speed; this would put you more-or-less at the spindash elevator above the steps, and there may not be enough space to get enough speed and position yourself properly.
TheYogWog wrote:
I was able to glitch through the floors shown below in Sandopolis 2 and I didn't think I could do that at first, either, so maybe the same will work here. I think it might help a lot if I knew what the numbers mean, usually on 2x tile floors they're labeled "FFFF FFFF". Is that hex for the value of how thick they are?
They are related to the slope of the tile; FF is equal to zero for the game.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
TheYogWog wrote:
Ok, thanks for explaining everything. So, does that mean the effect won't occur whenever the video is played back in unhacked versions of the emulator?
Correct; it also does not happen when you disable map hack with scroll lock. If you note, my HUD is also not affected by this.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Paused is correct, that was a typo I missed: it should be PM instead of OM.
Edit: ah, I see what is going on: this is not a real increase, but simply graphical corruption in the rings display due to the camera hack. There is no way to really keep this increase as it only exists temporarily because of the camera hack. This was the tl;dr version; here is the full explanation:
To understand what is going on, you need to understand a bit about how the camera hack works: it first saves a state invisibly; then, it moves the camera to a position off-screen but close to the screen; it then emulates frames invisibly, while forcing all of object RAM to remain the same, until the camera is centered on the player; then, the camera hack forces an update to draw this frame; it then invisibly loads the state it had saved. The position the camera is moved to is chosen so that any objects that would appear on-screen have a chance to load in time to show up.
Now, the key bits are "emulates frames invisibly" and "forcing all of object RAM to remain the same". The monitors have a delay between being broken and giving their bonus; and there comes a moment when the timer is about to expire in which you are off-screen. In this state, every frame emulated by the camera hack will see the timer expire, give the rings and update the display, then reset the object RAM to what it was on the start of the frame, so that the next frame will do this again. The faster you are moving, the further off-screen you will be when this happens; there is a limit to how much can be "gained" this way, but I won't bother tracking it down.
In the end, this increase goes away because of the invisibly-loaded save state, which puts the game back on the correct state. So the increase is not real, but an unintended temporary consequence of the way the camera hack works.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
TheYogWog wrote:
One thing I noticed that was unusual, my ring count went up by 70-80 rings, but it only lasted for a single frame before going back to normal. The amount seemed to be affected by my speed, if I slowed down I would get slightly less. I have no idea what caused this, just wondering if anybody knows more about it? It happened after I ejected out of a wall approaching the boss area, I'm pretty sure I was off screen at the time, and there were 10 "pending" rings from a monitor I destroyed but which hadn't been displayed to my total yet.
Can you OM me the GMV? I can use it to try to figure out what is causing this.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
KPM wrote:
marzojr wrote:
KPM: you got lucky in that thread. Several threads in that forum are actively... "policed"... by some hackers that add thousands and thousands of embeds to videos, causing browsers to use up all available RAM and swap space to the point where you need to forcibly reboot the computer*. Seriously, avoid the "ASM Programming" subforum there unless you want to reboot.
* Unless you are on a Unix-based OS and know how to switch to the terminal to kill the flash plug-in processes.
I don't think you got it. I posted that because i KNEW he bad. read the second post on the page.
I understood you perfectly well; you missed my point: I am saying that browsing in that forum is dangerous. Green Snake and others prowl there, and make posts with thousands of video embeds; just by opening the "wrong" thread you can suffer greatly.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
KPM: you got lucky in that thread. Several threads in that forum are actively... "policed"... by some hackers that add thousands and thousands of embeds to videos, causing browsers to use up all available RAM and swap space to the point where you need to forcibly reboot the computer*. Seriously, avoid the "ASM Programming" subforum there unless you want to reboot.
* Unless you are on a Unix-based OS and know how to switch to the terminal to kill the flash plug-in processes.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Marx wrote:
marzojr wrote:
Or that every second for this "reference" observer is equivalent to a year for this person?
Yes this one
Relativity says that when you move relative to someone else, time passes more slowly to you than to the "stationary" person. So this scenario is impossible to happen without an additional source of time dilation for the "moving" person. Meaning you deliberately picked the scenario that goes against the laws of physics and was surprised that the result was contrary to the laws of physics.
But in any case, Warp was (is) correct -- since a year passes for the "moving" guy for each second that passes for the "stationary" guy, the "moving" guy will die in a year for the "stationary" guy regardless of why time is passing faster for him than it should be.
grassini wrote:
Marx is not a native english speaker,give him a break.
I'm not either.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
"Sonic 1 Open Source Project"? Seeing that threw all kinds of alarm bells in my head. So I googled it, and unfortunately, my fears were proven correct -- this hack is by OuricoDoido, a well known (read: infamous) code thief that stole code from, among others, MegaMix, and then distributed it. While he may have learned something or other since, he is likely to always be shunned by other Sonic hackers.
Experienced Forum User, Published Author, Experienced player
(752)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
You know, I read your question and decided not to answer it for one reason: it was horribly worded, in such a way that "pie" would be just as reasonable an answer as any. You are doing it again.
Lets see:
What if person is able to spend 1 sec like 1 year for his own. (not for observers)
What exactly does this mean? Does it mean that the observer is moving such that every second from his point of view is equivalent to 1 year to another, "reference" observer? Or that every second for this "reference" observer is equivalent to a year for this person?
They are quite possible interpretations on your horribly mangled wording. Moreover, you don't specify what is the source of the difference between the time for one observer versus the other; is it different gravitational field? Is it one falling in a black hole while the other is looking? Is it them drifting apart from a common starting point, never to meet again? Is it them converging to a common ending point without having ever been on the same place before? Is it them meeting again at a common ending point after drifting apart for some time?
Because each of these is a completely different scenario and gives a different answer.
Edit:
On my first question , If a person can spend a 1 sec like a year and if he runs , the observer would saw him moving at the high speed, right?
So after a horribly mangled version, you post a less mangled one that is completely different from the original and think you are still talking about said original. This is different because you specify the source of the difference in time passage -- the relative speed.
The question still accepts "pie" as an answer, though. Do you mean that the person "running" is moving fast enough that time passes for him at the rate of 1 second for every year that passes for the "outside world"? Or do you mean that each second from the "outside world" is equivalent to one year to him?
In either case, the answer would still be "pie": do they start at a common location and eventually re-converge at the same location to compare? Because if not, both "yes" and "no" are valid answers for both questions, as the two scenarios are equivalent -- relativity of simultaneity means you can always find one observer that sees the person dying before the "rest of the world", and one observer that sees the "rest of the world" dying before that person.
Anyway: care to specify the question more?
