A comparison of Quake Engines focused on Singleplayer
I updated it with some corrections and fixes.
QMB indeed does fullbrights, my fault.
For the animation interpolation I guess I will have to check them all again and watch closely at normal speed.
frag: Thanks!
FrikaC: The truth sometimes hurts. But it should be no reason to be offended, especially if your engine focused more on modding features. The comparison is full-on Singleplayer maps. It would be very different for mod support.
QMB indeed does fullbrights, my fault.
For the animation interpolation I guess I will have to check them all again and watch closely at normal speed.
frag: Thanks!
FrikaC: The truth sometimes hurts. But it should be no reason to be offended, especially if your engine focused more on modding features. The comparison is full-on Singleplayer maps. It would be very different for mod support.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
I found it a very interesting and informative test, and it's certainly highlighted a few areas where engine coders may need to concentrate their efforts. I'm not going to get too hung up over what an engine I made 4 or 5 years ago can or cannot do, but I will make some general comments that I think apply across the board.
Mod support is always the killer. You never know what weird quirks a mod might exploit in order to do it's thing, especially if the QC and/or map sources are unavailable. Even something as basic as a cleaned up render path could end up breaking certain mods. I'd love to see an "engine killer" map that only used ID1 features - that would be a much more valid and useful tool for an engine coder to build compatibility for larger maps. At least one could focus one's efforts on genuine support for the larger map, rather than continually getting sidetracked with building fixes for unintended QC exploits.
A lack of true standards is another thing that probably explains why a lot of engines don't have certain things implemented. Take loading a sky box from worldspawn. What key name do you use? What folder do the sky boxes go in? Does the value include the path or not? What's the naming convention for the 6 components? How do you react if you can't load all 6? Copying what Darkplaces does is the nearest we have to a standard, but then we get a new map that's designed for a specific faithful/minimalist engine that does things differently! The poor coder has to make the choice between trying to support every possible standard (and potentially creating a mess in the process), only implementing what seems reasonable to them (and potentially getting burned when their engine doesn't support stuff) or not bothering at all. It's a no-win situation.
The faithful/minimalist/purist people are another stumbling block. Engine coders like adding new effects, because they like Quake The Game but want to bring it's overall look up to more modern standards (or at least I know that's my motivation - when I see Doom 3 maps, I just think "wouldn't it be so cool if e2m5 looked at least partially like that?"). For most people this isn't a problem, but there is an extremely vocal minority who shoot down anything that doesn't look like DOS Quake at 320 x 200 (OK, silly exaggeration, but I'm sure you know what I mean).
Finally, there is no true collaboration among engine coders. I'd personally love to work with some of the folks out there on a single common codebase. Such a custom engine would stand a better chance of being all-things-to-all-people, and individual coders would be better able to focus on specific areas they're stronger in (in my case I'm good at kickstarting new and different ways of doing things, but a poor finisher). Collaboration is limited to exchanging snippets of code and giving the occasional helping hand, but it stops there. Most work is done in isolation. It's actually worse since QuakeSrc went down, as there's no melting pot of ideas any more.
It seems this got a bit more rant-ish than I'd intended, but I do think it's relevant in the context of this test, and would be interested in hearing what other engine coders think.
Mod support is always the killer. You never know what weird quirks a mod might exploit in order to do it's thing, especially if the QC and/or map sources are unavailable. Even something as basic as a cleaned up render path could end up breaking certain mods. I'd love to see an "engine killer" map that only used ID1 features - that would be a much more valid and useful tool for an engine coder to build compatibility for larger maps. At least one could focus one's efforts on genuine support for the larger map, rather than continually getting sidetracked with building fixes for unintended QC exploits.
A lack of true standards is another thing that probably explains why a lot of engines don't have certain things implemented. Take loading a sky box from worldspawn. What key name do you use? What folder do the sky boxes go in? Does the value include the path or not? What's the naming convention for the 6 components? How do you react if you can't load all 6? Copying what Darkplaces does is the nearest we have to a standard, but then we get a new map that's designed for a specific faithful/minimalist engine that does things differently! The poor coder has to make the choice between trying to support every possible standard (and potentially creating a mess in the process), only implementing what seems reasonable to them (and potentially getting burned when their engine doesn't support stuff) or not bothering at all. It's a no-win situation.
The faithful/minimalist/purist people are another stumbling block. Engine coders like adding new effects, because they like Quake The Game but want to bring it's overall look up to more modern standards (or at least I know that's my motivation - when I see Doom 3 maps, I just think "wouldn't it be so cool if e2m5 looked at least partially like that?"). For most people this isn't a problem, but there is an extremely vocal minority who shoot down anything that doesn't look like DOS Quake at 320 x 200 (OK, silly exaggeration, but I'm sure you know what I mean).
Finally, there is no true collaboration among engine coders. I'd personally love to work with some of the folks out there on a single common codebase. Such a custom engine would stand a better chance of being all-things-to-all-people, and individual coders would be better able to focus on specific areas they're stronger in (in my case I'm good at kickstarting new and different ways of doing things, but a poor finisher). Collaboration is limited to exchanging snippets of code and giving the occasional helping hand, but it stops there. Most work is done in isolation. It's actually worse since QuakeSrc went down, as there's no melting pot of ideas any more.
It seems this got a bit more rant-ish than I'd intended, but I do think it's relevant in the context of this test, and would be interested in hearing what other engine coders think.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Here you go: http://www.quaddicted.com/quake_engines ... spirit.zipr00k wrote:Spirit can you link me to a map that has fog in worldspawn to test?
mh: The lr map is a good id1-engine-killer. Simply a large box with loads of monsters and items.
I fully agree about the lack of standards.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Why should there be an all things for all people engine? I disagree there, since you can't possibly find the perfect commonground needed for everyone, or even most people, to be happy. Some feature or possibility will suffer. Overly new and cool features and optimisations and fixes will either break compatibility, or create a hell for the devs to debug (DarkPlaces) and still not be entirely compatible. Then again, a perfectly compatible engine with only minor features and fixes, possibly more balance and polish related than anything, won't match up in general coolness against engines wanting to be more than Quake. Why not just be honest and straightforward with things, than trying to find a commonground where a lot of people need to make sacrifices or compromises. There are engines which do only minor changes to just enhance your Quake experience a bit, or provide support for minor coolness for new maps (Fitz and arguire), and there are engines which don't even claim to be Quake (*cringe* Tenebrae). Things go bad when you try to be perfect for everyone. Things will go wrong.
I was once a Quake modder
let's see tenebrae on the list just to show how much it sucks in comparison
also every engine should support "gl_texturemode" or at least I can't name one that doesn't. Any that don't are really dumb anyway. GL_NEAREST_MIPMAP_NEAREST is the 'software' var for that you're looking for but it's not exactly using COLORMAPS and things so i wouldn 't really call that software, and plus there's the case of rounding down/up textures to be taken into account which will fudge appearances
also every engine should support "gl_texturemode" or at least I can't name one that doesn't. Any that don't are really dumb anyway. GL_NEAREST_MIPMAP_NEAREST is the 'software' var for that you're looking for but it's not exactly using COLORMAPS and things so i wouldn 't really call that software, and plus there's the case of rounding down/up textures to be taken into account which will fudge appearances
i should not be here
Spirit: I agree, people shouldn't get mad, but I can understand why they might. At any rate I was half joking.
There seems to be 4 different types of engines.
Engines meant to be pretty.
Engines meant to be faithful/minimalist
Engines for multiplayer.
Engines for modders.
Some are combinations of one or more, and the last category is sorely neglected. The only two with any chops in that area is DarkPlaces and FTE. I have little use for the first three categories personally, pretty features drag the game down and are generally useless to me. I'm not very aesthetic driven. On the other hand why would I want something that bends over backwards to achieve some old, weird look? It goes in the same bin about being all aesthetic.
There seems to be 4 different types of engines.
Engines meant to be pretty.
Engines meant to be faithful/minimalist
Engines for multiplayer.
Engines for modders.
Some are combinations of one or more, and the last category is sorely neglected. The only two with any chops in that area is DarkPlaces and FTE. I have little use for the first three categories personally, pretty features drag the game down and are generally useless to me. I'm not very aesthetic driven. On the other hand why would I want something that bends over backwards to achieve some old, weird look? It goes in the same bin about being all aesthetic.
My problem is, I myself am a casual player in some ways... I basically use only DarkPlaces or FitzQuake (or WinQuake). DP supports a fair bit for modders, its also pretty (but I have tons of control over that - tons), and when it comes to playing on a server, the only thing I need to ask myself is its location, and maybe if its using 'cheatfree', but I know from most people to not expect that.
99% of the time, it works as my "I'm going to play Quake" engine, whether that playing be id1, a mod, or a new map. It is far from perfect... ...and I do love logging centerprints. But as a casual player, it does a damn good job at everything I want, and rarely do I run into its exceptions.
Regarding faithful/minimalist... I don't feel I lose any of the Quakeyness with DP. Especially having the soundtrack in ogg, and with control over the particles and lighting like I do. But you did also cover that this section of the overview is completely subjective, as it would be in any person's case.
I don't want to start any off topic debate from this (and if some does, well, we can split it off into a new thread), but these are some things that often are in my mind when people speak of engines.
99% of the time, it works as my "I'm going to play Quake" engine, whether that playing be id1, a mod, or a new map. It is far from perfect... ...and I do love logging centerprints. But as a casual player, it does a damn good job at everything I want, and rarely do I run into its exceptions.
Regarding faithful/minimalist... I don't feel I lose any of the Quakeyness with DP. Especially having the soundtrack in ogg, and with control over the particles and lighting like I do. But you did also cover that this section of the overview is completely subjective, as it would be in any person's case.
I don't want to start any off topic debate from this (and if some does, well, we can split it off into a new thread), but these are some things that often are in my mind when people speak of engines.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
@spirit: I think you started a very useful thing here. TBH I am quite surprised that Q2K4 was able to load lr.bsp, let alone run it (I knew that it would run Marcher because I used this map to stress the engine in the latest versions, but this was almost 3 years ago). I think that, presuming you will continue and expand your tests, you could add a bit more info like what resolutions and bpp were used. Also, while the method you choose is valid for the casual gamer (to run the engines with defaults or minimal changes in configurations), some interaction with the projects coders to grab tips on fine tunning configurations files could be a very useful resource for those searching ways to squeeze the last drop of performance from their ancient hardware.
@mh: I agree with pretty much everything you pointed. Tomaz' cleansrc was the nearest thing of a good and safe start point for beginners, but while it was a noble and very successful effort, it was also a lonely one. We really should have embraced and improved it, so anyone could use that as a solid-rock base code without many hardcoded limits that plagued vanilla GlQuake. With such code base, writing code patches would be easier, and we could even have some patch interdependency control. I don't know if it's too late to do that, but it could helped A LOT to have something like this back then.
@mh: I agree with pretty much everything you pointed. Tomaz' cleansrc was the nearest thing of a good and safe start point for beginners, but while it was a noble and very successful effort, it was also a lonely one. We really should have embraced and improved it, so anyone could use that as a solid-rock base code without many hardcoded limits that plagued vanilla GlQuake. With such code base, writing code patches would be easier, and we could even have some patch interdependency control. I don't know if it's too late to do that, but it could helped A LOT to have something like this back then.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
I thought it was a fair and valid review and a rather detailed one from the perspective of a mapper's intent point-of-view, which a true single player enthusiast cares about the most.
Fog, skybox, lit support and especially compatibility and consistency.
Playing around with cvars is something most people don't do, unless it's standard GLQuake or WinQuake or not far from that.
It's hard to keep track of new cvars in any modern engine. FuhQuake was the last engine that kind of kept that under control and every engine after that, the number of cvars exploded.
Fog, skybox, lit support and especially compatibility and consistency.
Playing around with cvars is something most people don't do, unless it's standard GLQuake or WinQuake or not far from that.
It's hard to keep track of new cvars in any modern engine. FuhQuake was the last engine that kind of kept that under control and every engine after that, the number of cvars exploded.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
For those willing to fix their engines in order to load really huge maps like warpc.bsp from WarpSpasm, here follow my findings:
This map has more than 32767 marksurfaces, so we must be sure that indices values read from disk are treated as unsigned shorts, so open up gl_model.c and find the following lines in Mod_LoadLeafs:
Just add a cast to (unsigned short) before the calls to LittleShort() and the ugly crash goes away. Now I am stuck with a "Mod_ForName: NULL name" when loading submodels.
EDIT: Hmmm, I found why the message: the map tries to load more than 256 models, breaking protocol compatibility with Quake. Sigh. :?
This map has more than 32767 marksurfaces, so we must be sure that indices values read from disk are treated as unsigned shorts, so open up gl_model.c and find the following lines in Mod_LoadLeafs:
Code: Select all
out->firstmarksurface = loadmodel->marksurfaces + LittleShort(in->firstmarksurface);
out->nummarksurfaces = LittleShort(in->nummarksurfaces);
EDIT: Hmmm, I found why the message: the map tries to load more than 256 models, breaking protocol compatibility with Quake. Sigh. :?
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
eek, seems like I should have done better preparation
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Eh, it's okay, it's a great starting document and, if you have time, you can tweak it from time to time based on the feedback/comments of engine coders
The fact that your page generated such discussion is already very positive in itself, I find
The fact that your page generated such discussion is already very positive in itself, I find
Neurotic Conversions - New location: Update your bookmarks!
Actually warpc is a good test indeed as aguirRe verified.
It sure is a bitch of a map and nothing you would expect as engine coder. By no means every engine MUST support it, it was just the "extreme maximum super giga hyper" "let's let the engine crash" map.
It sure is a bitch of a map and nothing you would expect as engine coder. By no means every engine MUST support it, it was just the "extreme maximum super giga hyper" "let's let the engine crash" map.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews