InsideQC Forums

That code archive is still on Quaketastic too: http://www.quaketastic.com/files/tools/ ... rchive.zip

Anyway we should consider to create a public GitHub repository and replicate all this stuff there, just for historical reasons. I myself lost my engine sources and only managed to recover the last release. That's a bloody good idea. While it's certainly the case that stuff I wrote years ago is not ...

Still live here, but because it's never any harm: http://www.quaketastic.com/files/tools/ ... -12-21.zip

Not a problem, link away - it was GPL, after all.

I don't even have that source any more myself.

Madfox wrote:...but from what I have heard all later editions are more backswitched in order to make the comfortabillity of the user more efficïent.

That's what they said about XP back in 2001 too.

frag.machine wrote:Makes sense since it's based on DOOM 2016 codebase.

It's not.

Yeah, the great thing about OpenGL is that you can look at the spec, read how things are implemented, then construct your own variant if you need to. It should be possible (and easy!) to write a GL_RotatedFrustum that does the same in a single operation, not that it would be a performance improvemen...

Actually, I remember Carmack saying he regretted going to native C DLL for game code, thus Quake 3 used interpreted C. That was for security & portability reasons. It's also notable that Q3 does have the ability to load native DLLs in addition to QVMs. The idea is that you develop using DLLs an...

idTech3 is Quake 3, not 2.

idTech2 is Quake 2; idTech 1 is Doom. The Quake engine doesn't have an idTech number but can be considered an earlier version of 2.

So in 2016 it was based on FTE; in 2018 it's based on Quake 3; simple explanation: the team switched engine.

Software Quake version http://www.quaketastic.com/files/screen_shots/BModelDLight.jpg In the dlight_t struct, add a new member: vec3_t transformed; In R_MarkLights, replace occurrances of "light->origin" with "light->transformed". In R_PushDlights, before the call to R_MarkLight...

There's a method using the stencil buffer described here: ftp://ftp.sgi.com/opengl/contrib/blythe ... ode20.html

Not certain how robust it is for this particular use case though.

I pretty much stopped using the site because of it's inability to keep me logged in. Yes, it would be great if this was fixed; it would have been even greater if it hadn't happened in the first place.

I think the intention is that it's to allow the following Q_memset to take it's fast path.

192 lightmaps, at 128x128, is sufficient to load AD Sepulcher so you can probably just safely increase the max number without worrying about making it fully dynamic. Alternatively increase lightmap size to 256x256 which has the same effect as quadrupling the max. Either way watch out for "the l...

there may be other limits. I vaugely recall quakespasm having an issue with subdivisions if a sky/water surface is outside the +/- 9999 range. the qbsp is likely to also have limitations. This is a bug in QuakeSpasm's BoundPoly (QuakeSpasm ADMod fixes it): mins[0] = mins[1] = mins[2] = 9999; maxs[0...