FTE QW engine.

[Seven]

Hello Spike,

I noticed 2 small things today, I would like to report to you. I am using the actual 17.9.2014 build.

One is that in "menue/video options" the "Apply settings" function does not work.
I wanted to make the screen brighter and set the sliders accordingly (by the way you have to switch them from left to right, as right implies a bigger value to the user and a bigger gamma is usualy brighter I think).
After that I clicked "Apply settings", the engine restarts and jumps back into the menue. But the settings have jumped to the prior condition and both sliders will not work anymore.
I had to push the "esc" button 4 times to get back to prio menue.
This is reproducable each time, so you should find the solution quickly.

The other is, that when using vanilla Quake and using the "Realtime preset" and starting "start.bsp" the floor around the players spawn point gets black when the lava ball is falling into lave (in hard entrance).
You can see when starting the map and you do not move. Just wait.
Each time the lava ball falls into the pool the floor gets black around the player.

I deleted the "fte" subfolder each time before testings.

Best wishes.

[Henry]

Spike, I am using win32 build of fte and have a problem i would like to report.
Since 2014 the animmap shader support seems to be corrupted. With a 2013 build (svn 4392) animmap works fine and robust in all graphic presets.

Changing to recent svn 4863 it doesnt work in realtime preset at all. And only works in default preset when 1st time starting the engine to create configs. After that at second engine start it stops working even in default preset.

I made a simple shader to test this, like:
tex_foo
{
{
animmap 2 textures/tex_test1.tga textures/tex_test2.tga
alphaGen vertex
}
}

Result in game is: the texture always stays at tex_test1 and doesnt switch to tex_test2.
In svn 4392 animation works robust in all presets and all circumstances. In svn 4863 it behaves like posted above.

Can you please look into it? That would be nice.
Thank you Spike.

[Spike]

$diffuse refers to a single texture. this means that rtlights are unable to utilise anything but the first frame of an animmap. this has been true for as long as I can remember.
r_shadow_realtime_world_lightmaps got changed to 0 at some point (it was 0.5 or something). this small change will have completely removed any animmaps in the realtime preset. I can't think of how else they might have 'worked' in the past.

its basically a symptom of trying to get something fundamentally incompatible with rtlights working with rtlights without just being downright wasteful. :s
animmaps gives me more reasons to rework how shader overrides work, so thanks... I think.

I don't see why that particular shader would be broken in the default preset though, as there's no glsl to override anything.
I can't think of any reason for fullbright animmaps to not work - unless they have some (fte-specific) glsl code attached to them (in this case, a recent builtin-shader change will have broken them some time this year).

[Henry]

Yes, when enabling r_shadow_realtime_world_lightmaps again, the animmap shader works (its visual intensity is directly depending to that value, though). I had assumed that DP and FTE are acting similar here, as DP´s animmap still works when r_shadow_realtime_world_lightmaps is set to 0 (visually even independent to its value).
So, shader overriding is quite different in both engines then. Hmmm.

I also still could not find out if and how FTE is supporting _glow replacement textures. The ones from existing texture packs for DP are not working in FTE. _glow or _luma doesnt seem to do anything when used without a shader in all presets.

I was hoping to be able to convert some of the available much used extension packs for DP to be usable for FTE as well, but it gives me trouble as both engines handle textures quite different when it comes to those. Different shader overriding procedures and "effect texture" handling such as _glow makes it hard to somehow convert them to FTE and keep the 'look' ingame.

That is kinda sad, as FTE is becoming the most advanced engine and most existing extension packs doesnt work in their current condition, as they are made and developed for DP in first place.
At least I tried

[Spike]

I added an r_programify cvar which should get FTE to treat shaders more like DP does. Set it to 2 and it'll strip some extra things that DP ignores/requires.
$diffuse etc got a little reworking so that they'll now utilise animmaps.
_luma should already be supported (r_fb_bmodels 1 or something, if you disabled that).
[dp_]reflectcube should also be supported now (but only on walls+rtlights. models/others didn't get any updated glsl yet).

[Seven]

Hello Spike,

Great to hear. Thank you for your effort in adding Darkplaces-compability into your engine. I have also read about toneddu2000´s work and your modifications in shaders on this manner.

It is always interesting for me to read people writing and mentioning "FTE + DP" when they are talkjing about the most advanced engines. Even though these two engines are quite different in many areas.
So it is honorable from you for putting much effort in trying to make available content usable for FTE too. I remember our discussions about the "effectinfo"-translater in your engine...

Best wishes,
Seven

[xaGe]

Thanks for your efforts spike.

[Henry]

Spike, Thank you very much.
Unfortunately I still have issues. Maybe you can help me.

SVN 4870 has no more issues playing animMap in realtime preset without enabling r_shadow_realtime_world_lightmaps.
But the issue with animMap working at all is still present. Several times it stops working after restarting the engine. Then only the 1st texture in the animmap shader definition is shown. No animation. It seems to be some corruption in the config. When I delete fte subfolder and start the engine again it works again for me. But after several restarts, animMap doesnt animate again (like described in earlier post). That is weird, but lets not think about it too much. Deleting configs always makes animmap work again.

My next question is, _luma textures work, when I do NOT use a shader:


But when I simply add the animmap shader, the area where the _luma shall shine, gets almost black, while the diffuse texture looks identical:



What would be a shader example to get the same effect like without a shader? Bringing the _luma texture to shine?
Because the 2 texture sets in this example have the identical diffuse and _norm textures. The only different texture is the _luma texture. One is bright and one is dark (but not black). That shall make the ammo box lights flashing frequently with animmap.


Your new cvar r_programify is not recognized by SVN 4870. That is the newest I could find. Typing it into console makes the player say: r_programify

[Spike]

its r_forceprogramify sorry.

using strict q3 syntax, for lumas you need something like:

foo
{
{
map foo.tga
}
{
map $lightmap
blend filter
}
{
animmap 5 foo_luma.tga $blackimage
blendfunc add
}
}

Of course, this omits deluxemapping.

typically you'll find it easier to take a dp shader, strip out any stupidities like 'depthfunc equal' on the first pass, remove any stupid over-darkening caused by multiple lightmap passes, disable the stupid tcmod scales that dp seems to require ONLY with shaders, and then add a 'program defaultwall' line.
and then you'll have something roughly equivelent to r_forceprogramify.
note that by adding 'program defaultwall' you basically tell the engine to surpress certain q3a things and draw the surface with some glsl instead. this means its free to load any extra textures like bumpmaps or fullbrights that it thinks it needs, so long as they're enabled for the model type.
its a bit complex, and it feels like I still haven't ironed out the kinks. :s
but it is quite versatile when you get deep into it. especially when you start playing with bemodes

[LkMax]

Hi, so, where can I get the latest version of this port? the site fteqw apparently changed. I'm having constant crashes and I want to see if a new version might fix my problems - this is the best port among the ones I tested and I'd really appreciate to be able to play with it (darkplaces is also fine but it has progression bugs on the expansions which does not happen on FTE).

[Johnny Law]

FTEQW - Latest

[LkMax]

Thanks, it worked perfectly! Played for half an hour and no crash at all, some graphic glitches where gone too. =)

[mushi]

I'm having issues with getting the animated ammoboxes pak to work with FTE. this one: shader_animated_bulletboxes-high.pk3

sorry for the spam:
currently only rockets animation is working.

textures/b_batt0
{
	fte_program defaultwall
	{
	map textures/b_batt0.tga
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
	}

}

b_batt1
{
	fte_program defaultwall
	{
	map textures/b_batt1.tga
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
	}

}

b_batt1_lbar
{
	{
	animMap 6 textures/b_batt1_lbar_00.tga textures/b_batt1_lbar_01.tga textures/b_batt1_lbar_02.tga textures/b_batt1_lbar_03.tga textures/b_batt1_lbar_04.tga textures/b_batt1_lbar_05.tga textures/b_batt1_lbar_06.tga textures/b_batt1_lbar_07.tga textures/b_batt1_lbar_08.tga textures/b_batt1_lbar_09.tga textures/b_batt1_lbar_10.tga textures/b_batt1_lbar_00.tga textures/b_batt1_lbar_10.tga textures/b_batt1_lbar_10.tga textures/b_batt1_lbar_10.tga textures/b_batt1_lbar_10.tga textures/b_batt1_lbar_10.tga textures/b_batt1_lbar_00.tga
	alphaGen vertex
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
    	blendFunc GL_DST_COLOR GL_ZERO
	}

}


textures/b_nail0
{
	fte_program defaultwall
	{
	map textures/b_nail0.tga
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
	}

}

b_nail1
{
	{
	animMap 2 textures/b_nail1_0.tga textures/b_nail1_1.tga 
	alphaGen vertex
	rgbGen identity
	}

	{
      	map $lightmap
      	rgbGen identity
    	blendFunc GL_DST_COLOR GL_ZERO
	}

}

b_rock
{
	fte_program defaultwall
	{
	map textures/b_rock.tga
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
	}

}

b_ID1rocketbar
{
	{
	animMap 10 textures/b_ID1rocketbar_00.tga textures/b_ID1rocketbar_01.tga textures/b_ID1rocketbar_02.tga textures/b_ID1rocketbar_03.tga textures/b_ID1rocketbar_04.tga textures/b_ID1rocketbar_05.tga textures/b_ID1rocketbar_06.tga textures/b_ID1rocketbar_07.tga textures/b_ID1rocketbar_08.tga textures/b_ID1rocketbar_09.tga textures/b_ID1rocketbar_10.tga textures/b_ID1rocketbar_11.tga textures/b_ID1rocketbar_12.tga textures/b_ID1rocketbar_13.tga textures/b_ID1rocketbar_14.tga textures/b_ID1rocketbar_15.tga
	alphaGen vertex
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
    	blendFunc GL_DST_COLOR GL_ZERO
	}

}

textures/b_shell0
{	
	fte_program defaultwall
	{
	map textures/b_shell0.tga
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
	}

}

b_shell1
{
	{
	animMap 2 textures/b_shell1_0.tga textures/b_shell1_1.tga 
	alphaGen vertex
	rgbGen identity
	}

	{
	map $lightmap
      	rgbGen identity
    	blendFunc GL_DST_COLOR GL_ZERO
	}

}

help

[Duke]

I have this problem where skins glow, anyway to fix this?

See screenshot

[Spike]

@mushi
the rocket shader is the only one that has a non-vanilla shader name.
presumably this means that your other models have similar textures which are not replaced by that shader.
if you open maps/b_batt0.bsp for instance with the model viewer, it should display the names of the shaders/textures in use. however, this does not mean that the textures in that package are compatible with the replacement model that you're trying to use.

@duke
the glow itself is because you have bloom enabled.
fullbright player skins are a common theme with quakeworld (and really, if you're playing deathmatch you'd be at a disadvantage if you didn't).

I don't know what other stuff you have installed, but it looks like you do have a high-res skin on that player (as well as some replacement realtime lighting stuff).
my guess is that you have some scripts/*.shader file that was made for DP that glitches out in engines that actually support those shaders more fully.
you can try using the 'dpcompat_makeshitup 2' setting, which ignores chunks of functionality and overrides most of the rest of the shaders. unfortunately it breaks other stuff too.
if you want to try rewriting the shader, you can use fte's 'dir' console command to list possible shader files within paks+pk3s, and then open+change whichever file sounds most appropriate with notepad or whatever (pk3s are just renamed zip files, but pak files are much more awkward).
typical things to look out for are lightmap passes on things which have no lightmaps, especially additive ones (which would give lots of white).