1.0.26
Moderator: Graf Zahl
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
1.0.26
Yes, there's another release!
This was mainly done to fix a crash while reading the GLDEFS file.
In addition there are a few new features:
- added round and smooth particles from Skulltag
- added model interpolation from Skulltag
- added support for Strife's fullbright colors. Be advised that this needs a shader and therefore at least a Geforce 5 or similar card to work. I plan to expand this feature to full brightness map support in the next version. Since this is a shader based feature it is disabled by default so you have to enable it in the menu first to see the difference.
This was mainly done to fix a crash while reading the GLDEFS file.
In addition there are a few new features:
- added round and smooth particles from Skulltag
- added model interpolation from Skulltag
- added support for Strife's fullbright colors. Be advised that this needs a shader and therefore at least a Geforce 5 or similar card to work. I plan to expand this feature to full brightness map support in the next version. Since this is a shader based feature it is disabled by default so you have to enable it in the menu first to see the difference.
- BlazingPhoenix
- Posts: 488
- Joined: Sun Aug 28, 2005 5:11
- Contact:
- Enjay
- Developer
- Posts: 4748
- Joined: Tue Aug 30, 2005 23:19
- Location: Scotland
- Contact:
Re: 1.0.26
Yay! Two things I've wanted for a while. Thanks Graf. Can't wait to get home and DL this.Graf Zahl wrote:- added round and smooth particles from Skulltag
- added support for Strife's fullbright colors.

[edit] and both of them look very nice. Any clues as to how the light-map shaders work? I've had a look at the lumps but I couldn't work out the format. [/edit]
- Torr Samaho
- Developer
- Posts: 160
- Joined: Fri Apr 13, 2007 8:26
- Location: Germany
- Contact:
Re: 1.0.26
I just had a quick look at the code and it looks like you ported almost all of my changes of the model code. Thanks!Graf Zahl wrote: - added model interpolation from Skulltag
I guess it won't hurt if I mention all the changes in more detail, so that people know of their existence and can use them:
- model frame interpolation, controlled by the the new CVAR gl_interpolate_model_frames
- model skin color translation support. The skin texture may only use colors from the game palette, otherwise it won't work properly.
- Models respect the actor render style now, e.g. a model of a player with an invisibility sphere is rendered translucent. To reduce the problems caused by missing depth sorting, back face culling is used. This doesn't work if the model is not a closed surface.
- z-offset support to MODELDEF
- Doomsday like rotation of the weapon pickup models, controlled by the the new CVAR gl_rotate_weapon_models
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: 1.0.26
Since I just wanted to get the version out as quickly as possible I just copied the stuff without making any changes to it so far. There's a few things I'd like to change though:
But first on my list is the implementation of customizable brightness maps so it may take a week or two.
This still needs an option in the menu.Torr Samaho wrote: - model frame interpolation, controlled by the the new CVAR gl_interpolate_model_frames
I really wish I could find a way to apply translations to wall textures and flats in the software renderer. Then this could be turned into a universal feature...- model skin color translation support. The skin texture may only use colors from the game palette, otherwise it won't work properly.
So where can I find a decent sorting algortihm for this?- Models respect the actor render style now, e.g. a model of a player with an invisibility sphere is rendered translucent. To reduce the problems caused by missing depth sorting, back face culling is used. This doesn't work if the model is not a closed surface.
This should be a MODELDEF option, not just applicable to weapons. I'll change this for the next version but keep the option in.- Doomsday like rotation of the weapon pickup models, controlled by the the new CVAR gl_rotate_weapon_models
But first on my list is the implementation of customizable brightness maps so it may take a week or two.
- Torr Samaho
- Developer
- Posts: 160
- Joined: Fri Apr 13, 2007 8:26
- Location: Germany
- Contact:
Re: 1.0.26
I think sorting the triangles according to their barycenter in a quadtree should do it, but this is just a basic idea, not a ready to implement algorithm. Does anybody know if Vavoom or Doomsday use depth sorting? Both support model transparency, so they should use it (or suffer from rendering artifacts).Graf Zahl wrote:So where can I find a decent sorting algortihm for this?- Models respect the actor render style now, e.g. a model of a player with an invisibility sphere is rendered translucent. To reduce the problems caused by missing depth sorting, back face culling is used. This doesn't work if the model is not a closed surface.
Yeah, right. I planned to add several optional flags to MODELDEF to toggle different things, like rotation, interpolation and "pitch from momentum", but didn't have time to do so yet.Graf Zahl wrote:This should be a MODELDEF option, not just applicable to weapons. I'll change this for the next version but keep the option in.- Doomsday like rotation of the weapon pickup models, controlled by the the new CVAR gl_rotate_weapon_models
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: 1.0.26
Enjay wrote: Any clues as to how the light-map shaders work? I've had a look at the lumps but I couldn't work out the format. [/edit]
A short explanation:
Code: Select all
varying float fogcoord;
uniform int fogenabled;
uniform sampler2D brightmap;
// Input to this function is the unprocessed texel that would be displayed at this position.
vec4 lightpixel(vec4 pixin)
{
vec4 lightcolor = gl_Color;
// This 'if' only calculates depth fog. This is normally done automatically when no shader is used but in a shader you have to do it yourself.
if (fogenabled != 0)
{
const float LOG2E = 1.442692; // = 1/log(2)
float factor = exp2 ( -gl_Fog.density * fogcoord * LOG2E);
lightcolor = vec4(mix(gl_Fog.color, lightcolor, factor).rgb, lightcolor.a);
}
//Gets the color from the brightness map which is a second texture.
// After that it is multiplied with the inverse of the current light color
// and then added to it. If the brightmap is pure white this will result
// in white light, otherwise something in between.
vec4 bright = texture2D(brightmap, gl_TexCoord[0].st) * (vec4(1.0,1.0,1.0,1.0) - lightcolor);
bright.a = 0.0;
lightcolor += bright;
// and finally multiply the input texel with the newly generated light color.
return pixin * lightcolor;
}
- Nash
- Developer
- Posts: 1226
- Joined: Sun Sep 25, 2005 1:49
- Location: Kuala Lumpur, Malaysia
- Contact:
- Torr Samaho
- Developer
- Posts: 160
- Joined: Fri Apr 13, 2007 8:26
- Location: Germany
- Contact:
- Nash
- Developer
- Posts: 1226
- Joined: Sun Sep 25, 2005 1:49
- Location: Kuala Lumpur, Malaysia
- Contact:
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
-
- Posts: 34
- Joined: Sun May 13, 2007 13:34