opendemo-devel Mailing List for OpenDemo
Status: Beta
Brought to you by:
girlich
Menu
▾
▴
opendemo-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(12) |
Oct
(7) |
Nov
(2) |
Dec
(10) |
| 2002 |
Jan
(52) |
Feb
|
Mar
(1) |
Apr
(6) |
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dr. U. G. <Uwe...@ph...> - 2004-02-23 09:46:40
|
Hello! The new implementation of the odfile interface is based on XML::Parser, which is a small layer around Expat. The old one was based on XML::DOM, which also uses XML::Parser for XML parsing but has an object interface written totally in Perl. A short performance test on a 800MHz Duron: echo q | time ./odcut.pl ../../test/profile/odprofile.odq3a -f dom 40.81user 3.18system 0:49.62elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (492major+32016minor)pagefaults 0swaps echo q | time ./odcut.pl ../../test/profile/odprofile.odq3a -f parser 8.72user 0.65system 0:10.02elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (489major+12125minor)pagefaults 0swaps Thus reading in a 3115634 bytes XML file goes from 40.81 seconds down to mere 8.72 seconds, which results in a speedup factor of 4.68. Then I checked the more important frame output time: ./odcut.pl ../../test/profile/odprofile.odq3a -f dom -l 10 b r 0 1 i 1 show in the logging, that the avagage wait time is -0.12 seconds (the system is too slow to print even frame 1 in time). The calculation time was 0.050 - ( -0.12) = 0.170 On the other hand ./odcut.pl ../../test/profile/odprofile.odq3a -f parser -l 10 b r 0 1 i 1 show in the logging, that the avagage wait time is 0.025 seconds. The calculation time was 0.050 - 0.025 = 0.025 seconds, which results in a speedup factor of 6.8. As much as I'm happy about this, it is not enough. Frame 0 is a more complete frame and it takes 0.050 - (-0.14) = 0.19 seconds even with -f parser (-f dom was totally inacceptable with a calc time of over a whole second). When I shall implement on-the-fly delta-compression, there is much more to do that the calculation of frame 0. I'll repeat these tests later today at home on a fater system but it seems to become clear: I have to go back to plain C for this. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2004-02-09 11:59:34
|
Hello! Here are the next few things about ODcut (copied out of my .plan on machinima.com): ODcut, the simple OpenDemo file cutter program just reached the prototype state. It is written in plain Perl and uses XML::DOM for XML file manipulating and WxPerl (and with it WxWindows) for the GUI. A plain console mode like in demcut is also available. It is already checked into CVS and needs the current OpenDemo from CVS (the binary release opendemo-20031008 is too old). It can cut and paste (with frame accuracy) parts of different OpenDemo files into one. These parts may be played back backwards. There is a real time preview window (Q3A will be remote controlled much like in KeyGrip2) and a simple slider to seek through the input file. It works currently with Linux and Q3A. The other games will follow. Windows will follow, if I learn how a named pipe and symbolic links work there. It does not do any delta expansion and re-compression yet (OpenDemo files are delta encoded) but this is the next task, which must be done in C (Perl is a bit too slow for real time sensitive things) and SAX (DOM is too slow at comparing 2 document sub-trees). Bye, Uwe |
|
From: Dr. U. G. <gi...@ph...> - 2004-01-07 10:28:40
|
Hello! Just to keep a record of all my holiday changes: tools/odcut/odcut.pl is a really similar replacement for DEMcut from the old Quake1 days. It understands almost the same commands and can write to a named pipe or a file. It is written purely in Perl. The core XML functionality is in tools/odcut/odfile.pm and is currently too slow (DOM is too complicated for our simple needs). I think about a C reimplementation as a Perl module (something I never did before but need to learn anyway) using SAX. Features: * read in OpenDemo files * switch between these demo files * close OpenDemo input files * select the output file (or pipe) * write the XML header * write a single frame from the current input file * write a range of frames from the current input file * range can be played forward and backwards * write the XML footer * output frames are manipulated, so that the sequence number is increased every time a frame is written * output frames are manipulated, so that the time of the frame is increased by the length of the previous frame * output frames are manipulated, so that all absolute times in a frame have the same difference to the frame time in the output file as they had in the input file * interactive mode waits the correct amount of time to synchronize written output with the time mentioned in the frames * interactive mode repeats the last output frame over and over but corrects (as usual) the sequence number and the time Missing: * delta decompression is already started but does not work. * delta compression is not started at all. The interactive mode makes it easy to let odcut.pl write into a named pipe and let Q3A+OpenDemo read from this pipe. In this way Q3A+OpenDemo can be remote controlled (similar to what KeyGrip2 does). I already started a WxPerl based GUI for all this. It does not do anything useful yet but the graphical elements are almost all there and event handlers are connected to the various buttons. Before I forget it, odcut.pl can write to a pipe but OpenDemo must be compiled from CVS to get the pipe reading feature. The last binary release of OpenDemo can only read in a normal file edited with odcut.pl. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2003-12-01 08:02:43
|
Hello! > I have no idea, if Q3A can even read from a named pipe ... It can. > The next step is to remove optionally (with a new console variable) called od_pipe > all tests on the file end (comparisons with stream->len). Thus odfread() may > block but the external program will feed in always new data anyway. When > these comparisons are gone, I'll try 'cat odfile.xml > pipe.odq3a' and let > Q3A replay 'pipe.odq3a'. It works with the current CVS source. In tools/odcut I just started a small OD file editor. The Perl module odfile.pm can read OD file, write OD files and extract (out of the internal DOM tree) the header (everything, which comes before the first <snapshot>), every single <snapshot>, and the footer (everything, which comes after the last </snapshot>). The next step is to take care of the always increasing sequence number and the time stamp in a sequence of <snapshot> elements. Then I'll code a wxPerl frontend with a slider, play backwards, pause, and play forward buttons, and a speed scale number. Only then we can seriously think about any real features of the OD editor. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2003-11-26 21:18:35
|
Hello! I intend to increase OpenDemo usage a bit more. For this I'll write a very simple demo editor over the xmas holiday. The most important thing for such an editor is a preview window, where Q3A directly plays back, what I just edited (or where I moved the timeline slider). Thus we need to feed into the OpenDemo playback mode a continous stream of data calculated by another program. The idea is to use a named pipe instead of a plain file. But now the problems start: we can't rewind a named pipe and we don't know the amount of data at the start at all. I have no idea, if Q3A can even read from a named pipe, as it has no size to begin with. To check this out I committed today and yesterday a small change to switch off the ZLIB code (at compile time and at runtime). The runtime switch off already works. The compile time switch off is not tested yet. The next step is to remove optionally (with a new console variable) all tests on the file end (comparisons with stream->len). Thus odfread() may block but the external program will feed in always new data anyway. When these comparisons are gone, I'll try 'cat odfile.xml > pipe.odq3a' and let Q3A replay 'pipe.odq3a'. If it works, we can continue with the actual work of the editor. If it does not work, we can always fall back to native shared libraries and let the C library read from the named pipe. What is the state of named pipe support in Windows? Is there finally an equivalent of the standard >20 years old 'mkfifo' command? For reference, the whole idea is a direct replica of the interactive mode of the demcut program (part of the LMPC project). Quake1 had no problem reading from a named pipe (and I even wrote a PerlTk front-end for demcut back then). Let's hope the best. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2003-02-23 14:08:50
|
Hello list! On Fri, Feb 21, 2003 at 01:17:07PM -0800, Dan Hollis wrote: > On Thu, 23 Jan 2003, Dr. Uwe Girlich wrote: > > I just checked in a change for this effect in all 5 games (tried only on > > RtCW and patched the same source everywhere else). > Does this mean you have a copy of RTCW to test with now? Exactly. Do a "cvs update" or get the binary packages from SF.net. And please use the same address for posting as you used for subscribing to this list. Bye, Uwe |
|
From: Dan H. <go...@an...> - 2003-02-21 21:18:55
|
On Thu, 23 Jan 2003, Dr. Uwe Girlich wrote: > > On Thu, Jan 23, 2003 at 12:49:00AM -0800, Dan Hollis wrote: > > > How about odr_pre_ConsoleCommand() which intercepts just the opendemo > > > console commands, and skips over the odr_vmMain() if it's intercepted > > > a command. That means you don't have to change the game code... > I just checked in a change for this effect in all 5 games (tried only on > RtCW and patched the same source everywhere else). Does this mean you have a copy of RTCW to test with now? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] |
|
From: Dr. U. G. <Uwe...@ph...> - 2003-02-01 16:28:08
|
Hello! > I just checked in a change for this effect in all 5 games (tried only on RtCW > and patched the same source everywhere else). Finally I found the time for a new binary release 20030201 with this bug fix. It's already announed at machinima.com. I also corrected some minor problems in Makefiles, wpurc, and .cvsignore. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ma...> - 2003-01-24 07:42:20
|
Hello! > On Thu, Jan 23, 2003 at 12:49:00AM -0800, Dan Hollis wrote: > > How about odr_pre_ConsoleCommand() which intercepts just the opendemo > > console commands, and skips over the odr_vmMain() if it's intercepted > > a command. That means you don't have to change the game code... I just checked in a change for this effect in all 5 games (tried only on RtCW and patched the same source everywhere else). Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2003-01-23 09:05:43
|
Hello Dan! On Thu, Jan 23, 2003 at 12:49:00AM -0800, Dan Hollis wrote: > How about odr_pre_ConsoleCommand() which intercepts just the opendemo > console commands, and skips over the odr_vmMain() if it's intercepted > a command. That means you don't have to change the game code... That's it! Why I didn't think of it? It will add the additional overhead of 2 strcmp() functions to every console command but I think this is not that performace sensitive anyway. Oh, and BTW, only subscribers to opendemo-devel can post there and you wrote a mail from go...@an... but are subscribed with another name. Bye, Uwe |
|
From: Dan H. <go...@an...> - 2003-01-23 08:49:32
|
On Thu, 23 Jan 2003, Dr. Uwe Girlich wrote:
> Here we have the problem, that this must be updated, if the corresponding code
> in g_svcmds.c/ConsoleCommand() will be changed. The other possibility would be
> to remove the additional test in odr_main.c/odr_vmMain() and always call
> odr_post_ConsoleCommand(). So we would not have to change anything in
> g_svcmds.c but we would get all odrecord and odstop commands as "server say"
> output too.
How about odr_pre_ConsoleCommand() which intercepts just the opendemo
console commands, and skips over the odr_vmMain() if it's intercepted
a command. That means you don't have to change the game code...
Still, I don't think it's too bad to do:
if (0 && g_dedicated.integer)
And then implement "say" in odr_post_ConsoleCommand().
It's the least ugly and most efficient solution to my eyes.
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
|
|
From: Dr. U. G. <gi...@ph...> - 2003-01-23 08:10:37
|
Hello Dan!
Dan Hollis <go...@an...> wrote:
> At the end of ConsoleCommand() in g_svcmds.c:
> if (g_dedicated.integer) {
...
> return qtrue;
> }
> And in odr_vmMain() in odr_main.c:
> case GAME_CONSOLE_COMMAND:
> result = orig_vmMain(command, arg0, arg1, arg2, arg3, a$
> if (result == qfalse)
> ^^^^^^^^^^^^^^^^
> result = odr_post_ConsoleCommand();
> This means on dedicated server, console commands will never reach
^^^^^^^^^
> odr_post_ConsoleCommand() ...
Now I understand. You are totally right.
> And I have tested it. Indeed, opendemo does not work on RTCW.
On a dedicated server, you can't type in any new command. The problem exists in
all OpenDemo versions (Q3A, ...).
The solution would be to deactivate the dedicated server check but insert it
again in odr_vmMain(). This is ugly but I have no other solution. All OpenDemo
changes should touch only the absolute minimum of lines in the base code.
Something like
g_svcmds.c/ConsoleCommand():
if (0 && g_dedicated.integer) {
...
return qtrue;
}
return qfalse;
(1 line change)
and in
odr_main.c/odr_post_ConsoleCommand():
after the block
if (Q_stricmp(str, "odstop") == 0) {
odrRecordStop();
return qtrue;
}
the new part
if (g_dedicated.integer) {
if (Q_stricmp (cmd, "say") == 0) {
trap_SendServerCommand( -1, va("print \"server: %s\"", ConcatArgs(1) ) );
return qtrue;
}
// everything else will also be printed as a say command
trap_SendServerCommand( -1, va("print \"server: %s\"", ConcatArgs(0) ) );
return qtrue;
}
Here we have the problem, that this must be updated, if the corresponding code
in g_svcmds.c/ConsoleCommand() will be changed. The other possibility would be
to remove the additional test in odr_main.c/odr_vmMain() and always call
odr_post_ConsoleCommand(). So we would not have to change anything in
g_svcmds.c but we would get all odrecord and odstop commands as "server say"
output too.
> commands never reach opendemo code, so you can't start or stop recording.
Exactly. But it works as it should on a normal player server, which I checked
just yesterday evening.
Bye, Uwe
|
|
From: Dan H. <go...@an...> - 2003-01-12 16:03:00
|
It seems this project is dead... Also, rtcw opendemo doesn't work... looking at the source code, I can't see that it ever could have worked :-) :-o -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-] |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-07-01 05:40:12
|
Hello! There was a new source release 1.33 for RtCW lately and I had to rebase the OpenDemo code to this new level. During this process I found, that game/bg_lib.c was not yet patched, so that floating point variables were printed without fractional part and %.*s was also not implemented. That is the problem, if you have 5 really similar source trees. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-06-18 15:57:10
|
Hello all! The new release 20020618 at https://sourceforge.net/project/showfiles.php?group_id=6195&release_id=95434 has binary packages for all 5 supported games: * JK2 * Q3A * RtCW * SOF2 * STEF I'd be glad, if someone other than me would try them out too. The source code package is now >5MB. It may be better to spread the source over the different binary packages? Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-06-17 06:25:36
|
Hello! I just added yesterday support for "Star Trek Voyager: Elite Force" to OpenDemo. So we support now 5 games. I really expect fan-films from Star Trek and StarWars freaks all over the world. A web page update and a binary release should follow soon. BTW, I had had many discussions with film-makers in Hamburg (Short Film Festival, Bitfilm Festival) and they saw great difficulties in writing a consistent script for a movie, where the viewer has full control over the camera. They found the idea interesting but a good script is in such a case really difficult. Another point should be, that the player follow mode should follow a person (third person view) and not look through the eyes of it. And we really need the real-time switching between spectator and player-follow- mode. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-06-06 16:05:40
|
Hello! > > I added over the week-end JK2 support in OpenDemo. The state is as follows: > > * I got the SDK2, checked in the source > > * added opendemo directory > > * made it compile cleanly (#include "..\.." -> #include "../..") > > * added hints in all the overhead files (doc, wpurc, README) > > * created the DTD > > * added some of the more important entity fields > * I bought the game and tried it out. The base CD version does not work > (totally unstable, wine crashes constantly) > * after the patch to 1.0.3 jk2mpgame.qvm with OpenDemo works. * qvm files have the right (strange) names: jk2mpgame.qvm, ui.qvm, cgame.qvm. * batch files for compiling under Windows were removed from the CVS tree, as the Makefile can create them ToDo: * I did not touch Windows project files at all. I'll give a short presentation on "Game Hacking" on the "Hamburg Short Film Festival" (www.shortfilm.com) in Hamburg next week (it starts on Saturday), so I won't be able to read & write mails for one week. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-06-06 11:36:03
|
Hello! > I added over the week-end JK2 support in OpenDemo. The state is as follows: > * I got the SDK2, checked in the source > * added opendemo directory > * made it compile cleanly (#include "..\.." -> #include "../..") > * added hints in all the overhead files (doc, wpurc, README) > * created the DTD > * added some of the more important entity fields * I bought the game and tried it out. The base CD version does not work (totally unstable, wine crashes constantly) * after the patch to 1.0.3 jk2mpgame.qvm with OpenDemo works. ToDo: * qvm files (ui and cgame) have the wrong name. * batch files for compiling under Windows aren't corrected (extended) yet. * I did not touch Windows project files at all. And BTW, the replay had not the problems of SOF2. I could see flying projectils and the change between first&third person was OK. Only a strange sphere circled around the player. I tried everything with duel_pit.bsp, which is one of the smallest BSP files of JK2 to reduce the game start and level load time. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-06-03 05:18:17
|
Hello! I added over the week-end JK2 support in OpenDemo. The state is as follows: * I got the SDK2, checked in the source * added opendemo directory * made it compile cleanly (#include "..\.." -> #include "../..") * added hints in all the overhead files (doc, wpurc, README) * created the DTD * added some of the more important entity fields I didn't check it at all. In fact, I'm not having the game yet (which will change later today). Please try it out too! BTW, it becomes more and more easy to add a new game: changes are usually: include od_public.h, one define in g_main.c (to activate the own vmMain entry), one define in g_syscalls.c (to deactivate the syscall wrappings in this file, actually it is not necessary to do it, if we can only generate qvm files) and patching bg_lib.c (for the printf extensins). That's it. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-05-27 20:14:50
|
Hello all!
I just added SOF2 support to OpenDemo. It has the following state:
1. The SOF2 SDK contains the MP code only, so I added OpenDemo to MP only.
2. MP libraries are QVM only, so I used (unter Linux) my Q3A QVM compiler
an generated the libraries.
3. gzip reading does not work (was expected).
4. Somehow the player looks distorted on replay:
o
--\--
\
/\
_/ \_
Firstly, I suspected the leaning but this works: if I lean left or
right, the player leans based on this distorted shape.
5. Flying rockets are not shown during replay.
6. Zoomed view (sniper rifle) switches to 5x, and the picture remains fixed
until and switch back to normal view, zoom factor changes and viewing
direction changes are not replayed.
7. The batch files (for compilation under Windows) are not updated accordingly.
I'll calculate them (as I do it for Q3A) with the Makefile. I did not
do it yet.
8. As usual I do everything in Linux. Sof2 runs perfectly under Wine in Linux.
We really need binary packages for all games NOW! I have them all here on my
disk (source, toolkit, Q3A bin, RTCW bin, SOF2 bin) but I remember, that there
was some discussion about an XML file format change before the next release.
What is the current state?
I would think, if we change the XML file format, we can provide easily an
XSLT stylesheet and everyone can convert the recordings with this stylesheet.
XSLT is really easy to write and use and it is supported on every OS.
Bye, Uwe
|
|
From: Conor D. <co...@ma...> - 2002-04-23 01:44:23
|
Nice work, Uwe! The sources for the different games will share some code eventually, right? I mean q3a and rtcw sharing od_xml_read.c or something. Would that make separate source packages tricky? Also, I still want to finalize the xml format before a big release (merge the 'odq3a' and 'map' tags into 1 tag, get rid of baselines). I'll try to get working on it. On Mon, Apr 22, 2002 at 01:55:53PM +0200, Dr. Uwe Girlich wrote: > Hello! > > > Now I really have to look into cross-compiling from Linux to Win32 to > > make a binary OpenDemo package possible. > I made it! The Cygwin cross compiler can create Windows DLLs, which can > be loaded into Windows RTCW. I tested it (of course) only in Wine under > Linux. That's all really sick but it works! A native compilation with the > Cygwin toolset for Windows should also be no problem. > > Now I have only to repair the last problem with the missing weapon reload > animation on replay (the reload sound is there though). > > The next step is again a binary release of OpenDemo. Should we split the > packages more? I would think we need 5 packages: > qvm toolset > q3a source > q3a binaries > rtcw source > rtcw binaries > but we have some other sources too (tools directory, Java stuff). Maybe > a 'all the rest', 'everything', or a 'all sources' package would be needed > too. > > Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-04-22 11:54:20
|
Hello! > Now I really have to look into cross-compiling from Linux to Win32 to > make a binary OpenDemo package possible. I made it! The Cygwin cross compiler can create Windows DLLs, which can be loaded into Windows RTCW. I tested it (of course) only in Wine under Linux. That's all really sick but it works! A native compilation with the Cygwin toolset for Windows should also be no problem. Now I have only to repair the last problem with the missing weapon reload animation on replay (the reload sound is there though). The next step is again a binary release of OpenDemo. Should we split the packages more? I would think we need 5 packages: qvm toolset q3a source q3a binaries rtcw source rtcw binaries but we have some other sources too (tools directory, Java stuff). Maybe a 'all the rest', 'everything', or a 'all sources' package would be needed too. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-04-15 05:39:30
|
Hello! > ... Is the game code architecture any different (as in game/cgame/ui)? It is more or less the same. Some things were removed (bg_lib.h, ID_INLINE), some things were added (additional botai directory used in game) and some other things were changed (MAX_GENTITIES, entity_t). Now I really have to look into cross-compiling from Linux to Win32 to make a binary OpenDemo package possible. Bye, Uwe |
|
From: Conor D. <co...@ma...> - 2002-04-14 21:29:37
|
Hello, It's crunch time for my classes, so I won't be able to do much until the semester is over (mid-May). I don't own or plan to buy RTCW anytime soon. Is the game code architecture any different (as in game/cgame/ui)? On Sat, Apr 13, 2002 at 10:39:50AM +0200, Dr. Uwe Girlich wrote: > Hello! > > It's been quiet lately but with the release of the RTCW code I hope we get > OpenDemo going again. Check out src/rtcw-mp! It contains the just released > public game code (only MP, as this may be the most important). I already added > a Makefile for Linux compilation. qvm cannot work (no bg_lib.h file). The next > step is to snap in all the opendemo files and zlib files. > > I think about Windows cross compilation to create the Windows DLL files with > my Linux machine. Win32 RTCW even runs under Wine, so I can check, if they > work. We need this, because we have no longer the QVM option. The other > possibility would be to copy from Q3A the missing bg_lib.h file and try it out. > The QVM virtual machine is contained in RTCW. > > Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-04-14 16:14:05
|
Hello! > The next step is to snap in all the opendemo files and zlib files. I just did this. It worked on the first try. Please could someone patch the *.dsp files as necessary? There are still people without Linux out there. Bye, Uwe |
