Speed Bumps

It seems that I have lost a server which was hosting the source code. I will try and buy a new system this weekend.

Doom Filesystem, WADFS

Just finished up the wadfs, this exports WAD game content as a filetree or service. This allows anyone to overlay static content with another PWAD or even custom files. However the interesting thing is one could even overlay with a custom program, that's right, one could write procedural texture code and mount it over the existing texture and have some dynamic content. This would require the engine know when to re-cache the data, this could be implemented as a file that dynamic content programs just send a "updated WIMINUS" message to.

term% games/doomfs -m mnt wad /usr/james/lib/doom/doomu.wad
DBG: numlumps = 2306
DBG: tableofs = 12371396
term% lc mnt/E4M2
BLOCKMAP NODES SECTORS SIDEDEFS THINGS
LINEDEFS REJECT SEGS SSECTORS VERTEXES
term% ls -l mnt/WIMINUS
--r--r--r-- M 270 doomfs doomfs 80 Mar 17 21:30 mnt/WIMINUS
term% xd mnt/WIMINUS
0000000 06000300 0000fbff 20000000 28000000
0000010 30000000 38000000 40000000 48000000
0000020 0003bfbf bfbfbfff 0003bfbf b4bfbfff
0000030 0003bfbf b4bfbfff 0003bfbf b2bfbfff
0000040 0003bfbf b1bfbfff 0003bfbf bfbfbfff
0000050
0000050
term% unmount mnt
DBG: wadfs end



Doom Filesystem?

After deciding to look at the gamestate, Uriel had some good suggestions on exposing the internals as a filesystem. Since I am new to Plan9 I thought I'd tackle this later, but I thought I would at least try it out first, and it turns out to be easier than I thought so I started prototyping it.

term% doomserver -m mnt
doomserver> startup
term% ls -l mnt
d-r-x-r-x-r-x M 129 doom doom 0 Mar 13 20:22 mnt/clients
d-r-x-r-x-r-x M 129 doom doom 0 Mar 13 20:22 mnt/edicts
--rw--rw----- M 129 doom doom 0 Mar 13 20:22 mnt/servercmd
term% cat mnt/servercmd
Server Commands
fraglimit <#>, 0 - no limit
timelimit <#min>, 0 - no limit
term% echo fraglimit 10 >mnt/servercmd
term% unmount mnt
doomserver> shutdown

An enumerated list of clients are in clients/ which expose the client/server networking interface. Likewise, the game logic can interact with edicts/ to update their gamestate. Traditionally in other operating systems this is done through the use of dynamic libraries, but because everything is a file there is no restriction on what programming language or even shell script can be used. Want to play with genetic evolution of bot AI code? Let them duke it out in the arena. How about a massive online DOOM FPS? Distribute the clients and server states across many servers.

Game State Rework Needed

The current implementation of the Doom game state has been causing some problems.

• Audio playback speed changes.
• User input events get dropped.
• Not well suited for Internet play.

The first two appear to be related with the rendering frame rate. After forcing a ~35fps frame rate I noticed the audio plays back just fine. Also, after forcing the "singletics = true" which is a debug mode, the mouse/keyboard input worked just fine. (Which is good as it means my custom Plan 9 input driver is working out).

Since I will probably have to rework the game state to allow for Internet play anyways, I'm going to spend a week or two on a rewrite of the internals. This should allow a playable yet probably un-stable version.

Rendering Complete

I've worked out the scaling issues, and now the title screen, sky and player sprites scale with the window dimensions. Next I will work on completing a new /dev/input driver for Plan9 that will be suitable for handling keyboard/mouse/joystick inputs.

Plan9 Doom Port - SOUND!

After finding and fixing the AC97 driver bug, it took all of tonight to port the audio. So what's left?

• Raw Input Driver
• Scale titlescreen, sky and weapon textures
  
• Multiplayer netcode
• Allow for dynamic window resize
  

Plan9 AC97 Driver Bug

The AC97 driver was crashing the system, after taking a look I saw this in audioac97.c, ac97reset:

if(p->mem[0].size == 64){
  ctlr->port = p->mem[0].bar & ~3;
  ctlr->mixport = p->mem[1].bar & ~3;
} else if(p->mem[1].size == 64){
  ctlr->port = p->mem[1].bar & ~3;
  ctlr->mixport = p->mem[0].bar & ~3;
}

So what happens if neither size is 64? Crash.
My pci was showing sizes of 1024 and 256 for the audio device.
This is what I did to get it working:

ctlr->port = p->mem[1].bar & ~3;
ctlr->mixport = p->mem[0].bar & ~3;