Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Aglar wrote:
First of all you MUST run faster than 13 pixels/frame at a 45 degree angle (the value 32 in the lua HUD), which means at least a speed of 3329.
4663 * sin(45) = 3297 so no it will not work from here, Sanic gotta go faster.
Yeah, then it seems like it can't be done in this case; it doesn't seem possible to run up the slope, align to the side of the monitor for the "monitor madness" and keep enough speed to run up the next slope.
Out of curiosity, what are the other requirements in terms of alignment?
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Aglar: out of curiosity, how do you do the run up a slope trick? I ask because I managed to do what WST is calling "monitor madness" on that last monitor, but I haven't had much success running up the last slope. And I am too lazy to test all possibilities of input on the remaining stretch of terrain to do the trick...
Edit: More specifically, can it be done starting from 8961:230 with 4663 sp/f speed?
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
keylie wrote:
Well, according to this site, based on their own log, still 44% browse the internet with a resolution strictly less than 1024 pixels wide.
That site does not say what you think it says:
As of today, about 97% of our visitors have a screen resolution of 1024x768 pixels or higher:
In the table that follows, it lists 800x600 with 0.3% and "lower" with 2% as the only options with width strictly less than 1024 for Jan 2015; the last time strictly less than 1024 was 44% or more was in Jan 2003 — at least according to this data.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Dynamic wrote:
Apologies if this has been asked and answered before, but is there some way to check (e.g. memory location) to see whether a certain action causes you to zip or not?
If 0x13036 gets executed, you have triggered zipping behavior. Here is a small script that tells if you are zipping or not:
You can test it by running into a wall. This address is for rev01; for rev00, it is 0x13036 instead. You may want to restrict the actual definition of "zipping" by looking at the final value of speed after a zip, as was done in the "no zips" run.[/code]
Edit: Added quote due to page break.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
TASed the undisputed winner of 2015's Sonic Hacking Contest:
Link to video
Gust Planet 1: 0:21::11
Gust Planet 2: 0:28::34
Gust Planet 3: 2:33::41
Total: 3:23::26
Acts 2 and 3 can probably be improved a lot.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
dwangoAC wrote:
Ilari made an image writer that was quite interesting but it took quite some time to write a single image to the screen even at the maximum rate we could sustain through the controller cables so I don't think that's a good choice.
Out of curiosity, did he try some form of compression? Streaming a LZ77 or LZSS decompressor* first, then having the SNES decompress this data as it is being streamed might allow a lot more effective bandwidth.
*LZ77 and LZSS decompressors are relatively small and evry fast, for a good compression ratio, which is why I mentioned these.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
ars4326 wrote:
If we're speaking of sturdier and proportionally sized giants (and not anomalies like Wadlow), then I'd imagine that they'd possess formidable explosiveness and athleticism. Take your 6'4+, 285lb+ linebackers in football. They're big guys, but they can generate major power and speed on the gridiron in a relatively short period of time. Now take a giant-sized equivalent at, say, 12'6", 575 lbs.
A 12'6" 575 lbs giant would be more akin to a chronically malnourished human on his death bed than a linebacker — a 6'4" human with the same proportions would weigh just under 75 lbs[1].
If we were to assume (for just a brief moment) that a giant is just a proportionally bigger human in every way, the 12'6" giant equivalent of the 6'4" 285 lbs linebacker would weigh about 2191 lbs[2]. His athletics capabilities would be nowhere near those of the human linebacker because of cube-square law: muscle and bone strength is proportional to the cross-section of the muscle fibers and bones; since I am assuming he is proportional to the human linebacker in every way, the cross section of his muscle fibers and bones are about 3.9 times the human linebacker's[3]. Overall, this strength-to-weight ratio of the giant's bones and muscles is slightly more than half that of the human linebacker[4]. Moreover metabolic rate per unit mass decreases with size in real creatures; with an exponent of -0.75, in fact. This giant would have about 60% of the metabolic rate per unit mass[5] that the linebacker has. He just has less maximum power per unit mass available for his athletics endeavors than the linebacker does.
In all likelihood, his bones and muscle would be unable to sustain his weight in vigorous physical activity and would crack and snap under the pressure; a giant would have to more slowly and carefully to avoid this fate (as large land animals do, in fact). Any fall would be crippling and likely fatal.
Using more realistic scaling laws based on animals, muscle mass grows with the cube of scale factor (same as weight) and skeletal mass would grow with the 3.25th power; so a larger fraction of the giant's weight would be bone compared to the human (this gives about 30 lbs more bone, while keeping the same total weight — organs tend to scale slower than total body mass anyway). This would slightly increase the relative bone cross section, meaning the giant's bones would be slightly more resilient relative to mass than what I said above. For reference, an exponent of 4 would be needed to keep strength-to-mass constant, so both muscle and bones grow with size (in real creatures) slower than needed to keep the same strength-to-weight ratio. So while the details differ when using more accurate scaling laws, the overall conclusion remains.
[1] human weight = (giant weight) / ((giant height)/(human height))^3.
[2] giant weight = (human weight) * ((giant height)/(human height))^3
[3] (giant cross section) / (human cross section) = ((giant height)/(human height))^2.
[4] The giant's strength-to-weight ratio relative to the human's is equal to (human height)/(giant height) when you put it all together.
[5] ((giant height)/(human height))^(-.75)
ars4326 wrote:
This is also assuming that they'd still be just as intelligent. So even if they were too slow to close in on prey in close-quarters, I'd bet they could nonetheless adapt by making a mean long-ranged weapon with some vicious force behind it (slings, spears, bows, etc.).
Because weapons also follow the cube-square law, giants would end up having to use tiny weapons: a proportional weapon (or any tool, for that matter) would be about 7.7 times heavier than a human equivalent, and relatively brittle in comparison. Many of them would be unwieldly as well because of longer lever arms and weight: a proportional spear might be usable for throwing (the giant might be able to throw this proportional speed about 40% farther than a human would throw his spear[6]), but fighting with it would a lot more work, and much more tiring. However, a proportional sling or bow would likely fall apart due to the strain during use. And the giant might not even be able to use them effectively anyway: the giant would likely not have the strength to draw a proportional bow in full (and it would likely snap in half if he could) unless he were using a relatively small bow, and the sling would combine a factor of ~2 for lever arm with a factor of ~7.7 for stone weight, for about 15.4 times the strain in the giant's bones and muscles to throw a proportional stone with a proportional speed in a proportional sling.
[6] This is complicated to compute exactly, but can be approximated in general by sqrt((giant height)/(human height))
Bottom line: real world giants would be nothing like the giants from fantasy and mythology. They would be slow (because of slower metabolism, as well as to avoid falling with its dire consequences) and cautious (because falling is dangerous), they would use undersized tools and weapons (both for effectiveness, as well as to avoid getting tired from lugging a proportionally higher load compared to their strength) and be extra careful with them (because they are relatively brittle).
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
New version of Bunnie TAS using new version of the hack:
Link to video
Times:
GHZ1: 0:13::17
GHZ2: 0:09::55
GHZ3: 0:24::45
MZ1: 0:09::19
MZ2: 0:10::26
MZ3: 0:22::25
SYZ1: 0:17::51
SYZ2: 0:18::58
SYZ3: 0:40::56
LZ1: 0:07::55
LZ2: 0:05::28
LZ3: 0:15::39
SLZ1: 0:09::29
SLZ2: 0:08::48
SLZ3: 0:21::49
SBZ1: 0:14::35
SBZ2: 0:09::30
SBZ3: 0:02::47
FZ: 1:10::19
Total: 5:34::11
Basically, changes in boss fights.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Link to video
Improved the Bunnie TAS by 0:11::33.
A full game TAS. Not very well optimized, there is probably a lot of frames to save in a lot of levels.
Times:
GHZ1: 0:13::57
GHZ2: 0:09::55
GHZ3: 0:25::52
MZ1: 0:09::52
MZ2: 0:10::26
MZ3: 0:26::51
SYZ1: 0:18::38
SYZ2: 0:19::31
SYZ3: 0:41::50
LZ1: 0:07::57
LZ2: 0:05::31
LZ3: 0:15::39
SLZ1: 0:09::29
SLZ2: 0:08::48
SLZ3: 0:26::16
SBZ1: 0:17::40
SBZ2: 0:09::30
SBZ3: 0:02::47
FZ: 1:10::19
Total: 5:50::48
Tails and Knuckles are now left eating dust in almost all levels.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
So, I have a question.
I recently found out in Sonic Retro that there is a bug in Sonic 1 that allows you to enable debug mode on the ending by holding A at the end of Final Zone — without having to input the debug code first. This allows the possibility of optimizing the ending.
Would this count as using a cheat code? And would people actually care about an optimized ending?
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
So, I went for the full game TAS. Not very well optimized, but already faster than Tails and Knuckles.
Link to video
Times:
GHZ1: 0:13::57
GHZ2: 0:11::49
GHZ3: 0:26::30
MZ1: 0:10::46
MZ2: 0:11::07
MZ3: 0:26::51
SYZ1: 0:18::38
SYZ2: 0:19::46
SYZ3: 0:47::30
LZ1: 0:07::57
LZ2: 0:05::31
LZ3: 0:15::56
SLZ1: 0:09::29
SLZ2: 0:09::46
SLZ3: 0:26::16
SBZ1: 0:17::56
SBZ2: 0:09::30
SBZ3: 0:02::47
FZ: 1:10::19
Total: 6:02::21
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Reading a bit of Exodus's source (specifically, this), I now have some more information regarding H32 and H40 in the Genesis.
Specifically, the active display portion takes exactly the same time in both of the modes. This corresponds to the 256 (H32) or 320 (H40) pixels rendered in emulators being drawn.
This means that, at least on a Genesis, you can get a perfect aspect ratio for H32 mode by simply stretching horizontally from 256 to 320 pixels.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
AdituV wrote:
I was unaware of this; could you expand on how mass-energy equivalence is a relativistic effect please?
As I said in IRC, here are some links:
First, the Wikipedia article; it is very comprehensive, with some history of the principle.
Then this article from one of the physicists involved in finding the Higgs boson, which is more in-depth in some aspects, and is more conceptual.
I can't seem to find a good derivation of the equation that is (1) simple enough to be easily understandable without a heavy math background; and (2) correct enough to satisfy me. So here is a flawed one that skips a lot of important steps (particularly between the first 3 equations), but has the general correct idea.
If you have any questions about those, fire away.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
While the explanation is correct, I just want to point out that nothing here is unique to the nuclear force, or quantum physics: any bound system has a total lower energy than an unbound system, and the more tightly bound the system is, the lower the total energy will be. And since total energy is related to mass by relativity, the mass deficit in the helium atom is actually a relativistic effect.
A helium nucleus has less mass than the sum of its nucleons' masses because they are bound together. But so does the Solar system have a lower total mass than the sums of its component masses, as they are gravitationally bound together.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
feos wrote:
write a wrong answer very CLEARLY and visibly, and the right one invisibly. this gives you the obviously impossible result of the game accepting an answer that's obviously wrong as correct.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
dwangoAC wrote:
I personally feel we have an echo chamber here and that the only people who care about whether we use these two combined glitches at the same time is us. My point remains that we have destroyed the game so thoroughly that we can do whatever we want - why would we *ever* want to hide this? Why would we want to artificially handcuff ourselves as if we were sorry for what we had done to the game?
I was going to weigh in with a similar remark: I quite agree that both glitches should be used, abused and combined to make the run.
In my opinion, whether the OOB glitch i used or not, the net result is the same: a TAS that abuses the OCR system by making it ignore almost everything being drawn on-screen. That it was actually recognizing something drawn offscreen, instead of mistaking part of the drawing for the answer, is pretty minor, given that you only need only a few pixels to give any answer anyway.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
dwangoAC wrote:
That text is definitely a bit too deep but yes, I think I could do a better job of explaining the general concept. Where did your quote come from, by the way? Just curious.
My own head, actually, the quote block was just to make it stand out from the rest of the message. I have been researching entropy collection, PRNGs and related stuff for some time now, ever since I decided to add more randomness to one of my Sonic hacks; this is basically a distilled summary of everything I have read.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Pokota wrote:
Another thing that we could help clarify is the difference between actual randomness and deterministic RNG - I saw a lot of people on twitch chat complain that it's not random if the same result can be forced during the 100% Chrono Trigger run. If we can include an explanation of that (probably best if we can console verify one of the more controversial Monopoly movies for this purpose) then it might make things easier on other runners as well.
Lets see, how about this:
The first thing you[the audience] have to understand is that we don't know if there is such a thing as randomness outside of Philosophy or information theory; nor is it very relevant in practice. In the real world, what is used is unpredictability: if something is too hard to predict, we can use it for pseudo-randomness. High quality unpredictable data is supposed to be indistinguishable from "true" random data without computational capabilities we don't have, and may never achieve.
There is one problem: high quality unpredictability is slow; typically, a few bits per second if you are using a typical commercial "hardware number generator". So you need a method to extrapolate from small quantities of high quality unpredictable data to large volumes of reasonable quality unpredictable data.
This is done with pseudo-random number generators (PRNG). A PRNG is a small program that generates a crazy sequence of numbers by a deterministic method. Its only claim to unpredictability is that it keeps its internal state secret; without knowing it, you generally can't know what the next output will be given the current output. The initial state of a PRNG is called a seed; modern computers and operating systems use high quality unpreditcable data to seed a PRNG, and periodically reseed it with more unpredictable data.
Video games — especially older ones — generally have very few good sources of unpredictable data; the chief among those is the player. Moreover, older console games generally didn't reseed the PRNG — they either chose a seed based on when the player started the game, or had a fixed seed. Thus, the only real source of unpredictability used was the player. By removing all unpredictability from the player, you remove all unpredictability from these games.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Ignoring fail's "reply", which has nothing to do with the question: if you want to preserve input from later levels, one way is to use TAS Movie Editor to copy the input from one movie file and paste it into another. You would make a copy of your movie, note the frame range you want to copy, redo the error in one of the files, and copy the frame range from the other movie.
Be warned that there is a high chance of desyncs due to lag differences; a good way to reduce them is to copy in-level input. For example, you copy the input starting from the first frame in which the game timer runs in a zone, and paste it so that it becomes the first frame, adding blank frames until you are pasting in such a place.
Even then, many levels don't help at all — any changes before DDZ, DEZ1, DEZ2, SSZ or LRZ1 will almost always cause these levels to desync at the boss. Likewise, changes before SOZ2 may cause a desync if you rely on the ghosts behaving in a certain way. Changes before MHZ1 can cause a desync at the boss as well because the flame on/off pattern is different. Changes before either CNZ1 or CNZ2 are almost certain to desync everywhere because of the balloons ending up in different positions. Changes before MGZ2 can cause Knuckles' boss to desync due to a different pattern, and changes before MGZ1 can cause lag differences if beating Sonic's MHZ2 boss in act 1, leading to a desync. All of these can be worked around, but it takes time and effort.
Experienced Forum User, Published Author, Experienced player
(751)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
So, there is a new S1 trick found by Tee-N-Tee:
Link to video
Based on that, I made a TAS version, which completes the level in 0:08::09; the published TAS is 0:09::42, meaning a 93-frame improvement. It might be possible to gain a frame or 2 in the jump from the switch by changing the braking pattern, but that is about it.
Edit: here is a new version in a maddening 0:08::02. I can't see a way to gain the final 3 frames to go sub-7... Tee-N-Tee? Aglar?
