Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Creaphis

The Two Types of Glides

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

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++.

Share this post


Link to post

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:



(It's also completely useless.)

Share this post


Link to post

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?

Share this post


Link to post

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... :)

Share this post


Link to post

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.

Share this post


Link to post

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. ;)

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

evtests.zip

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.)

Share this post


Link to post
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

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×