I've been hacking some on the Doom 3 BFG code, and was interested to note that it uses the same method as mine for widescreen FOV: first calculate fov_y based on an ideal aspect (16:9 for D3, 4:3 for mine, although I adjust height for sb_lines too), then calculate fov_x based on the true aspect. 

It opens an interesting question so far as the topic of "fixing up Quake" is concerned

For myself, as far as sound attenuation is concerned, as long as there is a cvar to revert it to default values, then engines can default to whatever they want. Like I said, DP has that option and now I know your engines do so it's a simple matter of including them in config files that run before a mod is loaded.
It's more problematic if you aren't making a mod, but at least the option is there to fix it.

In fact, providing a cvar offers interesting new possibilities for messing with sounds such as fading them out gradually for dramatic effect. 

I'll just use the original sound distance if the single player scoreboard is showing (single player + coop) and if the deathmatch scoreboard is showing I'll use the other value.

Not looking at the source, I'm not 100% sure if the value is client (likely) or server (doesn't seem likely, but I'm not looking @ the source).

I don't like cvars and settings (except for features that help developers tune stuff). 

There's a bug in my map that has a unique component only in Fitzquake. The first room has a pretty large bsp model for some pesky vertex saving. It seems that only RMQ actually allows collision with the model (DP/DirectQ/Fitz don't collide with it at all so I guess this bit is definitely my fault).

However in fitzquake if you move to the far side of the room away from the model it disappears, which no other engine does:

Model rendering properly

Taking a step backward 

fyi the model entity is positioned just to the left of the healthpacks near the middle of the screen, so is definitely inside the room. 

1. ALL engines should handle external bsp collision. Unless you rotated it.

2. You can't fix this unless you can find a way to change the size of the entity's bbox to be smaller. :( 

bleh. '2' is referring to the disappearing bmodel.
This is due to the bmodel's bbox being linked to too many visiblility 'areas'. the problem is that the engine has a limited number of links to visible areas and when that list fills up, it just starts removing other links and replacing them. 

Ah, hopefully won't be a problem with a full vis then? :/ 

I noticed that dropout in the beta but didn't think anything of it specifically because lots of the bmodels in my map did that and yes it got better after fullvis. 

In my experience, it tends to get worse with a full vis, but you won't know for sure until it's done. 

As well as the problem with it's size (which would affect any brush model type) try this:

gl_flashblend 0
Fire a rocket at it.

Ugly, isn't it? 

Does Mark V support luma on skin textures? 

Model replacement textures use the DarkPlaces external texture naming convention (so replacement textures for models go in the progs folder).

You can call them _glow or _luma (_glow is what Quake 3 uses.) 

After trial and error I got _luma to work. The thing is the _luma texture need to be sized to the original model skin NOT the replacement texture. So dropping in a replacement skin pack doesn't work out. 

I can't remember all the details, but it was really hard to add external texture support for .mdl for FitzQuake while sticking by the strengths of FitzQuake.

I can't remember what texture set I used to test the feature, but I wanted to keep with FitzQuake way of doing things which in this particular case involved some contortions.

FitzQuake, unlike other engines, doesn't stretch skins to accommodate OpenGL baseline compatibility and instead pads it. This made adding external texture support for .mdl difficult while still retaining the feature (which is good and avoid stretching). As far as I know, the replacement texture and the luma/glow texture being the same size should always work, but you seem to be saying it doesn't.

I'm not sure when I'll be back to doing a revision #8 of the engine, but clearly this will be checked out , rectified and documented in the readme. 

Checking for and using GL_ARB_texture_non_power_of_two as an optional path instead of using skin padding.

Also - and this is available in GL1.1 as well so it may appeal to you more - instead of recalculating the skin texcoords based on the padded size, just scale the texture matrix instead. You can keep the original skin texcoords and have different sized skins this way. 

Extension would be extremely useful in FitzQuake, ultimately. Because the padding stuff --- and that code was ingenious --- but it really increases the overhead.

Something fun about non_power_of_two --> the texture you download is the one you uploaded ;-) so in theory, one might even be able to super-optimize the Fitz texture manager to not even need to store raw pixels source location (* I am aware of the exceptions here and there).

re: Texture matrix scaling, may I trouble you for a really simple example (which I would normally do at I3D except it is rather broken)?

I've never done anything with the texture matrix, but a simple example and I'm sure I could take it from there with ease ... 

Something like this should work:

void GL_PadAliasSkin (aliashdr_t *hdr, gltexture_t *tex)
{
glMatrixMode (GL_TEXTURE);
glLoadIdentity ();
glScalef ((float) hdr->skinwidth / (float) tex->width, (float) hdr->skinheight / (float) tex->height, 1.0f);
glMatrixMode (GL_MODELVIEW);
}


void GL_UnpadAliasSkin (void)
{
glMatrixMode (GL_TEXTURE);
glLoadIdentity ();
glMatrixMode (GL_MODELVIEW);
} 

MH adds Baker XP +1 for the Nth time, where N is getting to be a sizable number ... 

You can also translate and rotate, or even do wacky crap like load perspective onto it. Very handy stuff, and a far more elegant solution to many problems than trying to brute-force it in C code. 

Would it be possible to have a map key to set light level on static entities? 

I remember asking when working on statics in my last map
and I thought it was not possible.
So the only way out was resetting the gammalevel of their skinfiles. 

It should be possible but would need a protocol change as statics are sent from the server to the client during connection time. You'd also need to define how it works with coloured light and whether or not they should be affected by dynamic lights too. 

I'm trying to use the -basedir command-line option and something is off. (This is on Windows 7.)

If the path doesn't have any spaces in it, all is fine. Let's say the folder containing id1 is named "foobar" at the root of the C drive:

fitzquake_mark_5.exe -basedir C:\foobar

That works. But if the folder name is "foo bar" I'm out of luck. This doesn't work:

fitzquake_mark_5.exe -basedir "C:\foo bar"

Using the "shortname" (barf) of the path-with-spaces does work:

fitzquake_mark_5.exe -basedir C:\FOOBAR~1


This isn't an emergency at all and I'm likely just making some stupid mistake, but FYI. (I ran across this while trying to write up some info on how to use different Quake engines.)

FWIW, QuakeSpasm does handle the path with spaces OK. 

@Baker, Is there any plans for another update soon?