Nathan Mates' Personal Info Pages

Nathan Mates's .plan Archives

Plan Archives from March 1999.

[visi.com] 
Login name: nathan    			In real life: Nathan Mates
Directory: /home/nathan             	Shell: /bin/tcsh
Plan:

Job: Network Programmer, Battlezone 2, developed by Pandemic Studios http://www.pandemicstudios.com , published by Activision http://www.activision.com [Note: in this, I am *NOT* speaking officially for either of those, I'm only speaking for myself.]

3/31/99, Afternoon: Had a few hours to spare, so implemented most of my ideas for shrinking the average packet size down... 25% off an already pretty darn small number impressed me a lot-- and I may revisit parts of this code later, as I've still got a few ideas for crunching things more. [I run 4 compressors against each other on all data, and pick the best result of the lot, plus other stuff...]

3/28/99: Yet another NathanRant(tm). Regular Unleaded gasoline: $1.45/gal today at gas station nearish work in Santa Monica. What a ripoff...

3/26/99: Been collecting stats on average packet size and bytes transmitted during multiplayer games. While I can't give raw numbers without getting in trouble, I'll just say that the other programmers on the team were quite happy with the bandwidth used... and I've been mulling over ideas in my head for knocking that figure down 10-33% more. I plan to bring in one of my linux boxes from home to packetsniff and see exactly how big the DirectPlay headers are on them (if any), and get some better ideas on where the unnecessary bits are. I don't think I'll be fully happy with everything until I hear of the beta testers and end users having a good experience...

3/20/99: Another subject I figured I'd have to comment on eventually came out of a mention of the usenet group 'alt.games.battlezone' on the official BZ2 discussion board. Here's my take on it-- I've been on usenet since the fall of 1992, and know my way around it.

--- snip

That's a sore spot of mine, and I while I'm going to be somewhat yelling at the tide, let me make this very clear: making a usenet group for a specific game is a BAD IDEA. Let me repeat that: DON'T DO IT. DON'T PARTICIPATE. STAY AWAY.

alt groups have rotten propagation-- they're not carried everywhere. [at visi.com, the ISP account I pay for, it doesn't have that group. I could get it added in a heartbeat as I know the admin, but I won't.] Further, distribution of articles in them tend to be distributed slower or less accurately than proper groups.

There are 2 newsgroups where Battlezone should be discussed: comp.sys.ibm.pc.games.action and csipg.strategy. Those groups, as part of the big 8, have proper coverage to just about everywhere, with more reliable distribution. You should use them. Yes, you *will* have to share the newsgroups with other action and strategy games, but if you can't handle them, then learn to set up a usenet killfile and ignore posts on other games. [Tip: just about every web browser that try and fool you into thinking they're a usenet reader don't do killfiles. Don't be fooled, and get a *proper* newsreader, one built for the job.] I already read csipg.{action|rpg|strategy}, and with some killfiles, it's quite manageable to read all of those three every day.

My bottom line: I do not support alt.games.*. I will never subscribe to there, and will remove crosspostings to there from csipg.* whenever possible in a followup I make from my personal account. Do NOT participate in the alt.games.* nonsense, stay away from them, and all will be much better off for it.

Here endeth my rant. :)

--- snip

3/19/99: I've been a bit active on the official BZ2 website's discussion board, and a subject I covered on 2/20/99 (see .plan archives linked in from my website above), and one thing that's kept coming up is 3DNow support and the like. *PLEASE*, folks, read my 2/20/99 writings, as well as this bit I just wrote for the boards before you even think of asking for support for X in the game:

--- snip
We're a DirectX 6 game, using DirectX 6 video card drivers. DX6 and your drivers can eat *OVER* 50% of cpu time-- get them optimized first, and games much later. So, get K6-3D happy DX6 and DX6 drivers, and you'll probably get more speedups than from bugging us.

I've commented on this more in my .plan archives at http://www.matesfamily.org/cgi-bin/plan.html -- 3DNow, Katmai (Pentium 3) and the like are MORE work for the developer to support within the game. Period. I personally do NOT like having work dumped on me, and I really don't like CPU makers trying to segment up the market and getting ravenous fans attacking developers. [See the 2/20/99 update for my .plan comments on this.]

Consider this: every hour of coding to support piece of hardware X is an hour not going into something else in the game that everyone can enjoy. Be sure you know what the heck you're asking for will mean before speaking up.

Also, when a new video board comes out, do we have to do extra work to support that? No. We just shove polygons at it, and it does them faster than previous video boards, but there's ZERO extra work for us. That's the way it should be-- zero work for the developer, all the work on the part of those who made piece of hardware X. One HW maker doing the work is MORE efficient than every dang games developer jumping thru hoops for the HW makers.

--- snip

3/18/99, Later: Sad day here at the offices: the fridge is out of Coca-Cola products. [Except for this 'Diet' gunk.]

3/18/99: Red Odyssey (BZ1 addon) demo is out; see your favorite PC gaming news site or www.bz2.com if you don't read the news. Red Odyssey isn't being done by us here at Pandemic, but at Team Evolve, so don't ask for tips, suggestions, or the like from me. I wish Red Odyssey all the best, as better sales of that will probably indicate more sales of BZ2. :)

Work continues here ar Pandemic; I'm trying to nail down some inconsistencies in network play that only show up in the retail builds and not the debug builds I normally play...

3/16/99: BZ2 official site is up. See http://www.pandemicstudios.com/bzii/index.html

3/15/99: Due mostly to inaction on my part, I'm not going to be attending the Game Developer's Conference (GDC) this week. Some employees from Pandemic Studios are going and presenting, but most of the rest of us wouldn't. Oh well. I should be going to E3, though, as it's in Los Angeles (and Pandemic is in Santa Monica).

3/13/99: After dismissing the "49.7 day maximum uptime" limit present in Win95/98, it looks as if my system at home is trying to do a serious run at that limit. (Uptime in general is how long it's been since the computer was last [re]booted; it can also be applied to an app's uptime. Uptime is something of a measure of confidence in the OS and hardware-- being able to run for a year between reboots is a far better system with an uptime of only a few days. I've had some Linux boxes of mine running for almost a year before the power company decided to kill power longer than the UPS could handle.)

Anyhow, according to Norton System Doctor, it's just 5 minutes shy of having an uptime of 2 weeks on my Win98 box at home. I'm very impressed-- this is while I've played tons of games, rc5 cruncher keeping the processor busy 100% of the time, web browsing, emails, running the spinner.com player, and emacs for Win9x.

Now if Win98 would last 1.4 days at work, I'd be even happier. I think MS Visual Resource Hog (DevStudio) and/or running development versions of BZ2 kill the machine after a few hours of work. Blech.

3/10/99: Based on some feedback, let me clarify what I wrote yesterday:

(1) You can still have infinite time and/or kills for a multiplayer game.

(2) If you *choose* to limit, the limits are 1-99 minutes and/or 1-99 kills. You could set infinite time and 50 kills, 30 minutes and unlimited kills, 5 minutes and 5 kills, or any other similar setup. [Whatever condition is met first ends the mission, so 5 minutes/5 kills could be over in a minute if someone racked up 5 kills in that time. Or, if everybody was pacifists, the 5 minute timer would end the game.]

Clear as mud now? :)

3/9/99: Rudimentary chat is in the game shell, along with mission selection, and NO MORE TYPING IN IP ADDRESSES! [Well, I can deal with numbers just fine, but I think some users would get annoyed. :] In the process of implementing multiplayer end of game conditions for the new DLL spec, like a time limit (1-99 minutes, or infinite), # of kills, and other stuff. In-game chat should be in soon.

[By the way, anyone think that 99 minutes or 99 kills is too short for a strategy or deathmatch game? Currently, you can enter a number from 0 to 99, with 0 being infinite time/kills. I might up the limits to 999 or so just to be sure nobody will feel cramped.]

3/2/99: My jaw is still somewhere near floor-level with the specs sheets on the "Playstation2[000?]". [See http://psx.ign.com or any other gaming site that covers consoles.] First off, I had to check the date on my wristwatch. No, it's not 4/1/99. I'm still somewhat in shock over what Sony claims to have done, especially how far it is ahead of current PC titles.

A CPU of 300Mhz pulling 6.2 billion floating pt ops per second, capable of generating 75 million polys/sec. I don't have hard numbers, but that's probably on par with or in excess of current high-end CPUs (PentiumIII, Alpha, etc). With NURBS (curved surface) support via realtime tessellation and the like eating a good chunk of available FPU power (as it's apparently draw-limited to 20 million polys/sec), nice curved surfaces will be pretty darn cheap to free. And 20 million polys/sec reported speed is a bit more than double the Voodoo3's 9 million polys/sec.

What's this mean? First off, I think this is a serious wakeup call to PC 3D accelerators, though the V3 should be shipping in the next few months vs the PSX2's Spring 2000. By Spring 2000, I think 20 million polys will be available on the PC side, assuming those numbers don't go up in the meantime.

But, what I think this will be a big kick in the pants to the other limiting factors of PC games-- the making the main CPU (still) do a lot of work every frame. As I said in me 2/20/99 .plan update, profilers have found the 3D drivers and DirectX/D3D taking up more than 50% of CPU time while games are running. Now, compare that to the CPU usages of the Aureal chipsets and the Soundblaster Live-- those 3D sound cards are under 5% of CPU time. What's the difference? 3D sound is done almost completely on the card's silicon, not host CPU. I think that to get further speedups, a PSX2-like geometry processor and/or specialized CPU will enable more work to be shifted to the 3D card.

If on-3D card fpu and/or geometry accelerators become more common, Intel and AMD are going to be in trouble. Say game X gets 30fps on cpu/speed Y, with graphics card Z's drivers eating 50% of CPU time. Graphics card W comes along with drivers that only eat 25% of the CPU for the same polycount, efx, etc. You've just increased CPU time available to the game by 50%, enabling a framerate boost to 45+fps. Nice big improvement, and the CPU didn't need to get upgraded. This is another reason why I believe CPU makers are pushing "geometry acceleration" onto the chip, but if a cheapo 3D card does geometry acceleration better, all the CPU maker's work is in vain. Just gimme a PSX2 on my next videoboard inside my PC, and I'll be VERY happy. :)

Next, the PSX2 demos looked pretty darn close to what we're used to for prerendered FMV. But, it's realtime. FMV better take a HUGE step forward soon, or your home console will look better in realtime than Bug's Life. Games are going to start looking VERY dang pretty in realtime; if you're at all interested in creating computer art, there's going to be a HUGE demand for artists as games are forced somewhat to look like the FMV we're used to now. I feel that gameplay's *still* more important than graphics, but that's going to be VERY pretty-looking gameplay soon.

I have a background in console (Saturn, PSX, 8/16 bit home PCs which were pretty close in some respects to consoles) and PC development (DirectX). Right now, the PSX2 has taken a *huge* step forward ahead of any current PC; PCs will most likely have some high-end gamer rigs near PSX2 by summer 2000, with mass consumer-level prices by a year later. [Yes, I'm rooting for PCs right now simply because that's what I'm more familiar with, and I play more games on my PC... sit me down with a PSX2 devkit for a few months, and that may change. :}

This is certainly an exciting time to be in the computer games business-- both as a developer and a gameplayer. Performance is going through the roof, and yet there's still been a LOT of good games released recently. Good gameplay, good graphics, I ain't complaining.

3/2/99: Finally got around to keeping only about 2 week's worth of .plan updates in the fingered plan (which is mirrored automatically to my website). Archives are being kept by month on my website, so that should be a semi-permanent record.

3/2/99: Whoo. Network's User Interface mini-milestone of seeing LAN games listed in the shell and being able to point-and-click at them instead of manually typing in IP Addresses is working. [Though something broke in the craft movement and smoothness code since mid last week when I last did a multiplayer game... gotta figure out the source of that.] The interface still needs a lot of polish, but it's a nice step forward.

I also need to trim out older .plan updates into separate webpages to keep things smaller and more tidy; should get around to that later tonight when I get home.

3/1/99: 'Mattrox' pointed out to me that re my screen centering problems with my new TNT board, there's a refresh rate setting in the Display Control Panel -> Settings -> Advanced -> Refresh Rate. My monitor just couldn't keep the display centered at 1152x864x85Hz refresh rates (while 1024x768 was fine). Dropping the max refresh rate down to "only" 75Hz fixed the problem, and my screen's now nicely recentered at 1152*864*16bpp*75Hz. Just in case any of the rest of you folks are having similar problems, that's the solution that just worked for me.

[And, if you haven't read the some of the latest .plan updates from Dave Moore at Dynamic suggest that with the current round of TNT drivers and Tribes 1.3, a Voodoo1 is experiencing faster texture download speeds than a TNT board. Sure makes me feel happy I've still got my Voodoo1 in my new system-- Tribes is definitely* a lot faster and smoother with a PII-350 and Voodoo1 vs a P200+Voodoo1. Nice to see a video board I bought years ago not maxxed out by a P200.]

3/1/99: More Microsoft bashing somewhat related to BZ2. [Non-programmers can skip this technical explanation, except for the fact that Mr. Bug Magnet (aka Nathan Mates) ran into another one in MS products. So what else isn't new?]

MS DevStudio 6 (and VC++6.0 + SP1) can't keep dependencies straight if 2 .h files have the same name, yet reside in different folders. As of last Friday, I split functions off d:\bz2\source\network\util.h to more logically organize the code. [Stuff like [delta]-RLEing of bytestreams and other stuff.] All my other network files (residing in the network folder) did a '#include "..\Network\util.h"' to make it very clear what they depended on. There's no way that #include could refer to any other file than the one I wanted.

So, of course, I want to modify network\util.h to add in a new function today, and notice that my network files aren't being rebuilt. Ok, try and update dependencies. No deal. Delete all intermediate files and rebuild all. No luck. Finally, I try modifying network\NetInternals.h, and notice things rebuild properly. Hmmm. Looking around in the project, there's no other file named 'util.h' in our source code. Rename util.{h|cpp} to NetUtil.*, and things suddenly are happy. [Well, except for MS Visual Sourcesafe *once again* mangling our .dsp on a merged checkin...]

Appeal to Bill Gates: fire all your lawyers and marketing weasels, and use the money saved to hire some competent beta testers. People won't have such a deep distrust of MS if they continue to shovel out such buggy crud.

nathan.j.mates@gmail.com