@@decino What if we have a cyber demon that cannot move and just turns. It should shoot the rockets from same location. Then just fine tune the walls so the rockets never explode. This would let you make a room where you can dance with the demon.
@@user-jp7tw3sd3x That only works if the cyber has enough room to move so that he can count down his shot delay timer. Otherwise he gets stuck and does nothing.
So this explains why id Software themselves were extremely careful of orientation of linedefs. It's always puzzled me why would they go to such lengths to ensure every line was placed in a specific orientation, whereas in fan maps the orientation never seemed to matter as there were no obvious downsides to do it either way (save than for line actions). Very nice video as always, decino.
I seem to recall encountering a wall that ate projectiles in Doom 2, Map 15. It always confused me, making me think there was a secret there or something. Good to know this might be the explanation.
LOL the scream for Doom Guy at 5:30 XD I was always a bit pedantic about which side of the linedef was the front. Looks like it wasn't just me being silly. :O
I've known about this since forever - I observed it for the first time in E1M8 (try to shoot rocket into the huge pentagram building once you've fallen down). The outer corners of the big yard in E1M8 also exhibit some unusual anomalies related to hitscan attacks (in Vanilla Doom, that is). It's like your bullets are hitting invisible walls.
A potentially interesting topic to look upon is how Doom actually renders it's graphics (at least in software mode). A lot of curious contrasts between what it did back in the day compared to modern day rendering engines.
Older versions of Doom had some pretty weird bugs and glitches. Contemporary Doomers probably don't know what the "moire effect" is, or the "tutti-frutti effect" - they could be observed fairly often in the oldest PWADs (especially the 1994 ones).
The weirdest OG software rendering weird thing I'm curious of is: if you walk over a line, you can see the line move around a little bit when your origin is close to line, which makes a ledge for instance look like it is starting to extend a bit. Since you cant look up and down you can only really see this by facing parallel with the line you are crossing. Even weirder is this also happens in Star Wars Dark Forces, which is a totally different engine!
@@MGMan37 Ah yes, I think you can observe this on the triangular stairs near the start of Entryway. I suppose engines with similar rendering routines could exhibit similar glitches. It's one of the reasons a lot of people mistakenly thought DF ran on some variation of the Doom (or Build) engine. BTW, if a wall is very, very long, it could also sometimes shift in a weird manner, when observed from an angle. I've seen this in some old PWADs.
Especially the really weird stretching if you were able to look up or down which you can see in games like Dark Forces or even Doom sourceports if you look up or down with software rendering.
Hey, how about making a couple of tutorials about maping in doom? Especially in the complicated parts like sky walls, because It looks that you are very clear when it comes to explain, and you do it better than some people in RUclips in my opinion. I think you would do it great and specially when you add that Great editing. And by the way this video was also great.
As a mapper, thanks a lot for the video! I was wondering what was the cause of this oddity when testing my maps. I remember fixing it by upping the ceiling sector to the same height as the sky and projectiles stopped disappearing.
Ohhhhh, THAT must be why the wall in E4M6 next to the blue skull key and the lava pit behaves the way it does! I never really looked into it, but I assumed it was blockmap-related (guess I was wrong). The Doom engine sure is weird, but it's always fascinating to learn all about its little quirks! Side note: does P_RemoveMobj also make the firing sound cut off when the projectile disappears?
And when I thought I knew everything about the game, Decino manages to teach something new! Also those visuals were amazing! The quality and visual aid of these analisis videos are astonishing! :D
Well, a general mapping practice is that when you have a ledge of some sort, that the sector with lower floor is on the linedef front side; or, if they are on equal levels,that the sector with higher ceiling is on the linedef front side. This does not catch all possible cases one could map, but it's a good principle that avoids issues like these. In fact, one could argue that, because maps *could* be constructed "properly" this way, the source code need not do more than the backside check. Also because CPU cycles were kinda expensive in the 90s for all the things Doom was/is trying to do.
I love these analysis videos, as a game developer, I love the doom engine, and whenever I discover something new about it, my love for it grows even more! That's the main reason why I subscribed to this channel
I have no idea why I love so much watching videos revealing a bunch of technical details and flaws of a game that the last time I played was 20+ years ago
I imagine the solution would be using line-line collision checks for each movement, although that gets a bit more complicated when it's no longer a point but rather a box or some other shape... I've been working on a game and have been thinking a lot about this kind of stuff. I decided on a compromised solution because a more sure way to do it using full polygon collision checks extended along the direction of motion is just very complicated and beyond me to actually implement haha.
playing doom for a few years shy of 3 decades now, so many things in your videos i can recall happening over the years and having it make sense now blows my mind.
I remember Zedek (NoMac90) covered this lightly a few years back in his Doom Bugs, Glitchs and Crashes series. Cool to see it finally broken all the way down
I have always been very careful about which side of linedefs was front and which back in my maps even though I never knew *why* it is important anyway. It was just of those superstition "just in case" things. This info about projectiles going poof is very interesting.
Hey Decino, have you ever noticed that Doom Guy uses his right hand to hold and fire weapons, but uses his left hand to fist bump demons. Is Doom Guy right or left handed? Ambidextrous? Or will we never actually know because of the way the engine mirrors 180 degrees?
I've been trying to understand the code and even though my brain just can't keep up I still enjoy these videos. Maybe it's your calm tone and voice that just works with these kinds of things.
Really interesting I had absolutely no idea about any of this. I like how you go through the code but then also provide visual examples to help visualize whats happening. Well done!
Another great analysis video my friend and now I know why rockets and Projectiles goes POOF! in some moments especially for new doom mappers who just begin to create doom maps
Well, that was interesting. Something I don't think I've ever come across, or don't recall if it did happen. Yeah; that oddity with not really being able to set a 'transparent' border wall makes mapping for fully outdoor areas with cliffs instead of walls rather difficult...it's one of those things that is making my vision *_Starion_* hard to realize.
An (incomplete?) fix for the origin check is to store the spawning position of the projectile. You can use this to create to determine the proper wall face. This fix might fail at extremely close distances to the target or if it hits a thin wall wedge (i.e. a very narrow pointy wall corner), but should much better than nothing.
I wonder how this would work in a setup where this is just layered. So multiple sectors of broken collision. Sometimes the rocket will fall further into the wall than others. Probably makes damage super unpredictable.
I noticed an odd bug about rocket explosions: if I manage to fire one at a pillar or a wall that have sky, sometimes the rocket explodes inside the wall, but the damage I take is the same as if the rocket were to explode outside the wall. Noticed this first in Plutonia Map 31, where I fired rockets at the pillar with the yellow key, more specifically at the steps in the spiral staircase. Basically I just run at the pillar, I fire the rocket at a certain distance before I collide with the wall, rocket explosion animation is seen just above the staircase, I take a certain amount of damage. But if I hug the same pillar wall, and fire the rocket at it, I take the exact amount of damage, even though the explosion animation is clearly outside the pillar/staircase. The same thing happens when I try on walls that have a direct sky connection. However, the bug doesn't happen inside rooms, only works when there's a clear sky above the pillar/wall. What's the deal here? Does the explosion animation and the actual rocket explosion take place in slightly different positions due to the sky hack?
So, here's a funny coincidence: I was watching your playthrough of Hell Revealed map 19 (for reference, because I'm doing a playthrough of it myself) and notice a rocket disappeared at about 3:25. Funny, huh? You had a disappearing rocket in both HR maps 19, 1 and 2!
Got one thing I've been curious about. Probably a silly thing, but I always found it interesting how the monsters always know exactly where you are once they're active. Yet you could have no clue where they are, unless the cheat that sees everything on the map is on. I'm guessing that's probably what they do to find you but I've always found it interesting as what makes them able to home in on the player so well. Lol
If only this were more reliable to trigger, could make for some interesting map effects, although I would guess this is what actually happens to some of the "explosions" that occur when the Icon of Sin is killed, namely the ones that spawn in the floor.
In DOOM E1M8 Phobos Anomaly, I recall that projectiles shot into the sides of the points of the “star” tend to disappear. It seems we have much to learn about the still-elusive DOOM. Brilliant work as always. And my inner Beavis and Butt-head will never tire of the reading of the ridiculous Patreon usernames.
You have the uncanny ability of making analysis videos about glitches I just noticed. I'm pretty sure a revenant missile did the same thing today on Doom II in Spain Only's MAP29 (yes, you made me revisit this one ;) ). IF the oversight also applies to enemy projectiles, that is. If not, it was something else. Thanks for explaining!
Oh, so that's what happened in that clip that I had: When I was playing that TNT Evilution map that contained unreachable enemies behind the wall, I shoot a few rockets into their direction, and some of their origins might have appeared behind the sky wall while doing the collision check, resulting in rockets explosion and triggering enemies. Hm... But I may be wrong again, still confused about how did I manage to avoid projectile disappearance
I actually had this problem before. I had a large city map where I got different height buildings by bringing the sky down to the wall. I left the map for 6 months and on my return suddenly my rockets were no longer working! After some testing I realized the problem and I had to go through every building and make the sky extend from the wall a bit. Since the two sectors have the same ceiling height the projectiles don't evaporate. Then if I'm remembering correctly, I realized I had been testing on the wrong complevel and I think boom fixed this issue so all my hard work fixing my map wasn't strictly necessary.
I love the sound effects when you're explaining how missiles react to walls with sky textures. Missile hits wall - boink! Missile disappears - pop! :-)
Something really odd, whenever collision checks like these have to check for what it is that's colliding. I'm used to objects handling their own behaviour code, or at the very least supplying their own state variables.
I've been watching a lot of these analyses videos even though I don't play Doom, and it's just always fascinating looking into the internals of the game. I also very much enjoyed the Serious Sam ones too! Big Serious Sam fan and I always thought something was off about the weapon speeds sometimes, but never thought it was an issue, as I never played above normal. Keep up the amazing work on these!
I've been playing Doom since the very beginning and I'm still learning more and more about the inner workings of the game, and that's 99% down to you, Decino. Your analysis series is required viewing for anyone even remotely interested in Doom. Good work.
why this video isn't supposed to be a tutorial for putting the sky texture on walls, it is actually the best "put sky texture on walls" tutorial I've seen.
So if I'm remembering right a major performance trick for Doom that allowed it to run well on computers of the era was Binary Space Partitioning. Would there be a video on that some day?
Well, that's that mystery solved. I always wondered what was causing this to sometimes happen to me back in the day. It wasn't that common, but I definitely saw it happen on multiple occasions. You'd think Id would have figured out the fix for it themselves though, it's just one line of code that's needed.
Игры
Background song now available on Bandcamp:
decino.bandcamp.com/album/pumpkin-beats-to-analyse-to
hell yeah bitch dis go hard as hell
what luck I check back to this video on the day this was created! I've been waiting to listen to some of these songs for ages, thanks!
Citing sources are for pussies. But I'm not surprised seeing as how you say zed instead of z and jibs instead of gibs.
We're so back
Oh sweet! Just the information I needed.
Now I will never miss a face-rocket again!
Honestly I just chalk it up to your luck with Doom
@@cherubswrath8820
That's a very safe bet.
hello Decino's Alter personality. nice to see you here.
>Wanting to kill a monster - face rocket
>Wanting to kill self - no rocket
>All a Coincidence
@@THEGRUMPTRUCK
Please no.
Kind of ironic how Coincident is quite often the casualty of a face rocket, then once the action is purposely performed, it won't work, poor guy
His jinx isn't that rockets always explode in his face it seems. It's actually that rockets never work as intended.
We wouldn't want to have it any other way lol
The curse of the speedrunner: live by the bug, die by the bug.
Quite a… coincidence.
His name doesn't lie
It seems like this would be a really cool trick to use in a map to jump scare a player or create a projectile poofing zone.
I was thinking the same thing but unfortunately it isn't 100% reliable because of where the projectile's origin attempts to move to.
@@decino What if we have a cyber demon that cannot move and just turns. It should shoot the rockets from same location. Then just fine tune the walls so the rockets never explode.
This would let you make a room where you can dance with the demon.
That might work with a carefully positioned turret enemy that cannot move like the Evil Eyes in Magnolia.
@@user-jp7tw3sd3x wholesome doom moment, i approve
@@user-jp7tw3sd3x That only works if the cyber has enough room to move so that he can count down his shot delay timer. Otherwise he gets stuck and does nothing.
I'm actually surprised it didn't involve the blockmap. It sometimes seems like all weird Doom behavior involves the blockmap.
That's because Blockmap handles all the important stuff like collision, so when IT fails, the entire game starts to break.
So this explains why id Software themselves were extremely careful of orientation of linedefs. It's always puzzled me why would they go to such lengths to ensure every line was placed in a specific orientation, whereas in fan maps the orientation never seemed to matter as there were no obvious downsides to do it either way (save than for line actions).
Very nice video as always, decino.
A bunch of frat boys and Chad nerds got together in the early nineties to deliver us this gem and it's still delivering.
Doom really is one of the GOATs
I laughed when decino described coincident's video as a purposely attempt to shoot a face rocket
I hope this doesn't get demonetised for saying 'poof'!
You mean... poof™©®
Poof is not a dirty word that would get censored.
@@iguana9173 I am pretty sure p**f is an insult
@@brenomordida How and why it’s an insult? :/
@@jordandino417 It's a bad word, used for insulting
I seem to recall encountering a wall that ate projectiles in Doom 2, Map 15. It always confused me, making me think there was a secret there or something. Good to know this might be the explanation.
That scream will never not be funny.
Another great analysis, gotta love those Patron names.
I felt he was overusing sound gags like that in the last analysis video, this video felt better, using just a few.
LOL the scream for Doom Guy at 5:30 XD
I was always a bit pedantic about which side of the linedef was the front. Looks like it wasn't just me being silly. :O
Almost spat my beer out when that happened. Wasn’t expecting that.
I've known about this since forever - I observed it for the first time in E1M8 (try to shoot rocket into the huge pentagram building once you've fallen down). The outer corners of the big yard in E1M8 also exhibit some unusual anomalies related to hitscan attacks (in Vanilla Doom, that is). It's like your bullets are hitting invisible walls.
A potentially interesting topic to look upon is how Doom actually renders it's graphics (at least in software mode). A lot of curious contrasts between what it did back in the day compared to modern day rendering engines.
Older versions of Doom had some pretty weird bugs and glitches. Contemporary Doomers probably don't know what the "moire effect" is, or the "tutti-frutti effect" - they could be observed fairly often in the oldest PWADs (especially the 1994 ones).
The weirdest OG software rendering weird thing I'm curious of is: if you walk over a line, you can see the line move around a little bit when your origin is close to line, which makes a ledge for instance look like it is starting to extend a bit. Since you cant look up and down you can only really see this by facing parallel with the line you are crossing. Even weirder is this also happens in Star Wars Dark Forces, which is a totally different engine!
@@MGMan37 Ah yes, I think you can observe this on the triangular stairs near the start of Entryway. I suppose engines with similar rendering routines could exhibit similar glitches. It's one of the reasons a lot of people mistakenly thought DF ran on some variation of the Doom (or Build) engine.
BTW, if a wall is very, very long, it could also sometimes shift in a weird manner, when observed from an angle. I've seen this in some old PWADs.
Especially the really weird stretching if you were able to look up or down which you can see in games like Dark Forces or even Doom sourceports if you look up or down with software rendering.
Hey, how about making a couple of tutorials about maping in doom? Especially in the complicated parts like sky walls, because It looks that you are very clear when it comes to explain, and you do it better than some people in RUclips in my opinion. I think you would do it great and specially when you add that Great editing.
And by the way this video was also great.
I'll second this, Decino would be a good teacher. I've been attempting Quake maps for Dusk but I think it might be easier to start with Doom maps.
That would be sweet.
Coincident and Decino in one video? My life is complete now.
As a mapper, thanks a lot for the video! I was wondering what was the cause of this oddity when testing my maps.
I remember fixing it by upping the ceiling sector to the same height as the sky and projectiles stopped disappearing.
Ohhhhh, THAT must be why the wall in E4M6 next to the blue skull key and the lava pit behaves the way it does! I never really looked into it, but I assumed it was blockmap-related (guess I was wrong). The Doom engine sure is weird, but it's always fascinating to learn all about its little quirks!
Side note: does P_RemoveMobj also make the firing sound cut off when the projectile disappears?
Correct.
And when I thought I knew everything about the game, Decino manages to teach something new!
Also those visuals were amazing! The quality and visual aid of these analisis videos are astonishing! :D
Well, a general mapping practice is that when you have a ledge of some sort, that the sector with lower floor is on the linedef front side; or, if they are on equal levels,that the sector with higher ceiling is on the linedef front side. This does not catch all possible cases one could map, but it's a good principle that avoids issues like these. In fact, one could argue that, because maps *could* be constructed "properly" this way, the source code need not do more than the backside check. Also because CPU cycles were kinda expensive in the 90s for all the things Doom was/is trying to do.
I love these analysis videos, as a game developer, I love the doom engine, and whenever I discover something new about it, my love for it grows even more! That's the main reason why I subscribed to this channel
Decino analysis video? Always a welcome surprise.
Solving life mysteries is always fun!
love the higher production value/attention to detail. the shrinking/enlarging shadows is a nice touch, really conveys depth.
I think this taught me more about the mechanics of sky areas than some trick I'll probably never use. Thanks anyways!
I have no idea why I love so much watching videos revealing a bunch of technical details and flaws of a game that the last time I played was 20+ years ago
I imagine the solution would be using line-line collision checks for each movement, although that gets a bit more complicated when it's no longer a point but rather a box or some other shape... I've been working on a game and have been thinking a lot about this kind of stuff. I decided on a compromised solution because a more sure way to do it using full polygon collision checks extended along the direction of motion is just very complicated and beyond me to actually implement haha.
What's the compromised solution? I have been pondering the same issue and honestly it breaks my brain.
I love how you explain stuff and put a little humor while doing it... Keep up the great work!!!
Hehe, I always get a smile on my face when I see a new decino analysis video.
playing doom for a few years shy of 3 decades now, so many things in your videos i can recall happening over the years and having it make sense now blows my mind.
thanks for another great analysis video Decino! Really appreciate the way you dive all the way into the code, and tie it back to the shown examples!
I remember Zedek (NoMac90) covered this lightly a few years back in his Doom Bugs, Glitchs and Crashes series. Cool to see it finally broken all the way down
8 minute video and dozens of hours of work for what amounts to a one line git commit fix. Great video man!
I have always been very careful about which side of linedefs was front and which back in my maps even though I never knew *why* it is important anyway. It was just of those superstition "just in case" things. This info about projectiles going poof is very interesting.
1:24
Rocket: *Hits sky ceiling*
Sky Ceiling: I command you to go poof.
Rocket: 💥
Sky Ceiling: You weren’t supposed to do that!! 😡
Hey Decino, have you ever noticed that Doom Guy uses his right hand to hold and fire weapons, but uses his left hand to fist bump demons. Is Doom Guy right or left handed? Ambidextrous? Or will we never actually know because of the way the engine mirrors 180 degrees?
I've been trying to understand the code and even though my brain just can't keep up I still enjoy these videos. Maybe it's your calm tone and voice that just works with these kinds of things.
Amazing how much can be uncovered and learned about this game even still.
Yeah I remember doing this when I was kid and it surprised me. I can't believe I had to wait 17 years to find out why it's happening.
This game never ceases to surprise me with how much weirdness there is
I wanted to be a mapper for so long...but I didn't realize how much technical work was required. Still an amazing vid btw, decino!
😊💯
Really interesting I had absolutely no idea about any of this.
I like how you go through the code but then also provide visual examples to help visualize whats happening. Well done!
So this is what decino have been doing all week - looking for dissapearing rockets in his previous videos :) Great analysis, as always!
Another great analysis video my friend and now I know why rockets and Projectiles goes POOF! in some moments especially for new doom mappers who just begin to create doom maps
Thank you Decino, I love your code reviews , I learnt a lot today :)
Well, that was interesting.
Something I don't think I've ever come across, or don't recall if it did happen.
Yeah; that oddity with not really being able to set a 'transparent' border wall makes mapping for fully outdoor areas with cliffs instead of walls rather difficult...it's one of those things that is making my vision *_Starion_* hard to realize.
An (incomplete?) fix for the origin check is to store the spawning position of the projectile. You can use this to create to determine the proper wall face. This fix might fail at extremely close distances to the target or if it hits a thin wall wedge (i.e. a very narrow pointy wall corner), but should much better than nothing.
This also wouldn't be robust with homing projectiles.
I wonder how this would work in a setup where this is just layered. So multiple sectors of broken collision. Sometimes the rocket will fall further into the wall than others. Probably makes damage super unpredictable.
Fascinating as always - I didn’t know about the exact implementation of the sky hack and its drawbacks. Also I love the cartoon sounding rocket :$
I noticed an odd bug about rocket explosions: if I manage to fire one at a pillar or a wall that have sky, sometimes the rocket explodes inside the wall, but the damage I take is the same as if the rocket were to explode outside the wall. Noticed this first in Plutonia Map 31, where I fired rockets at the pillar with the yellow key, more specifically at the steps in the spiral staircase. Basically I just run at the pillar, I fire the rocket at a certain distance before I collide with the wall, rocket explosion animation is seen just above the staircase, I take a certain amount of damage. But if I hug the same pillar wall, and fire the rocket at it, I take the exact amount of damage, even though the explosion animation is clearly outside the pillar/staircase. The same thing happens when I try on walls that have a direct sky connection. However, the bug doesn't happen inside rooms, only works when there's a clear sky above the pillar/wall. What's the deal here? Does the explosion animation and the actual rocket explosion take place in slightly different positions due to the sky hack?
Nope
I love the part about the sky wall. A rookie mistake indeed. Since I've started making my own level's and made that mistake just yesterday!
So, here's a funny coincidence: I was watching your playthrough of Hell Revealed map 19 (for reference, because I'm doing a playthrough of it myself) and notice a rocket disappeared at about 3:25. Funny, huh? You had a disappearing rocket in both HR maps 19, 1 and 2!
fantastic explanations as always.
Got one thing I've been curious about. Probably a silly thing, but I always found it interesting how the monsters always know exactly where you are once they're active. Yet you could have no clue where they are, unless the cheat that sees everything on the map is on. I'm guessing that's probably what they do to find you but I've always found it interesting as what makes them able to home in on the player so well. Lol
The conditions for this to happen do not seem particularly rare. It's surprising we don't see it more!
Thanks, decino. Very informative as always 👍
If only this were more reliable to trigger, could make for some interesting map effects, although I would guess this is what actually happens to some of the "explosions" that occur when the Icon of Sin is killed, namely the ones that spawn in the floor.
Oh, so _that's_ how that works. I initially thought I had to use no texture on those sky walls.
Love these informative videos. Always learn something new about Doom everytime 👍
In DOOM E1M8 Phobos Anomaly, I recall that projectiles shot into the sides of the points of the “star” tend to disappear. It seems we have much to learn about the still-elusive DOOM. Brilliant work as always.
And my inner Beavis and Butt-head will never tire of the reading of the ridiculous Patreon usernames.
This was a really interesting analysis video.
You have the uncanny ability of making analysis videos about glitches I just noticed. I'm pretty sure a revenant missile did the same thing today on Doom II in Spain Only's MAP29 (yes, you made me revisit this one ;) ). IF the oversight also applies to enemy projectiles, that is. If not, it was something else. Thanks for explaining!
Oh, so that's what happened in that clip that I had:
When I was playing that TNT Evilution map that contained unreachable enemies behind the wall, I shoot a few rockets into their direction, and some of their origins might have appeared behind the sky wall while doing the collision check, resulting in rockets explosion and triggering enemies. Hm... But I may be wrong again, still confused about how did I manage to avoid projectile disappearance
I actually had this problem before. I had a large city map where I got different height buildings by bringing the sky down to the wall. I left the map for 6 months and on my return suddenly my rockets were no longer working! After some testing I realized the problem and I had to go through every building and make the sky extend from the wall a bit. Since the two sectors have the same ceiling height the projectiles don't evaporate.
Then if I'm remembering correctly, I realized I had been testing on the wrong complevel and I think boom fixed this issue so all my hard work fixing my map wasn't strictly necessary.
Congratulations (again) on fifty million views on your channel. 50 Million!
Epic.
I love the sound effects when you're explaining how missiles react to walls with sky textures.
Missile hits wall - boink!
Missile disappears - pop!
:-)
I've noticed this a couple times and always wondered what was going on. Thanks for the video :)
Something really odd, whenever collision checks like these have to check for what it is that's colliding. I'm used to objects handling their own behaviour code, or at the very least supplying their own state variables.
Hurray Decino uploaded another video!!
I've been watching a lot of these analyses videos even though I don't play Doom, and it's just always fascinating looking into the internals of the game. I also very much enjoyed the Serious Sam ones too! Big Serious Sam fan and I always thought something was off about the weapon speeds sometimes, but never thought it was an issue, as I never played above normal. Keep up the amazing work on these!
These analysis videos are my favorite!
Great informational video! Keep up the hard work.
1:38 "These walls are clearly solid..."
*Me:* OK.
1:41 "Let's take a look..."
*Me:* Hey, that wall's paper-thin! How can it be solid?!
😆
New Decino video with yellow background, get the popcorn
Didn't know about this one, but still an interesting topic to cover. Thank you for these information :D
"John Carmack is a programming God" and Decino hands us a beer to hold.
Another great analysis vid.
Thanks for the information!
Awesome explanation!
I've been playing Doom since the very beginning and I'm still learning more and more about the inner workings of the game, and that's 99% down to you, Decino. Your analysis series is required viewing for anyone even remotely interested in Doom. Good work.
And yet love seeing these videos, keep it up lad
Get your popcorn ready Lads & Lasses uncle decino made a new analysis vid
Yellow background crew checking in !!
Great video as ALWAYS decino !
I will never tire of your deadpan reeditions of the patreon names, even when they are hilariously offensive.
0:44 the BFG sound effect being cut off made me laugh for some reason
why this video isn't supposed to be a tutorial for putting the sky texture on walls, it is actually the best "put sky texture on walls" tutorial I've seen.
i have immense respect for you actually reading every comment. not many content creators can say they do.
So if I'm remembering right a major performance trick for Doom that allowed it to run well on computers of the era was Binary Space Partitioning. Would there be a video on that some day?
Someday.
Watching Doomguy firing a rocket from his chest carrying what looks like an assault rifle is super weird
Great Video
19 day agonizing rectal pain sounded like a beginning to decino mixtape
I had first seen this projectile bug on E4M6 as a kid when I'm near the entrance of the structure with the blue key.
you the man decino
"in this video, Decino investigates...
the vanishing projectiles!"
lol
Another great Analytics video by Mr pumpkin man. Also probably in the code, that if rocket is by fired by Coincident -eq facerocket.
Well, that's that mystery solved. I always wondered what was causing this to sometimes happen to me back in the day. It wasn't that common, but I definitely saw it happen on multiple occasions. You'd think Id would have figured out the fix for it themselves though, it's just one line of code that's needed.
I see yellow, I click. interesting topic! I always wondered why the hell this happens in my maps... The more you know!
decinopedia never fails. 🙌🏼
This is new, I never experienced something like that while playing.
Yellow back grounds the best. Great video!