Let's Program Doom - Part 1
HTML-код
- Опубликовано: 8 июн 2024
- I might be the most excited about this video. I really wanted to learn how the original Doom game engine works. l spent a long time learning the basic concepts but created the code myself from scratch and how I wanted to design it. You can follow along or convert this code to any other programming language since I kept it simple in C that draws a pixel at x and y coordinates.
Let me know if you enjoy this series! Thank you for all your great ideas and I hope to see what you make from this tutorial series. Send me a link so I can share it in part 2!
How to install OpenGL: • Install Dev C++ and Op...
Download my starter code here: github.com/3DSage/OpenGL-Star...
Starter code: 02:28
Drawing dots: 05:52
Drawing a line: 10:38
Drawing a wall: 11:51
Sectors: 15:40
Surfaces: 20:31
Raycaster Part 1: • Make Your Own Raycaste...
Raycaster Part 2: • Make Your Own Raycaste...
Raycaster Part 3: • Make Your Own Raycaste... 
Игры
![How Quake's software renderer ELIMINATES overdraw [⚠️ flashing images]](/img/1.gif)
I can't tell you how much I've enjoyed this tutorial. It was clear and to the point, but thorough and at no point did you skip/handwave anything important or get too bogged down on details on the basics. Really well done.
The demo videos showing the concepts were really clear
That means a lot to me. That is what I was hoping to hear and accomplish. Thank you!
Without any sort of learning curve across your tutorials you've nailed the perfect tutorial video format. May I ask how old you are? You sound fairly young (I'm forty, so anyone high school or college age is a kid to me), which makes the accomplishment doubly impressive. I wish something like this was available when I was a kid, but all I had were incomprehensible textbook-like volumes and 14.4 Mbps dial-up internet so I couldn't wrap my head around this sort of thing. Excuse the geriatric rambling. Good work, sir, and I'm looking forward to the follow-up videos.
@@LarpingGecko3851 16, you are right, i am young.
one thing i love about your videos is how you keep them language agnostic. you specifically mentioned it this time, but a while ago i followed your raycaster series in js and ended up making a multiplayer arena shooter that could run on my school computers and played it in class with my friends
Wow, that's amazing! Could you share the source code please? I am also learning to make a shooter game and I could use such a thing
Boss!
Thats actually really cool. Congrats my guy!
Shit, you a real G
instant cool kid
1:30 Sectors were what gave me the most trouble when learning to make Doom WADs. Turns out you're not creating walls when you define a sector, you're actually defining the empty space. So making a room in Doom isn't so much about building the wall but rather you're carving out a space from a chunk of...solid stuff.
Yes and if you screw that up, you wind up with the hall of mirrors glitch.
@@SmallSpoonBrigade HOM is the result of not applying a texture to a linedef that borders void. While that can happen as a result of making a mistake when setting up a sector I was able to avoid that by using Edmap. It created a sector with a set wall, ceiling and floor texture, floor height 0, ceiling height 128 and brightness set to 128 as defaults. I just had to go in and change them to whatever I wanted after making the sector or I could change the default settings before making a large group of sectors. Edmap was easily my favorite after trying the others.
@@mr.pavone9719 The last time I tried that was a couple decades ago, and I was a bit on the busy side to get far with that. I'd expect that the tools improved greatly since the mid-90s.
The way Doom handles level geometry is some next-level 💩.
First of all, each sector is a kind of prism. That's why everything is either horizontal or vertical. The floor is the inside of the base of the prism, and the ceiling is the inside of its top. Back then, PCs weren't powerful enough to do real 3D, so id had to make 2d look like 3d. In this case, both the walls and pillars of a room are prisms: polygons where each side is a wall, and the difference between the pillar and the entire room is that the top of the pillar is drawn if the player is _above_ it and the top (ceiling) of the room is drawn if the player is _below_ it.
IDK how it's habdled inside the WAD, but I wouldn't be surprised if one had top > bottom and the other top < bottom, and the order of the vertices reversed. In that case, the render loop would treat both equally but with very different results due to the order. (3dSage already demonstrated that the _for_ loops skip over the "back-to-front" walls by default; it took extra work to draw them no matter where they were facing.)
@@mr.pavone9719 There are other ways to end up with HOM's, although that was the most common if it was the fault of the mapper. Missing lower or upper textures on sectors that weren't "bordering the void" - a deep pit in the middle of room missing a lower texture would do it when you fell on it.
But there's more. At least two I can come up with:
1) With the OG engine - and I believe even chocolate doom has fixed this - there were hardcoded limits in the engine. One of them was number of two-sided linedefs in view at once. Heretic had even lower limit, which I found out when I *really* had to cut down detail level down from what I was used to with DooM. Probably to optimize it to use less memory, that's my guess.
It's hard to bump into in original levels amount of detail... but when I started playing with ceiling lights that created a circle of light - using enough linedefs to make it look smooth circle, and not just polygon (which meant like 32-64 lines for one light circle), and on top of that I wanted a smooth-transition between light levels, so if I had 256 units wide corridor with light level of 96, and light circles that were 128 units wide with light level of 192, I would create 2 or three slightly bigger circles around the innermost, and set those sectors light levels to values between 96 and 192. And when I tested it, I would receive a smacking with HOM. In worst areas I had to change the "circles" to be made of just 16-linedefs. With heretic I couldn't do even one such light source in room with quite little detail...
And once the source was released and BooM source port became first I remember to remove this limitation alltogether, I revisited all those levels and added the detail level I was originally aiming for back there :D
2) ...and this one is not the level creators fault. As you likely remember, you would always need to rebuild the maps BSP-tree after editing before you could test it. And some BSP builders were better than others - the one named simply BSP was considered the best, and I don't remember ever getting HOM's from badly done job from it. But then, it wasn't the 1st version of the application I was using, it probably wasn't as good from the start.
But with big, complex and detailed levels this could take time. And you didn't want to wait between editing and testing. That's what I used ZenNode for - it did the job sometimes in fraction of the time it took from BSP to do it; perfect for testing quickly, but not so much always getting it right. So when you had a finished level, you (or I did at least) built it using BSP ;p
I came to like DETH (which was short for Doom Editor for Total Headcases), which was probably one of the more popular ones in the end of 90's, as it was the first editor to have a fork that supported ZDooM's extended flags/parameters to objects, linedefs and sectors - the fork was called ZETH. I'm getting back to mapping, and I think that to work with the modern source ports, I'll have to check modern editors (besides, I really don't want to run in DOS environment - even if it's really easy with DOSBox just to use my old fav), and as the source ports have evolved I think the editors must have been written to work with old map formats and to support new extended formats as well. And I think there are ones that actually combine other resource editing and level editing into one complete suite.
That was a lot more said than I planned to - sorta turned into reminiscing, I could write a lot more on DETH. But let's just say that it too put a default middle texture automatically on any 1-sided linedefs. What I loved most about it that while it had some automated features, such as creating a polygon around point that was of size you wanted and made of as many linedefs as you wanted, and most crucial, selecting a bunch of linedefs joined together and auto-aligning the textures, it allowed doing everything as manually as you wanted - even allowing inserting multiple overlapping vertices and linedefs at same exact place, which was useful for certain visual tricks :p Also a requirement for the special effects, like fake 3-D bridges, etc. that turned certain bugs in the engine into features ;p Btw, the 3D bridge works great as long as nothing can try to go under it while something else goes over it, tee-hee... Ok, seriously, that's enough for this message (*slaps himself around a bit with a large trout*). Thumbed up your comment :)
A cat is teaching me programming, we truly live in amazing times.
Meow 😺
thats not a real cat silly its just a picture
explain the first answer then@@ing_frantisek_mohykan
@@ing_frantisek_mohykan did you get the joke? 😐
@@spartanbravo1482 this guy literally thinks the video was made by a cat
oh my god, thank you so so much. For the longest time I was trying to find someone programming a doom-style rendering engine so that I could better understand how it works, thank you for making this!
I felt the same way. I worked really hard to make my code super simple and clean and easy to follow while also creating 3D animations to visually help. I'm glad you liked it!
@@3DSage Im honestly surprized at how well you explained it so it isn't c specific, I feel super comfortable just taking this same information and implementing it in any other language.
Yes i also was waiting for bsp in 3D graphics tutorial about 3 months and now i am very happy that this video realesed!
Such a great video, the math, editing, attention to detail. Part 2 will be a must-watch!
A month ago I started my own retro 2d first person raytracing game engine, using your two year old raytracing tutorial as a springboard, but figuring everything out on my own as best I can. I'm very excited to see you're back with more! I don't want to spoil the exploratory process for myself, so it'll probably be many months before I watch this video... but I can already tell from skimming that it's really good!
This is the most interesting tutorial i've seen on youtube for the last 10 years. Your explanation is clear and well organized. The only thing i would suggest is, while you are explaining the geometrical logic behind the pixel rendering functions on the program, it would be nicer if you could in parallel show on the screen a small graphic with the vectors so we can follow your thought on real time.
This is great man, thank you for your videos!
YOU are a legend sir, keep up with these impressive tutorials. You are clearly knowledgeable and capable of explaining complex concepts in a simple way that everyone can understand
I'm glad to hear that since I spent a long time figuring out how to explain everything in the best way!
@@3DSage It shows - I've rarely seen anything about this specific subject explained in this easy to understand kind of way; I mean, I've seen pretty good, but this is quite a lot better - it's a skill of it's own to do that :) One that I'm not nearly good enough at :D
While this is not actually how Doom works, this video is full of valuable insight and techniques, and very well explained. Thank you very much.
0:22 decino has alot to say about Doom's engine. And he's yet to run out of steam or yellow backgrounds.
Some of the best programming tutorials I've seen, and its covers something I straight up haven't really seen before - cant wait for more! (especially the potential quake series)
Im playing it on half speed and frequently pausing. Simple and complicated at the same time, surely truly fascinating. Very cool video!
I'm a lowly JavaScript programmer and yet I still love watching these videos. Makes you wonder what kind of genius a guy must be to come up with this. It's like a whole new level of existence.
yeah they're definitely on a different frequency than us
I just stumbled upon this channel, I am a chronic Civvie-11 watcher, and I'm super excited to see all these type episodes
These videos are amazing. The process is intimidating, but you make it seem achievable and fun. I'm excited to see more.
Heck yeah, new series! Your videos are always super good and I'm excited when they come out!
looking forward to you tackling Quake
Please continue this series, really great to see this content and the effort you've put in. So little information out there on building a Doom like renderer from scratch like this. Lots for ray casters, but not sector and wall type engines like this
Agreed.
I'm wanting to know more on this for I'm wanting to develop a doom/build inspired engine with some special features.
This video was a lot of fun, I really learned a lot. I can’t wait to try it out myself.
You can tell there is some inspiration here from that famous video by Bitsqwit where he makes a similar project, but slowed down to a digerible rate and with insanely detailed explanation acompained by good narration and clean code. This is definitely extremely high quality content and I am very excited to see more of it
Your tutorials are appreciated. You explain everytNice tutorialng so simply and show the fundantals of producing. Many people and myself thank
This is the kind of content youtube is for. You sir have earned my subscription. I'm glad to find you
Awesome! Thank you! 😎👍
A NEW 3DSAGE VIDEO!!! If only i got the darn notification
this is so amazing that we have tutorials like this FOR FREE! teaching me better than any bootcamp would
Finally! Been asking for this one...
Your content is wonderful btw, and I think you definitely deserve the growth you're getting!
Thats what i have been doing right now, just after your video explaining 3d, that you just need to divide x and y by z, now i just need to make the binary space partitioning and stuff, thx
i am with the project opened right now, this is crazy!
This is just the video I've been looking for for years.
This is incredible. Watched some of your other videos too. Love it all. Glad I found your channel!
OH NO THIS SERIES JUST STARTED! It's amazing, and I was looking for the next video, when I saw the date. Looking forward for the next one! :)
Thank you so much for creating this! I don't know any actual coding languages but so far I've been able to make this engine in scratch.
Using the period/comma keys for strafing. Throwback!!!
Now I know why the Id crew customized their own STL libs (at least for doom 3). The amount of of recursion and iteration that would have to be done to keep this game going at speed is just insane.
Thank you for the breakdown!
DDUUUDE THANK YOU VERY MUCH!! I seriously have been wanting a tutorial like this! This literally made my day!
Edit: Also, CUTE CAT!!
Thank you for saying that!! That makes my day too. My cat made me sign a contract so I have to add him these videos :P
go enjoy 1 fps 240x120 graphic programming expirience
Cool, I wish I had such videos in the 90s.
Very well made video! I have ported myself doom to several embedded platforms quite a while ago and this video reminded me those good old times! ❤️
The best content I've seen on the subject so far! Please continue with the series!!!
My cat also gives always the "Got it? Ok." look. :)
Ahh, finally. Proper programming in a youtube channel. You made my day.
I’m ready for part 2! Great video and keep up the awesomeness!
some tips for those porting to SDL2 -- coordinate origin is top left instead of bottom left. So in pixel() be sure to calculate a new y, which is window height minus y value. For pixel scaling I just multiplied x,y values by 4. I used SDL FillRect to draw the pixels (with height and width as pixel_scale value). Oh, and lastly be sure to make your window height SH * pixel_scale + pixel scale, same with width.
That's it, this is the perfect style of video for a coding video. Every one from now on should copy this video for making their programming videos.
Thanks, this is a great video! Goes over everything efficiently but effectively. Seeing the code built in (mostly) real time makes me realize that things like low-level 3D graphics are actually within my reach as a programmer.
These days, when John was writing the original game, it would have been much harder as the resources to run the code were a lot tighter. Other programmers had written similar games earlier, Ultima Underworld was a good example, but it didn't do anywhere near as well n terms of the actual engine.
Well, yeah, I mean on modern hardware of course. It just never occurred to me that I could write a renderer or rendering code.
This was great, very clear yet deep tutorial. This is a well deserved sub !
perfect timing! Seriously, love this.
INCREDIBLY CLEAR tutorial! Wow! Very inspiring! Thank You!
You don't know how much I've been waiting for this.
Wow, what a neat tutorial! Gave me the impression that this stuff is accessible for me, too! Thank you so much!
Been watcNice tutorialng your vids for a good few weeks now, learning new sNice tutorialt each day. my worksoftow has improved so much since watcNice tutorialng
This is great! Looking forward to future videos in this series. I too have a love of these old engines
Thank you! :)
Your videos have inspired me to change to OpenGL
You can if you want or I kept the code simple so you can port it to another program or language as long as you can draw a pixel with color :)
Instant subscribe for this alone, but then I went on your channel and saw all your work on Gameboy advance engines?? Truly incredible, I'm sad it took me so long to find this channel
Hey thank you so much!! Yes the GBA was very important to me as a kid and now I'm so happy I can program my own games on the system! Thank you for the sub!
TNice tutorials might just be the first motivational comnt ive ever seen on a tutorial vid. ga thanks bro
This is really cool. I've always wanted to get into game engine programming, but it's got a pretty high difficulty curve. This is a great starting point to understand the basics of graphics rendering.
I like your work! Can't wait for part 2
Have to admit this is a very nice start to this series, I am more interested in your BSP implementation but this was a good intro and well presented.
Just managed to implement the first line render in Rust; it's brilliant how well you explained everything.
Wow, great walkthrou of the process 👍
Thanks for sharing your expirences with All of us👍😃
This is some of the best content on youtube. Thank you. I'm gonna give it go! Bring on the next episode.
I actually have to thank you significantly In your code! At first I wasn’t able to understand any of it, even when listening to you explain it. But your code and your explanation were just specific enough for me to put into an ai to explain it further and you won’t believe how well the open chat ai explained transformation projection and interpolation. I can’t wait to see how you handle slopes in your code!
Hmm, I'd like it as well, if he does go into slopes, but I have to remind you, DooM didn't have sloped floors or ceilings. There are modern source ports that add support for that as well, but the original engine did not have them - the Build engine (used in Duke3D) did have them, but DooM didn't.
Awesome tutorial, awesome editing, awesome narration. You're amazing dude
Yes! I love it when you upload!
Really respect and appreciate people like yourself who give their ti and expert knowledge so others can benefit and enjoy soft
This was great! Excited for Part 2.
This is awesome! As someone who has loved DooM, and it's engine (and all the games created with it) and modding - from mapping to extending the engines features (since the source code was open sourced - before that, hacking the engine with tools like DeHackEd), but never myself have modified it's code or even had much knowledge on coding 3D rendering engines, I really like this video - it makes it easy to grasp, and I love being able to understand it from this point of view; finally.
I'm going to watch and save to special playlist all these videos, including your previous and what comes next ;)
I just tried this method and it really works perfectly for me. Thank you.
Now this, _this_ , THIS is what I was looking for! Interesting stuff! 👍🏻
You're making the world a better place. Thank you, kind human.
24:45 Do I hear a GBACAD being made? (If so, I will totally drop PicoCAD as soon as GBACAD releases, I need more polys to render and building entire shapes seems a whole lot easier (and more visually appealing)) Also, I might try and host a GBACAD jam or something just to encourage more people to use it.
This is awesome, can't wait for the next one :)
Thank you!
Awesome!!! Easy to follow and with a lot of useful information. I am half-way through it and I've already written 15 pages with notes on my notebook. I am also adapting it to SDL2 as I follow it along. I'll share it once I complete the first part. :) Many thanks!
God damn this is real content youtube needs, awesome channel btw
Thank you! 😎👍
every minute worth it... gracias amigo!
de nada mi amigo
wow, great video again! I already peeked at part 2 and hope you are still considering a follow-up about the BSP technique. I already saw some great tutorials about that but I would love to see it happen in Doom Part3 🙂
Btw: I like your very basic approach to utilizing language features. It is easy to see what you're doing and should also be easy to port to other languages while leaving room for me to come up with my ow vector/matrix/angle classes that add another level of understanding, as I could just type in the statements you show me but in order to apply abstract vector math I have to really see whats going on here. I like that! Merry Christmas, happy festivus and happy new year!
Can't wait for the next video, It's amazing so far.
Love the videos mate, can't wait to see the one for a QUAKE style engine!
That's going to be a lot more complicated, a Build style engine would probably be the next logical step after this. It wasn't truly 3D, it used some weird warping to make it seem like rooms were on top of rooms, even though they weren't.
@@SmallSpoonBrigade I believe in the video he mentioned he'd be eventually moving onto a QUAKE style 3D engine
That final "level" image was and amazing show off.
That took a really long time to make haha. I will make a better level editor for part 2!
I missed you so much! I thought this was the end of the 3D game in C/OpenGL, and you come back with a Doom game-engine.
Holy shit, this is so well explained. The visuals are top notch. Thanks for this.
Also can't wait for part 2!
I cannot believe what I am seeing it with my eyes! LOOL TY SO MUCH!
I have no idea why i’m so curious about how Doom/Daggerfall/DukeNukem worked cus i’m not exactly a programmer but i’ve looked up a few videos already about this and this is by far the one that really, truly explains what’s happening.
Amazing! Part 2 let’s gooo!
I used the code I learned from your Wolfenstein 3D-like raycaster engine and changed it up to make a Doom-like engine myself!! It's not nearly as optimized, technically advanced, clipping doesn't work 100%, it doesn't have a distance-sorting algorithm yet, and I don't fully understand how I made the Z-calculus work, but I'm incredibly proud of it!
Hey I would like to see that! I am impressed and honored that my tutorial could help you in some way! 😎👍
I appreciate your work. A lot has been said about the Wolfenshtein 3D engine, how it works and even how to make one. But for Doom engine i couldn't find any information. Its a bit hard to keep up with your code, but you're the first one i'm aware of to do that, so its a lot better than nothing.
I couldn't find a simple and well explained walkthrough so I decided to make my own version. It is a lot to teach and I don't want to go too slow but you can always pause and rewatch to help absorb the concepts.
PLEASE MAKE A PART TWO THIS IS SO GOOD
I am working on it now :)
@@3DSage thank you so much
i've been waiting for something like this! thank you!
No problem! :)
This is all absolutely wonderful
I am so excited for part 2
I've been working on my own doom-style game engine for a bit now, but I did move to pure-GPU rendering. Although software rendering is really cool, my code was just too annoying to work around. This video is making me wanna rewatch Bisqwit's Doom-style 3d renderer video
2mins in and I already know I'm going to have a fun time. Thank you RUclips algorithm. Subbed
I don't think I'll be following along as this is too big time for me (for now at least), but this looks like a very promising series. You got my sub! Keep up the great work!
Thank you for the sub and watching my video!
YeEees! Doom game. Thank you. i wait part 2!
Started taking the time to follow this tutorial. Going to try and adapt this to work with full 3d in openGL to try and learn how it works. Will update on progress.
Nice! Sounds exciting and yes keep me updated! :)
I can't tell you how cool the things you make are.
That means a lot to me so thank you!
@@3DSage Badge of Honor!
Fascinating! I've been using BSPs for years in Hammer and Unreal and didn't even know what it stands for.
That's why people shouldn't make such regular use of abbreviations, acronyms and initialisms. Sure, it does make typing faster, but it does rob the phrase of it's descriptive power to those that aren't already knowledgeable.
it's like another language you're speaking lol
so happy you people exist cuz the original game is amazing and all the mods just make it better and basically never ending
No way! THIS IS INCREDIBLE
Great video, I love how you built everything out step by step and didn't just magically make something happen. I think the only thing I would wish to see on this is better variable naming. What is wx? What is s? Why not just write wall_X or surface. Just makes it cleaner imo. Great stuff regardless.
One thing I would suggest is to learn the power of switch. Enumerate all of the keys as single bits and or them together, then switch ( key ) { case KEY_A: /* do something for just a */ break; case KEY_A | KEY_MOD: /* do something for a with a modifier */ break; case KEY_A | KEY_W: /* do something for a+w */ break; default: /* do something when the user presses a key or combo we don't recognize */ break; }