Tutorial: Killing z-fighting in a stock Quake engine
Re: Tutorial: Killing z-fighting in a stock Quake engine
Why are you hardcoding the thing in the engine while you have the ability of loading an external ent file?
Re: Tutorial: Killing z-fighting in a stock Quake engine
I don't wish to have weird installation instructions because users don't like it.szo wrote:Why are you hardcoding the thing in the engine while you have the ability of loading an external ent file?
FitzQuake patches the shotgunshell skin in the engine instead of using an external texture (so do about 20 different engines, DarkPlaces being a notable exception ).
I don't see a difference between correcting that annoying area in E1M1 via hack if the shotgunbox skin is also being corrected via a hack.
Besides, if someone is using, say, a CTF external .ent file for E1M1 wouldn't it be nice if that if that got automatically fixed up.
I cannot imagine any sane scenario where someone would want the issue. And gl_zfix and polygon offset in other engines show secret door outlines on some video cards --- sometimes really obviously with a very noticeable black line around them.
Shotgun shell fix in FitzQuake + every modern engine I know of except DarkPlaces:
Code: Select all
// HACK HACK HACK -- taken from tomazquake
if (strstr(glt->name, "shot1sid") &&
glt->width==32 && glt->height==32 &&
CRC_Block(data, 1024) == 65393)
{
// This texture in b_shell1.bsp has some of the first 32 pixels painted white.
// They are invisible in software, but look really ugly in GL. So we just copy
// 32 pixels from the bottom to make it look nice.
memcpy (data, data + 32*31, 32);
}
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Tutorial: Killing z-fighting in a stock Quake engine
You see, personally this kind of hack always bothered me. Why ? Because wiring the engine to handle content errors turn the modder life harder.Baker wrote:I don't wish to have weird installation instructions because users don't like it.szo wrote:Why are you hardcoding the thing in the engine while you have the ability of loading an external ent file?
FitzQuake patches the shotgunshell skin in the engine instead of using an external texture (so do about 20 different engines, DarkPlaces being a notable exception ).
I think it all boils down to the engine intended target audience. Fitzquake is the mapper choice; ProQuake is the preferred engine of semipro-serious online gamers, whom don't want to waste time downloading patches to fix content; FTE and Darkplaces are the main targets of modders whom don't want to be constrained by legacy mistakes in the original Quake content; it's already bad enough having to deal with content format limits itself. Nowadays I put myself in the last group, and I value a "clean sheet" engine approach.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Tutorial: Killing z-fighting in a stock Quake engine
Which is why Makaqu includes a PAK file with lots of content fixes plus some improvements. I don't want to make its code a whole mess by adding content hacks.
How about a patch file format for Quake? Essentially, get the map_patches_t map_patches[] struct from Baker's code and load its contents from a file instead of hardcoding.
Such a format could even be expanded to support textures, UV mapping, 3D meshes and everything else. This would allow for modified content to also receive the fixes, and would allow users to create new content fixes without recompiling the engine.
I see no need for installation instructions if such a patch file is to be loaded from the executable dir. Many engines are bundled with DLL files, and the users doesn't complain about that.
How about a patch file format for Quake? Essentially, get the map_patches_t map_patches[] struct from Baker's code and load its contents from a file instead of hardcoding.
Such a format could even be expanded to support textures, UV mapping, 3D meshes and everything else. This would allow for modified content to also receive the fixes, and would allow users to create new content fixes without recompiling the engine.
I see no need for installation instructions if such a patch file is to be loaded from the executable dir. Many engines are bundled with DLL files, and the users doesn't complain about that.
Re: Tutorial: Killing z-fighting in a stock Quake engine
I think people that use DarkPlaces and FTE tend to familiarize themselves with those engines and take an active interest in learning about them.frag.machine wrote:Fitzquake is the mapper choice; ProQuake is the preferred engine of semipro-serious online gamers, whom don't want to waste time downloading patches to fix content; FTE and Darkplaces are the main targets of modders whom don't want to be constrained by legacy mistakes in the original Quake content; it's already bad enough having to deal with content format limits itself. Nowadays I put myself in the last group, and I value a "clean sheet" engine approach.
So they know more and have a modder lean. And more experience.
Someone using a classic engine like FitzQuake or ProQuake, they just double-click and load a map (FitzQuake) or connect to a server (ProQuake).
And those users don't want to learn about the engine, they just view it as a "fixed-up" drop-and-replace GLQuake. Nothing wrong with that.
1. The ones using FitzQuake or ProQuake really are starting it up to play Quake.
2. Versus, say, a fair number of DarkPlaces users who are customizing the appearance and essentially creating art --- or viewing someone else's creations.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..