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
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.
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
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.
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.
@@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 :)
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.
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
@@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
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!
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.
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
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!
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
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.
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
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.
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.
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!
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
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.
Neat code, but uhh.. would it kill you to use more than 1, 2, or 3 letters in your variable names? Like, couldn't you just as easily have made CS and SN, COS and SIN?? Stuff like that makes it WAYYY more readable, especially when you talk so fast.
This bothered me as well. Single or two-letter variable names all over the place like this would get you destroyed during code review at pretty much every software company I've worked for.
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.
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)
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.
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; }
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.
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!
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.
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.
@3DSage when you gonna upload part 2? I love these tutorials, and i've taken the liberty of converting what i see here to SDL2 and i plan on doing it for all your videos
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
10:33 I am absolutely flabbergasted by how relatively simple 3D is in code, it definitely looks impressive. I was taking 3D engines as a given magical code in game engines that I'll never understand, but seeing it in action is amazing. Altho ofc 3D engines are more complex than this engine, but still
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!
1:30 The pillar is not a sector! It's "void" space. A sector is the puddle you stand in with the steps being the boundaries of the sector. The pillar here is floor-to-ceiling walls that are part of at least three sectors (left and right halfway stairs, and the metal floor sector behind them).
One idea is to just build a world editor directly into the 'engine'. Switch between 2D drawing mode and 3D editing mode where you can raise/lower sectors that the camera is looking at. This is how the Build engine let us edit levels. You could also choose textures while in 3D editing mode.
Tutorial: Is meant to be an example of code that is easy to understand and self-documenting. The tutorial's code: a[g].h[0]+=(TWM*200/25); ko2[g].a/=a[g].h[0]+oa; t.d[0]=bb-((TWM/2)+(ko2[g].a*a[g].h[0]*3); a[g].h[1]+=(TWM*200/25); ko2[g].b/=a[g].h[1]+ob; t.d[1]=bb-((TWM/2)+(ko2[g].b*a[g].h[1]*3); a[g].h[2]+=(TWM*200/25); ko2[g].c/=a[g].h[2]+oc; t.d[2]=bb-((TWM/2)+(ko2[g].c*a[g].h[2]*3); a[g].h[3]+=(TWM*200/25); ko2[g].d/=a[g].h[3]+od; t.d[3]=bb-((TWM/2)+(ko2[g].d*a[g].h[3]*3);
Yeah for personal code I think this is fine, but when following along with a tutorial and trying to track down your bugs, it would be helpful for the base code to be human readable.
I mean, it is kinda hard to read through, but it does require you to really understand it, if you are serious. So I'm almost half ok with it. Something that is easy to read that makes you feel like you understand it when you really don't isn't much better.
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 ;)
This video is just what I needed in the middle of evaluating if doing my own rendering engine for fun or to use an already available one. Right now I am working to convert all your code to Java (using LibGDX) to see the result. Thank you very much! EDIT: I don't know if I am missing something, but at 17:11 I had also to subtract the S[s].z1 of the surface from wz[2] wz[3] to get the correct value (lines 174 and 175). I found that problem trying to render the structure at 24:48.
Hi 3DSage, can't wait for part 2! One question, why do you use radians/degrees instead of vectors? Vectors make algorithms such as DDA more understandable, and IMO are alot nicer than a float which under/overflows (you can rotate a vector quite easily with trig)
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
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!
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 :)
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.
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
Such a great video, the math, editing, attention to detail. Part 2 will be a must-watch!
I got clickbaited, thought cat would explain how to program doom
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
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!
looking forward to you tackling Quake
Im playing it on half speed and frequently pausing. Simple and complicated at the same time, surely truly fascinating. Very cool video!
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.
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!
Cool, I wish I had such videos in the 90s.
This is just the video I've been looking for for years.
My cat also gives always the "Got it? Ok." look. :)
0:22 decino has alot to say about Doom's engine. And he's yet to run out of steam or yellow backgrounds.
Using the period/comma keys for strafing. Throwback!!!
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!
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.
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 :)
You know it really helps when you have unexplained functionality and magic constants in your code tutorial. Very cool.
A NEW 3DSAGE VIDEO!!! If only i got the darn notification
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.
This is the kind of content youtube is for. You sir have earned my subscription. I'm glad to find you
Awesome! Thank you! 😎👍
PLEASE MAKE A PART TWO THIS IS SO GOOD
I am working on it now :)
@@3DSage thank you so much
This video was a lot of fun, I really learned a lot. I can’t wait to try it out myself.
Hell yeah! I was excited to take my raycaster even further, but this is even better!
I'm still considering revisiting the raycaster with a few more fun ideas I have but I had to share this tutorial with you all too!
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.
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!
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
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
For those struggling to read “digerible”, it means “digestible” in Spanish
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
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! :)
this is so amazing that we have tutorials like this FOR FREE! teaching me better than any bootcamp would
Your tutorials are appreciated. You explain everytNice tutorialng so simply and show the fundantals of producing. Many people and myself thank
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.
Just managed to implement the first line render in Rust; it's brilliant how well you explained everything.
God damn this is real content youtube needs, awesome channel btw
Thank you! 😎👍
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! 😎👍
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
Also can't wait for part 2!
I knew cats were the best at purrgraming, us plebs cannot keep up with those lightning paws.
This is great! Looking forward to future videos in this series. I too have a love of these old engines
Thank you! :)
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.
Neat code, but uhh.. would it kill you to use more than 1, 2, or 3 letters in your variable names? Like, couldn't you just as easily have made CS and SN, COS and SIN?? Stuff like that makes it WAYYY more readable, especially when you talk so fast.
He's going for that "written in 1979" aesthetic.
This bothered me as well. Single or two-letter variable names all over the place like this would get you destroyed during code review at pretty much every software company I've worked for.
(!(!(!(!(!(!(!(!(!maybe)
I agree.
Very often locals take up more words than they deserve
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.
These videos are amazing. The process is intimidating, but you make it seem achievable and fun. I'm excited to see more.
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)
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.
I am so excited for part 2
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; }
Heck yeah, new series! Your videos are always super good and I'm excited when they come out!
I cannot believe what I am seeing it with my eyes! LOOL TY SO MUCH!
This is awesome, can't wait for the next one :)
Thank you!
I cannot wait to follow along with these on my arduino console!
Nice! I hope to see that too!
every minute worth it... gracias amigo!
de nada mi amigo
Amazing! Part 2 let’s gooo!
Yes! I love it when you upload!
I just stumbled upon this channel, I am a chronic Civvie-11 watcher, and I'm super excited to see all these type episodes
1:03 Finnally something in one of these videos that I can actually do.
perfect timing! Seriously, love this.
Ahh, finally. Proper programming in a youtube channel. You made my day.
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.
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!
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.
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.
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 like your work! Can't wait for part 2
I’m ready for part 2! Great video and keep up the awesomeness!
YeEees! Doom game. Thank you. i wait part 2!
@3DSage when you gonna upload part 2? I love these tutorials, and i've taken the liberty of converting what i see here to SDL2 and i plan on doing it for all your videos
SIUUUUU, thanks to you i'm pretty much understanding C from nowhere lol
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
Really respect and appreciate people like yourself who give their ti and expert knowledge so others can benefit and enjoy soft
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! ❤️
You don't know how much I've been waiting for this.
10:33 I am absolutely flabbergasted by how relatively simple 3D is in code, it definitely looks impressive. I was taking 3D engines as a given magical code in game engines that I'll never understand, but seeing it in action is amazing.
Altho ofc 3D engines are more complex than this engine, but still
1:00 Looks like I came fully prepared for this video.
Lol
Wow, great walkthrou of the process 👍
Thanks for sharing your expirences with All of us👍😃
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 part 2!!
1:30 The pillar is not a sector! It's "void" space. A sector is the puddle you stand in with the steps being the boundaries of the sector. The pillar here is floor-to-ceiling walls that are part of at least three sectors (left and right halfway stairs, and the metal floor sector behind them).
TNice tutorials might just be the first motivational comnt ive ever seen on a tutorial vid. ga thanks bro
1:06 - DONE!
I didn't even know it to begin with!
One idea is to just build a world editor directly into the 'engine'. Switch between 2D drawing mode and 3D editing mode where you can raise/lower sectors that the camera is looking at. This is how the Build engine let us edit levels. You could also choose textures while in 3D editing mode.
You're making the world a better place. Thank you, kind human.
Tutorial: Is meant to be an example of code that is easy to understand and self-documenting.
The tutorial's code:
a[g].h[0]+=(TWM*200/25); ko2[g].a/=a[g].h[0]+oa; t.d[0]=bb-((TWM/2)+(ko2[g].a*a[g].h[0]*3);
a[g].h[1]+=(TWM*200/25); ko2[g].b/=a[g].h[1]+ob; t.d[1]=bb-((TWM/2)+(ko2[g].b*a[g].h[1]*3);
a[g].h[2]+=(TWM*200/25); ko2[g].c/=a[g].h[2]+oc; t.d[2]=bb-((TWM/2)+(ko2[g].c*a[g].h[2]*3);
a[g].h[3]+=(TWM*200/25); ko2[g].d/=a[g].h[3]+od; t.d[3]=bb-((TWM/2)+(ko2[g].d*a[g].h[3]*3);
Yeah for personal code I think this is fine, but when following along with a tutorial and trying to track down your bugs, it would be helpful for the base code to be human readable.
I mean, it is kinda hard to read through, but it does require you to really understand it, if you are serious. So I'm almost half ok with it. Something that is easy to read that makes you feel like you understand it when you really don't isn't much better.
the code is not that complicated lol
looks cool! might try it tommorow
Stop procrastinating and start now!!
@@HexOverride i would never
@@SDFTDusername ):
Fantastic video, rarely does someone actually explain how the math works.
I did my best to explain so thank you!
I just tried this method and it really works perfectly for me. Thank you.
No way! THIS IS INCREDIBLE
The best content I've seen on the subject so far! Please continue with the series!!!
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 ;)
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! :)
This video is just what I needed in the middle of evaluating if doing my own rendering engine for fun or to use an already available one. Right now I am working to convert all your code to Java (using LibGDX) to see the result. Thank you very much!
EDIT: I don't know if I am missing something, but at 17:11 I had also to subtract the S[s].z1 of the surface from wz[2] wz[3] to get the correct value (lines 174 and 175). I found that problem trying to render the structure at 24:48.
INCREDIBLY CLEAR tutorial! Wow! Very inspiring! Thank You!
Hi 3DSage, can't wait for part 2! One question, why do you use radians/degrees instead of vectors? Vectors make algorithms such as DDA more understandable, and IMO are alot nicer than a float which under/overflows (you can rotate a vector quite easily with trig)
Hi, do you have an example of how to do it with vectors? I'm a beginner and I was curious. ty in advance