opendemo-devel Mailing List for OpenDemo (Page 2)
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...> - 2002-04-13 08:38:19
|
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-03-12 07:01:24
|
Hello! I just had contact with Logo, who has a Q3A demo competition site at http://q3abc.neora.ru/cgi-bin/q3bc.pl?w_m=q3adq&w_l=en His problem is, that he can't be sure, if the demo files on his site are faked (recorded with timescale, bots on a lower skill than reported or the like). The obvious solution would be to go to a similar format as it was used in DOOM: LMP. In such a file, only actual player actions were recorded but all monster movements (or in the current case: bot movements) will be recalculated on replay time. Would it be possible to store only the <player> tags in OD files during record mode (the easy part) and reactivate the bot code or more general everything but get the player input from the XML file (the difficult part)? Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-31 11:00:17
|
Hello! Please have a look at http://tremulous.sourceforge.net/junk/Q3A-source/ There is a tar.gz file for Linux with the game source code. It refers to http://www.icculus.org/~phaethon/q3/q3asm-turbo/q3asm-turbo.html where a faster version of q3asm is created. Maybe this other toolset will remove our problems with QVM or at least we have someone outside id Software to discuss the "return value problem". Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-30 20:37:06
|
Hello! On Wed, Jan 30, 2002 at 06:42:08PM +0100, Dr. Uwe Girlich wrote: > I'm currently hunting for compiler warnings from GCC. It may be, that we > just overlooked some strange warning, which could cause all our current > problems. I just corrected a few small int/size_t comparision problems but > they are not so severe. I corrected some more things. The number of warnings goes down considerably but QVM can't play gz files after all. It's really frustrating. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-30 17:41:36
|
Hello!
I'm currently hunting for compiler warnings from GCC. It may be, that we
just overlooked some strange warning, which could cause all our current
problems. I just corrected a few small int/size_t comparision problems but
they are not so severe.
But what about the macro
#define OD_ENTISACTIVE(ent) \
((ent)->r.linked \
&& !((ent)->r.svFlags & SVF_NOCLIENT) \
&& (((ent)->r.svFlags & (SVF_BROADCAST|SVF_PORTAL)) || (ent)->s.modelindex \
|| (ent)->s.event || (ent)->s.loopSound) || (ent)->s.eType)
Is this correct? We have in effect
A && !B && C || D
I would really appreciate some parentheses. My C book tells me, that && is
more important than ||, so we have
( A && !B && C ) || D
Was this the desired?
Bye, Uwe
|
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-24 17:53:49
|
Hello! Just for completeness: the assembler language for QVM is the standard internal LCC assembler language (double and short and byte are removed). It is described in the LCC book or shortly in http://research.microsoft.com/~drh/pubs/interface4.pdf Bye, Uwe |
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-24 14:05:37
|
>> One major obstacle is the map hub3tourney1 used in odprofile.odq3a for >> profiling under Windows. I could not find it in all my pk3 files (original >>Q3A >> Linux installation CD, upgraded until 1.30). In pak0.pk3 I found the file >> maps/q3tourney1.bsp. Is this the same? >Maybe it came with Q3A Team Arena (which I don't have)? No, it's a custom map (my fault). I'll re-record on q3dm17 |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-24 09:22:23
|
Hello! > What would > be more interesting is where return pointers and return values are stored, > as they apparently aren't stored in the same place as local variables and > function parameters. Totally correct. Function parameters are stored relative to some thing called "Frame Pointer". ADDRFP4 0 is the first argument of a function. Local variables are stored relative to some other thing called "Local Pointer". ADDRLP4 0 is the first local variable. Return values are stored on the normal calculation stack. But both the calling and called function must work together: we have CALLV to call a void function and CALLI4 to call a function, which returns an integer (and CALLU4 for unsigned etc.). Then we have RETI4 to return an integer. A strange thing is, that after all CALLV statements comes a pop, which would mean, that even a void function returns something but I looked at the asm of void functions and they simply end with "endproc localspace framespace". May it be, that void functions do not work at all? Then I found at least one place (I did not especially look for it) in zlib, where framespace was 4 (bytes) but we had 2 arguments (8 bytes). Strange indeed! So we have first the problem, that we need ALWAYS and in EVERY case the CORRECT prototype for ANY function call. I'll do some automatic post-processing of the asm files to look from more inconsistencies. What happens, if the compiler issues the warning: unused function parameter? Will the space for it removed but all calling functions don't know about this decision! > >From what I remember, wbxml only stores XML structure data binary, so for > example: > <origin index="123">456</origin> This particular tag would result in 1 byte for "origin with attributes and content", one byte for "index", then one byte encoding and 3 bytes "123", then 1 byte attribute end, one byte for "text", one byte encoding, 3 bytes for "456" and one byte "tag-end". So we get 1 1 1 3 1 1 1 3 1 = 13 bytes (text XML is 22 bytes). Bye, Uwe |
|
From: Conor D. <co...@ma...> - 2002-01-24 03:25:57
|
Hello, > Hello! > > On Tue, Jan 22, 2002 at 12:27:46AM -0600, Conor Davis wrote: > > I've pretty much given up on getting zlib to work with qvm files, especially > > with the garbage return value bug. I started to do a bunch of hacks the > > stored return values in global variables, but that addresses the symptoms > > and not the problem. Anyway, in my testing I've found that the qvm maximum > > stack size seems to be 512K (after that quake3 crashes). I suspected that > > zlib was exceeding the maximum stack size, but with 512K it looks doubtful. > Enough is enough. Now I look in the created asm files and learn this asm > language. It can't be more difficult than any other assembler language. After > that I'll write a tool calculate the maximum used stack frame. Unless qvm asm is very different from native code, the stack size should be about the same between qvm and native code. It seems like there should be a tool that does this for 'real' programs, but I didn't find one. What would be more interesting is where return pointers and return values are stored, as they apparently aren't stored in the same place as local variables and function parameters. It boggles my mind as to how they could get corrupted. > > Instead of zlib, maybe we should use a binary XML format similar to wbxml? > Why not the unchanged wbxml? As far as I can remember, the Java code in > opendemo/tools/com/machinima/opendemo > contains a fully working xml text <-> wbxml converter. It was one of the first > things I did for OpenDemo. The only thing to correct it the tag string <-> code > table. From what I remember, wbxml only stores XML structure data binary, so for example: <origin index="123">456</origin> the numbers would still be encoded as text. I was thinking of something where you feed the parser a schema (that specifies datatypes), and it could store numbers as binary. However, this whole binary XML thing should be a last resort if we can't get zlib to work, or if it is not fast enough. Then we would have to decide which is more desirable: an arcane compression format or an arcane binary XML format. -Conor |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-23 21:13:19
|
Hello! > documented but it works. I'm working on a test/profil/odprofile.sh shell > script to start profiling. Checked in. A first result (with an own recording) is attached. I switched off all the tracing stuff currently in CVS. > One major obstacle is the map hub3tourney1 used in odprofile.odq3a for > profiling under Windows. I could not find it in all my pk3 files (original Q3A > Linux installation CD, upgraded until 1.30). In pak0.pk3 I found the file > maps/q3tourney1.bsp. Is this the same? Maybe it came with Q3A Team Arena (which I don't have)? Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-23 20:43:56
|
Hello! Profiling under Linux comes along nicely. You only need to set the environment variables LD_PROFILE and LD_PROFILE_OUTPUT. It is nearly nowhere documented but it works. I'm working on a test/profil/odprofile.sh shell script to start profiling. One major obstacle is the map hub3tourney1 used in odprofile.odq3a for profiling under Windows. I could not find it in all my pk3 files (original Q3A Linux installation CD, upgraded until 1.30). In pak0.pk3 I found the file maps/q3tourney1.bsp. Is this the same? Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-22 07:18:32
|
Hello! On Tue, Jan 22, 2002 at 12:27:46AM -0600, Conor Davis wrote: > I've pretty much given up on getting zlib to work with qvm files, especially > with the garbage return value bug. I started to do a bunch of hacks the > stored return values in global variables, but that addresses the symptoms > and not the problem. Anyway, in my testing I've found that the qvm maximum > stack size seems to be 512K (after that quake3 crashes). I suspected that > zlib was exceeding the maximum stack size, but with 512K it looks doubtful. Enough is enough. Now I look in the created asm files and learn this asm language. It can't be more difficult than any other assembler language. After that I'll write a tool calculate the maximum used stack frame. > Instead of zlib, maybe we should use a binary XML format similar to wbxml? Why not the unchanged wbxml? As far as I can remember, the Java code in opendemo/tools/com/machinima/opendemo contains a fully working xml text <-> wbxml converter. It was one of the first things I did for OpenDemo. The only thing to correct it the tag string <-> code table. > It could even speed things up, since we could store numbers in binary > instead of text. No more strcmp(). Yeah! But the main point is, that we can use the already existing XML framework and only have to switch the lowest layer: od_xml_read.c or even better, we detect the file format by reading 1 byte. If it is '<', we assume plain text XML, if it is not, it must be wbxml. But the zlib code should stay there, at least for native code. > I reduced the number of demo states from 16 to 1, which reduced the memory > footprint from 11 megs to 3 megs. The file format is unchanged for now (I > plan to mess with it soon). Please do it soon. I intend to come up with a RtCW release shortly after the SDK release for RtCW and we can't change the format too often afterwards. Bye, Uwe |
|
From: Conor D. <co...@ma...> - 2002-01-22 06:27:53
|
Hello, I've pretty much given up on getting zlib to work with qvm files, especially with the garbage return value bug. I started to do a bunch of hacks the stored return values in global variables, but that addresses the symptoms and not the problem. Anyway, in my testing I've found that the qvm maximum stack size seems to be 512K (after that quake3 crashes). I suspected that zlib was exceeding the maximum stack size, but with 512K it looks doubtful. Instead of zlib, maybe we should use a binary XML format similar to wbxml? It could even speed things up, since we could store numbers in binary instead of text. I reduced the number of demo states from 16 to 1, which reduced the memory footprint from 11 megs to 3 megs. The file format is unchanged for now (I plan to mess with it soon). -Conor |
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-21 12:47:26
|
Oops, forgot to attach. ----- Original Message ----- > Did profile with gzipped odemo. (odLogPrintf() is still here) -------- - Eugene 'HMage' Bujak |
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-20 13:00:51
|
Did profile with gzipped odemo. (odLogPrintf() is still here) -------- - Eugene 'HMage' Bujak |
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-20 12:33:05
|
Profile: Function timing, sorted by time
Date: Sun Jan 20 15:18:03 2002
Program Statistics
------------------
Command line at 2002 Jan 20 15:16: quake3.exe +set fs_game opendemo =
+set r_mode 0 +set r_fullscreen 0 +exec odprofile.cfg
Total time: 8793,395 millisecond
Time outside of functions: 4989,886 millisecond
Call depth: 16
Total functions: 1417
Total hits: 8786574
Function coverage: 8,1%
Overhead Calculated 5
Overhead Average 5
Module Statistics for qagamex86.dll
-----------------------------------
Time in module: 3803,510 millisecond
Percent of time in module: 100,0%
Functions in module: 1417
Hits in module: 8786574
Module function coverage: 8,1%
Func Func+Child Hit
Time % Time % Count Function
---------------------------------------------------------
821,425 21,6 834,390 21,9 40371 _odpStartElement =
(odp_parse.obj)
551,539 14,5 896,092 23,6 2037568 _fbReadChar =
(od_filebuf.obj)
409,178 10,8 464,940 12,2 2862552 _fbGrow (od_filebuf.obj)
228,132 6,0 367,957 9,7 404480 _odpUpdateEntity =
(odp_main.obj)
179,660 4,7 279,967 7,4 679265 _fbSkip (od_filebuf.obj)
171,318 4,5 815,539 21,4 110023 _xmlParseName =
(od_xml_read.obj)
138,245 3,6 188,466 5,0 275042 _odmalloc (od_mem.obj)
97,127 2,6 97,127 2,6 35635 _odSetField =
(od_fields.obj)
84,341 2,2 3610,048 94,9 160785 _xmlParseText =
(od_xml_read.obj)
83,232 2,2 367,710 9,7 80392 _xmlParseCharacters =
(od_xml_read.obj)
70,869 1,9 70,869 1,9 24175 _trap_LinkEntity =
(g_syscalls.obj)
70,103 1,8 224,528 5,9 169287 _xmlSkipWhiteSpace =
(od_xml_read.obj)
68,889 1,8 1974,693 51,9 40371 _xmlParseStartTag =
(od_xml_read.obj)
59,792 1,6 79,871 2,1 145719 _fbRead (od_filebuf.obj)
56,858 1,5 56,858 1,5 275025 _odfree (od_mem.obj)
55,328 1,5 55,328 1,5 381 _trap_FS_Read =
(g_syscalls.obj)
53,468 1,4 78,336 2,1 160785 _fbEOF (od_filebuf.obj)
50,919 1,3 418,876 11,0 395 _odpUpdateEntities =
(odp_main.obj)
50,195 1,3 50,195 1,3 275042 _odShrinkBlock =
(od_mem.obj)
44,239 1,2 44,239 1,2 1 _odDemoInit =
(od_utils.obj)
38,038 1,0 235,224 6,2 29632 _xmlParseAttValue =
(od_xml_read.obj)
36,317 1,0 3733,208 98,2 397 _xmlParseLoop =
(od_xml_read.obj)
35,221 0,9 1084,372 28,5 40020 _xmlParseEndTag =
(od_xml_read.obj)
33,208 0,9 120,525 3,2 150494 _mbResize (od_membuf.obj)
31,330 0,8 31,330 0,8 3160 _trap_SetBrushModel =
(g_syscalls.obj)
30,969 0,8 533,611 14,0 29632 _xmlParseAttribute =
(od_xml_read.obj)
30,267 0,8 122,495 3,2 110122 _mbAppend (od_membuf.obj)
30,017 0,8 87,318 2,3 110375 _odrealloc (od_mem.obj)
26,973 0,7 609,650 16,0 40371 _odpEndElement =
(odp_parse.obj)
24,995 0,7 24,995 0,7 161346 _gzeof (gzio.obj)
20,292 0,5 20,292 0,5 103427 _odpAdjustRecordTime =
(odp_main.obj)
11,051 0,3 11,051 0,3 1 _dllEntry =
(g_syscalls.obj)
10,989 0,3 22,579 0,6 29634 _mbFree (od_membuf.obj)
10,904 0,3 29,949 0,8 29634 _mbCreate (od_membuf.obj)
10,506 0,3 10,506 0,3 29633 _xmlGetAttValue =
(od_xml_read.obj)
9,457 0,2 22,770 0,6 29985 _fbCmp (od_filebuf.obj)
8,972 0,2 9,888 0,3 25280 _odpUpdatePlayer =
(odp_main.obj)
8,956 0,2 8,956 0,2 27625 _odpEntityHasEvent =
(odp_main.obj)
8,499 0,2 63,605 1,7 35696 _odpCharacters =
(odp_parse.obj)
8,090 0,2 8,094 0,2 1 _inflate_blocks_free =
(infblock.obj)
7,158 0,2 8,217 0,2 3160 _Com_sprintf =
(q_shared.obj)
5,740 0,2 15,628 0,4 395 _odpUpdatePlayers =
(odp_main.obj)
3,518 0,1 79,176 2,1 1 _odpInitGame =
(odp_main.obj)
2,206 0,1 2,206 0,1 2765 _trap_Cvar_Update =
(g_syscalls.obj)
2,127 0,1 2,127 0,1 2985 _odpEntitySetActive =
(odp_main.obj)
1,611 0,0 1,611 0,0 386 _odpFollowerEndFrame =
(odp_client.obj)
1,095 0,0 3,301 0,1 395 _odUpdateCvars =
(od_main.obj)
1,059 0,0 1,059 0,0 3160 _Q_strncpyz =
(q_shared.obj)
0,988 0,0 3791,825 99,7 873 _od_vmMain (od_main.obj)
0,770 0,0 3706,129 97,4 395 _odpRunFrame =
(odp_main.obj)
0,697 0,0 3787,373 99,6 873 _odp_vmMain =
(odp_main.obj)
0,677 0,0 0,677 0,0 232 _trap_GetUsercmd =
(g_syscalls.obj)
0,634 0,0 3792,459 99,7 873 _vmMain (g_main.obj)
0,607 0,0 0,607 0,0 1559 _odpPlayerHasEvent =
(odp_main.obj)
0,575 0,0 1,252 0,0 232 _odpClientThink =
(odp_client.obj)
0,417 0,0 0,417 0,0 318 _trap_UnlinkEntity =
(g_syscalls.obj)
0,403 0,0 0,403 0,0 2 _trap_FS_FOpenFile =
(g_syscalls.obj)
0,386 0,0 0,386 0,0 790 _odFindState =
(od_utils.obj)
0,296 0,0 55,620 1,5 383 _gzread (gzio.obj)
0,275 0,0 0,275 0,0 1 _trap_Printf =
(g_syscalls.obj)
0,258 0,0 55,586 1,5 381 _odfread (od_fileio.obj)
0,230 0,0 3707,150 97,5 395 _odpReadSnapshot =
(odp_parse.obj)
0,221 0,0 0,221 0,0 23 _trap_SendServerCommand =
(g_syscalls.obj)
0,216 0,0 0,216 0,0 41 _trap_SetConfigstring =
(g_syscalls.obj)
0,210 0,0 1,821 0,0 386 _odpClientEndFrame =
(odp_client.obj)
0,210 0,0 3711,716 97,6 396 _xmlResume =
(od_xml_read.obj)
0,168 0,0 0,168 0,0 2 _trap_FS_FCloseFile =
(g_syscalls.obj)
0,142 0,0 0,161 0,0 4 _odcalloc (od_mem.obj)
0,135 0,0 0,135 0,0 255 =
_trap_AdjustAreaPortalState (g_syscalls.obj)
0,096 0,0 0,096 0,0 396 _xmlPause =
(od_xml_read.obj)
0,085 0,0 3,386 0,1 395 _odRunFrame (od_main.obj)
0,070 0,0 0,070 0,0 241 _odpBotAIStartFrame =
(odp_main.obj)
0,050 0,0 0,050 0,0 7 _trap_Cvar_Register =
(g_syscalls.obj)
0,033 0,0 0,058 0,0 43 _odstrdup (od_mem.obj)
0,028 0,0 0,079 0,0 1 _odInitGame (od_main.obj)
0,027 0,0 0,027 0,0 1 _odInitPool (od_mem.obj)
0,026 0,0 0,026 0,0 4 _trap_Cvar_Set =
(g_syscalls.obj)
0,022 0,0 22,873 0,6 1 _odpReadDemo =
(odp_parse.obj)
0,018 0,0 0,230 0,0 18 _odpHandleServerCommand =
(odp_main.obj)
0,017 0,0 0,673 0,0 1 _fbCreate =
(od_filebuf.obj)
0,015 0,0 0,073 0,0 1 _xmlParseDocTypeDecl =
(od_xml_read.obj)
0,012 0,0 22,403 0,6 1 _xmlParseFile =
(od_xml_read.obj)
0,008 0,0 0,649 0,0 1 _gz_open (gzio.obj)
0,007 0,0 0,174 0,0 1 _inflateInit2_ =
(inflate.obj)
0,006 0,0 0,006 0,0 1 =
_trap_Cvar_VariableIntegerValue (g_syscalls.obj)
0,005 0,0 0,280 0,0 1 _G_Printf (g_main.obj)
0,005 0,0 0,005 0,0 1 _crc32 (crc32.obj)
0,005 0,0 0,654 0,0 1 _gzopen (gzio.obj)
0,005 0,0 0,165 0,0 1 _inflate_blocks_new =
(infblock.obj)
0,004 0,0 0,004 0,0 1 _trap_LocateGameData =
(g_syscalls.obj)
0,003 0,0 0,003 0,0 1 _trap_SendConsoleCommand =
(g_syscalls.obj)
0,003 0,0 8,220 0,2 1 _destroy (gzio.obj)
0,003 0,0 0,020 0,0 1 _odpClientBegin =
(odp_main.obj)
0,003 0,0 0,537 0,0 2 _odfopen (od_fileio.obj)
0,002 0,0 8,096 0,2 1 _inflateEnd (inflate.obj)
0,002 0,0 0,193 0,0 1 _xmlParseXMLDecl =
(od_xml_read.obj)
0,002 0,0 0,263 0,0 1 _get_byte (gzio.obj)
0,002 0,0 0,171 0,0 2 _odfclose (od_fileio.obj)
0,001 0,0 0,001 0,0 3 _inflate_blocks_reset =
(infblock.obj)
0,001 0,0 0,001 0,0 1 _odpFollowPlayer =
(odp_client.obj)
0,001 0,0 0,028 0,0 1 _odpShutdownGame =
(odp_main.obj)
0,001 0,0 0,001 0,0 2 _xmlStop =
(od_xml_read.obj)
0,001 0,0 8,223 0,2 1 _fbFree (od_filebuf.obj)
0,001 0,0 0,263 0,0 1 _check_header (gzio.obj)
0,001 0,0 8,221 0,2 1 _gzclose (gzio.obj)
0,001 0,0 0,001 0,0 1 _odpClientConnect =
(odp_main.obj)
0,001 0,0 0,162 0,0 4 _zcalloc (zutil.obj)
0,001 0,0 0,003 0,0 4 _zcfree (zutil.obj)
0,001 0,0 0,284 0,0 1 _odpEndDocument =
(odp_parse.obj)
0,001 0,0 8,507 0,2 1 _xmlEnd (od_xml_read.obj)
0,000 0,0 0,000 0,0 1 _inflateReset =
(inflate.obj)
0,000 0,0 0,000 0,0 1 _odftell (od_fileio.obj)
0,000 0,0 0,000 0,0 1 _odpClientUserinfoChanged =
(odp_main.obj)
0,000 0,0 4,796 0,1 1 _odpReadGameState =
(odp_parse.obj)
0,000 0,0 0,015 0,0 1 _odpStartDocument =
(odp_parse.obj)
|
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-20 02:56:28
|
> To make OpenDemo more attractive for Machinima, we need something between > fixed camera and free fly camera. > We could overcome this problem in small steps: > * run-time change from free-fly to camera fixed on "player 0 view" and back > from the client side (some impulse command) > * let the server initiate this change. > * new opendemo XML tag to initiate this change. The XML tag something to 'change point of view to' could be easier to understand for machinima artists and will give them more artistic power. The data specified by this tag theoretically should accept entity number to follow, or fixed point in space (with, or without transition between old and new positions). I remember using keygrip and the key features it had, so I feel like that if we put the feature this way, we will be at best. -------- - Eugene 'HMage' Bujak |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-19 17:32:45
|
Hello! I just played through the Linux RTCW spdemo. They don't have demo recording at all -> good for us, we can provide it. They use native shared libraries only -> bad for us; but I think, that the binary program wolfsp.x86 itself can load qvm files. The cinematics are made with scripts but the camera paths are read in from a binary file. To create something like the opening scene, an external camera path editor is needed. What a patch work! Isn't it much easier to have a spline or a similar interpolation function for the camera movement? I can't wait for the source code! Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-18 13:26:21
|
Hello!
To make OpenDemo more attractive for Machinima, we need something between
fixed camera and free fly camera. Viewer controlled camera is great (it is a
totally new concept never seen in any art form before) but it gives too much
freedom. The viewer has somehow to guess, where the plot actually will take
place. If he doesn't, he wont see anything of the movie at all, because he is
always in the wrong room. Any ideas?
We could overcome this problem in small steps:
* run-time change from free-fly to camera fixed on "player 0 view" and back
from the client side (some impulse command)
* let the server initiate this change.
* new opendemo XML tag to initiate this change.
Then an director could bring the viewer into the right room, where the plot
starts and then let him fly free if he wants to. If the action changes over
into another room, the camera is again fixed onto player 0. A small nice
model of a camera at the position of player 0 (the camera man) visible in
free-fly mode would be great too.
Bye, Uwe
|
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-18 13:24:05
|
Hello! On Thu, Jan 17, 2002 at 08:00:33PM +0700, Eugene 'HMage' Bujak wrote: > > It is a system that allows live > > spectating of quake3 matches, where clients connect to one of many > > spectator-servers, which are in turn linked to the server that actually > > hosts the match. Some hints on the GamersTV system: the current version uses the original id Software code, which means they incorporated the original server and client code in a small command line oriented program. All internal game states are kept, somehow reworked and forwarded. The network protocol is always the original Q3A spectator protocol. > > Do you guys think this is a long-term goal worth pursuing? > It definetly is worth pursuing. As ideal, I think we need at least reach the > level of HLTV first. As I understand it, HLTV is basically the same thing as GamersTV: a standalone proxy application, which acts as server and client simultaniously but the supported game is HalfLife. Please keep in mind, that Martin Otten is involved in both projects. > In details, we will need an external application that connects to the server > and relays in our opendemo format (compressed with zlib) between chains and So we need to decode the Q3A protocol from the client point of view. This won't work with open CVS development. > client being able to control Point of View and fly spectating, while no > client-side modifications will be required -- this is our rule #1: Do not > modify cgame if it is definetly impossible to do server-side only. And here we have to pose as a real Q3A server. The same problem with open source: don't explain how Q3A network protcol works. If we want to incorporate at least a bit of this, we can use the same principle, which I used in DEMcut: http://www.planetquake.com/demospecs/lmpc-stable/lmpc-4.html In chapter 4.3 I propose named pipes (is now a similar concept in Windows available?) to transfer data between a stand-alone program and a file-reading Quake-program. But anyway, we can't compete with GamerTV or HLTV because both are based upon the original source code of the game and can so use all functionality already available and we have only the small number of available trap_* functions to interact with the main program. > Explanation: this is a rule that motivates to be creative, thus making > something impossible, and we will have great feedback (not near from instant, > mind you) by closely following the rule - client will not have to download any > client-side programs to use opendemo and opendemo-using projects. This was never disputed: cgame should't be changed at all and currently we follow this rule. Bye, Uwe |
|
From: Dr. U. G. <Uwe...@ph...> - 2002-01-17 21:25:20
|
Hello! On Thu, Jan 17, 2002 at 01:20:04AM -0600, Conor Davis wrote: > ... I would like to have a > list that sends an email for every cvs commit. Done. In the current implementation it even sends out full diffs for all changed files. Do we really need that much traffic? Bye, Uwe |
|
From: Conor D. <co...@ma...> - 2002-01-17 21:16:54
|
----- Original Message ----- From: "Eugene 'HMage' Bujak" <hm...@ma...> To: "OpenDemo Development List" <ope...@li...> Sent: Thursday, January 17, 2002 7:00 AM Subject: Re: [opendemo-devel] GamersTV > [...] > > Do you guys think this is a long-term goal worth pursuing? > > It definetly is worth pursuing. As ideal, I think we need at least reach the > level of HLTV first. > > In details, we will need an external application that connects to the server > and relays in our opendemo format (compressed with zlib) between chains and > client being able to control Point of View and fly spectating, while no > client-side modifications will be required -- this is our rule #1: Do not > modify cgame if it is definetly impossible to do server-side only. Why not? If somebody wants to watch a match using the hypothetical mod ClanMatch, then they would need the ClanMatch cgame module to render things properly. Since ClanMatch's game module includes opendemo code, why couldn't its cgame module also include opendemo code? The only problem is with the vanilla (baseq3) modules. We can probably make it work either way (i.e. you get extra features if your cgame has opendemo code in it). -Conor |
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-17 13:13:01
|
Hello, > > I just analysed the crashing behaviour of the QVM code on playback of > > compressed files. It is really strange. The attached patch file adds a > mini > > trace to the first call of fbReadChar, which get the character '<', as we > all > > would expect. But the calling function xmlParseText get another return > value. > > Ok this is driving me crazy. If vm_game is 1, then I don't get the bug you > described, but I do get the ~ operator bug. If vm_game is 2, then I do get > the bug you described (with the return value of gzread, it crashes before > fbReadChar exits), but I don't get the ~ operator bug. I fixed the ~ bug, > but nothing I do fixes the return value bug. Perhaps the virtual machine's > frame pointer is getting corrupted somehow? I have no idea how to test for > this. The same happens with string manipulation when trying to attach an extension to odemo filename, after copying it from cvar value, but the cvar reading returns empty string, or some other random string from the memory. Definetly looks like the frame pointer is messed somehow... Perhaps we need to mail id? ------ - Eugene 'HMage' Bujak |
|
From: Eugene 'H. B. <hm...@ma...> - 2002-01-17 13:00:41
|
> It is a system that allows live > spectating of quake3 matches, where clients connect to one of many > spectator-servers, which are in turn linked to the server that actually > hosts the match. > Do you guys think this is a long-term goal worth pursuing? It definetly is worth pursuing. As ideal, I think we need at least reach the level of HLTV first. In details, we will need an external application that connects to the server and relays in our opendemo format (compressed with zlib) between chains and client being able to control Point of View and fly spectating, while no client-side modifications will be required -- this is our rule #1: Do not modify cgame if it is definetly impossible to do server-side only. Explanation: this is a rule that motivates to be creative, thus making something impossible, and we will have great feedback (not near from instant, mind you) by closely following the rule - client will not have to download any client-side programs to use opendemo and opendemo-using projects. I hope you understand what I mean, because English is not my first language, if something is not clear, ask. ------ - Eugene 'HMage' Bujak |
|
From: Conor D. <co...@ma...> - 2002-01-17 07:19:49
|
Uwe, can you set up what is described in this page? I would like to have a list that sends an email for every cvs commit. http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1 -Conor |
