Mancubus
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Doom Speed Demos > The Two Types of Glides
Pages (5): « 1 2 [3] 4 5 »  
Author
All times are GMT. The time now is 19:18. Post New Thread    Post A Reply
Creaphis
I will deliberately take a contrary position just for the sake of writing incredibly long arguments


Posts: 4167
Registered: 10-05



Grazza said:
kimo: cack_handed's hangar13 run didn't feature moving into the void. It's actually very similar to the e1m3 glide, where there is also a right angle at the point of intersection. So actually this idea is about a decade old. :) The main idea from that demo and its analysis is that it is an obstruction to your movement away from the two-sided linedef that is necessary for this type of glide. That obstruction can come from a sloping wall (as in most of the demos where this trick is used), but it doesn't have to. I guess it could come from a coop partner, in which case pl15 looks ripe for this.


In both cack_handed's hanger13 glide and in the e1m3 glide (if we're thinking of the same glide), the player's hitbox contacts a horizontal impassible line and another linedef that isn't quite perpendicular to the first. 4mer's earlier explanation of the hanger13 glide makes it seem that these conditions are necessary; the second linedef must have a slight diagonal so that Doom will use functions that only approximate (and frequently overestimate) the distance that the player can slide along this line, but it must still be nearly perpendicular to the first linedef so that this slide will project the player all the way across the line.

What I'm getting at, I guess, is that a coop partner wouldn't help you with this type of glide unless he could rotate his bounding box by a few degrees. Oh well.

Old Post 09-15-10 15:58 #
Creaphis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
myk
volveré y seré millones


Posts: 15137
Registered: 04-02



Ryback said:
It's not entirely separate, as what happens in the void can affect the rest of the level. eg PEs spawning lost souls in the void, whose movement can be heard and will have an effect on the RNG. Or Archvile attacks where most of the blast is absorbed by the void, leaving the player almost untouched. Ghost monsters can go wandering in the void, and I think there are levels where they have to cross voidspace before showing up to be killed by the player. So I would lean toward considering the void just another part of the level.
To clarify something, since I'm fine with the idea of people disagreeing and uploading what they feel is valid in this respect, your conclusion still follows your mode of thinking; a decision by attempting some sort of mechanical objectivity based on what the engine permits. All that concerned me was whether the player entered the void, specifically. The main reason not to put void-space playing in the highlight is to avoid Doomguy in Voidland or Through the Hall-of-Mirrors scenarios. Do people really want to be playing in a totally untested, visually warped area around the level? Do they still consider that "playing the game"? It's very easy to avoid, easier that applying some of the existing categories that rely on more arbitrary rules, still leaving the (miscellaneous, or a more controlled TAS) option to explore a technically quicker level exit with the glitch.


Creaphis said:
If anything deserves a separate category it's Doom runs that use glides, at all.
It might have been easy and sensible to disqualify line-glides by the roots, where it's obvious the player just goes through a vertex joining two solid linedefs, but gap-glides seem fuzzier to judge and like an extreme form of squeezing through a space, so I wouldn't argue against them.

Old Post 09-19-10 17:14 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
xepop
Junior Member


Posts: 232
Registered: 10-09


I wondered why it's harder to get into void in icarus map29 than i.e. e2m6 or doom2 map30, so I took some tests and came to conclusion that the lenght of the linedefs making the 45 degree angle to the east have an effect on how easily you glide through and which strafing angle is the best to use.

I made a test map with void in and void out glides (it seems you can't glide from the backside of linedef so they must be flipped, other than that it doesn't matter if you are in or out). I recorded a demo and started to adjust the "/" linedef and see if my demo breaks completely or exit happens.

Results were (grid size convenient):
shortest tested 33,94
working 237,59 (10.51s); 182,02 (10.54s)
best (9,94s) 305,47; 294,16; 282,84; 271,53; 214,96;
longest tested 316,78

Also, I tested these values by playing myself and seeing if they feel easy or not (182,02 feels good in terms of short linedef and reasonably easy glide). Now of course these values were specific for "one step" glide {zero position is POV to east, one step is one chunk to right and (some momentum needed ) then strafe 50 to left will make it (only weirdos strafe to right :p)} so this type of glide may/will not work on other linedef lenghts.

So I actually have a humble request for someone who knows something about the source code to explicate collision detection a bit and/or point the relevant part from the files for me as I'm yet to learn a thing about c++.

Old Post 12-05-10 17:35 #
xepop is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Creaphis
I will deliberately take a contrary position just for the sake of writing incredibly long arguments


Posts: 4167
Registered: 10-05


I don't quite understand all the values in your post. For instance, does


xepop said:
237,59 (10.51s)


mean that your two linedef lengths were 237 and 59, and that it took 10.51 seconds for your demo to perform the glide?

Anyways, if you're collecting data points, then I may as well share that I've found a very easy void glide on DV.wad MAP03:

http://img710.imageshack.us/img710/814/dvvoid.png

(It's also completely useless.)

Old Post 12-05-10 20:27 #
Creaphis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
xepop
Junior Member


Posts: 232
Registered: 10-09


Upper linedef were constant = 90,51
I changed only lower linedef and doombuilder gives it to me with 2 decimals. And yes, the times were the exit time for demo. I don't know if that is relevant but I wrote them anyway.

Hmm, which should I use 90.51 or 90,51?

Old Post 12-05-10 20:58 #
xepop is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
dew
experts


Posts: 3041
Registered: 05-08


there are two very obvious and easy void glide spots in speed of doom map24. nothing good comes from it though, because exit is in an unfavourable place and not even travelling "around the globe" helps. maybe if there was a way to produce a ghost archvile... :)

Old Post 12-05-10 21:30 #
dew is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Grazza
1.19345614 × 10^-66 m^4 kg^2 / s^2


Posts: 12322
Registered: 07-02


Evilution (TNT.WAD) map13 features a very easy void glide (it should be obvious from a glance at the map where it is), but also useless from the point of view of exiting as far as I can tell, as there is no viable path through the void.

Old Post 12-06-10 21:46 #
Grazza is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Creaphis
I will deliberately take a contrary position just for the sake of writing incredibly long arguments


Posts: 4167
Registered: 10-05


Okay, I said that I'd share my knowledge (read: guesses) about guideless glides so I guess I'll do that now.

To start, I'd like to make a change to my earlier taxonomy. I've taken a liking to the term "gap glide" rather than "standard glide" as it's more intuitive. The subject of this post will be "guideless gap glides," or "guideless glides" for short as the guided/guideless distinction doesn't apply to wobble glides.

It's only going to get more complicated from here.

My first point of reference after deciding to learn how to perform these glides was this post by cack_handed. The techniques I use in my Epic 2 demo are so much the same as those listed here that the differences aren't worth noting. Also, the most important insights about how these glides work can already be found in that thread, but in this case I may be able to offer a few refinements.

For instance, a common belief (if beliefs in a field as esoteric as this can be considered "common") is that, for a guideless glide to be possible, the player must position himself exactly in front of the center of the gap, and then move directly into it. Speaking strictly, this isn't the case. After I managed to record my first successful glides on Epic 2 MAP07, and after I got Doom Replay Editor 2 (download) to work, I was surprised to learn that at the moment of each successful glide the player moves from a position that's outside the gap, and just barely off-center with it, to a position that's centered in the gap, and already a small distance inside it, in a single tic. This microscopic teleport surprised me, but I think it can be fully explained within Doom's intended movement logic. But, to tell you that story I'll have to tell you this one: the phenomenon of sideways drifting when attempting one of these glides can also be explained within Doom's movement logic.

The explanation behind "drift" is actually so simple that it hardly deserves its own paragraph. The truth is that, when playing with a reduced turning resolution (eg. when recording a vanilla demo), the four orthogonal directions that the player can face aren't orthogonal at all; instead of lining up perfectly with the map's axes, these directions are turned to the left by about 0.01 degrees. I discovered this by recording a demo of the player simply running forwards and backwards along one of these "orthogonal" directions, and then studying the resulting demo in DRE to see the player's position at each tic. For every 5000 map units (roughly) that the player moves forward along one of these directions, he will also move to the left by one unit. Because of this, when the player runs "directly" into a wall, the angle of his approach causes him to drift just slightly leftward.

This factoid allows us to explain a successful glide within the terms of Doom's movement logic. (The following explanation should probably be taken with a grain of salt, as my only understanding of Doom's movement code is what I've been able to glean and extrapolate from this post by 4mer.) When calculating the player's movement during a single tic, the normal (low-momentum) case is that the engine makes up to two checks. First, the engine looks at the player's momentum for that tic, calculates a displacement vector from that momentum, and then checks whether the position where that vector would place him is legal (ie. not intersecting any lines/things the player can't walk over). If it is legal, then the player is placed there and that's the end of it. If it's illegal, then Doom tries to "slide" the player along the line (or one of the lines) that caused the first check to fail by reducing the displacement vector to the component that is parallel with the offending line. Then, Doom moves the player according to this new vector (assuming that the resulting position isn't also illegal).

Performing a guideless glide requires the first check to succeed. During a tic where a guideless glide succeeds, the engine has first calculated the player's momentum (taking both the player's input for that tic and leftover momentum from previous tics into account), calculated a displacement vector from that momentum, and decided that the resulting position from that vector is perfectly one-hundred-percent legal. Because the "orthogonal" directions that the player can face aren't truly orthogonal, the displacement vector will always have both "forward" and "left" components to it, so the only original positions from which a move into the gap can be can be considered legal are, in fact, some miniscule distance to the right of the gap entrance. A glide succeeds if the "sideways" component of the displacement vector calculated during this first check is perfectly sized to place the player in the exact center of the gap, and because that same displacement vector also has a "forwards" component, the player will be moved some distance inside of the gap in the same tic. This is the cause of the "microscopic teleport."

If you're still reading this, then I'm sure that the first question on your mind, which you've been patiently waiting for me to answer, is, "What's the easiest way to do these glides?" Well, if my relentlessly exact language hasn't already made its message clear, let me spell it out: there's no easy way. However, there is a "safe" way and a "fast" way, both of which should become reasonably possible to perform with practice and a good set-up. Before describing them, however, I'll have to plunge you neck-deep into seemingly irrelevant details just one more time!

Doom Replay Editor writes out the X and Y coordinates of the player after each tic down to six decimal places. I noticed while studying demos that the smallest amount of movement possible along one of the map's axes appears to be roughly 0.000015 map units. I'm going to hazard the guess that the Doom engine considers this distance as 1/65536 of a unit, and that a unit's worth of distance can be broken up into 65536 of these "micro-units." What makes a guideless glide difficult is that you need to come up with a displacement vector that places the player exactly in the middle of a 32-unit gap, instead of in one of the 65535 other positions that all return the same coordinate value when you type "idmypos." Also, there's essentially only one tic per glide attempt during which there's a chance that the glide will succeed. Remember, if the first check in Doom's movement code fails, it will "slide" the player, so, if you're almost lined up with the 32-unit gap, but the sideways component of your movement vector for the next tic is just a little bit too large, you'll slide past the opening and fail the glide, without receiving any visual indication that you have done so.

When the odds are this steeply against you, it's astounding that these glides are possible at all. Here's how cack_handed's method beats the odds:

- By playing at vanilla resolution, you can study the pixels visible on-screen to narrow down your position. When the player's face is pressed directly against an orthogonally-facing wall, he can see 32 units' worth of texture. At 320x200 resolution, each texture pixel is ten screen pixels wide. Therefore, you can ensure that you're standing within the correct tenth of a map unit by positioning yourself so that the right pixels are showing. (Theoretically, you could pinpoint your exact location even more finely when playing at higher resolutions, but it becomes much harder to identify individual columns of pixels as screen resolution increases.)

- It just so happens that, when sliding left towards the center of a 32-unit gap, at the moment that the first column of screen pixels of the texture on the front face of the left pillar comes into view, the player is positioned about a twentieth of a unit from the gap's center. Human reaction times being what they are, it's likely that the player will be even closer to the center of the gap by the time he releases his "move forward" key (assuming he hasn't overshot it entirely). It's a bit odd that the player can see more of the left side of the gap than the right one, even when still positioned to the right of the gap's center, but this may be because, as mentioned earlier, the player is turned 0.01 degrees to the left of what you'd expect.

- With a slow enough forward approach, it's actually possible for the player to slide sideways by only one micro-unit per tic, guaranteeing that the glide will ultimately succeed. (On one tic, the player will be located only one micro-unit to the right of the gap's center - on the next, the player will end up inside the gap.) This repeated movement of 1/65536 of a unit per tic will be the result if the player can somehow feed the engine an endless stream of GF2 (Go Forward 2) commands. The part of Doom's movement code that handles sliding takes the movement vector of a GF2 tic and flattens it into a vector that moves the player only 1 micro-unit along the wall. (The distance that a GF1 tic moves the player is so slight that the sideways component of the movement vector seemingly rounds to zero.)

Ta-daa! We have perfected the art of guideless gliding - in theory. Looking at the matter practically, there are still a few things to consider. Let's imagine that an aspiring glider has positioned himself as accurately as possible with pixel cues, and is now somewhere within one-twentieth of a unit to the right of a gap's center. Let's also suppose that, thanks to a perfect set-up and diligent practice, our glider is able to send a pure stream of GF2 commands to the engine. Well, one twentieth of a unit is around 3277 micro-units, and each second has 35 tics, so it'll take up to ninety-four seconds for the glide to happen. I'm calling this the "safe" way to do a guideless glide, because it's not fast.

If you want to perform a guideless glide in a reasonable time-frame, take a chance and do it the "fast" way. To give you a sense of what the "fast" way looks like, I'll analyze my own demo.

After I first approach the bars, I spend a few awkward moments crudely positioning myself, lining myself up with the gap in front of me as best I can. Then, at tic 1299 the sex metaphor breaks down as I start running forward - a series of GF50 tics is a "quick" way of moving to the left. At tic 1436 I'm done tapping my "run forward" key and all existing momentum has resolved. I'm quite lucky, because I'm now resting only 230 micro-units from the center of the gap. At tic 1484 I start pushing my mouse forward, and only 12 tics later I botch the glide. My Go-Forward commands have an average value of 5, but the sideways momentum caused by them is already large enough to take more than one tic to resolve, so my momentum during each tic is increased by a slight additive effect. This results in my displacement vectors being big enough to send me skipping 10-30 micro-units to the left every tic, so the odds of landing on the correct micro-unit really were quite low. I have no way of knowing that I've already blown the glide, so I keep up the attempt until tic 1577, when I finally abort it by turning one player-angle-unit to the right and moving forward to quickly slide back to the right side of the gap. (Note that it's also possible for a glide to succeed during these return trips - it's just much less likely that the player will land directly in the middle of the gap when he's sliding at such a "fast" pace.) At tic 1606 I start running into the bars again to slide back left into position, and at tic 1701 I come to rest, and again I'm quite lucky - I'm only 151 micro-units from the gap's center. I start moving my mouse forward at tic 1722 (a little slower this time) and on tic 1739, a lucky jump of 13 micro-units puts me square inside the gap.

This is the fast way. The odds are never in your favour, but with more practice and finesse than are on display in my demo, you should be able to make a complete glide attempt in only a few seconds. Then, it's your choice whether you string multiple glide attempts together in a single run attempt or restart your run in between. Either way, the glide will eventually succeed.

The most important skill to practice is positioning yourself (with GF50 tics) as close as possible to the middle of the gap without going past it - it's kind of like "The Price is Right." I believe it should be possible to develop a "feeling" that will help you enter this sweet spot fairly consistently. Also, if it's ever important that a glide succeed in its first few attempts, remember that can increase the chance of success of a single glide attempt by making smaller forward movements during that phase of the attempt.

Well Grazza, I'm glad you read all the way through, even though nobody else did. ;)

PS: I have absolutely no idea why east-west glides are easier.

PPS: I think that all of this may also have some bearing on guided glides. I may analyze a few more demos and return to that topic later.

Old Post 12-09-10 03:26 #
Creaphis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Never_Again
knows his birth month


Posts: 959
Registered: 04-03


Thank you, Creaphis, for finally delivering your explanation. I may have had even more reasons than Grazza to read it closely, as the day before you posted your MAP07 glide in the EPIC2 thread I was looking at doing a NM Speed on MAP03.

The red bars immediately caught my attention. I had never done a glide in my life, but the 32-unit gap between them seemed to mock me: "See? Grazza or dew would fly right through me and finish the level in no time. But that's them; a sucker like you is condemned to crawl around". After trying to stick it to the bitch for half an hour I beat a tactical retreat and dived into Forum Search. Like you, I found cack_handed's step-by-step glide explanation the most lucid and in another ten minutes I had done my own pl08 glide twice!

My confidence revitalized, I returned to EPIC2 only to taste failure again. After countless fruitless attempts I started examining the difference in the level geometry between ep203 and pl08. The only difference I found is that in pl08 the player glides east-to-west, and in ep203 he needs to go in the opposite direction. Quick noclip to the other side of the red bars and in a couple of minutes I was able to glide through!

I found that the easiest way to accomplish that in prB+ is to set the automap grid to 16 and align the player's arrow with the grid line running between the bars. However, going through the gap east-to-west and then trying immediately to back into it didn't work. I even saved the game while inside the gap, noted the IDMYPOS numbers and replicated the angle and the Y-pos on the westerly approach to the bars - all in vain. It appears that c_h's method breaks down when used west-to-east: the player never stops sliding while pushing full-speed against the bars. Trying to push with the mouse only at the lowest sensitivity didn't help either - even though I managed to match the angle and the Y-pos exactly from the west, sliding never stopped and I never got through once.

At this point I started suspecting that the numbers didn't actually match exactly and prB+'s integer IDMYPOS output (unlike vanilla's, based on map coordinates) lacked the necessary resolution to display the difference. Indeed, Choco's hex numbers are a lot more precise (and confusing, being in hex ;) and watching your MAP07 glide over and over with continuous IDMYPOS output I was able to spot that "teleporting instant" a day before you pointed it out. You can see it around the 24s mark: one moment the player is in front of the gap at Y=0xE7FF3 and the next he's at 0xE8000 - and already inside the gap!

I made a video of it - the YT screen is at the bottom of this post. YT doesn't let you slow down the playback and its rewinding blows, so here is the raw footage that you can slo-mo through with Media Player Classic.

This finding encouraged me to spend close to an hour trying to get 0xE8000 in Choco on MAP07 for myself, but it was an hour wasted. That led me to suspect that while that number may indeed reflect the player's position while inside the gap, the number required to get in there may be actually lower. This suspicion has now been confirmed, albeit I must admit I'm not dexterous yet to take advantage of Creaphis' revelation.

And the biggest question on my mind still has to be answered: why doesn't cack_handed's method work in the west-to-east direction? i.e. why does the player never stop sliding?

Here's to hoping that this somewhat confused post may nudge greater minds than mine into the right direction. ;)

Last edited by Never_Again on 12-09-10 at 05:21

Old Post 12-09-10 05:16 #
Never_Again is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
xepop
Junior Member


Posts: 232
Registered: 10-09


Just for clarification when we are talking about "gap glides" do we mean east-to-west and north-to-south glides as opposite to the "guideless gap glides" in west-to-east and south-to-north directions? At least that's the way I always thought these gap glides. Epic2 map02 for example has one easy gap glide (guided as the player stops sliding when in position), but monsters kind of ruins everything always.

Old Post 12-09-10 05:51 #
xepop is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Grazza
1.19345614 × 10^-66 m^4 kg^2 / s^2


Posts: 12322
Registered: 07-02


Excellent post and explanation. Many of your conclusions help explain things that had been puzzling, and will doubtless lead to more discoveries.

For instance, I believe you have explained why my own Strain map07 glide (north-to-south) failed when even a single tic greater than GB1 was used - I was already lined up perfectly, and any GB2s would have sent me off to the side.

Judging from your account, the odds of success for a guideless glide attempt can be doubled by alternating GF2 and GF1 tics (at the cost of taking twice as long).

Maybe the biggest puzzles are:
Why do guided glides ever fail?
Why are east-to-west guideless glides so much easier? Looking at the poor "odds" for a east-to-west glide to succeed, there is something going on that vastly improves them in the opposite direction.

xepop: Creaphis's Epic 2 map07 glide was west-to-east, and his analysis applies to that. But the mechanics in other directions must involve similar considerations - but why they are not identical is yet to be explained. BTW, from your post, do I take it that you regard north-to-south as being as easy as east-to-west? I've never had any luck with Evilution map17's NS glide, although I've generally had few problems with EW glides.

Old Post 12-09-10 06:02 #
Grazza is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Creaphis
I will deliberately take a contrary position just for the sake of writing incredibly long arguments


Posts: 4167
Registered: 10-05



Never_Again said:
And the biggest question on my mind still has to be answered: why doesn't cack_handed's method work in the west-to-east direction? i.e. why does the player never stop sliding?


I never interpreted any part of cack_handed's instructions to mean that the player will stop sliding once in position. So, I would say that his method works perfectly in the west-to-east direction. Also, it's expected that the player will never stop sliding; east-to-west glide openings are the odd ones out because, for some reason, the player does stop sliding!

Believe it or not, I wrote that whole post above without being aware of that last fact. I was aware of the common judgment that east-west guideless glides are easier than those in other directions, but I wasn't aware of how, and never actually bothered to try one myself. I'm more interested in "rules" than "exceptions" anyway - they apply to a wider set of cases, and are easier to deduce. (I doubt I'll ever figure out why east-west glide openings behave the way they do unless I learn C and spend a lot of lonely hours with the source code.)


xepop said:
Just for clarification when we are talking about "gap glides" do we mean east-to-west and north-to-south glides as opposite to the "guideless gap glides" in west-to-east and south-to-north directions?


By "gap glides" I mean all glides that involve a gap that's an even 32-units wide that the player slips through. By "guideless" gap glides I mean the subset of gap glides that is performed through gaps that resemble holes in a flat wall, in that there is no jutting architecture that the player could use to easily align himself with the gap. Even though there is one direction (or two?) in which guideless gap glides are "guided" by this unexplained sudden stop to the player's slide, I'm still calling them "guideless."


Grazza said:
Judging from your account, the odds of success for a guideless glide attempt can be doubled by alternating GF2 and GF1 tics (at the cost of taking twice as long).


I don't think so. The sideways momentum caused by a GF2 command is so small that it fully resolves during a single tic. No momentum is carried over to subsequent tics, and therefore, the player should reliably slide sideways by one micro-unit each and every tic during a block of GF2 commands. Any movement pattern that approaches every single micro-unit as if it were the gap should guarantee the success of the glide, and hitting each location twice could hardly make success more guaranteed. If success is in fact not guaranteed by a stream of GF2 commands then we have another problem, which GF1 commands wouldn't necessarily solve.


Grazza said:
Why do guided glides ever fail?


This one's bugging me. I think I'll test some things.

Old Post 12-09-10 07:17 #
Creaphis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
RjY
anARCHy


Posts: 930
Registered: 05-02


Summary: when you apply a forward motion Doom converts its magnitude and the angle you are facing into x and y components of momentum using precalculated cosine and sine tables. These tables are not very accurate. Neither is the 16.16 fixed point arithmetic very accurate for these precise purposes. In particular I show why it is less accurate when moving north than when moving east.

--

Consider first, angle.

Going north your angle in polar coordinates is pi/2 (90 degrees.) In Doom's internal binary angle measurement system of unsigned int32s, it is 0x40000000. To convert to rectangular coordinates the angle is shifted right ANGLETOFINESHIFT = 19 times to give a 13-bit index (from 0 to 8191), which in this case is 2048, and looked up in tables called finecosine and finesine in the sources to give you x and y components of a unit vector in the direction of the angle as 16.16 fixed point numbers. (Aside: finecosine is just an offset into finesine; cosine is of course just sine with a phase offset)

So we have (pi/2) -> 0x40000000. and 0x40000000 -> 2048. So for movement north, finecosine[2048] is used to calculate the x-component of your momentum and finesine[2048] for the y-component.

Ideally, finecosine[2048] would be 0 and finesine[2048] would be exactly FRACUNIT (0x10000, or exactly 1.0) when travelling north, but they're not. In fact they are 0xffffffe7 and 0x0000ffff. About -0.00038 and 0.99998.

So even if you are facing exactly north you will drift to the west ever so slightly as you move.

I hope someone can follow all this.

When going east your angle is 0, which is more easily seen to be just finecosine[0] and finesine[0], looking up which gives you 0x0000ffff and 0x00000019, about 0.99998 and 0.00038. So at least they're symmetric!

--

I apologise for the incoherence of this post. I am writing it out as notes as I work through the calculations and source code. At this point I have no idea if I'm even going to reach a useful conclusion!

--

Now we come to converting a forward moving tic in a demo to momentum and the question of why gliding north is harder than gliding east. I think this is due to the fact that the perpendicular deviation (north when gliding east, west when gliding north) is negative in the north case.

For each tic when you are moving forward the size of your forward move (I think people call it GFsomething) is multiplied by something called movefactor, which defaults to 2048, or 1/32 as a fixed_t (this is different in a Boom friction sector obviously, but let's forget about that for now)

So, suppose you do a GF01 tic in your demo. So for that one tic, 2048*cos(angle) is added to your x-momentum and similarly with sin(angle) for y.

This introduces the vagaries of fixed point multiplication and the FixedMul function. In fixed point we have as perpendicular deviations from movement as follows
east: FixedMul(50*2048, finesine[0]) = FixedMul(102402048, 0x00000019) = 0.
north: FixedMul(50*2048, finecosine[2048]) = FixedMul(102402048, 0xffffffe7) = -1.

So there we have it. If you record a GF01 tic moving east, you do not deviate at all north or south. However if you make even the slightest move north, your momentum drifts at least 1/65536 map units per tic to the west. This seems to explain why gliding north is harder than gliding east. I've put it in bold so it stands out more to a reader quickly scanning the page and only skimming excessively long posts.

--

Phew! I'm glad that turned out all right. I'd've felt pretty stupid if I'd gone through working all that out and writing it up only to find there's no obvious reason for north glides being harder. I haven't proofread this post as much as I should've either, so apologies for any obvious errors.

Last edited by RjY on 12-09-10 at 13:59

Old Post 12-09-10 08:33 #
RjY is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
dew
experts


Posts: 3041
Registered: 05-08


haha more doom disertation. this is quite epic research you guys are undertaking... now how about the doom2 map22 glide? my cz-n nomo record shows the best position is actually one full step to the left of the pretend-orthogonal direction. is this a conjuncture of the glide theory and doom engine's failed collision check?

anyways, i aim for perfect position and gf1 stream in my free/guideless glides, of course higher resolution in pr+ helps that. the easiest way for anyone to achieve the highest free glide chance is to use vertical mouse movement (1 notch above zero) and completely kill your horizontal axe mouse movement. then you just find the right spot (pixel hunting, usually on the bar on the left end of your screen, and push your mouse slowwwwly forward. another ridiculous nonsensical trick is to go back a bit and "restart" your attempt if it doesn't work.

perfect gliders would actually be keyboarders with mouse adjusted specifically for gliding... prboom+ allows sort of cheating, because it pauses the game while you go fiddle with mouse settings.

Old Post 12-09-10 12:29 #
dew is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
xepop
Junior Member


Posts: 232
Registered: 10-09


Yes, nice to know what's behind these. For the pseudo guided guideless gap glides (heh) there are 2 styles what I've used. One is the already mentioned vertical mouse movement stuff, which has a problem of losing the pseudo guide after all. The other is turning 90 degrees (does it matter which direction? probbly not) and going in with strafe, which has the added bonus that the pseudo guide stays and you can retry easily. I recorded these demos (evilution map 17) and they probably clarifies more than my english could. Note that in vertical style (evs) I rememberd the correct procedure after 6th demo.

Attachment: evtests.zip
This has been downloaded 21 time(s).

Old Post 12-09-10 15:41 #
xepop is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Wagi
Member


Posts: 325
Registered: 11-10



Creaphis said:
PS: I have absolutely no idea why east-west glides are easier
Looking at the code, I can't tell you exactly why, but it's probably the same reason why wallrunning only works when moving North and not when moving East.

Old Post 12-09-10 18:20 #
Wagi is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Creaphis
I will deliberately take a contrary position just for the sake of writing incredibly long arguments


Posts: 4167
Registered: 10-05


Thanks for your input, RjY! I guess that means that, when attempting a south-to-north guideless glide, a series of GF1 tics would be ideal. I'm also getting the impression that each of the four glide directions is afflicted with its own idiosyncrasies, so any conclusions drawn about glides in one direction might not be applicable to the rest. Bummer.


dew said:
another ridiculous nonsensical trick is to go back a bit and "restart" your attempt if it doesn't work.


I think this is mostly just a superstitious habit.


dew said:
prboom+ allows sort of cheating, because it pauses the game while you go fiddle with mouse settings.


I "cheated" in my epic2 demo by lowering my mouse sensitivity at the moment of the glide with my mouse's built-in sensitivity controls.


Wagi said:
Looking at the code, I can't tell you exactly why, but it's probably the same reason why wallrunning only works when moving North and not when moving East.


I thought of this, but wallrunning can be fully explained by bugs in Doom's Newtonian physics that couldn't have any effect at the quantum level of ultra-low-momentum player movements. The Doom Wiki article explains it well.

EDIT: Oh wait, I misunderstood. Wallrunning doesn't work when moving east? Really? I guess I haven't spent enough time in a classic demo-recording environment to realize otherwise. Well, depending on the nature of that glitch, it might have something to do with east-to-west glides and it might not.

Last edited by Creaphis on 12-09-10 at 18:56

Old Post 12-09-10 18:45 #
Creaphis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
dew
experts


Posts: 3041
Registered: 05-08



Creaphis said:
I think this is mostly just a superstitious habit.

well... i tend to agree, because i have no real explanation for it. however i have far greater success rate for wall-guided glides with it. if i don't glide under a second, i go back, sideways against the wall, then try again. using a variant of this for free glides might be just my habit.


I "cheated" in my epic2 demo by lowering my mouse sensitivity at the moment of the glide with my mouse's built-in sensitivity controls.

tbh the prboom+ menu trick feels like a mild TAS to me, because very specific, axially asymmetrical sens change is used and reverted immediatelly after the glide. i can do what you described as well, but that's just a crutch compared to removing horizontal turning entirely, at least for me.
i'd like to hear grazza's, myk's and other opinions on abusing the prboom+ menu pausing, because if i'm allowed to do so, i might produce a stream of free glide speedruns. :)


Wallrunning doesn't work when moving east?

it does, it is just "slightly" harder.

Old Post 12-09-10 20:00 #
dew is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
xepop
Junior Member


Posts: 232
Registered: 10-09



dew said:
i'd like to hear grazza's, myk's and other opinions on abusing the prboom+ menu pausing, because if i'm allowed to do so, i might produce a stream of free glide speedruns.

There's this dms015 utility for doom2.exe, which allows you to map vertical sens toggle for a key so you can enable and disable it when you want. Would like to hear about that, too.

Old Post 12-09-10 20:09 #
xepop is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Creaphis
I will deliberately take a contrary position just for the sake of writing incredibly long arguments


Posts: 4167
Registered: 10-05



dew said:

well... i tend to agree, because i have no real explanation for it. however i have far greater success rate for wall-guided glides with it. if i don't glide under a second, i go back, sideways against the wall, then try again. using a variant of this for free glides might be just my habit.



I may have misunderstood again. Going back to the right is definitely necessary if the player has already slid to the left of the gap entrance, which will often happen within the first few seconds of a glide attempt. What I meant is that the habit some players have of moving backward off of the gap before making a fresh attempt at the glide is probably useless. However, this could be useful if it helps a player to renew their concentration.


dew said:
i'd like to hear grazza's, myk's and other opinions on abusing the prboom+ menu pausing


Same here. My guess, though, is that consensus will consider it as similar to HUD use - it's something that should be mentioned in a demo's text file, just so everyone knows what the runner was working with.

Old Post 12-09-10 20:38 #
Creaphis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Never_Again
knows his birth month


Posts: 959
Registered: 04-03


Trying to define sub-categories of TAS is akin to attempts to introduce terms like "slightly pregnant" into obstetrics. Then again, there have been plenty debates on what constitutes TAS and what doesn't already, I don't mean to restart them. Let's just say, for simplicity's sake, that if you have the slightest doubt whether your demo is TAS or not - mark it as TAS in the TXT and your posts, and specify your reasons for doing so.

And I'd like to point out that TAS is not a four-letter word, there are actually three letters in it. ;) There, it's nothing to be ashamed of.

About HUD use - this term needs to be qualified. "HUD used" in a TXT file tells me nothing. You can have full-screen HUD with just health, armor and ammo - what's TAS about that? The kills/secrets stats counter is what really needs to be mentioned, the HUD itself really doesn't matter.

Old Post 12-09-10 21:04 #
Never_Again is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Grazza
1.19345614 × 10^-66 m^4 kg^2 / s^2


Posts: 12322
Registered: 07-02


I also thought that whatever causes wallrunning might be responsible for whatever it is that is making east-to-west guideless glides easier. Or at least related. After all, it seems to be the only one of four directions that this happens, and it coincides with the one of four directions where wallrunning works - i.e. there is a mysterious 'northwards force' on the player in both cases.

I suppose this hypothesis could be tested by setting up a glide in another direction with two-sided walls blocking the player.

Creaphis said:
What I meant is that the habit some players have of moving backward off of the gap before making a fresh attempt at the glide is probably useless.
If you're talking about guided glides, I think it's because by dint of experience people learn what a successful glide looks like (in terms of wobbling, shaking, etc.), and what it doesn't. If it appears to be failing, then it makes sense to back off and try again.

As for the question of pausing in order to change settings... personally I wouldn't do it, and would tend to view it as at least a little questionable. Indeed, I have steered clear of radically changing settings for specific demos (i.e. changing them before recording) - if the settings aren't ones that I consider usable for general purposes, then I don't use them for recording. (Obviously this is just a personal preference.) Since adopting low-sensitivity mouse movement (having been a novert-er for years) to make glides easier, this has become my setting for general use too.

But is it legitimate? I dunno. Henning would often go to Windows to pause in his 30nm runs, and no one seemed to object to that. And in those breaks he would get something to eat, calm his nerves, or even plan tactics (including getting advice from Anders J.) for the next map if he had suffered a surprising loss of health, etc. Is that any less radical than changing mouse sensitivity? And indeed, some hardware/software may enable these changes to be made on the fly without resorting to menu-based pausing - does that instantly make it OK, even though it is the same effect? So my conclusion is "I wouldn't use it myself, but definitely wouldn't call it cheating, wouldn't call it TAS (reserve that for slowmo, joining and S50 automation), but it's a little awkward, and should be mentioned in the txt."

Creaphis said:
My guess, though, is that consensus will consider it as similar to HUD use
Personally, I consider using a live-monsters counter in a Max category to be more questionable.

Old Post 12-10-10 02:05 #
Grazza is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
kimo_xvirus
Junior Member


Posts: 242
Registered: 03-08


I thought menu pausing desyncs demos but it turns out that only happens in vanilla Doom


dew said:
prboom+ allows sort of cheating, because it pauses the game while you go fiddle with mouse settings.


Creaphis said:
I "cheated" in my epic2 demo by lowering my mouse sensitivity at the moment of the glide with my mouse's built-in sensitivity controls


I think Creaphis method is more legitimate because
1. It's done in real time
2. Pausing stops the gameplay, you can abuse it in other ways like pausing for a moment to plan where to move to dodge projectiles or calming your nerves midrun
3. And if we allow pausing to change mouse sens only at glides, it's an unclean rule because it's not like we pause and unpause at the exact same time...

But if we allow Creaphis method, it'll be like "Using External Software or Hardware to change mouse sensitivity during game is allowed as long as game is not paused"
More proper imo, and we can standardize in the community if we get a software that does that or maybe ask Entryway to implement flexible mouse sensitivity bindings in Prboom+

dew, can you tell me your demos where you paused during gliding?

Old Post 12-10-10 20:12 #
kimo_xvirus is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Qaatar
Member


Posts: 411
Registered: 06-09



Never_Again said:
About HUD use - this term needs to be qualified. "HUD used" in a TXT file tells me nothing. You can have full-screen HUD with just health, armor and ammo - what's TAS about that? The kills/secrets stats counter is what really needs to be mentioned, the HUD itself really doesn't matter.


Except one should just use common sense. If I took the time to indicate in my text that I used the HUD (with asterisks and all), pretty sure it signifies something important. People don't indicate "screen resolution used," and having full screen HUD with regular information is the same as having a higher resolution. Thus, what could be so important about using the HUD? Hmm...

Of course, you're technically right, so one should get into the habit of writing "monster counter" used intead of the HUD. HUD is just easier to type.

Old Post 12-10-10 21:41 #
Qaatar is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
myk
volveré y seré millones


Posts: 15137
Registered: 04-02



xepop said:
There's this dms015 utility for doom2.exe,
According to the "other hacks" section of the Compet~n rules page: Various DOOM spinning utilities are allowed.

I don't really see a reason why that one that allows one to toggle sensitivity in-game would be controversial, with that rule in mind, just because it is beneficial for glides. There are no Compet~n rules about how vertical sensitivity should or shouldn't work, and as we can see by what Creaphis says, some hardware already allows one to change that.

Heh, so maybe you guys might want to ask Andrey for a vertical sensitivity toggle key option to emulate it in PrBoom+. Otherwise, PrBoom+ users are forced to obtain a special mouse like Creaphis' or to mess with the menu while playing to do something that is possible already for vanilla (and arguably valid even for Compet~n.)

Old Post 12-10-10 22:13 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
dew
experts


Posts: 3041
Registered: 05-08



kimo_xvirus said:
dew, can you tell me your demos where you paused during gliding?

2c16-058 and sp02-019.31. it's mentioned nebulously in the textfile of the former demo, i actually discovered the abuse during that session. the latter was recorded for czech-n, but i've never submitted it. we used it for the movie to show off a little. :p and the double glide in 30p2 map27, but that's rather obvious, heh.

my 2c01-008, tv22-009 and sp02-025.69 were recorded with keyboard only movement and mouse set up for gliding from the start. my atrocious keyboarding skills are quite apparent in them, hehe.

i will probably record some free glide demos and call them 'uv-hax' category. :P

Old Post 12-10-10 23:14 #
dew is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Grazza
1.19345614 × 10^-66 m^4 kg^2 / s^2


Posts: 12322
Registered: 07-02


Since for the demo I posted here, I devised a way to make the void glide work reliably and quickly, I should post something about it in this thread.

First of all I got myself lodged in the (384, 0) vertex. Then I made sure I was facing exactly to the east, visually aligning the weapon against a particular pixel (a light area on the left of the RL). That meant that I was aligned with the axes and that a pure 45-degree movement would bring me to the vertex that I would be gliding through (512, 128), still facing east. So I used strafe-50? No, I used strafe-40 (just forward and strafe-left keys). This angle of movement (c. 38 degrees from pure forward motion) meant that I grazed against the wall, causing some wobbling/weird momentum shit. When I arrived at the (512, 128) vertex, I was still facing east and already wobbling a little. I found that the glide rarely failed when I had got properly lined up in this way.

Probably this is old news to those who have already practised these glides a fair bit, and it isn't the only way to get them to work. But the fact that this glide is formulaic and easily reproduced by anyone may help those who haven't managed a void glide so far, and anyone looking to work out what is going on with this stuff.

Old Post 12-24-10 15:22 #
Grazza is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
xepop
Junior Member


Posts: 232
Registered: 10-09



Grazza said:
First of all I got myself lodged in the (384, 0) vertex. Then I made sure I was facing exactly to the east, visually aligning the weapon against a particular pixel (a light area on the left of the RL). That meant that I was aligned with the axes and that a pure 45-degree movement would bring me to the vertex that I would be gliding through (512, 128), still facing east. So I used strafe-50? No, I used strafe-40 (just forward and strafe-left keys). This angle of movement (c. 38 degrees from pure forward motion) meant that I grazed against the wall, causing some wobbling/weird momentum shit. When I arrived at the (512, 128) vertex, I was still facing east and already wobbling a little. I found that the glide rarely failed when I have got properly lined up in this way.


I'm not sure about this. I don't seem to get it work in e2m6 for example. I think it has some dependency on where you start the maneuvre. I also probably has to take back the stuff about the linedefs and stuff, as with this style everything behaves differently than with what I used then. It's just weird shit.

Edit: Ok I see now.

Last edited by xepop on 12-24-10 at 19:43

Old Post 12-24-10 19:03 #
xepop is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Grazza
1.19345614 × 10^-66 m^4 kg^2 / s^2


Posts: 12322
Registered: 07-02


I wasn't suggesting that this procedure should work in all cases, or even in superficially similar ones. I was just describing what worked reliably in this specific situation, in case this was useful in some way. Perhaps each geometry has a specific (and different) 'solution', and maybe some pattern will emerge among all this, and we'll have a toolbox of methods to try in each new instance.

Old Post 12-24-10 19:15 #
Grazza is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Looper
Member


Posts: 474
Registered: 07-09



Grazza said:

Why do guided glides ever fail?



I found out that sometimes when you run to the wall you can run like "there was no wall". Atleast the weapon bobs like there was no wall. After this state has been achieved, guided glide never fails.

Using this trick in doom2 map21, one can just "walk" through the gap between the two yellow key doors.


Creaphis said:


I never interpreted any part of cack_handed's instructions to mean that the player will stop sliding once in position. So, I would say that his method works perfectly in the west-to-east direction. Also, it's expected that the player will never stop sliding; east-to-west glide openings are the odd ones out because, for some reason, the player does stop sliding!



It stops always, no matter what direction the glide is, but only if you change the direction, which is not possible while recording. If you are not recording, you can get the angle 0.01 RIGHT instead of left, then it will stop.

(It's possible to have the angle 0.01 right even while recording, but requires using fist/chainsaw to monsters)

Old Post 12-26-10 13:52 #
Looper is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 19:18. Post New Thread    Post A Reply
Pages (5): « 1 2 [3] 4 5 »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Doom Speed Demos > The Two Types of Glides

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Message Board Statistics