Improving "ProQuake" Demo Record At Any Time

[Baker]

[qbism]

I didn't realize this was possible in Proquake. Proquake vs. Vanilla quake demo record- would it be easy to see the changes with a diff of cl_demo.c, or is it more elaborate than that?

[Baker]

It is pretty straightforward to implement, I'd diff ProQuake 3.50 ( source link ftp://ftp.runequake.com/quake/engines/p ... /3.50/src/ ) versus GLQuake.

[qbism]

Just got around to trying this, works almost out-of-the-box diffing with Proquake 3.50 cl_demo.c as Baker mentioned.

Now thinking about saving particle info as well. Will have to reverse-engineer color based on particle type (if possible) so it can be saved correctly. In svc_particle message the color number is encoded w/ particle type. Even if successful, svc_particle doesn't send remaining time information (or alpha for some engines). The temptation is to create a new svc_ command that sends an absolute particle snapshot.

[r00k]

qBISM UR ICON STILL SCARES ME.

Edit: Hmm, i went to look and Qrack has had this since v1.5 maybe sooner, though i do remember talking about this in the past...

[mh]

[qbism]

[Baker]

I hate to be a killjoy -- and please do not let this thought stop your experimentation because unconventional thought benefits us all ----

But savegames are supposed to be from the perspective of the server. The server doesn't have particles or temp entities or R_(anything) since R_(anything) is "render" (which isn't something the server ever does).

[Again ... at the same time, wouldn't it be nice if savegames preserved the entire world state, so kudos to your ideas .... I have some terribly unconventional ideas in this department myself ... not the particles department, but things like the server thinking about lighting and knowing lighting levels without the Quake2 hackery where the client sends it back to the server ... solar powered armor, monsters that ignore pitch black players, players entirely in shadows not getting sent to the client, etc. ]

[qbism]

This is still only for demo recording at this point, rather than savegames. Yeah, savegames would involve another insane layer including clients sending their individual particle states up to the server.

[Spike]

its really not worth it.
1: you loose demo compatibility. different engines can have wildly different particle systems, so don't expect any sane workarounds for that.
2: doesn't help multiplayer at all. different clients still get different particle patterns.
3: 1/8th qu precision probably isn't enough for tight bunches of particles.
4: console tends to cover up everything when starting playback, so you miss the first halfsecond anyway.

if you're trying to capture a good bit of action, it would be best to write the data to memory even when not actually dumping to disk, so when you actually start recording you can rewind a bit and actually record the action that the user wanted to record, instead of only the parts after it.
you can keep whatever particle log active for a little longer.

[qbism]

[taniwha]

The way it's always done: with a ring-buffer that stores X number of packets. Packets are stuffed into the head of the buffer, and read out of the tail. For this particular case, when not actually recording, when the buffer is full, packets are discarded from the tail.

[qbism]

[Spike]

yes, there's a catch. if you have any large state info that can get destroyed/replaced (like stats) you need to provide some way to restore them to what they are at the start of the log, rather than just dumping whatever the client currently has and hope that it hasn't changed.
doing this with quakeworld is much messier with its state-based delta compression.
you can generate a keyframe every second or so if there's a lot of data, though if its just NQ's stats most of it is repeated anyway, memory usage probably allows you to just dump out a copy of that data each frame.
obviously, you'd not be able to rewind over an svc_serverdata. flush the log when you get such a message. perhaps also for static entities/sounds too. baselines shouldn't generate extra data, and shouldn't be changed mid-game so should be safe to rewind over (on account of that baseline not existing and thus not being relevent before).

5 secs is probably enough, 10 secs would be great.
if you've got enough memory, you could even try and record an entire match. a 30-min 4v4 (quakeworld) demo comes out as only 15mb.

[taniwha]