Posts for Tub


Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
scrimpeh wrote:
Also, here's a screenshot mothrayas suggested on IRC:
Now that's one Gergoth *puts on sunglasses* that got his ass kicked. Once again an awesome run where it's easy to vote. Thanks cpadolf!
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
I like chocolate. I also like bacon. So obviously chocolate covered bacon would be the best thing ever, right? This game has neither the strengths of castlevania, nor those of super mario. For a castlevania game, it lacks atmosphere, whips and maybe a few cheesy lines of dialogue. For a mario game, it's way too slow and lacks proper jumping physics. It brings little value on its own. Sprites and music are mostly "borrowed" from the other games, mixed up into an incoherent whole. The tricks we see aren't new, there are other runs with Bullet Bill action, and getting stuck in a moving platform isn't that interesting, either. What's new are the boss fights, but IMHO they're not interesting enough to tolerate the rest of the game. No due to game choice.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Easy Yes vote. re ingame vs. realtime:
BioSpark wrote:
I could have wasted the same amount of frames before each room without pausing, but I figured why waste in-game and real-time when I could just waste real-time?
Because the time might have been used to do something more interesting than hitting the pause button. Killing an extra enemy, picking a route that's slightly slower but contains this neat walljump etc. IIRC the guidelines advised to hide longer delays by spreading tiny delays in unnoticeable spots instead, but I can't find it in the guidelines right now.
BioSpark wrote:
Furthermore, there are many places in the run where jumping through the door saves time, because it scrolls the camera to the right place for the door transition. In the example gif below, 10 real-time frames are saved, but 22 in-game frames are lost. If people agreed that this should not be used in the run, then the run would be considered to contain speed/entertainment tradeoffs.
So why shouldn't it be used? What's wrong with it? It looks slightly off, but so does armpumping, backdash-canceling, backwalking and all the other tricks that don't make sense until you read the submission text. Or, for that matter, frequently pausing before a door.
m00
Post subject: Re: #3652: Saturn's SNES Super Metroid "Reverse Boss Order" in 46:42.38
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
TASVideoAgent wrote:
The story is about a bounty hunter called Samus who has the goal to explore a foreign planet called Zebes[..]
It's not foreign! She grew up there! Despite your lore weaknesses, I'll have to vote yes. I still don't like the choice of ingame-time and the consequences it brings, but since this obsoletes an ingame-run there's no point arguing about it.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Found the source code for the hilbert curves \o/ Many geeks know the Hilbert curve. Not so many know that it can be extended into 3d space and beyond. In 2D space, the hilbert curve is unique (when the start- and end-corner are given), while in 3 or more dimensions, it is not. For the following, I picked a 3d curve that was experimentally chosen to provide the best spacial locality. Exhibit 1: I've defined a total order over the RGB-cube by said 3D hilbert curve, then laid out the colors line by line in ascending order. TC_linear.png, 440 kB The main property of hilbert curve is easy to see: there are no more "jumps". Each pixel is at most 1 color value away from the pixel to its left (or to the last pixel in the preceeding line). While it is ordered, it doesn't look like a rainbow at all. Similar colors may appear at very different parts of the image. This is an unavoidable consequence of mapping a 3D space to a 1D space. (A rainbow will only display a 1D color space, fully saturated colors at equal brightness, just with different hue.) Unlike arflech's slice-mapping, this attempt provided perfect locality to the pixels to the left and right, but not necessarily to the pixels above or below. After all, I did map to a 1D-space, in which colors 4096 positions apart are totally unrelated. Which leads me to Exhibit 2: Instead of laying out the ordered colors line by line, I've arranged them along a 2-dimensional hilbert curve. TC_hilbert.png, 2.9 MB At first glance, you'll see 16 cubes, each having roughly a similar tone. Zooming in, you'll notice smaller and smaller cubes. The smaller the cube, the smoother its color will be, so much that the 16x16 cubes look single-colored to the naked eye, despite showing 256 unique colors each. /edit: replaced images with pngcrush'ed versions
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
I do like how PNGs image prediction was abused to reduce 48MB of raw image data to just 55kB. Though I do wonder if a different layout could be used to compress it even further? As for ordering, you could order the colors by a 3-dimensional hilbert curve, then add them to the plane by a 2-dimensional hilbert curve. It would certainly look more chaotic and compress worse, but it may be interesting to see anyway. Unfortunately, I can't seem to find my source code for the 3-dimensional hilbert curves :(
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Warp wrote:
My original question was about the expanding universe and overlapping observable universes.
I haven't been able to find the original question in the last few pages, but there's nothing wrong with expansion within relativity, and the quote you provided is a good explanation of light cones and causality. Now you're asking what happens if they move faster than c. The answer is: they don't. Not within relativity. If they do, you're using a different set of definitions and formulas, and everything you know about relativity is wrong; the diagram doesn't apply any more. So you're either looking for an explanation within relativity, in which there is no receding faster than c. Or you're looking for an explanation in which they recede faster than c, in which case you won't find the answer in relativity, but in the formulas outlined behind the link I gave you. Let's try within relativity. You could sit on the star in the middle and notice that A is receding with 0.9c and B is receding with 0.9c in the opposite direction. That doesn't mean they're receding with 1.8c from each other - if an observer on A could see B, it'd still measure a speed less than c. So since we can see A and B, we're obviously in the uAB-part of the diagram you linked, and A and B are in our past. Let's say that the "probe" is actually a radio signal and travels with c - it would reach us along the light. (If it's a probe below, but sufficiently close to c, it'll reach us a bit later.) We can retransmit the signal, and eventually it would reach a B' in the future. Unless B accelerates away from us. B will always be slower than the radio signal, yet the signal will never reach B. How is that possible? Let's do an example in simple newtonian physics. You have a person running away at 900 km/h and accelerating to a top speed of 1000 km/h, halving the distance to his top speed each hour. So he'd start at 900 km/h, reach 950 km/h after one hour, 975 after 2, 987.5 after 3 etc. We're firing a bullet at 1000 km/h. It's unstoppable, will never slow down, and is heat seeking. Screw the guy. During the first hour, the bullet is at most 100 km/h faster and can catch up at most 100km. During the second hour, the bullet is at most 50 km/h faster, and can catch up at most 50km. During the third hour, 25km. 12.5km. 6.25km, ... This is an infinite sum, but with a finite value. Adding these up, you'll find a limit of 200km. So if the guy had a 200 km head start, he'd live. Now replace "1000km" with "c" in your head, and you have an idea why the observable universe can shrink. It's not because objects move away from us faster than c (they don't), but it's because they're accelerating away from us. Now queue someone to bash me on the head and substitute the real formulas.
Warp wrote:
Can't someone just answer the questions and help me understand the answers?
Sure, provided there is a short and easy answer..
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Warp wrote:
Assume that we have two planets A and B, and that the universe is expanding at such a rate that A and B are always receding from each other slightly faster than c. Also assume that there's a star between them that both can observe.
You're now including cosmic expansion, a concept outside of special relativity, and you're trying to answer a question that cannot be answered strictly within relativity. The answer depends not only on the position and relative motion of the star in the middle and the exact speeds of A and B, but mostly on the actual expansion of the universe. Try starting here, for example: http://www.astro.ucla.edu/~wright/cosmology_faq.html#FTL
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Warp wrote:
It could also be that what we perceive as movement in time is actually our universe moving inside this metaverse. The "time axis" is in actuality the movement axis that our universe traverses along in the metaverse.
Again, movement as we know it requires both space and time. If our universe is to "move" across the metaverse, then the metaverse needs a time dimension. So how would you then explain the time dimension in the metaverse? Moving through a meta-metaverse? How many turtles down, exactly?
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
I cannot really tell you why the time dimension seems to work differently than the room dimensions. I could point out some formulas where time is treated differently, but that wouldn't really answer the question. However, I can add a few comments: * Movement speed is distance over time. If you're trying to talk about the speed of moving through time, you get time over time, which is always 1. Not a useful thing to talk about, unfortunately. * You cannot even measure how "fast" you're moving through time. Let's say you create a sci-fi-bubble in your living room in which time passes twice as fast as outside the bubble. While inside, you wouldn't notice anything different, because both your perception and any clocks you may carry will proceed twice as fast, too. The only way to know that something is different about the bubble is to compare a clock inside the bubble with a clock outside. And even then you wouldn't know if the bubble sped up time inside, or slowed down time outside of it. * You have heard about synchronized clocks ending up with different times in several relativity examples. Would that satisfy your notion of "moving faster through time"? About traveling backwards through time: most laws of nature don't differentiate between time directions. If we reversed time right now, without changing physics, the universe would remain almost the same. The reason we perceive a "past" and a "future" is purely a statistical thing, second law of thermodynamics. It suggests that there have been some initial conditions at some point in time, and the universe as we know has been derived from those. It makes sense to call these initial conditions "past" and everything that's derived from our current state as "future", but I think that's mostly a perception thing. Past and future are not a property of the time dimension. Time is mostly symmetrical (not entirely, but mostly). Past is simply the direction in time when the initial conditions were created.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
adelikat wrote:
If you are talking about the currently published 20 minute movie, this will have to obsolete it. It is the same glitch done better. More importantly the currently published movie has been proven invalid! It relied on the fact that saving takes 2 frames, and so reset can happen after one frame and corrupt memory. But it only takes 2 frames because snes9x is inaccurate in its emulation, it should only take 1, thus sub-frame reset would be required to corrupt ram.
On that note, can we please delay publication of this movie until we're reasonably certain that lsnes gets it right? Maybe this research has already been done; in that case I'd appreciate a link in the submission text.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Twelvepack wrote:
Most importantly, the gameplay itself is far less monotonous, given that you have 6 skills you actually use instead of 1 or two.
You could map more skills to F1-F8, and once you found your way into the settings and "fixed" the default keyboard mapping, you could easily switch skills without twisting your fingers. I've played builds with a dozen mapped and used skills. Necromancers for example really benefit from having just the right curse for every situation on a hotkey. Other characters used less, but I usually ended up with 5-12 skills on hotkeys. I actually wanted a 13th skill for my necro, but there were only 12 hotkeys.. My setup was usually two major attacks on the mouse wheel (up/down), TPs on MB3, a "panic skill" (slow missiles, mind blast, Leap attack, teleport, ...) on MB4 and my inventory on MB5. Support-skills, situational skills or pre-battle-buffs on my keyboard, on QWERT..SDFG. Minor changes in that setup as the build required. Compared to that, I found D3 to feel extremely limited. I only played the demo, but my sorc wizard had both an AoE-spell for creeps and a single-target debuff. And I had no way to switch between them during combat. That totally sucked, I'd either get swarmed by creeps, because I couldn't kill them fast enough, or I was obliterated by bosses because I couldn't keep them away from my glass cannon. The solution of course was to retreat through half the map and plink at 'em until they died of boredom. Surely a modern gameplay element fitting for a game from 2012, right? Because "skill switching" is such a complicated thing that the player has to be forbidden from ever using it. What's the point of having situational skills if you can only pick one of them, instead of the right one in each situation? So you were one of those that only used 1-2 skills per character, and you like the new system. Apparently Blizzard succeeded in what they wanted to do: make it easier to play for the casual gamer. But for me, it just felt like a giant step backwards. Granted, I only played the demo, and you cannot judge a diablo-game from the first few levels. Yet, I'm not going to buy it on blind faith.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
I've spent way too much time in D2, several of its mods, and its community, probably reached 5k character levels in total, wrote several guides, calculators, researched game formulas, and generally just wasted a huge chunk of my life on it. Now D3 is released and I just can't bring myself to care about it. Not only did they NOT combat those that destroyed bnet in d2, they're actively supporting them to get a slice of their money. And they've removed the alternatives of playing offline, in LANs or playing different mods. So they basically reduced the game to the one part I couldn't stand. Though I have a strange desire to play d2 once more... Oh btw, who else is looking forward to Torchlight 2?
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
The 500 error happens when there's too much server load. The admins are aware of it, but haven't found a solution yet. Just wait a few minutes and try again.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
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? With all the work and policy changes towards making TASing more open to new players and to TASes from other communities, such draconic restrictions won't do us any good. And don't forget that "newer" doesn't alway mean "more accurate". I'd have to look up the details, but I remember a couple of emulator updates that did quite the opposite to certain games. Having a strict deadline of, say, no emulator older than 1 year would also prevent anyone from submitting a TAS that has been worked on for longer than a year. That does actually happen, when the TASer doesn't have much spare time, or needs to drop TASing for a while due to RL stuff, or is generally working on ten projects at a time and rarely gets any finished. Any policy that'd prevent these TASes from being submitted is bad. "2 revisions behind" is actually worse, since you newer know how many revisions are going to be published and when. Now you might say that we count the time when the TAS was started. But that's impossible to verify, making any strict bans unenforcable as long as the submitter is smart enough to lie about it.
jlun2 wrote:
What if someone posted a very entertaining "glitched" playaround that abuses errors that a console couldn't do due to emulation flaws?
Then it shouldn't be published. Gamebreaking glitches are always subject to more scrutiny than usual runs. But verifying the glitch is more work than looking at the emulator's release date. Ideally, it's checked against the console itself. Lacking that, against multiple emulators of the same system. There's no guarantee that the most recent emulator gets it right, nor that the older emulator gets it wrong.
CoolKirby wrote:
However, VBA 19, 21, and 22 movies should all sync perfectly on the latest VBA 23, so I don't see any reason for runs on these older versions to still be accepted.
If 23 isn't more accurate than 19, 21 or 22, what's the point in banning the older ones? Please, let's stick with the recommendation instead of "banning" things.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Are you suggesting any concrete emulators or is this just an unspecific rant? In the case of SMW or SM, it's not just a question of saving frames, but also a question of comparing to existing runs. If you're working on an improvement, and you're losing a frame - was it you, or was it the emulator? How will you find out? Same for the final submission. If you're switching emulators, you'll need to explain how many frames were gained or lost due to the change. This is additional work, it complicates things, and thus switching to a different version when improving runs isn't as easy as just using the same emu. This is especially true for games with highly optimized runs, where changes due to emulator differences will dwarf any actual improvements. That should never be an excuse to start a run for a new game on an inaccurate emu, but I can understand if it's done when improving existing runs. You should also consider that newer emulators are often less mature, less stable (as in, the run may not sync on future versions), may have unknown bugs (as in, eats your TAS and laughs at you), and sometimes lack useful secondary features (like lua-support, memory watch etc). Or sometimes TASers are simply more comfortable with the emulator they've always been using. Since the goal of this site is to produce entertaining runs, perfect console compatibility is a nice feature to have, but by no means required. And to address the issue you raised in the edit of the initial post: the goal of this site isn't to expedite emulator developement, either. I agree with Warp on this:
It goes without saying that a more accurate emulator should always be preferred over a less accurate one
With the emphasis on "should" instead of "must".
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
nanogyth wrote:
http://www.w3.org/TR/html5/the-video-element.html#concept-video-intrinsic-height I haven't wrapped my head around that concept, but I'd be shocked if html5 only worked with square pixels.
That's a roundabout way of saying that custom aspect ratios are specified in the video, not in the html. There doesn't appear to be a way of overriding it in the video element. Using css transform:scaleX(..) might work, but it isn't standardized yet. It's supported by all major browsers (with their respective prefixes), but I haven't checked if they support applying it to <video> tags. /edit: I checked Firefox, and scaling via css transform works, e.g.
<video src="bla.webm" autoplay="autoplay" controls="controls"
style="border: 1px solid black; -moz-transform: scaleX(2); -moz-transform-origin: top left;"></video>
/edit2: so does opera, if you replace -moz- with -o- So it seems that it would be fixable on youtube's end. If they actually cared. So the actual problem is that youtube destroys aspect ratio information when re-encoding into their different formats?
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Out of curiousity: * Why do you get the bottle instead of a real ocarina? Wouldn't the real ocarina work after entering the blue warp, or is cucko collecting actually faster than the cutscene? * Why the deathwarp after gohma? Is that required to make the door usable again? Haven't found a way to trigger the door while closed?
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Optimizing the swordfighting sequences to gain just the right amount of questions/answers is going to be difficult. Or optimizing the random maze-sections for a shorter path. Or rowing. Good luck!
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Dada wrote:
Isn't html5 mode something you have to set in your Youtube account settings? At least this means most viewers won't have this problem.
That was true a year ago. Today youtube uses autodetection. If flash is available, it is used. If flash isn't available, but html5 is, html5 is used. Lacking either, an error message is thrown. The setting at http://www.youtube.com/html5 merely tells youtube to try html5 first, using flash as a fallback. I don't have flash, so I'm getting the html5 version. So do many mobile devices, or people with non-windows OSes where flash isn't pre-installed. Without touching any hidden setting.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
turska wrote:
before the html5 player is rolled out.
It's been in trial for almost two years, with no actual progress, roadmap or estimated release date. In fact, they broke it for a lot of videos in february, and haven't managed to fix it since. I really wouldn't bet on an official release this decade, much less speedy bug fixes. That said, lacking alternatives to html5 that aren't malware disguised as a browser plugin, I've been using html5 mode for quite a while. So if you can support it, please do, even if google doesn't.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
Warp wrote:
But if it's stationary with respect to the surface of the Earth, that means that it's actually orbiting the Earth (at a speed of one revolution per day). In other words, it's moving along with the Earth. This lateral movement does not stop when the object is let go. Thus it will stay over that same point as it falls down.
Yes, one revolution per day. But one revolution per day on the surface is ~40.000km/day, while one revolution high up in the atmosphere is quite a bit faster. When the object drops down, the horizontal velocity will be slowed by the atmosphere (assuming no wind etc), but it'll remain greater than the horizontal velocity on the ground, thus traveling further than the guy on the surface. This is of course simplified. Just talking about the horizontal velocity when the object is let go is slighly misleading: when the earth continues to turn, the vector that was once horizontal isn't parallel to the surface near the observer any more, and the downwards momentum isn't perfectly downwards any more, so you'll need to constantly translate those vectors. (Or do the right thing and model it as angular momentum) But this effect is only minor on reasonable altitudes and the short durations of the respective drops. "Dropping" a geostationary object from higher than ~36.000km will result in the object flying away, and I'm not sure where it'll land if you drop it from slightly below that.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
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. IIRC the current consensus is that experiments contradict neither interpretation. It may be caused by gravitons, or it may be caused by an actual bending of space. At the scales at which gravity is measurable with current equipment, both interpretations yield the same results.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
He's also playing with his balls.
m00
Tub
Experienced Forum User
Joined: 6/25/2005
Posts: 1377
My avatar should be NC17, because he is having naughty thoughts about the neighbours' cat.
m00