Ancient DOS Games Filler #48 - Is the Doom Engine a Raycaster? is online!

So yeah, back in my Heretic episode I mentioned that the Doom Engine was a raycaster. I didn't actually look this up ahead of time or anything as I figured my ancient knowledge from the mid 90s gleamed from books and level authors was accurate enough. Even nowadays though, people still argue about this, though the people arguing that Doom is a raycaster is the losing side because... well... the source code kinda proves it's not. :P

Thus I decided rather than just correcting myself with a paragraph, I'd do an entire video on the topic. Mind you, I had difficulty trying to figure out ways to show what I was talking about, so instead I just opted to show browsing Doom levels in Doom Builder 2. Mind you, I did come across one missing wall texture which I was able to demonstrate as how the visplanes just generate right into them. :B

Also cleared up a couple other misconceptions along the way, such as the difference between raycasting and raytracing, as well as the notion that the presence of BSP Trees precludes the ability to raycast.

Also noticed both Clint and Roses have gone on vacation now, so those viewing their stuff early on Patreon are going to have to wait a bit for new videos. I'm not on "vacation" (more like "Minimal Work Mode") until the last two months of the year so I'll still be doing my usual videos and such! ;)

You're right that lots of misconceptions about Dune II are floating around, but the recent research work carried out by the guys who reverse-engineered the game has helped clarify most if not all of the issues. This information is however scattered across the FED2k Forums. Some was also available at the OpenDUNE forums but those are apparently down after the project moved to GitHub.

Gemini000 wrote:

For instance, part of the reason I stuck with v1.0 is because supposedly, the feature allowing one unit to follow another was broken by the update to 1.07, but then I found I couldn't get this aspect working anyways.

IIRC the team stuff works similar in both versions. You can indeed have one unit follow another, but this will only happen until the "follower" unit reaches its destination.

Basically, you pick a unit, order it to move and select another unit as the target. If you then order the target unit to move (or the target unit is already moving), the first unit will move after the target. However, once the following unit reaches the target and stops, its orders will be reset and it will no longer follow the target.

I have no idea if this is a bug or intended behaviour (likely a bug though), but in the Sega Genesis/Mega Drive version the "follow mode" is implemented as described in the manual.

Gemini000 wrote:

Also, I'm not very good at strategy games and there's no difficulty adjustments in the game (well, unless you count changing the speed given the changes that causes to some of the unit stats) so I figured a higher version might be harder for me to succeed and get anywhere with, thus why I didn't patch it up.

Well, v1.0 is indeed easier a bit because the AI very rarely rebuilds its structures, whereas in v1.07 it regularly does so. And unlike C&C you cannot prevent it from rebuilding by placing a unit or your own structure as an obstacle.

*Watches Kris' filler video "Is the Doom Engine a Raycaster?"*

Mmmhmm...

Mmmhmm...

Mmmhmm...

....Yeah, I understood some of those words. 😉

switchblade wrote:

....Yeah, I understood some of those words. ;)

Some is better than none! ;D

switchblade wrote:

*Watches Kris' filler video "Is the Doom Engine a Raycaster?"* […]
Show full quote

*Watches Kris' filler video "Is the Doom Engine a Raycaster?"*

Mmmhmm...

Mmmhmm...

Mmmhmm...

....Yeah, I understood some of those words. 😉

That video blew my mind. 🤣 I wonder now, what would it take if you wanted to implement horizontally sliding walls a la Wolf3D, or room-over-room? The lack of RoR support is probably the one thing that frustrates me the most about the Doom engine, though it's understandable since the Doom engine as it was struggled enough on most computers of its time.

mr_bigmouth_502 wrote:

I wonder now, what would it take if you wanted to implement horizontally sliding walls a la Wolf3D, or room-over-room?

Just look at Quake. It uses BSP Trees too. :B

The difference is that Quake is a full 3D polygon-rendering system with a depth buffer and everything. Anything 3D which is capable of movement in any direction is treated as an object, not as the actual level structure.

The other potential is to do what Duke3D did and go with a portal-rendering system instead of BSP Trees. Duke3D's engine renders everything one sector at a time. When the renderer gets to a 2-way wall, it queues that up and then renders the sector on the other side. If any 2-way walls are touched by the renderer in the next sector, it keeps chaining through, however, the way portal rendering works is that you have to have succeeded at drawing at least one pixel of a 2-way wall in order for the sector beyond to be drawn. This includes the empty space from the floor to ceiling. It's not as efficient a process as using a BSP Tree, but it allows for the level structure to dynamically change mid-game and is what allows sectors over sectors to work, so long as those sectors don't actually interfere with each other.

FUN FACT: Quake was going to go for a portal/passage rendering system but axed it after its performance in detailed areas were unsatisfactory, just a month before shipping.

Quake relies on a ton of preprocessed sorting and visibility calculation for it to rely on and draws the whole world back to front with clever edge lists to kill overdraw. It also relies on a surfacecache system where all the textures are tiled in memory with a blended lightmap on top and all the spans have to worry about is drawing the surfacecache with correct perspective every 8 or 16 pixels. Dynamic lights were a late addition too, and is something of a sort of featurecreep given how much performance it ruins on 486s 🙁

leileilol wrote:

FUN FACT: Quake was going to go for a portal/passage rendering system but axed it after its performance in detailed areas were unsatisfactory, just a month before shipping.

Quake relies on a ton of preprocessed sorting and visibility calculation for it to rely on and draws the whole world back to front with clever edge lists to kill overdraw. It also relies on a surfacecache system where all the textures are tiled in memory with a blended lightmap on top and all the spans have to worry about is drawing the surfacecache with correct perspective every 8 or 16 pixels. Dynamic lights were a late addition too, and is something of a sort of featurecreep given how much performance it ruins on 486s :(

I'm somewhat surprised they would've tried to do portal rendering with Quake at first, given that the level architecture doesn't really lend itself to the method very well. To do decent portal rendering, there has to be some kind of separations in place to split levels up into pieces which can portal between each other in a way which makes sense. For any 2 1/2 D engine, the 2-way walls which split two sectors apart are perfect for this. :B

As for the rest, yeah, Quake went all out with new features and methods of optimizing them so that the framerate would be at least somewhat decent on Pentium systems. 486 systems though, just forget it. The Pentium FPU is numerous times faster than the 486 FPU, and since Quake was one of the first 3D games to go with floating-point math over integer math... yeah...

Stuff that I'll bring up when I eventually get to Quake on ADG. ;)

mr_bigmouth_502 wrote:

The lack of RoR support is probably the one thing that frustrates me the most about the Doom engine

Well, that's no longer an issue for some of the modern, enhanced Doom source ports. The Eternity Engine does a particularly beautiful job considering the limitations of the original game, though hardly anybody uses it.

But here's the thing. What'd eventually destroy video games was the grotesque amount of resources available to game designers. Back in the better days, mappers were forced to work with a lot of limitations which enticed creativity as they still had to lure the player in with something interesting enough that would compensate for the relative lack of realism, thus they just couldn't get away with hacking a bunch of generic-looking, free-roaming, open-ended, urban decay/war-themed garbage maps together like they've been doing for well over a decade now.

No ror, no problem, it all worked out for the best.

I'm still a firm believer in setting yourself limits when you make a game. This way, you're forced to make those limits DANCE! ;D

Plus you're more likely to end up with something that will run at 60 FPS. :P

Gemini000 wrote:

Just look at Quake. It uses BSP Trees too. :B […]
Show full quote

mr_bigmouth_502 wrote:

I wonder now, what would it take if you wanted to implement horizontally sliding walls a la Wolf3D, or room-over-room?

Just look at Quake. It uses BSP Trees too. :B

The difference is that Quake is a full 3D polygon-rendering system with a depth buffer and everything. Anything 3D which is capable of movement in any direction is treated as an object, not as the actual level structure.

The other potential is to do what Duke3D did and go with a portal-rendering system instead of BSP Trees. Duke3D's engine renders everything one sector at a time. When the renderer gets to a 2-way wall, it queues that up and then renders the sector on the other side. If any 2-way walls are touched by the renderer in the next sector, it keeps chaining through, however, the way portal rendering works is that you have to have succeeded at drawing at least one pixel of a 2-way wall in order for the sector beyond to be drawn. This includes the empty space from the floor to ceiling. It's not as efficient a process as using a BSP Tree, but it allows for the level structure to dynamically change mid-game and is what allows sectors over sectors to work, so long as those sectors don't actually interfere with each other.

So, in other words, Doom's level geometry limitations really have to do with it being BSP based. I knew it was a 2.5D engine, I just wondered why it wasn't capable of things that other 2.5D engines could do.

Now, I remember Duke3D had a small application that allowed you to convert Doom WADs over to its map format. Would I be correct in assuming that a Doom sourceport could theoretically use portal rendering instead, and convert existing levels from BSP? It may not be the most faithful way of doing things, but it would be a way of implementing RoR without the requirement of "true" 3D rendering.

Lo Wang wrote:

Well, that's no longer an issue for some of the modern, enhanced Doom source ports. The Eternity Engine does a particularly beau […]
Show full quote

mr_bigmouth_502 wrote:

The lack of RoR support is probably the one thing that frustrates me the most about the Doom engine

Well, that's no longer an issue for some of the modern, enhanced Doom source ports. The Eternity Engine does a particularly beautiful job considering the limitations of the original game, though hardly anybody uses it.

But here's the thing. What'd eventually destroy video games was the grotesque amount of resources available to game designers. Back in the better days, mappers were forced to work with a lot of limitations which enticed creativity as they still had to lure the player in with something interesting enough that would compensate for the relative lack of realism, thus they just couldn't get away with hacking a bunch of generic-looking, free-roaming, open-ended, urban decay/war-themed garbage maps together like they've been doing for well over a decade now.

No ror, no problem, it all worked out for the best.

I understand what you're saying, and while I agree for the most part, I still think it would be awesome if Doom had RoR. Forget all the other crap like scripting, mouselook, jumping, etc. 🤣

mr_bigmouth_502 wrote:

Now, I remember Duke3D had a small application that allowed you to convert Doom WADs over to its map format. Would I be correct in assuming that a Doom sourceport could theoretically use portal rendering instead, and convert existing levels from BSP?

Almost. Doom levels still contain the raw level data which the BSP Trees were created out of, since much of that data is still used by the engine, such as sector heights and lighting, as well as sprite positions, not to mention each linedef (wall) has texturing info and may also have other triggers assigned. Thus you wouldn't have to convert the BSP Tree data at all to use the Doom levels with a portal rendering system, you'd just use the raw level data that's already there. ;)

Most modern source ports however like to generate their OWN BSP Trees in order to optimize to however the source port works, usually polygon rendering in 3D space.

One thing that's neat about the original Doom and Doom II levels is that many of them were designed with jumping in mind, thus some of the things you can't normally get over by default, most notably windows, you STILL can't get through even if you try to jump through them! There are a few exceptions of course, but it seems there was at least one point in the development where they were thinking of adding jumping and wanted to make sure the level designs could handle it. :B

Ancient DOS Games Episode 166 - HardBall! is online!

It was actually really difficult coming up with much of anything to serve as a patriotic DOS game, much less American patriotism. It seems that kind of stuff is only slightly more common nowadays. :P

A lot of people sent in guesses for John Madden Football as well, which TBH, didn't even occur to me because I didn't realize there was a DOS version of the game, I was only familiar with the console versions. :o

Ancient DOS Games Episode 167 - The 7th Guest is online!

Wow, this episode turned out to be a lot longer than I was anticipating... Ah well, I covered a lot of stuff and still managed to spoil very little in the process, plus there's an unboxing at the start, so I think the length can be forgiven. Just get yourself something to eat and/or drink before you watch it. ;)

I'm VERY slowly getting my old programming work-ethic back too. Super Minesweeper and PixelShips Retro were both games I made in roughly just two months time, and that's including the assets. Since then though, given the financial failure of those games, it started getting harder and harder to code, just from the notion that I couldn't be sure all the hard work I was doing would pay off. When I started ADG, I was barely doing any coding at all given the call centre job I was working. Since then, it's been VERY hard to get back into the swing of coding.

The reason I'm mentioning all of this though is because... about a week ago I had the strangest sensation when I realized, "I'm actually really close to finishing a game and being able to play and enjoy it just like any game made by someone else." This hasn't happened since 2007 and it's a really difficult feeling to put into words... It's helped fuel my programming desire though and I think may be a big part of what went missing between 2007 and now. I spent just as much time working on ADG this week as I did working on my game project and made substantial progress in such a short time... As a result, I'm a little more confident now that I can pull this thing off and with any luck, what I have to offer will go over really well when I finally get the free version out there and start adding the pay-games to it following.

Gemini000 wrote:

Ancient DOS Games Episode 167 - The 7th Guest is online!

Wow, this episode turned out to be a lot longer than I was anticipating... Ah well, I covered a lot of stuff and still managed to spoil very little in the process, plus there's an unboxing at the start, so I think the length can be forgiven. Just get yourself something to eat and/or drink before you watch it. 😉

The box was big to accommodate the "The Making of the 7th Guest" VHS tape distributed with some versions.

kolano wrote:

The box was big to accommodate the "The Making of the 7th Guest" VHS tape distributed with some versions.

That... makes a lot of sense, actually. :o

Ancient DOS Games Episode 168 - Slipstream 5000 is online!

...and I myself in body and mind am virtually offline, so off I go before I pass out on my keyboard. :P

Interesting. Slipstream reminds me of Descent in terms of graphics and even game play, especially with the tunnel-like level designs despite their linearity. But WTF is up with that New York level? Holy hell, that looks terrible! They should've just thrown out that level entirely. Still looks like an interesting game, nonetheless.

It does make me wonder, though.... What kind of reception would Descent have gotten if it was designed to be a combat racer from the beginning?

Thanks for covering this lesser known game. There are hardly any posts on vogons mentioning this one, but for some reason it's one of my favourite pc game ever. I bought it in 1995 when it came out, and I remember that not only I found it technically impressive at the time, but I also had loads of fun playing it. I actually replayed it a few years ago when I got into retrocomputing and still really enjoyed it.

It sure has its quirks, but played with a CH Flightstick Pro or any decent joystick, the gameplay is really good, and blasting your opponents feels very satisfying. I actually find this game more fun than descent to play, thanks to simpler controls (I also use the "reverse accelerator" option).

I never really paid attention to the dubious humour, probably because being a non-native english speaker, I didn't understand it at the time. Also, I was lucky to own a SCC-1 back in the day, so I never played it with FM music. I actually really like the midi soundtrack of this game and even if some tracks are a bit repetitive, I think it suits the action quite well.

Never played this, but the review by Kris tells me all I need to know.

Somehow I don't see much similarity with Descent other than the concept; and to me at least, Descent is far superior 😜 . And I'll take Whiplash or Destruction Derby 2 over this if I want a racing game where I can go completely nuts and physically eliminate the competition by any means necessary 😈 . The crass, in-your-face humor and continuous stereotyping doesn't help either.

switchblade wrote:

It does make me wonder, though.... What kind of reception would Descent have gotten if it was designed to be a combat racer from the beginning?

Personally I would have ignored it. Not really a fan of flight sims in general (Descent and Descent 2 are two of the exceptions).