with modern graphics cards, fitzquake could draw skyboxes using a cubemap (directly rendering the sky faces instead of drawing an actual giant cube.) And for the classic scrolling sky, i think you could do it with a pixel shader. 

[This excludes the idea that someone would write custom func_train code that supported angles, but even then the values would be positive].

I don't think engines should make this kind of assumption based on the mods that exist today. Suppose someone writes a mod that unifies func_train and func_rotate_train under the former name. Then a negative angle is a deliberate signal to the mod - make the rotation towards the next waypoint move in the positive direction. 

Baker, I'm surprised sky is a bottleneck.

If I make Sky_DrawSky return immediately without drawing anything, I get essentially no change in fps. This is with a fairly fast cpu (2.3ghz i7), 2 year old laptop gpu (nvidia gt 650m).

For me over half the time in the roman1.bsp starting position is spent drawing entities (mostly on alias models), a bit less than half drawing the world. In Mark V I get 90fps, 205fps with "r_drawentities 0" and 135fps with "r_drawworld 0" (but r_drawentities 1). Try setting those to draw only the world / only entities, to see relatively how much time is spent on each. 

sky is expensive in terms of overdraw - if its drawn fullscreen anyway.
the vanilla code is ugly as heck, it warps in a horrible way as you move around.
the skybox code that seems to be fairly abundant has a few issues with certain situations, like side windows, that increase overdraw unnecessarily, which can be expensive. a good example is dm2, where the side windows (that noone remembers are there) result in the sky basically covering the entire screen.

it can be significant when you're framerate limited, but at least the worst-case is limited to (less than) only half the framerate. 

@preach

I suppose so, I hadn't considered that. The traditional func_train would never move up/down like a door or plat. ;)

@ericw

Load up a skybox and instead of not drawing the sky, don't draw the world.

Now I understand what you say in regards to speed, I'm not blaming the fps in arwop on the sky (make no mistake) -- if you load up ARWOP and in Mark V and type in "cl_shownet 1" and then type "sv_cullentities 2" (which is DarkPlaces/FTE anti-wallhack level of culling server-side) --- you will watch the network traffic drop by 2/3rds --- ARWOP is a prime example of a beneficiary of network optimization (DarkPlaces and FTE probably breeze by it).

But I think the sky may be costing 100 fps on a map like id1\start.

I'll be finding out ... 

Make no mistake, I love the FitzQuake renderer, obviously.

The sky has been bothering me for years! And it reared up yet again.

The way the rest of the rendering works, I have never been able to determine or intent of the sky drawing the way it does --- everything else in the engine is clearly a clockwork and quite deliberate.

My only guess is to render fog on it consistently. And I intend to find another way to do that, if so. 

Goals of the fitzquake sky rendering:

* sky should only be visible when looking at a sky brush, not void
* if a sky brush is in front of some other geometry in the PVS, you should see sky, not the geometry behind it.
* brush entities with sky texture on them should look like sky too
* sky should be rendered as if it was a giant cube, and should not be distorted by the actual geometry of the sky brushes or the movement of the camera

So what i do is clear the zbuffer, then draw all the sky surfaces (brush faces) untextured (to write to the zbuffer), then draw the skybox with the depth-test reversed so that only farther objects pass the test. This means the giant, distant box of the sky will only appear on portions of the screen where the sky brushes were already rendered. Then I draw the rest of the world, and since the sky surfaces have correct depth values, they occlude any polygons farther away.

Even when drawing the scrolling cloud sky, i use a giant cube that has been subdivided enough to approximate the dome shape (r_sky_quality controls the subdivisions)

There's also some code to attempt to draw less than a full box, when only part of the screen shows sky. This was disabled for skyboxes (couldn't get it right at the time, due to tjunctions), but enabled for the cloudy sky (since it's subdivided into a grid anyway, there are no tjunctions.) 

I've been looking at MH's home work, and because I want any speedup I do to render identical to FitzQuake 0.85, I think I'm going to try this:

1) Instead of drawing the sky first, run through the sky texture chain + sky entities and see if any sky surfaces are visible. Set frame_skyshown to true or false.

2) Provided frame_skyshown, at end of drawing instead of beginning, either do a sky surface stencil pass or draw with glColormask (FALSE, FALSE, FALSE, FALSE) using sky surfaces + sky entity surfaces.

3) Then use the drawing code more or less as-is.

I understand the trickery of handling the skybox, ironically the software engine Makaqu supports skyboxes in WinQuake and draws the skybox only on those brushes (and it looks perfect too).

While tempting to give that a shot in Fitz, I think I'll try the more simple method outlined above at least at first.

Hopefully, it results in some fps. 

Stencil buffer sounds like a reasonable way to do it. At the time I didn't want to introduce a new hardware requirement but since every card for 15 years has had stencil, it's probably safe :) 

In Fitz 0.85's Host_Game_f (), do you remember why this is commented out?

//Cbuf_InsertText ("exec quake.rc");

We were discussing re-adding it in Quakespasm. Not doing it creates a disparity between the "-game" flag and the "game" console command, where "-game" will exec the mod's quake.rc possibly with custom settings, but "game" won't. This is a problem for some mods, e.g. those that set an increased max_edicts required for their maps in their quake.rc.

The only issue I can see is execing quake.rc might trigger a video mode change, if the gamedir you're switching to has some different vid_width/vid_height saved in the config.cfg. But it's easy to work around that with the vid_locked mechanism. 

@ericw
startdemos
stufftext
both are annoying every time you change gamedir. and yeah, engines that unconditionally shove a vid_restart into configs are annoying too.

if you can change gamedir without any side effects then you're a miracle worker.

your current settings getting wiped is pretty annoying too, if you bind your controls then change gamedir.

changing gamedirs without restarting is actually quite complicated if you want to to do it properly. plus its annoying if its not done properly.

FTE checks if the various configs change over the gamedir change, so it doesn't oblierate settings if there was no point in doing it in the first place. this helps reduce how annoying it is. There's still other issues, but they don't appear as often thanks to this. :P 

I originally added that line for the same reasons you want to resurrect it; to help make the mod's configuration closer to intended. But I disabled it because i encountered a lot of awkward problems as mentioned by Spike.

I decided it's better to do to little rather than too much, in this case.

I still think the config behavior is awkward, due to the fact that it only saves when you quit, and this means only one mod dir gets the updated config. I had plans to save it before switching mods, so the mod you are leaving gets any modified settings you created while in that mod.

It's still weird, though; and there are some settings that should probably be engine-specific vs. mod-specific, like graphics and audio settings. So there really should be two configs, one that is always stored in id1 and the other that is saved per mod. Each cvar would know which config it belonged to. 

A system where engines effectively intercepted the "exec config.cfg" command and converted it to the moral equivalent of "exec config.cfg;exec fitzquake.cfg" could work, especially if engine specific persistent variables got saved to that custom file instead of config.cfg itself. 

It sounds like the best option for QS right now is not changing anything and just document the behaviour/bug. 

So much old mods that can be broken by these sort of changes. 

I saw an interesting bug report on quaddicted by NoNameUser, here:

Also, "r_lerpmodels" is set to 1 by default, but the weapon models lose their smooth animations outside the start map; monsters are ok, though, and everything else seems fine too. I've had this problem with the weapons animations with other mods too (Warp Spasm, The Horde of Zendar, and others).

I was able to reproduce it in two big maps (warpd.bsp, zendar.bsp) on various Fitz engines (0.85, QS 0.90.0, MarkV). What was happening was, this condition in CL_ParseClientdata was firing every frame, even when I wasn't changing weapons:

if (cl.viewent.model != cl.model_precache[cl.stats[STAT_WEAPON]])
{
cl.viewent.lerpflags |= LERP_RESETANIM; //don't lerp animation across model changes
}


The cause was, the above check was done before handling the SU_WEAPON2 byte, so only the bottom 8 bits of cl.stats[STAT_WEAPON] were set, which would cause the test to always fail if the weapon model was > 255. I just moved the if() statement to the end of the function, seemed to fix up the issue; here's the diff.

Does that look sensible? The lerping if() block used to be inside
if (cl.stats[STAT_WEAPON] != i), but I think it should be safe to move it outside of that, because the lerping if() is also testing that the weapon changed. 

Good catch. Your fix makes sense to me. 

Sounds like a great catch. 

Is there a way to code in so modders can choose which models can and cannot cast shadows, and which weapons/enemies are lerped?

I am using a bunch of models in one of my maps and they cast unwanted shadows. 

Fitz/Quakespasm/Mark V all have r_nolerp_list.

Mark V has r_noshadow_list too. 

Huh... how do you add to this list? Rc file? Cfg file? 

They're just cvars so you set their values the same as any other.

It would probably be a usability improvement to have commands to add individual items to these lists rather than having to require the user (or moder) to respecify the entire list. 

yeah, it's not very user or modder friendly, but for modders adding it to quake.rc is the best idea. (alternate idea: use stuffcmd)

In the case of modders, you should be able to create a full list of what should have shadows and what should interpolate (since you wrote the mod!)

As a player you end up creating a really long list that applies to multiple mods, since most mods do not provide their own lists.

The ideal would be an extension to the model format or new fields on quakec entities for the modder to define the behavior for each model or entity. All of those things require engine support, plus either a tools change or protocol change.

Hence, the hacky config file method. 

who's idea was it to add all this stuff to console commands anyway? can we change this to some text file where we just put a full path in from the mod dir (eg: progs/flame.mdl) and anything in that text file is not lerped?

config files are infinitely easier for modders and users alike. 

necros, it already works like that, you can set up the list in your config file.