Half-Life WAD3 and MAP support in DirectQ?

[OpenMaw]

Is Half-Life WAD3 and Map support possible in DirectQ? I was looking at one of the tutorials posted on here about adding it to basic GLQuake, but apparently it would be much harder to do with an engine that is not in line with GLQuake. It seems to be down to the way that Direct3D would handle the colors?

[leileilol]

It can do it, but whether MH wants to is a different matter. HL map support would mean supporting maps built with SDK tools that have strict usage rights tied to them (i.e. for use with Half-Life only) so it's not something that would be encouraged anymore...

[Spike]

both rendering apis boil down to 4 channels in the end. only difference is that d3d9 is explicitly bgr, while opengl will automatically translate from rgb to what the hardware prefers. its easy enough to just rewrite the various channel ordering.
the real problems will be from the fact that all the tutorial code that's already written for you is completely incompatible with directq's changes that do not relate to pure rendering api.

considering how MH has gone missing, you'd need to fork directq anyway, regardless of his ideals.

[OpenMaw]

It can do it, but whether MH wants to is a different matter. HL map support would mean supporting maps built with SDK tools that have strict usage rights tied to them (i.e. for use with Half-Life only) so it's not something that would be encouraged anymore...

As I understand it though, that would only apply to maps built with Valve Hammer Editor specifically, not with maps built under the Worldcraft banner. Right?


Would the compromise of using WAD3 files with the Quake map format work, actually? Cause all i'm really after with this is the 256 colors per individual texture. It's an arbitrary and stylistic thing, but i'd like to avoid using full/true color tgas/pngs, but keep things sorta neatly 90s.

both rendering apis boil down to 4 channels in the end. only difference is that d3d9 is explicitly bgr, while opengl will automatically translate from rgb to what the hardware prefers. its easy enough to just rewrite the various channel ordering.
the real problems will be from the fact that all the tutorial code that's already written for you is completely incompatible with directq's changes that do not relate to pure rendering api.

considering how MH has gone missing, you'd need to fork directq anyway, regardless of his ideals.

Ah... So, basically, i'd probably be better of sticking with an opengl based port to begin with? There are a couple other software/d3d related limitations I've bumped into already.

[Spike]

by 'sdk tools', he means the halflife qbsp etc programs that take your map and generate an optimised bsp. the ones that you can't make a halflife map without, regardless of the actual editor you use.

you could use wad3 files with a quake map... but what's the point? just use paletted tgas or something. or pcx if you're going for that vibe... many quake engines already support pcx. its just a stupid format that noone bothers to mention it, but hey, if you're going for 256 colours per individual texture then its right up your street!...
of course, you'll have redundancy as each bsp has a copy of every texture.

[OpenMaw]

by 'sdk tools', he means the halflife qbsp etc programs that take your map and generate an optimised bsp. the ones that you can't make a halflife map without, regardless of the actual editor you use.

I have never heard that before. That's both interesting, and unfortunate. I was under the impression the problem was with using "Hammer" specifically (which is why some people choose to use Worldcraft with the WCadapter for making maps.) I suppose this does make sense, though.

you could use wad3 files with a quake map... but what's the point? just use paletted tgas or something. or pcx if you're going for that vibe... many quake engines already support pcx. its just a stupid format that noone bothers to mention it, but hey, if you're going for 256 colours per individual texture then its right up your street!...
of course, you'll have redundancy as each bsp has a copy of every texture.

Some of it is a stylistic choice, some of it is an attempt to maintain good system requirements for low end users, and some of it is I just don't want a whole bunch of excess file clutter in my directories.

[Dr. Shadowborg]

Hmmm, you might also want to check out the possibility of using Q2BSP map format and FTE instead of that nasty ol' HLBSP.

[Spike]

excess file clutter? put the bsp AND the pcx files inside a pak/pk3, which is less file clutter than both a bsp and a wad would be.

[leileilol]

Some of it is a stylistic choice, some of it is an attempt to maintain good system requirements for low end users, and some of it is I just don't want a whole bunch of excess file clutter in my directories.

The only users you'll benefit by using paletted textures are 3dfx Voodoo owners - which are getting close to a handful amount these days - and THAT'S if the renderer supports the long deprecated paletted texture extensions. By going DirectQ anyway you'll shut the entire Voodoo line out for the minimum requirement being the Geforce6-7 (or was it 8800?) line.

When a 256-color PCX loads on common hardware it gets turned into a 24-bit texture and the only advantage I can think of is the loading process from disk... I've used 8-bit color PCXs for OA's levelshots for that reason, since PCX files are much smaller to decompress and load from a zip than a TGA and it doesn't require processing like a JPEG, and the RGB conversion is already taken care of by the loader...

[goldenboy]

Use dxt compression / .dds format for replacement textures. Saves a lot of video RAM. DirectQ should support that. Usually a good choice anyway.

[leileilol]

Good luck with those patents! DXTC also contradicts his direction......

[OpenMaw]

The more i'm thinking about it, the more i'm thinking I may just want to bite the bullet and deal with being limited to the 256 color palette for a number of reasons. It's a bit of a headache in some ways, but in others it may be best for what my end goal is.

Hmmm, you might also want to check out the possibility of using Q2BSP map format and FTE instead of that nasty ol' HLBSP.

I've fiddled with FTE, and though it has some good features, there's also a lot of stuff for this particular project i'd have to excise simply because I don't want the extra business in there.

Use dxt compression / .dds format for replacement textures. Saves a lot of video RAM. DirectQ should support that. Usually a good choice anyway.

In all fairness, not necessarily a bad idea, but in this case it's precisely what I want to avoid.

Some of it is a stylistic choice, some of it is an attempt to maintain good system requirements for low end users, and some of it is I just don't want a whole bunch of excess file clutter in my directories.

The only users you'll benefit by using paletted textures are 3dfx Voodoo owners - which are getting close to a handful amount these days - and THAT'S if the renderer supports the long deprecated paletted texture extensions. By going DirectQ anyway you'll shut the entire Voodoo line out for the minimum requirement being the Geforce6-7 (or was it 8800?) line.

When a 256-color PCX loads on common hardware it gets turned into a 24-bit texture and the only advantage I can think of is the loading process from disk... I've used 8-bit color PCXs for OA's levelshots for that reason, since PCX files are much smaller to decompress and load from a zip than a TGA and it doesn't require processing like a JPEG, and the RGB conversion is already taken care of by the loader...

Why are DirectQ's requirements that high up, exactly?


Just to put it in perspective for you guys, this is what my "dream" list of features is(There are other, QC side features which will be taken care of once the engine is where I need it to be.):

*Colored lighting/Global Lighting(IE: setting "sun" angle and so forth. I'm pretty sure this is just down the compiler, though, not an "engine" feature)
*Skyboxes (The only caveat here would be, maybe the ability to set their rotation and speed ala Quake II.)
Mirrors/Reflective surfaces (With the ability to toggle them on/off from the menu and console, but also the ability to set their strength from within the map itself. IE: having a purely transparent mirror, or having a reflective marble floor.)
Entity-based water (Some of this is more QC related, but, basically, brush entity akin to func_water from Half-Life, with the ability to set the transparency in the editor.)
*"alpha" support (Translucent textures)
Alpha TEXTURE support (Not sure on the precise term here, but essentially, if the last color of the palette is used on an brush entity or model, those parts will be rendered invisible/skipped.)
*MP3 playback for music instead of CD-Audio. (I'd rather replace the functionality entirely to avoid having anything but the intended music playing. DirectQ already has a bug where if you have anything mounted, or any discs in the drive, it will read them instead of the MP3 audio.)
Light flares (Unreal, Half-Life, DNF circa 1998. 2D sprites that scale and fade dynamically as the player moves about the world. This may be a QC thing, but i'm not sure if something engine side would have to be done to properly support it.)
Model and Sprite scaling. (The ability to scale models and sprites with a "scale" setting in their entity properties. Would be useful for creating high resolution sprites and shrinking them down for various wall decals and such that I want to do.)
Darkplaces style gun-model bobbing (Instead of the Quake style pogo effect, DP guns rock back and forth, which looks much better to me.)
*Functioning and stable multiplayer/netcode. (I'm not looking to be a pro Quake engine, but having stable and fast multiplayer code would be nice.)

*features that DirectQ has.

Things I do not want:
True-Color/High Resolution texture support.
Bump Mapping/Specular Highlights.
Dynamic Light/Shadows (This does not include standard Quake dynamic lighting/lightstyles.)
Bloom.
Motion Blur.

[leileilol]

Why are DirectQ's requirements that high up, exactly?

Because it uses pixel shaders for many of the effects such as water warp, water surface turbulence, and the sky. It's unique in that it does that.

Colored lighting/Global Lighting

Almost every port supports this.

Skyboxes

Almost every port supports this as well and it's probably easier to list exceptions. The spinning stuff i'm not sure is supported in Darkplaces

Mirrors/Reflective surfaces

Darkplaces allows this but you're probably better off doing simple cubemap reflections for the sake of performance.

Entity-based water

I know p0x's extras r4 did something like this.

if the last color of the palette is used on an brush entity or model, those parts will be rendered invisible/skipped

Chroma key alpha isn't really something many support outside of WAD3...

MP3 playback for music instead of CD-Audio.

MP3 is evile and covered by patents. As engines licensed under the GNU GPL v2 we have to stay far far far away from that format and use Ogg instead. Darkplaces can do this fine. Ogg's technically better anyway
DirectQ sidesteps the decoding process and just goes to the DirectMedia or MCI functions IIRC, and that's not exactly crossplatform...

Light flares

There's lots of engines that do this in a rudimentary fashion using flashblends and only Darkplaces and Engoo seem to do it right regarding the fade and occlusion (still not sure if FTEQW ever implemented it). It's definitely an engine thing, tied to tracelines and/or depth reads.

Darkplaces style gun-model bobbing

Unfortunately only Darkplaces and Engoo do this. Most don't touch the standard bobbing or just break it completely. Shame more bobbing options never caught on.

Functioning and stable multiplayer/netcode.

Darkplaces?

[frag.machine]

I second what leileilol said. Darkplaces has a lot of man/hours in feature additions and bug fixes.

[OpenMaw]

Why are DirectQ's requirements that high up, exactly?

Chroma key alpha isn't really something many support outside of WAD3...

Maybe I wasn't 100% clear, because at least in theory i'm pretty sure the engine already supports this with sprites and the menus. I know that's not the same thing exactly, but the implementation is technically already there. At least, according to this thread:

http://forums.inside3d.com/viewtopic.php?f=3&t=1042

I don't pretend to be experienced at coding, so i'll certainly take your word for it. I'm a bit if a moron and a novice right now, especially engine side coding. I'm just trying to ultimately pick the smartest place to start and go from there. The foundation is fundamentally important after all.



Don't get me wrong, I love Darkplaces, it's just coming with a lot of features that stylistically I not only don't need, but actively do not want within the engine. Makes me sound a bit of a fascist, but going for a particular look will require me to, essentially, hack a bunch off.