22 May 2003
-----------

* Fixed a bug where the movement clipping lines array was being
  overrun in extreme circumstances. Thanks to BlasterDRP for
  pointing this out. See the epilogue for more details.


17 May 2003
-----------

* With Ken's help the rendering performance in 1024x768 is now
  dramatically improved. By making scanlines odd lengths the CPU
  cache issues associated with multiples of 4096 are now eliminated.
* Modified the 16-colour emulation functions since 640 bytes is no
  longer the pitch of one line.
* Added auto-repainting of the frame if WM_PAINT is posted in the
  winlayer. The repaint happens on a call to handleevents();


15 May 2003
-----------

* Rewrote the map menu.


11 May 2003
-----------

* Rewrote the onscreen display. It's now a lot like Quake's console.


7 May 2003
----------

* Changed CACHE1D.C to open the group file in read-only mode. Why it
  was being opened in random-access is a mystery to me. This fixes
  problems where the GRP file was read-only and the games would not
  start. Thanks to Sean Magiera for this one.
* Added detection of input devices to winlayer.c (and made sdlayer.c
  currently enable only keyboard and mouse without testing). Now the
  Duke input code can grow a little more intelligent.
  

1 May 2003
----------

* Made Ctrl+Tab show sprite stats in the way Alt+Tab does.
* Added task switching disabling to winlayer.c.


25 April 2003
-------------

* Modifications here and there, plus I've adjusted the Makefile to
  allow code which links against the engine to compile its own copy
  in its development tree. Duke uses this to compile the engine
  without voxel support.


17 April 2003
-------------

* Various changes have been made in order to fully support my Duke3D
  port.


7 April 2003
-------------

* Quite a few minor changes have been made here and there.
* Added support to the interface layers for game-defined input event
  callbacks which are used with the jMACT library I have written for
  Duke.
* Fixed a bug which was preventing screen-tilting and savegame screen-
  shots from being drawn in Duke3D. Side-effect being windowed render
  mode is now more similar to fullscreen in its behaviour, ie. the
  frameplace variable is set to NULL when unlocked.


1 April 2003
-------------

* Thanks to a report by admin@combatgold1.co.uk these bugs are fixed:
   - Alt-key combinations broken. Thankyou for nothing, DirectInput.
   - Prompts for menu, 3d-mode quit, etc not being displayed. A little
     short-sightedness on my part to blame here.
   - Crash on changing palette to a palette mapping that is NULL.
     This has been a bug from the very beginning in Ken's original DOS
     version too, benign back then but turned malignant now thanks to
     the great debugging tool known as the segmentation fault. Fixed now.
* Took a leaf from SDL's book and made the input code not suck anymore
  by having buffered keyboard and mouse with event objects to tell when
  there's data available. Very nice. Something I should have done from
  the start had I had a brain. Mouse is now perfectly smooth.
* Made the flash speed of highlighted sprites and lines in Build derive
  from the clock and not the speed at which the frames can be drawn to
  the display. In DOS, locking to the display refresh worked fine, but
  my haste in porting originally did not take this into account. Fixed
  now.
* Fixed a problem in my very amateur DirectDraw code where I wasn't
  restoring surfaces once they'd been lost (d'uh). We now have a picture
  when Alt-tabbing back to the game/editor.
* Made operation on 8-bit desktops much more sane. It actually kinda
  works reliably now.


Bugs present in Ken's original source
-------------------------------------

This epilogue is here for those people wishing to do their own port of
the Build source and wish to save time tracking down bugs in Ken's source.
The bugs here are the ones I found during my travels and the list should
not be considered complete. Thankfully, Ken's code is very solid and the
bugs that do exist did not pose a serious threat under DOS, but they do
make life very interesting these days.

(Line numbers refer to Ken's original source distribution)

ENGINE.C l1222, l1388, l7225:
	palookup[] is accessed from the assembly functions to translate
	palette indexes to alternate indexes for palette-shifting of
	images. It contains pointers to tables which map the original
	palette index to the new index. Unused lookup entries have their
	pointer set to NULL. If a NULL palette lookup is referenced then
	a null-pointer exception is raised. In DOS this just caused
	garbage palette mappings. In Windows/Linux it causes segfaults.
	A fix for this is to add a line after the specified ones like:

	if (!globalpalwritten) globalpalwritten = palookup[globalpal];

	This remaps the NULL palette to the default one.

ENGINE.C l5691, l5692, l5697, l5698:
	drawline16() is used for the 2D map view in the BUILD editor.
	In the clipping calculations it sometimes happens that the x-
	coordinates are not properly clipped to the left or right of the
	video memory and are offscreen by one or two pixels when clipping
	against the very top or very bottom rows of video memory. Adding
	these checks before the closing braces of the specified lines
	makes sure the coordinate does not go negative and segfault.

	Line 5691 and 5698:    if (x1 < 0) x1 = 0;
	Line 5692 and 5697:    if (x2 < 0) x2 = 0;

ENGINE.C l88, l8326:
	slopalookup[] is a table used for drawing sloped sector floors
	and ceilings. It holds the palette shading indicies for each
	scanline. Problem is, in high resolutions somewhere around
	1024x768, this array is too small and memory corruption happens
	when the code writes past the end of this array. The way to fix
	it is to rewrite the algorithm. Since that's an unattractive
	proposition, increasing the size of this array will hold the
	problem off for more typical cases.

	Line 88:	long slopalookup[16384];
	Line 8326:	... else shoffs = ((16380-ydimen)<<15);

ENGINE.C l6773:
	The addclipline() macro appends a clipping line for the movement
	clipping code to test, but it doesn't attempt to see if adding
	the new line would overrun the buffer. Extreme cases exist where
	the buffer overruns and the game crashes. The problem can be fixed
	by testing if clipnum is less than MAXCLIPNUM before adding the
	new line.

	#define addclipline(dax1, day1, dax2, day2, daoval)      \
	{                                                        \
	    if (clipnum < MAXCLIPNUM) { \
		clipit[clipnum].x1 = dax1; clipit[clipnum].y1 = day1; \
		clipit[clipnum].x2 = dax2; clipit[clipnum].y2 = day2; \
		clipobjectval[clipnum] = daoval;                      \
		clipnum++;                                            \
	    }                           \
	}                                                        \

	This change will increase the possibility of clipping bugs though
	because not all possible sprites may being included in the test,
	so increasing the MAXCLIPNUM constant on line 31 to 1024 will
	decrease the chance of this happening.
