good news!
thanks, Baker. 

Would it be possible to do alpha animated textures?

Something like this:
{+fire1
{+fire2
{+fire3 

I'll let Baker answer on his own behalf; this opnion is mine and mine alone.

Yes, it should be possible with the necessary code changes. However, by this point in time you're stacking up multiple "first character" hacks (alpha animated water with alternate anims anyone?) and things will begin to look a little delicate.

So some form of alternate system would be needed. Since Q3A shaders are out there, since we have a GPL working reference implementation (the Q3A engine), and since they don't require any format changes (just add a .shader file for anything you want different behaviour for), that would be my own preference. 

It might already be possible to do them:

Set r_texprefix_fence "+alpha" and load your level.

It should process all the textures that begin "+alpha" and likewise set a flag to mark that surface for alpha mask rendering.

I hadn't expected someone to want to use alpha textures like that, but I bet it works.

(Note: fullbright pixels in alpha textures are supported (except color 255 of course). Replacement textures replacing an alpha texture that has an alpha mask are also supported.) 

Baker this makes fitzquake look more like darkplaces, joequake, qrack e.t.c?

record demo is awesome... 

 

If by chance you are looking for something like JoeQuake, you might try Engine X. Engine X supports FitzQuake 666 protocol and looks like JoeQuake with the kind of very recent engine features one would expect (video mode change, etc). 

Obrigado Baker

I will see it ASAP!

thanks 

Thanks for the reply!

Also, regarding the alpha textures, I think there is a bug with the way they are rendered, or it may be intended. The transparency textures bleed through the floor and you can see the void of the map.

Here is a picture showing what I mean:
http://imgur.com/ZFOz1

Even if I paint the bottom of the glass brush with a solid texture, it still shows the void through the floor. 

Turn your alpha brushes into an entity like illusionary, door, func wall etc. Use a really good q3 fence texture, enable texture scroll and be amazed. 

Yup.

Because of the way QBSP seals the world and chops off outside faces, putting this texture type on a brush that's not part of an entity will produce this result. It's expected behaviour and a result of normal QBSP operation, not really an engine bug (there's actually nothing that the engine can do to work around it as the data required isn't even there in the BSP to begin with). 

See above. I almost decided to enable alpha textures only for entities (func_wall, etc.).

But an experienced mapper knows all the rules and how the tools work and allowing it for the world is no different than, for instance, using the skip-remove tool.

Alpha textures should generally be limited to entities (func_wall, platforms, doors, etc). 

I have been testing my map with the mark V engine and for some reason all my models (map objects, items, weapons and monsters) randomly go black and monsters do it while patrolling.

I have checked the area the monsters patrol and my weapon does not go black. It is not a subtle change either, they are normal (full bright) one minute and then solid black the next.

Is there a special reason for this? (I know this is a counter productive thing to say but it does not happen in Fitz85) Is there a command line parameter I need to stop this? 

do they stay black with r_fullbright 1?

If yes, may be a texture problem.... if no, may be a lighting problem. (not a problem with your level, i mean a problem with the engine) 

I loaded the map, typed in r_fullbright 1 and I could see everything, no blackness. It looks like r_fullbright removes the light map from everything. It is very strange the blackness on certain objects, I thought it was specific locations where I have spawned stuff but it happens to wandering monsters.

I checked the original Q1 maps (played episode 1) and could not see any problems. I am using the latest compiler tools, hitting a couple of max limits but the engine still copes with it. 

It could be because I made the light check test against world submodels (plats, lifts).

I have a new revision to this with new features essentially done. I'll put a cvar in disable shadows/lighting from world submodels to see if that is the origin of the issue.

I also changed the lighting depth check (because MH did) from 8192(Fitz 0.85) to 2048 (original Quake) because MH had a comment about performance (8192 is a long, long distance).

The new version should be be available in 6-7 hours. 

The code that obtains shadow surfaces in Quake is actually very imperfect and can fail to "hit" a downtrace for lighting. Prior to the trace, I may have it reset the result color to black (full darkness).

Either way this shouldn't be hard to solve. 

Awesome, thanks :D I will download it and test my map once you got a new link ready.

Another bug:
When I start the engine (windowed mode) the +mlook does not work (even if I have the window selected) The old Fitz engine when it started windowed would never give up the mlook but at least I could test my maps without have to go full screen all the time. (I usually have to exit Fitz to use another application because the mouse cursor is not available to any other windows apps).

Is this a windows issue? a problem with active window focus? Or is the application (mark V) not able to control the mouse look when windowed? 

I also changed the lighting depth check (because MH did) from 8192(Fitz 0.85) to 2048 (original Quake) because MH had a comment about performance (8192 is a long, long distance).

Note: the reason i extended this distance is because CZG had a really deep pit in one of his maps, and the scrags floating over that pit were black instead of taking the lighting from the floor. 

the light depth check could be tweaked via a command line parameter? Something to set before the engine fully loads? 

How much the increased depth check costs to make. Is it really worth reducing back to stock quake for a little extra performance? 

The lighting depth check should be cvar-ized. Having to restart the engine to change something like this is stupid.

2048 is probably a little too low, especially with the "run the test for static entities once only at startup" trick (which was where the main performance impact came from in tests - and mind you this was quite an extreme case too). It also fails to light models properly in Zerstorer when this low.

It's probably worth finding the max top-to-bottom extent of the world and using that value as well - that'll be guaranteed to catch anything. 

end[2] = start[2] - (cl.worldmodel->maxs[2] - cl.worldmodel->mins[2]);

Why make the player do it when you can do you yourself? 

@Necros: The lighting check is one of those super slow recursive world checks. I'll do as MH suggests and default it to the Fitz 0.85 --- I wasn't looking to make an changes in how Fitz 0.85 operates (I lacked the imagination of a situation where 8192 could actually be needed, like the CZG map metslime said that induced him to raise the distance check).

[I'll add in MH's idea of a world bounding box check .. and if set to 0 will check lighting from unlimited depth. These things are going to push the update version to tomorrow it seems. But getting things absolutely right is something worth taking the time to do.]

@Sock: Any chance you could zip your map plus save the game exactly at the point the view model (weapon) lighting is wrong? It would help me avoid investigating things that aren't actually the source of the problem. 

if you use the max level extents of the world, does that still save any performance? I assumed the cost of a traceline is related to the number of nodes it has to cross, and once the line is >= level extents, it's already the worst case, right?