Glad to have the option for the physics and that was what I was trying to remember after all! I recall trying to make some very specific jumps to a very narrow ledge and slipping off a bit. I am so used to NQ with QS that it's extremely noticeable. I have quite a few jumping puzzles in the map I am testing.

thx 

mmmm thats bad how the lighting setting would need tweaking to look right in the first place for users .

I did some experiments with breakable furniture, i guess it dosnt look to bad when its not casting a shadow, the AO these new compilers have kinda helps it not look to shitty.

Its always fun to play with new toys tho, especially all the render option this one has, is there an FGD file for the entitys i wouldnt mind playing around with it. 

I'm not concerned with DP, just wanted to know what translated that I already knew. This would simply be for FTE only mapping. 

.fdg files are a human-friendly and easily editable. It's very to edit a .fgd file to add what you want.

Beginner level mapping stuff, really. Open one and look. 

Just wanted to say that r_softwarebanding is a seriously awesome feature, very similar to gl_tonemap=5 in GZDoom (https://forum.drdteam.org/viewtopic.php?t=7097).

Just wish it would be ported to Quakespasm (maybe the "Spiked" fork?) someday. It's the only "feature" that's still missing from DOS/WinQuake.

On another note, how did you fix the texture seams when upscaling the HUD in Hexen 2? It's still broken in Hammer of Thyrion after all these years. Did you change GL_CLAMP to GL_CLAMP_TO_EDGE or what was it? 

I've heard positive things about FTE, so i decided to put it to the test. Not only did it load both really large maps shib3 and shib5, it performed really well, marginally better than Quakespasm. Of course FTE does have it's minor problems.

Many distant scenery had details missing, and there were odd holes in the cliff side wall. In addition, at some point transparent textures and static entities disappear. Could this be hitting an efrags limit?

Shib 5 had less visual issues, but more prominent ones. The mountains in the background disappear completely until you get fairly close to them, which you typically cannot do, so the scenery looks really bland.

Despite these visual defects, the maps themselves run fine with no gameplay issues

The other odd issue that can be game breaking is every so often, the player will just spontaneously warp to a completely different spot in the map, either inside or outside. It just happens randomly without rhyme or reason.

But despite these small setbacks, it appears to be a terrific engine with lots of customizable options to suit the needs of any players. 

Shib requires gl_farclip 256000, which FTE doesn't seem to support. 

all that jazz and no VR support?

these older games play really well in VR for some reason if VR is modded in correctly the new quakespasm sdl2 works great.

hacky injected forced VR however is poison 

Spike once said FTE has recursive mirrors. (99% on this).

FTE also has true rotation available and ericw-tools map compiling tools true rotation as an option. (To get the most out of true rotation -- like doors and drawbridges and such -- requires QuakeC, the Remake Quake game code QuakeC has that available http://svn.icculus.org/remakequake/src/ ). 

Am I reading that right?

Just need to add RMQ's rotation QC code to a progs compile and all the pieces(ericw tools + progs + FTE) are in place for true rotation? 

I already tested this so, it worked. No need for a reply.

Such an easy setup. Only downside left is the "choppiness" of the rotation. But every Quake rotation has this as well. 

That is correct. Should work in DarkPlaces as well. DarkPlaces also supports true rotation.

Rotation particularly is required for, say, func_door. You have to modify the door code.

As I understand it, it's probably a notch or 2 above novice level -- so if you are completely QuakeC clueless/coding adverse you'll either need to commit to doing a QuakeC tutorial or 2 to move yourself above novice --- or find a QuakeC literate friend and either bribe him/twist his arm to doing the task or helping you along the way.)

If you use something like WinMerge (a user-friendly file app to compare files or whole folders) to compare versus vanilla progs 1.06 source code to the below, you may find this useful as a start ...

http://forums.insideqc.com/viewtopic.php?f=12&t=2376 (ignore all the engine code on that page like world.c, sv_phys.c -- that ain't QuakeC).

Nothing about it is "hard". But will require a medium commitment to detail.

I, in fact, was quite newbie writing that tutorial and used WinMerge to extract the door rotation QuakeC from Avirox's source code. I doubt I understood much about the actual QuakeC -- but I didn't need to. Then I made a test map with Rubicon wad setting angle and such.

The QuakeC source is included with the sample map. 

Choppiness of the rotation should be able to be fixed. It needs higher precision angles.

I would expect that in DarkPlaces it may be smooth as silk because I believe DarkPlaces protocol 7 uses precise angles by default.

FTE may need some kind of "hint" to cause smooth angles.

I don't know how to do that.

Hopefully Spike notices your angle precision needs. FTE has protocol extensions (etc.), but I am not versed on those. 

You might be able to do "sv_protocol 999" in FTE. It may immediately resolve it if it is available, although if 999 is available in FTE, I'm not sure that FTE doesn't have something better available that would be a better choice in the long run. 

Spike can confirm, but I think it's "sv_bigcoords 1" 

I had vsync enabled(hate screen tearing), it is smooth as silk now.

Thanks Eric, Baker, Spike and the RMQ peeps. 

@KenChennar
gl_maxdist 0 will give you an infinite projection matrix, at the cost of depth precision.

@damage_inc / Baker
sv_bigcoords 1 is equivalent to sv_protocol 999, but also applies to fte's qw protocol too (and is required for the server to use dpp7, also).
this setting provides both 32bit coords and 16bit angles.
enabling vsync or setting cl_netfps lower, or making the thing rotate faster can avoid two sequential snapshots with the same angle (ie: the rotation periodically stops), giving better use of the precision that's already there. 

I'm not sure what that command has to do with what I described, considering its always on 0 by default. 

Ok, I've been testing with this since I started this thread. Here's something I'm curious about.

I have a completely stock install of FTE making sure that these are set in my autoexec.cfg, and are working as intended:

gl_load24bit 1
gl_specular 1
r_glsl_offsetmapping 1
r_deluxemapping 1

Compiling, Light gets this:

-lux -extra4 "$bspdir/$file"

Nothing else, as far as the engine and the mapping, is changed for this test.

I am of course using some replacement textures each with normal maps and one including a specular map(floor).

My issue is, you know how we use "muzzle flash" from the weapons to light up dark areas? Or even just general rocket/grenade usage that lights up areas as well...

That doesn't seem to work for me mapping like this. Or it's inconsistent.

The dark areas most of the time just stay really dark(black/unlit) or... for no reason will light up occasionally and then stop again.

This of course looks strange.

Any thoughts on what I can do to correct this? 

... but no matter what window mode I select, FTE writes only a transparent image and my Windows "Print Screen" button seems disabled(?) as well!

Hope the info I provided is enough. 

I used OBS to record and grabbed images from video:

https://i.imgur.com/mIOxyaA.jpg 

rabbit holes, explore 2 or 3 with an advanced engine ... eventually ... you don't return at all.

Quake is successful because of the limitations (256 colors, etc.) and the many things you cannot do force an author to limit the scope of their project.

With an advanced engine, what starts as a project morphs into exploration drift -- then you find bugs or limitations.

I mention this because it is very uncommon to find a completed project that targeted DarkPlaces or FTE.

The specs of the project increase and increase, exponentially growing the labor hours required for the result --- until the number of labor hours passes the event horizon ... never to return.

A paradox ensues --- offering more capabilities dramatically increases the possibilities but decreases the probabilities.

So planned projects that plan to target the engine capabilities increase, but completed projects that actually do target the engine decrease --- usually to a specific number --> zero.

/Thought of the day 

Having an engine with more advanced capabilities seems a dubious problem. Evidently there are projects built on UE4, CryEngine, Source, etc that do get completed.

Having the capability to mod the engine is IMO more of a problem. But blaming the engine is only half the story. Mod teams need to exercise discipline and restraint too. 

quake defined the limits higher.

dork. 

This is accurate, in my limited experience. I have since imposed a set of limits on my project so that it will be coherent and actually make it to completion. IMO, setting limits was a great move both logistically and creatively.