			Wolfenstein 3D ST (v0.5 Beta)
			-----------------------------

hiya fellas!

  i'm proud to present you the next beta release of my wolf3d project. it
  has been heavily delayed this time due to various issues (finishing beams,
  a really nasty bug, lazyness, studies etc.). you see i'm sorry you had to
  wait for more than a year now.

  this new version incorporates a software 4-voice digisound engine which
  adds alot to the atmosphere. samples get replayed at 12.5khz if DMA sound
  is available while they will be subsampled to 3khz on plain YM machines
  (ST, Mega ST) for speed reasons, since the DAC has to be emulated via a
  cpu-time demanding timer a interrupt.

  furthermore i've added animated enemies yelling at you, starting to
  chase you and shoot at you as soon as you got spotted. atm. there's only
  a single enemy class (guard) and you can't shoot them yet even if i added
  a (not yet animated) weapon - so please do not bother. a more advanced
  gamelogic has to wait until one of the next versions.
  i've finally added pick-up items, too.

 IMPORTANT NEW FEATURE! :)
  you can toggle the level of detail using the '*' key on your numpad.
  the high resolution mode is really only recommended on faster machines
  like the Falcon or TT (i couldn't test this on the Mega STE merely due to
  the lack of a such) unless you decrease the window size. enjoy...


 remaining/known bugs that will be fixed soon:

  - restoring issues in tos versions <= 2.06 remain.

  please drop me a line if you notice further bugs on your configuration


 stuff to be covered in the next version:

  - a fullfeatured gamelogic (an animated weapon giving you the ability
    to shoot those bad guys, a score/health counter, BJs animated face etc.)


requirements/specs.:

	-any (M)ST(e)/Falcon030/TT030 (CT60 support is yet to follow)
	-you'll temporarily need at least 2Mb to run the preview as
	 data aren't loaded in from disc atm. (i'll go for 1Mb later on)
	-RGB/VGA
	-Fastram is supported
	-MiNT compatible

any urgent requests: ray@tscc.de

ray//.tSCc.                                                           05-02-05
------------------------------------------------------------------------------
history of v0.5 beta:

07-17-04	optimized: player collision routines.

08-06-04	finished my 4 channel sample mixer (thank you earx for the
		sample-segmentation optimization hint). samples are replayed
		at 12.5khz mono on DMA sound machines ((M)STe/TT030/Falcon030).
		i still need to add support for (M)STs where 3khz mono should
		not slow down too much emulating sample replay via their
		YM2149 and a timer a interrupt.

08-12-04	added: sound support for (M)STs. the replay quality of 3khz
		       is a bit poor but better than no sound at all on
		       those machines imo.


08-17-04	i finally included the sound system with wolf3d and after some
		bugfixing it seems to work out fine on all systems it could
		be tested with. however i still need to find a way to stabilize
		my rasters on (M)ST machines where DMA sound is emulated via
		a timer a isr which interferes here if sound is played.

08-19-04	there was no way for me to actually stabilize the gamepanel's
		palette on (M)STs, not even by moving the DAC emulator from 
		timer a to timer d exchanging it with my keyframing interrupt
		and hoping for MFP irq priorities to do their job, but it
		didn't work out :/.
		however i sort of solved that problem by moving the most simi-
		lar colors to the same palette entries so the flicker doesn't
		get visible.

10-02-04	after a bit of a break (i was busy with moving to aachen) i
		finally implemented the *very* important "MoveActors" procedure,
		which was sort of a boring issue since i mainly had to convert
		bunches of actor-class definitions, sound defs and so on from
		c-structures to rs.x-lines.
		done with that i can now place enemies going into attackmode as
		soon as they've spotted you. due to the lack of movement/chasing
		routines they will stay in place (which looks quite funny with
		sprite animations). fortunately, i'll have one more week of
		sparetime so i should be able to code these routines very soon.

10-04-04	i've included a "FirstSight" procedure, so that there are now
		enemies	not directly reacting upon noticing you. a random
		attention sound is yelled.

10-05-04	today i bothered with hand porting and optimizing the very
		extensive but at least just as important source module
		"EnMove.s".
		having incorporated it with my sourcecode i did	not have the
		time to test those movement routines because i had to iron out
		some typos and stuff before. additionally i'm too tired for
		bugfixing sensitive stuff like this code after the "exhausting"
		porting task tonight. i'm quite curious about if my movement
		routines do work correctly though but testing must wait until
		tomorrow.

10-06-04	i've played around with those "EnMove.s" routines a bit and
		after some fixes enemies come to move across now, but as it
		seems i'll have to do alot of fixings due to various issues
		(enemies dodging instead of chasing you, moving into the wrong
		direction, buggy collisions for enemies etc.) :/.

10-07-04	alright, at least i could fix my "MoveActor" routine so that
		actors can be moved on into arbitrary directions by a certain
		keyframing amout. i obviously need to keep searching for a
		series of bugs preventing the chase/dodge direction selection
		from working correctly - so i've spotted the problem, finally.

10-08-04	i heavily optimized those movement routines relying on a com-
		pletely diffrent concept. the good news: the chase direction
		selection works correctly now even if there are still some
		collision issues left. the bad news: i had to simplify the
		enemy logic a bit so they aren't supposed to be able to open
		doors anymore.

10-09-04	today i applied another number of minor optimizations to the
		3d rendering engine.

04-04-05	man, that's been a very long pause again. but now that our
		falcon demo "beams" is finally finished i can return to working
		on the interesting bits eventually. it's been a long time since
		i touched the wolf3d sourcecode at all so i'll need a bit of
		time to get into it again.

		fixed:  door collision issues on 8mhz atari's (sometimes doors/
			pushwalls didn't react. this was due to a too large motion
			keyframing value which didn't appear on faster computers
			and which needed clamping in order to not step across more
			then a single block per frame)

		i assume there's a similar problem with the enemies' motion
		causing collision errors with those.

		i've played around a bit with my c2p/scaler code compilers so that
		i can have a hi detail mode (160x160 px.) that should be accessible
		on faster machines later on.

04-05-05	ok, for now i added a check for the '*'-key to be able to toggle
		the level of detail during the game. i also had to fix the sprite
		scaling so that position and scale get fixed up in the high detail
		(2x1 px.) mode.

		still no success with fixing the enemie collisions :(.

04-06-05	i eventually changed the packer from ICE! to lz77 as i recently
		fixed it. it did so rather due to 'cosmetic' reasons...

04-07-05	today i've implemented a little conversion ultility which generates
		a codetable from a picture so that i can quickly paint 1*1 sprites
		into the screen incorporating pixeldata into the code directly (i.e.
		i've finally decided to add a weapon).
		i still need to add optimization on runlength encodable spans to my
		utility so that painting get's a bit quicker.
		the compiled code works as follow's:

		sprite	andi.l	#pxmask01,(a1)	; Mask out significant pixels, plane 0-1
			ori.l	#pl01,(a1)+	; Set significant pixels
			andi.l	#pxmask23,(a1)	; Same for plane 2-3
			ori.l	#pl23,(a1)+
			.
			.
			.
			lea.l	(320-SprX)/2(a1),a1	; Destination skip
			.
			.
			rts

04-08-05	optimized: RLE optimization on blank sections. for instance move.l is
			   used instead of andi.l/ori.l if pxmask == 0x00000000, as well
			   as addq.l #skip,a1 / lea.l skip(a1),a1 along colorkeyed spans.

04-09-05	added a few lines of code so the weapon gets justified depending on the
		window size and resolution.

04-18-05	after a bit of a break i think i finally spotted the reason for the enemy
		collisions to not work properly. i assume the problem is caused during
		diagonal movements where i don't check for the "in-between" cells.
		i'll still need to verify this, however.

		yes! i was right, so enemy collisions are finally fixed completely. i need
		to extend the code a bit though so that enemies (except for dogs) can open
		doors, too.

		bug: enemies disappearing at certain facings and/or distances

04-26-05	fixed: the bug described above was due to the rendering engines limited
		       view on the game map and the way, enemies are marked within it.
		       the whole problem was about removing and replacing goal markers
		       which i could fix now, obviously. but gosh, i'll need to take
		       care of the doors now.

		fixed: too near wallslices getting clipped off to soon in the high
		       detail mode. plus i limited the minimum size for the game window
		       so that the weapon (which doesn't get rescaled) doesn't overlap.

		doors seem to kind of work now but for some reason only in the north and
		south direction. i'll try to fix that in one of the following releases.

		i skipped the "SelectDogeDir" routine, to save lots of cycles as to me the
		enemies movement seems dodgy enough yet.

		the "Actorat" object will get build dynamically as opposed to statically
		compiled data as used before. this gives me the possibility to quickly
		and easily make up new test levels without having to compile loads of
		data. nonetheless this solution is far from finished where the complete
		world data are supposed to be read from harddisk.

04-27-05	i extended the "EnThink" module so enemies can now shoot at you (without
		doing you any harm atm.). though the solution is a bit "hacked", since
		they will stop shooting as soon as _they_ are out of your field of vision
		while they shouldn't be shooting as long as they can't se _you_, actually.

04-28-05	today i made up a little routine that interprets the original level data,
		which means i had to include all the textures, which did heavily increase
		the binary's size - however this is a temporary solution, as i plan to
		make the engine load only needed textures later on to save memory.

		ok, after experimenting some bit i improved the level processing so that
		only the needed wall shapes are expanded out of an lz77 packed block of
		texture data, this way i could save roughly 120kb. but still this is no
		final solution, where data are supposed to get loaded from harddisc.

		i extended the level processor a bit so it spawns pushwalls and doors as
		well, but there seems to be a problem with item data not corresponding to
		the tilemap so doors get misplaced and so on, this might be due to a bug
		in my routine, too which causes the level data to be interpreted
		incorrectly somehow :/. i need a break now...

04-30-05	ok, after some fixings pushwall and door records now seem to get
		initialized correctly. i'll still have to find out how to interpret the
		"SpawnPlayer" type entries so that our player gets placed correctly on
		startup, as well. spawning statics and enemies will be the next issue
		afterwards.
	
		spawning the player works ok now, too. time for some statics

		i just implemented the static spawning procedure and it works fine, but
		atm. every static gets assigned the same texture with doesn't make much
		sense...i'll need to make up some sprite management system there, too.

		implemented a temporary "GetBonus" routine to let me have pickup-items,
		eventually.

		extended the door type structure, so that i can have various door types
		(steel, silver key, gold key, elevator).

05-02-05	today i improved the texture management a bit, so i can have dynamically
		allocated texture buffers as an advantage for machines with only 1mb.
		i'm not able to use malloc() for allocating texture buffers though,
		since i'd need to reorganize my routines a bit (gemdos/bios and xbios
		get overwritten by the c2p tables) and hence the demo requires 2mb to run
		atm. i'll try to fix this problem later on, a solution would be loading
		the textures _before_ generating the c2p table.

		ok, i now added the static sprite management system with using lz77 packed
		textures just like i do with all the wall shapes. time to finally bother
		with spawing some enemies...

		done!