News | Forum | People | FAQ | Links | Search | Register | Log in
Quake Custom Engines
Discuss modified Quake engines here, I guess. What engines do you use? What are the pros/cons of existing engines? What features would you like to see implemented/removed?
This is of particular interest to me, because my next map will certainly require a custom engine; at least one with increased capacity, and preferably one with skybox support and tga sprite replacement textures.

I'd like to get a good idea of what engines most people here find acceptable. 
I Cant Run 
standard glquake properly on my setup, dont know why.

Instead I use mhquake with all 'enhancements' turned off except for model interpolation. So it looks and runs exactly like glquake would but with smoother animation.

For levels like nesp09 which need higher edict counts, I use the nehahra version of darkplaces.

Fitzquake would be my preferred engine if it had model interpolation and was capable of handling levels like nesp09. The software emulated lighting it can do is wonderful.

As for darkplaces, I liked earlier versions but havent tried it lately because I ran into big problems with it when bumpmapping was introduced, mainly due to lack of documentation to turn off stuff. 
For my part I'm currently mapping using FitzQuake 0.75 as a "Quake test" engine (it support colored lightning, transparent water, for example, and have a better capacity ,in term of resolution and performances than a standard WinQuake for example)
Furthermore I suppose this is the most used engine by many of us here... let me know if I'm wrong !!

Regarding custom Quake engine, I don't know if an engine like the one you required exists today... Many custom engine features are really specific to a map (or pack) and thus are developed especially for a precise project...
If you want a special custoom engine, I think you'd rather modify existing Quake C code by yourself.. or be helped by a good software "Quake" engineer ;P 
seems good, but it won't load my current map, which exceeds a number of limits. 
Yes, darkplaces used to be very nice, but as more and more features were added, it just moved further and further from quake. It's not really a glquake replacement anymore - OK I guess if you are making a completely new TC, but that's narrowing the user base a bit IMO. 
Your latest map seems to be a very huge map if FitzQuake is not able to load it !! BTW, what are the number of limits you exceed ?? 
Fitzquake would be my preferred engine if it had model interpolation and was capable of handling levels like nesp09. The software emulated lighting it can do is wonderful.

You realise that the software-emulated lighting was first written by LordHavoc for Darkplaces and that other Quake engines are mostly using parts of his code to archieve the same? :) 
Well, just edict limits really. Static entities, that sort of thing. Also, unless it has a higher tolerance for packet overflows, I'm sure it would cause chokeage in the final battle(s) too. 
AguirRe's Engines 
I'd just like to say that AguirRe's Win/GlQuake replacements are pretty much spot-on for my needs in terms of map capacity. These are a great choice if you want an ultra-conservative single-player engine, for use in huge maps. 
You realise that the software-emulated lighting was first written by LordHavoc for Darkplaces and that other Quake engines are mostly using parts of his code to archieve the same? :)

That may be true - LordHavoc is an extremely talented coder and I love a lot of what he's done with DarkPlaces.

The problem most people have though is with all the extraneous bloat that comes with it. 
Sorry Above Post Meant For Jago. 
I Mainly Use. 
Glxpro+ (ver 1.01). It was a hacked of a version of GL ProQuake by Trujen that cause a bit of a fuss because Trujen refused to release the source (instant GPL issue). Nice client that has all the ProQuake stuff, plus 24bit texture support and some other eyecandy stuff. This client is probably concidered old hat now, but it as good as I want it.

Anyway, lets start a list.

Quake1 Clients (excluding QW clients)

DarkPlaces (LordHavoc) :

FitzQuake v0.75 (John Fitzgibbons) :

GLQuake v0.97 (author?) :

GQ Quake v1.07 (Matthew 'Gleeb' Garnett-Frizelle) :

ProQuake v350 (jp grossman) :

Telejano version 8.03 (Tei) :

Tenebrae (Charles Hollemeersch?)

TomazQuake v1.46(Tomaz) :

XQuake v1.01 GL (Trujen) : 
I dont know much about who coded what but fitzquake's implementation of it looks better on my setup than darkplaces. And it runs a lot faster.

Like I said, the newer versions of DP may have fixed all that but I stopped using it after I couldnt work out how to turn off a lot of the new features. 
More Engines 
There is also Twilight at and QuakeForge (website seems to be down). 
While I do have some issues with newer versions of DP (for example the Shambler lightning thing Kinn has mentioned), I have actually switched from using FitzQuake for testing my maps to DarkPlaces. I am not sure which version you were using, but the latest ones have definately much better lighting than any other NQ/QW engine I�ve seen to date. 
I think pretty much all of DarkPlaces' graphical "enhancements" can be controlled via cvars, but I agree, the documentation is pretty poor. What's turned me off recently though, is that I can't get any build of DarkPlaces after the 21may04 build to run properly on my system. Dunno why. Up-to-date vid drivers and all that. 
Shambler lightning has been fixed in latest DP build I believe. The player lightning is still bolloxed though. 
Do you mean the player shadow with r_shadow_realtime_world "1" ? If that's what you mean, the player shadow IS in the correct place. If you don't like the player shadow (I know I don't), you can disable it, leaving on everything else. 
Small Thing, But 
I tried "The Abandon" with Darkplaces, and it skipped the grenadelauncher in "Facade".
Strange, because FitzQuake or Telejanos didn't.

Could there be a reason for it, ie. bouncing box to big for the used surounding space? 
One of my main design focuses in DarkPlaces is keeping down bloat, this is why all the features are integrated in the core of the engine, rather than just tutorials tacked on like some other engines, serving specific features with little consistency.

DarkPlaces was created for modders, that is its primary reason for existence, I made a promise to the quake community more than a year ago to maintain DarkPlaces to support the community for years to come, it delivers a consistent user and modding experience, rather than needing a custom engine for every mod, which was fragmenting the community (for example Tenebrae).

It's the only engine that tries to support every mod in one engine so that users don't have to deal with different hardware compatibility issues and different missing features in each mod, and that developers don't have to write their own engine for each mod.

This is why it greatly puzzles me that some modders want to use less featureful engines, often maintained by people who are less than appreciative of modding feature requests.

The worst part of this is that the released quake source is quite honestly outdated, it works (barely) on windows (for example too many GL extensions crashes glquake), not at all on Linux and MacOSX, and lacks multiplayer - nq borders on unusable for multiplayer due to incompatibility with the NAT routers most people use for broadband, combined with using too much bandwidth for dialup to be playable.

When I rewrote the networking it made all supported mods playable online, a rewrite that would not have been worth the trouble for just one mod's custom engine.

It seems many people just complain about darkplaces on forums I can't read regularly (it takes too much time to keep an eye on several forums just combing for complaints and suggestions).

Could people please email me about these things before they get upset?

P.S. What ever happened to extensions? If a minimal engine is really desired, make your own, with support for the specific extensions your mod uses, and darkplaces will have these same extensions, thus the users who can run your engine can use it instead of darkplaces if they wish. 
Player *lightning* - note the "n" ;)

I'm talking about the lightning gun beam. 
LordHavoc - like I say, I love what you did with DarkPlaces but, well, as I've mentioned before, my system has serious problems running all versions since the 21may04 build.

I've since been checking out FitzQuake, with the intention of using this as my "engine of choice". It's a fantastic engine that emulates Quake's original look and feel, whilst still providing the most important extra features to meet the demands of modern maps. If FitzQuake would allow me to replace my sprite frames with external .tga textures, it would be the perfect engine IMHO. 
FitzQuake Again 
Does it really have increased map/entity limits? I tried FitzQuake 0.75 in my spawning test map, and it hit "no free edicts" at about the same time as standard quake. 
well, if anyone cares, my ideal engine would be somewhere halfway between fitzquake and DP.

i need to try DP with sv_jump thing disabled and detail textures off though, i don't have the means to do that atm.

anyway, taking FQ as a base, i'd like to add:

-q3bsp format support
-any sized bounding box
-controllable particle effects, ie customizable TempEntity effects, not just the built in ones.
For example, TE_EXPLOSION2 has limited customizability in that you can specify the colours that it will use, but, you can't change the speed, duration, or behaviour of the particles at all.
-NOT have r_exp3.wav automatically played with explosion tempentities. sure, it makes sense, but it's also bad if you want to use the particle effects with a different explosion sound.
-Flying Monster BugFix
-TGA Sprites
-Model Interpolation
-Larger Edict Limit
-Larger BModel limit(or whatever it is) (i know this breaks compatibility for netplay, but i am talking from a purely SP pov. maybe have this setting optional via command line, so that you could still use the engine for netplay on maps that don't need the high limit, but on SP maps that require it, you turn it on)
-Stop Packet Overflows

..that's it for right now... writing this all down on the fly, so i might have missed something...

i'm starting to get the feeling that DP could be used with everything except what i'm talking about disabled... but i won't be able to tell until i can see a cvar list., maybe the real reason people dislike DP is because there isn't any documentation to let people know that they can turn things off (like Nitin who couldn't turn off the bump mapping) 
ie: when i said "any sized bounding box" what i really mean is "no hulls" 
no, FQ doesn't have bumped edict limits, neither does it handle packet overflows differently from GLQ...

i find this is the major flaw of FQ atm... well, that and the skybox bug, bug that's fixed in the next version anyway. 
Necros, I'd probably say almost the same thing if someone asked me to describe my dream engine.

However, I'd settle for FitzQuake + increased entity limits + packet overflow reduction + tga sprites (Additive blend mode).

Q3BSP support is the holy grail of engine features for me though. I know DP has it, but I've already described the issues I have with DP. 
I went ahead and sent a copy of the extension list. It may be a little under documented but there is enough info there to get a grasp of the cvar settings. There is also a tutorial on Inside3d on modding for DP that can be useful as well.

On the general question; I am still using glquake/fitzquake for the next handful of levels that I'm pushing out the door because they are single map adventures (two very nearly finished, I'm just trying to improve my brush work and texturing at this point), but after that I'm going to need a custom engine and Q3 bsp capabilaties. 
Thanks for the nice comments on fitzquake, guys.

Jago: turns out i wrote most of fitzquake's core rendering stuff. I do have some darkplaces code in fitzquake, though it's mostly utility functions like frustum culling and vector math and that sort of thing.

Lordhavoc: darkplaces is extrememly customizable and I think it could satisfy most people if only they knew how to customize it. Lack of decent documentation is the biggest problem with darkplaces, in my opinion. 
Hey Metl ^_^ 
Would you be willing to consider bumping up some of the map limits (like aguirRe is doing with his engines) for a future FQ release?

Pretty please? ^_^ 
but wouldn't that just encourage mappers to release maps that go over the limits? 
That's the point. Many mappers (me included) feel that it's time to push the boundaries/limits of the Quake engine. Now if only all engine writers could agree on BY HOW MUCH they should push them. 
tried the latest version, it actully works ok on my system and looks and runs better than prvious builds. I've got most the options the way I want (it took a lot of fiddling but anyway).

Can someone tell me how to revert the blood effects back to normal and also how to get the weapon and monster effects back to normal. Right now there's a big coloured glow on things like scrag attacks, rocket explosions etc.

Also, is it me or is the player turn speed and jump speed different than normal? 
and I'm happy that the DP software lighting now looks like fitz's. 
yes, i noticed the jump speed and turn speed too... not sure if it really is different or not...

also, disabling bump mapping really speeds things up, though the hell knight now has the cpu crusher attack added to his normal attack when using dynamic lights... :P it's too bad because the dynamic lights work fine for other monsters, but because the hknight shoots 5 projectiles at the same time, it starts hurting my vidcard. :P

also, why is the jumping messed up? when i jump, then hold down the jump button while still in the air, when i hit the ground, the jump sound gets made but i don't actually move up. is that a bug? 
Bumped Engine Limits... 
... will encourage many mappers to start very huge map.. Engine limitation for sure limits mappers' creativity ;) 
I think limits create the necessary context for creativity. 
Metlslime Unbound 
But what if someone wants to make a FarCry clone mod using FitzQuake? It would take several applications of Terragen per map to achieve those lush landscapes. It would be a pity to deny this well, likely non-existent person. 
why not have raised limits and then let the mapper decide whether he wants to make a humongous map or a standard map? 
Creativity needs huge spaces to grow... Creativity in a small space is limited, so boosting up engine limits allow mappers to create much more creative maps... Take just the example of a tree: it can grow very easily if unconstrained due to "nature exhuberant creativity". Put the same tree into a small flower-pot, and never it can grow as it should...
I think that creativity works like this... but I understand your point of view metlslime, with constraints, mappers have to "use their brain" much more than if they are unconstrained... And what about brainstorming without constraints ?? It can give very good results, isn't it ?? 
About Quake not running on Mac OSX.. do you mean the original code, or... what exactly? Because I run this port: and all I have to do is copy the ID1 dir from my PC Quake cd. 
Trees Don't Make Quake Levels! 
I Beg To Differ 
but wouldn't that just encourage mappers to release maps that go over the limits?

Firstly, I'm not talking about architectural limits (like map boundaries and stuff) - just increased edict counts, stop packet overflow and stuff.

Well I suppose this is just a request to make my new map playable in FQ, I guess. Otherwise I'll have to say it's DarkPlaces only, which might not go down too well, round here. :( 
you could make a map that's compatible with ALL engines, even if it looks better in some :) 
Please will everyone that seems to be able to get the latest DarkPlaces running, tell me if they experience what I'm experiencing:

With all versions after the 21may04 version (inclusing the latest Oct 6th version), the screen seemingly jerks and stutters at about 2 FPS, even if the FPS counter says "60 fps". What's more it feels like really, really bad lag rather than a low rendering framerate, almost as if I'm playing online on a 56k, but not quite. (I'm never online btw.)

Btw - I have *all* dynamic lighting features turned off; even dlights like the rocket glow turn the game into a 1 FPS slideshow.

With the May 21 build, it's silky-smooth again.

My system: Dell Inspiron 8200 laptop, 1.5GHz, 512MB RAM, GeForce4 440 GO.

I use this command line:

C:\QUAKE\darkplaces.exe -nocdaudio -novorbis -nojoy -noudp -noipx -noserial -nolan -sndspeed 11025 +exec bdw.cfg +skill 2 +developer 1 +map start

My vid drivers are up-to-date, and in any case, I don't feel I should have to worry about my graphics hardware just *to play Quake*.

Sorry, I don't want to turn this thread into a DarkPlaces tech support forum, but I've had no luck solving this problem using other channels of enquiry. 
... it was a kind of comparison... I know that trees don'r make quake level... silly guy ;P 
honestly, i don't understand the point of keeping limits in.
and i, personally, will make my maps regardless if they are playable in all engines or not. i try to get them to work in all of them, but if they can't i won't redesign a whole map just for that.

i think fixing edict limits is actually more for players who use your engine than for mappers. because then people will be able to use your engine instead of another one when they'd prefer to use yours. 
because then people will be able to use your engine instead of another one when they'd prefer to use yours.

metl, read this. A Lot. Print it out and tape it to your fridge door. Spraypaint it on the road outside your apartment building. And stop acting like such a stuck-up ass. 
i, personally, will make my maps regardless if they are playable in all engines or not. i try to get them to work in all of them, but if they can't i won't redesign a whole map just for that.

Yes. I made Bastion 2 with the idea that it will have to use a raised-edict engine. The map is basically done now, and I can't really re-design it so that it will play in standard engines sadly :( 
Necromatic-Kinn Entity And The Great Lord Of The Chaote Dimenion, 
DarkPlaces has always worked smoothly on my system, performance wise. Some Quake entities get messed up, like the telefrag sequence at the beginning of Space God's Rune. I have been meaning to report this to LordHavoc as he has requested.

If you are reading this, Good Sir, often times the mapper is relunctant to do this because he is uncertain if it is a bug or if it is just his own personal ignorance on how the engine is intended to perform if tweaked correctly (I'm absolutely shameless in my ignorance, so we have communicated a few times previously). 
DarkPlaces Problem Solved 
Turns out it was simply a matter of setting gl_finish "1", which has a huge benefit on my system (but others get more performance with gl_finish "0" apparently). Try both to see what works best with you. 
Necros - DP Blood 
In GA, you mentioned the blood-splatter stainmaps not clearing on level reload. Try setting cl_stainmapsclearonload "1". Also, you could try an alternative effect, which is decals, which I find quite cool: turn stainmaps off (cl_stainmaps "0") and use cl_decals "1". Decals fade with time as well, which I prefer.

Also, you do have limited control of stuff like this in the in-game menu, but it will be nice when all the cvars are documented ^_^ 
I think limits create the necessary context for creativity

Im not sure this logic regarding limits makes sense to me. Surely it should be up to the artist[mapper] themselves to exercise their creative right to freedom to create whatever they want.

Applying your line of thought to other media, for example, we would say all books should be under 200 pages, or all films under 2 hours.
Which just seems plain wrong to me. :/ 
Creativity Also Involves Working Within Constraints 
of your medium. For example, in sculpture, you have to work with the grain of the rock or else you are not going to get anywhere.

I think Metlsime's concern may have to do with the Universality of Quake. It is hard to imagine any PC that it can't play on (maybe someone somewhere still maintains a 286/32). As long as the game that is being played is essentially Quake than it makes sense to me as well that the lower end is maintained.

The DP approach is apt for Total Conversions, as is Quake Fusion. Many mappers do not really understand what these custom engines are about and why anyone would bother with them.

For me, these engines represent a potential to reach an ambition of mine and that is to make a mod that is not dependent on the end user having to buy anything including the gaming engine. 
I don't know how to quote things, so:

"I think limits create the necessary context for creativity."

Just wanted to say: I couldn't agree more with that. I discussed that topic so much with aardappel and headshot, and it always came down to that. I think the more freedom you have, the less creative you are. 
Creativity, Blah Blah... 
If I can just cut through all the posturing and fannying around for a minute, all I am suggesting (along with Necros, and others I'm sure) is that metlslime goes in and bumps up a few of the numbers like MAX_EDICTS and such, so that we can go ahead and make the sort of 300 monster maps which I know you guys all love ;)

In Bastion I had to resort to all manner of complicated QC "hacks" to trick the engine into loading a 300+ monster map with all the necessary pickups items etc. to dispatch said beasties. Now, I guess I could resort to doing this again in my new map, but it would be nice (and would make mapping much easier) if I didn't have to worry about this so much. 
I Think 
that modyifing an engine to support more monsters, etc. for Kinn's next map sounds like a good idea. I mean, it should be worth it. 
Thanks Zwiff 
Additionally, this would benefit a lot of existing maps; take czg07c for example - a large map, but not what you would call ridiculously large by any means - in Hard I still often reached the edict limit and crashed out of the game. 
"I think limits create the necessary context for creativity."

this is irrelevant. the maps will be made regardless. this is so players who like fitzquake can play those maps on their engine of choice, not be forced to use another engine. 
The thing i said about creativity is something i really think is true, and i hope most people realize someday. But, that isn't my actual reason for resisting these suggestions.

The actual reason is, compatibility. I don't like maps that require one specific engine, websites that only work in one browser, etc. I think it's much better if maps and engines were built to a standard. That way each map could run in any engine and each engine could run any map. When a map or engine requires something extra, hopefully that extra thing is also standardized. Lit files are a good example of a standard. "More edicts" is a good example of no standard, since each engine that bumps max_edicts will pick arbitrarily what the new maximum should be.

uwf, you compare this issue to filmmakers having the freedom to make films longer than 2 hours. Well, what about the freedom to release DVDs that only work in a few, special DVD players? I think that's a closer analogy. 
I Declare... 
the standard for the edict limit is 2048.
now, everyone change your code to reflect this.
The actual reason is, compatibility. I don't like maps that require one specific engine, websites that only work in one browser, etc. I think it's much better if maps and engines were built to a standard.

Necros For President! 
The man is not afraid to weld the power or grab the reins. I like his style!

Now it is time to go over QuakeSrc and Inside3D and tell them, 'listen up! The new edict limit is 2048. Now get to it!'  
The Inside3d Forums... 
appear to be down... 
Darn . . . 
I noticed a bit of a pinging problem when I checked there last week.

Quakesrc forums just came back up a few days ago. 
The actual reason is, compatibility. I don't like maps that require one specific engine, websites that only work in one browser, etc. I think it's much better if maps and engines were built to a standard.

I agree with this. I always prefer the map that doesn't require any custom engine, but there may exist some maps that are worth playing but require a custom engine. In other words I can say, I like to play large levels, I enjoy them most of all. And I don't think that everyone will make large levels when FitzQuake increases its limits.
There are only few mappers here who make maps with higher number of edicts or anything like that. And I think their maps are always worth playing and it would be good if their maps were playable in engine that most people here use. 
Despite my hard-liner philosophy, I did turn max_edicts into a cvar, where the default is 1024 (quake is set to 600,) and the max possible value is something like 8192. So you can play ne1sp06 or whatever that big one was with all the monsters. You know, and the lava. 
thanks, sir! :) 
Metlsime Sacrifices The Purity 
of his soul so the rest of us may tread further and higher. Let us not let him down. 
I, for one, salute you. This is excellent news. Are static ents similarly raised? 
no :P 
Enhanced Version Of Win/GLQuake For Mappers 
Win/GLQuake for mappers. No idea if this is any good :

This Win/GLQuake version is *not* meant for general play, although it should suffice at least for SP. It's meant to be a stable, high-capacity version of the original Win/GLQuake with some minor features added for convenience. Its main purpose is to be used when other engines fail to load a bsp.

This makes it ideal for mappers who at one time or another experience problems with their maps; there are leaks, entity overflow or other issues that prevent the map from loading in a normal engine. These problems should of course be fixed so the map can be loaded in any engine, but during development this engine can be used to help finding and fixing the problems.
Win/GLQuake for mappers. No idea if this is any good

Lol, uh yeah, they're AquirRe's Win/GlQuake replacements, in case you were wondering. ;)

And yes, they *are* very good, as are his compile utils. 
How Hard Is It To Change These Limits? 
is it just a matter of changing a #define or two in the source?

Failing that, can anyone point me to an enhanced *non-GL* build for linux? 
Sometimes they're just a #define away, sometimes increasing one limit will just exceed another and worst of all, sometimes you'll need to change the client/server protocol which may break a lot of interesting things ...

As for Linux non-GL build, check out TyrQuake at . You might need to ask Tyrann for the executables.

Kinn: Thanks for the kind words :) 
Well, That Was Easy 
Tyr-Quake seems to work nicely. Didn't even take very long to build... thanks for the pointer.

Now I need to remember what all the huge maps I haven't been able to play yet were... some of them were by necros, I think :) 
LH, maybe the real reason people dislike DP is because there isn't any documentation to let people know that they can turn things off

Its not just that. The problem, as with many other engines, is twofold. Sure, there's a lack of good documentation, making it hard or impossible to figure out how to turn off all the shitty graphical 'enhancements' that you don't want (and that often kill performance, too). But the real problem is that said shitty graphical effects are enabled by default, thereby requiring people to figure out how to turn it off, which they can't figure out because of the lack of adequete documentation... so they just delete it from their system and that's the end of it.

As an engine programmer I'm sure you're asking 'but how are people going to know about and see all my spankworthy new effects if they're disabled by default??'

Well the answer is to have good documentation so the user knows about, and is encouraged to try, all the new options. And put the stuff in the menu where possible.

I'd explore new engines a lot more thoroughly if my first reaction wasn't 'this looks like ass, how do I turn off all these shitty effects!' followed by 'can't figure it out, just delete the shit!' 
what frib said! 
Yes 2 
Again, what Frib said.

Sometimes though, extra graphical effects actually fundamentally override existing effects. Take the rocket trail in DarkPlaces, for example. Now, I'm a big fan of DarkPlaces - it's Q3BSP support is what will keep me making Quake levels for years to come - however, it is not possible (at least not with the current version) to make it look exactly like (or close enough to) "Real" Quake, for many people's (including my) tastes.

Ok, I understand that DarkPlaces is meant primarily as a "Total Conversion" engine, so it is assumed that modders will use so many custom models and stuff that the radically different appearance of the built-in particle effects will be irrelevant. However, I feel that nevertheless, there should always be an option to at least "emulate" Quake's classic look and feel, to cater for the purists (or pseudo-purists, I guess if you're into custom engines). 
what frib said 
That bunny hopping bug you reported in DarkPlaces might have its origins in QuakeWorld - check this out:

Scroll down a bit. Sounds awfully familiar doesn't it? 
meh :\
i'm so *not* surprised. 
LTH Would Disagree... 
Frib - there other people in the world, you know. People who use DP because they think it looks pretty and they *want* the custom effects to work out-of-the-box. If you cared that much, you could take LH up on his offedr and email him, instead of whining in forums that he hardly reads. 
And those people should be culled, to prevent further corruption. 
New DarkPlaces Release 20041017

Awesome, awesome stuff - LH has been really improving the Q3BSP stuff recently - most shaders will at least load a texture now, and the curve loading has been rewritten. To test it, I fired up Sock's POM map, and played Aard's DMSP mod in it. Seeing the quake monsters running around in that environment was pretty cool, I must say ^_^ 
Very Cool 
i just tried the same, and it looks very nice.. plants seem to glow fullbright though, but the implementation of the q3bsp format in darkplaces is very effective, judging from having loaded this level 
If I had to name one problem with Quake, it was that my Radeon 9800 gave a framerate which was too playable. 
Well, in DarkPlaces, I get a consistent 60 FPS in 1024x768 (yes, in Sock's map) on my crappy 2 year old Dell laptop, with a graphics card that can barely play UT2K3, so try fiddling with the graphics options. 
turning off the bump mapping helps a lot. you won't miss it anyway.

i get ~120fps with 1000wpoly on a radeon 9600np. 
Re: New DarkPlaces Release 20041017 + POM 
did anyone else notice the clipping bugs in POM? there's a few areas where there were invisible walls and such from, what seemed to be the floor edges.

i thought using q3bsp meant no hulls = no clipping problems... apparently not... i don't remember it happening in q3 though, so what's the deal? is the collision detection somehow different from q3 then?
also, the torches were completly white and the plants were fullbright. 
DP + Pom 
Does this mean that DP can run Pom directly or do you need Q3? 
Necros: Clipping problems - I didn't really notice any when I gave POM a thorough spanking - can you describe any specific locations where this occurs?

Of course, one would assume that the collision detection does not use the exact same algorithms as Q3, so there might be some areas where it "feels" different.

The torches, plants and some other shaders are not displayed correctly (the terrain textures don't blend together either), as complete Q3 shader support has not been added to DP (yet). This is cool for people like me who just want to make classic quake stuff, but in the Q3BSP format (and who aren't particularly fussed about spangly shader effects).

Mike: just the POM .pk3 should suffice, Although bear in mind that many shaders will not be displayed correctly. DP is NOT intended as a Q3 replacement engine - it is designed to allow Quake mappers to make classic Quake maps in the Q3BSP format.

Caveat: All of the above is pure conjecture on my part, and quite possibly a load of old bollocks - consult LordHavoc if you need proper answers to these questions. 
Game Over Man! Game Over! 
UK Teletext reports that British director Paul W. S. Anderson ("Alien vs. Predator", "Resident Evil") is to write the sixth movie in the "Alien" franchise, according to sources close to the film maker.

Newcastle-born Anderson, 39, has apparently been asked by Twentieth Century Fox to pen a new script featuring the creatures on their own (ie. no Predators). Whether that includes the return of Ellen Ripley (Sigourney Weaver) however is unknown.

The offer for the moment is simply to pen the script, not to direct as such although that may happen thanks to the success of AVP
that shouldn tbe there, please ignore, it's meant for the Film Thread. 
There are a few reasons DP has Q3BSP support:
1. Nexuiz really wanted to use it.
2. Usually less compile errors; since detail brushes do not result in BSP errors.
3. More flexible collisions; ability to have more than just projectiles, players, and shamblers.
4. Potentially faster rendering; more triangles per surface usually, however ydnar refuses to do the additional merging I requested to make detailed walls render faster. (Technical note: it merges multiple brush surfaces but only if they are flat, all one big flat surface, I wanted him to merge non-flat surfaces in the same room)
5. Patches make curved architecture easier; although good collisions against them are a nightmare to code. (Hence the mentioned collision problems I would like to find a solution to)

I will admit it is rather fun to run around Quake3 maps (both stock and usermade) in Quake1, but this isn't the intent, only a fun toy.

The intent of the Q3BSP support is that people may use it if they wish, just like all features in a modding oriented engine.

As for the darkplaces effects, DarkPlaces is not meant to be Quake, making an engine look intentionally identical to Quake seems largely a waste of time to me.

DarkPlaces is an engine by a level designer/modder (me), for modders and level designers to enjoy, I was not satisfied with the other engines available in early 2000, and still do not see any other engines designed to add new features for modders and level designers to use, so I still see this as a necessary project in the Quake community.

I redid the particle effects because I thought they could be improved, and to improve benchmarks, I feel I succeeded at both of these, some disagree. (Note: as mentioned later the rest of the darkplaces renderer is still slower than Quake however)

My biggest disappointments in darkplaces are currently:

Speed - it pales in comparison to Twilight (which benchmarks over 2x faster than glquake with its skillful design that I have not yet managed to match in darkplaces despite years of optimization, it is very hard to adapt to the Twilight design while preserving the full feature set modders and users have come to expect).

Features - There is so much more to do.

Enhancement criticism - some people rant against all Quake enhancements, I assume they want to play all mods in stock WinQuake even though WinQuake is not capable of the designers' artistic vision. I guess this is similar to wanting a watercolor version of the Mona Lisa because you don't like oil paintings. 
Best Engine For Screenshots? 
I'm going to be redoing my website here in the next few months and would like to actually offer screenshots of my maps. Is there a particular engine that gives the best image quality? I'm not looking for any of the advanced engine lighting ones really as none of my maps take advantage of those features.

Also do any of the engines offer higher DPI? I don't even know if thats possible to up the DPI in a game. But if one of them were able to give higher dpi then 72 that would be nice as I'm also working on a photoshop collage for my lame art class and i was going to use some shots as backgrounds to it.

Anyways, thanks for any advice you guys might have 
Go with a GL engine with overbrighting and 32bit colour depth (FitzQuake, DarkPlaces are two examples). I'm not sure of the maximum screen resolutions for these engines, but they're pretty high I'm sure. You'll also probably want .tga screenshot output for maximum quality.

Of course, you'll want to do a bit of post-processing in Photoshop (I find a simple curves correction ussually suffices). 
...making an engine look intentionally identical to Quake seems largely a waste of time to me.

I think most engine coders would agree with you, which is why I had to make Fitzquake. We all have our niche, I guess. 
"Artistic Vision" 
I assume they want to play all mods in stock WinQuake even though WinQuake is not capable of the designers' artistic vision. I guess this is similar to wanting a watercolor version of the Mona Lisa because you don't like oil paintings.

Well, if I'm making a new Quake level, not a Total Conversion, I think it is important that graphically, it looks as close to Quake as possible (and by that I don't just mean WinQuake - I'd consider FitzQuake as a better Quake "renderer", whilst GlQuake is not).

Then again, DarkPlaces excites me, because it's Q3BSP support is just too cool for words.

I guess I have to find the balance between using DarkPlaces' powerful engine features, whilst still keeping it "Quakey". 
i imagine you could just have a cfg file that gets exec'd on startup which switches off all the extra effects stuff. 
Check It Out 
looks so bad it's not even funny 
I Represent 
The Federation of Newbie Mappers Guild, and behalf of our members, I would just like to say fuck you Jago! 
...thank you, thank you! 
In the long run I think will win DarkPlaces, because is rendered is simply better, is redone and use existing 3d cards features that glquake ignore.

Also glquake whas the "Hello world" test for carmack, not a serius implementation. Theres lots of enhancements to be made, and DP has that enhancements.

Even if you DONT really want a new engine, you sould use DP because will give you smoooother FPS.

So, Imho, you sould use DP by default and change to Telejano if you like it, or Fritzquake for whatever reason people like Fritzquake, but imho DP is fritzquake enough to dont need FQ. 
That Would Be "FitzQuake" 
Darplaces isn't fitzquake enough for me, because it's just too unreliable. The qexpo version did this to me:

(to replicate, just stand still while in contact with the enforcer, and the projectiles all get stuck until you move. It can also be done by other monsters if they infight with an enforcer at point blank)

Now don't get me wrong, I love all the extensions that DP has. If I'm making a fun mod for myself it's the first choice as it frees up most of the restrictions of moding for quake. But time and again the added features create problems for playing through the original quake.

Fitzquake on the other hand has never messed with the original game dynamics, and as long as it doesn't, it'll be my engine of choice for playing maps for the original quake. It's got the same kind of rendering enhancements DP has(which made hacking motion interpolation into it a real pain....) but none of the extra baggage. And that's why we need it. 
To Me 
DP just seems like a futile exercise in excess. It follows the rather amateurish philosophy of "chuck as many features in as possible and it's got to be good!" that most newbie designers seem to follow. Now I know DP is no newbie project, but the final result just comes across that way to me. 
from what i know, darkplaces is pretty well-designed. The problem comes when all these features are enabled by default, becuase many of them are ugly unless the game arwork is designed to support them. In a stock id map or most custom maps, the arwork is NOT. there is no bumpmap, and the auto-generated one sucks. There is no appropriate detail map, so the default detail map makes every texture look like it was painted on sandstone. And so on.

Yes, this is partly a problem of lack of documentation -- if users could easily configure their DP into "normal quake" mode, then they could enjoy quake with DP's rendering benefits, like real-time visibility culling, faster opengl pipeline, etc.

But the extra problem is the misconception that all users want the same thing, or that all engines should provide it.

DP is a great modding engine. Fitzquake is not -- it's main goal is to let players enjoy regular quake and regular quake maps as much as possible. Joequake, proquake, fuhquake, and aquirre's engine are all in similar situations -- they each satisfy certain kinds of user. This is why each community has a different favorite engine, becuase each community has different needs. 
is "Fritzquake" the german version of Fitzquake?

sorry, couldnt resist. 
Jewish version? 
for me the ideal choice of engine is fitzquake and aquire's engine (maybe it's time to call it bengtquake?) because they both look classic but work better. Everything's simple.

btw uwf lol 
I Dont Know What Crazy Version You Guys Have... 
...darkplaces never defaulted to having bumpmapping on for me in any version, i have to turn on bumpmapping, bloom, real time lights, and so on... granted it doesnt look exactly like Quake, but it still feels Quake to me and i enjoy it. it runs fine and runs only slightly slower than FitzQuake (which i only use when specified to use basically because i really do enjoy frame interpolation) while still having the potential of looking awesome (rtlights on dlights makes those multi-ogre battles quite dramatic).

i dunno, ive never had any confusion in using DP aside from when i tried to edit the real time lights in game (as in selecting an entity, and adjusting various fields of it within the console). its straightforward, supports so much, looks good to me, and is the third fastest engine ive tried. that and i can use it for multiplayer as well because it plays the same on nq and qw servers which i like - so to me the difference doesnt exist, its all just servers. i like that level of unity. 
If all you miss in fitzquake is model interpolation then you can try my unofficial attempt to hack it in : - )
Just don't use r_shadows 1, the wonder of an unofficial release. 
does it break anything else ? 
Not to my knowledge, I've been using it regularly since I wrote it and not encountered anything else. I only changed one other bit of code, and that was just adding the monsterclip thing(which isn't required now thanks to the trick Than found which works the same in all engines). So it should be fine. Maybe I should go back and fix the shadows code, I'm sure it wouldn't be too hard... 
you sir, rock! 
No Need For A New Thread 
For anyone who has trouble compiling for example TyrQuake in Linux for this error:
/usr/bin/ld: cannot find -lGL

First try running ldconfig as root.
If that didn't help check what is your "real" in /usr/lib
ls -l | grep

For me this looks like this:
18 2007-09-19 10:17 ->
608400 2007-08-23 11:43
386460 2007-08-28 12:41

The is my "real" one. The -> implies a symlink from to it. What is missing though is a which is needed for compiling. Create a new symlink that points ->

Now make again. :) 
I Am Adding Engines To Quaddicted 
Please help me finding what should be listed about them: 
A New Tyrquake Is Out, 0.6.0 
Metl And Other Engine Coders 
Join the interesting discussion A new standardised protocol? 
Tyrquake, fuck that, where's a new Tyrmap??!? 
Daylight Assault! 
Hats Off To Spirit 
If anything comes of his idea.

The 2 protocols that would be the best are:

1. DarkPlaces protocol 7, so coop play without lag is possible without an expensive dedicated server. (yeah, I know about ZQuake and FTEQW).

2. aguirRe's default protocol with the near infinite limits support. 
aguirRe's with qrack and joequake eyescandy


and same menus to demos and stuff...

that whould take me out of joequake i think... 
Linux Engines 
I just stumbled onto a bunch of Linux engines and their sources: 
I Like Joequake 
I always disable all graphic effects. But i can't turn off the green lightning of the scrags. XD
Not too fond of qrack, it think it's not that stable, but the packet overflow seems to be fixed. 
Pcx Woes 
Is the screenshot function broken in tyr-quake 0.60 (sw, on Linux)? The PCX files I get from it look like this in GIMP: 
I have the same problem, I think it is the bit depth of the X server though (or of the framebuffer, or both). Didn't get it to work yet. Most sw renderers do that.

Tyrann seems to be MIA, so maybe we should ask sezero to fix that. I also have a heap of patches for tyrquake that I don't have anyone to contact about :-/ and a manpage O_o

Even for Joequake I have to start the X server in 8 bit mode to get proper screenies O_o

FTE does working screenies in software, though. Sometimes >:-) 
Sounds Like 
stable and mature software alright 
ah yeah please, bring it on. No, then again, don't.

Thing is, not many people even cared about Linux Quake in the last 13 years. Maybe 0.1 % did. Similar for software. So we have kind of a, umm, steep hill facing us.

Doing only Windows Quake sure was easier. It's 1999, man!11!1 
also, X11 and the GUIs have been rapidly changing. Unlike Windows.

Of course, that created other problems for Windows. :)

People just can live with no change much better than with change. It's easier.

Finally, someone could report a bug. O_o

There's always Fitzquake SDL... 
Yeah, thankfully :) 
Model Format Support Question 
What is the most "acceptable" engine (i.e. least offensive to us funcsters) that supports a model format with 16-bit vertex accuracy - either .md3, or a 16-bit vertex version of good ol' .mdl, or whatever.

Can anyone provide a list of such quake engines? 
i wouldn't mind at all if all engines moved to a 16bit model format. just sayin'... 
Among fitzquake-derived engines, RMQEngine supports IQM format ( DirectQ also seems to support IQM. (I've never actually tried IQM support in these engines, though). 
Right, Thanks 
Although, I can't find anything that mentions iqm support in DirectQ other than a post by mh here saying he doesn't think DirectQ will get iqm support... 
RMQEngine Had IQM Support. 
The RMQ Winter 11 demo is a working example. 
Yeah, I coded up IQM a few times. I don't think it's a viable format for general replacement of MDLs for a few reasons.

Skeletal animation realy needs to run on the GPU otherwise it can get horrendously slow. That means that those working on software engines can't really join the party, whereas those using hardware accelerate may need to bump the entry level to a point beyond which they're comfortable.

Personally I don't think that's a big deal - it's 2014 and everybody has good shader support these days - but for some people retaining the old "Quake will run on anything" philosophy might be important. (There's an irony here in that Quake actually needed quite high-end hardware on it's original release, but that's probably a topic for a separate discussion.)

Also I favour taking a minimally invasive approach towards content replacement formats. Some of the thinking behind BSP2 was that it should be easy to add to any engine and/or toolset, that it should work in both software and hardware, and that it should use the very same map format as before. I think this really helps adoption - if someone can more easily add it to their engine and if it just works without compromise, then they're more likely to add it. On the other hand if it involves importing 1000s of lines of code they may not even understand well, if it doesn't play nice with existing code, and if half of it breaks in software, then it's not going to be as popular.

That's why BSP2 didn't get features like coloured light, 32-bit textures, surface flags, removal of fixed hulls, etc. All of these would have been cool to have, but they would have also been barriers to adoption. (The fact that it went from not even being on the radar to being fully specified and coded over the course of an evening or so also contributed, as well as explaining some weirdness like the fact that I missed out on switching node and leaf bboxes to 32-bit in the first version.)

A replacement format doesn't need to be perfect or have lots of extra features; it just needs to be sufficiently good enough and easy enough to implement so that it can drive adoption.

A 16-bit (or why not just go full 32-bit?) variant of MDL would meet that description. 
16 Bit Backwards Compatible 
I'm sure I read a suggestion once before to bung the 16 bit info at the end of a standard mdl file, so essentially it's all in a single backwards compatible file. Just literally after the standard frame data (which is already at the end of the file) have a second set of vertex coordinates which "refines" the 8 bit data with a second 8 bits of precision:

pos_16_x = orig_x * 256 + refine_x

That kind of thing. I'd be able to create a test mdl or two like this pretty easy with qmdl at the stage it is now.

QME might choke on it though, as once upon a time that's where it stored extra metadata for editing models. On the other hand, the existence of QME created models that are carrying that kind of added payload does suggest most engines let you get away with extra data appended to model files... 
yeah that's totally what I was thinking. Just taking the existing model format and going from 8 to 32bit for storing vertices and skin coords. (like you said, why not!)

It means getting existing tools to work with the new format would be very easy too because it'd just be a matter of changing the header being used to read the files and changing the storage data types to 32 bit.

I think skeletal animation can be really cool, but straight up vertex deformations are no longer possible on the mesh and now need to be driven by bones which increases model and animation complexity by quite a bit.

For example, say you wanted to animate something weird like a tentacle that can stretch. You might go with splines if you were doing a normal .mdl, but the engine would not recognize that kind of skeletal structure, so you'd have to rig some crazy deforming bone hierarchy thing which, while possible, is nuts...

And under normal circumstances, the only real boon to be had by it is so you can get the feet to line up with slopes via IK.
Any mod that's going to do something really wild with the skeleton like having some kind of procedurally generated stuff would be some really heavy duty mod that'd be better off on a crazy modder engine anyway. 
that is very clever, and I definitely see how it can be a good thing in that you only have one model that will automatically use better precision if available. 
Thanks For The Useful Info Guys 
I agree - my preferred choice would simply be a .mdl with more bits for vertices. Sounds like it's easy to implement and stands the highest chance of getting into as many engines as possible.

I'm not too into skeletal formats in quake, for the same reason necros describes.

Ok, basically I'm making monsters for a mobile game. I own the assets and can do whatever I want with them, so it occurred to me one day that I'm building these very quakey looking monsters with a very quakey polycount (about 400 pollies for most), and it might be nice to one day turn 'em into quake monsters, but then the quake 8-bit vertex thing rears its misshapen, wobbly head and kind of deflates my enthusiasm a bit. 
Preach, that's a cool idea of tacking the lower 8 bits of each coordinate on at the end of the file. Only concern I have is code to find that refinement block could be ugly; you'd have to parse all of the structures in the mdl keeping track of the largest byte offset from the start, then if that offset + 1 is still within bounds, try to parse it as the refinement data.

Perhaps a cleaner way would be just leave the mdl file alone and dump the refinement data into another file (.bsp + .lit style), so you'd have shambler.mdl + shambler.16b (or whatever). Whenever loading a .mdl, the engine could check for a .16b file, and if present, use it to enhance the precision.

It feels a little wrong to create yet another model format, but the beauty of this would be it would work on all quake engines from the beginning, just without the enhanced precision. 
I dig that, sounds like a nice way of keeping the fallback .mdls "pure".

best of both worlds! 
it would also avoid potential problems if the model was loaded into QME. you wouldn't have to worry about the old editor clobbering the new data. 
Actually, qme already supports 16bit mdls. If you use the 'save' option instead of the export option, it'll write out an mdl format with a load of qme-specific data on the end of the file.
figure out the extensions and get some engine authors to support it, as well as a blender exporter.

regarding iqm, there's no reason that an engine couldn't just transform verts on load and then interpolate from there the same as they do with mdl (or just skip interpolation completely, if you really like vanilla quake).
Even geforce2 drivers will emulate support for vertex shaders.

iqm omits skingroups, so cannot be used as a pure superset (ignoring animation differences). luckily these are rarely used, and where they are used, they're often better replaced with a shader instead anyway. assuming your engine supports shaders...

mdl has other issues, like texture coord positions precise only to a texel, a single surface, implied flood fill requirements, onseam stuff is ugly as hell (and unsupported in any tool but qme (which breaks when onseam stuff isn't used)), palette limitations.
but worst, many of the limitations of mdl are not with the format itself, but with the engine.
by the time you have 1000 verts, all of those glVertex calls will be a significant time waster.
frankly, if you're going to rewrite enough of the engine to remove those limitations, you might as well add support for md3 too, which is typically easier to export to anyway.
ultimately, I don't see any point in mdl extensions unless qme can write them. backwards compatiblity is pointless if its going to just look terrible anyway. 
really? i wouldn't really let QME be a deciding factor at all. it's shit...
Best results with models always involves avoiding the use of QME in the workflow. 
backwards compatiblity is pointless if its going to just look terrible anyway

I tend to agree. The only reason to use 16bit or more accuracy is for large models with a large range of movement that *would* look terrible in 8-bit. If most users are going to see an awful mangled .mdl version of it anyway, then I would say the idea has failed. 
things like the vermis come to mind. or monsters that move around their model space a lot. 
It could be that using md3 makes more sense than a MDL + new 16bit refinement format.

I could have a look at how difficult a minimal md3 implementation for fitzquake/qs/glquake would be. 
would be just awesome. 
Kinn We Get A Preview Of Your Models? 
Pwease ^_^ 
maybe, except with preach's idea, a 16 bit model would be fully compatible with even winquake/glquake. 
To Be Honest 
If you're gonna have a separate file, you may as well make it a MD3... 
True dat. Add MD3 support to the engine and boo-ya... 
If nothing else, md3 support saves creating a new standard. :P
Plus its already supported by a load of engines.

Software renderers might get something out of: but its too long ago for me to really remember much about it.

I'm tempted to port fte's mdl/md2/md3/iqm/zym/dpm/psk/md5 loader+renderer to glquake, but I doubt any engines would actually use any resulting patch which kinda makes it pointless, plus I'm feeling lazy. 
I'm tempted to port fte's mdl/md2/md3/iqm/zym/dpm/psk/md5 loader+renderer to glquake, but I doubt any engines would actually use any resulting patch which kinda makes it pointless

I touched on this above, but this is actually a great example of why certain features don't make it to widespread adoption.

You're right in that nobody would use the resulting patch, and the reason why is that the resulting can only be overly complex. 8 model formats and a renderer (I assume it's a single common renderer for all 8) is just too much. It touches too many parts of the code, and adoption would involve too much surgery, particularly if an engine author has already done work on these parts of the code themsleves.

In order to drive adoption features need to be easy to adopt. By way of contrast, an MD2 loader that brutalizes it into the same in-memory format as MDL (and they're not too different so it wouldn't be too difficult) would be just a simple matter of a drop-'n'-go loader, some simple struct modifications and another line or two here and there. That's the kind of feature that gets adopted. 
1) but this is actually a great example of why certain features don't make it to widespread adoption

2) particularly if an engine author has already done work on these parts of the code themselves

In very recent times, I have become increasingly convinced that many programming languages --- especially C -- are broke by design.

At first, this sounds crazy. Because C is incredibly powerful and amazingly well constructed. And the assertion that C is "bad" means virtually every programming language is bad becomes most of them mimic the behaviors.

But I am convinced C is a terrible programming language (and almost all the ones we use):

Let's assume there is problem X and solution Y.

1. An "ideal programming language" (which probably does not exist at this time), the abstract solution does not get reduced to code. The abstract solution becomes a very specific implementation that drifts away from the abstract solution.

This is a characteristic of most programming languages -- and it is terrible.

2. C offers too many ways of doing things. Many of these ways are ridiculous. And coding towards a specific implementation vs. abstract solution is actually rewarded by the language. So you get stuff like this:

g = (byte)((((k & 0x03) << 3) + ((j & 0xE0) >> 5)) << 3);

3. A good example of C encouraging drifting away from the abstract solution is short-circuit evaluation. In a specific implementation, this might make sense but backing up a bit would deny a highly intelligent or advanced compiler from deriving intent. The order of logic in a statement using short-circuit evaluation doesn't obscure the logic --- it actually removes the information permanently -- so a highly advanced compiler could never know if the order was important or the programmers best guess of the right order for speed.

As a result the language doesn't offer:
1) Collective works
2) Additive gain
3) People spend their time reinventing the wheel.

And because the language offers so many coding styles and ways of doing things, you could draw an entire org chart of different styles.

This results in the kind of failures seen in Quake, where engines struggle to adopt features that have been common place in other engines for a decade --- because the abstract solution never gets reduced to code, but an implementation-specific solution.

[Of course, if a language is ever written that does this right, it will have to be written in C ;-)] 
You've more or less restated the problem that OOP was meant to solve.

The nirvana here was supposed to be that you could have components expressed as reusable objects and then all that you need to know is the public interface of that object and you can link to it and use it without having to worry about it's internal implementation.

Likewise if you're writing such a component you specify and document the public interface and the same magic happens for anyone using it.

At a sufficiently high level of abstraction using these objects becomes broadly analogous to putting Lego bricks together. Join a "model" object to a "renderer" object and you have support for a model format. Want to support another model format? Just drop in another object and if it understands the interface to the "renderer" (and vice-versa) you have the awesome.

True, the person writing such an object still has a lot more work to do, but that's a one-time-only job and then everyone gets to join the party.

Of course the end result we have today is somewhat different to this ideal world, but hey-ho, you can't win them all. -> " 93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. " 
But It Isn't True 
And you've been tricked! There may be 99 gems of actual wisdom on that page, but you've fallen for decoy with that one.

If two programmers will code essentially the same solution, the programmers are NOT coding.

Rather the programmers are, in fact, acting as the compiler.

This is a waste of human time. 
I think the point is more that observing that this is a problem does not bring us any closer to a solution. Languages like Haskell are finally getting more widely used these days so maybe there's hope for the world (although I found Haskell pretty hard for just getting things done when I used it, that was 15 years ago now though...). 
The problem is this: A compiler is a transformation program that transforms one model to another. In the case of a C compiler, the input model is source code that conforms to the C spec, and the output is machine code that conforms to the spec of the targeted platform.

The input model is already an abstraction in that it abstracts (somewhat) from the details of the target platform. As you know, abstraction means omission of details, that is, every abstraction entails a (purposeful) loss of information. In the case of C, the missing information (platform details) can be added by the compiler because the information can be derived from the C spec and the platform spec.

What you want is even more abstraction, which again entails more loss of information. The question is, how can we get this information back during compilation? If you want an automated compiler from your more abstract input model, you need to store the missing information somewhere and add it back in during compilation. This is how toolkits work. For example, in a game toolkit like the latest Unreal Engine, you work on a much more abstract level, and the missing information (that is, how to render things, how to handle input, how to handle sound etc.) is added in when the game is assembled by the compiler.

Basically, the missing information is again stored in a platform specification. In this example, the platform specification is the specification of the engine, its toolchains, its file formats, and so on. Of course all of this abstraction comes at a price, and that is less flexibility. You are restricted in what you can do with the engine and how you can do it so that the "compiler" can add in the missing information.

But what you seem to want is having the ultimate flexibility AND a large degree of abstraction. You want to specify a very abstract solution and have the compiler figure out how to generate machine code from that. Again, the compiler needs to add the missing information, but where does it come from? If you formalize it somehow as a model, you must again limit the user / programmer in what she can do with your system.

And therein lies the problem: The more abstract your language, the more restricted it must be. Don't want do deal with memory representation? Use Java, but suffer the restrictions in performance and memory consumption. Don't want to specify types and such? Use Python/Ruby/whatever, but suffer the restrictions in performance and safety.

The challenge of abstraction is to balance it with flexibility, and apparently this is such a hard problem that the entire software engineering discipline has not been able to solve it (generally) and is nowhere near a solution, too. Some abstractions (languages) are "good" in this sense and others are not, but we don't precisely know why.

But! you say - can't the computer guess the missing information somehow? My brain can do it, so the computer should be able to, too! No, it cannot, because it's not creative and needs precise mathematical descriptions. Only our brain can do this.

But! what about Prolog and such? You don't even need to specify a solution, only a problem! Yes, but specifying complex problems so that a system like Prolog can derive a solution is (in general) much harder than inventing a solution in your head and coding that up, even if that's hard too. Logical programming is very useful for a specific set of problems, but it is more targeted at the scientific and engineering communities and are usually applied in AI and computer linguistics. You can't write a 3D game in Prolog (AFAIK), nor would you want to.

So, I for one don't believe that there will ever be a system that will write your code for you. Or if computers ever get "smart" in this way, I doubt we will be around to use them. Maybe our grandchildren will. 
make a trenchbroom for C code!.. 
Imho C is a necessary and best kludge to get the most of out hardware and hence is the underpinning of serious programming. C++ is an even uglier but still great kludge for the reasons sleepwalkr says.

But I for one *love* my main language. Wish/Tcl is a beautiful archaic thing with aspects of functional programming,and great interfaces to a huge (slightly ugly) graphical toolkit, and to C/C++ as well.

wish <<!
pack [button .b -text "Func is.. " -command {.b configure -text Dead ; update ; after 1000 ; destroy .}]
MD3 YES? :) 
MD3 support for Fitzquake and Quakespasm!? :)
I for one can use this already... I'm using it to replace models for KMquake2 and currently working on a new Shambler model for the Original Quake. But ofcourse it ends up as an MDL in Quakespasm and Fitzquake... My pipeline goes from 3dsmax exported to FBX and then I simply use Neosis for the conversion to MDL right now. Works perfectly but the model formats lack of precision makes me sad. If somebody adds MD3 support I could pretty much instantly take advantage of it. I would still use the quake palette though because I prefer the pixel retro look.

IF you add it I will use it! Regardless

Here is a sneak preview for those wondering what it looks like. 
ACK Better Link 
i've seen vertex dancing on md3 though... it's a lot less, but it's still there. is there no better format? 
what about something similar to external textures...
so you have your player.mdl
and then you have player_0.fbx, player_1.fbx, etc... and give external model information.

the workflow these days is to export multiple single frames and use tools to merge them into a .mdl anyway, so for the modeller, it's not adding any steps anyway. 
@mwh, Sleepwalkr, Etc. 
mwh:I think the point is more that observing that this is a problem does not bring us any closer to a solution.

I just want to prevent myself from writing bad code in the future (and I hope I have the definition correct and complete). And needed to know what "bad code" looks like --- bad code isn't obvious.

That is all I can do.

sleepwalkr:So, I for one don't believe that there will ever be a system that will write your code for you.

Is anyone actually writing any complex code to begin with? I don't know that ..

1) Anyone is.
2) If it is even possible to do so.

You've put tons of work into Trenchbroom, but isn't it all rendering triangles by distance at the end of a frame, when everything is said and done?

Developers: creators of simple works, using crude tools. Rewarded with praise for winning the endurance and stamina test using crude tools that are hard to understand, use correctly and master. The idea conceived in seconds, the debugging achieved in hours, but the implementation --- should it ever come --- will take months, if ever at all.

However, if you master a low-level language like C, you can do almost anything without any natural limitations except time. Knowing time is the limitation, I want to re-evaluate my use of it.

I do know the definition of insanity is doing the same thing over and over and expecting a different result.

I think this sums up current thoughts on the subject quite well:

I debated on clicking 'Submit'. Logic says no. The Labatt's Blue says "apathy now". And who am I to question the logic of beer! 
Too Bad To See A Nice Post Go To Waste 
Just a quick reply then:

You've put tons of work into Trenchbroom, but isn't it all rendering triangles by distance at the end of a frame, when everything is said and done?

Not by a long shot. 
bad code isn't obvious.

I take offense to that. Mine certainly is. 
Engine Coders... 
Currently we can choose between linear filtering and nearest-neighbor filtering. How about giving hqx a try? 
The filtering that is currently available is there because the hardware supports it, hqx would probably have to be done by up sampling the textures in software and loading the higher res images to the video card. Which you could also do manually using external textures. 
Question is would hqx even look good on quake textures, since it's designed for pixel art 
Yeah hqx only looks half-decent on stuff like nes sprites - In Quake it would just look like you've upscaled the texture then run them through some ugly watercolour filter or something. 
I looked into other texture filtering once and it is not worth it unless you are into amateur painter art. 
No idea what I used to create them but here is scale4x: 
Sorry, I Should Stop Using That Site, They Had Direct Download Links.. 
8-bit Software Renderer + Bsp2 
awesome, always good to see bsp2 on a wider range of engines! 
Very Cool 
also, that RRP video revealed to me a design flaw in the burning player effect from rubicon 2 -- if your health is > 100, you can't pick up a health pack, which means you can't stop the burning! 
Especially that MadFox map for RRP looks good. 
I Love This Engine... 
It really is fun to play Quake on, and it's often overlooked (I have to remind myself it exists occasionally). What I really love is low-grav + gore. This makes Quake even gorier :)

Here's some gore screens from my low grav map (coming soon I hope) - 
super8 - pretty cool, but when fog and coloured lighting is all going on, you tend to lose a lot when you try and map that back to the quake palette. 
Super8 - played in it for five minutes - could kinda do with "make it look/sound like quake" preset in the options :)

Over-the-top weapon bobbing craziness...quake's 8-bit sounds up-sampled to whatever...starts with a funky palette bend by default...not my cup of chai I'm afraid :) 
I wish you guys realised how bloody annoying Dropbox is. Every time I click a link here, I get a popup if I want to join it. 
Yeah - Seriously Just Use Imgur For Picture Uploads 
Uhh, is the new bobbing combined with the regular bobbing? It looks like the weapon is twitching in all directions at once. 
you have to join it
It is simple as that 
Why Wouldn't You Use Dropbox? 
It's literally the most useful thing I've ever signed up to, it's the first thing I get going after a fresh install.

Seriously just get it already. 
Why Wouldn't I Use Obnoxious Bloatware? 
This boggles the mind!

Use imgur or GTFO. 
Uhh, is the new bobbing combined with the regular bobbing? It looks like the weapon is twitching in all directions at once.

Fook knows. Also, whether the weaponmodel idles on the left or the right depends on player facing angle! Doesn't appear to be an option to make it use sensible behaviour either.

Oh well, one less engine to keep track of I guess!

*deletes it* 
Why would I use a US-based, unencrypted, closed source data hoarding company?

Syncthing works great for synchronization. And for temporary hosting there are tons of options that do not require account or have surveillance-loving warmongers on their board. 
The new bobbing is being controlled by the following commands:


Setting "up" and "side" to 0 turns it off and reveals that, indeed, old forward-back bobbing is preserved. Therefore, to make the new bobbing look good, you also need to set "cl_bob" to 0, but then the camera won't bob.

I didn't find a way to make the weapon's position independent of the player's facing angle. 
I didn't find a way to make the weapon's position independent of the player's facing angle.

Super8: Your weapon is literally a compass. 
DropBox links are fine if you know how to use them. Click this ... nice, huh? 
"Why Wouldn't I Use Obnoxious Bloatware? "

DropBox? It's literally one of the most useful things I have installed on my machine. It's always the first thing that gets installed on a new machine because I store pretty much everything in there from app installers to settings to ... whatever! 
Weapon Bobbing 
Most people either love or hate this engine. Personally I hate it but I can't quit it ;)

The default weapon bobbing might be a tad too much motion (the tendency with a new feature). But like dwere, I am unable to duplicate the compass effect.

Kinn: Did this happen on a particular map or settings change?

Fifth: great shots. I am waiting patiently for the pack.

Classic settings: r_palette palette; fog 0; r_coloredlighting 0. Maybe a couple other tweaks to meet tastes. I likely won't do a menu preset due to lack of consensus... most existing users want a finer grain of control (cvars).

Fog: Imagine a world without fog, only well-composed lighting and textures to lend a sense of depth. As much effort was spent on fog as any other feature. Maybe that's why I feel burnt-out on this effect. Colored-lighting + fog +8bits = compromise, and there are many ways to slice it. Engoo has a different approach and aesthetic for fog and lighting as a comparison.

RRP burn: WTF? --> 'oh yeah...' --> LOL 
MFX X 2 
I was starting a vid of the OTHER mfx map, then decided to do something different, not realizing at first there were two.

For classic config, I might do a separate commented cfg file. Most users interested in that can handle cfg. 
Dropbox Is Pretty Cool 
Loads of free cloud storage! 
Why Would I Want To Store Clouds 
Cheers, sorry if I come across as harsh/unreasonable - many of us here are purists who roll our eyes at anything that deviates from the original aesthetic as laid down by WinQuake, although tasteful fog, and subtle coloured lighting (although my right eye does a little involuntary twitch at the mere mention of it), seems to have caught on around here in recent years.

When I get a moment i'll post some screens to illustrate what I mean by the "compass problem".

A "purist" .cfg file would be grand, thanks. 
I Think 
when it comes to "purist" engines we already have several that do an excellent job. I don't mind seeing other engines, I think at some point I need to configure Darkplaces to how Sock seems to use it because it looks nice. 
To be honest, qbism looks a lot more like how I remember Quake looking when I first played it compared to a modern OpenGL engine in high resolution. 
Pi"Quake"sso is the 1996 best game ! 
Why Would I Want To Store Clouds

For the same reason that you have a locker for your own personal rain of course. Because you can.

(rain locker = shower in case you didn't know that) 
when it comes to "purist" engines we already have several that do an excellent job

super8 does software rendering tho - this is important.

That said, if Quakespasm were to introduce some shader magic that truly emulated the look of software Quake...droooooooool 
Theres an engine for doom called Chocolate Doom that's very much a "pure" engine, we could do with a Chocolate Quake 
Chocolate Quake Already Exists 
It's called Winquake. 
well obviously WinQuake doesn't run maps with modern limits, bsp2 and all that bojangles. 
Hahaha... yeah I guess it does. :) 
Chocolate Doom also doesn't run maps with modern levels of detail. 
I wonder if there's an argument going on right now on the Chocolate Doom forums where people are saying "Over in the Quake community they've got this whole engine family called Fitzquake that plays modern maps with raised limits and levels of detail but visually stays true to the original aesthetic, why can't we have that?" 
Spirit Hits The Nail On The Head 
I ripped-off the trendy adjective 'meta-nostalgic' from a news post to differentiate from pure retro. Time candy-coats past game memory and dilutes it with MW3.

Kinn: No offence taken, candid first impressions are valuable. Sustaining the genuine feel of classic Quake while removing the burrs and sharp edges is a major historical preservation/ UI project on it's own.

Aside: The Requeim engine includes deep and subtle tweaks to improve gameplay of older maps and nasty old progs. This is code worth stealing. For example, the 'impulse 12' hack gives weapprev support to mods like Mexx.

Magic 8-bit shader: Everyone wants it. Is it even possible? Can the palette be shoved far enough upstream not to look like a downsampled fake? 
Doom Retro a limit-removing fork of Choco Doom, but demo recording is disabled.

Doomsday can be set up for classic aesthetic. The slick GUI provides amazing fine grain control but feels more like Doom3 than Doom. 
Regarding 8-bit gl shaders, try quakeforge's gles renderer which uses the colourmap and everything. 
Fitzquake renders in OpenGL, so I doubt that it would be considered true to the original aesthetic by Doom community's standarts.

There are plenty of different Doom source ports out there. Most of them have increased limits, a lot of them have at least some additional modding capabilities, and it's not uncommon for them to preserve the software renderer. 
Well tickle my ptarmigan - that's the first I've heard of quakeforge, and that looks awesome. Ok, we need that in quakespasm. 
Doing it requires bumping the hardware requirements to something that supports fragment shaders and dependent texture reads, with good performance. Broadly equivalent to something that can run Doom 3.

Since this is something that the Quake community as a whole seems incredibly reluctant to accept, it's unlikely to happen in an engine like QS. 
Broadly equivalent to something that can run Doom 3.

So, my laptop from 2006. cool beans.

Anyway, I was only suggesting it as an optional option, not the default or anything. 
I'd Say Keep It Simple 
A source port like Fitzquake/QS shouldn't turn into bloatware, IMO. Although forking it may be an option. 
True, but I think anything that moves the visuals closer to the original game is a worthy change. 
I'm entirely uncertain how such added functionality could be called "bloatware". 
One of the definitions of bloatware is that it has "higher hardware requirements than the previous version whilst making only dubious user-perceptible improvements". 
quakeforge is probably the most overlooked yet impressive engine out there. taniwha put a lot of work into it (and its tools) the last years. 

So, explain how adding a new shader to bring the hardware rendering more inline with the software rendering is bloat. That's a great goal to shoot for in many people's eyes. 
Emulating software mode using hardware rendering with fancy shader tricks seems like too much hackiness for such a "practical" engine. Even if the hardware requirements will stay the same.

Especially considering that the difference between software and relatively simple hardware rendering is not that big in Quake compared to Doom. You really need shaders to emulate Doom's light diminishing feature, because it can't be properly emulated with regular hardware fog, which affects the picture big time. On the other hand, shoehorning the picture into the palette is a purely cosmetic feature. 
So 2x overbrighting is also "bloatware" to you then. Because that raises the hardware requirements too (either by way of extra functionality via GL_ARB_texture_env_combine or extra GPU muscle by way of multipassing). Likewise fullbright colours. 
Of course not. Those are important features, their absence in GLQuake was a flaw (unless you're aguirRe).

Whether true color rendering is a flaw is highly debatable. 
It's About Aesthetics - Not What's A "flaw" And What's Not 
I like the 8-bit look for the same reason people like pixels. Same reason people like model interp turned off. Same reason people don't like coloured lights.

And so on. 
I'm Confused :( 
I like colored lights. And I like all other things, except for different reasons. 
I Was Just Giving An Example Of One Set Of Tastes 
Not saying everyone here has those tastes.

I mean, I like fog, which makes me a hypocrite I guess. 
For the record, I'm not saying that 8-bit rendering shouldn't exist, I'm merely expressing my doubts about having this implementation in QS. 
Had an old laptop with EGA(?) video once. Down sampled everything to 256 color fixed palette with dithering. Quake looked like a cross-stitched scene. 
This Also Needs To Be Said 
One of the definitions of bloatware is that it has "higher hardware requirements than the previous version whilst making only dubious user-perceptible improvements".

It's the case that a certain amount of what software Quake did can only be accurately replicated using fragment/pixel shaders, and I'm not just talking about 8-bit reduction here.

Water warp, underwater warp and scrolling sky are shader effects. It's true that QS (and by extension Fitz) do reasonably decent approximations, but they remain approximations and come with extra overhead of their own (such as hitting the framebuffer and bandwidth quite heavily, massive vertex counts, etc).

The fact that they're approximations means that glitches are still visible if you know what to look for and where to look. And they're the kind of glitches that, when you see them once, you're just going to keep on seeing them.

Keeping the GL_VERSION at 1.1 works counter to what seems common sense in these cases, because it involves performance and quality tradeoffs elsewhere. Brute-forcing something on the CPU that can be done simply and elegantly on the GPU, particularly on what is nowadays entry-level commodity hardware, is a dead-end.

For a specific example, take the sky code. Have you seen FitzQuake's sky code? Sure, it does an awesome job given what it is, but it's also 1013 lines of crawling horror.

A shader-based approach, bumping the hardware requirement to GL2.0 (i.e entry-level commodity hardware) can be done in maybe 100 lines by comparison. It's simpler, clearer, more robust, easier to extend, has less unwanted side-effects if you go hacking at it (and less interactions with other parts of the code if you go hacking at them), it's higher quality, and guess what - it will also run faster.

The thing is: most players won't even notice the difference. But the difference is there, and just because an improvement isn't user-perceptible (or it's user-perceptibility is borderline) doesn't mean that it's not worth shooting for.

It's also one-tenth the code so it can hardly be classified as "bloated".

Emulating software mode using hardware rendering with fancy shader tricks seems like too much hackiness for such a "practical" engine.

I understand what you're saying here, but the example I've given is just one case where Fitz/QS emulates software Quake (nobody seriously wants GLQuake-style sky back) using hardware rendering but without fancy shader tricks. And the simplicity and practicality that you ascribe to Fitz/QS just isn't there. 
My Heart Is Broken 
I'm going back to Winquake. 
Oh man, if we could get proper water effects again like in the software renderer that ALONE would be worth the price of admission. 
I Still Use Winquake... 
because my pak is going to be WQ compatible :P 
Water effects are likewise easy and fast with shaders, but they do need the dFdx/dFdy instructions for the best quality, which means GLSL 1.10 or higher is required. This equates to the second generation of GL 2.0 class hardware, because while the first generation will support these instructions (which it has to by spec), it will quite likely software-emulate them.

The reason why it needs these is because the warped texture coords will cause a shifting between miplevels as the texture warps. It looks really ugly when nothing else is moving and you see a teleport shifting back and forth between higher and lower miplevels in patches and over time. (This is another glitch that you normally don't notice but once you become aware of it - mighty fuck...)

By taking the derivatives for the base (unwarped) texcoords, then doing the warp, and finally plugging the warped texcoords plus the unwarped derivatives into texture2DGrad you get a solid image with no miplevel shifting coming out. 
MH, thanks, that's interesting.

Would people use underwater warp in QS if I added it? I think it would be fairly easy... I recently put in render-to-texture gamma correction with a glsl shader (so we don't need to use SDL's gamma functions, which don't work for a lot of people, mess up the whole monitor, etc.); the water warp code should be pretty similar to that.

regarding software lighting emulation in QS, personally i'm not that motivated to work on it. If it can be done without actually uploading 8-bit textures and doing lookups for lighting in the colormap, but just sampling the lightmap and then rounding the value, it's probably not too bad (add another world drawing function that uses glsl, and modify the existing glsl mdl code to support that). 
What I said above applies to water surfaces, not underwater.

For underwater I've found that perturbing the texcoords by a noise texture that's scrolled by time gives a more pleasing result than a sine wave warp.

The fun part is dealing with edge clamping where the 3D view meets the status bar or the fill texture.

Underwater can also be more reasonably emulated on the CPU using a grid and warping per-vertex, similar to what stock Fitz uses for it's r_oldwater 0. That practically is underwater warp already. 
I'm pretty certain you can emulate the 8 bit look by taking a 24 bit color grading look-up texture, converting it to Quake's 8bit pallete and back again. Should be a pure post process approach. I know it's in Sikkmod and Unvanquished (and virtually every AA engine). Don't know about hardware requirements... 
I'm in the purist camp that plays with GL_NEAREST but even I could do without palettized lighting - too many cases where tasteful colored lighting could really go to shit in a hurry - but if it's a mode that can be toggled or it goes into its own fork, it would be great that it exists.

Getting waterwarp back and such would be hot, but the point about hardware requirement creep is an important one. I'd hope that if waterwarp makes fire shoot out of my laptop, I could turn just waterwarp off and the rest of the engine would still hum along with its present low requirements. The reason that I hope that is that adding GLSL based fancies kind of opens the floodgates for finding better ways to do everything else in GLSL also and suddenly Quakespasm is a GLSL engine. 
It cuts both ways because so-called "GLSL based fancies" can actually be significantly more efficient than brute-forcing something in software.

So in other words, using GLSL for water and sky surfaces will run faster and put less strain on both your GPU and your CPU. So by bumping the hardware requirement a little, the engine can be made more efficient all-round.

Regarding underwater warp, I'd propose that 3 options would be acceptable: off, low-quality (the current effect) and high-quality (a GLSL-based effect). Something like that should suit everybody's requirements. 
Like Button 
I think we're on the same page.. QS 0.90 will use some newer GL features than Fitz if they're available on your hardware (world/bmodels stored in a VBO, non-power-of-two textures, and the next release will be able to use GLSL for .mdl rendering.) However, these are all optional - there's a command line flag to disable each extension if needed, and I tried to keep the implementations isolated from the original code. The hardware requirements won't be going up. 
The Latest Fitz 
supports NPOT textures already. I know, I begged for it to be added. :P 
Mark V Though Fifth 
not original fitz.

Also, personally I dont see any issue with what mh is suggesting at all. If there is an engine that does bump up hardware requirements that everyone already has but it is more efficient, what is wrong with it being available as a choice? 
10-bit Color? 
10-bits= 1024 color palette. More subtlety to fog and colored lighting while still blending consistently with the 8-bit textures. Possible in gl 2.0?
Engoo does an elegant job of this in 8-bit. The lighting must be designed with the palette colors in-mind for best effect. 10-bits is more flexible. 
8-bit Colour 
For me it's an "all or nothing" thing - i.e. it's only worth doing if the exercise is to emulate software quake's visuals exactly, right down to all the nuances - otherwise stick with true colour and reap the benefits of coloured lighting, fog and whatnot. 
It's worth reminding people that Bengt Jardrup has a version of WinQuake that does nothing fancy beyond raising a ton of map limits.

I remember playing Tronyn's Arcanum episode with it, and the experience was nothing short of...religious.

I don't think that engine has been updated since 2007 though, so I don't know how it would handle many of today's maps - certainly wouldn't load bsp2. 
Yeah, About That 
Would it be feasible to combine bsp2 support with real software renderer? What about framerate on giant maps? 
I'm with Kinn.

Well, mostly ... I mean, I'd be willing to accept colored lights and fog and all that as long as that, too, conformed to the Quake palette at all times.

Might be an interesting look! 
Dwere, Meet Qbism. 
Don't Know How I Missed That 
I wasn't even drunk. 
I'm With Kinn Too 
Well, the framerate in RRP is bad. But it's kinda predictable. What I really don't like is how the engine distorts everything in 4:3 modes.

Not everyone has a widescreen display. Some people have widescreen displays that can show a 4:3 picture without stretching it to fill the screen.

=> It would be nice to have the ability to control aspect ratio correction in the options. 
Old 4:3 Display... Pentium 3 Laptop? 
I have a similar 4:3 situation on an old laptop. Set vid_nativeaspect 1.333 in the console. By default super8 will guess aspect based on the highest available resolution.

Rolling with 8-bit purism theme, the only legitimate framerate comparison is with Quakeforge and GLSL simulated 8-bit. How's that compare on same machine? 
Also Framerate 
Biggest boost to framerate would be fog 0 in console. But it will never reach Quakespasm fps. (Well, maybe on fast CPU with lousy GPU.) Among all bigmap-capable engines QS is the fastest I've seen.

I usually set cl_maxfps to 24. In SW mode it doesn't feel as choppy as one might think. Hardcore is 12 or maybe 10. Might have been thrilled to get 12 fps in '96. 
I don't know if it's the same issue, but just realized my fov compensation is slightly off-center. The effect is that the view and the vwep are not rotating on the same axis. Fixable. 
Yah, what you said sounds like the culprit. Here is the porblem as I see it:

Look left:

Look right: 
>> Pentium 3 laptop?

No, but I often use 640x480 to improve performance, because it's the smallest resolution available to me.

Thanks, "vid_nativeaspect 1.333" helped, although 2D is still distorted. That was my main gripe, really, because unfiltered artwork looks very ugly when stretched by the wrong amount.

>> The effect is that the view and the vwep are not rotating on the same axis.

TBH, it's the case even with the vanilla engine, although it's not nearly as noticeable. 
Thanks for the pics. Bob settings move the model but scr_ofsx, y, and z move player POV. Hadn't thought about that before.

aspect: It might be possible to affect 2D graphics by the override as well. Will look into it. 
Does snd_speed "11025" work? I set this in my config but the sound still seems all crisp and squeaky, like it's stuck at a higher value...? 
QuakeForge, Windows, And Fullscreen? 
Anybody here using QF on Windows 7?

I was giving it a try, and I can't get it to go fullscreen. Console just says "vid_updatefullscreen: error setting fullscreen".

Googling just turns up a lot of "yep that's a problem" sorts of pages, either about QF specifically or about SDL on Windows, so I thought I'd ask here if it is a known QF issue that has a fix/workaround.

Perhaps related: the framerate tanks if I leave QF in windowed mode but increase it to some usable resolution (like 1280x720) using command-line args. 
I Have Same Problem On Windows 8 
I tried QuakeForge - can't get it to do anything beyond a 320x200 window.

Buggered about for a few minutes with configs, command line bollox etc, then gave up. 
Sound initialization occurs very early in Winquake. It's in the video code prior to video initialization. According to code comments, this is so that a pop-up error message could be displayed if the audio card is already in use by another program.

In next build this will be a command-line setting:

Really the only the way to get to it without possibly breaking compatibility. Because that is the case, will leave the original 11025 as default. 
can set -width 800 -height 600 (for example) in cammand line to get a bigger window. Still won't be fullscreen, and the FPS is very low for me. 
is so damn buggy. I went through a two day period of absolutely loving that engine, then realised it was buggy and (then) abandoned. 
Did you report them? Bug finding needs active users. 
runs at a really low frame-rate for me. lasted about 5 minutes with it then deleted it. 
Yeah, if it can't even get fullscreen stuff right, I'm not surprised that the rest of it is jangly as all trousers too... 
There are different renderers available, try

+set vid_render (gl|gles|sw|sw32)

No idea if the windows binary has them built in or something. has some more tips. 
(The accidentally-anon QF post above was me, BTW.)

This command line works for me: +set vid_render sw +set vid_width 1920 +set vid_height 1080 +set vid_fullscreen 1 +set con_width 640 +set con_height 360

Both sw and sw32 work for vid_render. Not sure what the difference is? Output pixel bit depth?

The gl renderer is painfully slow, and glsl causes an error dialog that says "Couldn't load critical OpenGL function glActiveTexture" (same thing that sock reported in that thread). 
Also Featuring Ghost Torches 
fteqw has r_softwarebanding now, I never knew the software stuff was responsible for the proper brownness. It looks so much nicer, especially the bricks. 
Those are the colours I remember in my Quake. 
is it possible glquake/fitzquake/etc. are missing a gamma correction step somewhere? The second shot "pops" more, I'm not sure it's just the banding doing it 
those are both from FTE

i think what you're noticing is the first shot has blurry floors and ceilings from the trilinear filtering (plus the lack of anisotropic.) Second shot appears to use GL_NEAREST filtering. 
You need to compare thoses images on a fairly bright monitor to really appreciate the difference, and when you do it's crystal clear that the colours are totally different, especially in the shadows, because the first image is just combining the textures with the lightmap using multiply or whatever, whilst the second image is using quake's colormap shenanigans. You can see it especially in the wood texture, which darkens to a rich, almost purpley shade in the software version. The colours have a lot more life in them, because the colormap bojangles shades and highlights the textures in a way that changes the hue in subtle ways, and your usual Fitz-esque lighting doesn't. 
Hmm, here is fitz085 vs winquake at 1024x768, gamma 1 on both, and gl_overbrights is turned on in fitz:

The difference I'm looking at is the metal around the Q vs the A. In the winquake shot it's brighter around the A than the Q, in fitz they're about the same. I guess it's probably just an artifact of the lightmap * texture being snapped to a fixed set of values in WQ, but i was wondering if there was some gamma curve in the colormap table that WQ uses. 
Software Lighting Appreciation 
You should be thankful that the colormap in Quake is not nearly as crude and abysmal as the one in Doom. 
There's no special magic in the colormap.

It's just a 2D table which takes a palette index and a lighting intensity and returns another palette index as the lookup result.

Because Quake is an 8-bit renderer the returned palette index isn't a straightforward multiplication but instead a nearest colour match (I assume; I haven't done any deep analysis of this beyond a rough comparison with what the result would be if it had been a multiplication, and determined that they match well enough).

So sometimes what would be a brown, or a green, if it had been a multiplication comes out as a yellow or an orange instead and hence software Quake can seem to display a greater variety of colour; but you shouldn't fool yourself into thinking that it's anything other than a flawed approximation that looks good by accident rather than by design.

This same applies to mipmap level reduction. In GLQuake it's a straightforward average of 4 texels to produce the reduced texel, but that can give results that aren't in the Quake palette, and so it's not possible in software Quake. Again, I assume that ID did nothing more than nearest-colour-match this to the Quake palette, and again that means that you can get results that were never in the top-level image, which again can give the illusion of more detail, or more colours.

A GL-based engine should gamma-correct it's mipmap reduction, but most don't. At the most basic level this means square each texel, then do the average, then take the square root of the result. That can give a huge improvement in the look of GLQuake right off the bat and without anything fancy needed. 
Most rows of the quake palette tend to gain saturation as they darken. It's an aesthetic choice (a very painterly one) that causes shadows to richen a little bit as the indexes are stepped down by shadows.

Very carefully tuned colored lighting could achieve a similar effect ... 
Software Quake lighting doesn't step down the palette indexes though. It's perfectly possible for a column in the colormap to jump from, say, palette index 89 to 21 as part of a single step in the lighting ramp.

For a real-world example, if we look at column 128 of the colormap, as the lighting darkens we step from palette index 254 to 15 to 14 to 161 to 128; at one point it goes from 4 to 36 to 3 over the space of 3 consecutive steps.

Now, obviously there's nothing in the Quake palette between indexes 4 and 3, so that 36 must have come from taking what it would have been and performing some colour matching to select a palette index to use.

So it's a good deal weirder than just a simple stepping-down of palette indexes. 
I can reproduce the same "painterly" effect in Photoshop in about 10 seconds by overlaying a banal black gradient over the Quake colors, and then quantizing the result into the Quake palette. 
for reference, here is the colormap converted to a PNG:
(I used lordhavoc's lmp2pcx tool to convert to tga, then gimp to convert that to a png, but had to hardcode the width/height into lmp2pcx because the colormap doesn't have the lmp header) 
The thing is, whether the effect is painterly, or aesthetic, or deliberate, or some, all or none of the above, is totally irrelevant because it's not what software Quake uses for lighting. 
Now it should be noted that when you simply overlay black, the original colors tend to LOSE saturation, not gain it.

Ultimately, the amount of saturation you lose after quantization depends on the palette you quantize to. In Doom, for example, a lot of colors mutate into browns and greys, because the palette sucks for lighting. With a well-balanced palette (like Quake's) it's possible to preserve as much saturation as there was before quantization (but after darkening). Maybe even more in places, but not much more, and only by accident.

Unless you have a very deliberate algorithm for building the colormap, but it's not the case with Quake. 
Software Quake uses colormap. I was talking about reproducing said colormap (its lower part, at least) with a very simple and lazy method. Not sure what you're getting at. 
The Seldom Discussed Qlumpy Palette Tool 
The lightmap colortable generator seeks the indexed 8-bit color that is closest to the desired 24-bit color for each entry based on least distortion.
distortion = dr*dr + dg*dg + db*db
dr is the red delta, etc.

It runs through the whole palette (minus fullbrights) for each table entry. Slow on a DOS machine, which is why it was generated in advance. ToChris introduced an alphatable to the mix. Engoo embedded the table generation into the engine for colored lighting, fog, and effects. 
but i was wondering if there was some gamma curve in the colormap table that WQ uses.
just to dismiss this idea, I took the 8th color in the first block of browns, plotted the red values from the top of the colormap to the bottom, and it follows a jagged but straight line. 
I Like It 
When clever people talk. 
I should probably point out that at this time, my code cheats and disables mipmaps for those surfaces.
It really only gets away with it because people tend to not run quake at 320*200 any more.
I suspect spirit's regular-gl screenshot used min=linear, mag=nearest, mip=nearest filtering (which is an impossible setting in vanilla glquake).

Its entirely feasable to upload the 4 mips to GL and use only those, but I didn't get around to doing this yet. This would allow it to avoid needless precision loss from mipmapping.
Most gl engines mipmap recursively, accumulating imprecision with every mip, so there's likely benefits to uploading the 4 mips even when not using colourmapping.
Considering this would boost loading times, and reduce imprecision, its a wonder gl engines don't already utilise all 4 mips, yet I don't know of any glquake engine that actually does this - GL_TEXTURE_MAX_LEVEL=3, combined with npot, and us engine devs have NO excuse for shoddy mipmaps.

There'll still be precision differences from the lightmap, and when mipmap boundarys occur. I won't claim that it matches software rendering exactly, but its close enough that you do have to stare quite hard at the walls. 
that assumes the mips in the bsp aren't "shoddy" -- do we know what method was used to create them? (obviously might differ between id textures and user-made textures) 
that assumes the mips in the bsp aren't "shoddy" -- do we know what method was used to create them? (obviously might differ between id textures and user-made textures)

qlumpy source code again; the GrabMip and AveragePixels functions (in quakegrb.c) show that it's just a simple averaging, followed by a nearest colour match, with some error diffusion mixed in at the end for non-fullbright texels.

An obvious risk with user-made textures is that the creator may have never bothered with making miplevels beyond 0. That's something that wouldn't show up in GLQuake and we all know that a lot of content was never even tested in software Quake back in the day (hence stray fullbright texels, bad overbrighting, etc). 
Software Quake lighting doesn't step down the palette indexes though.

Right, it uses the colormap ericw posted, which defines lighting per intensity and palette index as a lookup. And, in almost every case, the values present in that lookup are from the same palette row. That's all I meant.

Either way, shadows gain saturation because the darker values in the palette are more saturated.

Anybody know how Texmex generates mips? Since that's prooobably what everyone's using ... 
>> Either way, shadows gain saturation because the darker values in the palette are more saturated.

Not really.

But sometimes they have different hue (compared to the brighter colors of the same row). 
And, in almost every case, the values present in that lookup are from the same palette row.

Actually in most cases they're not.

Each palette row has 16 colours, whereas each palette entry in the colormap has 64, so straight away you can see that there's a huge amount that must come from other rows.

The darkest entries in each palette row also each have 64 lighting gradations, and because there's nothing darker in that entry's row the gradations absolutely must come from other rows.

By way of an example, here's a copy of the colormap with the 6th palette row entirely replaced with bright pink:

We can see that entries from this row are used in regions of the colormap that correspond to other rows, and we can also see how much of the region of the colormap corresponding to this row actaully comes from elsewhere in the palette.

As ericw has demonstrated above, the colormap is pretty much a straight line as it steps down, which is expected as the code that generates it uses "frac = 1.0 - (float)l/(levels-1);" to calculate the fraction of the base colour for a given light intensity.

What I suspect you're really seeing is that eventually each column in the colormap goes to palette row 0, i.e the greyscale row, so as shadows in software Quake darken they lose their colour too. 
i remember distinctly that the darkest non-black color is a deep red. You see it a lot on the edges of pitch black shadows in software mode. 
>> Each palette row has 16 colours, whereas each palette entry in the colormap has 64, so straight away you can see that there's a huge amount that must come from other rows.

Not necessarily from other rows. "Duplicates" (if you could call it that) are very common in colormaps. 
Not necessarily from other rows. "Duplicates" (if you could call it that) are very common in colormaps.

That falls down on two counts.

First of all, each palette row corresponds to (16*64 =) 1024 colormap entries, which would necessitate far too many duplicates.

Secondly, if you actually look at the colormap data itself you'll see that they mostly do come from other rows.

I've posted an example from row 6 above that you can look at and check; over two-thirds of the colormap entries for row 6 come from other rows. The same example can be repeated for every other row if necessary.

I'm not sure what part of this you're not understanding. Some of us have actually looked at the colormap, we've analyzed the data in it, we've read the code that generates it. We know what we're talking about and we're not talking theoretically. 
>> Some of us have actually looked at the colormap, we've analyzed the data in it, we've read the code that generates it.

And I actually made a few. And not by running an algorithm.

>> I've posted an example from row 6 above that you can look at and check; over two-thirds of the colormap entries for row 6 come from other rows.

I'm sorry, but you got it backwards. Row 6 is not a "recipient" in your example, it's a "donor".

Note how you painted it pink even in the middle, between the shadow part and the overbright part. The colors are supposed to be "raw" there, they can't come from other rows (unless there's something very wrong).

So yes, the colors are often mixed between rows. But not nearly as much as you think. If you examine pixel columns very closely, you'll see that the colors are often repeated many times. The darker (or brighter) the original color is, the less precision there'll be. 
Lacking Fog, Mips Textures Help As A Depth Cue 
A minor super8 update is posted that fixes HUD aspect ratio. A config is included for more authentic colors/lighting/hud. This shot from Tronyn's Jam2 entry shows both:

The config is just:
sbar 2
sbar_show_bg 1
sbar_scale 0.7
r_light_style 0
r_fog 0
r_coloredlights 0
r_palette palette
v_gunkick 0
cl_bobmodel 0
cl_nobob 1 
Oh I Got It 
It's not the colors painted pink that were supposed to come from outside the row, it's all the others.

The example is one of the more extreme ones. A good complementary example would be the red row. It barely has any "foreign intrusions"; the overall amount of unique colors in its part of the colormap is 23, which means a lot of repetition, but it looks very smooth nevertheless.

The point being that using half of the palette to shade one row is unnecessary, and is usually unintended. The reasons for it to happen I can think of:

1. The row in question lacks sufficiently dark and/or bright colors. You still have to shade it somehow, so the only option is to borrow from other rows.

2. The common ways of producing darker and brighter shades tend to mess with hue and saturation. Row 9 is a good example. The brightest colors lose the most saturation when darkened, hence the grey pixels.

3. The math behind quantization may suddenly decide that a color from another row is closer to the shaded color in question than any of the current row's indexes. The grey row is a perfect example.

Quake palette has a lot of similar hues, which means that a lot of colors are interchangeable between rows, so 2 and 3 are rather common. Doom palette has a lot of horrible examples of 1. Many games that I've seen avoid using the colors outside of their rows as much as possible (Strife being a notable example), but that requires less straightforward methods. 
And As If 2 Wasn't Enough Chaos 
4. When the artists feel especially artsy, they produce rows with inconsistent hue. Row 7 starts with reddish brown and ends with bright yellow. 
FTE Fake Sw Looks Good 
It even barfs on red colored lighting like a sw engine:). The lighting looks blended with the textures, especially in dramatic contrast areas. In GL the lighting can look airbrushed or too smooth when the lightmap ramp is steep. sw engines can run into banding here but it can be solved with dithering. Which in normal conversation seems ironic. 
Thanks... I Think... 
It cheats when it comes to coloured lighting. It still has a 24bit colour framebuffer, so it just does 3 colourmap lookups instead of 1. This can result in different colour channels banding at different points.

The actual glsl code is here:
the EIGHTBIT define is true for colourmapped surfaces.

once you already have glsl in your engine, its actually pretty trivial to do this. just the 8bit texture loading, colormap loading (no header!), and glsl tweaks.
This would actually have been possible even without any engine changes, but would have needed lots of external textures+shaders. 
The only alternative to cheating on colored lighting AFAIK is a dither function. Can glsl do this? Otherwise banding/blocking is extreme.
I posted earlier about a hypothetical SW engine cheat that would use a bigger palette to expand colored light range. Because, well, modern 8-bit engines are FAKE, the output must be upsampled to 32-bit for newer graphics cards.
Actually mixing in a little dither for its own sake (if possible) might obscure that glsl cheat and look even more softwarey. 
Checking Alpha Texture Support 
Is it possible, using QC, to check whether the engine running supports partially transparent brush textures, so I can disable certain objects on certain engines? 
Probably Not 
I know a few have tried tackling this problem before with limited success.

The Qc is basically scripting, and isn't good at requesting things from the multiple standards of engines.

Whilst its admirable to try and make your stuff run on many engines I've never really bothered. Making something good for one engine takes all my energy during a project and if its good enough then the other engine owners will want to support it anyway.

The risk is that it isn't popular enough and gets lost to redundancy, but considering the track record of Quake mods in general that's a rare occurrence.

Quakespasm is the best engine now anyway ;D 
You could just add a parameter to turn off all objects marked as X. And then provide the player with a number of different configs.

It'd still be down to them to use _software or _tenebrae or _darkplaces though. 
Ok Thanks 
In that case, I think I'll just design to my engine of choice (which happens to be QuakeSpasm), and just make it very clear in the readme that this is the case. Setting out with this philosophy at least has the advantage that I can use QS features to their full potential, not to mention simplifying the design. 
QC And Textures 
Another problem is that QC runs on the server, which may be a different machine to the client (which runs the renderer), e.g for multiplayer games (which includes co-op).

Because they may be running on different PCs they may also be running different engines.

The only reasonable workaround I can think of is for the client to tell the server what engine version (or better yet, engine features) it uses during signon, and have that standardised as part of the protocol. 
mankrip is doing a Patreon: 
Resurrecting this chat from last december...

It could be that using md3 makes more sense than a MDL + new 16bit refinement format.

I could have a look at how difficult a minimal md3 implementation for fitzquake/qs/glquake would be.

There seemed to be quite a lot of "thumbs ups" when this was suggested. Just wondering what the mood is regarding adopting md3 as a standard, now it seems everyone's pretty much either using quakespasm or darkplaces... 
iqm is skeletal tho which limits the sort of animation you can do. 
iqm is easier to animate programatically, that is you can do ragdoll and separate legs/torso stuff. of course, this requires lots of extra logic, most of it as part of the gamecode.
if you think of skeletal formats as more limited, then you're probably stuck trying to animate with qme or something, which is going to be nasty when you get a reasonable poly+anim count, otherwise there's not much difference as you're positioning it all the same anyway.
md3 is simpler, but that's pretty much the only reason you'd bother with it, tbh (that and its simplicity meaning its more likely to already be supported in the more limited engines). 
this is not 100% correct.

when people say skeletal is limited, what they mean is that it is limited because the engine is limited.

of course, we are all animating with skeletal systems in max or whatever, but the skeletal stuff is maybe 80% of the stuff. the rest is animated with scripted things and/or vertex deformations. when those skeletal + vertex animations are collapsed into pure vertex animations, we get all the power of the 3d program in quake.

if we instead relied on the engine to move the vertices, then all we have is bare bones (haha....) skeletal only animations.

or you are faced with the prospect of assigning one vertex per bone and then trying to run deformations on the bone objects which most 3d tools are not natively meant to do, so it's just needlessly harder. 
Yeah What Necros Said 
In the modelling app I'd be animating bones to do most of the movement, but I'd also be using blend shapes a lot. 
Soft Selection 
Does iqm suppose vertex assignment to multiple bones? Because soft selection on bones is remarkably helpful in creating convincing anmations when you've got a low poly count... 
preach, yeah, 4 influnces max, like most skeletal formats designed for hardware acceleration. 
I noticed ezquake you can aim down straight to the ground. Is there any netquake engine that supports FULL (180 degrees) freelook in the same way as ezquake, besides darkplaces? 
Silly me, didn't check that one. Thank you. 
IQM... Tempting 
I tend to do most of my animation worth with bones regardless. Blendshape support would be nice though but I don't know of any other format that we could snag for the best of both worlds. MD3 would be a massive improvement but with IQM you can animate at 10FPS and then get bone rotation instead of linear interpolation for vertex positions... makes for nice big sweeping motions with proper arch. :) 
I have recently, and will be for several months, been switching to a Pentium 4 Toshiba laptop with Windows XP Home SP3.

The problem is that, no custom engine i have tried (Aguirre's Enhanced GLquake, Quakespasm, ReQuiem, Fitz, Fitz Mark V ...) runs at all or runs even close to a decently speed in this computer, even before loading a map, i don't know if because of the age of the computer, compability reasons, or bugs (this last case probably not as i have tested in several engines). In case of Fitz and Aguirre's the video fails but the rest works, in the first engine the screen is black and in the second the console doesn't drop and everything is in a low color mode. Fitz Mark V won't even load. DirectQ gives me the same error as in almost any computer till now.

So far only WinQuake that comes with Aguirre's GL engine works (haven't tested the original one to see if its different). And thanks to this i am noticing how much we are depending on the added engines features, as my maps look so different now without them.

All the info i get from the engines besides Fitz, Fitz MArk V and AGuirre's is several warning messages about non-supporting several features or not finding certain things, the newer the version engine the more the warnings.

So the question is, which engine would be able to run well besides WinQuake, or what can i turn down in any engine (i use mostly Quakespasm)so it works good enough to play? 
Because of my work I use the NumPad a lot. So far only QuakeSpasm seems to allow typing in the console with it. An engine that has individual transparency for each liquid would also be welcome. 
More than likely the laptop's hardware is lacking, the video in particular. I ran Fitzquake on XP for years, but that computer had a pretty decent Nvidia video card. 
I remember Aguirre's engine and old versions of Fitz ran perfectly on much older rigs back then. 
What's your gpu? Got drivers installed? Try r_dynamic 0. 
Slowness Even Before Loading A Map 
Is a sure sign of windows software rendering, caused by missing or not-working graphics drivers.

gl_info in the quake console will print info on the driver being used, to confirm this

If you dont know the exact gpu model in that laptop, try the utility "GPUZ" which should tell you 
If you can use winquake, then try qbism's Super 8 engine. It is a software engine like winquake but supports lots of the new features. 
With a Pentium 4 and from how you describe it, you've almost certainly got an old Intel graphics chip. The age of the CPU is unfortunate but it's still capable despite that; the graphics chip being absolute crap is what's killing you. 
The Direct3D version of Mark V should run on that old computer with flying colors.

It doesn't care about your OpenGL drivers ...

It doesn't even need them. 
Thanks. The laptop is probably running on old drivers, but i don't know, this laptop isn't mine, and i am doubting on updating them, as this is the only computer, i have seen running a certain videogame i like a lot, in the last 10 years.
I have been testing what you have told me and this are the results.

* Necros: About Qbism Super 8, it seems to work, at least the older versions i got from Quaddicted, the page for that in the official website gives error 80.

* Baker: About Fitz Mark V on Direct3d, yes, it works, thanks. It looks that i was using a version from before you added that feature.

* Spirit and Ericw:

The GPU is a Intel(R) 82852/82855 GM/GME Graphics Controller. GPU I855GM.

r_dynamic 0 doesn't look to have any impact on it.

Gl_info shows this:
gl_vendor: Microsoft Corporation
gl_renderer: gdi generic
gl_version: 1.1.0

For now i suppose i'll stick with MArk V. It is a relief, i thought i wouldn't be able to map for the next half a year. Yeah, i know i could still amp, but mapping without checking from time to time is asking for trouble and for ending with an impossible to fix map. 
Compatability Matters To Me 
"Baker: About Fitz Mark V on Direct3d, yes, it works, thanks."

The Mark V Direct3D version can run on a 1990s clunker because it uses Direct3D's 8 API.

In fact, the only reason I made a Mark V Direct3D version was because I encountered a machine that wouldn't run the OpenGL version but was otherwise an "ok" business-like computer running Windows 7. 
Thanks For Bumping This Thread, Bots 
I should have posted here before. 
Func_, I Need Your Merciless Opinion 
I've changed the description of the Retroquad engine in my Patreon profile, and I need to know if it's good enough for me to spread the word around now. Suggestions are welcome. 
The most exciting thing about the RQ engine is the 4-player splitscreen and controller support. Everything else is simply the icing on the cake. 
Anyway, here's a preview of the server side of my protocol code. It will support big maps but it won't be compatible with the FitzQuake protocol because the original algorithm of SV_WriteClientdataToEntity is a mess. I've only made an effort to keep protocol 15 compatibility because the original startdemos uses it. 
Retroquad is purely software rendered, no GL whatsoever? Are you making those shadows and bloom without OpenGL? 
And I'm getting better at it.

In the past I wanted to write a hardware-accelerated renderer, but I don't think that's necessary anymore.

It's a shame that Carmack abandoned his own software renderer, because the ideas behind it still have a lot of potential. The more I master it, the more things I realize that can be efficiently done.

The error most people makes is to try to mimic hardware acceleration verbatim. I'm ignoring that and focusing on the software renderer's strengths. 
So, about the description: it seems that you're speaking to yourself (a lot, by the way), not to your user. The description doesn't make crystal clear what makes RQ stands out, where's its place among other ports. Is it the "software render" guy? Is it the "console Quake" one? The "modular code port"? What's its motto? The description strikes me more like a big "thinking out loud" and less like a pitch for dummies looking for an engine like me.

Hope these 2c are helpful someway. 
Yeah you need to cut down on the ramble. To be honest you could probably cut down the text to a quarter of its size without losing the salient points.

Like this is a typical paragraph, and most of it is just waffle to be honest:

"To make sure that it all comes out as expected, with everything working well not just in the technical sense, but also in the artistic sense, one of the main guidelines I've established for this engine is "feature consistency". It means that if a certain feature is available for a certain kind of thing, it should also be available in some similar form to all similar kinds of things (e.g. in Quake, only static surfaces, MDL models and internal BSP models were lit, but in Retroquad, everything else - external BSP models, liquid surfaces, skies, 2D sprites and particles - can also be lit), and it should adapt itself to behave consistently in any user configuration (no matter the screen resolution, aspect, FOV, and so on)."

I would just turn that whole lot into a heading and a paragraph focusing on the important bit, e.g.

Feature consistency
e.g. in Quake, only static surfaces, MDL models and internal BSP models were lit, but in Retroquad, everything else - external BSP models, liquid surfaces, skies, 2D sprites and particles - can also be lit.
Two More Things 
First, and most importantly: It all seems as if you're asking me to pay for your hobby. I do understand that your financial situation is difficult, but I still don't really see why I should give you this money.

Second, I don't know who your target audience is. Is it players? They are not interested in all those technical descriptions I'm afraid. I suppose you're really trying to market this engine to modders and indie game developers, but even then, it remains unclear why they should choose your engine over others.

Finally, if you do target indie game developers, then you need to add a roadmap detailing when certain features will be finished and when you expect the entire project to be done. Your approach seems to be "I'll just release it all when it's done, with some files here and there when I feel like it.", but seriously, who is going to wait for that and be content to shell out their money on trust alone? I certainly would not.

To be truly honest, all this seems like you're trying to make some money off of your hobby, which in principle is fine, but in this case I think it's hopeless. Your engine is way too niche to be interesting to game developers when there are plenty of free, and already finished, alternatives out there which do run on more platforms and with a proven track record. They few things that set your engine apart don't justify the money nor the time a dev would have to wait for you to be done (which might very well be never).

I'm sorry if this sounds harsh, but it is my opinion :-( 
:D Thanks 
Hmm, let's see.

"The description doesn't make crystal clear what makes RQ stands out, where's its place among other ports. [�] What's its motto?"


All engines focus on improvements, but refinement is a more strict approach. Sorry, I don't know how to explain in a more concise way.

Unifying the features of all official ports is part of this refinement.

"To be honest you could probably cut down the text to a quarter of its size without losing the salient points."

That's my weakness. I'm not good resuming stuff, which is why I've asked for some opinions.

But you've cut a bit too much. The last bit is also important, because I'm not aiming just for the presence of the features. I'm also aiming to make their behavior consistent, and that's important because the vanilla software renderer behave in awfully inconsistent ways (particles becomes _smaller_ when you zoom in, for example). I just don't know how to make that clear in a more concise way. 
Those are valid points.

Yes, the target audience is also indie developers.

"but even then, it remains unclear why they should choose your engine over others."

I'm certainly not trying to compete with Unity or UE4.

And I admit that this is what I have the most difficult to answer. If an indie dev feels at home using other engines, there's no reason to change.

But, just like there still are people developing games for retro consoles such as the Genesis or the Jaguar, there may be some people interested in developing PC games with a current engine that's truly retro. I see a lot of indie games doing this with 2D engines, but 3D indie games usually tries to fake the style of software renderers using hardware renderers, what in my opinion is just plain wrong.

An indie Genesis game running on an actual Genesis is a technical achievement; a 3D game underusing a hardware-accelerated to simulate a software renderer is not.

I guess my main audience is people interested in making that kind of technical achievement, but I admit that's a really small niche indeed.

"Finally, if you do target indie game developers, then you need to add a roadmap detailing when certain features will be finished and when you expect the entire project to be done. Your approach seems to be "I'll just release it all when it's done, with some files here and there when I feel like it." "

It's not when I feel like it; it's just that I don't like to make promises I'm not absolutely sure I can fulfill, and giving exact dates is one of those promises. My life is too unpredictable, because any small problem is taking a big portion of my resources to fix. For example, if the roof of my house falls down, I'd be desperate and unable to deliver the code in time� which would make me double desperate. That's an extreme example, but it's actually possible.

I feel a lot of remorse when I don't keep up with my promises. 
Even if you develop your engine based on Quake, would an indie dev be able to sell it? Surely zenimax would get really pissed off about it? 
It's still under the GPL, so no problem. 
Your competition is DarkPlaces, QuakeSpasm, FitzQuake, and the like. The only thing your engine has going over these appears to be the software renderer. But I also expect that using it comes at a cost of performance and platform availability (no Mac OS X, for example). I'm really not sure if the software renderer is enough of an argument to sell an indie dev on your engine.

Regarding a timeline, I understand where you're coming from, it's the same with me and TrenchBroom, but for different reasons. That's why it's free and open source. No one can, and no one does, expect me to make promises as to when a release happens, and what features it contains. You on the other hand want money, but without any commitment. That's not gonna work for a lot of people I'm afraid. It's also why it looks like you wanting others to fund your hobby projects. 
Asking people for sponsoring a hobby that leads to public products is perfectly fine and pretty much what Patreon is. It's a hobby for the receiver of the monetary support, they can justify extra time investment or feel rewarded. It's 'paying' for something nice for the patrons. 
Spirit is basically right. Mankrip is doing exactly what patreon was designed for... it's literally the reason it exists :P 
If mankrip were making a commercial-like product he wouldn't be asking for donations at Patreon.

I don't think it is fair to compare a hobby project to a commercial-like project. 
In this case I believe Strafe 1996 is communicating perfectly to your audience.

Sleepwalkr, patreon is not like crowdfunding. Though I agree there must be a clearer quid pro quo in this case.

I feel like giving some unsolicited sugestions, bare with me: maybe we need more project management here; maybe it should be a code refactoring/doc project, aiming programmers, something like Quake Code Bible. Is there onde already? 
software renderer .. (no Mac OS X, for example*cough* Mark V has a Mac software renderer. 
Though I agree there must be a clearer quid pro quo in this case

... to be more successful, to get more patreons. 
Okay, Sorry 
I didn't understand the nature of Patreon. But my other objections stand. 
Typically, Patreons WILL get something in return tho. In your case, maybe you could do a weekly stream or something where you work on the engine in real time and interact with people? Like Handmade Hero does... 
The last bit is also important, because I'm not aiming just for the presence of the features. I'm also aiming to make their behavior consistent, and that's important because the vanilla software renderer behave in awfully inconsistent ways (particles becomes _smaller_ when you zoom in, for example). I just don't know how to make that clear in a more concise way.

As written initially it's a bit vague and leaves people wondering what exactly you mean. Just saying features will behave consistently no matter what screen resolution you are in will just result in a " what?" reaction.

Giving an actual example of what it fixes is much better. However, details of minor bugfixes like that should probably be left for a seperate section which just lists (in concise bullet points) what it does differently to vanilla quake. 
I Have To Say, 
there are some good ideas about Retroquad. The idea of a quality modern software renderer. The idea of refactoring and documenting a legendary engine's code. The idea of running this legendary game/tech on Android. Lot of potential to explore. 
For $10,000 
You get a func post. 
Armchair Quarterbacking ... 
The Func crowd is composed of critics, and rightfully so.

Criticism is the aspiration for excellence.

Although there is no bad "publicity", unless it is specifically criticism and high standards you are looking for, this may not be the kind of feedback you are looking for.

[Translation: when I've posted about highest standards "completed and tangible" projects here, it has gone well --- the others, not very well. I wouldn't even think of posting about a work-in-progress here unless it was very clearly known to be such *AND* I needed a mapper's point-of-view to complete it correctly.]

/Free internet advise. Probably no better or worse than other "free internet advice". Haha ;-) 
However, what's being criticized is not the engine; it's the proposal.

Anyway, if I have to justify it, that's because it was rejected.

I won't dispute this anymore, Right now I just want to write the engine, and writing about it won't help with that. I'm happy with how it's shaping up, and that's enough for me.

Thank you all for your solid reasoning. I'll keep to myself from now on. 
There is lots more to the Quake community than just the nitpicking know-it-all func people. 
Nitpicking is good. The problem is that there's no way to properly nitpick this project yet, and I didn't realize that before. 
FTE Questions?> 
A Few FTE-related Questions [EDIT]

Posted by babgo [] on 2015/12/22 14:46:01
I'm trying out FTE and i ended up with a few questions about the engine.

1) Does it still have a software renderer? How can i enable it?
2) What's the difference between full and minimal OpenGL clients?
3) I've seen some browser versions mentioned. Is that emscripten? Does MP work, or only SP?
4) All rendering in FTE is done through shaders? No fixed pipeline crap?
5) I've seen this engine/common/com_phys_bullet.cpp which seems to be an integration with the Bullet library. How can i enable and explore this feature? Is it available from QuakeC?
6) I've also seen engine/gl/gl_heightmap.c. How can i create a map with terrain?

FTE seems to be an undocumented gem. There's so many features hidden in the code! I'll keep researching and reading more about it. 
FTE Stuff 
1) there no software renderer any more. the 'vanilla' preset gives a faithful enough reproduction via the gl renderer.

2) minimal builds lack a load of optional extras, like the server parts, q3bsp, etc. basically the stuff that you don't need if you just want to play quake on the vast majority of public servers.

3) fte's browser port is compiled with emscripten, yes. there's no real access to udp from web browsers, although it can connect to servers via websockets.
however, this requires 1: a server with sv_port_tcp set. 2: adhere to all the cross-domain blocks that browsers insist on implementing. this means that the only real way to use it would be if someone wrote a proxy. which would suck even more for latency.
so yeah, practically speaking its singleplayer only (you could bind some keys for splitscreen play, but there's no way to deal with multiple mice).

4) webgl support demonstrates that fte can do all its rendering without any fixed pipeline crap.
it can still fall back on fixed pipeline stuff for old devices, but this tends to disable a load of stuff like shadowmaps.
FTE's usage of the word 'shader' refers to q3(+extensions) shaders. All the built-in shaders pull in some glsl as required, and it make some stuff up as it goes along if the shaders neglect to specify any glsl, if fixed pipeline stuff isn't usable.

5) bullet is some experimental feature and is mutually exclusive with ode support (fte's ode integration is more feature-complete). both require extra dlls - ode is partly built into the exe and just needs a libode1.dll (check the 3rdparty zip iirc), while bullet requires some fteplug_bulletx86.dll which is not publically available in a pre-built form due to it being significantly feature-incomplete compared to ode.
this stuff is available to qc, but is a bit too unreliable (with both ode or bullet) for actual use. stuff tends to fall through walls if you're not really careful with it.

6) there's two ways. the original way is to use 'mod_terrain_create foo; map foo' and then paint stuff with the csaddon.dat thingie (some csqc-based editor util thing - you should be able to find a copy on
the other way is to just copy the various terrain-specific worldspawn fields from that foo.hmp file and place those into a bsp 'shell' map, and then use csaddon to paint it again.
be warned that both terrain and csaddon need a bit more polish.
obviously, other engines have no chance of displaying any of this stuff properly.

7) play with the apropos command whenever you can't remember the name of a cvar/console command (or want to see if one exists with some word in its name or description).
some cvars+commands will display a description of what they do when you try tab-completing them at the console.
check fteextensions.qc for similar things in regard to qc extensions. the descriptions may be a little terse but they should usually be enough to guide anyone that is vaugely familiar with the functionality.

8) this forum generally favours big huge topics with lots of cross-talk over lots of individual threads, hence why your topic got moderated the way it did.

oops. :s 
It's sad that the software-renderer is gone. What's the latest SVN commit with it? I wonder if i can fork it and remove all the GL stuff. 
So Right Now 
What is the best software rendering engine in terms of the ability to play modern maps and faithfulness to the proper DosQuake/WinQuake look? 
In my humble opinion, the WinQuake is in this download is a million light years beyond any other software renderer in polish and faithfulness.

Download: Mark V WinQuake

Can play anything Quakespasm can play including BSP2 maps. Can also play Nehahra, etc.

Set r_wateralpha to 1 if you choose, it defaults to 0.5. 
Why did I not know this? 
I also swear by mark v winquake. Also mark v 
otp: Baker buries goodies deep in the Fitzquake Mark V thread... 
a machine man 
Mark V is great indeed.

Super8 is also good and has lots of interesting features, but it looks significantly different from vanilla Quake.

The latest release of Engoo is also very good, but I haven't tested it enough and the previous versions had some instabilities. 
Mark V Winquake 
Cheers - looks good! 
uuuuunnnngggghhhh...god I love how the textures look in the software renderer.... 
Load up Zendar or that Koohoo knock off Sock made to see a couple of maps that really accentuate software rendering. ;-) 
In Fact ... 
You can type:

install zendar1d
game zendar1d

Single Player->New Game 
"Can play anything Quakespasm can play including BSP2 maps. Can also play Nehahra, etc. "

Crashes on Arcane Dimensions tho. If I load the start map, I start riding the lift and kaboom ... 
Crashes on Arcane Dimensions tho

so does the current release build of quakespasm. 
Every new SP release these days seems to require new engine limits.

No doubt I'll eventually be checking that out.

I did make the statement before Arcane Dimensions was released. ;-) 
Load up Zendar or that Koohoo knock off Sock made to see a couple of maps that really accentuate software rendering. ;-)

Will do...

There is something sublime about what the software renderer does to the colours. It's all so much grittier and creepier. 
Crashes on Arcane Dimensions tho.

I played AD using mark v and everything was fine. no crashes or any problems. skill 2. 
I played and tested AD on MarkV and it worked fine. Not the Winquake version I believe... it identifies as v0.99 on the lower right corner of the console. 
Ah, I was using the Winquake version ... the regular just outright crashed and wouldn't even start up. Weird. 
Does any of those SW engines support 64-bit Linux? 
Tried to run on my Ubuntu 64 box, after compiling it, crashed when trying to start a new game. Playing demos works fine, menus work fine as well. 
Likely, they haven't fixed QuakeC interpreter to use 64-bit aligned pointers, which Linux 64-bit is rather insistent on.

So the demos run, it should be able to play as a client, but the second single player attempts game logic, it'll explode. 
So something you could do ...

Start Quakespasm -dedicated and maxplayers = 1 and deathmatch = 0 and then connect to the Quakespasm server. 
Arcane Dimensions On Qbism Super8 
Anyone get arcane dimesnions to run on qbism super8? I tried running but it crashes on start up. 
mark_V_Winquake just crashes for me. Used the link that was included. Sad. Was looking forward to the palleted texture rendering. hehe 
If you post your config.cfg, your command line, start up Mark V with "c:\quake\mark_v_winquake.exe -condebug start" and post the contents of "c:\quake\id1\start.log" tell me about your machine specs (version of Windows, anything unusual) ...

I'd be willing to quickly check for anything unusual.

I haven't had anyone say that Mark V WinQuake and 30-40 people have given it a test drive, but obviously it isn't working for you. 
Qbism Super8 Cl_beams_quakepositionhack? 
does qbism super8 have a console command similar to qbism super8 cl_beams_quakepositionhack? for darkplaces? I am trying to adjust the position of the lightening gun beam in QC but no matter what I do, it is always in the center when using qbism super8. I was wondering if it is the result of qbism also having a console variable similar to qbism super8 cl_beams_quakepositionhack? in dark places that I need to disable in order to get it to work.

I've looked for one. but no luck so far. 
That behavior was implemented by me before qbism forked the code, so he may have not changed it. When I implemented it I didn't add any cvar to restore the original behavior.

Hmm� Yep, no changes were made: 
@mankrip: So no matter what, there is no way around it unless something is changed in the engine itself? No way around using quakec code? 
:/ Yep, no way around, other than using a different kind of beam. 
Well not quite... You can spawn a new entity to be the source of the beam at the spot you want. 
@ necros:
You mean create an entirely new entity that duplicates that of the lightening bolt but with a different name and just use that as what is called by the lightening gun when fired? and it should appear where I want it to and stay steady? I managed to change the location of where the lightening bolt originates from the gun, but as the player moves, the lightening beams seem to lag to catch up with where the player is standing. 
Yeah, it's going to be messy, but what you do us something like this...

Spawn the entity, set its owner to the player. give it a think method to set it's origin relative to the player and make the nextthink 1. This makes it run every frame so the helper resets it's position all the time.
Then you'll want to store a time value 0.1 seconds in the future and include an if condition to remove itself after that time. 
could I just add the think method to the original lightening entity? btw, where/which qc file is the code for the lightening bolt entity stored? I'm having trouble finding it. 
That's basically what the original code in cl_tent.c already does - spawn an entity at the view model origin and update it's position each frame. What you're proposing just seems a more complex way of reproducing the same behaviour as is already there.

Part of the problem is that the view origin for the view entity is actually not the same as the view origin that's used for drawing. I haven't actually traced through this part of the engine code in sufficent detail to say more though. 
Sure, I did say it was messy. But it's qc only as opposed to needing engine changes. 
qbism has released a super8 with the ability to toggle the beams behavior ...

Presumbly the cvar is cl_truelighting 0/1, the same as JoeQuake/ezQuake/Qrack/etc. where a setting of 0 is Quake normal behavior. 
I tried qbism and I really like the look of the engine but ... fullscreen seems broken? My Windows task bar never goes away which is annoying. Am I alone on that? 
Cvar name is cl_beams_quakepositionhack 
What are the cvars that can be tweaked to make DarkPlaces look like software Quake? 
type in this -

gl_texturemode gl_nearest 
r_useanotherengine 1 
Gl_texturemode Gl_nearest 
Doesn't make any engine look like software Quake. Software Quake had mipmaps but gl_texturemode gl_nearest will disable mipmapping. 
software quake didn't have mipmapping. This will remove all texture filtering and make it look oldschool.

Are you trolling? 
Of course software Quake had mipmapping. That was one of the cool features. 
Oh, I see, you're confusing mipmapping with filtering ... no, it didn't have texture filtering. But it DID have mipping. 
If you view a texture in TexMex, it will let you see the 4 mipmap textures it creates.

Any Quake texture wad has 4 levels of detail built into the texture.

WinQuake uses them. GLQuake did not use them and instead generates it's own mipmaps from the texture. 
TexMex ---> open a wad --> select a texture and click View ->View Detailed.

The smaller images below the main image are the mipmap level textures. 
I guess I was confusing filtering and mipmapping as the same thing.

Basically I was helping the dude get the pixelly goodness. 
The workings of the software renderer aren't as well known to most as the GL engines.

Mostly because for maybe a decade, the WinQuake style engines were basically abandoned and forgotten.

Mankrip was probably the main person working on them (other than Spike) but MH did 2 big tutorials that really made them better (one was animation frame lerping). 
You guys seem to over-emphasize smaller differences in rendering from GL to Software. I mean, what most people really want, and notice, are the pixeled textures. And that's it. 
Without simulated 8-bit rendering (i.e. every pixel you see on screen is in the quake palette) I'd be reluctant to say it looks anything like software quake. 
The quake palette is not up to the task of rendering most modern maps which have been designed with coloured lighting. They look like garbage in anything but mark_v and quakespasm. 
I Know 
I mean, what most people really want, and notice, are the pixeled textures. And that's it.

overbright lighting is hugely important. glquake doesn't support it, which is why everyone complained about it being "dark", and the idgamma fix which just wrecked the palette instead was ugly and didn't address the real problem.

metlslime began supporting it in fitzquake 0.70 or so. 
Software Quake 
There's also R_DrawSurfaceBlock8_mip0, R_DrawSurfaceBlock8_mip1, R_DrawSurfaceBlock8_mip2 and R_DrawSurfaceBlock8_mip3.

nearest_mipmap_nearest looks fine, but nearest_mipmap_linear can look better; it retains the pixel crunchiness but gives a smoother transition between mip levels. Of course that's moving away from how software Quake looked again, but that's no bad thing IMO in cases where software Quake actually did look worse (is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better, for another example).

Of course, some people confuse aliasing with detail, which is why some may actually prefer gl_nearest on it's own.

All that aside, the pixel crunchiness of software Quake has other advantages too, aside from just pixel-crunchiness for the sake of pixel-crunchiness. One of them is that the texture art is actually quite finely detailed down to a per-texel level to begin with, with a lot of those details being as small as a single texel. Look at the health pickup box textures, for example. When you blur those with linear filtering all of that fine texture art just turns into a mushy mess. 
The quake palette is not up to the task of rendering most modern maps which have been designed with coloured lighting. They look like garbage in anything but mark_v and quakespasm.

I'm sorry, but Quakespasm doesn't do anything special with either the Quake palette or with textures. It's just an absolutely standard 2x modulate blend using built-in GL functionality. 
(is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better

This is one of the things that bothers me with most modern engines that "fix" it... 
(is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better

What like e.g. in QuakeSpasm? A particle near the player's face is a quake unit in size I think, but the same particle the other side of the room has to be drawn bigger otherwise it would be completely invisible. 
A particle near the player's face is a quake unit in size I think, but the same particle the other side of the room has to be drawn bigger otherwise it would be completely invisible.

Nope, that's not what I mean at all.

It's evidently been quite a while since people have actually used software Quake, and have forgotten how it really looks... :)

What I mean is that in software Quake particles on the other side of a room start out small enough, but still visible. As they get closer they increase in size normally with perspective. Then once they get so close they start getting smaller again. So a particle that's, say, 10 units from the viewpoint is actually substantially smaller than one that's, say, 100 units from the viewpoint.

That's how software Quake looks and that's what I mean. 
To try to retain the distance cue of particle size without occasionally obscuring the view with a gigantic square of color? Makes sense. 
No. It was due to the particles of the vanilla software renderer being fully broken.

Everything about their maths is fucking wrong. From the top of my head, here's a list:

� They're not scaled to the screen resolution. They were developed for a 320*240 video mode, with a double height version for the obscure 320*480 video mode, and that's it. Their dimensions will always be wrong on any other video mode, including 320*200.

� They were hardcoded for FOV 90, and go wrong on any other FOV. This makes them get actually *smaller* when zoomed in, which is bloody awful.

� Their origin in 3D space is *not* in the center of their square, but in its top-left point. If you freeze them by pulling down the console and then rotate the camera around, their squares will move around their top-left point, instead of staying at the center of their previous 3D space position.

� Their maximum size is 8 pixels, IIRC. Again, the actual screen resolution is ignored, which means that in lower resolutions, they'll be able to get closer to the camera before being clamped. So, this "feature" doesn't make sense at all, it's just some weirdness that people got used to.

I'd actually challenge people to play WinQuake at 320*240 fullscreen for several hours doing everything the vanilla game can do and try to compare it to how the game look & behave on their regular engine & config setups. But I don't want to be that annoying. :P 
The main purpose of the mipmaps in the software renderer is not to make the game prettier, but to conserve surface cache memory, which is used for the lighting.

Since the liquids in the vanilla renderer doesn't use lightmaps, they don't use mipmaps either. And hardware rendering with mipmaps will also mipmap the liquids.

And GL_NEAREST doesn't disable the lightmap filtering, not to mention that hardware rendering doesn't feature the same color banding of Quake's colormap, unless explicitly coded for it (FTE is one of the rare hardware-accelerated engines that does this, but I haven't tested it). 
To try to retain the distance cue of particle size without occasionally obscuring the view with a gigantic square of color? Makes sense.

Seems more like you're trying to retroactively justify incorrect behaviour. That's not going to fly. Again, I'd encourage you to actually go back and run the original software Quake to see exactly what it is you're trying to support. 
The main purpose of the mipmaps in the software renderer is not to make the game prettier, but to conserve surface cache memory, which is used for the lighting.

For anyone interested in learning more about the reasons behind many of the decisions in the software Quake renderer (and those reasons are often "it had to run in 8mb on a P60") the latter chapters of Michael Abrash's Graphics Programming Black Book are a valuable reference:

Mankrip's statement here is confirmed by chapter 68, the section on mipmapping, by the way. 
Can a charitable gentleman remind me which Quake engines have external file reading/writing ability via QuakeC? 
Makaqu (and therefore Super8) does, IIRC.

Darkplaces and FTEQW certainly does. 
Any idea whether they follow a standard, or just do it in different ways? 
Most engines with QC file access probably uses Frik_File. 
Right Cheers 
If that's a kind of standard, and QuakeSpasm were to implement it, it would be AWESOME 
BSP Trees 
Not an engine programmer per say, but was curious if its possible to put in an engine hack which recalculates collisions against regular bsp and treats them as if they were q3 bsp, so that the point, player and shambler hitboxes can be overcome? 
RE: BSP Trees 
Q2/Q3 BSP does not use the bsp tree for culling, it only uses it to find the nearby brushes.
The information needed just isn't in the file...

With the 'smoothnstuff' branch of ericw's branch of tyrutils, the 'stuff' part that I snuck in includes an -wrbrushes argument to qbsp. This causes the qbsp to insert brush info into the bsp file, this can be used with a supporting engine (read: FTE only for now) for brush collisions in a similar way to q2 or q3 brush collisions.
(you also need to use the matching vis+light tools in order to prevent the extra info getting stripped).
Add -noclip if you want to break every other engine but compile your bsp a bit faster, but without this second arg, the bsp will still work in other engines, just using vanilla-style collisions. 
bsp leaves are convex, in theory the engine could treat each solid leaf as a brush, then use that brush to do the q2/q3 brush expansion logic to handle arbitrary sized boxes.

that's also how collision should be handled on rotating brushmodels. 
in theory, you can do something like that (a little more complex though).
in practise, you lose all clip brushes.

The other option is to use trisoup collision. Again, no clip brushes, so again not a real option (imho). 
ah right, clip brushes. I guess you could pull them out of hull1, but they would only be useful against entitys at least player size (since you can't shrink them, only expand.) 
Interesting ... 
So far most of the time the standard q1bsp's seem to collide ok on hitboxes < player size and > point , except when you are in tight areas of the bsp, like corners and irregular shaped solid bruses. The 'squarer' the area you are in , the less this seems to be an issue. I also seem to recall that the velocity of the ent effects the collision as well, past a certain value, I dont recall what it was, or if it was movetype related.

So I suppose traceline / tracebox fails when you have a non-standard mins/maxs ent formed and want to check collision on it, though would those not stand a better chance to hit the world than say another ent which is also non standard? I guess world is not considered a point type collision hit when contact is is not point, player or shambler, but it does have a mins and maxs and a size, so I guess collision on it all depends on the brushes? Im not a mapper so I dont get to work with that stuff very often...but I always thought a collision against a bsp brush was calculated on a point size area of the bsp. 
The collision hulls in Quake are based on clipping polygons which are pushed inwards from the visual hull, and the amount pushed is based on the set sizes of the 2 sizes of boxes that Quake supports. That way everything is a point check and cheap.

I think... 
Point To Point Collision 
Hrm, well when you think about it, the grenades and rockets traveling are point sized. Theoretically, they ought to collide once in a while if you play deathmatch....or maybe when you are fighting an ogre. Whens the last time you saw that happen? Never. So does / would traceline collide with a point sized ent? Just for fun, one time I gave the missile a.think which set its size randomly between point, and I believe half point. Collisions failed when you hit specific parts of the q1bsp sch as corners or angles mostly, but I was able to see a "point to point" collision of sorts with another missile during some tests in dm with another player. So thats why I said earlier, velocity seems to have a factor. Maybe Im being redundant, but I'm curious if the engines are checking the collision boundaries with velocity factored in, or if they stop the ent each frame for the check? 
point size

What you are saying doesn't make sense, unless you think point size means "1 pixel size", which it doesn't.

Point size is mathematically zero size, i.e. a point. 
AFAIK, bbox <> bbox collision supports arbitrary bbox sizes, unlike bbox <> world. 
bbox<->bsp collisions are aligned to the bbox's min position.
This means changing size_z leaves the monster sitting on the ground still, but changing size_x or size_y can allow the monster to (obviously) move into walls on one side but not the other.
Thus its generally much better to just use fixed x+y mins+maxs values, while z values can be more accurate with much less regard to hulls (note that hexen2 uses mins_z set to 0, because why not).
engines that support rotating bsps do so by rotating the start+end positions of any tracelines/boxes around the bsp object. This has the effect of rotating the bbox too, meaning that the top or bottom surfaces (in a non-rotated position) of the bsp are further away than its side edges, when standing on top of said surfaces after rotation.

bbox<->bbox collisions do support arbitrary sizes, but as the same mins pos affects the bsp collision offset, and the size field affects the hull that is used, you're still limited in terms of bbox sizes.
note that bboxes don't rotate, which generally means that the corners of the bboxes can become excessively obvious with large bbox sizes (side note: doom used cylinders, thus didn't have this issue). 
Case-sensitive Console 
I just realized you can type in small or big.

Is this a feature for case-sensitive OSs?

In Windows version it does not seem to be a useful feature, because if you happen to use a capital letter
in a console command it says 'unkown command'. 
Sorry, Wrong Thread. 
I posted it in the intended QS thread. 
Interesting OS X Port ...

"Also, only the software renderer is currently available for video - though, to render frames to the screen, I decided to use the new Metal framework available for both desktop and mobile devices"

Usually someone porting the original Quake to an operating system they like comes up with inventive ways to handle video, sound, input. 
Darkplaces Engine Bug [EDIT]

Posted by Teknoskillz [] on 2016/02/07 21:51:33
Was not sure if this is ok to start a new thread , so feel free to move it to the right one if Im making a mess here. The last engine related topic I was posting in got moved someplace, I cant find i it now? Anyway , on the chance there may be some experienced people here using DP, and may know whats going on, heres a screenshot of the problem: [ ]

It happens when you set r_showbboxes to non zero. Its some kind of artifacting / re-replicating going on and its been a while since I first saw it, but I seem to remember I was playing with another graphics related cvar before I set showbboxes again during testing, so I am pretty sure its related to the other cvar, just what one, I cant remember? Any help appreciated. This is the most recent release of DP. 
Murky Vines 
Swampy in Super8:

New test build with better color and transparency rendition:

Intense saturated colored lighting: forever blocky. 
:D Yay, A New Build 
Testing it now. 
Missing Dlls 
For anyone who doesn't already have super8 installed, this link includes the the test build above (v267) plus missing dlls for music playing: 
I already had some DLLs installed, but the music sounds a little unusual. I thought you were using a statically-linked library.

By the way, the color in this version has really improved a lot. Haven't tried it with colored lighting yet. The MDLs looks shiny. 
The features of super8 are outstanding and very well done. 
They are, i love this engine.

We need a love cube symbol! 
Yum, Pie! 
Pie is good, too.
Shiny mdls: Change r_light_style cvar to 0 for conventional flat lighting. I guess the default is 1. 
any chance of a native linux build of super8? 
A matter of time and form, but no super8 goal for now except a stable windows release for qexpo. I'm on Mint as much as possible lately. Linux is on the list if development continues. 
Looping Sounds 
Trying to help a new modder with their soundpack for Quake. He has the ambent fire for the torches giving an error in Proquake that its not a loop type audio file. I believe other engines such as DP and Fitz probably automaticly loop these, but does anyone know how to change it so its a looping type? We looked in Audacity and could not find a setting. I thought I remember readint there was more or less a bit you change in the .wav , but maybe thats only 8 bit type audio? 
I never found a reliable explanation of how to loop sounds, even though i have done it myself multiple times. Part of the problem is the terminology is inconsistent across audio tools.

I think you basically have to open the wav in a program like cool edit 96, soundforge, etc, and add a "tag" or "marker" or something at the point in the file where you want the loop to re-start. If you want the whole thing to loop, place it at the beginning. If you want there to be an intro and then a loop, place it at the end of the intro.

Even when i did this, sometimes it didn't work for me. I might have tried multiple programs to make it work.

Because of this frustration and hassle, one of my wish list quake tools is a dead-simple "make a sound loop" utility program where you run it on a wav and it adds the data that is appropriate. Perhaps other people had better experiences, though! 
I Used Goldwave 
And there under tools (I think) add marker.

It didn't matter where or what it was called, Quake would then treat it as looping. 
found a link here maybe some info, too 
Ahk, Win 7 or later for Goldwave so I cant check it, but will fwd to the modder the link to this thread. Thanks all. 
The version I had/have somewhere is pretty old. 
Older versions for XP/etc here: 
What are the commands for making DP resemble the software quake engines? 
gl_texturemode gl_nearest

The rest can be difficult
DP To Real Quake 
Getting DarkPlaces to look correct is only partially achievable. I have a particle font I got from somewhere that allows particles to be square and pixelly. gl_texturemode gl_nearest is good. Water will not twist unfortunately. I have not found a way to re-enable the twist effect and is the only reason Darkplaces is not a fully supported and true Quake engine, for all its interesting options. 
You're better off just using a different engine for the true software look. Darkplaces' whole shtick is about looking fancy. Why use it at all if you wont use its features? 
Really it's true strength is for use in total conversions where you want to use cool stuff like the Q3 bsp format and md3 models.

For playing Quake? Ehhhhh... not so good. 
Because i want to use CSQC, great QC extensions, great multiplayer and a stable codebase. :D 
With Darkplaces you have a prvm command so you can check globals and look at entity specific fields etc, using the command prompt.

Is this something just in Darkplaces? I thought all the legacy engines have it, but apparently no? 
fte has 'poke_MODULE' commands that you can use to get/set various qc terms (ents can be read by number).

every engine supports saved games (with the possible exception of dedicated servers). saved games are always text, and should allow some sort of inspection, although figuring out entity numbers may be awkward. 
Interesting - yea, Darkplaces has a crash.dmp option you can set, and turns out its merely doing a save game (.sav) just before crashing.

It does comment each bracketed field past the worldspawn with "entity" [x] so you can find them, however I imagine the save game would be numbering all the edicts past worldspawn as entity 1, and incrementing, which I guess can be a pain sifting through.

I had thought the legacy engines from way back like Winquake etc, all had the prvm command , but maybe it was the "edicts" command. I remember doing that and it would just spit everything out to the console.

Cant recall if I used it to actually set things during the game and test them though. 
code dump:
Cmd_AddCommand ("edict", ED_PrintEdict_f);
Cmd_AddCommand ("edicts", ED_PrintEdicts);
Cmd_AddCommand ("edictcount", ED_Count);
Cmd_AddCommand ("profile", PR_Profile_f);
you mean those? I'd kinda forgotten about them tbh, sorry.
iirc, edicts is basically unusable because it fills the console buffer too easily.
either way in vanilla there's no way to peek at globals without saved games.
fteqw+fteqccgui has a watch list thing that's updated with each single-step, or you can just mouse-over stuff too, of course. 
That looks like them.

DP also lets you use the prvm to filter things , ie:

prvm_edicts server model

Prints all the edicts on the current server to the console and shows their current model string.

You are right, edicts command crashes the engine. DP removed it but some other engines like Direct Q are still using it. Fitzquake 0.85 does not crash tho.. 
Broadcasting A Clients Engine 
Saw this a long time ago, I guess its a Proquake feature, thought I once saw it being able to detect Darkplaces clients connecting as well but not sure. As it stands when I use the "Manquake" version of Proquake, it always seems to detect Proquake, just different veersions. Are the engines using a standard ID and a tag of some sorts to ID the engines, or is this all now just a passing fancy?

string ()
PQ_Version =
local float i, ch, sum;
local string format = " with proquake version 0.00";
local string x;

i = self.netconnection[QS_MOD] / %1;
if (!i)
return " with a non-proquake client";
else if (i == 1)
return " with an unknown proquake client";
else if (i == 2)
return " as a qsmack client";

ch = floor (i / 4096);
i = i - ch * 4096;
sum = hex_ctof (hex[ch * %2]) * 16;
ch = floor (i / 256);
i = i - ch * 256;
sum = sum + hex_ctof (hex[ch * %2]);
ch = floor (sum / 10);
x = ftos (ch);

i = %23;
strcpy (format[i], x); i = i + %1;
strcpy (format[i], "."); i = i + %1;

sum = sum - (ch * 10);
x = ftos (sum);
strcpy (format[i], x); i = i + %1;
strcpy (format[i], "0");

return format;
proquake added som extra byte or two at the end of its connection requests. this is meant to contain some [engine]mod id, and the version of it. proquake also added 16bit client->server coords only for proquake clients, and nothing else that's particuarly special.
this resulted in pretty much every NQ client suddenly pretending to be proquake because it was the only way to get 16bit angles at the time.
so really, all that code can actually detect is whether the developers of said client actually gave a fuck about multiplayer or not.

it also depends upon qccx hacks that will break with any engine that even attempts to provide sandboxing, with offsets that are highly specific to the server in question.
adding hacks with assumptions about memory layouts is evil, but if the engine doesn't actually provide any extensions then really the only choice is to hack said engines. 
What Spike said, I had to fake qrack to telling proquake server's it is pq3.50 compatible so that it will allow players to use the 16-bit angles. once the handshaking is established pq will send angles as such and qrack will read them. Other engines like Qspasm connecting to a PQ server will only use 8-bit angles and thus be at a disadvantage. :( btw pq server/clients in this fashion also break demos played on other non proquake clients... 
Do the 16 bit angles allow fullpitch?

So I guess older engines and even Darkplaces still only has 8 bit angles, and therefore if a non pq clients is on a pq server, their angles are not as precise, is that how it works? 
angle cheats are separate from angle precision.

darkplaces pretends to be a proquake client too.
its own network protocol always uses 16bit angles, for both client->server AND server->client.

because proquake's angle thing is strictly client->server, it doesn't break demos because it doesn't even appear in demos (so r00k is wrong in that regard, unless there's some other difference that I'm overlooking, like proquake's svc_print encodings, but those should just look glitchy).

the fitzquake protocol also uses 16bit client->server angles. however, proquake doesn't support that, so quakespasm is indeed limited to 8bit angles on public deathmatch servers, but not when playing singleplayer. 
btw pq server/clients in this fashion also break demos played on other non proquake clients...

It is well known that ProQuake demos play even in the original Quake/WinQuake/GLQuake.

And by extension JoeQuake --- which uses ProQuake network code -- this is why speed runners use JoeQuake to record their demos [amongst other reasons]. 
Why could not each engine have its own cvar that more or less corresponds to its clienttype and version?

IE: cvar FitzQuake = "Fitzquake 0.85"

Then feed this field into something decided upon to be 'universal' in the engine community in case they 'give a shit' about mp...heh.

As it stands now the code I posted is I guess cute, it can announce what client a player is using when connected...if it were to work accurately that is. At least if the structure did pass a unique string to read to the layman qc modder, they could perhaps customize some mods to take into account the many differences in all the engines and give the user a better experience, ideally... 
1: cvars are not normally server-visible. making them server-visible also implies making all cvars server-visible, like ones that contain rcon passwords or other things that shouldn't be scraped.

2: string parsing is not possible/feasable without server extensions, limiting the servers that can actually benefit from it to those that either don't support anything but their own by default(dp), or that already have their own auto-detection(fte).


4: really, it would need a whole list of 'compatible with' much like user-agent strings in http. string parsing is annoying, did I mention that yet?

5: encouraging people to use client-specific features also encourages people to depend upon incompatibilities. the end result is probably not very good in the long term. don't get me wrong, it'd be nice to know what each client supports, but doing it on a per-feature basis rather than a per-client basis helps to encourage people to actually adopt the standard properly rather than getting modders to add a hundred different hacks for each client.

6: quakeworld clients can be distinguished fairly easy by reading that client's userinfo string.
of course, this still requires knowing everything about every client.
I admit that I've used it for blacklisting clients that don't appear to implement standards properly, and I know mvdsv uses it for both blacklists and more annoyingly whitelists.
whitelists suck by the way. you end up straight back with trying to pretend to be some other client. and then all the complaints about cheats start. whitelists suck.

so yeah, it'd be nice for servers to be able to tell what they're actually talking to, but at this point I seriously doubt anything is going to change, and even if it did, it probably isn't going to be TOWARDS compatibility, at least in the long run. 
what i meant as "break" was that all demos play back with 8bit angles. So, in slow motion watching a demo from first person pov, the aim isnt as smooth as the player saw when recording.

this is in cl_input.c

if (!cls.demoplayback && cls.netcon->mod == MOD_PROQUAKE) // JPG - precise aim for ProQuake!
for (i=0 ; i<3 ; i++)
MSG_WriteAngle16(buf, cl.viewangles[i]);
for (i=0 ; i<3 ; i++)
MSG_WriteAngle(buf, cl.viewangles[i]);
btw Qrack breaks demos because the number of lightmaps increased for halflife map support, which i could easily scrap but then i have 1000s of demos that were recorded with that fact. :| 
the viewangles displayed by an nq demo are exactly as precise as was displayed when it was being recorded, on acount of each demo packet containing 3 floats for angles, no truncation at all, not even to 16bit.
those writes are irrelevant when playing back a demo. that buffer isn't sent anywhere on playback, even if its still made.

If you recam a demo or have qc generating some sort of chasecam with forceangles/svc_setviewangle then yeah, you're probably going to end up with 8bit data getting expanded to floats, purely because the result is based upon the server->client precision (which is unmodified by proquake).

regarding lightstyles, you'll find this nice line memset (cl_lightstyle, 0, sizeof(cl_lightstyle)); inside CL_ClearState. Or, in other words, you can omit any lightstyles following an svc_serverinfo that are empty (whether recording a demo or serving to clients), and your halflife support etc still works, without any needless incompatibilities. Obviously if a map/mod does use one of those lightstyles then that's the map/mod's problem rather than yours.
Really, support for 255 lightstyles should be a standard feature by now. 
Chatted with Zop last night, and he says that command ' q_version ' was I guess a Manquake type of mod where participating engines could code in their response string, and it would be initiated using the 'say' command. Doing it alone on a server would not yield a response, however more than 1 player on a server would trigger each client to respond with their engine version. According to Zop, the admins voted that out of the RQ games so I guess its either commented out in the eng source or deleted, but I guess this is one way of doing it. 
in CL_ParseString i call this...

void Q_Version(char *s)
extern cvar_t cl_echo_qversion;
static float qv_time = 0;
static float qi_time = 0;
char *t;
int l = 0, n = 0;

if (cl_echo_qversion.value == 0)

t = s;

while (*t != ':')//skip name

l = strlen(t);

while (n < l)
if (!strncmp(t, "q_version", 9))
if ((qv_time > 0) && (qv_time > realtime))

if (cl_mm2)
Cbuf_AddText (va("say_team Qrack version %s\n", VersionString()));
Cbuf_AddText (va("say Qrack version %s\n", VersionString()));

Cbuf_Execute ();
qv_time = realtime + 20;
break; // Baker: only do once per string
if (!strncmp(t, "q_sysinfo", 9))
if ((qi_time > 0) && (qi_time > realtime))


if (cl_mm2)
Cbuf_AddText(va("say_team %iMHz %iMB %s\n\n", MHz, (int)(Mem/1024), gl_renderer));
Cbuf_AddText(va("say_team Video mode %s \n", VID_GetModeDescription (vid_modenum)));
#ifdef WINVER
Cbuf_AddText(va("say_team Windows Version %x \n", WINVER));
Cbuf_AddText(va("say %iMHz %iMB %s\n\n", MHz, (int)(Mem/1024), gl_renderer));
Cbuf_AddText(va("say Video mode %s \n", VID_GetModeDescription (vid_modenum)));
#ifdef WINVER
Cbuf_AddText(va("say Windows Version %x \n", WINVER));
qi_time = realtime + 20;
Cbuf_Execute ();
break; // Baker: only do once per string
n++; t++;

all client-side... 
Qrack goes one step further than ProQuake in that, if the player who initiated the q_version in mm2 mode then Qrack will respond in mm2. 
1: requires annother player on the server.
2: can potentially be exploited to get other kicked/muted from the server due to spamming.
3: working around the previous issue makes it unreliable.
4: the reply is indistinguishable from many other possible responses.
5: the reply is totally not standardized.
6: you can't tell what the client is until a not-insignificant time after the player is already running around.

its fine for players to know what other players are using, for those that are curious about it, but its useless for mods.

quakeworld standardized upon f_version triggering the main response, after fuhquake, but also works for fte and fodquake too, but I guess ezquake has an off-by-one error... 
^ Text Colors 
I thought all the engines since day 1 supported colored text using the ' ^ ' character?

Turns out if I push a string in QC and use one of the extended colors with that character, Darkplaces will print it with bprint or sprint with the new color, but I noticed PQ does not seem to support this? Have not tried Fitzquake or other engines yet. 
I thought all the engines since day 1 supported colored text using the ' ^ ' character?

Engines that support it are actually a minority.

It was one of those niche features that appeared in one or two engines way back at the dawn of time - i.e very soon after the GPL code release, and IIRC on the ancient (and long-dead) QER site - but was never really documented nor standardised, and never really picked up by any others. 
^ is pretty much just DP+FTE (and q3 onwards, obviously, but that's quake3 and not quake).

if you just want 'red' text, you can use \b (iirc) within a string to toggle it in fteqcc or frikqcc.
so maybe that's why you think it works in more engines. 
I appreciate your comments about q_version, though yes 1 doesnt work unless two online, is kinda moot since you know your own client version. :|

I can make it so it's only mm2 and/or only before a match is going; and limited to once per minute response.

That said there is also a command to just disable it called cl_echo_q_version... 
as for ^ color chars I'd rather see full ANSI support with blinking characters and the full set of extended characters too! ;)
but then Quake was kinda unique with it's own custom character set... 
q_version was never anything but a social feature to create awareness of modern clients.

And get people to upgrade.

If you were using glquake or ProQuake 3.50 and someone typed q_version, 2 things might happen:

1) You see may everyone else on the server was using ProQuake4, Qrack (later DirectQ supported it, but wasn't around at the time).

2) Another player might ask you what you are using and why and someone might even suggest you are using a cheater client.

The social pressure thing worked wonders and I can recall connecting and doing a q_version check and within weeks it was close to 100% modern clients.

At the time, it was important to get people to upgrade so automatic map download had a near 100% rate and people could play custom maps, ctf, coop servers, rocket arena automatically. 
Good Points, Baker 
From A Seperate Thread. 
Any Quake 1-2 Ports With Monster Footsteps? [EDIT]
Posted by crystallize [] on 2016/04/22 15:01:24
It would be intresting to see a port where monster sounds are synched to animation, unlike Q2 with gibbed monsters screaming or making falling sounds. 
That is soooo not an engine thing. 
A fiend or a spawn or a dog or a shambler making footstep sounds would be odd.

Maybe someone could make a model with those monsters wearing boots. 
I believe AD has footstep sounds for every enemy type. The shambler footstep is the biggest and heaviest but also kind of muted/muffled. 
yeah this is mod territory. 
Thought port meant engine? 
Thought port meant engine?

It does, but engines wouldn't handle that sort of gamecode - it's something you'd have to do in a QC mod - so the chap asking is barking up the wrong tree.

AD does footsteps, obvs. 
Strings In PQ 
Wasnt sure to post this here or in coding help. Im trying to alter the field "world.message" so it is strcat'd to be something more than just the description. Basicly I made some cute does that appends the Original authors name(s) to the ID maps. However, when the map loads, the message seems to always be either nulled / empty or its something the engine dont want to show. Basicly the line where it use to show in the console is now empty.

I have tried moving it outside of Worldspawn and seems to be no help. Basicly I am doing a strcat in worldspawn to the message field so is this safe? There is no strzone function in older PQ otherwise Id try using that. 
An external .ent file would be the proper way to do this. 
If you want to change the map name in the signon message, then hacking it in the QC strings or the entities text is totally the wrong way to go.

Just change the message sent as part of svc_serverinfo instead.

Or change the Con_Printf in CL_ParseServerInfo.

And be ready to have a fallback for the case where the mapper has already included their name here. 
I disagree about using engine code for what's merely an asset design thing. Unless it's implemented as an extra feature, using a new field instead of hacking world.message.

If this is implemented as an engine hack, it'll need CRC checks to ensure that it won't change the description of all the other start.bsp maps out there, for example (including the ones recompiled for transparent water). It overcomplicates things and creates yet more code to maintain.

Using an external .ent file in the ID1 dir won't affect the start maps of the mods, and will still work with recompiled versions of the vanilla start.bsp. No extra work, and no issues. 
PS: I meant to say "(including a CRC whitelist for the ones recompiled for transparent water)". 
Thanks Mankrip and MH for your points made. Didnt know PQ supports .ent files. I had some in a local folder, and apparently they have to be populated with the maps original ents, as I tried just using the modified worldspawn field, and the eng crashed in a runaway loop...but I was using modified Qc in a Darkplaces mod with Gyro for that Im not sure it was a good one.

Src mod Im working with for the message field is Runequake...and its got a file called strman.qc (string management I guess) so I thought maybe you could do just about anything with strings there, but apparently theres more to it in PQ. I can code changes to any world .field in Darkplaces no problem like this...but since Im not quite there yet programming eng code, I suppose I will try the .ent file thing for the time being and see how it goes. Thanks. 
Yes, .ent files replaces all entity definitions from the .bsp file, so you must get/extract the original .ent files and modify them. 
[i]That is soooo not an engine thing.[/i]
moderator moved me here :P

Thanks for the hint about Arcane Dimensions.

Also I want to show you Tenebrae 1.02 (2002) that can't be found in the web today... except may be as source code. It's difference with currently available 1.04 is lack of annoying colored fog and different lights placement. All these old fancy screenshots that Tenebrae was always advertised with, were most likely taken from this version. 
Noticed in legacy PQ if you rcon to a non std port other than 26000, initially you appear to be connected ok, however any further rcon commands except "status" are diverted to port 26000 somehow. So far the only client that correctly routes to the initial port and stays there seems to be Qrack.

Decided to try this tool which seems to be mostly designed for Q3 era games [ ] and after modifying a line of code, seems to be able to rcon ok into Darkplaces servers, but still cant seem to get it to rcon to a PQ type server. Would anyone have an idea why or what has to be done so it works? 
LordHavoc was quite inspired by Quake 3 in the early days which is why DarkPlaces and Nexuiz used the Quake 3 model format, the Quake 3 .bsp format and a master server strategy similar to Quake 3.

ProQuake's author seemed to just want regular Quake to have some features that Quakeworld had for those who preferred NetQuake physics.

It isn't surprising that DarkPlaces rcon is very similar to Quake 3, as Nexuiz in many ways was very Quake 3-like.

ProQuake's author probably used a method very similar to what was in the Quakeworld source code (I'm guessing, but its an educated guess). 
Thanks for that info. I too have noticed the similarities, and I like how it uses the pk3 file system with curl for connecting players to get all the assets to play the mod. It really is a modder friendly engine in that regard.

After reading what you said, I decided to revert the altered code back to the original that came with the above download, and in that form, it wont rcon to my dp server. So the changes we made to rcon_code.php allow DP rcons to happen but so far with PQ, no dice. We changed line 27 or thereabouts as follows:

// $query = "xFFxFFxFFxFFx02 rcon "" . $PASSWORD . "" " . $COMMAND;
$query = "xFFxFFxFFxFFrcon " . $PASSWORD . " $COMMANDn";

Sorry of this is turning into a coding thread, but I didnt get any response to my other rcon issue in the coding area.

Also if anyone is interested in modding said dl so that it covers all the legacy Quake / qw engines with me that would be great. I thought maybe we could have a session manager of sorts with this and add icons up there for all the quake engines so that when you click on one, the "mode" changes so you can rcon into those kinds of servers too. The author was contacted but hes got not much time to help mod it and has ok'd me to modify it to cover other games / engines. 
QW Rcon 
Just a side note since Baker refered to QW rcon maybe being used in PQ, when you rcon into a DP server and successfully send a command that prints something to its con, it will lead with : "QW print command from " , which tends to maybe say that DP is using QW type rcon code?

Another tidbit - DP uses rcon_address as opposed to rcon_server. During my tests this seemed to be incompatable when using DP to try and rcon to a PQ type server. However DP does have a "PQRCON" command, which seems to claim it can rcon to a PQ type server, and also does not work. Weather or not its related to the differences in the 2 cvars for the server address, not sure. 
However, if you want to understand network code you really have to be willing to get your hands dirty. There are no shortcuts.

Search for rcon in the source, it is precious few lines in precious few files. Find out how it sent, received, the packaging.

If you end up not being able to figure it out, I wouldn't be too worried.

Engine coding is hard, requires very strong determination and it isn't for everyone. For network, this is doubly true. 
Another way of thinking about this: rcon is sending and receiving a text string telling the server to do something.

And considering how few instances of the word "rcon" there is the source, shouldn't you find out how the client sends it, what code it sends (CCREQ_RCON for ProQuake) and where the server receives it.

And I'm not claiming it is "easy".

However, this is the kind of challenge where everything is sitting right out in the open and you can say "This sucks, but if I make up my mind I can read it line by line" in the applicable places -- or the other option is not doing it.

It is just kind of binary decision. 
NQ's netchan sucks.
Its the reason that quake can't easily be played through NATs. Yes, there are hacks that mitigate that in a few engines (like proquake), but not all (like quakespasm), and those hacks don't work for the serverside parts.
Any reliable data that is sent requires two extra udp packets at a minimum - one for the data, and one as an ack.
Its just undesirable in general.
Which is why DP switched at least part of its netchan towards the qw/q2/q3 style for connectionless packets (shame about those reliables really).

rcon is insecure. passwords are sent as plain text for a start. Most engines have no throttling against bad packets (just spam everything you can). If you have rcon passwords embedded in your config then its just a simple stuffcmd(self,"cmd rcp $rcon_password\n"); away from any server that wants to exploit you.
You're probably better off using 'screen' or some equivelent tool to admin your server, although yes, these are slightly more hassle to use (yay! less inclination for admins to interrupt games!).
sending an rcon command to a server that you're not connected to should imho be considered bad form. It may be useful if you just want to kick someone, but chances are you'd want more than that anyway, and it'd be a shame if you eg got the IP wrong and didn't notice.
The response is unreliable, so you have no idea whether the server actually got your command or nor when the response doesn't arrive, and if the response is too long then you also have issues
So yeah, rcon sucks. There are better alternatives, even without modding a server.

I personally tend to enjoy writing networking code. It requires you to follow two 'threads' at once, but unlike actual threads they generally have much better defined sync points.
Tbh at the end of the day, ALL code is just passing messages around the place. Whether its across a network or between cpu cores or just between two sides of an API, for a LOT of people coding is pretty much all just message passing. Even QC has thinks and touches and other events.
Yes, it can take a while to familiarise yourself with the various concepts, but its also very useful if you intend to program anything.
Most of the time, the challenge is figuring out where to start. For NQ that would be CCREQ_* for client->server requests, CCREP_* for server->client responses. Those are all the out-of-band things you can send. Actual connections uses more stuff, of course, so I'm going to gloss over all of that and end the rant here. 
So, there's not a single engine with software rendering that has modern netcode for decent multiplayer? ppl just care about damn gfx :( 
What's Wrong With Fodquake? 
Rcon, Cont'd 
I was told by the author of Qtracker, [ ] the intended Gamespy replacement...that its capable of rcon for other gameservers, but he did not include rcon for Quake. He intends to code it in for the next release, so was glad to hear that. As long as there is something that can rcon based on the server type, Ill be satisfied.

As for engine coding, yea have meant to have a go at it again, but something like a video showing how to do it would clear up alot of things for me. So far after asking on other forums no ones interested in making a video, and another idea would be some kind of site that uses an api of sorts to work with and or experiment compiling the engines based on the material uploaded. Probably asking for alot, but at least that way there is some kind of centralized point where its easier to learn and with some real engine coders like we see here having access, it could lead to some interesting new ideas or improvements. 
No You Won't, And You Know It. 
People who make things are determined types that don't get stopped easily.

They don't get stopped by the lack of a video. It isn't like there aren't a million tutorials, books, videos and game dev sites and places like insideqc,, moddb and the other zillon sites.

A developer is someone with a strong determination.

You aren't going to be making anything and you broadcast the "I'm a helpless snowflake" vibe in every post.

If you wanted to get into this stuff ---

-- there are so many resources on the internet that you'd already be doing it.

Real developers overcome obstacles and every real developer has overcome so many obstacles they don't even keep track. 
is something I have tried for a long time to get a grasp of and I just don't have the mind for it.

Mapping however is second nature 
Trial And Error 
might be the way some people do things, but its not for everyone.

So far the most professional helpful engine developers that have ever inspired me, dont make condescending or patronizing posts such as above ^^^

Thats about all Im gonna say regarding it. I rather see the discussion stay on track about Quake Engines instead of taking snipes at how people decide to tackle certain problems or gain knowledge. If you have a system that works for you , wondeful. Not everyone has the same way of doing things. 
Maybe something on Philip Buuk's channel would help you out?

Also, I don't think baker is insulting you, rather, giving you some tough love.

Listen to baker, you probably are putting out the "helpless snowflake" vibe unknowingly. I'm guilty of it and it's an easy trap to fall into when you're stuck and really don't know where to begin. Ultimately, that's going to 1) cause people to be disinterested in your cause and 2) distract you from what you ought to be doing. Also, don't dismiss advice because you find its content or presentation repugnant. This shit is hard and, more often than not, the truth of the matter is usually what you don't want to hear.

might be the way some people do things, but its not for everyone.

I can relate, but that way of thinking is ultimately a crutch. There is no shortcut from a to z. You're going to have to put your nose to the grindstone and work your way through. If I had taken this advice some time ago I would be in a much better position now. Maybe my advice isn't applicable to your scenario, maybe it is, who knows. Just my 2 cents. Best of luck! 
Thanks for your link, started watching it, seems very appropriate. Something like that may "fill in the blanks" for me perhaps. Thats more like proactive posting and providing possible solutions based on the real common goal, which is definitely more constructive.

As for the "helpless snowflake" insinuation, it all depends on how much research you do on me. Check my profile, I have a website though outdated regarding a QC mod. I am an active QC coder and also just recently started a Quake C support Email list fr the casual newcomer if need be. Im active in Quake as best as I can possibly be given its hurting circumstances. I have interacted with Baker before on other sites, but obviously theres only so much cooperation possible there. Aside from Quake, sometimes I get to have a real life, and Im not ashamed to say its been a lousy one lately for lots of reasons I could lay out here, which would most likely make people sick to their stomachs, so I wont do it. Its also off topic as well. There is a tendency on the internet in general these days for forget there is an actual imperfect human being on the other side who may feel "helpless" or "powerless" at times. To me, thats fine and despite me feeling that way lately , Im still able to help people if asked, and also do things for the possible new person trying Quake, so I think Im not as helpless as was implied. Thanks. 
good, I hope that material will prove useful!

It sounded as though you may have been going down a familiar path. I just wanted to take the opportunity to save you some time and grief if that were actually the case. No insult was intended. 
No problemo KP, understood.

Already watching the 2nd vid, and it does make me remember part of what may be my "special snowflake mental block" here so to speak. Its regarding Visual Studio. I have 2008 and 2010 installed on my main desktop PC, and when I tried compiling an eng straight from original known good src, (without making a single change) I could never get a good compile without an error. Checking further, I saw LOTS of complaints and remarks about inconsistencies back and fourth from different versions, and its well known I guess in the coder communities about these problems. I guess I could have gone to those sites and waded through tons of material to find my particular issue, but since I have been a sorta active member in some Quake Websites where there are real actual engine coders, made more sense to ask for the help there. But I think this video will def help alot for me. Glad to see some poeple are making vids about modding or coding Quake, could not find any when I looked. The internet is becoming a real vast place packed with so much content, sometimes its pretty easy to get lost...or overwhelemed. Maybe thats also part of it.

In case you or anyone else wants to see some of my Quake modding experiments etc, heres my Quake only youtube
[ ]

Maybe we can 1 day create Quaketube? :o) 
Sadly, Fodquake doesn't have a server implementation. Only client. :( 
technically it does... it just doesn't work. :)
even if it did, it still wouldn't run mods properly (being a qw engine) without a huge amount of work. Even getting the official mission packs working properly wouldn't be trivial. 
Quake In 1996 Vs 2016 
Posted by Sgt-PieFace [] on 2016/06/28 18:16:56
I made a short video show the changes that have been made to Quake via client updates and mods over then 20 years of its existence. 
Well Then 
Sgt-PieFace can take a faceful of poo pie. 
Kinn you might explain why ... he's not going to know unless you give him the "straight up" from the level designer point of view. 
Both look bad.

1996 seems to have been made at a lower resolution and/or picmipped down, probably the latter judging by the relative size of the sbar. The original Quake textures may have been low-res but they were also quite crisp. no fullbrights or overbrights either; GLQuake may not have had them, but software Quake did and software Quake came first.

2016 looks even worse. It's the typical DarkPlaces baby setup: a horrible mixture of high-res textures and low-res content. Looks in no way cohesive and the whole setup just seems to be designed to appeal to those who want to look at the pretty normal maps rather than play the game. The Quake high-res mod community still doesn't seem to understand that if you have normal maps then you need flat diffuse maps.

Yuck. Next. 
Well, if you have a Mac with Xcode and the latest version of everything, you could switch the left part of the video with my soft-rendered OSX port. You would get the crispiness of low resolution textures as rendered on a 2880x1800 screen (or whatever resolution you have) - or even in a small window if you prefer. Might make for a fairer comparison. 
Kinn you might explain why ... he's not going to know unless you give him the "straight up" from the level designer point of view.

It's like mapping a hi-res photograph of a person onto a minecraft character model. I really don't have the energy to step people through why this looks bad. 
I take it there still aren't any truly high-def models for advanced Quake engines? 
It's not just high-res models, it's map geometry as well. The combination of high-res map textures and low-res map geometry just really really jars. Throw in the occasional spot where no high-res texture exists and it throws you even further. 
Can I Use Quakespasm For Standalone? 
Hey guys, I've recently picked up Quake modding, and I've been looking at ways to make content that I could distribute without people needing Quake itself. I realize it would entail me making all-new textures/models/code, that's fine. I've been running Quakespasm as my engine of choice due to its relative faithfulness to the source, would it allow for completely custom content without me needing the original Quake paks?

I know only of OpenQuartz as a completely 'bare' moddable engine. 
I don't know if QuakeSpasm still requires the "proof of purchase" file to run custom content, but Darkplaces doesn't. DP has been used to create some full standalone games, even commercial ones such as Steel-Storm: Burning Retribution. 
I don't know if QuakeSpasm still requires the "proof of purchase" file to run custom content

Just checked the most recent code, and yeah, it still does the COM_CheckRegistered check.

This is actually still a useful distinction in quake, even outside of the context of running custom content, because it also ensures tat people don't accidentally blunder into the e2, e3 or e4 entrances in the Start map if playing shareware. 
well you could set "registered" to false without disabling custom content. That cvar is what locks the episode gates. 
Stuttering With Animated Lightstyles 
If I'm experiencing big slowdown and framerate stuttering when there are lots of animated lightmaps on-screen, which command line value or cvar am I forgetting to set? The game runs 100% fine the rest of the time... 
R_dynamic 0 
Are you on the latest QS? 
I'm guessing you're running Intel GPU + Fitz 0.85 or an old version of Quakespasm?

The GLQuake lightmap upload code could slow to a crawl on some drivers, Intel in particular. MH fixed it a while ago and the fix made it in to QS 0.90.0 (iirc) and MarkV. 
You should probably also define "lots".

The animated lightstyle code in stock GLQuake and derivatives, even with my fix, just doesn't scale. All that my fix does is batch up some uploads and provide the right hints to the GPU that it doesn't need to do a format conversion, but it's still possible to construct scenes that run in the 20/30/40 milliseconds per frame range.

The real fix is to move lightstyle animation entirely to the GPU. This is actually quite simple (you can do it in GL 1.1 even) and you end up trading off texture uploads (and pipeline stalls) versus extra blend passes and draw calls (and increasing the video RAM requirements for lightmaps). The devil is in the dynamic lights, but you can do these with more blend passes and attenuation maps (if you don't have shaders), at the expense (I think) of not being able to take the surface normal into account.

The whole thing becomes significantly simpler (not to mention much faster) if you're prepared to say "screw GL 1.1" and require shaders.

End result either way is that the frame rate is levelled: scenes with lots of animated lightstyles run at much the same speed as scenes with none, and lightstyle interpolation becomes possible. Dynamic lights run roughly the same as the old code, but with much higher quality, and proper dynamic lighting of large MDLs and BSP models becomes possible. 
dynamic lights then need to become (shadowless) realtime lights, otherwise you're stuck with just flashblends/coronas.
still, if you're willing to ditch dynamic lights and non-glsl to optimise light styles, you can create a non-lit pathway through your code for almost no cost at all.
throw in texture arrays and remove the whole view-frustum-recalculation-every-frame thing, and your bsp rendering drops to almost the cost of just a pointcontents and a glMultiDrawIndirect call.
this is what I did with my 'onedraw' engine, its performance humiliates FTE on most/nearly all maps, but is also far more limited (being from-scratch doesn't help), with no dlights, no lits, no skyboxes, etc.

alternatively, you can move the lightmap updates onto a different thread - fte's 'r_dynamic -1' setting does this.
Unfortunately GL still basically requires the GL api to all be done on a single thread(as does d3d9), though presumably this could be accelerated a little with pbos. 
Shadowless real time is what I mean, yes.

As for lightstyles, when you break down the R_BuildLightmap code it clearly just becomes: texture * lightmap0 * style0 + texture * lightmap1 * style1 + texture * lightmap2 * style2 + texture * lightmap3 * style3. That's trivially easy to express in GLSL with or without additive blend passes, and not much more difficult to express in fixed pipeline GL.

End result is animated lightstyles without new texture uploads. 
Lightmap Updates (1) 
I'm going to rabbit on about this for a while cos it's something that I've done a lot of research on, and the end results were a little counter-intuitive. It's also useful to provide the background and reasoning for what I'm advocating; it demonstrates that I have done the research and that I have the figures to prove it.

So, I'd always been aware that lightmap updates were a bottleneck in GLQuake, and it really hit bad on some RMQ (and other) maps. There are basically two steps to a lightmap update: R_BuildLightmap and glTexSubImage2D.

Contrary to what I expected, when I benchmarked I found that R_BuildLightmap was actually not the bottleneck. You can comment out the calls to R_BuildLightmap so that it still does the glTexSubImage upload, and you get the same bad performance. You can comment out the calls to glTexSubImage but leave R_BuildLightmap in and it runs fast.

With glTexSubImage there are 3 factors that influence performance: size of data being uploaded, whether or not the driver needs to do a format conversion, and whether or not the driver needs to stall the pipeline. 
Lightmap Updates (2) 
For typical Quake lightmap usage, data size is hugely unimportant. Unless you consider extreme cases (e.g update nothing versus update everything) data size just doesn't matter.

Format conversions can kill performance, and the stock FitzQuake code will always need to do a format conversion.

Stock FitzQuake requests lightmaps in GL_RGB format on the GPU, but (unless you're using very weird hardware) there's no such thing as a 24-bit GPU texture format. It's powers of 2 all the way: 8-bit, 16-bit, 32-bit, etc. GL_RGB is also an unsized format, so the driver is free to give you 5/6/5, 10/10/10/2, 10/11/11, 8/8/8/8 or whatever. What you most likely will get is 32-bit, 8/8/8/8 with the last 8 unused, but you're not actually 100% guaranteed that unless you ask for it (i.e GL_RGB8).

At this point some people will kick and scream about "wasting memory". I loathe that term; it's not "wasting" it, it's using it. There may be nothing stored in the memory, it may never be read from or written to, but the extra byte per texel is being used to increase performance. This is the very same principle as cache-aligning data, aligning allocations on page boundaries, aligning (or padding) to 16-bytes for SIMD, etc etc etc on the CPU. Why are people so fucking surprised that similar principles apply on GPUs? Get over it. 
Lightmap Updates (3) 
So stock FitzQuake code has (most likely) a 32-bit texture on the GPU, but supplies 24-bit data on the CPU. That's a format conversion, right there, and you're totally at the mercy of the driver for how efficient (or not) it is.

NVIDIA always seemed to take the fastest path for the type of conversion needed, so a simple conversion might take 1ms but the most complex take 40ms.

AMD/ATI always seemed to take a similar path irrespective, so conversion times might bob around 10ms to 20ms.

Intel was batshit insane. I can't remember the times but they were off the chart. The only explanation I could think of was that the driver downloaded the entire texture from GPU to CPU, did the conversion, then re-uploaded the entire texture back to the GPU. I don't know if that's actually true or not. 
Lightmap Updates (4) 
Stock FitzQuake also did a glTexSubImage upload per-surface rather than per-lightmap. With a typical ID1-sized map, that could be several hundred uploads instead of maybe a maximum of 10. And each one of those uploads is a pipeline stall, so it totally breaks CPU/GPU asynchronous operation. Instead of the CPU handing a bunch of work off to the GPU and being able to continue itself, it instead handed a small bit of work off, waited for it to finish, handed another small bit off, waited, etc, several hundred times per frame.

That's the same codepath that stock GLQuake with R_DrawSequentialPoly took, and the same performance characteristics are observable there. But stock GLQuake didn't have GL_RGB lightmaps, so it didn't do any format conversions; stock FitzQuake just got the worst of every possible world.

This wasn't such a huge problem in the old 3DFX days because the graphics pipeline (or at least the part of it that was implemented by the GPU) wasn't as deep back then. Only per-fragment and framebuffer ops happened on the GPU, so the effects of a stall were significantly reduced. On modern hardware it's catastrophic. It's the equivalent of putting a glFinish call after drawing each msurface_t. 
Lightmap Updates (5) 
Stock GLQuake with multitexture disabled batches up glTexSubImage calls so that they only occur once per lightmap rather than once per surface. It also doesn't do any format conversions.

Stock FitzQuake with multitexture disabled also batches up glTexSubImage calls so that they only occur once per lightmap rather than once per surface. It still does format conversions, but the impact is reduced. It's still horrible on Intel though.

That's why "disable multitexture" was the standard advice when using stock FitzQuake on maps with lots of lightstyle animations. It wasn't that the single-texture path was any faster in the general sense, it was that lightmap uploads were implemented in a more performant manner.

But it's possible to write a multitexture path that also batch-uploads all lightmaps before drawing anything, and in that case disabling multitexure will just make everything slower. 
Lightmap Updates (6, And Last) 
So, current QuakeSpasm fixes all of this with the exception that it uses GL_RGBA/GL_UNSIGNED_BYTE on the CPU. That will still trigger a format conversion on (?some?) Intel drivers. On those drivers, the only combination that doesn't trigger a format conversion is GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV. I believe that on D3D10+ class hardware it's not a problem, however.

None of this scales. It runs fine on ID1 maps, it runs fine on medium-sized maps, it runs fine on small maps with many light updates, it runs fine on large maps with few light updates. It will still excessively slow down on large maps with many light updates. Again, the number of lightmaps grows, the number of glTexSubImage calls increases, factor in brush models and add lots of them, and you're back to hundreds of uploads per frame and all the herkie-jerkies that come from that.

Brute-forcing it on the CPU isn't the answer. With that kind of surface count you'll probably get something worthwhile by threading R_BuildLightmap (which will be called so many times as to make this worthwhile) but you'll still hit a single-thread ceiling with your glTexSubImage calls.

You need to solve it more creatively, and moving the updates entirely to the GPU is the answer. You never need to check if a lightstyle is modified, you never need to run R_BuildLightmap, you never need to call glTexSubImage2D.

And here's something else where parts of the Quake community need to pull a collective stick out of their collective arse. The best-case will run a little slower with this kind of set up. So instead of getting 4000 FPS in DM3 you might get 2500. That doesn't matter a bollocks. You don't optimize the best case, you optimize the worst. Sacrificing a tiny piece of performance (0.15ms) in the best case in exchange for a huge performance increase in the worst (to the extent that there can potentially be no difference between them) is the right thing. 
At this point some people will kick and scream about "wasting memory". I loathe that term; it's not "wasting" it, it's using it. There may be nothing stored in the memory, it may never be read from or written to, but the extra byte per texel is being used to increase performance. This is the very same principle as cache-aligning data, aligning allocations on page boundaries, aligning (or padding) to 16-bytes for SIMD, etc etc etc on the CPU.


The best-case will run a little slower with this kind of set up. So instead of getting 4000 FPS in DM3 you might get 2500. That doesn't matter a bollocks. You don't optimize the best case, you optimize the worst. Sacrificing a tiny piece of performance (0.15ms) in the best case in exchange for a huge performance increase in the worst (to the extent that there can potentially be no difference between them) is the right thing.

I wholeheartedly agree.

_o_ Here's a hug. 
Also, I'd love to see any hardware, ever, where you can run at 2500 FPS. Optimizing is good; obsessing over it is not. 
Thanks Mh 
Nice writeup, it all seems to make sense even though I don't have much to do with rendering stuff. For reference, it was fitzquake085 on the last map of The Five Rivers Land. Big wide arena mostly covered with torchlight and often a half-dozen dynamic-lit projectiles crossing it. Stuttering went away just by facing outwards, so I thought it must be a rendering thing. Quakespasm copes with it without the adverse reaction. 
The Tragedy Of The Commons Takes Many Forms 
Sometimes some newbie shows up and asks why "the Quake community" doesn't do X, Y, or Z like [insert other game, for example "like the Doom community" or "Quake 3"].

But there is no such thing as "the Quake community". Just different individuals of different interests doing stuff they want to do for free.

Its not like someone is demanding Barnak do this or that some Steam user must do this.

No --- because no one makes demands of free loaders and newbies and insists they must do things. 
Ah, I clicked submit instead of preview.

What I was trying to say that even a well-intentioned highly skilled engine coder diatribe about how things should work is still basically saying that someone else has to spend their time a certain way for free.

That point of view has merit.

And it is Tragedy of the Commons because such demands are only directed at the "top producers".

No one makes demands of noobs. 
@mh -- I Still Haven't Communicated Perfectly ... 
In a commercial project that would be sold and generates sales, you'd be absolutely right.

In a free project that is a pastime, I don't know if you are right.

And one of the most important rules for a pastime is knowing it is a pastime.

And The Tradegy of the Common very much applies, you made an exit back in 2013 for this reason and I was already making an exit and once I saw you declare your exit, I left too. It was too much of an out-of-control zoo. 18 months later I'd come back -- sort of --- with firm boundaries in my head and communicate clearly the limitation of what I was willing to (not) do and when I was willing to (not) do it. 
MH's now dead engine, DirectQ, could easily clock 5000+ fps on an id1 map. 
I'm pretty sure that's true, no doubt about it.
Do we have, however, some kind of display who can actually show those 5K FPS?
That was really kind of my point. :) 
Here is a partial list of "blockbuster" map releases in the last few years:

a) A Roman Wilderness of Pain [aka ARWOP]
b) The Alter of Storms [aka ne_ruins]
c) Rubicon Rumble
d) Remake Quake

that will grind down to single digit frames per second in a traditional GLQuake style engines. But a DirectQ or FTEQW can instead of getting 12 fps will get 150 fps or 300 fps.

And these kind of mega-maps have been "the norm" in the last 5-6 years. There are plenty more where those came from. 
Whoa. Can they run on vanilla? I'd love to test them on a iPhone ;) 
a) requires enhanced network protocol (FitzQuake 666 or similar)
b) requires enhanced network protocol (FitzQuake 666 or similar)
c) requires BSP2 support, enhanced network protocol (FitzQuake 666 or similar) and should have alpha masked texture support.
d) requires the Remake Quake engine bundled in the download (BSP2, alpha masked texture support, Remake Quake's protocol 999, hurt blurs, other 2D effects) 
What kind of hardware is actually limited to low FPS in those maps? Laptops with Intel GPUs? No system I've played them on with Nvidia GPUs has had issues. 
With what engine? Quakespasm since late 2014 or thereabout has used vertex arrays so the performance is about triple the norm on maps with tons and tons of monsters. 
Usually Quakespasm. 
try them. fix stuff that doesn't work. job done.
its not like engines that support this stuff are closed source, so it shouldn't be that hard considering the stuff you've previously managed. 
Sample source code implementing protocol 666 download source

Every single protocol 666 change is marked with:


Yeah, every last change is marked. 
Do we have, however, some kind of display who can actually show those 5K FPS?

That's kinda not the part that's important; it's a bit of a strawman, in fact. As some of us have hinted, running DM3 at 5k FPS is actually not an interesting problem. Take 200 FPS: say someone has a 144Hz display and bump the target framerate to 200 to allow headroom for transient peaks. Running DM3 at 200 FPS isn't an interesting problem either. I'm pretty sure that even a low-end phone can do that nowadays.

Running a big, complex map with big, complex scenes at 200 FPS - now that's an interesting problem. You can solve anything if you throw enough brute force at it; but solving it on lower-end hardware too: even more interesting.

Historically the Quake engine was viewed as "can't do big scenes" or "unsuitable for open areas" but it turned out that none of that was actually true. It's obviously not the best engine for this kind of thing, but a primary cause of it's historical problems was in the implementation of it's renderer, and it wasn't too difficult to make the necessary changes to solve those problems.

So do that and what will happen is that running DM3 at thousands of FPS will also happen, but as a side-effect, not as the primary goal. 
A Few Questions Regarding Indexed Colors And Lightmap Blending 
1. per-texel lightmap blending?

How does quake's software renderer achieve per-texel blending? example

2. how and where in the rendering pipeline does "palettization" occur?

I assume that illegal colors are produced after a lightmap is blended with the diffuse texture? If so, my best guess is that palettizing is the last step before being drawn, though I have a feeling this is probably certainly wrong.

3. a practical way to achieve this look for a modern game?

Software render? GL render? GL render + GLSL shaders or some other form of post processing?

here is a screenshot palettized in photoshop. I'm currently using these janky mockups to help inform art direction. Obviously, this method is sub-optimal and I suspect this is not close to what an actual game renderer would output. It's a pain in the ass because this rendering style depends on an appropriate art style else it all turns to shit... hence the previous questions.

After spending months testing color palettes, I have a whole new level of respect for the id art team. Cramming quake in to essentially 240-ish colors is an art form in itself. 
I apologize that can't comment on any of your questions but I do have to say that screenshot is extremely fucking killer. 
I concur. Love the light design on the door and the left & middle monsters. Would be thrilled to see them in Quake. 
I Appreciate The Compliments 
You're welcome. Are these for a Quake mod or a standalone project? 
Standalone Project 
unless the project dies, in which case the assets would probably be handed over to the quake community. 
You have a ModDB page or something for this project? I'd like to know more and keep myself informed. Perhaps send a PM or post in General Abuse? I don't want to clutter the thread with OT. 
for the first and second questions:

1. the lighting is blended with the textures in a "surface cache" which is in texture space so it's always 1 pixel per texel (rather than in screen space where one texel covers many pixels.) That's why you don't see banding that crosses over the middle of texels.

2. the entire renderer is 8-bit so it never has to be "palettized" at run time. 8-bit texture data is combined with light map data in a lookup table called colormap.lmp, where the resulting value is also 8-bit. So i guess it's the creation of this lookup table (shipped with the game) where the palettization takes place.

#3 is complicated an other people probably have better answers than me. 
huh, pretty interesting. that clears a few things up. feels like something that specialized could have some drawbacks. it would be super cool though. devil daggers looks really nice, i wonder how they did it?

@mugwump - no, nothing public currently. I'll make sure you get the word when it's out there :) 
OK, Thanks! 
Oops, Didn't Mean To Check The Q2 Icon... 
...stupid fat fingers on stupid phone! 
The Way FTE Does It... 
#2 something like:
diffuseindex = texture[s][t];
lightlevel = lightmap[lm_s][lm_t];
pixelvalue = colourmap[diffuseindex][lightlevel];

so yeah, a simple 2d lookup.
the surface cache is just a cache that provides a lower res source lightmap, at an appropriate mipmap level.

#3 r_softwarebanding in FTE replicates it with glsl (essentually the same, except the colourmap already has the rgb values expanded to save an extra lookup). taniwha's glsl renderer also does this.
this lookup actually happens 3 times over in fte so that lits work as expected. if the lighting is always grey then its identical(ish) to software rendering.
there's some fiddly stuff required to get the lightmap sample changes snapped to match the diffuse.
and the choice of which mipmap to use follows standard opengl based on pixel distance with an annoying bias based upon the slope of the surface, unlike software rendering picking some midpoint or something and then using a single mip level for the entire surface, so you might want to tweak the d_mipcap cvar to use only the first 3 mip levels or something (yes, FTE uses the proper mipmaps too). this is actually resolution dependant.
talking about resolution, r_renderscale 0.25 will scale the rendered res down. negative values in rev 5026 will give you nearest filtering (with a vid_restart annoyingly).

I have no idea what you'd need to set up to get DP to replicate this. In theory just paletted textures instead of rgb ones. you can probably just provide greyscale or whatever for the base mip level, but autogeneration of the other mips will just result in noise.
if you were to hack some paletization logic into glsl, then my suggestion to you would be to use a 3d texture, but again you'd probably need to hack dp's sourcecode for that.
failing that you'd have to express the colour ramps mathematically. 
2) See r_surf.c

3) Are you sure you want to do this?

The restrictions of 8-bit color software rendering are great for scientific purposes (because they help to expose the needs and the limits of color transformation algorithms), but not for artistic purposes.

After studying software rendering for so long, I'm sure that being truly faithful to its limitations isn't worth the effort. It's too painfully restricting.

You can get good, painless results by reducing the smoothness of each color channel individually. Let's say, by zeroing the lowest 4 bits of each channel, you'll limit the colors to 16 shades per channel, for a total of 4096 colors. This way, you'll be able to create low-color assets without fighting against palette limitations. 
8-bit Is A Worthwhile Artistic Goal. 
A lot of players like/prefer the paletted look. Yes, I'm sure a lot of it is down to nostalgia, but that doesn't make it any less a legitimate reason to pursue the 8-bit look for artistic purposes. 
@spike - interesting. I didn't realize fte had these features out of the box. I'll revisit fte this weekend. Honestly, I can't recall why I switched to dp, I think it was an issue with q3 shaders or something. r_softwarebanding and r_renderscale are some tasty morsels. Is there presently a cvar to control the distance at which a mip is used? Are mips generated by the engine? If so, can I create mips manually to be used instead? If i recall correctly, fte supports fbsp?

@mankrip - It's very restrictive, yes. Sometimes that's a good thing. I am very fond of the idea of an 8bit software renderer. It's a romantic idea, I can see why it would be ultimately be dismissed as impractical by many.

4096 is a lot of colors. I'm currently using 16 shade textures... after lightmaps (some of which are colored) you end up with a fairly large range that just doesn't look right. It's neither 8bit or hi-fi graphics... it's sort of a cheap impression, but not genuine.

If this were magical christmas land, I would have a software renderer with a 512 color palette, or something along those lines. Would that even be? it's not 8bit, but not high color either (I think).

@kinn - I agree entirely. In my case, it's not really nostalgia. Some of my first Doom/Quake experiences where with DP and Doomsday. I later discovered software rendering and immediately preferred the look. There is something magical about it, almost like an animated painting... I can't quite put my finger on it. 
If so, can I create mips manually to be used instead?
A while back in the mapping help thread, Rick told me about a program called MipDip that supposedly allows you to replace the submips. You can find it on Quake Terminus. I tested it briefly but didn't understand how it works, I'll need to look into it more. 
@killpixel, sorry, forgot to mention that r_softwarebanding only works with paletted source textures, which means the feature has only really been tested with q1bsp+q2bsp+q1map(with wads). the engine doesn't generate any mips itself in this mode (so watch out for that too).
I could give you some workarounds for q3bsp, but its probably better if I just add palletization logic so that you won't have to tread so carefully... and get wads+wals working properly for paletteized mips.

anyway, the basic idea is that you use 'fte_program defaultwall#EIGHTBIT' in your shader (giving you glsl-based nonq3style shaders) with a 'map $colourmap' (which preprocesses the colormap.lmp), then fte pulls in the palette+lightmap+etc textures too.
for q1+q2, this already happens by default, but q3 content is much more likely to have shaders overriding things, and fte's explictness means you may want to modify those. 
If this were magical christmas land, I would have a software renderer with a 512 color palette, or something along those lines. Would that even be?

This is one of the possibilities I've studied for a long time, and it isn't worth it. The problem isn't just the size of the palette, it's the speed performance.

A 512 color palette would use 9-bit values for addressing. However, those 9 bits would have to be stored in 16-bit pointers. So, each color index variable would require twice the memory anyway, increasing the amount of cache misses. They would also require bigger color transformation tables and extra bounds checking, which would result in significantly slower performance.

I don't remember all the specifics, but when comparing all possibilities, I've realized that the best options would be to either use direct RGB color values (as Unreal does), or keep the renderer in 8-bit indexed color. And then, since a number of operations are faster to perform in 8-bit indexed color, due to dealing with a single index value instead of individual values for 3 color channels, I've decided to stay in 8-bit. 
And Thus 
mankrip became the dither master. 

forgot to mention that r_softwarebanding only works with paletted source textures

I do use indexed/paletted textures (not quake's palette). though this might not be what you mean?


This is one of the possibilities I've studied for a long time, and it isn't worth it. The problem isn't just the size of the palette, it's the speed performance.

I had a feeling...

So, I really have 2(ish) options: 8bit (with all it's limits) or some sort of post-processing shader.

I don't understand how it works, but a glsl shader seems like a brute force method that's not as accurate as a true 8bit renderer. I imagine it functioning like the way I do it in Photoshop: The scene is rendered, then "palettized", then sent to the display.


thanks for the link to the glsl shader... I've messed with that and a couple other shaders in DP and never got them to work. They either don't work at all or end up looking all messed up... :/ 
a glsl shader seems like a brute force method that's not as accurate as a true 8bit renderer. I imagine it functioning like the way I do it in Photoshop: The scene is rendered, then "palettized", then sent to the display.

AFAIK, that's exactly this.

The "correct" way would probably be to quantize textures to a global 8-bit color palette, generate 8-bit color transformation tables (lighting, blending, etc.) from the palette, and apply them using a fragment shader.

Faithfully replicating Quake's lighting is more complicated, because lightmaps should be upscaled 16x with bilinear filtering, and then quantized to 64 levels. Those 64 levels are then used to index the 64 levels of the color shading map (colormap.lmp). 
AFAIK, that's exactly this.

That isn't desirable IMO, though it may seem trivial to others.

Not only does it seem inefficient, the pre-palettized scene is just an approximation and sometimes won't look the way it's intended once palettized. 
Designing for software rendering is partially about defining the intended looks, and partially about accepting the resulting looks. 
Look At Gz Doom Shader's 
Sorry, I meant to say "that", not "this". I'm not a native English speaker. 
Daemon engine supports Q3 maps and 3D color look up tables which could get you very close I think. In this case you could just take the look up table and apply the palette to it. Otherwise I guess you could do it a la deferred rendering and render lighting and albedo separate and then return the resulting index of lighting + albedo for every pixel, you'd only need 16 bits to store all that. Might be more true to quake's approach but I doubt the average player would notice the difference between the two, especially if you go low-res ("oh this looks like an *old* computer game").

It's probably easier to make a palette whilst doing art, only adding colors to the palette when you really need to, less is more and all. 
#622 - that seems to be the case.

#623 - I'm familiar with that. I think it's since been assimilated by the latest gzdoom build as "tonemapping".

#625 - I think I've come across that engine before, I think it was developed for a particular game? Something natural selection-esque IIRC. I'll have to give it another look. Thanks for the lead. 
Out Of Curiosity 
Is there an existing GL engine that accurately fakes the software look? 
Qbism super8 I think.

quakespasm with all the graphics settings nerfed. 
Quakespasm is not 8bit. 
I thought super8 was a software engine? Besides, I tried super8 and it fucked with so many basic things that I never wanted to open it again (weird particles, stupid weapon swaying etc, and it had some pointless palette-bend on by default which screwed up all the colours. 
quakespasm with all the graphics settings nerfed.

I'm talking about an emulation of how the software engine takes the texture pixel and the lightmap and then uses a LUT (quake's colormap) to output a colour still in the quake palette. There's something about the final look which is just magical to me, and it's not just nostalgia talking :} 
Mark_v Software Mode? 
I am sure that Mark_V has a winquake style version now? Not tried it a great deal but might be worth checking out 
MarkV WinQuake looks great but is a software engine and thus I get single digit framerates on modern maps.

I was just hoping someone may have tried to emulate the software look using a modern graphics API, that's all. 
Well, I know you don't like DP but Nahuel recently uncovered a GLSL shader for DP that aims to emulate the retro look. I haven't tried it so I don't know how accurate it is, but you might want to give it a try. You can find it here:
Note that the 2016 DP builds break this shader, so Seven has fixed it (scroll down to post #10 for link). 
Read baker's last post in the mark v thread. I just shat myself with excitement. 
Read baker's last post in the mark v thread. I just shat myself with excitement.



Windows WinQuake through Open GL for KillPixel

You mean that? Because if that means what I think it means, then consider my dungarees dung'ed and my breeches browned also! 
damn just realised a few posts up people are talking about FTE doing this - I'll have to have a look. 
The Browning 
not sure if it was mentioned, but FTE has r_renderscale, too. 
I thought you were talking about the markv thread. I'm fucking brilliant. 
fte with r_softwarebanding 1 uses 8bit rendering for the world and models, except for coloured lighting (where each colour channel is performed as a separate lookup) so disable lit support if you want strict 8bit colours.
this applies to world(gl+vk renderers) and models(gl renderer). other things including particles etc are unaffected by this, but at least fte's particles can follow palette-based ramps too. 
Thanks - just had a look and r_softwarebanding looks lovely and I even like how it looks with fog and coloured lights on top of it too!

There's a lot of stuff I'll need to turn off though to make it look and sound more vanilla - is there a "proper oldskool" config somewhere? 
how do i turn off the mouse smoothing in FTE? 
m_filter defaults to 0 so reset that if its no longer 0. there isn't any other mouse smoothing.
m_accel 0 maybe? again defaults to off.

'fps_preset vanilla' should disable(and in some cases enable) all the stuff to make fte feel like vanilla's software rendering, including the demo reel, nq sbar, nq player physics, software banding, square particles, disables lerping, etc.
complete list of cvars changed with the presets: (each preset is cumulative with the prior ones, so you'll need to consider the settings above the vanilla preset also, if you want the complete list)
the problem with lots of settings is figuring out which ones you actually want set. :s 
quakeforge's glsl renderer should also render much like software rendering (unlike its regular non-glsl gl renderer).
that said, I don't know how easy it is to get quakeforge to actually run, hopefully taniwha has fixed it up a little since I last tried. 
m_filter "0"
m_accel "0"

I have those set but it makes no difference - the mouse just feels weird and laggy compared to quakespasm, like the movement is being interpolated or something. QS feels immediate... 
I'm sure you've checked, but is vsync enabled, either in the client or forced by your gpu settings? 
I'm sure you've checked, but is vsync enabled, either in the client or forced by your gpu settings?

No I hadn't checked, and that was indeed the culprit.

vid_vsync "0" now added to my config. Cheers! 
Engine CPU / GPU Usage 
Can anyone recommend a tool I can use to profile the cpu / gpu usage of quake engines on my pc? I have noticed that when using Quakespasm, my laptop is silent, but on other engines I've tried (FTE, MarkV), running under the same config I use for QS, my laptop's fan blows like a foghorn for some reason... 
Gonna have a punt with a tool called HWiNFO. Will report if I see anything interesting 
This is almost certainly happening because QS is using a Sleep call every iteration of it's main loop, whereas other engines are not.

There are valid arguments to be made that running flat out is actually correct behaviour for a game engine. 
Might that also be related to how QS's CPU usage rockets when I have it minimised vs when I'm playing it? 
Right, So 
I used HWiNFO to log all the stats when running the quakes.

I did a test where I played demo1 twice in QS, and did the same for MarkV using equivalent graphics settings etc. (actually I played demo1 three times in MarkV because the fan was really going crazy after the second time round and I wanted to see if it was getting any hotter)

So here is a simple chart of the max CPU temp across all my cores when playing the demo, sampled at 2-second time intervals (there are less samples for QS because I played the demo twice there vs three times for MarkV)

With QS my CPU temp always stays just below 50C, but with MarkV it's constantly running over 70C.

Now I'm no engine guru but my gut feeling is I'd rather keep my CPU temp at 50C if I have a choice in the matter (considering I'm getting identical framerate in game either way)

mh - what are the advantages to "running flat out", as you say? 
is this win7? you can set your cpu states in power management. depending on your mobo you can do this via the bios. You can also have the client run on 1 core, may help temps. Maybe even give process tamer a try.

70C isn't necessarily bad. I wouldn't want to run 74-80 constantly, though. 
Not sure I want to go digging around in bioses and tinkering with CPU settings, not really my area :} 
Yeah, QS has a 1ms sleep in main_sdl.c. It also sets the Windows timer precision to 1ms (done by sdl) - afaik this raises power use somewhat for the entire system while QS is running, but it should mean that a 1ms sleep is actually 1ms and not 15ms or something.

Just looked at MarkV's source, it looks like you need to set "host_sleep" "1" to enable sleeping.

I imagine the temps will be about equal once MarkV is sleeping. On complex non-id1 maps QS may take a lead, owing to its new GL renderer, but not sure if this will show up in temps. 
Host_sleep "1" 
Well damn, that did the trick! Just did another profile and the temps in MarkV are down to around 50C, similar to QS.

So, any reason why this isn't the default behaviour? 
Advantages To Running Flat Out 
First of all, and to establish context, there at least used to be a perception that Quake is an older game, uses less resources, therefore it should have lower CPU usage than a newer game. However, a simple "while (1) {}" loop is sufficient to peg a CPU core at 100% (you won't see this in modern Windows because the OS will move it from core to core quite frequently). So it's not the amount of work you do that matters.

Both Windows Sleep and Unix/Linux usleep specify that Sleep times are a minimum, not a guaranteed time interval. To quote from the usleep man page: "The sleep may be lengthened slightly by any system activity or by the time spent processing the call or by the granularity of system timers."

So when you sleep for 1 millisecond, you will actually be sleeping for more than 1, and the specification allows it to be much more than 1; this can be sufficient to cause you to miss a vsync interval, or disrupt input. 1 millisecond doesn't sound like much, but if you remember that 60fps is 16 milliseconds per frame, then it's a substantial enough fraction of it.

At this point a typical reaction might be something like "Quake frame times are so short anyway, surely this is just a theoretical problem". So let's assume that a typical frame time is 1ms. The frame runs then it's followed by a bunch of Sleep(1) calls until it's time to run another.

It should be obvious what's going to happen - at some point the last of those Sleep(1) calls is going to fire, and if you sleep for just a little too long you're going to miss the interval and the next frame will run late. Slightly late with vsync disabled, but with vsync enabled you'll drop to 30fps.

So the reason why it's preferable to run flat out is because the alternative is potentially worse.

That shouldn't be read as meaning that all Sleep calls are bad. If you're running on battery your priority changes and you'll definitely want to sleep. But sleep as a general solution should be avoided; the OS should move your program between cores automatically which will prevent individual cores from ever running at 100% all the time, so nothing should be overheating. Or alternatively, if it's a multithreaded game that's already CPU-bound, then you most definitely don't want to be giving up a resource that you don't have enough of to begin with.

None of this is going to convice anyone who's already made up their minds, I know... 
Very Interesting 
how does this relate to c-states and os power management? Do sleep calls trigger certain c-states? If a system has c-states and power management disabled does host_sleep override that or does it do nothing? 
I don't know about Linux, but on Windows Sleep calls don't define how your program interacts with OS power management. All that the documentation states is that the current thread is suspended for an interval based on the value you specify.

What I infer from that is that if there's other work that the core could be doing, it will do it, so you should have no expectation that calling Sleep will guarantee that you'll go into a power-saving mode. After all - Quake isn't the only program running on your OS. 
Thanks for that detailed explanation, most informative. 
My only objection, for Windows anyway, is the current Sleep docs here seem to state pretty clearly that, if you set the timer resolution to 1ms with timeBeginPeriod, a Sleep(1) will actually sleep somewhere between 0 and 1ms, but not more than 1ms. IIRC, I have measured Sleep(1) sleeping for several milliseconds if you don't call timeBeginPeriod, but if you do it's reliably never more than 1ms. (Of course, this is one random test I did, one PC, probably windows 8.1 or 10, but at least it matched the docs.)

Agree regarding vsync.. it always seemed broken to me, at least in QS (adds so much input lag that it's almost unplayable), maybe most Quake engines (?). If vsync is in use, shouldn't the throttling of the mainloop be left to the blocking "swap buffers" call? 
I See, Thanks 
If vsync is active then I suggest don't throttle otherwise, either via sleep or Host_FilterTime. IIRC a glFinish immediately after SwapBuffers helps some; causing input to sync up correctly with display, otherwise the CPU may be running a few frames ahead of the GPU.

Last time I checked vsync was a busy-wait on some hardware/drivers, but that was in the D3D 9 era. 
About 3 weeks, I tried the Mark V WinQuake on a high end gaming laptop I imagine is similar to yours.

The experience was absolutely terrible and was like 10 fps.

Keep in mind on my Windows machine which is nothing remarkable, I get an easy 300-400 fps in Mark V WinQuake on resolutions like 640x480.

I made some adjustments in the just uploaded Mark V which I think may dramatically improve the WinQuake version with machines like yours.

(*I say "I think" because I made some adjustments for the GL version and it was perfect afterwards on that machine. It slipped my mind to do a WinQuake test, so I can't know for sure.) 
Ace, just had a go on your new GL WinQuake! Will report back in the other thread 
Is Darkplaces Still In Development 
is it worth my while reporting a bug? 
DP Is Not In Active Dev 
as far as I know... 
There is a gitlab with bug tracker here, not sure if it's Xonotic specific. However, it doesn't look like a fork; at least commits are synced between that and the icculus site. Still seems to be somewhat active. 
@Shamblernaut ... Check This Out! 
Thanks Guys :) 
We'll see if this fixes the bug, which is likely linux specific. 
heh, doesn't fix it... The 64 bit glx version forces my monitors into mirrored mode, rather than primary / secondary.

SDL version works fine though. 
DP Is Not In Active Dev as far as I know...
It is again since April 2016, as evidenced by Icaro's link (don't refer to the outdated Downloads page). 
I Updated My Quakespasm-IRC Engine 
It now uses the latest quakespasm base code.

I'm also slowly adding speedrunning features to it. When it gets a proper release with more features I might give it a name change and make a proper news post for it.

For now, if you're planning on streaming playthroughs, here ya go.

Random Question 
Does the .lit file contain all the lightmap information, or just colour information? 
It contains black magic and the souls of the undead. Want to check? Try loading a map that needs one... WITHOUT IT!!! 
It holds colour * intensity, so an intensity 0 red light will be 0|0|0.

Everything else needed for lighting is actually stored in the surfaces lump, outside of the lightdata. So: each surface stores an offset into the lightdata where it's lightmaps begin (if that offset is -1 then the surface has no lightmaps and so is fullly dark), as well as the styles used by the surface. 
Ah Ok 
Qrack Github 
Does anyone know why in Darkplaces sometimes the sky will show on the water...instead of the water? Is this fixable or a bug? 
Just A Guess 
But maybe it is caused by using the pretty water pack when the map is not water-vised. 
I think you're right, says it right in the README.

Having other issues now for some reason, if I alt+tab out of DP it will not let me back in the game and I have to ctrl+alt+delete...everytime. 
Fix Blinking Lights Issue 
Similar problem with latest darkplaces in VR on android port.

Set gl_nopartialtextureupdates 1 to fix 
So, is Quakespam the only engine compatible with 64-bit Linux? That sucks. :( 
No, FTE works fine too, at least when I've tried it on Ubuntu. 
Any other engine closer to Vanilla that works on 64 bit? Something like FitzQuake 
Mark V? 
Ugh, with that much cruft, FTE is a much better option. 
It's crazy how many features FTE has. It feels like a general purpose engine that happens to run Quake. The lack of documentation on the functionality might be really holding it back.

Congrats, Spike. There's a lot of good stuff in there. 
Doing FTE research, I found this:

It's like a micro-engine by Spike. This is just awesome. Minimal, effective, perfect. 
TyrQuake 0.65 is out:

Pretty good performance with Arcane Dimensions on old hardware. 
Whoa! Cool! 
I didn't realize Tyrann was back at it. :^) 
that is awesome, by far my favorite quake engine. it works everywhere. 
I've never looked at TyrQuake tbh.

I assume it's an engine that is designed to play quake, as opposed to one of these engines designed to play some "ate-a-block-of-stilton-before-bed-fever-dream programmer-art" version of quake? 
very fast, efficient engine, no bullshit. runs the game very well on 64-bit linux. just a joy to play with it 
Neat. Changelog is viewable here BTW: 
does quakespam have a software renderer version? can't find anything to play quake on software mode under wayland 64bit 

FTE runs on Linux and has a software-ish rendering mode. If you just care about the end results rather than the tech used, this may do it for you.

Also TyrQuake got some surprise updates recently, does have a software renderer, and you can compile-it-yourself for Linux. Haven't tried that yet though. 
TyrQuake it is. Works flawlessly. Beautiful. 
9 posts not shown on this page because they were spam
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.