Racing Ghosts (As this unfolds)

[Baker]

[Spirit]

While you are at that, a general demo parser -> human readable output would be ace. QuakeWorld has mvdparser for that http://qw-dev.net/svn/mvdparser/ but I am not aware of any such tool to process quake/netquake demos.

It could be interesting for analysing sp demos, eg where do players go, where do they die etc.

[Baker]

[qbism]

[Baker]

This is close to done.

+/- deciding if I think I need to get beer to wade through the final steps here of using the data ...
... I'm supporting multimap demos, involves some headaches...
... on the plus side, I think CL_Traceline can be used to keep the "ghost" from going out of sight (in the future)
..... basically pause the ghost if is be going to go out of visibility and keep him paused until he comes back into visibility.

[Baker]

Debugging phase ...

(Getting ghost progression right, etc.)

[Baker]

Hah ... working out the timing of this is soup-of-clocks. The pausing the ghosts BEFORE they go somewhere you can't see if perfect.

But there are 3 or 4 different timing scenarios that can go on here to do this right:

1. Someone else's demo may have a high fps or a low fps.
2. A demo may not start at cl.time 1
3. The data collection process that runs through a demo (at 30,000 - 100,000 fps = essentially instant ) --- which is like timedemo without the rendering or sound --- I don't have it waste space by writing if the player didn't move or look around or change frame (but it does record the cl.time obviously).
4. I need to allow for not only the client to be paused (opening the console in single player, for instance) but to stop the ghost so the player can catch up.

I've almost got this last part cracked. I have to have a virtual time (ghost time converted to client time) and if everything is paused then update the virtual time baseline and keep track of a "future time" which is essentially when we read again after cl.time exceeds that.

[But in reality, it is just slightly more of a mess than CL_RelinkEntities mtime[0]/ mtime[1] frac stuff. Unfortunately, like that, ghosts have to figure out if they teleported to avoid improper movement interpolation.]

/Note: Do you think Quake draws fast with the console up? I discovered that with a lot of text on-screen, it is actually very slow to render. This shouldn't be a surprise I guess, but I noticed my command to run through a demo hit only 400 fps with a lot of console text on the screen and 1100 fps with a clear console. When I had it stop refreshing the rendering entirely while the command was running, it hit several tens of thousands fps. The console is still on screen, it just isn't needless re-drawing it so it isn't like the screen is black, no it looks quite normal when the command is running.

[Spirit]

How can a user change the frame rate of a recorded demo? I always assumed that was a fixed number.

[Baker]

[Baker]

[Baker]

See it in action:

http://www.youtube.com/watch?v=TAod_G2J ... e=youtu.be

/ Because I'm kinda going to sleep now, heh.

[gnounc]

Two questions.

One: can you have the ghost render blueishWhite and transparent?
and Two: can you have the ghost NOT wait for you? So you can race him?
and if so, will he walk through doors? (currently it looks like he waits for you to open them, judging by your video).

[Baker]

[r00k]

That's pretty cool! This would be real handy to load up dm3 and ghost a match demo and spectate a match from Any angle..
Personally I think the SDA guys use a modified progs or server setting cause they seem to strafe jump faster than normal nq physics to me dunno

[Spike]

baker, regarding transparent models - draw the model with glColorMask(0,0,0,0); once, then draw it again with glColorMask(1,1,1,1);glDepthFunc(GL_EQUAL);
first time around you write just the depth (nothing actually visible at all), second time, you actually write colour, but only for the surfaces that actually match the nearest depth value written, resulting in a 'solid transparent' model. That's the theory, anyway.