(06/08/2005)
It's been a good while since I've updated the ol' plan. Been pretty busy. Abby is now almost 4 months
old. I attribute my sleep deprivation to her sleep schedule. :) Work keeps me busy. My main focus right
now is the Jupiter technology. There's close to Eleventy Billion(tm) items on my worklist, so I won't 
post that here. Needless to say, the DirectX 9 functionality is getting a bit of my dev time. 

I wanted to chime in on the whole Apple switching to Intel processors issue. It seems that certain 
folks in the Linux camp are getting bent out of shape on the possibility that this is will in some 
way affect the Linux market share. Is OSX going to be open source? no... So, I take that with a 
grain of salt. The issue that really bugs me is that folks are upset about Apple allowing the 
ability for people to dual-boot to Windows, or the fact that they aren't currently planning to 
actively block this action.An example of what I find most hypocritical about a majority of Linux 
evangelists can be found in the games industry. One of the big arguments for "Linux Desktop Adoption
Rate" is that developers should be creating AAA game titles exclusively for Linux in order to gain
the competitive edge. Not only is this not cost effective in most cases, it goes against the spirit
of Linux and the open source model. Microsoft is the favored target for the argument against proprietary
systems and applications. What's being suggested is to use the very same mentality that Microsoft
has been continually accused of using for the past 10+ years. It's the core ideology of the open
source movement to allow every one the ability to do whatever is it that they want to do, not to 
block it! Sometimes I'm just baffled by people... That being said, I'm a proponent of Linux. I'd 
love to see it continue to succeed. I just don't agree with certain proposed tactics. 

(01/07/2005)
First off, Happy New Year! As you might have noticed on the main page, We're expecting a little
girl soon. The due date is Feb 23rd, 2005. Kimberly and I are very excited to see little Abby. 
We just finished the final piece of the Chicago Enforcer project. It's off to testing, and should
go out to Microsoft for final approval on Monday. We're working on pushing out a new version of the
Jupiter 3D Technology SDK. (The 3D engine behind No One Lives Forever 2 and Tron 2.0) We've added
DirectX 9.0 support, and tons of bug fixes. I recently wrote a general debugging doc that's going 
in as well. I'm planning to make a public domain version of the doc as well.

(10/12/2004)
Well, it appears that I've been busy for quite a while now. We're putting the finishing touches
on Chicago Enforcer (Xbox). That has consumed most of my time. I'm looking forward to not having
to look at bug lists all day. 

(7/23/2004)
Wow, it's been almost two months since I've updated this page. I've been very busy with
work and personal stuff. So far on MobEnforcer Xbox, we've implemented system-link(LAN)
and Xbox Live support. You can currently play multiplayer games via LAN or Internet. Today
I'm working on the simplified auto-aim system, to compensate for the difficulty in aiming
with an Xbox controller when compared to using a mouse. Other than that, I've very very
tired. :)

(5/28/2004)
Well, it's been a busy few months for me at work. We recently sent our gold master of
MobEnforcer to our publisher, ValuSoft. So, I'm expecting to see it on the shelves
sometime in June. When I have more information on that, I'll post it here. The next step
for Duke is to get the -netmode_stable networking to function with the full 8 players.
I can't give a firm date on when I expect to have that in however. We're now working on
the Xbox version of MobEnforcer, with full Xbox Live support... So, I have a busy schedule
ahead. There may be a few releases before the networking code gets touched.

(4/12/2004)
I'm currently looking into why it is that the optimizations are killing the -game_dir 
option and the pig cops. It seems that with a few tweaks I'm able to get the flying pig
cops back and active, but the -game_dir option is still not happy. I need to hurry up and
get a 9.1 build out that fixes those two issues. 

(3/31/2004)
Well, It's been quite a while since my last update. Been very very busy. I'm planning
to put together a release for tonight. This release will include the new OGG/.S3m/etc.
drop in music support. Also, a unified networking solution including the old net code, 
for those who are happy with it, and a new 2 player stable networking mode. The 2 player
version uses the enet networking library. This was originally an experiment to see
if sending guaranteed packets was even feasible for Duke3d_w32. It has actually worked
out quite well. One user described it as “flawless”. I’m not sure if that was over LAN 
or the net. I’ve also made a few modifications to the SDL library to fix a few environment
variable issues. Basically it would cause certain OSs to run windowed mode in directx 
instead of windib, causing major performance issues. (Windows 2000 specifically)  The first 
version of Setup_w32 will be included. It’s very limited at this time. I’m hoping someone 
out there will pick it up and fill out the missing features. I’ve got to review my perforce 
change logs to determine exactly what else I fixed/added.  :)


(2/13/2004)
I did a bit of work tonight on Duke. First I started on a user map menu. That's going 
fairly well. It sook me a while to get my math correct on the back drop. Sometimes 
I wonder how I tie my shoes in the morning. After working on that a bit. I looked into
adding OGG and MP3 support since SDL_Mixer supports it. That will definitly be in the 
next build. I did a test of replacing grabbag.mid with Lee Jackson's hi-def MP3. Actually
I converted it to OGG since I need the smpeg library to compile MP3 support into SDL_Mixer.
I'll probably grab that from Icculus.org tomorrow. The hi-def version of grabbag sounds
pretty darn cool in the title screen. Anywho...

(1/14/2004)
I was able to do some testing tonight with the experimental 18.5 net code. It performed 
about what I expected of it. One game it worked quite flawless. Another game was pretty 
good minus a bit of lag. Neither game went "out of sync". With the 18.4 net code the
game went out of sync with in a few minutes of playing with the same person. The 18.4
code is very dependant on having a stable connection. Overall I'm very happy with 
the 18.5 net code experiment. I need to get it working with the full 8 players, then
move on to more exciting net stuff. (Thanks for the help Killa)

(1/13/2004)
I've had one confirmation that the new experimental net code works across the net. I'm 
pretty happy to hear that. I really wasn't too sure how it would perform. The test
was between two machines. I'll really be interested to see what happens when I get the
code working with more than two machines.

(1/11/2004)
Ok.. well that was a long day. I spent somewhere around 15-16 hours on the net code today.
I've got it ported over to the ENet library. I'm pretty happy with it currently. It works
pretty well between two machines. (it's currently limited to two machines) I would expect
it to be fairly sluggish over the net. The reason for that is that every packet is sent 
guaranteed. It's all UDP, but the ENet lib handles packet transport. Really this is an 
experiment to see just how laggy sending every packet guaranteed will actually be in duke. 
What I'm most likely to do is send logon/logoff/chat etc as guaranteed, and movement as 
not and just fix the way duke handles dropped packets. We'll see. I'll probably produce 
several test versions to see what happens.

For the crazies.. (This is NOT compatible with any other version of duke3d_w32)
http://www.rancidmeat.com/projects/duke3d_w32/duke3d_w32_net_dev_18.5.zip

(1/09/2004)
I finished playing around with the test app. I've begun reworking the duke3d_w32 net code with
the ENet lib. It's going fairly well. So far I've got them connecting to one another. I've
tested this with 3 machines. There seems to be a few inconsistancies in establishing connections.
That's something I need to sort out yet. Overall I'm happy with the progress. Basically I should
have something up and running this weekend. When it's ready I'll probably pass it off to AddFaz
for a round of testing. (as he has been quite happy to do) All of this is assuming nothing
evil pops up to steal my time away from me.

(1/08/2004)
I've been playing around with the ENet networking lib a little bit to better familiarize myself
with it. I created a small test app that runs on two machines and ping/pongs eachother. That
seems to work quite well. I'm going to try a few more tests, then work on integrating it into
the current duke net code. It should be fairly straight forward if my tinkings are any 
indication. We'll see how it reacts in a real world test. 

(12/30/2003)
I've implemented some new Duke3d router changes from AddFaz. I've sent a test build off to him 
for testing. My current goal is to strip mmulti.c down and reimplement the core winsock 
functionality with the ENet networking library. ENet is a lightweight UDP packet handling
library. It appears to have all of the features(plus more) that I was planning to implement in 
Duke3d_w32 in order to reduce/eliminate the "out of sync" errors that sometimes pops up in internet
play.

(11/08/2003)
So, The Tron 2.0 DM patch is out.. now life can somewhat return to normal for me. So, hopefully
that menas I can get some more work done on Duke. I'm planning to release an update soon. 
We'll see what "soon" means. I'm hoping this weekend. I believe the code is in a very usable
and stable state. I'll do some rough testing over here, then package it up. The setup.exe 
replacment app won't make it into this release, but that's ok.

(10/25/2003)
Well, it's been quite a while since I've updated the plan. Duke development has been slow
this month due to work stuff. One word, "Tron". More details later... I hope to get a
Duke build out pretty soon now. I probably won't get done what I wanted to for this release, 
and that is, the setup.exe replacement app, but that's ok. Build 18 will pretty much just 
contain bug fixes, and updated documentation. There are some new things, like Addfaz's router
netcode and autoaim toggle changes. I've also reworked the keyboard input to actually 
function as it was originally supposed to. Now, you'll be able to bind the mouse and keyboard
buttons to the same things. This was mostly annoying when you wanted the mousewheel for
switching weapons. It flat out didn't work. Now it does! :)

//-----------
// Duke3d
//-----------
Build 19.2 is now out. I've converted the VC.NET project to use a.c instead of a.asm. This allows me to enable
full compiler optimizations without it linking a bad build. In theory, this should allow for faster execution.

...Joystick support is in Build 17! Build 17 is out!

TODO: (no specific order)
Current Priority is finishing off Joystick support.
 -build:    Look into making a win32 build of.... build..
 -Code:     Refactoring of the source. (to C++?)
 -Console:  "level" check for "level 5 5" since it does not exsist.
 -Console:  shift is broken for chars like !@#$% (use "ToAscii" win api call on win32 systems)
 -Console:  Setconsolecolor needs to validate it's data.
 -Console:  Work on piping important printf() calls to CONSOLE_Printf()
 -Console:  Add the ability for each console entry to have a different color
 -Crash:    Crashes reported in several levels. Need to test out a wide variety of maps.
 -debug:    Get Mini Dumps working for debugging user crashes.
 -docs:     Add autoexec.cfg section to .CHM docs
 -docs:     trouble shooting.. (disable Cubic Interpolation if you're crashing)
 -docs:     how to submit a bug report
 -Input:    Look into integrating Kode54's mouse sensitivity changes. (add a cvar for enabling/disabling it)
 -Input:    Add Mouse flipping console command
 -Input:    Mouse-based menu navigation(mostly done)
 -misc:     Look into game crash when Duke dies. (still unable to confirm this bug)
 -misc:     User map browsing
 -misc:     Add data file checksumming.
 -misc:     Add /disableautoaim command line param.
 -net:      Implement ENet networking code instead of the current hack-mess known as mmulti.c
 -net:      Finish LAN connection in-game gui. (this is taking longer than I would like)
 -net:      Finish Linux side of DukeNet
 -Renderer: Voxels? (cDuke3d-ish)
 -Setup:    Work on "setup" app.
 -Sound:    "stalker.mid" plays when reloading saved games.
 -SDL:      Update to SDL 1.2.6

DONE: (recently)
 -Console:  (DONE)pause the game in singleplayer when the console is down.
 -Console:  (DONE)Add auto-aim toggle
 -Crash:    (FIXED)Multivoc crashes on Area51 in debug. voice->GetSound ends up null sometimes for some reason. Odd...
            ->Cubic Interpolation seems to be the cause... need to research.
 -Crash:    (FIXED)"crashes in the secret level "Launch Facility" of episode 1" (From bug report)
 -Input:    Add Chris Marsh's Mouse sensitivity console command(DONE)
 -Input:    (DONE)Look into mouse wheel support(Down works, Up always moves forward)
 -Input:    (DONE)Fix ControllerType 7 so that the keyboard is also fully functional.
 -Input:    (DONE)Add Joystick "top hat" support.
 -misc:     (DONE) (via -game_dir) Total Conversions stored in seperate directories. (perhaps a TC directory?)
 -misc:     (DONE, console)Look into a commandline option to disable autoaim(mainly for multiplayer)
 -net:      (DONE)Add AddFaz's NAT code.
 -net:      (FIXED/HACKED)Crash when you shoot the blimp in multi
 -Renderer: (FIXED)Look into fixing renderer slugishness
 -Web:      (DONE)Add Dukester X and AcrSetup to 3rd party section (AcrSetup link is dead)

//-----------
// Build-Lib
//-----------

For those who don't know, this is a C++ library for interacting 
with Build-engine(duke3d) file formats such as .GRP, .MAP and .ART. 
It can read each format into a data stucture thus exposing the data
to an application. I currently need to make one optimization. Right
now, when you open a .GRP file, it reads the entire thing into memory.
What it "should" do, is read just the file index into memory, then when
you need to access a file in the .GRP, it will read that data in.