[bf1942] New build.

jjohnso1 at sbcglobal.net jjohnso1 at sbcglobal.net
Mon Jan 6 20:46:44 EST 2003


I no longer see the lag problems with maps like Midway.  Not sure yet about
other issues.  But I noticed something trivial, but not immediately obvious
that might be adversely affecting others' testing and error results with the
new build.

IF YOU ARE SEEING OLD PROBLEMS THAT RYAN THINKS HE FIXED, PLEASE READ ON.

Many of you probably noticed this -- but double check that you correctly
extracted the new TAR into the correct location.  Unlike the previous
updates, this TAR archive does not extract into a subdirectory called
'bf1942-lnxded-1.2beta1' -- it simply places the binary files in the
directory where you run the TAR command.  So, if you aren't careful, you're
still running all of the code from the previous update.

Anyway, back to testing.  I just wanted to point that out since I didn't see
it mentioned by anybody else yet in this list.

John

P.S.  What the heck is a 'Holy Build Box' anyway?  ;)

----- Original Message -----
From: "Ryan C. Gordon" <icculus at clutteredmind.org>
To: <bf1942 at icculus.org>
Sent: Monday, January 06, 2003 2:45 AM
Subject: [bf1942] New build.


>
>
http://icculus.org/betas/bf1942/bf1942-lnxded-betaupdate-build-1041834125.ta
r.bz2
>
> The crashbugs are driving me nuts, and I'm not entirely certain they
> aren't race conditions. So I ripped the multithreading out. There's a few
> benefits to this:
>
> 1) The binary is 1.5 megs smaller (!).
> 2) Less latency due to context switching and mutex contention, etc.
> 3) Less context switches.
>
> The end result is that the server might actually respond better and eat
> less CPU (although I suspect the lag people are seeing is unrelated).
>
> Most importantly:
> 4) No race conditions.
>
> No, most importantly:
> 5) No more complaints that there's three copies of the game running!
>
> You might get all the same crashbugs in this build as the last one. We
> won't know until you try it, but it will let us rule out a threading
> problem (and at least I can say with certainty that you won't crash in
> pthread_mutex_lock() anymore.  :)  )
>
> Other stuff:
>
> 1) The server status info (the little red dot in the server browser)
> shouldn't be red anymore. That thing is based on framerate, but since all
> the video stuff was ripped out of the Linux server, the frames per second
> was always zero (which, I guess, is really really slow.  :)  ). Now it
> reports server frames per second, which in terms of a null rendering
> device, is a more accurate term for the exact same thing.
>
> 2) I set the gamespy socket to "reusable", which is the ONLY difference
> between the game's socket and the gamespy one...if this doesn't fix
> FreeBSD's binding problems, I can't fathom what's wrong with it.
>
> Ok, I'm getting on a plane for San Francisco now, but I'll be checking
> email throughout the week. Please report success and failure (and stack
> traces).
>
> Good luck,
> --ryan.
>




More information about the Bf1942 mailing list