Plan9 Doom Port

Color Conversion

2011-05-07T14:48:00.000-07:00

/* CMAP to RGB24 */
loadmemimage(cimg, cimg->r, screens[0], N);
memimagedraw(timg, timg->r, cimg, ZP, nil, ZP, S);

/* Memimage to Image */
unloadmemimage(timg, img->r, buf24, sizeof(buf24));
loadimage(img, img->r, buf24, sizeof(buf24));

Starting Over

2011-05-06T18:00:00.000-07:00

Had some time off from work, so I decided to redo the port from scratch because I simply couldn't find the original from backup and came up with this today. Need to figure out a nice way of remapping CMAP8 to 24bit displays as well as supplement the keyboard driver again. Oh well, the second time around I am doing more with less code.

Speed Bumps

2009-07-24T00:09:00.000-07:00

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

2009-03-17T15:37:00.000-07:00

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?

2009-03-13T13:27:00.000-07:00

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

2009-03-09T00:22:00.001-07:00

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

2009-03-02T22:57:00.000-08:00

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!

2009-02-28T02:10:00.000-08:00

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

2009-02-28T01:58:00.000-08:00

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;

Stable Rendering

2009-02-21T17:17:00.000-08:00

What's left on rendering is translation of weapon and scaling of title screen, sky texture and HUD to custom screen dimensions. However it is quite stable right now, and is playing through the demos. Still looking for a good solution on keyboard input on Plan9.

Doom Plan9 Port

2009-02-20T00:51:00.000-08:00

I have a port of Doom to Plan9 in the works. Most of the effort so far has been in the support of resolutions other than the original 320x200. Despite the picture shown here, the status bar is working, but the ceiling/floor draw functions need to be altered to cope with different vertical resolutions.

So far it is rendering very fast, the original code is well optimized already. I cannot use the Plan9 standard interface for input due to lacking of detection of key-release and do not want to hack it up.

First impressions of Plan9 are positive, access to PC registers is nice and reminds me of some of the older days of programming, while at the same time I get to use modern hardware with a modern OS.