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
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 :)
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.
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.
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!
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
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
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
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
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.
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.
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
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 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.
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)
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.
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.
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!
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
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.
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
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
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.
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 ;)
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 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; }
great video! in some ides you can select blocks of code and press tab to indent them all at once, and shift tab to remove indentation. might save you some keystrokes! looking forward to seeing more, keep up the great work!
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.
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
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
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 :)
I got clickbaited, thought cat would explain how to program doom
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.
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!
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
You know it really helps when you have unexplained functionality and magic constants in your code tutorial. Very cool.
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!
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!
Im playing it on half speed and frequently pausing. Simple and complicated at the same time, surely truly fascinating. Very cool video!
0:22 decino has alot to say about Doom's engine. And he's yet to run out of steam or yellow backgrounds.
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 is just the video I've been looking for for years.
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 NEW 3DSAGE VIDEO!!! If only i got the darn notification
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.
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.
1:03 Finnally something in one of these videos that I can actually do.
This video was a lot of fun, I really learned a lot. I can’t wait to try it out myself.
looking forward to you tackling Quake
Cool, I wish I had such videos in the 90s.
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.
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
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.
Using the period/comma keys for strafing. Throwback!!!
1:00 Looks like I came fully prepared for this video.
Lol
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.
This is the kind of content youtube is for. You sir have earned my subscription. I'm glad to find you
Awesome! 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! 😎👍
The most important: you DO put the opening braces at new lines, I love this!
this is so amazing that we have tutorials like this FOR FREE! teaching me better than any bootcamp would
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
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 :)
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 am sure you are fed up of answering this question, when is part 2?! Amazing job of explaining it all.
My cat also gives always the "Got it? Ok." look. :)
Your tutorials are appreciated. You explain everytNice tutorialng so simply and show the fundantals of producing. Many people and myself thank
Just managed to implement the first line render in Rust; it's brilliant how well you explained everything.
Heck yeah, new series! Your videos are always super good and I'm excited when they come out!
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.
This is great! Looking forward to future videos in this series. I too have a love of these old engines
Thank you! :)
I am currently trying to port this to scratch, made 75% of this video and it works!
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
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)
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.
Ahh, finally. Proper programming in a youtube channel. You made my day.
PLEASE MAKE A PART TWO THIS IS SO GOOD
I am working on it now :)
@@3DSage thank you so much
These videos are amazing. The process is intimidating, but you make it seem achievable and fun. I'm excited to see more.
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.
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!
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
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
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
God damn this is real content youtube needs, awesome channel btw
Thank you! 😎👍
Finally! Been asking for this one...
Your content is wonderful btw, and I think you definitely deserve the growth you're getting!
TNice tutorials might just be the first motivational comnt ive ever seen on a tutorial vid. ga thanks bro
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
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.
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! :)
I’m ready for part 2! Great video and keep up the awesomeness!
I cannot wait to follow along with these on my arduino console!
Nice! I hope to see that too!
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! ❤️
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 ;)
your way of structuring code scares me
I cannot believe what I am seeing it with my eyes! LOOL TY SO MUCH!
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!
I knew cats were the best at purrgraming, us plebs cannot keep up with those lightning paws.
You're making the world a better place. Thank you, kind human.
Really respect and appreciate people like yourself who give their ti and expert knowledge so others can benefit and enjoy soft
You don't know how much I've been waiting for this.
I just stumbled upon this channel, I am a chronic Civvie-11 watcher, and I'm super excited to see all these type episodes
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!
Wow, great walkthrou of the process 👍
Thanks for sharing your expirences with All of us👍😃
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.
This is some cool stuff, 3DSage. It's amazing how far games have come. I did half the levels for Duke Nukem 3D, btw 😎
The best content I've seen on the subject so far! Please continue with the series!!!
I just tried this method and it really works perfectly for me. Thank you.
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!
This is incredible. Watched some of your other videos too. Love it all. Glad I found your channel!
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).
Wow, what a neat tutorial! Gave me the impression that this stuff is accessible for me, too! Thank you so much!
I like your work! Can't wait for part 2
Yes! I love it when you upload!
perfect timing! Seriously, love this.
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.
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 am so excited for part 2
INCREDIBLY CLEAR tutorial! Wow! Very inspiring! Thank You!
great video! in some ides you can select blocks of code and press tab to indent them all at once, and shift tab to remove indentation. might save you some keystrokes! looking forward to seeing more, keep up the great work!
It's fun for me but I will show the tab trick in part 2!
Amazing! Part 2 let’s gooo!
Fantastic video, rarely does someone actually explain how the math works.
I did my best to explain so thank you!
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.
2mins in and I already know I'm going to have a fun time. Thank you RUclips algorithm. Subbed
This is awesome. Also, I love (I assume) your cat
Holy shit, this is so well explained. The visuals are top notch. Thanks for this.