opendemo-devel

[opendemo-devel] download statistics

[Dr. U. G. <Uwe...@ph...>]

Hello!

Has anyone looked at the "Usage Statistics" page for OpenDemo?
https://sourceforge.net/project/stats/index.php?report=last_30&group_id=6195
We had about 80 page views on december 19, which is clearly the result of
my .plan update and the top position of the news message on machinima.com
but the download rate is really low. Maybe we should also offer zip files
for the binary package? I prefer .tar.gz files as they preserve the access
rights and are usually a bit smaller than zip but to not irritate non-unix
users, a zip file would be better.

The second point is the 25th of december. What happended then? We've got over
120 page views and even more downloads! I suspect some kind of web robot.
Any ideas?

Bye, Uwe

[opendemo-devel] performance and other issues

[Conor D. <co...@ma...>]

Hello all,

It's been a long time since I've done anything about opendemo (many
apologies, I really need to take a time management class)! Anyway, I have
about a week and half with little else to do, so I can work on opendemo for
a while.

Congrats to hmage for fixing the event time bug; I don't think I would have
found that one for a long time. However, it looks like we are using
CS_LEVEL_START when writing to xml file, and since it is defined in
bg_public.h, in theory a mod author may change/remove it and screw
everything up. I've tried to only use stuff in q_shared.h to make the file
format as flexible as possible between all the various mods. Can we move
this code into the cgame module? I think we will have to modify cgame
eventually, so why not start now?

About performance:
- the od_filebuf.c routines use a linear buffer, which now I can see is a
really stupid thing to do. It shouldn't be too hard to convert it to use a
growable circular buffer which should solve the fbReadChar problems
- I'd say the problem in odpStartElement is in the <snapshot ...> element,
with:
   *od.demo.currentState = *od.demo.deltaState;
  This copies a lot of data (half a meg) every snapshot, which is not good.
We can save some time by looping through each player and entity, and only
copy the ones which are active.

Another option is to remove the whole 16 snapshot states and force delta'ing
only from the previous snapshot (since it is recording on the server, we
don't have to worry about dropped snapshots and whatnot). This would
completely kill any chance of converting real (client-side) demos into the
xml format (I'm just guessing that they use 16 states, since q2 does that),
and would hinder recording over a network (server-to-server), but would
solve the whole copying issue. Or we could leave the 16 snapshot history in
the file format, but have odplay only use one state (the odDemo_t structure
is almost 10 megs, the 16 states take up almost all of it).

I'm looking into using zlib for compression; it doesn't look too bad if we
can emulate ANSI file i/o and dynamic memory management, which we have
already done mostly. Speed will probably be an issue (using zlib's file i/o
routines, which use the emulated file i/o routines, which use quake3's trap
file i/o routines).

Can anyone forsee using od_file*.c, od_mem*.c, or od_xml_read.c outside of a
q3 mod? I tried to make them generic so we could use them in
demo-manipulating utilities, but we could just as well use a real xml parser
(expat, libxml, java stuff) for that. od_fileio is only needed for
od_filebuf, which is only needed by od_xml_read, so if we don't need
od_xml_read for other programs, we can move them to the q3 game directory
and do away with the abstract interfaces. od_mem*.c may be useful just to
have growable character arrays.

I don't think random-access play can be done well using a qvm, since AFAIK
we would need real random file i/o and dynamic memory access for that. We
can do it, but it looks like we would have to re-open the file every time we
go backward and re-read all the snapshots until we get to the desired frame.

-Conor

Re: [opendemo-devel] Perfomance.

[Dr. U. G. <Uwe...@ph...>]

Hello!

mbSize() and mbGetBuffer() are now macros.
> from the source:
>         c = fbReadChar(doc.fb, 0);
> this line is totally useless
wrong! The next line was the problem: the macro IS_NAMESTARTCHAR used its
argument several time, so we had many calls of fbReadChar(). Now the code reads:
>         c = fbReadChar(doc.fb, 0);
>         if (!IS_NAMESTARTCHAR(c)) {
>                 doc.errNo = XML_ERR_NAME_REQUIRED;
>                 doc.errString = "Name does not start with valid character";
>                 return NULL;
>         }

> I think we should collect the characters in a local variable and simply copy
> them over after odMalloc(). fbRead() calls fbGrow() and 2 times mbSize(),
> no wonder that it takes so much time.
This is not done yet. Please perform another profiler run first.

> ... Maybe a simple
> reordering of the strcmp()s by the number of their appearance would help
> a lot.
Also not done yet. I wait for the profiler results (or profile myself, which
takes a bit more time).

Bye, Uwe

Re: [opendemo-devel] Perfomance.

[Dr. U. G. <Uwe...@ph...>]

Hello!

> ... As expected, the bottleneck is XML parsing, which is not surprising,
> lots of strcmp's in odpStartElement().
But not all will be used every time. Therefore the parser keeps its state and
does only some strcmp()s every time. I'm thinking about a hash but I really
suspect, that it should be a lot faster.

> Second function that takes much time is fbGrow(),
> third in a row is fbReadChar().
And mbSize().
This is all somehow connected:

size_t
mbSize(mb_t* mb)
{
        return mb->size;
}

There is nothing to optimize any more, so we have to use inlining or a
macro for this function.

The same holds true for
char*
mbGetBuffer(mb_t* mb)
{
        return mb->base;
}

I think these two functions should be replaced by macros.

>         Func          Func+Child           Hit
>         Time   %         Time      %      Count  Function
> ---------------------------------------------------------
>      339,888  14,3      342,367  14,4    10816 _odpStartElement (odp_parse.obj)
>      328,374  13,8      809,179  34,1   870447 _fbGrow (od_filebuf.obj)


>      302,485  12,8     1231,081  51,9   666036 _fbReadChar (od_filebuf.obj)
This is the main bottleneck!!!!!
fbReadChar() calls fbGrow(), mbSize() (should be a macro) and mbGetBuffer()
(should be a macro too).
fbGrow() calls mbSize() again.

>      245,019  10,3      245,019  10,3  1795349 _mbSize (od_membuf.obj)
>      168,478   7,1      168,478   7,1  1173068 _mbGetBuffer (od_membuf.obj)
>      148,394   6,3      148,394   6,3   390172 _trap_FS_Read (g_syscalls.obj)
>      115,466   4,9      263,860  11,1   390172 _odFread (od_q3a_fileio.obj)
>       91,773   3,9      145,829   6,1   173056 _odpUpdateEntity (odp_main.obj)

>       73,557   3,1      868,949  36,6    29724 _xmlParseName (od_xml_read.obj)
from the source:
        c = fbReadChar(doc.fb, 0);
this line is totally useless

check of the first character
        if (!IS_NAMESTARTCHAR(fbReadChar(doc.fb, 0))) {
                doc.errNo = XML_ERR_NAME_REQUIRED;
                doc.errString = "Name does not start with valid character";
                return NULL;
        }

this checks for the end but does not remember the characters
        for (len = 1; ; len++) {
                c = fbReadChar(doc.fb, len);

                if (!IS_NAMECHAR(c) || c == EOF)
                        break;
        }

now we allocate enough space
        name = (char *)odMalloc(len + 1);
and read the full name AGAIN
        fbRead(doc.fb, name, len);
        name[len] = '\0';
I think we should collect the characters in a local variable and simply copy
them over after odMalloc(). fbRead() calls fbGrow() and 2 times mbSize(),
no wonder that it takes so much time.

>        0,776   0,0     2370,985 100,0      321 _vmMain (g_main.obj)
just as expected. Your profiling tool can sum up accurately!

>        0,144   0,0     2238,701  94,4      168 _odpReadSnapshot (odp_parse.obj)
That is interesting. Most of the time, we have snaphosts. Maybe a simple
reordering of the strcmp()s by the number of their appearance would help
a lot.

I'll try to add a new profiling target to the Makefile to help profiling
under Linux (using gprof).

Bye, Uwe

[opendemo-devel] Perfomance.

[Eugene 'H. B. <hm...@ma...>]

Profile: Function timing, sorted by time
Date:    Wed Dec 26 17:37:13 2001


Program Statistics
------------------
    Command line at 2001 Dec 26 17:36: quake3.exe +set fs_game opendemo =
+set com_blindlyloaddlls 1 +set sv_pure 0 +set r_fullscreen 0 +set =
r_mode 3 +set vm_ui 0 +set vm_game 0 +set vm_cgame 0
    Total time: 4975,440 millisecond
    Time outside of functions: 2603,677 millisecond
    Call depth: 15
    Total functions: 1319
    Total hits: 6794661
    Function coverage: 7,1%
    Overhead Calculated 5
    Overhead Average 5

Module Statistics for qagamex86.dll
-----------------------------------
    Time in module: 2371,763 millisecond
    Percent of time in module: 100,0%
    Functions in module: 1319
    Hits in module: 6794661
    Module function coverage: 7,1%

        Func          Func+Child           Hit
        Time   %         Time      %      Count  Function
---------------------------------------------------------
     339,888  14,3      342,367  14,4    10816 _odpStartElement =
(odp_parse.obj)
     328,374  13,8      809,179  34,1   870447 _fbGrow (od_filebuf.obj)
     302,485  12,8     1231,081  51,9   666036 _fbReadChar =
(od_filebuf.obj)
     245,019  10,3      245,019  10,3  1795349 _mbSize (od_membuf.obj)
     168,478   7,1      168,478   7,1  1173068 _mbGetBuffer =
(od_membuf.obj)
     148,394   6,3      148,394   6,3   390172 _trap_FS_Read =
(g_syscalls.obj)
     115,466   4,9      263,860  11,1   390172 _odFread =
(od_q3a_fileio.obj)
      91,773   3,9      145,829   6,1   173056 _odpUpdateEntity =
(odp_main.obj)
      73,557   3,1      868,949  36,6    29724 _xmlParseName =
(od_xml_read.obj)
      64,467   2,7       64,467   2,7   474015 _mbResize (od_membuf.obj)
      60,038   2,5      153,244   6,5   174687 _fbSkip (od_filebuf.obj)
      41,616   1,8       41,616   1,8        1 _odDemoInit =
(od_utils.obj)
      27,564   1,2       38,976   1,6    54289 _odMalloc =
(od_q3a_mem.obj)
      27,215   1,1       27,215   1,1     9584 _trap_LinkEntity =
(g_syscalls.obj)
      25,827   1,1       25,827   1,1     9482 _odSetField =
(od_fields.obj)
      22,631   1,0     2296,217  96,8    43101 _xmlParseText =
(od_xml_read.obj)
      21,618   0,9      149,197   6,3    46074 _xmlSkipWhiteSpace =
(od_xml_read.obj)
      21,122   0,9     1241,710  52,4    10816 _xmlParseStartTag =
(od_xml_read.obj)
      19,488   0,8      235,297   9,9    21550 _xmlParseCharacters =
(od_xml_read.obj)
      19,300   0,8       34,568   1,5    29930 _mbAppend (od_membuf.obj)
      18,916   0,8       37,455   1,6    29724 _fbRead (od_filebuf.obj)
      18,863   0,8      164,692   6,9      169 _odpUpdateEntities =
(odp_main.obj)
      13,835   0,6       34,151   1,4    43099 _fbShrink =
(od_filebuf.obj)
      13,741   0,6       20,316   0,9    43099 _mbShrink (od_membuf.obj)
      13,517   0,6      124,976   5,3     8175 _xmlParseAttValue =
(od_xml_read.obj)
      13,104   0,6       13,104   0,6     1352 _trap_SetBrushModel =
(g_syscalls.obj)
      11,412   0,5       11,412   0,5    54289 _odShrinkBlock =
(od_q3a_mem.obj)
      10,518   0,4     2314,435  97,6      170 _xmlParseLoop =
(od_xml_read.obj)
      10,207   0,4       10,207   0,4    54267 _odFree (od_q3a_mem.obj)
       9,281   0,4      645,103  27,2    10733 _xmlParseEndTag =
(od_xml_read.obj)
       8,491   0,4      220,693   9,3    10814 _odpEndElement =
(odp_parse.obj)
       8,307   0,4      378,133  15,9     8175 _xmlParseAttribute =
(od_xml_read.obj)
       7,701   0,3        7,701   0,3    43101 _fbEOF (od_filebuf.obj)
       7,177   0,3     2370,210  99,9      321 _od_vmMain (od_main.obj)
       7,049   0,3        7,049   0,3    42893 _odpAdjustRecordTime =
(odp_main.obj)
       3,514   0,1        3,810   0,2    10816 _odpUpdatePlayer =
(odp_main.obj)
       3,338   0,1        3,338   0,1    10974 _odpEntityHasEvent =
(odp_main.obj)
       3,197   0,1       15,054   0,6     9534 _odpCharacters =
(odp_parse.obj)
       3,107   0,1        3,428   0,1     1352 _Com_sprintf =
(q_shared.obj)
       3,048   0,1        5,816   0,2     8175 _mbFree (od_membuf.obj)
       2,934   0,1      126,571   5,3        1 _odpInitGame =
(odp_main.obj)
       2,645   0,1       12,148   0,5     8258 _fbCmp (od_filebuf.obj)
       2,380   0,1       14,092   0,6     8177 _mbCreate (od_membuf.obj)
       2,072   0,1        5,882   0,2      169 _odpUpdatePlayers =
(odp_main.obj)
       1,886   0,1        1,886   0,1     8176 _xmlGetAttValue =
(od_xml_read.obj)
       0,778   0,0        0,778   0,0        1 _dllEntry =
(g_syscalls.obj)
       0,776   0,0        0,776   0,0      835 _trap_Cvar_Update =
(g_syscalls.obj)
       0,776   0,0     2370,985 100,0      321 _vmMain (g_main.obj)
       0,635   0,0        0,635   0,0        2 _trap_FS_FOpenFile =
(g_syscalls.obj)
       0,524   0,0        0,524   0,0      695 _odpEntitySetActive =
(odp_main.obj)
       0,398   0,0     2234,661  94,2      167 _odpRunFrame =
(odp_main.obj)
       0,359   0,0        0,359   0,0      156 _odpFollowerEndFrame =
(odp_client.obj)
       0,324   0,0        0,324   0,0     1353 _Q_strncpyz =
(q_shared.obj)
       0,285   0,0        0,308   0,0        1 _fbCreate =
(od_filebuf.obj)
       0,270   0,0        1,046   0,0      167 _odUpdateCvars =
(od_main.obj)
       0,240   0,0     2361,858  99,6      321 _odp_vmMain =
(odp_main.obj)
       0,209   0,0        0,209   0,0       23 _trap_SendServerCommand =
(g_syscalls.obj)
       0,185   0,0        0,185   0,0       70 _trap_GetUsercmd =
(g_syscalls.obj)
       0,167   0,0        0,167   0,0      429 _odpPlayerHasEvent =
(odp_main.obj)
       0,144   0,0     2238,701  94,4      168 _odpReadSnapshot =
(odp_parse.obj)
       0,144   0,0        0,144   0,0      255 =
_trap_AdjustAreaPortalState (g_syscalls.obj)
       0,139   0,0        0,324   0,0       70 _odpClientThink =
(odp_client.obj)
       0,136   0,0        0,136   0,0      170 _xmlPause =
(od_xml_read.obj)
       0,114   0,0        0,114   0,0       35 _trap_SetConfigstring =
(g_syscalls.obj)
       0,081   0,0     2245,498  94,7      169 _xmlResume =
(od_xml_read.obj)
       0,077   0,0        0,077   0,0      338 _odFindState =
(od_utils.obj)
       0,076   0,0        1,122   0,0      167 _odRunFrame (od_main.obj)
       0,064   0,0        0,423   0,0      156 _odpClientEndFrame =
(odp_client.obj)
       0,045   0,0        0,045   0,0       50 _trap_UnlinkEntity =
(g_syscalls.obj)
       0,035   0,0        0,035   0,0        5 _trap_Cvar_Set =
(g_syscalls.obj)
       0,029   0,0        0,029   0,0        5 _trap_Cvar_Register =
(g_syscalls.obj)
       0,028   0,0       69,648   2,9        1 _xmlParseFile =
(od_xml_read.obj)
       0,025   0,0        0,053   0,0        1 _odInitGame (od_main.obj)
       0,024   0,0       70,062   3,0        1 _odpReadDemo =
(odp_parse.obj)
       0,022   0,0        0,022   0,0       79 _odpBotAIStartFrame =
(odp_main.obj)
       0,019   0,0        0,263   0,0        1 _xmlParseDocTypeDecl =
(od_xml_read.obj)
       0,015   0,0        0,034   0,0       35 _odStrdup =
(od_q3a_mem.obj)
       0,011   0,0        0,278   0,0        1 _xmlParseXMLDecl =
(od_xml_read.obj)
       0,011   0,0        0,011   0,0        1 =
_trap_Cvar_VariableIntegerValue (g_syscalls.obj)
       0,011   0,0        0,011   0,0        1 _Q_stricmp (q_shared.obj)
       0,008   0,0        0,643   0,0        2 _odFopen =
(od_q3a_fileio.obj)
       0,008   0,0        0,208   0,0       15 _odpHandleServerCommand =
(odp_main.obj)
       0,006   0,0        0,014   0,0        1 _odpStartDocument =
(odp_parse.obj)
       0,004   0,0        0,004   0,0        1 _trap_LocateGameData =
(g_syscalls.obj)
       0,002   0,0        0,015   0,0        1 _odpClientBegin =
(odp_main.obj)
       0,001   0,0        0,025   0,0        1 _odpShutdownGame =
(odp_main.obj)
       0,001   0,0        0,001   0,0        1 _odpFollowPlayer =
(odp_client.obj)
       0,001   0,0        0,001   0,0        1 _Q_stricmpn =
(q_shared.obj)
       0,001   0,0        0,001   0,0        1 _odpClientConnect =
(odp_main.obj)
       0,001   0,0        0,001   0,0        1 _xmlStop =
(od_xml_read.obj)
       0,001   0,0        0,001   0,0        1 _odInitPool =
(od_q3a_mem.obj)
       0,000   0,0        0,003   0,0        1 _Q_strcat (q_shared.obj)
       0,000   0,0        0,000   0,0        1 _odpClientUserinfoChanged =
(odp_main.obj)
       0,000   0,0        6,941   0,3        1 _odpReadGameState =
(odp_parse.obj)

Re: [opendemo-devel] xmas release soon

[Dr. U. G. <Uwe...@ph...>]

Hello!

What a mess! ftp://upload.sourceforge.net stopped my upload of 
opendemo-20011219-bin.tar.gz in the middle of the file, so now we have to wait,
until the cleaner process will remove this (now read-only) file again.

Is the upload server really so slow and kills transfers or is there any
connection with my ISP (S-DSL 1MBit both directions in Germany)? Currently I
can't even log into upload.sourceforge.net at all (timeout).

I'll update the web page anyway and hope to finish the release process later
today or tomorrow morning. In the meantime the download links point to 
nowhere.

Bye, Uwe

[opendemo-devel] xmas release soon

[Dr. U. G. <Uwe...@ph...>]

Hello!

I've got about six hours from now (14:25 CET) for the xmas release. Then I
will go to "LOTR" and afterwards my holiday starts. I'll read/write emails
until 2nd january 2002 but nothing more.

If someone needs a special feature in our release 20011219, hurry!
I already updated some documentation files and the web page (private copy
on my hard disk).

I closed also the 2 remaining bug reports, they are solved from my point of
view.

Bye, Uwe

[girlich: Re: [opendemo-devel] need test for bugfixes I did.]

[Dr. U. G. <Uwe...@ph...>]

Sorry, just forgot to send it to the list. Uwe

[opendemo-devel] need test for bugfixes I did.

[Eugene 'H. B. <hm...@ma...>]

Hello,

I would ask everyone who is subscribed to this list to test the EV_ =
entity events bug fix I did recently. The newest code is in CVS =
repository. Thank you

Please check comments on this bug - 486013. There are some problems =
which are far beyond the scope of this bug (like, lightning sound fire =
is retriggered sometimes).

PS: I did a some modifications to the code that allows seeing =
rockets/grenades and such. Now it no longer uses <map> element's =
property "time". This allows adding/removing snapshots without the need =
for many modifications in the whole file (editing snapshot time values =
everywhere). Though this is not tested much - need your feedback and =
help on this.

Thank you.

--------
- HMage

Re: [opendemo-devel] Christmas release?

[Eugene 'H. B. <hm...@ma...>]

----- Original Message -----
From: "Dr. Uwe Girlich" <Uwe...@ph...>
Subject: [opendemo-devel] Christmas release?


> I intend to make an x-mas release later this week. Any objections? As we
> all know, during the end-of-the-year-holiday many people try out new
things, so
> we should have a binary release ready.

I do not object on this at all - we need to do a feature freeze and squash
bugs or comment out buggy features from this moment till the release. If we
want to release with some quality in it.


> How about some simple demo files to show and a .cfg-file to simplify the
> record/replay process?

Yup, I did a demo that uses playback looping feature I checked in recently.
(though the feature is taking much resources on every demo restart, I need
to optimize it further)


BtW: I've contacted Rhea (maker of OSP) and he gladly received the proposal
to implement opendemo in the future, as soon as OpenDemo will be stable
enough (it will not have any critical or distracting bugs). Also, Lead coder
of Q3F mod, RR2DO2, agreed to try to merge the current opendemo code into
his sourcetree to find out if it works, his code had undergone some big
modifications, as in OSP, so this should help out with finding new bugs we
can't see right now at the moment.

PS: At the moment I'm researching on a new bug which is quite distracting
and doesn't show up instantly. Check my comments in the EV_ event bug entry.

Yes, having an xmas release is definetly a positive action.

--------
- HMage.

[opendemo-devel] Christmas release?

[Dr. U. G. <Uwe...@ph...>]

Hello!

I intend to make an x-mas release later this week. Any objections? As we
all know, during the end-of-the-year-holiday many people try out new things, so
we should have a binary release ready.

How about some simple demo files to show and a .cfg-file to simplify the
record/replay process?

Bye, Uwe

[opendemo-devel] Re: wrong MSVC project files

[Eugene 'H. B. <hm...@ma...>]

----- Original Message -----
From: "Dr. Uwe Girlich" <Uwe...@ph...>
Subject: [opendemo-devel] wrong MSVC project files


> Hello!
>
> Could someone please check-in updated MSVC project files? During my
rebasing
> to 1.30 source I detected some changes in these text files (changes from
id
> between 1.27 and 1.29) but we had also some changes on top: especially
added
> od_* files.

I've already checked them in three days ago. Check the CVS changelog please.

>
> Without compiling (and linking) these od-files, all important symbols are
> missing, see OD forum entry
> http://sourceforge.net/forum/message.php?msg_id=1437817
>
> As you might have guessed I have no access to any machine with MSVC
running.
> Sorry.
>
> Bye, Uwe
>
>
> _______________________________________________
> opendemo-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opendemo-devel
>

[opendemo-devel] wrong MSVC project files

[Dr. U. G. <Uwe...@ph...>]

Hello!

Could someone please check-in updated MSVC project files? During my rebasing
to 1.30 source I detected some changes in these text files (changes from id
between 1.27 and 1.29) but we had also some changes on top: especially added
od_* files.

Without compiling (and linking) these od-files, all important symbols are
missing, see OD forum entry
http://sourceforge.net/forum/message.php?msg_id=1437817

As you might have guessed I have no access to any machine with MSVC running.
Sorry.

Bye, Uwe

[opendemo-devel] bug #490006

[Dr. U. G. <Uwe...@ph...>]

Hello list!

I changed the #ifdef stuff for spectator mode to a check against the
console variable od_spectator. I tried it out, to playback in this spectator
mode a single player recording and missed the player model.
Please look at bug #490006.
https://sourceforge.net/tracker/index.php?func=detail&aid=490006&group_id=6195&atid=106195

It seems, that in spectator mode we need to double some client data because
the server doesn't transfer the original client 0 data to the spectating
client any more. May this be true?

Bye, Uwe

[opendemo-devel] [hmd@mail.ru: Missing rockets bug]

[Dr. U. G. <Uwe...@ph...>]

Hello!

Here is a mail, which explaines (in part) wy the rockets are missing.
We have a basic problem with the time management.

Bye, Uwe

[opendemo-devel] rebasing to 1.29h

[Dr. U. G. <Uwe...@ph...>]

Hello!

I just finished rebasing the OpenDemo changes (which were based on 1.27g)
onto 1.29h. Please try it out. I stopped my effort after (most of it) compiled
flawlessly. I did not perform any testing at all!

Now I'll install 1.30 (which I heard should be based on the same source code
release) and try it out myself.

BTW, the sf.net website is dead.

Bye, Uwe

[opendemo-devel] Makefile creates batch files

[Dr. U. G. <Uwe...@ph...>]

Hello!

I just finished some waiting check-ins:

* Now the main source Makefile creates the QVM batch files.
They never contained the od_* files anyway but now they do.
The additional *.q3asm files, which are used as linker
command line will be created from the Makefile too.
So all these *.bat and *.q3asm files are gone from CVS.
*.bat will be created with DOS-line-endings but the
linker script not. I have no idea, if this works correctly.

* Creating binary packages wont include any native libraries
any more.

Now, I can finally think about a DTD/Scheme and some cool 
demo converting XSLT scripts.

Bye, Uwe

[opendemo-devel] q3_ui ?

[Dr. U. G. <Uwe...@ph...>]

Hello!

Why do we have ui and q3_ui directories? Is there a deeper sense in it?
I used always the game library alone but one never knows...

Bye, Uwe

Re: [opendemo-devel] combined Makefile

[Dr. U. G. <Uwe...@ph...>]

Hello!

> > > The next step is to generate the DOS batch files also with this
> > > Makefile.
> > I'm not so sure any more, if this is such a good idea.
> Why is that?
Because I'm lazy. If you look at my Makefile implementation, you'll see,
that I let make alone figure out, where the soure files are located.
Some .o (or .asm) files will be derived from the source .c file in the
corresponding directory but sometimes also from the library or game
directory. I simply provided make with all possible rules and it will find,
where the source file comes from. If I intend to create a batch file for
compilation, I have to repeat this process (looking for the file) myself.
OK,
if [ -e $dir1/$file ]; then
	use $dir1/$file
else
	if [ -e $dir2/$file ]; then
		use $dir2/$file
	fi
fi
it is not too difficult.

> > > Another thing is to finally implement a working 'make debug'.
> > I just did that. I added the debugging shared library to the binary
> > package, which is now 1974628 bytes long. Shouldn't we better generate a
> > separate 'debugging' package?
> I don't think we need to include native libaries in the packages at all. I
> figure that end users would want qvm files, and developers would like to
> make debug builds for testing purposes. Since developers should be able to
> compile everything from source, who needs a debug binary that someone else
> built?
That's right. The debugging libraries even contain full path names of the
source files and nobody else has the source files in 
/home/uwe/mi/new/opendemo/src/q3a/...

> > > The last thing I'm thinking about is to compile the Win32 shared
> > > libraries with a Linux cross-compiler too.
> > This is now really easy to add, maybe next weekend.
> Is this necessary either (see above)?
You're right, lets dump native libraries in binary packages totally and
I can finally concentrate myself on the contents (XML DTD and/or Scheme
writing, XSLT converter to manipulate od files etc.) itself.

Bye, Uwe

Re: [opendemo-devel] combined Makefile

[Conor D. <co...@ma...>]

> On Wed, Oct 03, 2001 at 05:52:36PM +0200, Dr. Uwe Girlich wrote:
> > I just checked in a working version of a combined Makefile, which
generates
> > (under Linux) QVM files and native shared libraries. The shell scripts
are
> > no longer necessary.
>
> > The next step is to generate the DOS batch files also with this
Makefile.
> I'm not so sure any more, if this is such a good idea.

Why is that?

> > Another thing is to finally implement a working 'make debug'.
> I just did that. I added the debugging shared library to the binary
> package, which is now 1974628 bytes long. Shouldn't we better generate a
> separate 'debugging' package?

I don't think we need to include native libaries in the packages at all. I
figure that end users would want qvm files, and developers would like to
make debug builds for testing purposes. Since developers should be able to
compile everything from source, who needs a debug binary that someone else
built?

> > The last thing I'm thinking about is to compile the Win32 shared
libraries
> > with a Linux cross-compiler too.
> This is now really easy to add, maybe next weekend.

Is this necessary either (see above)?

-Conor

Re: [opendemo-devel] combined Makefile

[Dr. U. G. <Uwe...@ph...>]

Hello!

On Wed, Oct 03, 2001 at 05:52:36PM +0200, Dr. Uwe Girlich wrote:
> I just checked in a working version of a combined Makefile, which generates
> (under Linux) QVM files and native shared libraries. The shell scripts are
> no longer necessary.

> The next step is to generate the DOS batch files also with this Makefile.
I'm not so sure any more, if this is such a good idea.

> Another thing is to finally implement a working 'make debug'.
I just did that. I added the debugging shared library to the binary
package, which is now 1974628 bytes long. Shouldn't we better generate a
separate 'debugging' package?

> The last thing I'm thinking about is to compile the Win32 shared libraries
> 	with a Linux cross-compiler too.
This is now really easy to add, maybe next weekend.

Uwe

[opendemo-devel] combined Makefile

[Dr. U. G. <Uwe...@ph...>]

Hello!

I just checked in a working version of a combined Makefile, which generates
(under Linux) QVM files and native shared libraries. The shell scripts are
no longer necessary.

The next step is to generate the DOS batch files also with this Makefile.
Another thing is to finally implement a working 'make debug'.
The last thing I'm thinking about is to compile the Win32 shared libraries
	with a Linux cross-compiler too.

Uwe

[opendemo-devel] 1.30 point release

[Dr. U. G. <Uwe...@ph...>]

Hello!

There was a 1.30 Q3A relase last week. I see stuff popping up everywhere
using this point release but where is the new source code? In
ftp://ftp.idsoftware.com/idstuff/quake3/source
is only the old 1.29h game source code?!

Uwe

[opendemo-devel] character references added

[Conor D. <co...@ma...>]

I just comitted XML character reference support in od_xml_read.c, for
character data and attribute values. I tested it with a hand-edited demo
file (character data only) and it works.

I also made odr_write.c escape &, <, and > when writing configstrings and
server commands. I haven't tested this yet.

-Conor

Re: [opendemo-devel] AddFloat corrected

[Conor D. <co...@ma...>]

Were they really different to begin with? The changelog for Q3A 1.25y says
that they unified the float-to-int conversions, which I took to mean they
made everything round down. Apparently this is not the case?

-Conor

----- Original Message -----
From: "Dr. Uwe Girlich" <Uwe...@ph...>
To: "OpenDemo Development List" <ope...@li...>
Sent: Friday, September 21, 2001 6:40 PM
Subject: [opendemo-devel] AddFloat corrected


> Hello!
>
> AddFloat() contained one of the first problems I ever solved for OpenDemo:
> A type conversion with LCC (for bytecode) like
> float f;
> int i;
> i = (int)f;
> rounds the value sometimes up and does not always round down like GCC and
> most other compilers do.
> I had a correction for this in bg_lib.c but it somehow disappeared.
>
> Now it works again and two servers with bytecode or Linux native libraries
> (without any logged in clients, simply dedicated server of q3dm0) generate
> the exact identical recording file. Only configstring index="0" is
different
> (ordering problem, I'll look into it).
>
> Bye, Uwe