News | Forum | People | FAQ | Links | Search | Register | Log in
Recording Demo's And Protocols
As you migth have read in the e1m5qouth thread, i fried my videocard last week. And now can onyl run softwarequake pretty crap (it crashes pretty often) glquake nto at all, but fitz seem to run fine (except it doesnt run as smooth as it should but thats np).
I still have a some sort of project goign on and i need to do a couple more runs to complete it. All other demos are recorded in the standard protocol (i used joequake-gl).

Is it possible to change the protocol in Fitzquake? Or to convert the demos? Or is there a other custom engine i might be able to run wich uses the standard protocol?
Use Quakespasm.
You can specify the protocol with sv_protocol.
If the demos are standard protocol 15 then any engine should play them out of the box regardless of sv_protocol though. 
in fitzquake, set sv_protocol before starting a game. It can be "15" or "666" -- 15 is the standard protocol compatible with all engines.

There is currently no converter that can handle 666 demos. But several engines can -- at least DirectQ and RMQ can run them, plus I think Baker has released one or more engines that support it, but I don't know which ones or what they are called. 
Oh Yeah 
and quakespasm 
Thx For Tips 
Its kind of strange, it seems trivial when quake decides to crash. i tought i figured it out and winquake seemed stable on this (onboard)card but at some point (or a certain map) that started crashing to.

Then my AV gave a warning about fitz when that crashed. Then i found out i can watch demoes in joe-gl np, just when i start playing it stutters and crashes (oh and i dont see a menu nor console, good thing over the years i learned the menu by head). But in the end if i find somethign wich is stable its stable and i can play/record/watch np...until i change map or something

quake hasnt beem so exiting in years!:) 
Is there some kind of info that talks about how to load a demo file? Might be an interesting project to make a demo converter of some sort. 
Demo Tools 
There is plenty of code to read dem files, for example or indeed many of the things in the "source code" section of (some even in Turbo Pascal!!).

It's a fairly grotty format though. 
didn't know that remake studio source was released. i remember goofing around with that way way way back. :)

i'd probably try to do it in java if i did it at all. i have way too many things on my plate atm, but thanks for pointing me towards that. 
Is Quake like Doom, ie given the same player input entirely deterministic? or does it do anything more complex than that? :E 
Dem File Format 
The dem file format is documented by Uwe Girlich (author of lmpc) at (not sure if that's the original URL).

I don't think you could call Quake deterministic, there's a lot of random events (calls to rand in progs.dat) Not sure what the random seed is though. Thus, demo files do not track player input. Rather they store entity positions, frames, angles, etc, for all entities, not only the player. 
Oh And 
what's this project of yours, Basil? Heh now I'm curious! 
Its The.. 
never ending project! i think i got half of the work done now. I'm never good with planning but should be a mather of weeks till i got something 
playing back demos is deterministic, but playing a fresh session with the same input is not, because quakec calls random() sometimes. Also it's framerate-dependent, so faster/slower framerate will affect physics and timing. 
Some of the rand () calls in e.g. the particle system can give different results between different playbacks too. I just seed the generator with an int derived from the first 4 chars of the demo file name (and since it ends with ".dem" it will always be at least 5 chars) to work around that, then re-seed it with the current time (in microseconds) when done. 
Demo File Format 
Is just the same as Quake's network stream but with a handful of extra bits added. Much the same code is used for parsing both. It's slightly nasty in that it mixes text with binary file I/O, but otherwise it's quite straightforward. 
I guess the grottiness I was referring to is the lack of framing inside the blocks -- you have variable length messages and the length of each message depends not only on the message type but also which bits are set in the message-type dependent 'mask' flag (and on knowing which bits of the message are meant to be variable length things like strings). I can understand why it was done like this, but it's a pest if all you want to do is extract the position of entity 1 over time :-) 
Oh and there's also my completely crazy Python-that-genrates-C-to-be-used-with-Python code: 
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.