FTE QW engine.

[FC Zvyozdochka]

I've recently discovered this engine and I'm pretty impressed.
First of all, this engine looks better than Tenebrae and works faster than Darkplaces. It does supports realtime lighting, per-pixel lighting, bloom, offsetmapping (even POM) and many otnher graphical features. Good news for many Quake fans and especially for me - this engine will support RMQ once it will be released, so I'll be able to play this wonderful remake with nice graphics.
So this engine is good both for those who like eye-candies and for modders who like to do something new.

But there are some questions to Spike - engine's author.
1) Engine seems to support both *.lit and *.rtlights-files, but works weird (for example, when I come closer to RTLight it disappears). You can download this relight for two excellent maps by Shadow to see this issue.
2) Other problem with lighting - I can't set Dlights to realtime mode when static lights are set to lightmaps mode.
3) Bloom exists, but has no adjustments at all. That gives a bad picture, cause base bloom configuration is not so good. DP has some bloom options, and that allows to find an optimal bloom settings. And there is a bug with bottom left corner obscured with black rectangle when bloom is on.
4) Engine seems not to support glossmaps. It is not good, because glossmaps could greatly improve the game's look. Just as cubemap reflects.
5) It would be cool if engine will support shaders effects, such as realistic water, godrays etc.
6) And the last thing - particle effects. FTE's default effects are not bad, but the newest particle effects (for example from Seven's SMC) are just incredible, so it would nice if FTE will support them.

[Spike]

1) This is an old bug, which version are you using?
Your download link is a little too... russian... for me to be able to use. I have seen such a bug on start etc in the past, but can't reproduce that any more.
2) yeah, that's a menu bug. cvars work properly. this has already been fixed.
3) I rewrote bloom fairly recently, yes. The previous version was pretty much just a blur shader...
Not sure I should really advertise this, but you can tweek it by directly editing the glsl...
r_dumpshaders; flocate glsl/bloom_filter.glsl; flocate glsl/bloom_final.glsl
paste that into the console and it'll show some file you can edit to change the shaders themselves. Yes I should make those hard-coded values into cvars.
4) yeah, its not ideal. it is supposedly using them, they're just barely visible or something stupid.
5) theoretically the engine is already capable of refraction effects (requiring modified .shaders much like DP), as well as sky-based god rays, but currently lacks the glsl to really make it worth it.
6) FTE's particle system is more versatile than DP, and pre-dates DP's too.
The r_exportbuiltinparticles command will write out the built in particle effects which you can then be edited much like DP's can.
documentation here: http://fteqw.svn.sourceforge.net/vie.../particles.txt though there's some other things added since that was written.
You can actually set 'r_particledesc' to 'effectinfo', but doing so isn't recommended - it is less versatile, incomplete, and the resulting effect does not exactly match DP, making it pointless.

[golden_boy]

May I suggest to use this download link for FTEQW:

FTEQW - Main Trunk

It provides builds from the SVN repo, but since FTE is pretty much constantly being worked on it seems natural to use those.
I believe the "stable" version is somewhat stale.

FTE is good stuff, I do check out the new builds from time to time.

[FC Zvyozdochka]

1) This is an old bug, which version are you using?
2) yeah, that's a menu bug. cvars work properly. this has already been fixed.
3) I rewrote bloom fairly recently, yes. The previous version was pretty much just a blur shader...

I used SVN version, now I'm downloading another one, maybe its just my fault. I'll check all these things.
added: nope, just tried some versions from main trunk page - all these bugs exist for me tried windows versions, both 32 and 64 bits, full merged clients and full OpenGL ones. At least there are no black rectangle with bloom, but bloom still looks bad and has no options, and cvar bug with lighting options still exist.
Can't you please give the right download link?

Your download link is a little too... russian... for me to be able to use. I have seen such a bug on start etc in the past, but can't reproduce that any more.

It is easy to download. Picrelated.

Not sure I should really advertise this, but you can tweek it by directly editing the glsl...
r_dumpshaders; flocate glsl/bloom_filter.glsl; flocate glsl/bloom_final.glsl
paste that into the console and it'll show some file you can edit to change the shaders themselves.

Is it possible to copypaste some DP features via glsl dump file?

Yes I should make those hard-coded values into cvars.

That would be very kind of you!

4) yeah, its not ideal. it is supposedly using them, they're just barely visible or something stupid.
5) theoretically the engine is already capable of refraction effects (requiring modified .shaders much like DP), as well as sky-based god rays, but currently lacks the glsl to really make it worth it.

Will you work on these things, or it is not interesting for you?
"Pretty water" is the absolutely musthave for many people.

6) FTE's particle system is more versatile than DP, and pre-dates DP's too.
The r_exportbuiltinparticles command will write out the built in particle effects which you can then be edited much like DP's can.
documentation here: http://fteqw.svn.sourceforge.net/vie.../particles.txt though there's some other things added since that was written.

Cool! I didn't knew that. I'll try to make some effects to do something like Seven's SMC.

You can actually set 'r_particledesc' to 'effectinfo', but doing so isn't recommended - it is less versatile, incomplete, and the resulting effect does not exactly match DP, making it pointless.

Well, no, if FTE's own particle system is more powerful - then it deverse its own better particle set.

Golden boy, thanks, this page is already in my bookmarks

[Spike]

regarding the particle system, one (general) significant difference between fte and dp is that fte allows per-shader glsl code, including embedding shaders and thus glsl within particle effects.
The 'high' particleset contains a teleport effect which warps the screen around it, via glsl.
Check out high.cfg's te_teleport

Like I say, FTE can support refraction when given the proper shader.
This is a quickish example for eg *water1 (on eg dm3).
Shove this in some .shader file, enable r_novis (or use a water-vised map) and you'll have a somewhat cheesy refraction effect for that particular water texture.

*water1
{
	glslprogram
	{
!!cvarf r_wateralpha
varying vec2 tc;
varying vec4 tf;
varying vec3 norm;
varying vec3 eye;
#ifdef VERTEX_SHADER
attribute vec2 v_texcoord;
attribute vec3 v_normal;
uniform vec3 e_eyepos;
void main (void)
{
	tc = v_texcoord.st;
	tf = ftetransform();
	norm = v_normal;
	eye = e_eyepos - v_position;
	gl_Position = tf;
}
#endif
#ifdef FRAGMENT_SHADER
uniform sampler2D s_t0;	//refract
uniform sampler2D s_t1;	//normalmap
uniform sampler2D s_t2;	//diffuse
uniform float e_time;
uniform float cvar_r_wateralpha;
void main (void)
{
	vec2 stc, ntc;
	vec3 n, refr, refl;
	float fres;
	stc = (1.0 + (tf.xy / tf.w)) * 0.5;

	//apply q1-style warp, just for kicks
	ntc.s = tc.s + sin(tc.t+e_time)*0.125;
	ntc.t = tc.t + sin(tc.s+e_time)*0.125;

	//generate the two waveforms
	n = (texture2D(s_t1, 0.2*tc + vec2(e_time*0.1, 0)).xyz);
	n += (texture2D(s_t1, 0.2*tc - vec2(0, e_time*0.097)).xyz);
	n -= 1.0 - 4.0/256.0; //rebalance to avoid 8bit precision issues
	n = normalize(n);

	refr = texture2D(s_t0, stc + n.st*0.2).rgb;
	refl = texture2D(s_t2, ntc).rgb; //actually this is just the regular warped texture

	//fresnel term please!
	fres = abs(dot(norm, normalize(eye)));
	fres *= 1.0-(cvar_r_wateralpha * 0.5); //I've used an extra multiplier to ensure its visible.

	gl_FragColor = vec4(refr * fres + refl*(1-fres), 1.0);
}
#endif
	}
	{
		map $currentrender
	}
	{
		map water1_norm.tga
	}
	{
		map water1.tga
	}
}

Note that its not too fundamentally different from the te_teleport effect I mentioned earlier.
It does lack reflections however. Shouldn't be too hard to render that to an FBO (basically using the existing mirror/portal code). So consider that already done.


Regarding DP's glsl, theoretically yes, you could copy+paste the relevent bits out of dp's main.glsl file in to whatever shader you're trying to create. A few things worth mentioning: DP uses the one-shader-to-rule-them-all method which contains a whole huge mega big chunk of ohmygodlookatallthat code, which makes it quite hard to actually figure out which parts are useful, either way its not a direct copy+paste. Also both engines use different names for the various inputs (the uniforms/attributes). Its probably better to copy the maths/logic rather than the whole text.

[FC Zvyozdochka]

Look at your shader, Spike

Funny bug, isn't it?

However, that's very cool that your engine is not only powerful, but is also easily customizable.

Two more things I forgot to say:
-"previous weapon" command seems not to work properly (don't you remember how it is called ingame? "impulse **"?)
-straight edge shadows looks much worse than soft edge ones. It applies not only to your engine, but to any other, including DP and id Tech4.

[Spike]

lol, I try and show off and it blows up.
Chances are these two textures are not loading.
map water1_norm.tga
map water1.tga
Those two names are just textures I'd hoped you had. Bah.

its _generally_ impulse 12 for reverse-weapon-cycle. but some mods use different impulses (like 11), or don't even support it. if 10 works then its a mod issue.

[FC Zvyozdochka]

Yep, Spike, it was my fault
Now that's much better!

Still not as good as "pretty water"... but I guess it is only for now

BTW, are you planning to add DDS texture support or you don't see no need to do?

added: one thing that makes me happy in FTEQW (even though this engine does not yet support some kinds of eye-candies) is that its precise offsetmapping works at least twice faster than DP's one. It really adds a volume to the textures, without ugly curves that appears in DP when reliefmapping is turned off.

[Spike]

fte should already support dds files containing dxt1-5. I've not personally encountered any other type of dds file, though I've not really looked that hard either. I've no real feelings towards or against more complete dds support - if there's a texture pack using it then I'd probably find the motivation to support it, but until then I'm not sure there's much need. Like I say, fte does support dxt1-5 compression (assuming your drivers do too) so the main advantage of dds files is supported already. There's just a lot of ways for dds loading to fail due to gl drivers rather than just the game engine for me to be confident in using/promoting the format.

FTE is generally lighter on cpu usage than DP (every engine is tbh), resulting in differences like DP:600fps, FTE:2000fps on the initial start spot on start.bsp on my machine (my attempt at deathmatch-optimised settings in both engines, with a fairly low res of 640*480). They will get closer as more fillrate-demanding features are enabled, like reliefmapping and rtlights.
timedemos finishing before the monitor has even finished changing video mode is always fun though.

[gdiddy62]

@Spike
FC is right about your engine, it has many interesting features. One issue I have encountered is the inability to pull up saved games in single-player. I comes up with a warped picture.

[Spike]

gdiddy62: bug reproduced (far too easily, grr). Its probably somehow caused by the hub system, I'll have to fix it tomorrow though.

[gdiddy62]

Thank you!

[gdiddy62]

spike,
any luck with the save-game bug?

[Spike]

fix for saved games, and a few other things committed. buildbot doesn't seem to have run yet though.

[gdiddy62]

Thanks Spike! I look forward to downloading the updated version.