Engine standards for mod compatibility

[Spirit]

Fog is a very touchy subject actually.

Ignore the gamma, bugs and other oddities but look how different the fog is rendered. With differences like that a "this engine supports fog" standard is worthless. It needs to be remotely the same to be of use.

http://www.quaketastic.com/upload/files ... rreneh.jpg
http://www.quaketastic.com/upload/files ... ots/dp.jpg
http://www.quaketastic.com/upload/files ... s/fitz.jpg

[Baker]

Here is my crappy attempt to try to segment different voices and wants in this thread:

"Bigger, better world" support - where world is the map and models and base effects

Wants rotating doors (origin brushes/avelocity) and better rotation, more liberal texture palette (HLBSP like), colored lits, sky box, volumetric fog, fog, EF_ADDITIVE / colormod / EF_FULLBRIGHT / Alpha support even in software and Fitzquake 0.85 style larger limits.

What about monster_clip? More special textures like "skip" being native and those other ones mentioned?

Better and more varied model and sound presentation

Vwep, md2/md3 plus attachment, movetype_follow, modeltoclient/viewmodeltoclient

OGG, Midi, etc.

Better game logic support?

(none?)

Misc

Frik_File, better and easier menu definition, MH-like camera fix

More flexible 2D GFX and temp entities

CSQC, Maybe "proper" vwep falls in here

Reasonable engine user-friendliness

Those things that have become "expected" like video mode switching and vsync off/on and I'd say really a texture manager falls in here to do it right (so you can switch 16 bpp to 32 bpp and back). What about command history ... I mean seriously!

The real question I have is what does someone have to do in 2010 to have a smokey fire or a steam vent (Nehahra?) in a "good" engine like DarkPlaces or FTE? Shouldn't someone write a QuakeC tutorial to have a non-boring world?

Plus I'd really like a QuakeC tutorial of a monster that doesn't entirely and FOREVER abandon guarding the gold key (FAIL!) because I poked my head around a corner. We need better AI? Engine problem? Maybe not. But is there anything in the engine holding back "good" AI?

[Urre]

Spike said it. I've personally ignored all feature requests which have been offtopic, since I figured people would get it eventually, but it seems they just keep coming.

Anything which is a matter of personal taste (maybe I want a console which doesn't tab-complete for me cause I'm a sadist, or I don't care if the chase-cam feature in this or that engine is crap cause I don't use it) isn't part of a mod/map compatibility standard.

The thread is about a standardized set of enhanced modding/mapping features for Quake engines, be it Quakeworld, Netquake, software or Direct3D. Even though a discussion about the difficulty involved in creating MDL format files is a very interesting one, it's not part of the scope in this thread.

Aren't things like detail-brushes and hint-brushes compiler specific? Monster_clip and Player_clip could be engine-side, and is certainly interesting, but might not be very high-priority.

Features themselves are also not to blame when it comes to making tasteless mods, like mixing overly high-def textures/models with the rest of Quakes low-def ones. If I as a modder use md2 models with external textures, I'm the one responsible of making sure they fit in the game or world they exist in. It's not the features fault my taste sucks.

Also, please stop talking about purity, that is completely counterproductive for the purpose of this thread.

Fog is a very touchy subject actually.

I suspected it would be before I even started the thread, as it has been a touchy one in the past. I recall caring a lot about it when I still made maps. I'd like to hear more opinions on this. Fog could be made the same way alpha was discussed, that it's "close enough". Is "close enough" fog good enough for people?

Someone should invite people from func_ to post in here, or just voice their opinions.

It should not dictate the network protocol other than that a given extended protocol must be supported for demo compatibility only. A non-networked (flash?) engine needn't have a network protocol at all.
It would be nice if all engines could network together. In fact, any standard should specify builtins and fields, not SVCs and TEs.

I was pondering this as well, should supporting a specific protocol for multiplayer be part of the standard? What if you make a multiplayer mod, shouldn't you be able to expect people being able to play it together without specifying a specific engine? This also collides with the NQ/QW discussion a bit, sure, but if people are able to make that distinction, shouldn't any NQ engine supporting this standard be able to multiplay with any other NQ engine supporting the standard, and vice versa for QW?

With regards to mapping, Don't forget QW clients in the example mod/map. They've a slightly greater following, in europe, anyway, and you don't really want two standards.

Care to specify a bit, I certainly don't want to forget the QW clients. How would QW clients differ if they supported the standard?

[Baker]

(Urre/Spike ignore this and continue ... not wanting to distract from main theme of thread)

For Goldenboy and anyone else who does have an interest in software renderers (I do) ...

r_wateralpha and Makaqu ... software rendering and alpha ...

[Urre]

Baker: talking about alpha in software engines is staying on topic

[Urre]

Having IRC'd with Supa a bit, I want to try and squash some possible misinterpretations.

There will always be mods wanting to do things outside the standard, being unable to live without feature X and so forth. That really is up to them, and is their problem. The goal isn't to make all engines be as feature-filled as say FTEQW. The goal is to up the bar of basic modding and mapping. I want to kill GLQuake dead! Modding and mapping needs to get out of the dark ages!

Instead of lots of modders thinking "oh no, can't do that cause then my mod won't work on Dreamcast-Quake", they should now be able to, because Dreamcast-Quake will want to support this awesome new standard which all the awesome mods use.

Imagine Solitude using a generic PSP Quake engine instead of their own special one, because a generic one doesn't support all the features they need.

Checkextension alone doesn't cut it. We've seen how engine devs just pick the extensions they like and implement them, but ignore the ones they don't like. The idea is that everyone would need to agree on a minimum set of features.

Something which I think many realise, but it hasn't been said yet, is that there needs to be a big ol' rallying of convincing people to realise the importance of this. Especially the ones who don't care a lot, like say QW engine devs, 'cause their userbase "only plays MegaTF anyway". You'll need to convince the people who are capable of convincing the other people. Imagine if the MegaTF players became aware of this huge world of cool mods that their favorite engine is compatible with, just because they see something about QSB compatibility in the next engine release changelog.

[Dr. Shadowborg]

If what I'm about to say doesn't apply, then just ignore it, but...

It would be cool if we could have an engine feature that allowed at the very least limited generation of genuine new keys / buttons that could be configured within the config menu. i.e. for things like altfires, Rune controls, etc. (This isn't really too high priority though as this can be done from QuakeC and the console, but would definitely be a nice feature to have from a "easy for end user to use" standpoint.)

[Urre]

Supporting extra buttons is fine as a request, but listing them in the menu can be tricky, and not really part of this. That'd be a menuqc job if done right.

[Supa]

Just to throw my two cents in - PLEASE don't ignore the extension system that we already have.

I know most people ignore it in favor of dropping everything for NQ compatibility, but that's just because a mod~game can depend on multiple extensions just for base level functionality. What can you do when you *need* DP_SV_FOO, DP_QC_BAR *and* DP_EF_BAZ, but the engine only supports DP_EF_BAZ? I really think that if we do this, each standard needs to be a pure advertistment extension itself. So we'd know that every engine with STANDARD_QSB_2010 will support a guaranteed set of extensions, we wouldn't have to put up with the current patchwork support problem that we have now. That patchwork support problem (see above) is currently a *huge* incentive to target either just DP or base NQ, and it *needs* to go away. I understand that if a game hinges on a certain extension outside of the standard it's their problem, but right now I'd just be estatic if we could climb out of the pit of despair that is NQ.

Basically, I just want to see more support for the QSG extensions system[1] in general. It irritates me that only DP and FTE make an effort to support it and other engines focus on generic things that have already been ran into the ground, like alpha support or another skybox standard. We should build on what we already have and play to the strengths of the QSG system - we should build some kind of reference library, like a DP codebase that isn't insane at times. :P

One more thing - right now, I have a project that I cannot help but target at DP because it relies on a DP quirk/behavior, specifically the capability to allow stuck/merged entities to move outside of the others' bbox. Words fail me when I try to describe how wrongheaded this is. I need this behavior for my game, I want people who don't/can't use DP to be able to play it, I want other engines to be able to support this behavior, but without an reference for how it's supposed to be implemented and checked for it'll become worse than useless - it's too likely it would be advertised but not correctly supported, or supported and not advertised. Just *how* is the SSVM supposed to tell the difference between engine quirks?

To get to my point, I want to see more pure advertisment extensions - an extension that advertises every DP sv_gameplayfix* cvar, one for DP's collision behavior, extensions for anything that one would remark about when examining a specific engine. If an engine supports x skybox format, it needs an extension. I don't care if it means we'll end up with triplicate extensions that amount to the same thing, all I care is that the gamecode can find out on its' own what the engine supports. We all know users won't check the docs first, the gamecode *needs* to be able to know as much about the engine as it can.

*1 Yes, I'm aware of the QSG vs DP extension system history, I just think 'QSG extension system' is a more neutral name to present to potential implentators. :)

[LordHavoc]

that would be awesome to get an updated q1bsp version which was as good if not better than the hlbsp version. but is it possible? also if this was achieved would i still be able to map using worldcraft?

My hmap2 utility compiles q1 .map, hl .map (from worldcraft), q2 .map, q3 .map, and doom3 .map files to q1bsp, with .lit (colored lighting) and .dlit (a form of compiled per-pixel-lighting), if a few more files were added, many of the restrictions of q1bsp would be lifted, in a backward compatible way (at least as much as is possible).

But this gets off the topic, this thread is about standardizing existing features more than anything else.

[LordHavoc]

What about file formats?

I'd say TGA and PCX for textures; they're widely supported by image editing programs and would definitely allow for the fastest development pipeline.

I'd say to leave the option open, as not everyone can handle PCXs and TGA could be replaced by PNG, or JPG if there's no alpha involved. TGA could get too big a filesize.

Ahem, PCX is useless, it's paletted only and not the best compression, it also only supports color-keyed transparency (and most implementations do not even support that).

TGA supports paletted images just like PCX does, but with better compression.

I say the standard external image format should be TGA - however an improved loader is required (the glquake one does not support a variety of TGA features), and I recommend the one in darkplaces which is one of the most correct TGA implementations available, more correct than photoshop and gimp unfortunately.

PNG is slow.

JPG is slow and saves download size, but can not represent alpha, therefore it is not a general format.

DDS is a general format but usually contains S3TC compressed formats which are patented and thus problematic.

By process of elimination, TGA is the best format, and when zipped in a .pk3 archive it matches the size of PNG (but loads faster).

[MDave]

What about file formats?

I'd say TGA and PCX for textures; they're widely supported by image editing programs and would definitely allow for the fastest development pipeline.

I'd say to leave the option open, as not everyone can handle PCXs and TGA could be replaced by PNG, or JPG if there's no alpha involved. TGA could get too big a filesize.

Ahem, PCX is useless, it's paletted only and not the best compression, it also only supports color-keyed transparency (and most implementations do not even support that).

TGA supports paletted images just like PCX does, but with better compression.

I say the standard external image format should be TGA - however an improved loader is required (the glquake one does not support a variety of TGA features), and I recommend the one in darkplaces which is one of the most correct TGA implementations available, more correct than photoshop and gimp unfortunately.

PNG is slow.

JPG is slow and saves download size, but can not represent alpha, therefore it is not a general format.

DDS is a general format but usually contains S3TC compressed formats which are patented and thus problematic.

By process of elimination, TGA is the best format, and when zipped in a .pk3 archive it matches the size of PNG (but loads faster).

But there is a problem with TGA when it comes to running Quake based engines on less powerful devices that have limited RAM, they are quite RAM heavy. Which is where paletted textures are extremely important.

[LordHavoc]

But there is a problem with TGA when it comes to running Quake based engines on less powerful devices that have limited RAM, they are quite RAM heavy. Which is where paletted textures are extremely important.

TGA supports palettes as I said, if the engine wants to implement paletted textures in TGA and PCX form using a special code path that keeps it in paletted form, then great, otherwise the argument for PCX is moot.

I highly doubt you will see any modders/mappers trying to restrict themselves to PCX textures for better support of an embedded system like PSP.

To cite one platform in particular, iPhone/iPod drivers don't even support paletted textures - only 32bit (which paletted textures get converted to) and PVRTC (which is patented and we can't really touch that).

So you are asserting that support for a file format is critical based on these two assumptions:
1. that modders/mappers will restrict themselves to this file format.
2. that the platform in question supports this file format in a meaningful way.

Both can be true, but usually are not, and it does not seem like an issue of broad concern.

[MDave]

Ah doh, I completely forgot you said TGA can also do palette textures! Yeah TGA seems to be the best in this scenario then, because it's versatile and fast. Ignore my ignorance.

[Downsider]

The PSP supports compressed and paletted textures, but when you render in one of the compressed formats, you can't swizzle the texture, and thus slowdown occurs