Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

What things are worth listing about engines? Goto page 1, 2 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Fri Jun 20, 2008 5:28 pm Post subject: What things are worth listing about engines? |

I will be adding an Quake engine archive to Quaddicted.com and need some input (to prevent an "disaster" like my engine comparison apparently was). So what would be interesting to list/test? Here is my first sketch. It's not well sorted, hope it's not too bad. Comment, critic and flame:

Code:
title author url description (free text) platform (x86, 64bit, whatever else)
os (windows, mac, linux, ...)
renderer (gl, sw, other)
protocol (nq, qw, custom)
features:
gamma (yes|no)
overbright lighting (yes|no)
fullbrights (yes|no)
realtime shadows (yes|no)
coloured lights (.lit) (yes|no)
entity files (.ent) (yes|no)
in-game video mode change (yes|no)
texture formats (list of formats)
external texture support for (bsp, models, sprites, hud)
model formats (list of formats)
sound formats (list of formats)
bsp formats (list of formats)
nehahra support (yes|no)
CSQC (yes|no)
extensions:
QSG_ (none/some/all)
DP_ (none/some/all)
model animation interpolation (yes|no)
waterwarp (glquake, software, custom)
particles (glquake, software, qmb, custom)
transparency (yes|no)
tga skybox (worldspawn/manual) (yes|no)
fog (type and worldspawn/manual) (yes|no)
console:
tabcompletion (yes, enhanced|yes|no)
filename completion (yes, list of commands|no)
centerpring logging (yes|no)
switching game in-game (yes|no)
enhanced menu (yes|no)
resolution independant HUD (yes|no)
custom HUD (yes|optional|no)
dzip (yes|no)
special features (free text)
limits:
>600 edicts (yes|no)
>256 models (yes|no)
>255 sounds (yes|no)
Packet overflow fixed (yes|no)
what other limits are rather important?
parentengine (name of the parent engine, eg "glquake")
releases:
release:
filename (engine.zip)
filedate (dd.mm.yy)
version (1.23)
source (engine_source.zip|lost)
release:
...

I guess for "transparency" there should be several options for different transparencies (bsp, models, sprites?)?
For mods I will need something alike, work on that has not started yet. If anyone feels like doing it, please do and make a new thread or mail me. Cheers!
_________________
Quake Maps
Last edited by Spirit on Tue Jun 24, 2008 8:06 am; edited 4 times in total

Back to top |

Entar Joined: 05 Nov 2004 Posts: 422 Location: At my computer |

Posted: Fri Jun 20, 2008 5:44 pm Post subject: |

Supported .bsp formats should be in there too, I think. _________________ woh... feelin woozy... too much cider... http://entar.quakedev.com games fascination - My Game Development Blog/Journal

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Fri Jun 20, 2008 6:14 pm Post subject: |

don't forget the source. _________________

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Fri Jun 20, 2008 6:45 pm Post subject: |

An excellent suggestion and a important reminder, thanks a lot. _________________ Quake Maps

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Sat Jun 21, 2008 10:11 am Post subject: |

Added protocol, CSQC, resolution independant HUD and enhanced menu. Anything else? _________________ Quake Maps

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Sat Jun 21, 2008 10:59 am Post subject: |

Game changing. Add "custom" to particle types. Flag for external texture support on BSP only/BSP + some others/everything. Custom HUD/Sbar (yes enforced|yes optional|no) You've got Nehahra, but what about more general mod support? I reckon that it can be reasonably assumed that for any given engine there will be some mod out there somewhere that breaks. Maybe use a baseline of ID1/hipnotic/rogue?
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Sat Jun 21, 2008 11:24 am Post subject: |

Added, thanks. Compatibility is a huge issue. id1/hipnotic/rogue support is mandatory, otherwise the engine gets a big red "not compatible" note in specialfeatures. Apart from that it testing for compatibility would be too much work. Except of course for later reports that this or that does not work.
If you have certain "killer-mods" to suggest though it would be a good idea. But then I remember what I tested with the maps in my comparison and the very snappy reactions.
Maybe a "compatibility" list with mods and maps that the engine breaks (or possible workarounds like spprogs.dat for the missionpacks in quakeworld engines)?
The game changing ability is a touchy thing too, at least when it comes to hipnotic and rogue. In a perfect world any engine that supports the mission packs properly AND has an in-game game switching command would treat "game hipnotic" as "-hipnotic" instead of "-game hipnotic" (because of the specific engine code).
_________________
Quake Maps

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Sat Jun 21, 2008 11:01 pm Post subject: |

Spirit wrote:
If you have certain "killer-mods" to suggest though it would be a good idea. But then I remember what I tested with the maps in my comparison and the very snappy reactions.

Okay, I know that's for me.
Please don't get me wrong Spirit. I still think you made a really good job with your tests. Only pushing limits we can discover broken things or flawed archtitecture decisions, and I am always favorable to improvements. What really pissed me off back then was the attitude from others when I questioned the choice of warpc.bsp as a generic stress test, since this map not only requires robust BSP load/rendering support from the engine but also extended (non-retrocompatible) network protocol to load about 320 submodels (doors, plats, etc), something which only very few engines actually achieve even at this time. I read some stupid comments blaming my engine and not the map choice as the problem, and nobody likes to see the fruit of his work criticized by someone who clearly don't have the minimal knowledge to do that. Still, I choosed not reply and make this a longer and useless discussion. Also, I understand that was never your intention to generate any kind of pressure over the engine developers, because at the end most of us keep our projects as a hobby. So, no hard feelings from my part, and go ahead in your research project, it's a useful job to our community.
EDIT: for grammar
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Sun Jun 22, 2008 2:08 pm Post subject: |

That's a very good point, actually. I'd also not be in favour of using a map that was tied to specific backend engine features as a test. In fact, I'd go so far as to say that it seems a clear case of sidetracking into testing which engines are compatible with a certain specific mod, rather than the other way round (testing which engines have the widest mod compatibility).
Bottom line: if a mod also breaks in regular GL/Win Quake, then a custom engine that it breaks in shouldn't get the red X.
I've thought a bit more about mod compatibilty, and I'm actually going to suggest a 3-tier ranking: breaks | runs (but not all features enabled) | works perfectly.
The second one deserves a bit further comment. The kind of "features" I'm referring to here are cosmetic features, rather than gameplay features. To use an example most of us would be familiar with, let's look at Hipnotic. Among other things it has moving water brushes which are used to simulate waves, bullet hole sprites and alpha-stippled "windows" (footnote 1). The water brushes could be used as a gameplay feature (move the brush to reveal a hidden area) so that's a "break" result (footnote 2). Absense of the bullet-hole sprites is a "run" result. The "windows" is an interesting one. I'd put them as a "work" result if they're not supported, as they're also not supported in GLQuake (and possibly also WinQuake - I haven't tested) (footnote 3).
_______________
(footnote 1): Most people don't know about these. If you go to the start map and look in the hall with the moving lights you'll see them. They're brush models with alpha (palette index 255) texels in, so they're clearly intended to be windows.
(footnote 2): Interestingly, that's also a "break" result for regular GLQuake (but not for WinQuake), as you just have to turn on r_wateralpha to break it. I don't know if the Hipnotic QC actually allows them to be used in this way, but a mod might (with the same "break" result for the custom engine and for GLQuake).
(footnote 3): Others might consider them a "run" or even a "break" (if you can't see what's through the window it affects gameplay). The important point is that the result for the custom engine is also the same as the result for regular GLQuake.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Mon Jun 23, 2008 6:37 pm Post subject: |

That three level compatibility is a good idea. "Works" and "Runs" are way too hard to determine though I think. If one thing works, then maybe some other feature is broken. Testing everything would be a Sisyphus-task. So I would use "compatibility rating": "good", "problematic"(?) and "bad" rather.
Those three things you mention about Hipnotic are things I never really noticed, heh.
So, what things to test in which maps/mods (the engine's default settings will be used, unless the readme of the map/mod suggests something)?
-hipnotic: window alpha on start map (room with moving lights)
-hipnotic: bullet hole sprites
-hipnotic: moving water brushes (what map?)
-kinn_marcher: loads, runs in playable speed
- ?
Nehahra is "the" Quake mod, yet engine support is very limited. Thus it will not influence the "compatibility rating" but it will be a criteria in the infos (like "Nehahra Support: No").
frag.machine: Well, a bit of pressure sure was part of my intentions. But the warp map sure was a bit over the top. And the artificial lr map anyways. But then the focus was on singleplayer maps (which tend to grow out of proportion recently) and the "generic quaker" uses his favorite engine without caring what a readme says. "If a map or mod does not work then it sucks."
_________________
Quake Maps

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Mon Jun 23, 2008 7:26 pm Post subject: |

Spirit wrote:
"If a map or mod does not work then it sucks."

Unfortunately I've found that the converse of that is "if a map or mod does not work in (alternative engine x) then (alternative engine x) sucks."
Obviously you can't test everything in a mod (I wouldn't even bother testing the 3 I mentioned in Hipnotic, by the way...). I'm not even sure if it's reasonable to have any specific tests at all, as a mod you're testing may have only changed a small thing that doesn't fall under the umbrella of any set tests. So I'd say (1) use the mod's readme as a guide. This should indicate what has been changed, which should provide pointers for testing. (2) for mission packs you need to be sure that all weapons work, all monsters work, and all new multiplayer features work. (3) Any other special additions that don't fall under (1) and (2). (4) If there's a boss-level it might be worth running that - a boss level is an opportunity for the designer to go crazy with new stuff. And (5) keep in mind that you may hit an obscure engine or QC bug that only happens 1 time in 100, and that this may be that one time.
For which mods to test, obviously Hipnotic and Rogue are in there. Zerstorer might be an idea: it's an old school mod that works in regular GLQuake but yet pushes things well enough to be suitable. If a mod absolutely requires specific engine customisations I wouldn't bother, unless those customisations are relatively common (in which case you're probably flagging an engine feature rather than testing a mod...)
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Mon Jun 23, 2008 9:04 pm Post subject: |

Argh, yes. You are right. I think I will just leave out any compatibility stuff. Other tests such as the limits, the extensions etc should cover enough to get an idea. In special cases like Tenebrae the description or the specialfeatures field will simply contain a warning. That seems most reasonable and "efficient" to me. It could always been done later.
Many thanks for the brainstorming!
I just stumbled upon http://quakery.quakedev.com/qwiki/index.php/Enhanced_engine_features
Are any of those worth adding? ENT support maybe. The other things seem to be rather unique to specific engines, right?
And what about the extensions? I listed DP_ and TQ_ in the above draft as they were the ones that came to mind immediately. Yet according to http://quakery.quakedev.com/qwiki/index.php/QSG_extensions only the DP_ and FRIK_FILE seem to be worth mentioning.
_________________
Quake Maps

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Mon Jun 23, 2008 9:56 pm Post subject: |

ENT files can be useful for mod developers (especially if the engine can load them on the fly) so they definitely seem worth flagging, yes. Don't know about many of the rest... RScripts are kinda old hat these days aren't they? I've come to consider HUD models a compatibility breaking feature - all it takes is a single model with a weird size for things to screw up. Don't really know much about the rest.
Extensions are interesting... it seems counter-productive to list/test them all, so maybe just a single "supports extensions" flag with a pointer to the engine readme would do?

Spirit wrote:
In special cases like Tenebrae the description or the specialfeatures field will simply contain a warning.

_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Tue Jun 24, 2008 8:05 am Post subject: |

Ok, ENT is in. My idea about the extensions was to say "Support for DP_* extensions": many|some|none. I think I'll just start like that (maybe with DP_ and QSG_) and if it turns out that only the minority actually supports ANY extensions it will become "Supports extensions": yes|no.
I wish some more modders (hello!) would raise their voice and tell me what they need to know.
_________________
Quake Maps

Back to top |

metlslime Joined: 05 Feb 2008 Posts: 177 |

Posted: Tue Jun 24, 2008 9:29 am Post subject: spirit: |

this is a worthwhile project, glad you are doing it. first, i think it would be good to identify who the target audience is, because the question of what sorts of information should be presented ought to come from who you intend to serve with this.
second, here are some additional features/etc/comments:
- transparency -- maybe be more specific? is this entity alpha?
- things like "custom hud" and "enhanced menu" and other "enhanced" things -- if you reduce this to a simple yes/no, does that provide any useful info to anybody? custom hud seems the most relevant, but i think it would only work if it supported certain file formats and naming conventions or something. Like, can it load "McSpankyDood's Super Awesome HUD Replacement Images" or not? I don't know a lot about this sort of player customization, but i assume there are some standard directories you put the files in, and standard filenames the images have to have, or something.
- in general, if a feature is supported, but there is no standard about how that feature works, it might be good to include a few notes about how each specific engine handles it. For example, if the fog commands/cvars are different in different engine, list the cvars/commands instead of just saying "yes" to fog. Likewise for skybox loading, and gamedir switching, the command is different per engine.
- you asked what other limits are important? marksurfaces, faces, clipnodes, visleafs, static entites, lightmaps, are the ones i can think of right now. However, i wonder if it wouldn't be more useful to list all well-known maps that break at least one limit and check whether they load it or not. The partial list might be masque, warpspasm, sickbase, bod, laboratory x, and digs04 (these are all the recent released maps i recall which claimed to break standard engine limits)
(This gets back to the idea that the point of this project is to provide information to people, and if the people are quake players, the information they want is "does it play map X?" "does it load content X?" "does it run mod X?" "can i configure these settings that i care about?" I see above that people have talked about the downsides of taking that approach, but it seems like few users would be able to read "this engine supports 128 lightmaps" and do anything useful with that information. On the other hand, if the primary audience is mappers and modders, maybe that sort of info is useful.)
One other recommendation, it might be good to upload this project piece by piece, so people can start complaining early on and you can incorporate feedback as you continue working on it.
Oh, and here's another feature, just because i have it: anaglyph stereo rendering.

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group