Didn't Quake implement span based drawing also?

Awesome story!

Is there such a book you'd recommend for a more casual audience? I'd like to grind Vulkan one day

38yo and still having those episodes in my life (although with a bit more sleep)

I’m mad I’m just finding out about this book. Back in the 90s I couldn’t find anything with relation to graphics programming except for a Videogame programming for Dummies book in C and later an OpenGL book.

@@s81n Flights of Fantasy and Gardens of Imagination by Christopher Lampton were two that I had in high school that I loved.

Source 2 is a mesh based engine

@@jess648 sorse 2 is a bit too new :P

@@jess648They aren't talking about "Source 2" they are talking about "Source" (Half-Life 2, Counter-Strike:Source, Left 4 Dead, Team Fortress 2, Garry's Mod, Portal, Vampire: The Masquerade - Bloodlines, ect...) and "GoldSrc" (Half-Life 1, Blueshift, Opposing Force, Team Fortress Classic, Counter-Strike:Condition Zero, ect...)

Workstyle "Working more gets more done." - John Carmack[30] Carmack has maintained a sixty-hour work week, working a 10-hour day, six days a week, throughout his career.[30] He has spoken publicly about the importance of long hours of uninterrupted focus in his work. Not only does high intensity allow him to make progress more quickly, but long hours are also critical to maintaining a focused mindset over time. Despite working such a demanding schedule, he has never experienced burnout. source: en.wikipedia.org/wiki/John_Carmack

For that 3 axis rotation did you suffer gimble lock or figure out quarternions? :P It took me a long, long, long time to learn that one. I just dealt with it until I heard quarternions were better for encoding into network data.

Like Quake? Or just an empty square room?

Very neat! I was originally building out 3d stuff in software, but honestly abandoned ship for opengl once it was available to me.

@matthewtymaja3760 do you have the source code of the engine?

"I regret not developing that 3D graphics engine I made in 1996" developing a 3D engine in those years man ... crazy, with basically no information, no internet etc. That is tough. I developed some kind of "RPG Maker" back at 97/98 when I was 13. Nothing special actually, but seeing how RPG Maker is now a product and Game Maker is fueling a lot of indie games I even regret that. Funny sometimes how he do great things and simply stop where they could have changed your future. We do underestimate the small things too much :D

I got a commission to make a few counter strike maps 1.6 a couple years ago. CS is based on GoldSrc, which is like a modification of the Quake engine, you even use the same toolchain to make maps for either one. Compiling a map involves four steps: consolidating the geometry (and somo other stuff), generating the bsp, calculating visibility, and then radiosity-based lighting. They all run on the cpu, and for large / messy maps they still take quite a few minutes to run. It really is a lot of computation being made "offline" when you think about it.

I don’t understand why with early 3d graphics hardware you could not really render front to back. And you could place a boundary volume check before a node / expensive model. For one hierarchical z buffer seems to be difficult. And async await where you could put meshes and triggers behind tests were not supported. I mean like you use the CPU to upload the next finder geometry, while the GPU processes the coarse nodes in front.

@@ArneChristianRosenfeldt Quake predates 3D graphics cards, there was no GPU to offload anything to.

@@Ylyrra Quake came out in 1996. Nvidia nv1 came out in 1994 as did the psx. Some games targeted the 3do in 1993. The hardware was obviously geared towards 3d, but more in stage like way. Somehow dungeons only existed on home-computers and PCs. The console industry focused on 2d games with polygon characters or so. Or racing games with a camera very similar to pseudo3d on genesis. Before the internet there were trade shows. Leaders of software companies actually went there and saw 3do, PSX and Saturn even before their Japan release. Or you could just check at SGI to see the future. Donkey Kong Country was modelled on SGI.

@@ArneChristianRosenfeldt Yes, 3D cards "existed". Consumers vastly didn't have them. Every game still had to ship with a software renderer EVEN if it did have a hardware one. I knew ONE person with a 3dfx card, ever. Meanwhile the other 20-30 PC gamers I knew relied on software rendering. The technology effectively didn't exist when it came to developing a game you wanted to sell to any actual customers. And another factor is that development time leads release time.

I thought that a Beam Tree would be great for the AtariJaguar, but it feels so weird. Instead of normalized device coordinates to clip against, there is the beam tree. It feels more like raytracing. Only in the final step I would fill in the texture using linear interpolation. The tree splits so many polygons. I don’t even dare to start. All the code fills the cache. Access to the tree in DRAM is slow.

One thing that always amazes me to this day is Psion 5, i have the Mx Pro version. A handheld from late 90s which cost a lot of money, i think something like $2000. Equipped with a 16MHz ARM7TDMI and 24MB LPDRAM, it actually lacked internal storage except bootstrap ROM, instead you would install the operating system into RAM from a CF Card, consuming a couple megabytes, and you had the benefit of CR2032 battery to hold up the RAM contents if your main battery ran out, and of course you could back up your documents to CF card (or even a Microdrive with hundreds of megabytes capacity, up to 2GB eventually) anytime. The most amazing thing is that this thing was actually reliable AND shipped with a rather fully featured clone of Microsoft Office, which included Excel Word etc clones and also supported OLE, object linking and embedding just like desktop counterpart, meaning you could embed an Excel table into a Word document etc. How do you save documents? You don't, they're always saved with every typed character. There is undo. How does it handle when the system runs out of RAM? It simply won't let you type another character or do any changes to the document, but you can swap out to the file manager any time and delete something you don't need or move things to CF card. And it didn't have loading times etc it's very instant and responsive, only limited by the slightly slow screen. An absolute marvel of software and system engineering, and just a pleasure to use. Two AA batteries in the back would give you about 3 weeks of typical usage time, and you can use rechargeable cells but you don't charge them in device, you just have extras that you can drop in any time. Mechanically also rather slick, kicking the keyboard forward when you open it up, remaining perfectly balanced. In its closed state, a baffle could be pushed in to instantly turn it into a voice recorder. Another of my favourites is Casio PocketViewer. Equipped with 128KB SRAM, a power optimised clone of a 80186 CPU and generous 2/4MB flash, this very cheap about $100 device was small, much easier to handle than my smartphone and an absolute pleasure to use, particularly with elaborate one handed mode operated by a thumb click wheel. Also spectacularly reliable and quick. It ran for about 2 months per 2 AAA cells, and it doesn't need a backup battery since it flushes things to flash on every context change or when not in active use. My favourite app for it is an endless scroll of handwritten notes and scribbles. I was also reading e-books from it. Both came with native SDKs, and Psion even had a powerful scripting environment on board with full documentation that was robust enough to develop full applications in. And both work perfectly in sunlight. Of course both are greyscale only. And in spite of oodles more power, my smartphone is a lot slower and more cumbersome to use, the software ecosystem really isn't well designed in comparison. No way of charging your smartphone? Just grab your little power brick along, it's not like they didn't have power outlets back in the day.

Maybe not. We're reaching the limits of what's possible.

@@vibaj16 for single processor clock rates and transistor sizes. That doesn't mean other ways of improving aren't available, much less that they won't be found. It's just that this one specific way of growing which has worked really well is slowing down.

Pretty sure you could easily charge but just with 1 amp. Like any time back until.... early electrification.

Oh absolutely, I loved my PC back then, it was mindblowing to even have a computer. I didn't want to take anything away from what it was, in its era. That being said, for anybody who didn't live through that era, it's also important to understand just how limited it was, compared to that thing you doomscroll reddit on.

How does collision work? Apparently, collision needs polygons to slide on already for Sonic the hedgehog. So we intersect the sweep volume with the BSP and then find contact points?

Most videos that try to explain bsp trees in doom don't really understand it themselves so they usually gloss over it.

Wait 'til you learn that we landed on the moon with less computational power than your calculator. 😅

​@@redslate😂

@@redslate What's a "calculator"? 🤔 A phone app? 😁

@@redslate A calculator can do a lot if running continually and using a stored program though. Giving you the answer to a square root or a power function in a fraction of a second is no mean feat, even if it would seem achingly slow code-wise vs even an 80s computer. Most modern processors can be traced back to a combination of single-chip implementations of the architecture of a desk calculator, data terminal, or aircraft flight control system after all, in some cases almost exactly that (the 4004 series and a couple other early Intels in particular - and whilst that first processor was weak as hell, it was still considered useful for *something*)

A lot of dynamic culling is done per object, if all 6 vertices of the objects bounding box fall outside the camera frustrum then there is no need to test any of it's polygons. You also don't need to test every object, if a buildings bounding box is not visible then any object (fully) inside that building is also not visible.

Wow thanks for that info- Gotta check out those demos!

All of Source 1 uses BSP, so Portal 2 and CSGO used it as late as 2011 and 2012.

@@SirYodaJedi Explains why Portal's maps seem so Quakelike in feel, maybe. (And somewhat P2 though it hides it better... not sure about CSGo)

@@tahrey Portal 2 and CSGO make heavy use of props to fill in the details between the simple brushwork. The CSGO version of de_ancient is almost completely props, but it still has a brushwork shell because visibility testing and bounced lighting require it.

@@Simrealism An assembler is the software that assembles your program, written in assembly language, SensSword is correct. Most people nowadays misname it as 'assembler' for some weird reason, it is like saying you are programming in compiler.

I believe Carmack commented that only later in hindsight he noticed that PVS was similar to REJECT.

I have no idea what that video would even be about heh

Yeah, otherwise you'd lose a LOT of objects. If it's 8x8 pixels that sets an upper limit on how large a poly can be whilst still being losable, and even then it'd more flicker as you moved around because of the changing positions of a great many borders, so not truly lost. But it still saves you a hell of a lot of time, as, best-case, you may be casting only one ray instead of 64.

Descent was a really fun and ground-breaking game, but the graphics didn't seem as crisp or solid as Quake's. Also as I recall, the bigger areas connected between the tunnels were mostly just open rooms without complex geometry. Still it preceded Quake as did Bethesda's Terminator: Future Shock (using Bethesda's Xngine) which was fully-3D back in 1995.

@@curcumin417 Terminator was great but geometry was very light (and Descent was out 6 month before!) / the geometry of descent is mostly based on corridors (and most of all, based on cubes, that's why he was so smooth on my P90) => also as far as i remember, terminator was sloooooooow as hell to load!

@@edouardberge Right- I remember that! Also (I'm not a programmer or engineer) but I remember some rendering artifacts in the early version of Xngine as well. Still very impressive for its time

And was written by one man

@@turbodog99 Carmack wasn't the only programmer on Quake, though it seems that he was the main guy behind many clever optimizations.

That's the modern solution.

Dedotated wam

Or download more, ideally!

1.2GB OF RAM??? Yeah, in 2024 RAM is available in every corner drugstore.

Buy? Just download more ram from the internet

My first card was a Voodoo Banshee, those were the days!

Thank you so much!

With a path tracer you randomly vary the starting position of the ray over the lens ( 3 mm disk of your eye pupil)

You split the surfaces. It's not terribly complex, but I avoided it in the demo's mostly to keep them really simple.

You split everything onto both sides as you fill the tree. That is the ugly secret.

Yep, as Arne mentions, you do splits. It doesn't fundamentally change the understanding of the trees presented, but adds some complexity to implementation, which is why I skipped it. This was a crash course primer on bsp's, and I just wanted you to understand the concept.

I write shaders and define everything there using code. I have a shader course that touches on some of it, but the videos are like 99% SDF's and shaping functions.

@@simondev758 thank you.

Thank you for your support!

That would be the ideal - problem is that it can actually be *really* difficult to tell exactly what's in front at a given point, once you have overlapping/occluding objects. Doing that perfectly basically involves having to ray-trace every pixel. Z-buffers actually work on a similar-ish premise to what you proposed, though.

That's similar to z-buffering which is how 3D accelerators work. It wasn't practical on the CPUs quake was designed for though. It also has issues when it comes to transparency, and has to be bypassed for those cases. Usually objects aren't fully sorted because it would be prohibitively expensive, so the algorithm has to be able to draw closer objects on top of further ones, which is why it is called a z buffer, it stores depth and does a compare per-pixel. Quake gets away with this perfect sorting approach because the levels were relatively simple, geometrically speaking, and also because it reduces the amount of map geometry per frame the renderer deals with, via pre compiling the visibility info per map area. It still stores z (depth) information into a buffer for later use by the object renderer, but the map geometry renderer only performs writes to that buffer, no reads.

@@Ehal256translucency just needs perfect sort. It works front to back or back to front. That is why I don’t understand that PSX and Saturn with their sorting did not capitalise more on translucency. OpenLara breaks up the whole regular level and resorts by z when Lara turns her head… Early PC graphics card was so slow with texture filling. Front to back would have helped. Sadly, Jaguar is slow no matter if z is rejected.

As mentioned, yes you can, and this is basically what Z-buffering does (store how far away each pixel drawn is, so you never paint over something near with something far, regardless of how complex the geometry is). That works fine once you know which polygons need to be turned into pixels. BSPs etc. are about the next level of the problem: discarding entire chunks of the level/sets of polygons entirely, before you get to the slow work of considering them pixel by pixel.

@@mangobrainify Quake discards nodes in a BSP using PVS. This made level changes extremely expensive. We all just wish that hardware could check the surface polygons of a node against the z-buffer in a fast way, like Doom does it with its column buffer.

Watch my video on occlusion culling

@@simondev758 I have, I see what you mean now. My mind is on navmeshes.