I think QS's vsync implementation is broken, in that it doesn't disable the regular frame throttling code so sometimes you will get stutters. I would recommend avoiding vsync right now.

It sounds like you get hitching with vsync off as well, at 144Hz?

One hack you can try is "sys_throttle 0" - this will make QS use 100% CPU instead of sleeping (the default is 0.02).

If there's stuff we can do to make this better I am interested. I'm hoping to get a 144Hz monitor some time this spring as well. :-) 

I've set sys_throttle to 0 but there's no change that I can discern.

It's not hitching as such at 144 Hz with vsync off. The 'hitched' frame (for want of a better term) tears instead. It's regular as clockwork just as the hitched frame would be with vsync on.

Is there anything else I could try for you or any more info you need just now? 

sounds like you want SDL_GL_SetSwapInterval 2 instead of 1, or ideally -2 (to enable swap_tear when timings slip a little).
The interval in question is measured in terms of buffer swaps, so 2 means that it'll run at 72fps on a screen running at 144hz.

Regarding host_maxfps timings - quakespasm uses milliseconds for timing - and rounding down means it needs to wait a little longer before the next frame.
This alternative will give more accurate host_maxfps:
double Sys_DoubleTime (void)
{
return SDL_GetPerformanceCounter() / (long double)SDL_GetPerformanceFrequency();
}
But do note that it might misbehave on certain/old dual core machines that lack drivers to resync cpu timers.
And ideally you'd rebase the counter to 0 to reduce fpu precision problems, but they.

Regarding nvidia, (at least for me) vsync is broken in their opengl drivers when the program (otherwise) runs at about 1000fps. Crossing that boundary (relative to the previous frame) results in a noticeable stutter. Enabling something wasteful like bloom seems to help, thanks to it no longer drawing frames in 0ms...

tl;dr version: timers suck. 

host_maxfps has lots of subtle little interactions beyond just wonky physics and killer elevators.

Particle trails have been touched on before; here's another one that many people might not be aware of.

Record a demo of you running around in a map for a minute or so at host_maxfps 72.

Record another demo of you doing the same run-around in the same map at host_maxfps 1000.

Compare the file sizes.

Interesting, isn't it? 

For free. Why not? 

There's probably some legal shenanigans about distributing shareware Quake as part of another piece of software. Do you really want to read 17 pages of people who installed a sourceport without a game to play and are all copypasting the same gfx.wad not found error? 

I'm assuming there's a way to ensure Quake is installed before launching. Similar to DLC. I dunno. 

Can anyone explain why Quake monster models occasionally turn black? I'd guess it's a lighting bug in the Quake engine but if anyone could give more detail as to why. I remember seeing this especially with the Scrag model. 

Quake models get their lighting from the ground directly below them. If they pass over a bit of ground in total darkness, they go black.

Scrags sometimes fly over pits with pitch black bottoms far below them, and they thus turn black. Which is ugly. 

I kinda wish Quake used a 3d "light grid" like Quake 3 does for model lighting. People would probably be more inclined to make mdl props if the lighting was more accurate. 

And if there wasnt a 256^3 unit limit on size per frame. 

Don't models also only poll light from a fixed distance down? If they're too high up in the air they won't be lit regardless of what's below, iirc. 

 

I'm not sure if you're actually looking for a solution to it, maiden, and maybe this belongs more in Mapping Help, but there is a workaround for dark flying enemies.

At the very bottom of the area in question, use an ordinary texture, and light it adequately, for example with the texture light option in ericw's compile tools. A short distance above that put a brush entity, like a func_illusionary or func_wall, that has the visual you want, like the solid BLACK texture. Enemies will pick up the lighting info from the solid world geometry underneath the fake surface, but players will only see the brush entity. A func_wall will also have the effect of making the surface solid, so if a player dies their head camera won't fall through.

I used this trick in my Xmas Jam map, xmasjam_tens, and although I used a solid gray texture, the principle is the same. I did have to tweak the lights to prevent the lower edge of the world from being brightly lit, but with eric's light options I was able to set the surface light's '_surface_offset' key to a negative value (in my case -2048). The surface got enough light to make entities above it visible, but the lower edge of all my rockwork is no more prominently lit than the rest of it. I almost didn't expect it to work, but it seemed to, so I'm not going to look a gift horse in the mouth. If you want to take a look, my source .map file is included in the Jam release like everyone else's. The light entity I used for the surface light is sitting just atop the starting crate, at 296 248 -112.

There's also sock's ad_sepulcher. There's a cavern area with a bridge, which triggers a mini earthquake when you walk over it. Search for a bunch of entities with the targetname "cavebridge_setup", they're all in that space. Look down at the bottom of the pit and you'll see an approach similar to mine. First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures. There's a few lights with their 'mangle' key set to make them spot lights, pointing down, so they only illuminate the extreme floor and don't break the illusion of endless blackness.

I'm sure other mappers have examples of this too, it's an old trick, but those two are the only ones I can remember off the top of my head. 

Qmaster is right, here's a Scrag floating several thousand units above the floor and being lit by the red lighting at ground level. All the wall textures are grey. 

Winquake traced up to 2048 below the mdl, QS traces 8192 units. The code is in R_LightPoint: https://github.com/id-Software/Quake/blob/master/WinQuake/r_light.c#L248

@Tens
First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures.
Weird, I don't know why this worked, because the raytrace in R_LightPoint should have hit the func_detail_illusionary and picked that up instead of the lighting below it. Regular func_illusionary is safe though.

Btw, with my tools, you can set _minlight and _minlight_exclude on world brushes with func_group or func_detail - this could be a handy way to make the hidden brushes have the desired light value, without having to bother setting up spotlights pointing down. 

Thanks for the feedback mates. I was just curious what causes the ugly-looking effect. Good to know it's not a bug at all.

@ItEndsWithTens
If I ever dab at mapping I'll be sure to employ your workaround... :) 

@eric
I'm just going by what's in the 1.70 source files. Though looking at the map again in QS 0.93.0, Scrags flying over the pit do look kind of dark, so maybe it doesn't actually work? Hard to tell, honestly. You'd have to ask sock for more info, maybe there's more to it than meets the (or at least my) eye.

I'll be sure to fiddle with that minlight exclude key, sounds intriguing!

@maiden
Glad I could help! More Quake mappers is always a good thing, you'll certainly be welcome if you decide to join in one day. 

I added a "joy_exponent_move" cvar for controlling the move stick's mapping curve. Previously it was hardcoded as linear.. which translated to feeling twitchy (as Hipnotic Rogue was mentioing in ##3198)

I went with a new default of 3 (matching the "look" stick).. now you have to press the stuck further to get full speed, but it's easier to move slowly. The "look" stick is unchanged.

Wonder if any controller users could give me a second opinion on this in the dev build?
http://quakespasm.ericwa.com/job/quakespasm-sdl2/240/artifact/quakespasm-r1556.zip 

I'll give it a test run after work and get back to you. :) 

 

I've been messing around and setting the joy_exponent_move CVAR at lots of different values just to see the difference. I reckon you were on the money with setting it at "3" though. :)

Slow and small movements now feel much more manageable.

Good job. :) 

 

 

The scrag example is one of the reasons the lightgrid was invented for Quake 3.