Cutscenes
#1266 posted by svdijk on 2014/10/02 13:23:51
#1267 posted by Spirit on 2014/10/02 13:55:12
Afaik reQuiem has some fixes for that builtin and also it smoothes demo gameplay. jdhack was pretty proud of that.
Yeah
#1268 posted by ijed on 2014/10/02 14:36:30
The camera jerks about when rotating, its a limitation of something in the engine - can't remember what.
Supa solved it in RMQ.
#1269 posted by JneeraZ on 2014/10/02 15:13:57
I thought it had to do with the networking or something? Coarse values in rotations for faster transfers.
#1270 posted by mh on 2014/10/02 15:58:06
The cutscenes use a bunch of svc_setangle messages which are controlled by setting ent->v.fixangle (sorry, I don't know the QC equivalent to this). It would be possible to lerp between consecutive svc_setangles engine-side, but there are probably edge cases (aren't there always) that need to be worked out.
Summary is that for zer cutscenes it is a combination of coarseness and widely-spaced (via nextthink) messages.
Svc_setangle
#1271 posted by Baker on 2014/10/02 15:59:40
Sends a byte angle (256 values representing 360 degrees), so using that to continually reposition the angles is going to be jerky.
[And can't be interpolated client-side because the 'resolution' of byte angles leads to inconsistent rouunding.].
Looks like jdhack has the client read it directly from the server-side camera entity in single player.
Well
#1272 posted by ijed on 2014/10/02 16:08:04
We had daisy-changing and interpolation between multiple camera positions at once on all three axis in both rotation and position - it was pretty fucking sweet :D
#1273 posted by Baker on 2014/10/02 16:21:32
In RMQ engine, it looks like you have it reading/writing float with the RMQ protocol.
jdhack has a lot of code detecting the Zerstorer cut-scene.
I'm hoping that code isn't necessary and just doing svc_setangle as either a short (2 bytes) or a float angle would fix this kind of thing.
The choppy angles in the cutscenes in, say, Zerstorer are annoying.
Bugs
#1274 posted by ranger on 2014/10/02 17:52:15
The texture bug is fixed in the latest version
Also the lag has been reduced but is still noticeable sometimes
A suggestion, allow quakespasm to read from the the game folders, not only the .pak files
Bug
#1275 posted by ranger on 2014/10/02 18:21:20
The camera is messed up in the Monster Match mod
Svdijk, Szo
#1276 posted by Pekka on 2014/10/02 18:48:38
I tested Fitz-0.85 with Wine on Linux. It has the same behaviour, as far as I can tell without a careful side-by-side comparison. The zerend fix pak corrected the end map camera placement.
Rewatching the Youtube clip, I now see it stutters too when the camera is rotating. I think I perceive it as much less annoying because the YT video has a lower resolution and a slower framerate.
Thanks for the responses, everyone! Things work well enough with the patch. It would of course be nice to have non-stuttering rotating cameras in modern Quake source ports, but it's not a feature I really need at the moment.
If I do find unexpected engine differences with a more careful comparison, I'll post about them later. For now, I assume it was resolution, window size and FPS that made the rotational stutter so much more striking in the engine.
Svc_setangle As Short Or Float
#1277 posted by mh on 2014/10/03 18:54:00
Right now I don't think this is going to fix anything.
The real problem is that you're relying on how often QC updates the angles. If it thinks at 10fps then the angles are only going to update 10 times per second so it's going to be jerky no matter what precision you send the angle as.
The more robust solution seems to be to detect if a Zer cutscene is playing and use the cls.demoplayback angle interpolation code in CL_RelinkEntities.
At least in this case the QC isn't doing a bunch of PF_WriteChar/PF_WriteAngle calls, but that's also something you need to be careful of.
#1278 posted by necros on 2014/10/03 21:57:14
checking the zer progs, seems like camera updates are 100fps (time + 0.01).
This is just the low res angles for the camera.
#1279 posted by Spike on 2014/10/04 03:35:56
The irony being that the lower the packetrate used, the smoother the interpolation will be, as the network inprecision is hidden behind larger deltas.
with vanilla quake, with no interpolation, you wanted to spam as fast as you can to try to hit every notch to get it as smooth as possible that way. interpolation won't make that any worse, but you'll see it juddering still as the difference between each frame is non-linear due to rounding. shorts will help counter high packet rates.
my general recommendation would be to update angles exactly once per PlayerPostThink. This allows the client to properly detect when there's a camera active by the fact that every single update contains an angle change. The down side is that this requires the update be sent as unreliable packets instead of reliable ones so that they're kept in sync with entity snapshots over the internet where reliables cannot be acked near-instantly.
Anything else will be jerky in some situation. And yes... needs shorts or low snapshot rates.
#1280 posted by necros on 2014/10/04 18:19:12
is cutscene smoothness an issue over a network though?
#1281 posted by Baker on 2014/10/06 01:51:40
Cutscenes wouldn't be affected.
Zerstorer happens to be particularly uncoopable in a way that is more than having extra coop spawn points (I recall be pretty disappointed but can't recall the reason why it is uncoopable).
[Nehahra has at least one cutscene but is coopable (although if I recall a couple of rare maps failed to have multiple spawnpoints), but I don't recall anything about the cutscenes in coop (i.e. did they happen or not).
I know there are a couple of more single player releases with cut-scenes, but I can't their names and whether or not they are coop friendly.]
Config File Organization Tips Requested
#1282 posted by Pekka on 2014/10/10 11:21:56
How do people organize their config files for Quakespasm and multiple game directories? I mean the dirs that are selected with the -game option, of course.
I understand that I should put the bindings and options I want into autoexec.cfg files and it is probably helpful to delete the engine-created config.cfg files after modifying the autoexec files. However, what exactly happens if there are several config files that might apply for a given game setting? In what order are they processed?
What config files should I backup/copy, so I can reproduce my settings on another Quakespasm installation? I don't necessarily want to backup my whole .quakespasm subdir, because I don't want to keep all the saves, screenshots and whatnot.
Basically, I'm asking that if someone has worked out a good practice to follow, could they be kind & share the details. I'm asking here because QS is now my engine of choice for SP Quake.
Configs
#1283 posted by ericw on 2014/10/10 19:33:39
Preach has a great explanation of how the different config files relate:
http://tomeofpreach.wordpress.com/2013/09/05/quake-rc-and-being-a-good-citizen/
autoexec.cfg runs after config.cfg. You can put an autoexec.cfg in id1 and it'll get run on all mods (as long as the mod doesn't have its own autoexec.cfg), so putting all of your custom settings in id1/autoexec.cfg and backing that up is probably the way to go.
I'm pretty lazy and only change a couple settings from their defaults - always run, r_oldwater, statusbar size - so I don't bother with an autoexec.cfg.
Thanks Ericw
#1284 posted by Pekka on 2014/10/11 17:38:28
Thanks for the link. I also found this useful guide with a Google search.
http://steamcommunity.com/sharedfiles/filedetails/?id=120426294
Thought for the day: If I ever get confused which config files Quake is actually execing, I can put a lines like echo "this is from the foo directory" into them and see at the startup what is prints into the console. That'll help clear any confusion, though I think I got how it works already with the help of these links.
#1285 posted by Baker on 2014/10/11 18:11:27
When Quake starts up --- and this is in your console output:
execing quake.rc // This is in a pak file
execing default.cfg // This is in a pak file
execing config.cfg // This is YOURS
couldn't exec autoexec.cfg // This is YOURS
This always prints to the console so you don't need to put an echo in there.
If you are putting your personal settings in autoexec.cfg, that is the only file you need.
#1286 posted by Joel B on 2014/10/12 00:38:39
I've run into too many mods that contain an autoexec.cfg, so now I just always launch with a command line that will explicitly +exec a file that has the stuff I'd normally put in autoexec.
Wrongly Cfgured
#1287 posted by Preach on 2014/10/12 01:20:25
If it's any comfort, the post on how not to do that is one of the most read on my site, so it may happen less in future...
Yeah
#1288 posted by ijed on 2014/10/12 01:26:32
I read it, agreed with the logic and then went and broke all the rules in a fit of malaise.
I didn't force a resolution afaik though.
Sorry
#1289 posted by nitin on 2014/10/12 02:46:00
I might have asked this before but cannot remember where. Do any of the modern engines support Nehahra or are they too man mod specific hacks in that for that to be possible?
#1290 posted by Spirit on 2014/10/12 10:36:37
|