id_notes/John C/1999-04-24_1999-06-05
[idsoftware.com]
Welcome to id Software's Finger Service V1.5!
Name: John Carmack
Email: johnc@idsoftware.com
Description: Programmer
Project: Quake 3 Arena
Last Updated: 06/05/1999 01:01:21 (Central Standard Time)
-------------------------------------------------------------------------------
6/5/99
------
I have been mailbombed, so I won't be reading email for a while.
No more work logs for now.
6/3/99
------
Whee! Lots of hate mail from strafe-jupers!
Some reasonable messages have convinced me that a single immediate jump
after landing may be important to gameplay. I'll experiment with it.
Strafe jumping is an exploitable bug. Just because people have practiced
hard to allow themselves to take advantage of it does not justify it's
existance. When I tried fixing the code so that it just didn't work, I
thought it changed the normal running movement in an unfortunate way.
In the absense of powerups or level features (wind tunnels, jump pads, etc),
the game characters are supposed to be badasses with big guns. Arnold
Schwartzenegger and Sigourney Weaver don't get down a hallway by hopping
like a bunny rabbit.
This is personal preference, but when I play online, I enjoy it more when
people are running around dodging, rather than hopping.
My personal preference just counts a lot. :-)
btw, here are the current weapon effects:
gauntlet: 50 pts, 400 msec / punch
machinegun: 10 pts, 100 msec / shot
shotgun: 11 pellets of 10 each, 1000 msec / shot
rocket launcher: 100 pts direct hit, or 100 pts splash damage falling off
over 120 world units, 800 msec / shot
plasma gun: 20 pts direct hit or 15 pts splash damage over 15 units,
100 msec / shot
railgun: 100 pts, 1500 msec / shot
lightning gun: 8 pts, 33 msec / trace, max range 768 units
grenade launcher: 100 pts direct hit, or 100 pts splash over 150 units,
800 msec / shot.
bfg: 40 pts instant splash damage over 100 units, 100 msec / shot
flamethrower: to be determined, but short range / wide angle
Splash damage is calculated from the edge of the player's box, unlike
quake1, where it was calculated from the player's origin.
6/3/99
------
* ignore cl_maxpackets on LAN
* changed cl_packetdup to 1 by default, and archived
* defaulted com_maxfps to 100 and archived, automatically
disabling during timedemo. It was possible to lag
out some client connections on ultra fast systems even
with cl_maxpackets set fairly low due to a huge number
of individual commands being created
* 250 msec minimum time between landing and jumping again
I hate having players bouncing around all the time...
* fixed bug with large r_picmip values (white shotgun sight bug)
* new lightning and rail beam drawing
* player torso twitches with pain sounds
* r_drawstrips changed to r_primitives and archived, with changes:
default "0" uses glDrawElements if compiled vertex arrays
are present, or strips of glArrayElement if not.
"1" forces strips, "2" forces drawElements, "-1" skips drawing
* increased rocket speed to 900 from 800
decreased direct hit damage from 120 to 100
splash damage same as 1.05
* removed sound-in-use dialog, auto skip after second try
* made userinfo persistant on server across level changes
* allow different servers to respond to a challenge,
allowing redirecting server proxies
* notice bad ip addresses for connection: 192.1234.123.122
* removed neck length pivot to prevent view poking into
low subdivided curves. Also make aiming when
looking up or down more precise.
5/30/99
-------
For the past couple of weeks, I have been spending some development time on
linux, and for the first time on a non-NEXTSTEP unix platform, I have
actually been enjoying it.
While Id has been supporting linux since the Doom days, I have not personally
been much of a linux user -- it was always ddt or zoid doing the actual coding
and testing. Every year or so I would install a linux distribution and play
around with it for a few days, but I would always leave feeling that it was
still pretty crude (UI wise) compared to the NEXTSTEP UI I was used to, or
even what I had used on other commercial unix workstations and windows.
There have always been a ton of reasons to like linux, but the user
interface was enough of an issue that I couldn't buy into it completely.
The gnome user environment in Red Hat 6.0 is finally at a level that I
consider it a valid alternative to commercial desktop environments. Overall,
its still not as smooth, consistant, or complete as windows or the mac, but
is does have its strong points, and things seem to be progressing quite
rapidly.
Its still not something you would give to a purely casual computer user,
but I won't be surprised if even that changes in a couple years.
CodeWarrior for linux is also a significant aspect of my enjoyment. Its
a sort of crappy 1.0 port with a lot of little issues, but the editor works
well enough, which is the important thing for me. I have never been able
to stand vi or emacs for long enough to become proficient in them.
The code that I have been playing with most is the matrox g200 GLX driver.
Matrox is the first of the major 3D chip vendors that has had the guts to
publicly release register level documentation for their 3D chips.
An accelerated X windows OpenGL driver has been put together with this by
building on top of the existing Mesa and GLX projects.
It actually runs quake, quake2, and q3test. It doesn't run them FAST, but
the quality is good, and I am impressed nonetheless. It is bordering on
playable with all quality options set to the minimum on a fast computer,
but it still has a ways to go before casual users should take a look at it.
It is steadily improving, and I hope Matrox will be pleased enough with the
progress that they will release the documentation for their setup engine to
go with the rasterizer.
In testing q3 on it, I noticed that with picmip set to 0, textures would get
corrupted and it would never settle on a working set. The current Apple
OpenGL drivers also have exactly this problem.
The cool part is that this driver is completely open source. I downloaded
the project code, browsed through it a bit, and changed two lines of code to
fix the bug. That RULES.
The next thing is sort of funny. I had been suspecting that a lot of the
OpenGL drivers were clearing the entire depth buffer for each of the 3D icons
on the status bar, instead of limiting it to the scissor region. I added code
to the g200 driver to explicitly crop the clear region in the driver, but it
never got executed. A little more investigation showed that I had been making
an improper assumption for years -- scissor is not enabled by default. Doh.
Ever since noticing that glquake cleared the screen borders when the view is
sized down, I had been operating under the assumption that intergraph just had
a bug in their drivers. I had double checked that glClear was supposed to be
limited to the scissor region, so I thought they were just messing it up.
Now I know that I was just being an idiot about that for the last three
years... With scissor enabled, most of the cards got a few percent faster.
5/30/99
-------
* dynamic curve level of detail
r_subdivisions determines the maximum level
of detail, r_lodCurveError determines how
quickly polygons are pulled out with distance
* devmap
* change weapon item upscale to 1.5 instead of 2
* always toss items forward, even if looking up or down
* draw ammo in grey while weapons are reloading
* change railgun shader while reloading
* fixed head models not showing proper skin
* skip all shell eject code when cg_brassTime 0
* fixed sound memory overallocation
* profiling and rearrangement
* fixed dead spectator bug
5/27/99
-------
* enable scissor test properly
* archive r_lodBias
* cg_draw3dIcons 0 option
* data cheating protection
* userinfo renamed to clientinfo, added state and current
server address
* don't forward commands to a server when playing demos
* fixed NULL extension on dir command
* added one more shotgun pellet
* added CG_Shutdown for cgame cleanup
* fixed jitter in rising smoke
* increase minimum time before reusing an entity slot
* soundinfo reports current background streaming file
* changed IPX separator to . from :, moved port processing
to system independant code
* auto port scan wasn't updating the net_port cvar
* attack button presses reset inactivity timer now
* increased the forced respawn time from 10 to 20 seconds
* show smp on gfxinfo, slight reformat
5/26/99
-------
* basic joystick controls
some work still needed for advanced controlers
* r_dlightBacksides 0 option
* forced cvar_restart when version changes
* fixed some flare-in-fog problems
* fixed skin color in menus
* print obituary message even when you are the killer, so all
kills get an entry in the logfile
* fixed bugs in line token parsing when quotes or commands aren't
white space separated
* multiprocessor acceleration "r_smp 1"
* increase menu dimming
* increased rocket damage radius from 120 to 150 units
* check for running server in all server commands (dumpuser, etc)
* new cvar cheat setup -- by default, only archived
variables can be changed when not cheating
* "cg_drawstatus 0" only removes status bar
* "cg_draw2d 0" removes all 2d
5/22/99
-------
The SMP support is solid enough to play with now. The only feature that is
still broken is light flares.
As a happy consequence, some of the cleanup work I did for SMP gave a couple
percent speedup even when running without the separate thread.
On my development system, a dual 300 mhz intergraph realizm II, the low res
timedemo scores went from 27.8 to 37.8 with "r_smp 1". This is only a 35%
average speedup, but at some times (lots of dynamic lights in complex scenes)
the speedup is 90%+. Gameplay is noticably smoother.
The rendering thread is almost always the blocking factor, so the faster the
card and OpenGL driver, the larger the speedup will be.
This is explicitly a two thread producer / consumer, so there is no benefit
to more than two processors. The app is well behaved, using sleeping
syncronization so that you usually still have half a processor free for other
operating system functions.
Hopefully we will be able to test with some fast consumer cards sometime
soon.
------
A lot of people asked what was done differently this time vs the last time
I tried (without benefit) to use SMP.
My original attempt was to make a DLL that intercepted all OpenGL calls and
let a separate processor execute them. The benefit would have been that all
OpenGL applications could have gone faster. The problem was that the
bandwidth required to encode all the commands was enough that the processor
overhead was as much as it would have taken to just do the geometry on the
main processor.
It would have still been a win if the geometry side was doing
lots of work, like multiple lights, user clip planes, and texgens, but for
the vast majority of geometry, it didn't balance out. If someone wanted to
try that using the PIII or AltiVec streaming memory operations, it could
probably still work.
The current SMP code is implemented directly into the renderer, and a lot of
things were moved around and double buffered to allow it to use data in
place, instead of having to copy it off.
------
Some people expressed surprise that Quake3 wasn't threaded already.
Threading has been presented so often as the "high tech" "cool" way to
program, that many people aren't aware of the downsides.
A multi-threaded program will always have somewhat lower throughput when
running on a single CPU than a single threaded program that polls in
explicit places. The cost of a context switch at the cpu level is negligible,
but the damage that it can do to the cache hierarchy can add up to a
noticeable amount in bad cases.
The much larger problem is that you lose tight control over when things
occur. If the framerates are low enough, it isn't a huge issue, but for
applications running at 30+ fps, you really don't want to trust the OS
scheduler to coordinate multiple threads and have them all get in every
frame. Yes, with explicit sleep() calls you can sort of get it working,
but at that point, you might as well not be using threads.
A good example of not-quite-in-sync issues in the windows mouse performance.
A PS/2 mouse only samples 40 times a second, so when you get an app updating
at around that speed, you will get 0/1/2 scheduling variances.
They are also not terribly portable, and a pain in the ass to debug.
5/19/99
-------
Now that all the E3 stuff is done with, I can get back to work...
I was stuck in a room the entire time doing press interviews, but it seemed
to have gone well. It was mentioned to me that there were a few people on
the show floor with forged badges that read "John Carmack -- Id Software".
As if forged email / irc / icq isn't enough of a problem. Sigh.
The "download" crashtest was first reported by Rick Hammerstone. That was
a pure dumbass mistake on my part.
I should be sending the accumulated crashtest bounties off tomorrow.
The plan right now is to have an update release next week that will have
lots of bug fixes and cheat protections, but not too many new user visible
features.
I finally got around to implementing dual processor acceleration today. I
still have a couple issues to resolve and some more rearranging to do, but
it is giving 20%+ speedup right now in a worst-case situation for it.
When completed, I expect the average speedup to be in the 40% to 80% range,
depending on what is going on and the video configuration. Scenes with lots
of dynamic lighting and lots of sounds and other client processing going will
show the largest speedups. It helps the slow scenes more than the fast
scenes, which is basically what you want.
I am going to shake this out with the Windows (NT) code first, but it should
definately make its way to the linux port eventually.
I know SMP is a que for all the BeOS folks to ask about ports, so I'm going
to head that off: Be has all the code for Q3 (and Q2, for that matter), and
a version of Q3test should be available by the time they ship a release OS
with OpenGL hardware acceleration.
There will probably also be an SGI-irix port.
Regarding both of those ports: they are not supported ports, and will be
maintained by volenteers (like the current MacOS X port). Update releases
will lag the official ones, and we won't committ to ANY dates.
I am doing all of my development on intergraph and sgi-NT hardware, but when
I have everything rock solid, I will give Nvidia and ATI's NT drivers a try.
I would be somewhat shocked if they didn't explode -- I doubt multiple
threads playing occasional tag team on a context has been well tested.
True, only a tiny fraction of our players (probably less than 1%) will be
able to take advantage of this, but I consider SMP usage to be an important
technology to nurture over the coming years.
The top of the benchmark chart should be an SMP system (assuming the NT
drivers have all the optimizations of the '98 drivers), and it will also
be possible to build a reletively cheap SMP system (say, dual 400's) that
outperforms the best single processor system.
5/12/99
-------
We had to upgrade the crashtest machine to NT sp 5, because
some people were attacking it with windows crashers. Those
don't count.
Crashtest #3 from [iBO]QWhAX0R was a combination of two
problems:
The symptom was disconnecting all clients with an illegible
server message. This turned out to be caused by the fact
that I was parsing strings out of my net buffers with a
MSG_ReadChar() function, and I was checking for EOF as a
negative one return value. I had to change this to a
MSG_ReadByte() call, because -1 was showing up in the
messages, which then caused a parse error because it wasn't
really the end of the message.
The actual root of that issue was code like this:
{
char buffer[MAX_STRING_CHARS];
...
strncpy( buffer, input, sizeof(buffer) - 1 );
...
}
No buffer overruns are possible, but buffer is not forced
to be zero terminated if on the stack. I'm pretty sure this
was a result of copy-and-paste code where buffer used to be
a static with a guaranteed zero, but it made me find several
other places where similar things were happening.
I had started using a Q_strncpyz() function a while ago that
guarantees a trailing zero and doesn't require the -1, but it
turned out that between code I had written a long time ago,
and code that either Cash or Brian had added, there were still
a lot of normal strncpy calls around. A lot of them were wrong,
too. Either missing the -1, or missing the dedicated 0 fill in.
Crashtest #4 from Jim Paris was a variation on the first part
of #3.
Only one of these attacks so far has been a server crasher, but
I have been giving the bounty for anything that immediately kicks
all the players. I probably won't give it for attacks that only
overflow some lagged clients, but I'll evaluate as they happen.
I am off to E3 now for a bunch of PR silliness, so if
crashtest goes down, it won't be back up for a while...
* fixed crashtest 4
* fixed crashtest 3
* fixed jumping-over-item pickup prediction error
* made "Couldn't load sound" a developer only warning
* fixed demo recording not including portal surface entities
* precache grenade bounce sounds
5/11/99
-------
You can bias the level of detail lower than allowed in the
menu with "r_lodbias 2", which will force all models to the lowest
lod. The view weapon will look very ugly.
Another little speedup option that isn't offered in the menus is:
"cg_simpleitems 1" this removes the extra rings and spheres around
some items.
You can also turn off all the gibs with "cg_gibs 0".
* clear game memory at init, which fixes the stuck-at-intermission
problem on mac servers
* fixed mismatched free / Z_Free in demo menu
* removed unused reference to sprites/plama.md3
* automatically get sounds from model name
* scale sensitivity by zoom
* immediately archive changes to latched cvars
* cheat protect r_portalonly
* don't print "XXX connected" on level restarts
* fixed "give item" on levels where 0,0,0 is in solid
* fixed timedemo
* don't play pain falling sound if dead
* fixed falling damage sound not snd specific
* fixed crashtest 2
* fixed crashtest 1
* q3map_backshader
* q3map_globaltexture
5/11/99
-------
Do NOT send bug reports and game comments directly to me!
If I have to filter through hundreds of emails a day, I won't get any
more work done... Only crashtest related problems should come to me,
everything else should go to q3feedback@idsoftware.com.
5/11/99
-------
Sami Tammilehto wins the second prize. Some large connectionless packets
can cause crashes.
This one was a result of me having the maximum token size defined lower
than the maximum string size.
5/11/99
-------
BigImp wins the first prize. It doesn't crash the server, but fmtspec
names will crash all clients that try to log on. Technically that would
be an upkeep required DOS attack, but I'll let this one go.
I even had a "FIXME: make vsprintf safe" comment by the offending line...
I am going to update the server to filter out all % chars that come in
over the net to prevent any other similar things.
5/11/99
-------
Everyone should realize that many popular net links are going to be clogged
up with q3test downloads for a while, so net play may be a bit patchy to
a lot of servers.
-------------
Now that the first win32 test is out, here is The Plan for going forward:
All future releases should be same-day for all architectures.
There may be an exe-only update to the current distributions if there are
significant problems, but it isn't scheduled.
The next major test release will include a new one on one map designed for
tournement play, and new executables with server and game modifications, but
will not require downloading a new pak0.pk3.
The release after that will introduce various teamplay rules on the original
two maps. This version will likely be another full download, because I
know that I still have a couple things to change in the map format. This
will probably be the first test running with the virtual machine.
The final major test release will introduce the single player game with
bots and ranks.
After any bugs are shaken out of that, it will be the "Q3 Demo" instead of
the "Q3 Test", and we should be ready to release the full game to stores.
In an ideal world, people that aren't prepared to deal with in-development
software would wait until then to form an opinion of the product.
---------------
I am offering a bounty for server crashing bugs. Q2 had several releases
forced out because of malicious attacks on all the public servers, so I
want to try and flush out what I can during Q3's testing phase.
There is a server running in the debugger here at crashtest.idsoftware.com
(192.246.40.68). Anyone that can repeatably hang or crash this system can
have a $100 prize and some misc bit of Q3A paraphenalia that I can dig up.
Operating system level attacks don't count -- only things that I can actually
fix or protect against in my code.
Denial of service attacks don't count if they require upkeep, but if there is
a fire-and-forget DOS attack, it will still count.
Any actions you can perform with the released client are fair game. Crashing
the client isn't good for a bounty, but I would still like to know about it.
Custom attack programs are also fair game. These are actually what I am most
concerned about -- malicious programs that goes through and crash all listed
servers.
Ideally, you would practice on a private server under your control and only
hit crashtest when you think you can repeat it.
If you find one, email me the instructions so I can reproduce it. Include
"CRASHTEST" in the subject so I won't miss it.
First come, first served, one bounty per bug. I will update crashtest with
our internal builds, so it will certainly be possible that an attack on the
released servers no longer functions on crashtest.
5/10/99
-------
A good day of work. I just finished a long test game with all three
architectures, and everything looks solid.
As far as I can tell, these are ready to go after making installers
and such, but everyone else has an oportunity to find bugs while I
sleep...
We won't hold up for minor gameplay issues, but if anyone turns up
a repeatable crasher I will rebuild everything.
Barring problems, we should start rolling the releases out tonight.
* fixed crash case on fallback from an unsupported fullscreen
* fixed overrun with very fast system connecting to
a very lagged server
* fixed bad Z_Free on sounds not found
* fixed autoswitch with sync clients
* fixed losing console field on positive historie
* fixed demo recording and playback with new net code
* handle signed bit fields in msg code
* fixed playerstate event bit loss on encoding
* fixed "bad clientnum on player entity"
* reenabled corpses sinking into ground
5/9/99
------
We would up making tweaks to both maps today, so the data didn't
reach final form until a few hours ago.
I just finished making release candidates for all three architectures,
but I already found a couple problems that need to be fixed.
If everything goes perfectly (ha), and I nail these problems immediately
when I wake up, then we might make it out tonight, but it is looking a
bit doubtful.
There are a few known issues that I decided NOT to hold the test up for:
The gauntlet is functioning correctly, but the visuals are wrong.
The designed behavior is that when you hold down attack it will scan
for a target and only punch forward when it hits. The visuals currently
show it punching constantly.
Dynamic lighting is currently taking a really excessive amount of cpu
time. If you are having performance problems in firefights, you may
want to turn it off. The option is in the preferences, or you can
just issue "r_dynamicLighting 0" at the console.
The powerup item sounds aren't global across the entire world since
I went to the client side predicted items.
There are some cases when a weapon that was picked up with a predicted
item and immediately fired doesn't make a muzzle flash.
* fixed fs_copyfiles after ospath split
* fixed look-at-killer
* changed railgun impact to plasma dish
* convert connect packet to infostring
* put footsteps back in...
* r_drawsun 0 by default to avoid probs for now
* fixed event clear overwrite problem
* client side predict weapon switch on item pickup
* changed sound fallbacks to "visor" from "male"
* made turbulent texcoords based off of xyz instead of st
5/8/99
------
There is one must-fix issue and a couple smaller issues
remaining before the release candidate build, then we
have to do a lot of testing on it. I made a lot of
significant changes in the last week, and I'm sure there
are some things we still need to sort out before we
inflict it on the general public.
We are aiming for sunday, but understand that that means
sunday evening, not sunday morning.
If saturday night / sunday morning testing on the release
candidate turns up significant problems, we will put off
the release until they are fixed. That could be later
sunday night, or it might not make it until monday night.
The previous release delays for win32 were issues out
of our control, but this release rests squarely on me.
The content and other issues are ready, but we still
need to make sure all the new code is solid.
* fixed give item bug
* new first snapshot timing
* moved sun drawing outside of sky shader to fix showtris
* r_drawSun
* handle all shader tesselations in q3map with tjunc fixups
* different flatness epsilons for edge vs border grids
* reorganize sound directories
* removed footsteps on non-metalic and non-water surfaces
* fixed bug with multiple looping sounds
* client side predict teleporters, go to "hyperspace"
* precache remaining liquid sounds
* don't fire jumppad events if upward velocity
5/7/99
------
* changed grabbed items to SVF_NOCLIENT instead of EF_NODRAW
now that the pickup event is on the player
* clear event flags with event on reset
* move playerstate to netfield bit communication
* fixed configstring delta sequencing issue after initial
gamestate
* extended the netgraph: short red lines are missing
client to server packets (need to drop 3 in a row)
* extended cg_debugevents
* increased cl_maxpackets to 30
* fixed bug with console field not getting drawwidth set
* fastsky implies noportals
* changed fastsky color
* q3map now fixes tjunctions at fog boundaries
* build optimized tree with visible hulls of sides
* adjusted plane culling to avoid some cracks
* r_facePlaneCull
* fixed too-lax colinear collapse to avoid some cracks
5/5/99
------
* client side predict item pickups
running over items was one of the few
remaining locally perceived signs of lag
* new pont-in-patch test code
* fixed pathname errors when mac users had
slashes in their paths: "B/W mac". sigh.
5/4/99
------
* seeded random numbers differently on tourney restarts
* fixed events on initial snapshots
* removed g_maxentities configuration, set by G_ENTITY_BITS
* cl_motd 0 to allow never sending request packets
* fixed map cache clearing bug
* cg_drawFPS 1 for running fps counter in corner
* remove all teleport destination pads
* moved checkmap out of cgame
* moved time positioning out of cgame
* made usercmd overrun freeze in place instead of snapping back
* slightly increased shotgun spread
* protected against using a cleared clientinfo
* use snapped origin from players for linking to prevent
slight prediction errors during player collisions
4/30/99
-------
I put together a document on optimizing OpenGL drivers for Q3 that
should be helpfull to the various linux 3D teams.
http://www.quake3arena.com/news/glopt.html
4/29/99
-------
* rework versioning for architecture tracking
* use a seperate endpoint for address resolves on mac
* hide OTLook warnings if "developer" isn't set
* defered mac renderer scanning until after mode set so
8 bit desktops don't confuse it
* global motd/update server
* fixed view model animations on models with custom anims
technical note:
Q3 can run networked player movement in either an asynchronous or
synchronous manner. The default mode is to allow all client movement to be
done asynchronously with the servers advancement of time.
The primary reason is to allow player movement to be predicted on the client
side. The primary drawback is that while your movement is smooth, the other
players that you see running around in the world move with a jerkiness that
is relative to their framerate and network connection quality. It is NOT
necessarily relative to their ping - a player on a fast system with a clean
modem connection can move smoothly. If you see a player stuttering around,
either they have a bad franerate, or the network connection between them and
the server or you and the server is poor. The amount of stuttering is sort
of the sum of the dropped or variable packets on BOTH connections.
You can force Q3 to run all clients synchronously by setting
"g_synchronousClients 1" on the server. This will make Q3 behave similar to
Q1 for networking. All movement will be lagged except view angles, which are
still short-circuited immediately.
Some people claim to prefer synchronous movement when everyone had a very
good ping, but I don't personally think it is ever a play benefit. It
makes leading players a bit easier, but I think the crisp movement control
of client side prediction is a much better tradeoff.
However, there is still a reason for using it: recorded demos come out a
LOT smoother looking when running with sync. Note that q3test does not
allow demo recording and playback, so this is just for future reference...
4/28/99
-------
* converted sound positioning away from callback method
* increased mac memory zone by 5 megs
* new memory allocator for temporary render use during init
* converted cmodel references to handles and range checked
* converted sound references to handles and range checked
* converted file references to handles and range checked
4/27/99
-------
* cgame converted to use local buffer based lerpTag for interpretation
* cgame converted to use local buffer based argv for interpretation
* new sound code to remove latency
* added drop shadow to field characters and fixed scrolling
* fixed edge-of-bounce-pad misprediction error (server side)
* remove broken weapon-stay dmflag
* made menu gfx never picmip
* cheat protect r_lightmap
* clear sound buffer before any file IO
* use GetOSEvent instead of WaitNextEvent on mac when fullscreen
removes hitches caused by other tasks and gives a
performance boost
* continuous scoreboard / ping update when tab is down
* put version number on menu background
* fixed toggle cvar bug
* dim out behind floating menus
4/26/99
-------
One more addition to net cvars:
"cl_maxpackets" will restrict the maximum number of outgoing
packets to prevent client to server rate problems. This does
not limit the client framerate. This defaults to 20, which
might actually be a bit low. You might try experimenting
with raising this to 40.
"cl_maxfps" still exists, but it will never need to be used
for networking reasons.
4/26/99
-------
Interpreting the lagometer (the graph in the lower right corner):
The upper graph (blue/yellow) slides one pixel for every rendered
frame. Blue lines below the baseline mean that the frame is
interpolating between two valid snapshots. Yellow lines above
the baseline mean the frame is extrapolating beyond the latest
valid time. The length of the line is proportional to the time.
The lower graph (green/yellow/red) slides one pixel for every
received snapshot. By default, snapshots come 20 times a second,
so if you are running >20 fps, the top graph will move faster, and
vice versa. A red bar means the snapshot was dropped by the
network. Green and yellow bars are properly received snapshots,
with the height of the bar proportional to the ping. A yellow
bar indicates that the previous snapshot was intentionally
supressed to stay under the rate limit.
The upper graph indicates the consistancy of your connection.
Ideally, you should always have blue bars of only a pixel or two
in height. If you are commonly getting big triangles of yellow
on the graph, your connection is inconsistant.
In a heavy firefight, it is normal for modem players to see yellow
bars in the bottom graph, which should return to green when the
action quiets down. If you are getting several red bars visible,
you may want to look for a server that drops less packets.
There are a few tuning variables for people trying to optimize
their connection:
The most important one is "rate", which is what the connection
speed option in the menu sets.
We are fairly conservative with the values we set for the given
modem speeds: 2500 for 28.8, 3000 for 33, and 3500 for 56k.
You may actually be connecting faster than that, and modem
compression may be buying you something, so you might get a
better play experience by increasing the values slightly.
If you connect at 50000 bps, try a rate of 5000, etc.
I err on the conservative side, because too low of a rate will
only make the movement of other things in the world choppy, while
too high of a rate can cause huge amounts of lag.
Note that the optimal rate will be somewhat lower than a rate
for QW or Q2, because I now include the UDP packet header
length in the bandwidth estimate.
You can ask for a different number of snapshots by changing the
"snaps" variable, but there isn't a lot of benefit to that.
Dedicated servers run at 40hz, so stick to divisors of that:
40, 20 (default), 10. A snaps of 40 will usually just cause
you to hit your rate limit a lot faster. It may be useful
for tuning rate, if nothing else.
You can adjust the local timing point with "cg_timenudge
which effectively adds local lag to try to make sure you interpolate
instead of extrapolate. If you really want to play on a server that
is dropping a ton of packets, a timenudge of 100 or so might make
the game smoother.
4/26/99
-------
* converted cvar allocation to indexes to allow range checking
* cgame converted over to use vmCvar_t instead of cvar_t
needed for interpreted cgame
* fixed server crashing string bug
* adjusted scoreboard for 8 players
* show hostname on connection screen
* fixed null model warning on startup
* more space for hostname on local servers screen
* fixed mac Open Transport memory buffer bug
this was causing most of the mac crashes
* made Info_ValueForKey() case insensitive
* sv_privateClients, sv_privatePassword
this allows you to reserve slots on a
public server for password access while
allowing most to be freely available
* "server is full" message on connect screen
* archive handicap in config file
* cheat protect r_nocurves
* byte order independent zip checksum
* removed cl_stereo, use glConfig.stereoEnabled
4/25/99
-------
Some people seem to think that I just make up these performance comparison
numbers. I don't. I measure things, and I understand control conditions.
In this discussion, assume "wintel" is a 500 mhz PIII with either a agp
rage128, or an agp TNT card, and "macos" is a 400 mhz G3 with the pci rage128.
At the highest level, you can make application class comparisons between
platforms. For instance, CodeWarrior on the mac compiles faster than VC++
on wintel, but stuffit is way slower than winzip. This is useful data,
but says more about the application design than the relative merits of the
platforms. CW uses a single object file repository, for instance.
A better comparison is an identical app on both platforms.
Photoshop is often faster on macos than wintel. There is certainly a lot
of common code, but individual filters are optimized for each platform.
Some of these hand optimized operations are significantly faster on the
mac.
Quake1 was the counterpoint to that. Quake1 had significant amounts of
hand tuned asm code for intel, and the PPC version never got as much
attention. The PPC version was noticeably slower (you would have to time
at 640*480 to avoid unfairly penalizing the mac for lack of low res
modes).
So, clearly, hand tuned asm code can make either platform pull ahead. It
also shows that the two platforms are at least fairly close in performance.
I never said macs were SLOW, just not quite as fast as the best intel systems.
Quake3 doesn't software rasterize, so there isn't any great place for lots
of asm code (the great place is in the OpenGL driver). The code is
essentially identical on all platforms.
Q3 is definitely faster on a wintel system than a macos system. When the
wintel version is released, everyone will be independantly repeating that
measurement.
Even this measurement isn't exactly an apples to apples comparison, because
the OpenGL driver and 3D card are still a significant variance. The two
can be broken out farther: Q3 can be run without 3D output to test just
the identical compiled code. Wintel is still faster, although somewhat
less so. The OpenGL + 3D card setup can be benchmarked separately on the
axis of throughput and fill rate, which show the intel system being
significantly faster. I can't break that apart into the two separate
components, but I will guess that the OpenGL driver is probably as efficient
as the wintel drivers and the performance delta is due to the system
interface and the video card. The current mac rage128 cards run at 75 mhz,
which is a third slower than the PC cards. AGP is also more than just a
faster PCI, it can influence the structure of communication with the card.
It has been my observation in the past that most of my code tracks just about
midway between specint and specfp for performance comparisons. There is a
lot of floating point, but it is all short vectors, rather than the massive
vectors of scientific computing. If we discount the graphics subsystem, Q3
follows this reasonably well. The intel system does slightly better than
projected.
"Sucks" is a subjective description that can be dismissed as opinion. Note
that I have NEVER said that the hardware sucks, or the user interface sucks,
just that the mac OPERATING SYSTEM sucks.
"Faster", when qualified with testing conditions, is objective, and all the
wishing in the world doesn't change it.
Objectivity and quantification are the paths to improvement.
I will be very happy if Apple can produce a desktop system that is faster
than anything else you can get. I respect good engineering from any source.
Altivec should be better than the PIII extensions (trinary ops -- yeah!).
The upcoming system architectures look good. They have a shot at it, but
they won't make it if they complacently think "oh, we are already faster
than any pc system".
My twin turbo F50 can still be outrun at the dragstrip by much cheaper
race cars. Many ferrari owners would not dare set foot at a drag strip,
because they fear objective measurements that may not show their important
possession in the best light. I would rather have the facts, so I can base
future decisions on logical grounds.
4/24/99
-------
We are finally closing in on the first release of Q3test.
As you have probably heard by now, the first release in going to be the mac
version, probably followed by the linux version, and only then the
windows version.
Some of you are busy getting all bent out of shape about this.
We want to get a lot of people playing with the test to find bugs and
offer well thought out suggestions, but there are classes of bugs and
suggestions that emerge in each order of magnitude of exposed testers.
If a given bug is going to show up when a thousand people have looked
at it, but we had released it to a hundred thousand people, then we are
going to have a lot of duplication to wade through.
The mac testers will find some obvious problems.
We will fix them.
The later releases will be better.
Even if we had the windows distribution ready to go right now, I would
still seriously consider releasing one of the mac or linux versions first
because it will make our tracking a lot easier.
The holdup on the windows side are the issues with updated driver
distribution. The game itself doesn't have any holdups.
We could do a windows release for just, say, voodoo2 owners and get some
of the benefit of a controlled release, but it wouldn't really work out,
because everyone would figure out that it can be made to (almost) work
on lots of other cards by tweaking some values. That type of feedback
would not be useful, because we KNOW that there are problems with most
of the current drivers. We have been working with all of the vendors
for the past year to get them all straightened out.
Glsetup is going to be slick -- just run it and it will Do The Right Thing
for your video configuration.
We hope it will be done soon, but there are factors out of our direct
control involved.
Don't be spiteful. This is just the beginning of the testing and
release process.
One conspiracy theory suggests that Apple is somehow getting us to do this.
What we have "gotten" from Apple is a few development machines. No
cash payoff. No bundling deal. No marketing contract.
I am looking at this long term. I want to see OS X become a top notch
platform for graphics development. I think highly of the NEXTSTEP heritage
and I might move my development from NT if it turns out well. There is a
lot of groundwork that needs to be laid with apple for this to happen,
and my working on the mac right now is part of that. Plus a lot of
complaining to various apple engineers and executives. :-)
To be clear:
At this time, there is no mac that is as fast for gaming (or just
about anything, actually) as a pentium III with a top of the line 3D card.
Period. I have been misquoted by some mac evangelists as saying otherwise.
The new (blue and white) G3 systems are very good systems in many ways, and
make a perfectly good gaming platform. However, a high end wintel machine
just has more horsepower on both the CPU and the 3D card.
A 400 mhz G3 performs about the same as a 400 mhz PII if they aren't fill
rate limited, where the faster cards on the PC will give about a 25%
advantage. A 500 mhz PIII with an appropriate card in 30% faster than
the best mac you can buy.
The multi colored iMacs, old G3 desktops, and powerbooks can play Quake3,
but the RagePro 3D acceleration defines the absolute bottom end of our
supported platforms. A serious gamer will not be satisfied with it.
Voodoo cards are not currently supported by the OpenGL driver, which is
very unfortunate because many serious mac gamers own voodoo cards. I
hope Apple and 3dfx will be able to correct this soon, but I certainly
understand Apple's prioritization -- obviously, good support for the OEM
video options is of primary importance.
The voodoo performance will still lag the windows platform by some amount,
but some strides have been made in that area recently, so I expect good
performance,
Gaming is not a reason to buy a mac, but Apple is taking steps so that
it may not be a reason to avoid a mac if you have other reasons for wanting
one.
MacOS still sucks.