Skip to content
Browse files

The DOOM sources as originally released on December 23, 1997

0 parents commit 4eb368a960647c8cc82d721d0183629ae10759d1 @tbradshaw tbradshaw committed Jan 31, 2012
Showing with 22,813 additions and 0 deletions.
  1. +78 −0 README.TXT
  2. +109 −0 linuxdoom-1.10/CVS/Entries
  3. +1 −0 linuxdoom-1.10/CVS/Repository
  4. +1 −0 linuxdoom-1.10/CVS/Root
  5. +922 −0 linuxdoom-1.10/ChangeLog
  6. +112 −0 linuxdoom-1.10/DOOMLIC.TXT
  7. +98 −0 linuxdoom-1.10/FILES
  8. +221 −0 linuxdoom-1.10/FILES2
  9. +95 −0 linuxdoom-1.10/Makefile
  10. +283 −0 linuxdoom-1.10/README.asm
  11. +140 −0 linuxdoom-1.10/README.b
  12. +57 −0 linuxdoom-1.10/README.book
  13. +149 −0 linuxdoom-1.10/README.gl
  14. +110 −0 linuxdoom-1.10/README.sound
  15. +123 −0 linuxdoom-1.10/TODO
  16. +1,349 −0 linuxdoom-1.10/am_map.c
  17. +52 −0 linuxdoom-1.10/am_map.h
  18. +701 −0 linuxdoom-1.10/d_englsh.h
  19. +122 −0 linuxdoom-1.10/d_event.h
  20. +433 −0 linuxdoom-1.10/d_french.h
  21. +138 −0 linuxdoom-1.10/d_items.c
  22. +52 −0 linuxdoom-1.10/d_items.h
  23. +1,171 −0 linuxdoom-1.10/d_main.c
  24. +64 −0 linuxdoom-1.10/d_main.h
  25. +767 −0 linuxdoom-1.10/d_net.c
  26. +149 −0 linuxdoom-1.10/d_net.h
  27. +219 −0 linuxdoom-1.10/d_player.h
  28. +51 −0 linuxdoom-1.10/d_textur.h
  29. +79 −0 linuxdoom-1.10/d_think.h
  30. +53 −0 linuxdoom-1.10/d_ticcmd.h
  31. +222 −0 linuxdoom-1.10/doomdata.h
  32. +38 −0 linuxdoom-1.10/doomdef.c
  33. +338 −0 linuxdoom-1.10/doomdef.h
  34. +46 −0 linuxdoom-1.10/doomstat.c
  35. +296 −0 linuxdoom-1.10/doomstat.h
  36. +66 −0 linuxdoom-1.10/doomtype.h
  37. +72 −0 linuxdoom-1.10/dstrings.c
  38. +66 −0 linuxdoom-1.10/dstrings.h
  39. +738 −0 linuxdoom-1.10/f_finale.c
  40. +53 −0 linuxdoom-1.10/f_finale.h
  41. +302 −0 linuxdoom-1.10/f_wipe.c
  42. +71 −0 linuxdoom-1.10/f_wipe.h
  43. +1,690 −0 linuxdoom-1.10/g_game.c
  44. +79 −0 linuxdoom-1.10/g_game.h
  45. +354 −0 linuxdoom-1.10/hu_lib.c
  46. +196 −0 linuxdoom-1.10/hu_lib.h
  47. +759 −0 linuxdoom-1.10/hu_stuff.c
  48. +66 −0 linuxdoom-1.10/hu_stuff.h
  49. +45 −0 linuxdoom-1.10/i_main.c
  50. +348 −0 linuxdoom-1.10/i_net.c
  51. +45 −0 linuxdoom-1.10/i_net.h
  52. +985 −0 linuxdoom-1.10/i_sound.c
  53. +122 −0 linuxdoom-1.10/i_sound.h
  54. +183 −0 linuxdoom-1.10/i_system.c
  55. +97 −0 linuxdoom-1.10/i_system.h
  56. +1,050 −0 linuxdoom-1.10/i_video.c
  57. +63 −0 linuxdoom-1.10/i_video.h
  58. +4,670 −0 linuxdoom-1.10/info.c
  59. +1,340 −0 linuxdoom-1.10/info.h
  60. +56 −0 linuxdoom-1.10/m_argv.c
  61. +42 −0 linuxdoom-1.10/m_argv.h
  62. +64 −0 linuxdoom-1.10/m_bbox.c
  63. +55 −0 linuxdoom-1.10/m_bbox.h
  64. +101 −0 linuxdoom-1.10/m_cheat.c
  65. +58 −0 linuxdoom-1.10/m_cheat.h
  66. +87 −0 linuxdoom-1.10/m_fixed.c
  67. +51 −0 linuxdoom-1.10/m_fixed.h
Sorry, we could not display the entire diff because it was too big.
78 README.TXT
@@ -0,0 +1,78 @@
+
+Here it is, at long last. The DOOM source code is released for your
+non-profit use. You still need real DOOM data to work with this code.
+If you don't actually own a real copy of one of the DOOMs, you should
+still be able to find them at software stores.
+
+Many thanks to Bernd Kreimeier for taking the time to clean up the
+project and make sure that it actually works. Projects tends to rot if
+you leave it alone for a few years, and it takes effort for someone to
+deal with it again.
+
+The bad news: this code only compiles and runs on linux. We couldn't
+release the dos code because of a copyrighted sound library we used
+(wow, was that a mistake -- I write my own sound code now), and I
+honestly don't even know what happened to the port that microsoft did
+to windows.
+
+Still, the code is quite portable, and it should be straightforward to
+bring it up on just about any platform.
+
+I wrote this code a long, long time ago, and there are plenty of things
+that seem downright silly in retrospect (using polar coordinates for
+clipping comes to mind), but overall it should still be a usefull base
+to experiment and build on.
+
+The basic rendering concept -- horizontal and vertical lines of constant
+Z with fixed light shading per band was dead-on, but the implementation
+could be improved dramatically from the original code if it were
+revisited. The way the rendering proceded from walls to floors to
+sprites could be collapsed into a single front-to-back walk of the bsp
+tree to collect information, then draw all the contents of a subsector
+on the way back up the tree. It requires treating floors and ceilings
+as polygons, rather than just the gaps between walls, and it requires
+clipping sprite billboards into subsector fragments, but it would be
+The Right Thing.
+
+The movement and line of sight checking against the lines is one of the
+bigger misses that I look back on. It is messy code that had some
+failure cases, and there was a vastly simpler (and faster) solution
+sitting in front of my face. I used the BSP tree for rendering things,
+but I didn't realize at the time that it could also be used for
+environment testing. Replacing the line of sight test with a bsp line
+clip would be pretty easy. Sweeping volumes for movement gets a bit
+tougher, and touches on many of the challenges faced in quake / quake2
+with edge bevels on polyhedrons.
+
+Some project ideas:
+
+Port it to your favorite operating system.
+
+Add some rendering features -- transparency, look up / down, slopes,
+etc.
+
+Add some game features -- weapons, jumping, ducking, flying, etc.
+
+Create a packet server based internet game.
+
+Create a client / server based internet game.
+
+Do a 3D accelerated version. On modern hardware (fast pentium + 3DFX)
+you probably wouldn't even need to be clever -- you could just draw the
+entire level and get reasonable speed. With a touch of effort, it should
+easily lock at 60 fps (well, there are some issues with DOOM's 35 hz
+timebase...). The biggest issues would probably be the non-power of two
+texture sizes and the walls composed of multiple textures.
+
+
+I don't have a real good guess at how many people are going to be
+playing with this, but if significant projects are undertaken, it would
+be cool to see a level of community cooperation. I know that most early
+projects are going to be rough hacks done in isolation, but I would be
+very pleased to see a coordinated 'net release of an improved, backwards
+compatable version of DOOM on multiple platforms next year.
+
+Have fun.
+
+John Carmack
+12-23-97
109 linuxdoom-1.10/CVS/Entries
@@ -0,0 +1,109 @@
+/ChangeLog/1.14/Mon Feb 3 22:45:08 1997//
+/DOOMLIC.TXT/1.3/Sun Jan 26 07:44:56 1997//
+/FILES/1.1/Sun Jan 19 17:22:41 1997//
+/FILES2/1.1/Sun Jan 19 17:22:42 1997//
+/Makefile/1.6/Mon Feb 3 22:45:08 1997//
+/am_data.h/1.2/Tue Jan 21 18:59:56 1997//
+/am_map.c/1.4/Mon Feb 3 21:24:33 1997//
+/am_map.h/1.2/Tue Jan 21 18:59:56 1997//
+/d_englsh.h/1.1/Mon Feb 3 21:48:03 1997//
+/d_event.h/1.2/Mon Feb 3 22:01:47 1997//
+/d_french.h/1.3/Mon Feb 3 21:48:03 1997//
+/d_main.c/1.8/Mon Feb 3 22:45:09 1997//
+/d_net.c/1.3/Mon Feb 3 22:01:47 1997//
+/d_textur.h/1.1/Mon Feb 3 16:47:51 1997//
+/doomdata.h/1.5/Mon Feb 3 22:45:09 1997//
+/doomdef.h/1.9/Mon Feb 3 22:45:09 1997//
+/doomtype.h/1.2/Mon Feb 3 22:45:09 1997//
+/dstrings.h/1.4/Mon Feb 3 21:48:03 1997//
+/dutils.c/1.5/Mon Feb 3 17:11:23 1997//
+/dutils.h/1.4/Mon Feb 3 17:11:23 1997//
+/f_finale.c/1.5/Mon Feb 3 21:26:34 1997//
+/f_finale.h/1.1/Mon Feb 3 21:26:34 1997//
+/f_wipe.c/1.2/Mon Feb 3 22:45:09 1997//
+/f_wipe.h/1.1/Mon Feb 3 17:11:23 1997//
+/fpfunc.S/1.1/Sun Jan 19 17:22:43 1997//
+/g_game.c/1.8/Mon Feb 3 22:45:09 1997//
+/g_game.h/1.1/Mon Feb 3 21:34:47 1997//
+/hu_lib.c/1.3/Sun Jan 26 07:44:58 1997//
+/hu_lib.h/1.4/Mon Feb 3 16:47:52 1997//
+/hu_stuff.c/1.4/Mon Feb 3 16:47:52 1997//
+/hu_stuff.h/1.3/Sun Jan 26 07:44:58 1997//
+/i_dga.c/1.3/Sun Jan 26 07:44:58 1997//
+/i_ibm.c/1.3/Sun Jan 26 07:44:58 1997//
+/i_main.c/1.4/Mon Feb 3 22:45:10 1997//
+/i_pcnet.c/1.3/Sun Jan 26 07:44:59 1997//
+/i_sound.c/1.3/Sun Jan 26 07:44:59 1997//
+/i_sound.h/1.3/Sun Jan 26 07:44:59 1997//
+/i_svga.c/1.3/Sun Jan 26 07:44:59 1997//
+/i_unix.c/1.5/Mon Feb 3 22:45:10 1997//
+/i_x.c/1.6/Mon Feb 3 22:45:10 1997//
+/info.c/1.3/Sun Jan 26 07:45:00 1997//
+/info.h/1.3/Sun Jan 26 07:45:00 1997//
+/irix.c/1.3/Sun Jan 26 07:45:00 1997//
+/irix.h/1.3/Sun Jan 26 07:45:01 1997//
+/linux.c/1.3/Sun Jan 26 07:45:01 1997//
+/m_argv.c/1.1/Mon Feb 3 22:45:10 1997//
+/m_argv.h/1.1/Mon Feb 3 22:45:10 1997//
+/m_bbox.c/1.1/Mon Feb 3 22:45:10 1997//
+/m_bbox.h/1.1/Mon Feb 3 22:45:10 1997//
+/m_cheat.c/1.1/Mon Feb 3 21:24:34 1997//
+/m_cheat.h/1.1/Mon Feb 3 21:24:34 1997//
+/m_menu.c/1.7/Mon Feb 3 22:45:10 1997//
+/m_menu.h/1.1/Mon Feb 3 22:01:49 1997//
+/m_misc.c/1.6/Mon Feb 3 22:45:10 1997//
+/m_misc.h/1.1/Mon Feb 3 22:45:11 1997//
+/m_random.c/1.1/Mon Feb 3 22:45:11 1997//
+/m_random.h/1.1/Mon Feb 3 22:45:11 1997//
+/p_ceilng.c/1.4/Mon Feb 3 16:47:53 1997//
+/p_doors.c/1.4/Mon Feb 3 16:47:53 1997//
+/p_enemy.c/1.5/Mon Feb 3 22:45:11 1997//
+/p_floor.c/1.4/Mon Feb 3 16:47:54 1997//
+/p_inter.c/1.4/Mon Feb 3 22:45:11 1997//
+/p_lights.c/1.5/Mon Feb 3 22:45:11 1997//
+/p_local.h/1.3/Tue Jan 28 22:08:27 1997//
+/p_map.c/1.5/Mon Feb 3 22:45:11 1997//
+/p_maputl.c/1.5/Mon Feb 3 22:45:11 1997//
+/p_mobj.c/1.5/Mon Feb 3 22:45:12 1997//
+/p_plats.c/1.5/Mon Feb 3 22:45:12 1997//
+/p_pspr.c/1.5/Mon Feb 3 22:45:12 1997//
+/p_setup.c/1.5/Mon Feb 3 22:45:12 1997//
+/p_sight.c/1.3/Tue Jan 28 22:08:28 1997//
+/p_spec.c/1.6/Mon Feb 3 22:45:12 1997//
+/p_spec.h/1.3/Tue Jan 28 22:08:29 1997//
+/p_switch.c/1.3/Tue Jan 28 22:08:29 1997//
+/p_telept.c/1.3/Tue Jan 28 22:08:29 1997//
+/p_tick.c/1.4/Mon Feb 3 16:47:55 1997//
+/p_user.c/1.3/Tue Jan 28 22:08:29 1997//
+/r_bsp.c/1.4/Mon Feb 3 22:45:12 1997//
+/r_data.c/1.4/Mon Feb 3 16:47:55 1997//
+/r_draw.c/1.4/Mon Feb 3 16:47:55 1997//
+/r_local.h/1.4/Mon Feb 3 21:26:34 1997//
+/r_main.c/1.5/Mon Feb 3 22:45:12 1997//
+/r_plane.c/1.4/Mon Feb 3 16:47:55 1997//
+/r_segs.c/1.3/Wed Jan 29 20:10:19 1997//
+/r_things.c/1.5/Mon Feb 3 16:47:56 1997//
+/s_sound.c/1.6/Mon Feb 3 22:45:12 1997//
+/sounds.c/1.3/Wed Jan 29 22:40:44 1997//
+/sounds.h/1.3/Wed Jan 29 22:40:44 1997//
+/soundsrv.c/1.3/Wed Jan 29 22:40:44 1997//
+/soundsrv.h/1.3/Wed Jan 29 22:40:44 1997//
+/soundst.h/1.3/Wed Jan 29 22:40:45 1997//
+/st_lib.c/1.4/Mon Feb 3 16:47:56 1997//
+/st_lib.h/1.4/Mon Feb 3 16:47:56 1997//
+/st_stuff.c/1.6/Mon Feb 3 22:45:13 1997//
+/st_stuff.h/1.3/Thu Jan 30 19:54:22 1997//
+/sun.c/1.3/Thu Jan 30 19:54:22 1997//
+/tables.c/1.4/Mon Feb 3 16:47:57 1997//
+/tables.h/1.1/Mon Feb 3 16:47:57 1997//
+/tmap.S/1.1/Sun Jan 19 17:22:51 1997//
+/v_video.c/1.5/Mon Feb 3 22:45:13 1997//
+/v_video.h/1.2/Mon Feb 3 17:11:59 1997//
+/w_wad.c/1.5/Mon Feb 3 16:47:57 1997//
+/wadread.c/1.3/Thu Jan 30 19:54:23 1997//
+/wadread.h/1.3/Thu Jan 30 19:54:23 1997//
+/wi_data.h/1.3/Thu Jan 30 19:54:23 1997//
+/wi_stuff.c/1.7/Mon Feb 3 22:45:13 1997//
+/wi_stuff.h/1.4/Mon Feb 3 16:47:58 1997//
+/z_zone.c/1.4/Mon Feb 3 16:47:58 1997//
+/z_zone.h/1.1/Mon Feb 3 16:47:58 1997//
1 linuxdoom-1.10/CVS/Repository
@@ -0,0 +1 @@
+/info/cvsroot/id/id_doom
1 linuxdoom-1.10/CVS/Root
@@ -0,0 +1 @@
+/info/cvsroot/
922 linuxdoom-1.10/ChangeLog
@@ -0,0 +1,922 @@
+
+
+
+ * TODO: see below, and in the "TODO" file. Enjoy!
+
+Mon Dec 22 20:29:16 1997 <bk@gamers.org>
+
+ * CVS logs and other obsolete stuff removed. Anybody
+ who wants to keep some revision control now has a
+ clean slate to start with.
+
+Mon Dec 22 19:53:34 1997 <bk@gamers.org>
+
+
+ * i_sound.c: enabled SNDSERV, as SNDINTR for
+ some reason just gives ghastly results e.g.
+ on E4M2. Frankly, I am at a loss. SNDSERV is
+ now default, until the internal sound driver
+ is a bit more reliable.
+ Note that the current redundancy means that
+ changes like the one below will have to
+ be propagated manually to the soundserver
+ sources.
+
+ * m_menu.c: the 4th episode is now removed with
+ the original doom.wad. You need to rename the
+ Ultimate DOOM/Special Edition retail IWAD to
+ doomu.wad now, or you won't see the 4th episode
+ in the menu. The compile time SPECIAL define
+ is thus gone.
+
+Mon Dec 22 17:08:33 1997 <bk@gamers.org>
+
+ * v_video.c (V_DrawPatch): another last minute hack.
+ While shareware, retail, commercial, and plutonia
+ (being a full DOOM2 IWAD) seem to work okay now,
+ TNT gives an error on finishing the first mission:
+ "Patch at -35, -5 exceeds LFB".
+ I changed the error abort into a simple return,
+ thus the patch is ignored. The intermission screen
+ seems to come up okay.
+ * TODO: check which patch, and whether it is an IWAD
+ problem.
+
+ * i_sound.c: the sound table is hardwired in
+ sounds.h/sounds.c. As our current crude
+ sound handling simply loads *all* sounds at
+ startup, we are going to miss some with DOOM1
+ WAD files. I could skip them, but decided to
+ load a placeholder instead (dspistol). It might
+ be good to use a distinct default sound for
+ WAD debug purposes. A zero length sound lump
+ would work, but would not be noticeable.
+ Anyway, shareware and retail work now.
+ * TODO: implement proper handling for missing
+ lumps, sound and otherwise.
+ Perhaps move sound table into WAD?
+
+ * g_game.c (G_DoPlayDemo): finally removed the
+ annoying "Demo is from a different game version"
+ abort. It now simply declines to playback the
+ demo, and waits for user input on some
+ do_nothing screen.
+
+ * doomdef.h&Cie.: Lesson of the day - do not
+ replace a bunch of booleans with an enum and
+ use the same identifiers. Point in case:
+ "if ( commercial )" will not give an error,
+ and will always be true as long as the enum
+ value is greater than zero.
+ I found that the DOOM2 vs. DOOM differences
+ are everywhere (weapons, monsters, doors).
+ Number of episodes varies from shareware/commercial
+ to registered to retail, while commercial has
+ a unique set (two of them, counting the german
+ edition) of maps in one episode. Plus, TNT and
+ Plutonia add some TITLE strings to the mixture.
+
+ Well, Plutonia and TNT are treated as DOOM2 for
+ now, so you will miss the startup message.
+
+ * wi_stuff.h (NUMEPISODES): removed SPECIAL switch.
+ It is no 4 times 9 for wi_stuff.c internal
+ static arrays - doesn't matter.
+ * TODO: unified handling with DOOM 2 - dynamic
+ allocation of arrays.
+
+ * i_sound.c (I_UpdateSound): okay, I separated
+ the mixing, now done synchonously, along with
+ a flag signalling the timer that the mixing buffer
+ has been updated. The handler is now very short,
+ and I tried several intervals down to 50usecs,
+ w/o complaints. Now the man page says:
+ "system timer resolution currently 10ms". Odd.
+ Anyway, while the double shotgun/plasma rapid
+ fire problem seems to be a bit less disturbing
+ at higher refresh, it's still there. I set the
+ interval to 500usec, which is sufficient for
+ avoiding any buffer update misses.
+ Conclusion after just two days of experimentation:
+ yep, sound driver code isn't fun at all.
+
+ As for the bug - well, Dave Taylor suggested
+ close distance getting into a divide-by-near-zero
+ situation, screwing up the volume. I can't figure
+ why latency of an external sound driver or screen
+ size affect this, but I am running out of ideas.
+
+ * i_sound.c:
+ Some more experimentation with the timer driven
+ sound. It doesn't work well using an intervall
+ of less then 30 msecs - there will be artifacts
+ with say 50 msecs. This is pretty obvious with
+ a target frame rate of at least 30fps, methinks.
+ Using the REAL/SIGALRM timer with 30msec gets
+ rid of the artifacts, it seems - at the expense
+ of slowing down things on a P133 to a noticeable
+ jerkiness. Bah.
+
+Mon Dec 22 00:36:54 1997 <bk@gamers.org>
+
+ * info.c: and i_video.c and i_sound.c - don't ask
+ me why some Linux header files are different with
+ gcc vs. g++, or what the complaint about the g++
+ complaint info.c state table is all about:
+ "initializer element for `states[..].action.acp1'
+ is not constant"
+ Undid some changes, compiled with gcc, playtested,
+ seems okay. Done for today... yesterday.
+
+ * i_net.c (ntohl): okay, htons/htonl, ntohs,ntohl
+ are back to haunt me. Copied the macros that
+ on my box aren't used for whatever reason directly
+ into the source. Got rid of all other multiple and
+ undefined references. CC=g++ now compiles (still
+ many warnings) and links, but the binary dumps a
+ core after Init PlayLoop. So be it.
+
+Sun Dec 21 12:38:08 1997 <bk@gamers.org>
+
+ * p_enemy.c (P_NewChaseDir): changed tdir to int,
+ removed the LUTs - spurious locks were due to
+ endless loops created by boneheaded predecessor
+ map. Has to be a better way to do enum dirtype_t
+ anyway. Problem seems to be fixed.
+
+ * CC=gcc again, this time loads of #includes to
+ fix "implicit declarations, and one or two
+ unused variables. DOOM now compiles without
+ any -Wall warnings left, as C.
+
+ * Bug: compiled the reworked code with gcc. Within a
+ solid while of testing and blasting away, it
+ locked once. Got a core, which gdb doesn't grok.
+ Bah.
+
+ * TODO: okay, linkage of g++ build modules give loads
+ of errors, because we have many implicits, plus
+ missing #pragma implementation causing multiple
+ definitions. Yet, this is the very first time DOOM
+ was compiled as C++ without a parsing error. So there.
+
+ * sounds.c: included doomtype.h and removed yet another
+ enum { false, true } definition.
+
+ * p_saveg.c (misc): several.
+ * p_mobj.c (P_SpawnMobj): (actionf_p1)P_MobjThinker
+ * p_spec.c (EV_DoDonut): (action_p1) T_MoveFloor (twice).
+ * p_plats.c (EV_DoPlat): (actionf_p1) T_PlatRaise.
+ * p_plats.c (EV_StopPlat): (actionf_v)NULL.
+ * p_plats.c (P_ActivateInStasis): same
+ * p_lights.c (P_SpawnGlowingLight): (actionf_p1) T_Glow.
+ * p_lights.c (P_SpawnStrobeFlash): (actionf_p1) T_StrobeFlash.
+ * p_lights.c (P_SpawnLightFlash): (actionf_p1) T_LightFlash.
+ * p_lights.c (P_SpawnFireFlicker): (actionf_p1) T_FireFlicker.
+ * p_floor.c (EV_DoFloor): (actionf_p1) T_MoveFloor.
+ * p_floor.c (EV_BuildStairs): same (twice).
+ * p_doors.c (EV_VerticalDoor): (actionf_p1)T_VerticalDoor.
+ * p_doors.c (P_SpawnDoorCloseIn30): same
+ * p_doors.c (P_SpawnDoorRaiseIn5Mins): same
+ * p_doors.c (EV_DoDoor): same
+ * p_ceilng.c (EV_CeilingCrushStop): (actionf_v)NULL.
+ * p_ceilng.c (EV_DoCeiling): (actionf_p1)T_MoveCeiling.
+ * p_ceilng.c (P_ActivateInStasisCeiling): same.
+ These gave g++ errors, but have been ignored by gcc.
+
+ * r_data.c (R_PrecacheLevel): (actionf_p1)P_MobjThinker.
+
+ * p_saveg.c: conversions (actionf_p1)T_Whatever.
+
+ * p_tick.c: cast (actionf_v)(-1).
+
+ * p_telept.c: yet another (actionf_p1)P_MobjThinker.
+
+ * p_mobj.c (P_MobjThinker): cast (actionf_v)(-1).
+ * TODO: decent NOP/NULL/Nil function pointer.
+ I'd introduce a global A_NOP() function that
+ chokes up an error message.
+ Why -1 instead of NULL?
+
+ * p_enemy.c: conversions (actionf_p1)P_MobjThinker.
+
+ * d_think.h/info.h: think_t is essentially
+ the same action function pointer stuff.
+ I moved the definitions from info.h to
+ d_think.h, and aliased them with a typedef.
+ Now more changes needed.
+
+ * p_enemy.c (successor, predecessor): new LUT,
+ to provide increments/decrements for enum
+ dirtype_t, as g++ complaints:
+ "no post-increment/decrement operator for type"
+
+ * Makefile (CC): okay, tried "g++" once more.
+ A few errors (above). Plus shitloads of warnings
+ (obviously, better "unused" checking with C++,
+ lots of the usual int2enum suspects, implicit
+ declarations, the works).
+
+
+ * p_mobj.c: action.acp1 used accordingly.
+ * p_pspr.c: action.acp2 used accordingly.
+ * TODO: info.c:144 warning
+ "missing braces around initializer for `states[0].action'"
+
+ * info.h/info.c: some experimental stuff on
+ action function pointers.
+
+ * TODO: still some sound glitches at startup.
+ * i_sound.c: few more cleanups. Made mixing use
+ channel loop instead of unroll, set mixbuffer
+ to zero ot start.
+ Removed some more DOS leftovers (8bit),
+ kept some as comment.
+
+ * hu_stuff.c (HU_Start):
+ More gamemode changes. As in d_main.c, I
+ decided to use DOOM2 as default whenever
+ one needed - it was sold most, and had the
+ superset of items, enemies and monsters.
+
+ * TODO: the handling of WAD specific messages
+ like HU_TITLE, HU_TITLE2, HU_TITLEP etc.
+ should definitely be removed.
+
+ * d_main.c (CheckBetaTest):
+ Removed outdated, DOS specific BETATEST stuff.
+ d_main.c (IdentifyVersion):
+ Numerous changes to gamemode handling.
+
+ * TODO: currently, french language is enabled by
+ detecting an doom2f.wad - yet it needs FRENCH
+ define at compile time. I removed most language
+ stuff, and propose handling that at runtime,
+ using a switch in the config file. Well,
+ mission specific texts won't work outside the
+ WAD anyway.
+
+ * TODO: along the same lines: I suggest removing
+ the misc. devparm switches as well - lots of
+ redundancy not needed anymore.
+
+ * Makefile: finally added a doomstat.c for all
+ the global state variables listing internal
+ engine configuration. Right now, these are
+ scattered everywhere. Declaration to be found
+ in doomstat.h header.
+
+ * f_finale.c (F_StartFinale):
+ Reworked the entire finale handling based on
+ game mode enum.
+
+ * doomstat.h:
+ Global variables for game mode and language.
+ Removed old booleans.
+
+ * doomdef.h: GameMode_t and Language_t enum added.
+ Boolean for language was kinda limiting to 2
+ alternatives (french, english), and five boolean
+ plus #define SPECIAL for game version is just ugly.
+
+ * wi_stuff.h: SPECIAL switch compiles two
+ different EXE's, one for 3 episodes of 9 maps
+ each (DOOM 1 registered), one for 4 episodes
+ of 9 maps each (DOOM 1 retail/FinalDOOM).
+ Implicitely, the DOOM2 config (one episode,
+ 34 missions) is handled. How is the german
+ edition (32 missions only) done?
+ Frankly, this is a mess. The problem is that
+ intermission (animated as in DOOM 1, simple
+ backdrop as in DOOM2) as well as certain
+ items (double shotgun) as well as certain
+ rendering stuff (sky texture) depend on this.
+
+ Plus, it ties into runtime flags as "commercial"
+ as well. Yuck.
+
+ Each change will change the game. Postponed.
+
+ * d_net.c,m_misc.c: removed last two NeXT remains.
+
+ * d_englsh.h,d_french.h,d_main.c,m_misc.c,r_draw.c,v_video.c:
+ more WATCOM remains removed. Kept some stuff that
+ handeld the blocky mode/detailshift in DOS, which
+ is n.a. in Linux - but probably not worth fixing.
+
+Sat Dec 20 15:16:51 1997 <bk@gamers.org>
+
+ * Bug: core dump when using doom.wad or doom1.wad
+ without a "-file UNUSED/doom2.wad". Version
+ dependend handling of stuff (double shotgun)
+ comes to mind.
+
+ * doomdef.h:
+ SNDSERV enables external sound server
+ support. SNDINTR enables internal sound
+ output with timer (asynchronous). Default
+ is internal, synchronous.
+
+ * i_sound.c (I_HandleSoundTimer):
+ Okay, the plasma/double shotgun sound bug
+ (crapyy sund when firing nose-to-wall) is
+ obviously a problem with blocking at
+ refresh - smaller screen size makes it go
+ away.
+ I won't do threads w/o a proper gdb, and
+ I can't do whatever Dave Taylor did with
+ LinuxQuake w/o the sources, thus I broke
+ down and implemented a timer based solution.
+ Seems to work fine, given the fact that
+ this is the first time ever I implemented
+ sound handling.
+
+Fri Dec 19 10:02:48 1997 <bk@gamers.org>
+
+ * m_menu.c/i_sound.c/s_sound.c:
+ Removed a few more inconsistencies due to
+ old internal sound handling (DOS),
+ external (Linux sndserver), and
+ new internal (the unfinished merge of
+ both the former).
+ The Options/Sound/Music volume menu is
+ accessible now. It was due to an internal
+ scaling of the menu (effective range 0-15),
+ up to 0..120, by multiply with 8 scattered
+ all over the place, that we got a
+ v_video.c: I_Error ("Bad V_DrawPatch")
+ Now I am using the menu resolution
+ everywhere, and scaling should only be done
+ in the actual mixing/output.
+
+ * OK, obviously this hasn't been updated in months.
+ This is because: a) most of the time nothing
+ happened, and b) when something got done, it was
+ too much to keep track of it by CVS and/or ChangeLog.
+
+ Basically, what happened in the meantime is that
+ I did not find a publisher who believed that the book
+ sales would be worth doing it. Within the limited
+ amount of time that I could dedicate to a project
+ that will not generate any revenue whatsoever,
+ I spent some time on cleaning up the Linux code
+ base which works, essentially. I might or might not
+ be able to participate in a Mesa+Voodoo+Glide based
+ GLDOOM port for Linux. I won't waste a minute on
+ Win32 without getting paid for it.
+
+ Because of the legal issues involved with the
+ DMX sound library id licensed for DOS DOOM, Linuxdoom
+ is the only code base that has sound support at all.
+ Other UNIX ports (SGI, Sun) could probably be revived
+ and integrated w/o too many problems. There is no
+ Win32 port - I never had access to WinDOOM or
+ Jim Dose's GLDOOM sources. There is no Linux
+ OpenGL (read: Mesa) support yet - that'd involve
+ internal changes which will best be done after a
+ public source release.
+
+ John Carmack opted for a release of the Linux code.
+ I have removed all DMX references I could get a
+ hold of, but preserved some of the original
+ sound handling within DOOM that interfaced
+ with DMX. Linuxdoom (like previous UNIX ports)
+ used a separate sound server binary. I did some
+ work on putting the sound server module back into
+ the engine. It works, but shutdown (pending sounds),
+ and sound output parallel to refresh (blocking)
+ is crappy, and there is a problem with double
+ shotgun and plasma at close distance (as well as
+ with lots of other noises going on). As the
+ mixing code is identical to the separate
+ soundserver, and as it doesn't seem to be a
+ blocking issue, I am currently at a loss - I
+ wonder whether the IPC communication with the
+ soundserver process introduced a delay that
+ changed behaviour, or whether I simply overlooked
+ a bug. I am currently lacking the time to track
+ this down, so I am keeping both internal and
+ soundserver source.
+
+ I did remove DOS and Watcom specifics. I did also
+ remove the texture mapping and fixed point assembly.
+ From my experience, it isn't worth the trouble
+ to ue GCC inline assembler, as performance of
+ the same loop written in C is perfectly sufficient.
+ On demand I will put both assembly modules into some
+ documentation, as they are probably of historic
+ interest.
+
+ There is no Sun DGA, Irix, or other non-Linux stuff
+ in this code base (at least, not intentionally).
+ They will be back when ports to other UNIX
+ environments will be merged back (I can't do
+ testing, and the modules were separate and not
+ consistent, so I refrained from wasting time on
+ this prior to a public release).
+
+ While I made only minor changes to the actual code
+ (some fixes, some cleaning up of SHM and audio),
+ I did a huge amount of shuffling around. I
+ introduced many more header files and modules,
+ some of them laughably small (doing these changes
+ is bound to screw up CVS, so no CVS record anymore
+ for the time being). I would introduce even more
+ separation if I had the time. Splitting the
+ animation/AI/behaviour code that defines
+ "DOOM - The Game" into a separate game.so (like
+ Quake2 does) should definitely be done. Separating
+ a ref_soft.so aka "DOOM - The Engine", and defining
+ a clean interface prior to introducing a ref_gl.so
+ is recommended as well.
+
+ I am going to purge some more leftovers, remove
+ the obsolete CVS history except for comments,
+ and try to clean up the last "implicit declaration"
+ and "unused variable" warnings. Except for enabling
+ cheats in nightmare (to have more fun while testing),
+ I did not change the game mechanics at all. I would
+ strongly advise against doing so w/o the proper
+ separations suggested above. I will not waste time
+ on fixing detail and blocky mode, lack of resize,
+ or other stuff that it better addressed by a proper
+ GLDOOM port.
+
+
+Sat Aug 16 08:07:16 1997 <bk@hal.gamers.org>
+
+ * p_pspr.c:
+ Moved the sprite animation stuff from doomdef.h here.
+
+ * info.h:
+ Added #ifndef __INFO__ for multiple inclusion. I am
+ not going to deal with multigen, or changing the
+ original DOOM monster animation anyway.
+
+ * p_spec.h/c:
+ Moved anim_t etc., locally used only. There is
+ another anim_t in wi_stuff.h/c, now local as well,
+ so collisions on header inclusion should not occur.
+ #include "doomdef.h"
+ #include "doomstat.h"
+ these should now be topmost includes.
+
+ * doomstat.h, doomdef.h, wi_stuff.h, d_player.h:
+ I moved wbstartstruct_t to d_player.h, and wminfo
+ to doomstat.h. Basically, I will try to move all
+ global state related stuff into doomstat.h, and
+ all data structures defined for state variables
+ into doomdef.h - this will be kinda greek tragedy,
+ and never finished, but a body can try.
+
+ * wi_stuff.h/c, wi_data.h:
+ Removed wi_data.h, put all local stuff blah... see
+ below.
+ I have found several unused global variables,
+ started outcommenting them with //U, will remove
+ them later. It might be Watcom/PC stuff, or
+ somebody put the actual numbers into the implementation
+ instead of using STARDIST, ANIMPERIOD & Cie.
+
+ * st_stuff.h/c: from doomdef.h, local stuff moved
+ into st_stuff.c, etc.
+ In the current revisions, I am tolerating warnings
+ of the "implicit declaration" kind - the linker
+ resolves the stuff, and it will be handy in
+ unmangling the modules once the headers contain
+ only the globally visible stuff.
+
+ * am_map.h/c, am_data.h:
+ Removed am_data.h, put all local stuff into
+ am_map.c, moved globally needed headers from
+ doomdef.h into am_map.h.
+
+ * p_saveg.h, p_setup.h, p_tick.h:
+ created, stuff from doomde.h moved there
+
+ * d_main.c, d_net.c, doomdef.h:
+ Decided to dump mprintf, as only needed for
+ Watcom support which is not going to happen.
+
+ * doomdef.h:
+ Moved function prototypes to appropriate headers:
+ d_main.h, d_net.h.
+
+Fri Aug 15 16:38:53 1997 <bk@hal.gamers.org>
+
+ * doomstat.h:
+ added a few more comments, regrouped some of the
+ state variables.
+
+ * doomdata.h: added a few more comments.
+
+Thu Aug 14 10:38:37 1997 <bk@hal.gamers.org>
+
+ * g_game.c (G_DoLoadLevel):
+ copied the skyflatnum determination here, from
+ the R_InitSkyMap - once should be sufficient.
+
+ * Makefile, r_sky.h/c:
+ added r_sky module. The sky handling was scattered
+ over r_bsp, r_main, r_plane, doomstat.h...
+
+ * r_bsp.c, r_main.c, r_segs.c:
+ Removed RD_* calls from R_debug.m, NeXT switches.
+
+ * r_local.h:
+ Removed the R_debug.m NeXT specific debugging
+ code headers. Removed "drawbsp" flag from
+ here, and r_main.c, too.
+
+ * r_data.c:
+ Started to remove NORMALUNIX switches, using
+ LINUX instead. Basically, different UNIX
+ platforms using the same code should simply
+ be ANDed in the #ifdef switches.
+
+ * r_draw.c:
+ Removed some more, but not all WATCOMC support.
+ There is an unresolved problem with the fuzzy
+ blitting in the lowres (blocky) modes - either
+ the "detailshift" flag triggered lowres mode
+ will be removed, or the bug has to be fixed.
+
+ * r_bsp.h, r_draw.h, r_things.h, r_data.h,
+ r_segs.h, r_main.h, r_plane.h:
+ Created from r_local.h.
+
+ * Back to work.
+ Till March 22nd, a lot of source shuffling and addition
+ of new header files, separating stuff, and creating
+ new, smaller modules. Some Watcom/PC/DMX/NeXT etc.
+ related stuff got removed, but not all (yet). None of
+ this ended up in the Log (sorry) or the revision control
+ (CVS is not well suited while number of files and
+ respective names change a lot, especially if stuff gets
+ deleted and/or re-introduced).
+ Major change: part of the sound code got copied from the
+ separate Linux sndserver sources to the linuxdoom source.
+ Re-integration and removal of sndserver pending.
+ Nothing of importance happend since then (priorities).
+
+Mon Feb 3 16:41:05 1997 <bk@gamers.org ()>
+
+ * m_misc.c:
+ Created m_argv, m_random and m_bbox, kept remains in m_misc
+ for the time being. Misc. files changed to include only
+ necessary modules. Moved bbox definitions from doomdata.h.
+
+ * m_menu.h:
+ Created from doomdef.h. Misc. changes in dependend modules.
+ I am not going to list every affected file from now on.
+ See Log entries within each file.
+
+ * dstrings.h:
+ Now handles multi-language support and switches.
+ So far, only english (default) and french are available.
+
+ * d_englsh.h:
+ Created from dstrings.h.
+
+ * g_game.h:
+ Created, from doomdef.h.
+
+ * am_map.c, st_stuff.c, wi_stuff.c:
+ * Makefile:
+ Added m_cheat, removed dutils. Doubly linked list stuff unused.
+
+ * m_cheat.h, m_cheat.c:
+ Created, basci cheat string scrambling and check, from dutils.h
+ and dutils.c.
+
+ * doomdef.h
+ Moved screen declaration to v_video.h.
+
+ * dutils.h, dutils.c
+ Remode code for f_wipe.h and f_wipe.c.
+
+ * Makefile
+ * d_main.c,
+ Added f_wipe files.
+
+ * f_wipe.h, f_wipe.c:
+ Created, screen wipe/melt at mission begin, from dutils.h
+ and dutils.c.
+
+ * d_textur.h:
+ Created from doomdata.h. Separates all the patch/texture
+ defintions. Needed for v_video module.
+
+ * r_local.h, wi_stuff.h, st_lib.h, hu_lib.h:
+ * i_x.c, d_main.c, m_menu.c, m_misc.c:
+ Added v_video.h.
+
+ * v_video.h:
+ Created. Using headers from doomdef.h. Forward of patch_t.
+ Moved bool and byte to doomtype.h.
+
+Thu Jan 30 20:50:16 1997 <bk@gamers.org ()>
+
+ * doomtype.h:
+ Created, for fixed_t. Should add angle_t here, too.
+
+ * tables.c:
+ Added SlopeDiv from r_main.c, added all defines and typedefs
+ related to basic trig table use here, removed it.
+ Currently "tables.h" is included in doomdef.h and
+ r_local.h, too. This is not too cleanly separated, but
+ we have to start somewhere, right?
+
+ * tables.h:
+ Created from doomdef.h.
+ Note that tables.c had fixed size tables, while doomdef.h
+ calculated from the value of FINEANGLES. In addition,
+ entries were given as either "int" or "fixed_t". Bad boys.
+
+ * z_zone.c:
+ * s_sound.c:
+ * hu_stuff.c:
+ * st_lib.c, st_stuff.c:
+ * wi_stuff.c:
+ * w_wad.c:
+ * r_things.c, r_plane.c, r_draw.c, r_data.c:
+ * p_tick.c, p_mobj.c, p_spec.c, p_setup.c, p_lights.c,
+ p_plats.c, p_floor.c, p_doors.c, p_ceilng.c:
+ * am_map.c:
+ * m_misc.c, m_menu.c:
+ * g_game.c:
+ * d_main.c:
+ * f_finale.c:
+ Added #include "z_zone.h".
+
+ * z_zone.h:
+ Created, from stuff in doomdef.h
+
+ * CVS checkin. Reformatting run, last one.
+ Took a week to go through all the sources, w/o even
+ looking to closely.
+
+ * st_stuff.c (ST_Responder):
+ Removed a first tiny bit of redundancy (NO_CLIP checks).
+ Should remove idspispod completely, later.
+
+Wed Jan 29 19:53:43 1997 <bk@gamers.org ()>
+
+ * Another one, while we are on it. All S (Sound) files.
+
+ * CVS checkin. Reformatting run, all R (Refresh) files.
+
+ * r_draw.c (R_DrawSpanLow):
+ The non-Watcom, non-asm lowres mode was just a copy
+ of the default mode. As detailshift was used to scale
+ the image down, lowres mode just filled the left half
+ of the buffer.
+ * r_draw.c (R_DrawColumnLow):
+ Tried the same hack for walls, horribly broken.
+ Postponed.
+
+Tue Jan 28 19:32:48 1997 <bk@gamers.org ()>
+
+ * CVS checkin. Another reformatting run. Did all P files.
+
+ * p_spec.c: P_FindNextHighestFloor
+ The number of adjoining sectors is limited to 20, because
+ of a temporary LUT needed for determining lowest height
+ in adjacent sectors. No overflow checking is done.
+
+Sun Jan 26 08:41:21 1997 <bk@gamers.org ()>
+
+ * Another CVS checkin of a formatting run.
+ D,F,G,HU,I,M have been changed.
+
+ * Note: in initial and current release,
+ linuxxdoom -3 -file plutonia.wad, idclev 12
+ produces a Segmentation fault.
+
+Wed Jan 22 14:03:00 1997 <bk@gamers.org ()>
+
+ * m_menu.c:
+ initializer-string for array of chars is too long (skullName)
+ warning: unused parameter `int choice' (a couple of times)
+
+ * Attempt to compile as C++. Loads of warnings, a couple of errors.
+ p_enemy.c (P_Move):
+ r_things.c (R_ProjectSprite)
+ `catch', `throw', and `try' are all C++ reserved words,
+ thus changed "try" to "try_ok". Fixed.
+ p_pspr.c: In function `void P_SetPsprite(struct player_s *, ... )':
+ too many arguments to function
+ No convenient fix - state->action is declared void action(),
+ but called w/o, with one, or with two parameters.
+ There are more like this. Going to be a tough one.
+ Union of pointers?
+ Postponed.
+
+ r_plane.c: In function `void R_DrawPlanes()':
+ s_sound.c: In function `int S_AdjustSoundParams(struct mobj_s *, .. )':
+ p_map.c: In function `bool PIT_StompThing(struct mobj_s *)':
+ p_maputl.c: In function `int P_AproxDistance(int, int)':
+ r_main.c: In function `int R_PointToDist(int, int)':
+ p_enemy.c: In function `void P_NewChaseDir(struct mobj_s *)':
+ warning: implicit declaration of function `int abs(...)' <stdlib.h>
+
+Wed Jan 22 12:15:00 1997 <bk@gamers.org ()>
+
+ * CVS checkin of purification run. Sources now compile
+ without any "-Wall" warnings.
+
+ * Note: with -file "tnt.wad", we get an "Error: Bad V_DrawPatch"
+ abort each time we enter an exit. Invalid or missing
+ intermission screen?
+
+ * Makefile (CFLAGS): added -Wall, first purification run.
+
+ d_main.c: In function `D_DoomMain':
+ warning: implicit declaration of function `mkdir' <fcntl.h>
+
+ i_unix.c: In function `I_StartSound':
+ warning: control reaches end of non-void function
+ i_unix.c: In function `I_InitNetwork':
+ warning: implicit declaration of function `inet_addr' <arpa/inet.h>
+ i_unix.c: At top level:
+ warning: `endianness' defined but not used
+
+ i_x.c: In function `I_Error':
+ warning: unused variable `string'
+ i_x.c: In function `I_GetEvent':
+ warning: suggest parentheses around arithmetic in operand of |
+ i_x.c: In function `I_FinishUpdate':
+ warning: unused variable `bigscreen'
+ i_x.c: In function `grabsharedmemory':
+ warning: implicit declaration of function `getuid' <unistd.h>
+ warning: unused variable `done'
+ i_x.c: In function `I_InitGraphics':
+ warning: suggest parentheses around assignment used as truth value
+ warning: char format, different type arg (arg 3)
+ warning: char format, different type arg (arg 5)
+ warning: implicit declaration of function `XShmGetEventBase'
+ i_x.c: In function `InitExpand2':
+ warning: unused variable `jexp'
+ warning: unused variable `iexp'
+
+ m_menu.c: In function `M_ReadSaveStrings':
+ warning: implicit declaration of function `read' <sys/types.h>
+ warning: implicit declaration of function `close' <unistd.h>
+
+ m_misc.c: In function `M_WriteFile':
+ warning: implicit declaration of function `write'
+ warning: implicit declaration of function `close'
+ m_misc.c: In function `M_ReadFile':
+ warning: implicit declaration of function `read'
+ m_misc.c: In function `M_ScreenShot':
+ warning: implicit declaration of function `access' <unistd.h>
+
+ p_pspr.c: In function `P_MovePsprites':
+ suggest parentheses around assignment used as truth value
+
+ p_spec.c: In function `P_SpawnSpecials':
+ warning: implicit declaration of function `atoi' <stdlib.h>
+
+ w_wad.c: In function `strupr':
+ warning: implicit declaration of function `toupper' <ctype.h>
+ w_wad.c: In function `W_AddFile':
+ warning: implicit declaration of function `read' <sys/types.h>
+ warning: implicit declaration of function `lseek'
+ warning: implicit declaration of function `close' <unistd.h>
+
+ wi_stuff.c: In function `WI_loadData':
+ warning: unused variable `pic'
+ wi_stuff.c: At top level:
+ warning: `background' defined but not used
+
+Tue Jan 21 22:00:00 1997 <bk@gamers.org ()>
+
+ * doomdata.h (__BYTEBOOL__):
+ Use builtin ANSI C++ bool.
+
+ * d_main.c (IdentifyVersion):
+ Bug fix: insufficient malloc created errors in malloc/realloc
+ calls later on. Welcome to the risks of Copy'n'paste.
+
+Tue Jan 21 13:20:05 1997 <bk@gamers.org ()>
+
+ * First formatting checkin.
+ A word of explanation: prior to making any changes to the
+ source, a couple of formatting runs will be made, followed
+ by some purification runs.
+ For this run, the Emacs mode selection line has been changed
+ to use C++ style indenting (cc-mode.el). Each file has
+ been automatically reformatted using Emacs indent-region.
+ A few files have been changed manually already (i.e.,
+ comments, use of tabs).
+ Warning: using "diff" to compare files of different states
+ during the reformatting will not give useful results.
+
+ * hu_stuff.c:
+ fixed "assignment discard const", the last remaining error
+ message with default compilation.
+
+
+Sun Jan 19 14:27:06 1997 <bk@gamers.org ()>
+
+ * Makefile:
+ Minor fix for sndserver target, removed linuxsdoom target
+ for the time being, added CVS header (kind of).
+
+ * Initial CVS checkin.
+
+ * soundsrv/irix/linux/sun.c:
+ Changed includes (irix.h removed, soundsrv.h included).
+
+ * i_svga.c:
+ Changed to DOS 8+3.
+
+ * soundsrv.h/c:
+ Changed to DOS 8+3, included irix.h in soundsrv.h.
+
+ * r_local.h:
+ Same for PI, include math.h with Linux.
+
+ * doomdef.h:
+ Got rid of multiply defined warnings for Linux,
+ included values.h.
+
+ * FILES2:
+ created a commented list of all files, removed a few
+ more files (sndserver test, NeXT leftovers, DMX header).
+ Identified the following main modules (see FILES2):
+ AM, HU, M, P, R, S, ST, W, WI. Some stuff is separate
+ (Z, F), some not clearly separable (G, D). System specific
+ interfaces are in I. Some of the latter replace i_main.c
+ (i.e. the void/int main(argc,argv) call), e.g. SVGA,
+ others (X11, SHM, DGA) don't. There is a certain amount
+ of overlap, and the largest module (with possibly most
+ overlap) is P - playing, i.e. all the games state and
+ animation handling.
+ Dithering is currently not used.
+
+Sat Jan 18 15:14:41 1997 <bk@gamers.org ()>
+
+ * r_draw.c:
+ fixed !defined(USEASM) lines for R_DrawColumn/Span.
+ Removed fpfunc.o/S from Makefile, now compiling
+ X11 w/o any assembler.
+ Got a running linuxxdoom again. We are in business.
+ This source is going to be used for the initial CVS
+ check in.
+
+ * Tried a quick hack compiling it as COFF a.out instead
+ of ELF, with "gcc -b i486-linuxaout". Same linker
+ errors.
+ Tried removing -DUSE_ASM. Still using fpfunc.S.
+
+
+ * Tried linuxxdoom.
+ Compile run: some warnings (redefinition of MAX/MIN
+ SHORT/INT/LONG) in doomdef.h and (PI redefined)
+ r_local.h.
+ Link run: crashed, undefined references in
+ d_main.c: undefined reference to `FixedDiv2'
+ am_map.c: undefined reference to `FixedMul'
+ r_main.c: undefined reference to `R_DrawColumn'
+ r_main.c: undefined reference to `R_DrawSpan'
+ r_plane.c: undefined reference to `FixedMul'
+
+ This stuff is defined in fpfunc.S (Fixed point) and
+ in r_draw.c (assembler in tmap.S not used).
+ However, "nm," shows that r_draw.o does not include
+ the drawing functions (see below - USE_ASM).
+ Furthermore, the global symbols in fpfunc.S begin
+ with an underscore, "_FixedMul" and "_FixedDiv2".
+
+ More problems within fpfunc.o: undefined references to
+
+ `_dc_yl' `_dc_yh'
+ `_ylookup'
+ `_centery'
+ `_dc_x'
+ `_columnofs'
+ `_dc_iscale'
+ `_dc_texturemid'
+ `_dc_source'
+ `_dc_colormap'
+
+ `_ds_y' `_ds_x1' `_ds_x2'
+ `_ds_xfrac' `_ds_yfrac'
+ `_ds_xstep' `_ds_ystep'
+ `_ds_colormap'
+ `_ds_source'
+
+ Again, underscore problem.
+ Note: tmap.S currently obsolete, as somebody pasted all
+ the texture mapping assembly into fpfunc.S. Gotta clean
+ that up.
+
+ * Created initial release from CD sources, created ChangeLog.
+ Let the games begin.
+
+
+ **************************************************************
+ DOOM source code ChangeLog file
+ **************************************************************
+
112 linuxdoom-1.10/DOOMLIC.TXT
@@ -0,0 +1,112 @@
+
+
+ LIMITED USE SOFTWARE LICENSE AGREEMENT
+
+ This Limited Use Software License Agreement (the "Agreement")
+is a legal agreement between you, the end-user, and Id Software, Inc.
+("ID"). By downloading or purchasing the software material, which
+includes source code (the "Source Code"), artwork data, music and
+software tools (collectively, the "Software"), you are agreeing to
+be bound by the terms of this Agreement. If you do not agree to the
+terms of this Agreement, promptly destroy the Software you may have
+downloaded or copied.
+
+ID SOFTWARE LICENSE
+
+1. Grant of License. ID grants to you the right to use the
+Software. You have no ownership or proprietary rights in or to the
+Software, or the Trademark. For purposes of this section, "use" means
+loading the Software into RAM, as well as installation on a hard disk
+or other storage device. The Software, together with any archive copy
+thereof, shall be destroyed when no longer used in accordance with
+this Agreement, or when the right to use the Software is terminated.
+You agree that the Software will not be shipped, transferred or
+exported into any country in violation of the U.S. Export
+Administration Act (or any other law governing such matters) and that
+you will not utilize, in any other manner, the Software in violation
+of any applicable law.
+
+2. Permitted Uses. For educational purposes only, you, the
+end-user, may use portions of the Source Code, such as particular
+routines, to develop your own software, but may not duplicate the
+Source Code, except as noted in paragraph 4. The limited right
+referenced in the preceding sentence is hereinafter referred to as
+"Educational Use." By so exercising the Educational Use right you
+shall not obtain any ownership, copyright, proprietary or other
+interest in or to the Source Code, or any portion of the Source
+Code. You may dispose of your own software in your sole discretion.
+With the exception of the Educational Use right, you may not
+otherwise use the Software, or an portion of the Software, which
+includes the Source Code, for commercial gain.
+
+3. Prohibited Uses: Under no circumstances shall you, the
+end-user, be permitted, allowed or authorized to commercially exploit
+the Software. Neither you nor anyone at your direction shall do any
+of the following acts with regard to the Software, or any portion
+thereof:
+
+ Rent;
+
+ Sell;
+
+ Lease;
+
+ Offer on a pay-per-play basis;
+
+ Distribute for money or any other consideration; or
+
+ In any other manner and through any medium whatsoever
+commercially exploit or use for any commercial purpose.
+
+Notwithstanding the foregoing prohibitions, you may commercially
+exploit the software you develop by exercising the Educational Use
+right, referenced in paragraph 2. hereinabove.
+
+4. Copyright. The Software and all copyrights related thereto
+(including all characters and other images generated by the Software
+or depicted in the Software) are owned by ID and is protected by
+United States copyright laws and international treaty provisions.
+Id shall retain exclusive ownership and copyright in and to the
+Software and all portions of the Software and you shall have no
+ownership or other proprietary interest in such materials. You must
+treat the Software like any other copyrighted material. You may not
+otherwise reproduce, copy or disclose to others, in whole or in any
+part, the Software. You may not copy the written materials
+accompanying the Software. You agree to use your best efforts to
+see that any user of the Software licensed hereunder complies with
+this Agreement.
+
+5. NO WARRANTIES. ID DISCLAIMS ALL WARRANTIES, BOTH EXPRESS
+IMPLIED, INCLUDING BUT NOT LIMITED TO, IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE WITH RESPECT
+TO THE SOFTWARE. THIS LIMITED WARRANTY GIVES YOU SPECIFIC LEGAL
+RIGHTS. YOU MAY HAVE OTHER RIGHTS WHICH VARY FROM JURISDICTION TO
+JURISDICTION. ID DOES NOT WARRANT THAT THE OPERATION OF THE SOFTWARE
+WILL BE UNINTERRUPTED, ERROR FREE OR MEET YOUR SPECIFIC REQUIREMENTS.
+THE WARRANTY SET FORTH ABOVE IS IN LIEU OF ALL OTHER EXPRESS
+WARRANTIES WHETHER ORAL OR WRITTEN. THE AGENTS, EMPLOYEES,
+DISTRIBUTORS, AND DEALERS OF ID ARE NOT AUTHORIZED TO MAKE
+MODIFICATIONS TO THIS WARRANTY, OR ADDITIONAL WARRANTIES ON BEHALF
+OF ID.
+
+ Exclusive Remedies. The Software is being offered to you
+free of any charge. You agree that you have no remedy against ID, its
+affiliates, contractors, suppliers, and agents for loss or damage
+caused by any defect or failure in the Software regardless of the form
+of action, whether in contract, tort, includinegligence, strict
+liability or otherwise, with regard to the Software. This Agreement
+shall be construed in accordance with and governed by the laws of the
+State of Texas. Copyright and other proprietary matters will be
+governed by United States laws and international treaties. IN ANY
+CASE, ID SHALL NOT BE LIABLE FOR LOSS OF DATA, LOSS OF PROFITS, LOST
+SAVINGS, SPECIAL, INCIDENTAL, CONSEQUENTIAL, INDIRECT OR OTHER
+SIMILAR DAMAGES ARISING FROM BREACH OF WARRANTY, BREACH OF CONTRACT,
+NEGLIGENCE, OR OTHER LEGAL THEORY EVEN IF ID OR ITS AGENT HAS BEEN
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY
+OTHER PARTY. Some jurisdictions do not allow the exclusion or
+limitation of incidental or consequential damages, so the above
+limitation or exclusion may not apply to you.
+
+
+
+
98 linuxdoom-1.10/FILES
@@ -0,0 +1,98 @@
+total 1258
+-rw-r--r-- 1 b1 prog 0 Jan 18 15:08 FILES
+-rw-r--r-- 1 b1 prog 5799 Jan 18 15:07 Makefile
+-rw-r--r-- 1 b1 prog 1943 Jan 18 15:07 am_data.h
+-rw-r--r-- 1 b1 prog 20263 Jan 18 15:07 am_map.c
+-rw-r--r-- 1 b1 prog 2494 Jan 18 15:07 am_map.h
+-rw-r--r-- 1 b1 prog 1499 Jan 18 15:07 am_oids.c
+-rw-r--r-- 1 b1 prog 338 Jan 18 15:07 am_oids.h
+-rw-r--r-- 1 b1 prog 14005 Jan 18 15:07 d_french.h
+-rw-r--r-- 1 b1 prog 25287 Jan 18 15:07 d_main.c
+-rw-r--r-- 1 b1 prog 15586 Jan 18 15:07 d_net.c
+-rw-r--r-- 1 b1 prog 744 Jan 18 15:07 defs.inc
+-rw-r--r-- 1 b1 prog 3569 Jan 18 15:07 dither.c
+-rw-r--r-- 1 b1 prog 355 Jan 18 15:07 dither.h
+-rw-r--r-- 1 b1 prog 4234 Jan 18 15:07 doomdata.h
+-rw-r--r-- 1 b1 prog 32779 Jan 18 15:07 doomdef.h
+-rw-r--r-- 1 b1 prog 192 Jan 18 15:07 drcoord.h
+-rw-r--r-- 1 b1 prog 22377 Jan 18 15:07 dstrings.h
+-rw-r--r-- 1 b1 prog 6582 Jan 18 15:07 dutils.c
+-rw-r--r-- 1 b1 prog 1821 Jan 18 15:07 dutils.h
+-rw-r--r-- 1 b1 prog 14072 Jan 18 15:07 f_finale.c
+-rw-r--r-- 1 b1 prog 7357 Jan 18 15:07 fpfunc.S
+-rw-r--r-- 1 b1 prog 34770 Jan 18 15:07 g_game.c
+-rw-r--r-- 1 b1 prog 5394 Jan 18 15:07 hu_lib.c
+-rw-r--r-- 1 b1 prog 2878 Jan 18 15:07 hu_lib.h
+-rw-r--r-- 1 b1 prog 12040 Jan 18 15:07 hu_stuff.c
+-rw-r--r-- 1 b1 prog 934 Jan 18 15:07 hu_stuff.h
+-rw-r--r-- 1 b1 prog 6238 Jan 18 15:07 i_cyber.c
+-rw-r--r-- 1 b1 prog 18324 Jan 18 15:07 i_dga.c
+-rw-r--r-- 1 b1 prog 2499 Jan 18 15:07 i_header.h
+-rw-r--r-- 1 b1 prog 32815 Jan 18 15:07 i_ibm.c
+-rw-r--r-- 1 b1 prog 1867 Jan 18 15:07 i_ibm_a.asm
+-rw-r--r-- 1 b1 prog 121 Jan 18 15:07 i_main.c
+-rw-r--r-- 1 b1 prog 8251 Jan 18 15:07 i_pcnet.c
+-rw-r--r-- 1 b1 prog 8561 Jan 18 15:07 i_sound.c
+-rw-r--r-- 1 b1 prog 439 Jan 18 15:07 i_sound.h
+-rw-r--r-- 1 b1 prog 9537 Jan 18 15:07 i_svgalib.c
+-rw-r--r-- 1 b1 prog 10886 Jan 18 15:07 i_unix.c
+-rw-r--r-- 1 b1 prog 20891 Jan 18 15:07 i_x.c
+-rw-r--r-- 1 b1 prog 128797 Jan 18 15:07 info.c
+-rw-r--r-- 1 b1 prog 15840 Jan 18 15:07 info.h
+-rw-r--r-- 1 b1 prog 3477 Jan 18 15:07 irix.c
+-rw-r--r-- 1 b1 prog 240 Jan 18 15:07 irix.h
+-rw-r--r-- 1 b1 prog 1363 Jan 18 15:07 linux.c
+-rw-r--r-- 1 b1 prog 34628 Jan 18 15:07 m_menu.c
+-rw-r--r-- 1 b1 prog 13741 Jan 18 15:07 m_misc.c
+-rw-r--r-- 1 b1 prog 6117 Jan 18 15:07 p_ceilng.c
+-rw-r--r-- 1 b1 prog 15062 Jan 18 15:07 p_doors.c
+-rw-r--r-- 1 b1 prog 33758 Jan 18 15:07 p_enemy.c
+-rw-r--r-- 1 b1 prog 11409 Jan 18 15:07 p_floor.c
+-rw-r--r-- 1 b1 prog 16265 Jan 18 15:07 p_inter.c
+-rw-r--r-- 1 b1 prog 7592 Jan 18 15:07 p_lights.c
+-rw-r--r-- 1 b1 prog 6447 Jan 18 15:07 p_local.h
+-rw-r--r-- 1 b1 prog 30138 Jan 18 15:07 p_map.c
+-rw-r--r-- 1 b1 prog 14672 Jan 18 15:07 p_maputl.c
+-rw-r--r-- 1 b1 prog 17276 Jan 18 15:07 p_mobj.c
+-rw-r--r-- 1 b1 prog 5940 Jan 18 15:07 p_plats.c
+-rw-r--r-- 1 b1 prog 17084 Jan 18 15:07 p_pspr.c
+-rw-r--r-- 1 b1 prog 12828 Jan 18 15:07 p_setup.c
+-rw-r--r-- 1 b1 prog 5962 Jan 18 15:07 p_sight.c
+-rw-r--r-- 1 b1 prog 23846 Jan 18 15:07 p_spec.c
+-rw-r--r-- 1 b1 prog 11140 Jan 18 15:07 p_spec.h
+-rw-r--r-- 1 b1 prog 14229 Jan 18 15:07 p_switch.c
+-rw-r--r-- 1 b1 prog 1910 Jan 18 15:07 p_telept.c
+-rw-r--r-- 1 b1 prog 14075 Jan 18 15:07 p_tick.c
+-rw-r--r-- 1 b1 prog 7044 Jan 18 15:07 p_user.c
+-rw-r--r-- 1 b1 prog 13013 Jan 18 15:07 planar.asm
+-rw-r--r-- 1 b1 prog 9811 Jan 18 15:07 r_bsp.c
+-rw-r--r-- 1 b1 prog 14619 Jan 18 15:07 r_data.c
+-rw-r--r-- 1 b1 prog 13591 Jan 18 15:07 r_draw.c
+-rw-r--r-- 1 b1 prog 11378 Jan 18 15:07 r_local.h
+-rw-r--r-- 1 b1 prog 14868 Jan 18 15:07 r_main.c
+-rw-r--r-- 1 b1 prog 7108 Jan 18 15:07 r_plane.c
+-rw-r--r-- 1 b1 prog 15420 Jan 18 15:07 r_segs.c
+-rw-r--r-- 1 b1 prog 18969 Jan 18 15:07 r_things.c
+-rw-r--r-- 1 b1 prog 12274 Jan 18 15:07 s_sound.c
+-rw-r--r-- 1 b1 prog 12812 Jan 18 15:07 sndserver.c
+-rw-r--r-- 1 b1 prog 141 Jan 18 15:07 sndserver.h
+-rw-r--r-- 1 b1 prog 5811 Jan 18 15:07 sounds.c
+-rw-r--r-- 1 b1 prog 2674 Jan 18 15:07 sounds.h
+-rw-r--r-- 1 b1 prog 3975 Jan 18 15:07 soundst.h
+-rw-r--r-- 1 b1 prog 3461 Jan 18 15:07 st_lib.c
+-rw-r--r-- 1 b1 prog 2254 Jan 18 15:07 st_lib.h
+-rw-r--r-- 1 b1 prog 22769 Jan 18 15:07 st_stuff.c
+-rw-r--r-- 1 b1 prog 4685 Jan 18 15:07 st_stuff.h
+-rw-r--r-- 1 b1 prog 1725 Jan 18 15:07 sun.c
+-rw-r--r-- 1 b1 prog 75 Jan 18 15:07 t.c
+-rw-r--r-- 1 b1 prog 114621 Jan 18 15:07 tables.c
+-rw-r--r-- 1 b1 prog 5485 Jan 18 15:07 tmap.S
+-rw-r--r-- 1 b1 prog 10904 Jan 18 15:07 v_video.c
+-rw-r--r-- 1 b1 prog 268 Jan 18 15:07 vgaview.h
+-rw-r--r-- 1 b1 prog 9920 Jan 18 15:07 w_wad.c
+-rw-r--r-- 1 b1 prog 3629 Jan 18 15:07 wadread.c
+-rw-r--r-- 1 b1 prog 551 Jan 18 15:07 wadread.h
+-rw-r--r-- 1 b1 prog 3583 Jan 18 15:07 wi_data.h
+-rw-r--r-- 1 b1 prog 25608 Jan 18 15:07 wi_stuff.c
+-rw-r--r-- 1 b1 prog 1544 Jan 18 15:07 wi_stuff.h
+-rw-r--r-- 1 b1 prog 8501 Jan 18 15:07 z_zone.c
221 linuxdoom-1.10/FILES2
@@ -0,0 +1,221 @@
+ChangeLog
+FILES
+FILES2
+Makefile
+
+-----------------------------------------------------------------------
+Global and misc. stuff
+-----------------------------------------------------------------------
+doomdata.h - external data definitions (WAD file structure)
+doomdef.h - internal data definitions (game structs)
+dstrings.h - printed strings for translation, english
+d_french.h - printed strings for translation
+
+info.h
+info.c - LUT's for Thing TAB, Frame TAB,
+ generated by multigen utility
+dutils.h
+dutils.c - Dave's utilities
+ including doubly-linked lists & simple state machines.
+ Used in WI, ST, AM, and d_main.c
+
+------------------------------------------------------------------------
+DOOM game loop and top level stuff
+------------------------------------------------------------------------
+g_game.c - Game loop functions, event handling etc.
+
+ boolean G_CheckDemoStatus (void);
+ void G_ReadDemoTiccmd (ticcmd_t *cmd);
+ void G_WriteDemoTiccmd (ticcmd_t *cmd);
+ void G_PlayerReborn (int player);
+ void G_InitNew (skill_t skill, int episode, int map);
+
+ void G_DoReborn (int playernum);
+
+ void G_DoLoadLevel (void);
+ void G_DoNewGame (void);
+ void G_DoLoadGame (void);
+ void G_DoPlayDemo (void);
+ void G_DoCompleted (void);
+ void G_DoVictory (void);
+ void G_DoWorldDone (void);
+ void G_DoSaveGame (void);
+
+d_main.c - event handling, D_DoomMain() and other functions
+ NOT int main()
+
+d_net.c - high level networking protocol code
+
+------------------------------------------------------------------
+I Interfaces, system specifics
+------------------------------------------------------------------
+i_main.c - main(), calls D_DoomMain().
+i_svgalib.c - Linux SVGAlib code, including main(),
+ replaces i_main.c
+
+i_x.c - X11 with SHM code, use with i_main.c
+i_dga.c - X11 DGA code, use with i_main.c
+i_unix.c - fixed point, networking, and display stuff for UNIX
+
+i_ibm.c - IBM DOS VGA graphics and key/mouse/joystick,
+ use with i_main.c
+i_pcnet.c - IPX networking, DOS
+
+fpfunc.S - fixed point assembly and (currently) duplicate of
+tmap.S - texture mapping assembly (currently unused)
+
+------------------------------------------------------------------
+AM AutoMap
+------------------------------------------------------------------
+am_data.h - vector graphics for the automap
+
+am_map.h
+am_map.c - automap code
+
+------------------------------------------------------------------
+HU Heads Up
+------------------------------------------------------------------
+hu_lib.h
+hu_lib.c - heads-up text and input code
+
+hu_stuff.h
+hu_stuff.c - Heads-up displays
+
+
+-------------------------------------------------------------------
+M Menu
+-------------------------------------------------------------------
+m_menu.c - DOOM options code and leaving messages
+
+m_misc.c - misc. HUD text display, input checks, and
+ random table, file I/O
+
+
+-------------------------------------------------------------------
+P Play???
+-------------------------------------------------------------------
+p_local.h - header for all play modules
+
+p_spec.h - specials, lighting, doors, plats, texture animation
+p_spec.c - specials, texture animation
+
+p_doors.c - door code
+p_plats.c - platform raising/lowering code
+p_ceilng.c - active (e.g. crushing) ceilings
+p_floor.c - active (e.g. raising) floors
+p_lights.c - dynamic (e.g. flickering) lighting
+p_switch.c - button switches and animation
+
+p_enemy.c - enemy AI and animation
+p_inter.c - object/object interaction?
+p_map.c - movement objects, handling of collisions
+p_maputl.c - distance, position etc. utilities for movement
+p_mobj.c - mobile objects handling, spawn etc.
+p_user.c - more movement, bobbing etc.
+
+p_telept.c - teleportation code
+
+p_sight.c - LOS checks, REJECT
+
+
+p_pspr.c - weapon overlays, bobbing, raising, sprite tables,
+ firing, ammo bookkeeping
+
+p_setup.c - load map from WAF file, setup code
+
+
+p_tick.c - savegame function (archive/unarchive),
+ thinker list handling, allocation,
+ game tick execution (updates)
+
+
+-------------------------------------------------------------------
+R Rendering
+-------------------------------------------------------------------
+r_local.h - header for all rendering modules,
+ internal map data structure definitions
+
+r_bsp.c - BSP seg's clipping
+
+r_data.c - texture column caching, patch assembly,
+ flats, colormaps, sprites,
+ lookup by name
+
+r_draw.c - access to framebuffer API, drawing C functions
+
+
+r_main.c - geometry functions, trigonometry lookups,
+ R_RenderPlayerView
+
+r_plane.c - floor/ceiling visplanes, sky
+
+r_segs.c - drawing segs, marking hslices for floors/ceilings
+
+r_things.c - sprite and sprite frame/rotation handling, drawing
+
+
+tables.c - trigonometry lookup tables, static
+
+v_video.c - gamma correction lookup, patch drawing to rectangle
+
+-------------------------------------------------------------------
+S Sound
+-------------------------------------------------------------------
+s_sound.c - more sound and music handling
+
+soundst.h - sound and music data structures
+sounds.h
+sounds.c - sound and music lump LUT's (manually maintained)
+
+sndserver.h
+sndserver.c - (Irix) sndserver code
+
+irix.h
+irix.c - SGI Irix sound/sndserver support code
+
+linux.c - Linux voxware sound/sndserver support code,
+ replaces irix.c, uses irix.h
+sun.c - SUN replacement for irix.c
+
+
+i_sound.h
+i_sound.c - DOS DMX music and sound interface
+
+-------------------------------------------------------------------
+ST STatus bar
+-------------------------------------------------------------------
+st_lib.h
+st_lib.c - status bar widget code
+
+st_stuff.c
+st_stuff.h - status bar code
+
+
+-------------------------------------------------------------------
+W Wad file I/O
+-------------------------------------------------------------------
+w_wad.c - lump based functions
+wadread.h
+wadread.c - lump I/O, get SFX
+
+-------------------------------------------------------------------
+WI WIn / level end screens
+-------------------------------------------------------------------
+wi_data.h - lookups for intermission screens, patch positions
+
+wi_stuff.h
+wi_stuff.c - intermission animation patchwork
+
+-------------------------------------------------------------------
+Z Zone memory allocation
+-------------------------------------------------------------------
+z_zone.c
+
+-------------------------------------------------------------------
+F Final screen animation
+-------------------------------------------------------------------
+f_finale.c - DOOM mission end screens? (bunny)
+
+
+
+-------------------------------------------------------------------
95 linuxdoom-1.10/Makefile
@@ -0,0 +1,95 @@
+################################################################
+#
+# $Id:$
+#
+# $Log:$
+#
+CC= gcc # gcc or g++
+
+CFLAGS=-g -Wall -DNORMALUNIX -DLINUX # -DUSEASM
+LDFLAGS=-L/usr/X11R6/lib
+LIBS=-lXext -lX11 -lnsl -lm
+
+# subdirectory for objects
+O=linux
+
+# not too sophisticated dependency
+OBJS= \
+ $(O)/doomdef.o \
+ $(O)/doomstat.o \
+ $(O)/dstrings.o \
+ $(O)/i_system.o \
+ $(O)/i_sound.o \
+ $(O)/i_video.o \
+ $(O)/i_net.o \
+ $(O)/tables.o \
+ $(O)/f_finale.o \
+ $(O)/f_wipe.o \
+ $(O)/d_main.o \
+ $(O)/d_net.o \
+ $(O)/d_items.o \
+ $(O)/g_game.o \
+ $(O)/m_menu.o \
+ $(O)/m_misc.o \
+ $(O)/m_argv.o \
+ $(O)/m_bbox.o \
+ $(O)/m_fixed.o \
+ $(O)/m_swap.o \
+ $(O)/m_cheat.o \
+ $(O)/m_random.o \
+ $(O)/am_map.o \
+ $(O)/p_ceilng.o \
+ $(O)/p_doors.o \
+ $(O)/p_enemy.o \
+ $(O)/p_floor.o \
+ $(O)/p_inter.o \
+ $(O)/p_lights.o \
+ $(O)/p_map.o \
+ $(O)/p_maputl.o \
+ $(O)/p_plats.o \
+ $(O)/p_pspr.o \
+ $(O)/p_setup.o \
+ $(O)/p_sight.o \
+ $(O)/p_spec.o \
+ $(O)/p_switch.o \
+ $(O)/p_mobj.o \
+ $(O)/p_telept.o \
+ $(O)/p_tick.o \
+ $(O)/p_saveg.o \
+ $(O)/p_user.o \
+ $(O)/r_bsp.o \
+ $(O)/r_data.o \
+ $(O)/r_draw.o \
+ $(O)/r_main.o \
+ $(O)/r_plane.o \
+ $(O)/r_segs.o \
+ $(O)/r_sky.o \
+ $(O)/r_things.o \
+ $(O)/w_wad.o \
+ $(O)/wi_stuff.o \
+ $(O)/v_video.o \
+ $(O)/st_lib.o \
+ $(O)/st_stuff.o \
+ $(O)/hu_stuff.o \
+ $(O)/hu_lib.o \
+ $(O)/s_sound.o \
+ $(O)/z_zone.o \
+ $(O)/info.o \
+ $(O)/sounds.o
+
+all: $(O)/linuxxdoom
+
+clean:
+ rm -f *.o *~ *.flc
+ rm -f linux/*
+
+$(O)/linuxxdoom: $(OBJS) $(O)/i_main.o
+ $(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) $(O)/i_main.o \
+ -o $(O)/linuxxdoom $(LIBS)
+
+$(O)/%.o: %.c
+ $(CC) $(CFLAGS) -c $< -o $@
+
+#############################################################
+#
+#############################################################
283 linuxdoom-1.10/README.asm
@@ -0,0 +1,283 @@
+
+README - DOOM assembly code
+
+Okay, I add the DOS assembly module for the historically
+inclined here (may rec.games.programmer suffer). If anyone
+feels the urge to port these to GNU GCC; either inline or
+as separate modules including Makefile support, be my guest.
+
+Module tmap.S includes the inner loops for texture mapping,
+the interesting one being the floor/ceiling span rendering.
+
+There was another module in the source dump, fpfunc.S, that
+had both texture mapping and fixed point functions. It
+contained implementations both for i386 and M68k. For
+brevity, I include only the i386 fixed point stuff below.
+
+//====================================================
+// tmap.S as of January 10th, 1997
+
+//================
+//
+// R_DrawColumn
+//
+//================
+
+ .data
+loopcount .long 0
+pixelcount .long 0
+
+ .text
+
+ .align 16
+.globl _R_DrawColumn
+_R_DrawColumn:
+
+ pushad
+
+ movl ebp,[_dc_yl]
+ movl ebx,ebp
+ movl edi,[_ylookup+ebx*4]
+ movl ebx,[_dc_x]
+ addl edi,[_columnofs + ebx*4]
+
+ movl eax,[_dc_yh]
+ incl eax
+ subl eax,ebp // pixel count
+ movl [pixelcount],eax // save for final pixel
+ js done // nothing to scale
+ shrl eax,1 // double pixel count
+ movl [loopcount],eax
+
+ movl ecx,[_dc_iscale]
+
+ movl eax,[_centery]
+ subl eax,ebp
+ imull ecx
+ movl ebp,[_dc_texturemid]
+ subl ebp,eax
+ shll ebp,9 // 7 significant bits, 25 frac
+
+ movl esi,[_dc_source]
+
+
+ movl ebx,[_dc_iscale]
+ shll ebx,9
+ movl eax,OFFSET patch1+2 // convice tasm to modify code...
+ movl [eax],ebx
+ movl eax,OFFSET patch2+2 // convice tasm to modify code...
+ movl [eax],ebx
+
+// eax aligned colormap
+// ebx aligned colormap
+// ecx,edx scratch
+// esi virtual source
+// edi moving destination pointer
+// ebp frac
+
+ movl ecx,ebp // begin calculating first pixel
+ addl ebp,ebx // advance frac pointer
+ shrl ecx,25 // finish calculation for first pixel
+ movl edx,ebp // begin calculating second pixel
+ addl ebp,ebx // advance frac pointer
+ shrl edx,25 // finish calculation for second pixel
+ movl eax,[_dc_colormap]
+ movl ebx,eax
+ movb al,[esi+ecx] // get first pixel
+ movb bl,[esi+edx] // get second pixel
+ movb al,[eax] // color translate first pixel
+ movb bl,[ebx] // color translate second pixel
+
+ testl [pixelcount],0fffffffeh
+ jnz doubleloop // at least two pixels to map
+ jmp checklast
+
+ .align 16
+doubleloop:
+ movl ecx,ebp // begin calculating third pixel
+patch1:
+ addl ebp,12345678h // advance frac pointer
+ movb [edi],al // write first pixel
+ shrl ecx,25 // finish calculation for third pixel
+ movl edx,ebp // begin calculating fourth pixel
+patch2:
+ addl ebp,12345678h // advance frac pointer
+ movl [edi+SCREENWIDTH],bl // write second pixel
+ shrl edx,25 // finish calculation for fourth pixel
+ movb al,[esi+ecx] // get third pixel
+ addl edi,SCREENWIDTH*2 // advance to third pixel destination
+ movb bl,[esi+edx] // get fourth pixel
+ decl [loopcount] // done with loop?
+ movb al,[eax] // color translate third pixel
+ movb bl,[ebx] // color translate fourth pixel
+ jnz doubleloop
+
+// check for final pixel
+checklast:
+ testl [pixelcount],1
+ jz done
+ movb [edi],al // write final pixel
+
+done:
+ popad
+ ret
+
+
+
+//================
+//
+// R_DrawSpan
+//
+// Horizontal texture mapping
+//
+//================
+
+
+ .align 16
+.globl _R_DrawSpan
+_R_DrawSpan:
+ pushad
+
+//
+// find loop count
+//
+ movl eax,[_ds_x2]
+ incl eax
+ subl eax,[_ds_x1] // pixel count
+ movl [pixelcount],eax // save for final pixel
+ js hdone // nothing to scale
+ shrl eax,1 // double pixel count
+ movl [loopcount],eax
+
+//
+// build composite position
+//
+ movl ebp,[_ds_xfrac]
+ shll ebp,10
+ andl ebp,0ffff0000h
+ movl eax,[_ds_yfrac]
+ shrl eax,6
+ andl eax,0ffffh
+ orl ebp,eax
+
+ movl esi,[_ds_source]
+
+//
+// calculate screen dest
+//
+ movl edi,[_ds_y]
+ movl edi,[_ylookup+edi*4]
+ movl eax,[_ds_x1]
+ addl edi,[_columnofs+eax*4]
+
+//
+// build composite step
+//
+ movl ebx,[_ds_xstep]
+ shll ebx,10
+ andl ebx,0ffff0000h
+ movl eax,[_ds_ystep]
+ shrl eax,6
+ andl eax,0ffffh
+ orl ebx,eax
+
+ movl eax,OFFSET hpatch1+2 // convice tasm to modify code...
+ movl [eax],ebx
+ movl eax,OFFSET hpatch2+2 // convice tasm to modify code...
+ movl [eax],ebx
+
+// eax aligned colormap
+// ebx aligned colormap
+// ecx,edx scratch
+// esi virtual source
+// edi moving destination pointer
+// ebp frac
+
+ shldl ecx,ebp,22 // begin calculating third pixel (y units)
+ shldl ecx,ebp,6 // begin calculating third pixel (x units)
+ addl ebp,ebx // advance frac pointer
+ andl ecx,4095 // finish calculation for third pixel
+ shldl edx,ebp,22 // begin calculating fourth pixel (y units)
+ shldl edx,ebp,6 // begin calculating fourth pixel (x units)
+ addl ebp,ebx // advance frac pointer
+ andl edx,4095 // finish calculation for fourth pixel
+ movl eax,[_ds_colormap]
+ movl ebx,eax
+ movb al,[esi+ecx] // get first pixel
+ movb bl,[esi+edx] // get second pixel
+ movb al,[eax] // color translate first pixel
+ movb bl,[ebx] // color translate second pixel
+
+ testl [pixelcount],0fffffffeh
+ jnz hdoubleloop // at least two pixels to map
+ jmp hchecklast
+
+
+ .align 16
+hdoubleloop:
+ shldl ecx,ebp,22 // begin calculating third pixel (y units)
+ shldl ecx,ebp,6 // begin calculating third pixel (x units)
+hpatch1:
+ addl ebp,12345678h // advance frac pointer
+ movb [edi],al // write first pixel
+ andl ecx,4095 // finish calculation for third pixel
+ shldl edx,ebp,22 // begin calculating fourth pixel (y units)
+ shldl edx,ebp,6 // begin calculating fourth pixel (x units)
+hpatch2:
+ addl ebp,12345678h // advance frac pointer
+ movb [edi+1],bl // write second pixel
+ andl edx,4095 // finish calculation for fourth pixel
+ movb al,[esi+ecx] // get third pixel
+ addl edi,2 // advance to third pixel destination
+ movb bl,[esi+edx] // get fourth pixel
+ decl [loopcount] // done with loop?
+ movb al,[eax] // color translate third pixel
+ movb bl,[ebx] // color translate fourth pixel
+ jnz hdoubleloop
+
+// check for final pixel
+hchecklast:
+ testl [pixelcount],1
+ jz hdone
+ movb [edi],al // write final pixel
+
+hdone:
+ popad
+ ret
+
+
+
+
+//====================================================
+// fpfunc.S as of January 10th, 1997 (parts)
+
+#ifdef i386
+
+.text
+ .align 4
+.globl _FixedMul
+_FixedMul:
+ pushl %ebp
+ movl %esp,%ebp
+ movl 8(%ebp),%eax
+ imull 12(%ebp)
+ shrdl $16,%edx,%eax
+ popl %ebp
+ ret
+
+
+ .align 4
+.globl _FixedDiv2
+_FixedDiv2:
+ pushl %ebp
+ movl %esp,%ebp
+ movl 8(%ebp),%eax
+ cdq
+ shldl $16,%eax,%edx
+ sall $16,%eax
+ idivl 12(%ebp)
+ popl %ebp
+ ret
+
+#endif
+
140 linuxdoom-1.10/README.b
@@ -0,0 +1,140 @@
+
+README for Linux DOOM Source distribution
+=========================================
+
+
+DISCLAIMER
+----------
+This is not "The DOOM Source Code" dump for a bunch
+of reasons. It is based on a DOOM development directory
+snapshot as of January 10th, but has been stripped and
+changed. Thus it is the DOOM source, but there are many
+minor differences to the source as last used by id
+Software.
+
+Note that thus neither John Carmack nor Dave Taylor nor
+anybody else at id is responsible for the contents of
+this archive, or the changes introduced to the original
+source.
+
+If there are any questions, contact me at bk@gamers.org,
+or preferably post to the mailing list at
+
+ doom-editing@gamers.org
+
+(send mail to majordomo@gamers.org, content just
+a single "info doom-editing"). I will post any updates
+or notifcation of corrections there. I will probably
+put some stuff at
+
+ http://www.gamers.org/dEngine/doom/
+
+as well. Look there for the "Unofficial DOOM Specs" as
+minimal recommended documentation.
+
+
+
+REMARKS
+-------
+I made a few minor bug fixes, added some experimental sound
+code, and, and changed the handling of IWAD dependend game
+modes. Most of the changes though have been shuffling
+around sources in a sometimes futile attempt to separate
+modules more cleanly, and make certain parts easier
+to locate and modify. There is still much left to do, but
+I hope that the current source is a good base to start
+with, especially with a cooperative effort in mind. Those
+so inclined will find the source prepared for CVS.
+
+There is a list of changes and fixes I did not get around
+to in TODO, and an incomplete worklog in ChangeLog, that
+also includes some minor ToDo statements scattered throughout
+the log.
+
+
+a) Linux SVGA
+There is no SVGA support. For development and debug
+purposes, the X11 version seems to be more handy.
+
+b) Sound - see README.sound,
+ and the sndserver.tgz archive.
+
+c) GLDOOM - see README.gl
+
+d) Win32
+There was no Win32 support in the original dump.
+
+e) DOS
+Original DOS support (including the texture
+mapping and fixed point assembler) has been
+removed, mainly because of the lack of sound
+support.
+
+f) DoomEd
+The NeXTStep DoomEd sources in the dump were
+garbled (filenames - prolly an issue of ISO9660
+with or w/o extensions). Somehow Bear never got
+around to send me a list of the correct filenames,
+and I won't bother guessing without a NeXT box
+at hand.
+
+There is a plethora of useful editors
+for DOOM. I suggest using DEU for X11.
+
+g) BSP Tools
+The BSP builder and other tools have
+been released by John Carmack long ago,
+and since improved/replaced by others.
+Again, I recommend taking a pick among
+the tools available for Linux.
+
+h) DOOM game tools
+There are a number of tools that have
+not been released, namely those which
+compiled the Things and State Tables,
+the frame animation LUT's, sound tables
+etc. Basically, they compile similarly
+complex LUT's to generate C files. The
+tools are omitted from this distribution.
+
+There are some files in the
+distribution (info.h/c, sounds.h/c)
+that are essentially the output of these
+tools. This is the data that defines
+DOOM (as a game) for all practical
+purposes.
+
+I recommend keeping them, as they are
+part of the source. In the long run,
+handling them as well as the action/
+animation functions as a separate game.so
+library (as with Quake2) seems to be a
+good idea.
+
+i) Artwork
+Neither the original artwork nor the
+misc. WAD files are included in this
+archive. You will at least need the
+shareware WAD file to run the executable,
+but it shouldn't be to difficult to get
+a hold of that.
+
+Note that the mechanism to detect the
+presence of a registered or commercial
+version is still in the source, and
+homebrew maps are still disabled. This
+is easily removed now, but as FinalDOOM,
+Ultimate DOOM and DOOM 2 are still in
+the shops, it is probably polite not
+to distribute a source or binary without
+that mechanism.
+
+This version of Linuxdoom supports Plutonia
+and TNT WAD from FinalDOOM as well. No
+guarantees, though.
+
+
+Enjoy!
+
+
+ b. 97/12/22
57 linuxdoom-1.10/README.book
@@ -0,0 +1,57 @@
+
+The DOOM Book
+
+Shortly after the Wolfenstein 3D source release,
+I sent a mail to Jay Wilbur suggesting a book
+about the DOOM engine. I anticipated a similar
+release of the DOOM sources within a year or
+two, and the obvious problems with the Wolfenstein
+sources (lack of accompanying artwork, a code
+base not maintained for quite some time) seemed
+to demand a better approach. I talked to some
+publishing company reps at the Book Fair in 1995,
+and while they were cautiously interested, id was
+not.
+
+In the last weeks of 1996, following a visit at
+id Software two months earlier, and after the
+departure of Jay Wilbur, John Carmack asked me
+whether I was still interested in doing the book.
+I was, Bear sent me a code dump, and Todd
+Hollenshead set out to address the legal concerns
+(of which were many).
+
+Unfortunately, what might have worked in 1995
+turned out to be a doomed attempt in 1997. I won't
+go into the details - let's just say that my
+leaving university and going back to full time
+writing for a living repeatedly forced me to
+change priorities on what looked more and more
+like a project unlikely to generate any revenue.
+
+By mid of the year, when the legal issues had
+finally been settled, it didn't look like I was
+going to find a publisher at all. Following the
+Book Fair in 1997 and some more discussions
+(with about a dozen publishers, total), I gritted
+my teeth and decided to abandon the project.
+
+Note that the book project as such wasn't supposed
+to hold up the source release to the public.
+However, given the legal concerns relating to
+the third party sound code in DOS DOOM, and the
+lack of Win32 support as well as the advantages of
+an OpenGL based release, the idea was to put
+together a consistent, stable code base prior to
+public release - most of which was supposed to be
+an offspring of my reformatting and modifying the
+code for the book.
+
+None of this worked out as intended. However, I
+hope that, at long last, this distribution
+will finally provide a good point to start for
+any cooperative effort to extend the already
+impressive lifespan of DOOM into the age of
+multiplayer servers and hardware-accelerated
+clients.
+
149 linuxdoom-1.10/README.gl
@@ -0,0 +1,149 @@
+
+README: glDOOM
+
+I never got around to do anything with respect to
+a Linux glDOOM port except for assembling a Linux3Dfx
+HOWTO (which, at that time, was a prerequisite
+to get permission to publicly distribute the
+already finished LinuxGlide port by Daryll Strauss).
+
+Linux q2test (and soon LinuxQuake2) demonstrate that
+Mesa with the MesaVoodoo driver is quite up to the
+requirements for a glDOOM port. If anybody wants to
+get into Linux glDOOM, please drop me a line.
+
+There is a Win32 GLDOOM port in the works, by Jim Dose.
+Quoting a recent posting by him:
+
+"I haven't had as much time lately to really work on
+the conversion. I currently have the renderer drawing
+the walls and floors as texture spans as the are in
+the software renderer. There's lighting on the walls,
+but not the floors, and sprites are being drawn, but
+not with the right texture. I figure that this is one
+nights work to get the game looking "normal". I haven't
+tested the game on less than a p200, so I'm not sure
+how it will perform under the average machine, but I
+don't expect it to be blindingly fast because of the
+number of spans that have to be drawn each frame.
+Rendering as polys is definitely the way to go.
+
+The reason I chose to do spans first was because it
+left the base renderer intact and I could concentrate
+on ironing out any Windows compatibility problems.
+Actually, the first version I had running was simply
+a blit of the 320x200 game screen through Open GL.
+Surprisingly, this actually was very playable, but
+certainly wasn't taking any advantage of 3D acceleration.
+Once the game was running, I started converting all
+the span routines over."
+
+Comment: for merging Linuxdoom with Win32, this is
+probably the best source for getting the Win32
+environment done - before more significant changes
+occur.
+
+"One problem with drawing spans is that the engine
+doesn't calculate the texture coordinates with
+fractional accuracy, so the bilinear filtering works
+vertically, but not horizontally on the walls. I may
+try to fix this, but since I plan to use polys for
+the final version, it's not really high priority.
+Also, spans don't really allow for looking up and
+down."
+
+Comment: true looking up/down vs. Heretic-style
+y-shearing seems to require either a strange kind
+of transofrmation matrix (he probably does not use
+the OpenGL transformation at all), or rendering
+all the spans as textured rectangular slices
+instead of using glDrawBitmap. No, polys are the
+way to go.
+
+"When I tackle the conversion to polys, one big problem
+I'll encounter is drawing floors. Since the world is
+stored in a 2D bsp tree, there is no information on
+the shape of the floors. In fact the floors can be
+concave and may include holes (typically, most renderers
+break concave polys down into a collection of convex
+polys or triangles). In software, the floors are actually
+drawn using an algorithm that's similar to a flood fill
+(except that a list of open spans is kept instead of a
+buffer of pixels). This makes drawing the floors as
+polys fairly difficult."
+
+A polygon based approach will require significant changes
+to the data structures used in the refresh module. I
+recommend either separating a libref_soft.so first (a
+Quake2 like approach), and creating libref_gl afterwards,
+or abandoning the software rendering entirely.
+
+John Carmack wrote once upon a time:
+"... the U64 DOOM engine is much more what I would consider
+The Right Thing now -- it turns the subsector boundaries
+into polygons for the floors and ceilings ahead of time,
+then for rendering it walks the BSP front to back, doing
+visibility determination of subsectors by the one dimensional
+occlusion buffer and clipping sprites into subsectors, then
+it goes backwards through the visible subsectors, drawing
+floors, ceilings, walls, then sorted internal sprite fragments.
+It's a ton simpler and a ton faster, although it does suffer
+some overdraw when a high subsector overlooks a low one (but
+that is more than made up for by the simplicity of everything
+else)."
+
+Well, IMO compiling a separate list of floor/ceiling polygons
+after having read the WAD file, and thus introducing this as
+a completely separate data structure to the current code base
+might be the easiest thing to do. Jim Dose writes:
+
+"One method I may use to draw the floors as polys was suggested
+by Billy Zelsnack of Rebel Boat Rocker when we were working
+at 3D Realms together a few years ago. Basically, Billy was
+designing an engine that dealt with the world in a 2D portal
+format similar to the one that Build used, except that it had
+true looking up and down (no shearing). Since floors were
+basically implicit and could be concave, Billy drew them as
+if the walls extended downwards to infinity, but fixed the
+texture coordinates to appear that they were on the plane of
+the floor. The effect was that you could look up and down and
+there were no gaps or overdraw. It's a fairly clever method
+and allows you to store the world in a simpler data format.
+Had perspective texture mapping been fast enough back then,
+both Build and Doom could have done this in software."
+
+Perhaps the above is sufficient to get you started.
+Other Issues:
+
+1. Occlusion
+DOOM uses a per-column lookup (top/bottom index) to do HLHSR.
+This works fine with span based rendering (well, getting
+horizontal spans of floors/ceilings into the picture is a
+separate story). It isn't really mindboggling with polygon
+based rendering. GLDOOM should abandon that.
+
+2. Precalculated Visibility
+DOOM has the data used by Quake's PVS - in REJECT.
+During Quake development, lots of replacements for the
+occlusion buffer were tried, and PVS turned out to be best.
+I suggest usind the REJECT as PVS.
+
+There have been special effects using a utility named RMB.
+REJECT is a lump meant for enemy AI LoS calculation - a
+nonstandard REJECT will not work as a PVS, and introduce
+rendering errors. I suggest looking for a PVS lump in the
+WAD, and using REJECT if none is found. That way, it might
+be feasible to eat the cake and keep it.
+
+3. Mipmaps
+DOOM does not have mipmapping. As we have 8bit palettized
+textures, OpenGL mipmapping might not give the desired
+results. Plus, composing textures from patches at runtime
+would require runtime mipmapping. Precalculated mipmaps
+in the WAD?
+
+4. Sprites
+Partly transparent textures and sprites impose another
+problem related to mipmapping. Without alpha channel,
+this could give strange results. Precalculated, valid
+sprite mipmaps (w/o alpha)?
110 linuxdoom-1.10/README.sound
@@ -0,0 +1,110 @@
+
+README: sound in DOOM
+
+
+1) DOS/Win32 sound
+
+id licensed a third party sound library called
+DMX for DOS DOOM. The situation exhibited
+many symptons of serious NIH "Not Invented Here"),
+and one of the consequences is that the original
+DOOM sound code does not work without DMX. As
+DMX is not publicly available, the original DOOM
+sound support is removed.
+
+Win32 was not supported in the source dump I got.
+I have no knowledge how the WinDOOM port did the
+sound handling. A Win32 port should probaly rely on
+DirectSound. So far, the Win32 glDOOM port Jim Dose
+is working on has no sound support.
+
+In consequence, the only target with a working sound
+code is UNIX, which I could only verify with Linux
+on Intel586.
+
+2) Linux sound
+
+DOOM for Linux used a separate process, sndserver.
+
+Quoting Dave Taylor:
+
+"Sound drivers should be an asychronous model, either
+a seperate thread or a seperate process. This is
+because sound should always be fed to the card without
+interruption or else you get pops and with low latency
+or else you get angry players.
+
+Now it turns out that this kind of code isn't too fun
+to write. In the days of Linux Doom, threads were not a
+happnin thing in Linux. In fact, they still largely
+aren't. You can use them these days if you have gnu's
+libc installed, but you still can't debug them because
+gdb doesn't support them properly yet. I believe the
+original seperate process had a bad latency delay
+because of the time it took for commands to be flushed
+through the pipe used to communicate with the seperate
+process. I should have looked into this more thoroughly.
+
+In Quake, I discovered that I could feed multiple
+acknowledgements to a SoundBlaster or compatible without
+any side-effects such as pops or other malfunctions.
+This discovery led me to switch to a completely synchronous
+model, much much easier to debug and understand, so I
+think this was fairly intelligent. Although we had to
+populate the game with calls in the right places to keep
+the sound buffers fed, and although it wasn't gauranteed to
+be always fed, well over 99% of the time, it was fed, and
+your the latency was never worse than the frequency of your
+refills (several times per frame) plus a small lead time
+(40th of a second?)."
+
+The separate sndserver code base introduced some redundancy
+(WAD access for sound lumps) for each UNIX target (Sun, SGI,
+Linux) and more differences between DOS and UNIX version.
+However, I kept the IPC based parts in the source, and
+separated the sndserver target in another directory to avoid
+further redundancy. There seem to be a few bug-like things
+going on in the sndserver that do not receive penalty as
+the program has to do only a simple task. One example would
+be a libc realloc mixed with zone memory allocation.
+
+Ungraceful and untimely demise of Linuxdoom (core instead
+of I_Error) will leave idle sndserver processes in your
+system, blocking /dev/bsp. Kill them manually.
+
+I put the non-redundant parts of the sndserver program
+into the i_sound module of doom, and with the SND_SERV
+compiler switch you can choose to use the internal sound
+support. However, there is a problem with e.g. the
+double shotgun and the plasma gun - walk up to a wall,
+face it straight, and fire. The sound output is crappy.
+This vanishes with decreasing screen size. A similar
+problem occurs with trimer driven asynchronous output
+enabled by SNDINTR.
+
+I agree with Dave that threads would be preferable.
+With respect to Linux ports of John Carmack's next
+Trinity engine, this one will rely on Win32
+multithreading e.g. for input sampling. So the Linux
+community will have to sort out threads anyway :-).
+
+To improve the current sound server, other means of
+IPC should take care of the latency. The mixing
+buffer/command buffer as shared memory comes to mind.
+
+
+
+3) Music support
+
+There is, and was, no music support in Linuxdoom. Fine with
+me - I wouldn't give a bat's tail feathers for DOOM music.
+Your mileage may vary. There are a few leftovers of the DOS
+music support also interfacing DMX, so there is a place
+to start. However, in the age of CDROM based music, I
+recommend getting e.g. Workman to cooperate with DOOM
+(currently, DOOM accessing the soundcard SpekerOut
+interferes with Workman controlling the CD drives
+SpeakerOut), so musci could be chosen and run completely
+independend of the game. You could try Linuxdoom with
+Q2 music that way.
+
123 linuxdoom-1.10/TODO
@@ -0,0 +1,123 @@
+
+- create Web repository for sources, patches,
+ news, and pointer to doom-editing mailing
+ list.
+
+- get DOOM Public License from id
+
+-----------------------------------------------
+
+- remove m_fixed, switch to floating point
+ More stable, and prolly even faster.
+
+- make SCREENWIDTH/HEIGHT work at startup?
+ Well, the HUD/STBar stuff is tied to the
+ scales implied by the graphics. Rather do
+ GLDOOM and use texture mapping.
+
+- fix aspect ratio?
+ 320x200 is nothing viable nowadays.
+ A 320x240 base (4:3) would be a lot better.
+ See above on width/height.
+
+- limited look up/down by y-shearing?
+ Prolly not worth it, rather switch to GLDOOM.
+
+- switch to C++?
+ The action function pointers have varying
+ argument lists (no parameter, one, etc.).
+ C++ doesn't like that much. A major rewrite.
+
+- switch to doommain.c plus libdoom? Have
+ libref, libgame etc.?
+ Another major rewrite.
+
+- use XFree86 DGA, prolly not that much faster
+ than MIT SHM, but allows for directly sampled
+ mouse (and even freelook). Recommended for
+ GLDOOM.
+
+- put together an accompanying developer toolkit
+ source distribution: DEU, RMB, BSP for Linux/X.
+
+- move info.h, info.c, sounds.h, sounds.c and
+ other data to a separate lump in the WAD,
+ or into a libgame.so, to separate the
+ generic stuff (refresh, I/O) from the
+ DOOM specifics.
+
+- decide whether precaching all sounds is
+ better than retrieving and releasing
+ every so often. DOOM seems to do that
+ frequently (8bit stuff, originally for
+ DOS), and the Linux sound is 16bit
+ (conversion in the mixing, requires
+ some padding) - we prolly got the memory
+ to spare.
+
+- 16bpp CLUT. The lightmaps and the
+ framebuffer could be changed to switch
+ to 64K colors. Prolly better to do
+ GLDOOM right away.
+
+- remove checks for commercial etc., in
+ non-essential issues (enabling PWAD's).
+
+- change (simplify) determination of
+ sky texture (done by game version).
+ Explicit?
+
+- remove all game version checks
+
+- different handling of Demo - don't
+ exit on "different game version"
+
+- how about shareware/retail "You are here"
+ intermission animation? Wasn't in
+ commercial (DOOM 2).
+
+- double shotgun in DOOM1, all weapons with
+ shareware
+
+- checks for required lumps. We need fallbacks
+ for lumps that are not present, that is,
+ default sounds etc. to be used instead,
+ or removing THINGS w/o sprites etc.
+
+- client/server? I'd suggest ripping off some stuff
+ from the abandoned IBM WebView project
+
+- Blockmap
+ The BLOCKMAP lump might be (partly) redundant,
+ as the BSP allows for clipping (except certain
+ LineDefs that will not spawn Segs).
+
+- LOS
+ REJECT and intersection based LOS checking could be
+ done using the BSP. In case of REJECT, certain
+ monster AI special effects would be lost, though.
+
+- correct handling of height in collision. This is
+ not done, and the checks are scattered around in
+ many places. It does require handling of "player
+ on top of monster" situations, too - we have to
+ make sure the players falls off far enough to