GZDoom v0.9.27 released!

[justin024]

Impossible. The hardware can't render it faster and quite a lot of the time is spent in the movement logic of the engine.

It seemed like zdoom64 ran faster in hardware mode...
It was probably because I didn't load decorate, animdefs, and sndinfo

[Graf Zahl]

Generally the hardware renderer is faster. But the comets are an important exception and the reason is simple:

There are more than 1600 translucent sprites. Translucent objects have to be rendered back to front so that they display properly. That means that I can't optimize the order of rendering so that expensive operations like texture binds etc. are minimized. I end up with changing the texture for each single sprite of the comets and that kills the performance completely.

[justin024]

Generally the hardware renderer is faster. But the comets are an important exception and the reason is simple:

There are more than 1600 translucent sprites.

That is what I thought, but then I saw that post and was confused. What if the sprites were not translucent? That would surely free up some resources. The way I see it, if something is solid enough to burn up in the atomsphere, it would be mostly opaque anyway.

[Tormentor667]

Is the problem the translucency or the additive translucency?

[Graf Zahl]

Translucency is the deciding factor. The mode itself doesn't really matter. But the comets themselves are a big resource hog anyway, even when they aren't drawn. There are >1600 moving objects in the map and the movement logic has to be called each and every frame for them. That alone accounts for 5 ms per tic (on a P4 3.2 GHz) and considering the frame rate it makes 10-15 ms for each screen refresh which is 20-30% of the rendering time without the comets.

No matter how this can be improved you should add an option to switch them off. On low end machines they will most definitely bring down the game to a crawl.

Another thing that costs a lot is one warped texture that's 256x256 pixels. Warping that texture takes 8 ms per tic. I wonder if you can reduce it to 128x128 which reduces the processing time to 1/8th of that.

[justin024]

Adding an option to toggle between low/high end machines would be a good idea. I will probably apply it to zd64 so the user can toggle off the 512x512 warping textures

[Graf Zahl]

Ugh. Do you have any idea how long it takes to warp such a monster?
On my system (P4, 3.2 GHz) a 256x256 takes 8.5 ms to warp alone and that doesn't even count the upload into texture memory. For software rendering it won't be much faster so if you want to burn half the available frame rate for nothing it won't be fun to play at all.
The largest texture you can safely warp on a high end machine is 128x128 - no matter whether software or hardware. Anything bigger will give noticable frame rate drops. Large amounts of smaller textures add up of course.

[justin024]

It looks really sweet though, much better than if it were animated. I have added a script/keybinding to toggle them anyway. I can actually tell a difference without the 512sq warping textures.

[timmie]

One of the things that I was going to do with zdoomgl was add support for using pixel shaders to warp textures rather than reuploading a new texture each frame. But I never really found the time. There's a few tutorials around on how to achieve the effect.

[Graf Zahl]

I want to do the same. The only thing I haven't figured out yet is the formula for the warping, especially the 2 different types the unofficial build offers. I want to have it stay as true as possible to the original effect. But with a pixel (fragment) shader it should look much better. Although considering my past experiences with fragment shaders I somehow doubt there will any significant improvement in speed. Every time I used something more complex than a simple texel assignment the performance broke down measurably.

Even something simple like applying the invulnerability colormap

Code: Select all

struct pixel_in {
	float4 color : COLOR;
	float3 texcoord : TEXCOORD0;
};

struct pixel_out {
	float4 color : COLOR;
};

pixel_out
main(pixel_in IN, uniform sampler2D texture : TEXUNIT0)
{
	pixel_out OUT;
	float4 color = tex2D(texture, IN.texcoord);
	float gray = 1.0 - (color.r * 0.3 + color.g * 0.56 + color.b * 0.14);
	OUT.color = float4(gray, gray, gray, IN.color.a * color.a);
	return OUT;
}
 

was noticably slower than creating a texture duplicate and re-uploading every single texture.

[Graf Zahl]

UPDATE:

v 0.9.7 has just been released. No new feature but lots of bugfixes.

Have fun!

[DoomRater]

Stability = HEART.

[Costja]

Graf Zahl, do you think that crouching isn't a feature?

- Added crouching because Enjay sent me a PM that took at least an hour to type.

[kc32]

What kind of bug fixes? *coughaticough*

[Graf Zahl]

Graf Zahl, do you think that crouching isn't a feature?

- Added crouching because Enjay sent me a PM that took at least an hour to type.

Not until it's officially announced. It will be in the next version but it has to be tested first.