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

hey!

  it must have been at least a year of silence since the last wolf3d beta.
  but i sort of returned from death after a hdd-crash, my military service
  and several periods of very bad and demotivated mood.

  this time i added the following features:
  another faster and less memory consuming c2p, static objects (a major step
  towards a more complete game engine) and a 256 color title picture (from
  the apple IIgs version). you can also resize the gamewindow by pressing
  +/- during the demo to gain some speed on 8 mhz machines.

  remaining/known bugs that will be fixed soon:

  - wolf seems to have trouble restoring the system in tos 1.6x and 2.06

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


  stuff to be covered in the next version:

  - pickups, maybe even some actors yet(?)


requirements/specs.:

	-any 1mb+ (M)ST(e)/Falcon030/TT030 (there's an SDL port for CT60s)
	-RGB/VGA
	-Fastram is supported
	-MiNT compatible

any urgent requests: ray@tscc.de

ray//.tSCc.                                                           07-23-04
------------------------------------------------------------------------------

uncomplete tech history of v0.4 beta (some data got lost during the hdd-crash
mentioned above)

xx-xx-03	fixed: 256 color title picture + own display routine to
		       work on "fast" machines. (can't remember the date,
		       exactly)

xx-xx-03	added: sprite scaling routine. the coordinate transform bugs
		       as hell. z-buffering works fine (for clipping sprites
		       against walls)

07-11-04	today is a great day: ninjaforce resent the complete set of
		game data (gfx, sfx) which got lost during a hdd-crash last
		year. so after playing around with some annoying parsers and
		convertors i had to write in cpp i recovered the texture and
		sprite data in a format useful to my gameengine...niceness.
		
		i'm just listening to john frusciante's awesome "the will to
		death" album, which for strange reasons inspired me to re-
		turn to optimizing the c2p once more (as i'm hardly satisfied
		with the excessive useage of that slooow i8(an,dn.l) addres-
		sing mode).
		well here's the result: i could save another 16kb storing the
		2 used conversion-tables in an interleaved format...pretty
		blind fault to store them in a row in the first place.
		remembering some interesting conversations with defjam and
		ultra last year i remembered a dirty possibility of placing my
		table(s) at an absolute position in a low memory area (possibly
		overwriting useful bios/xbios routines) 0x00001010.w, for
		instance. for preprocessed pixel data my c2p becomes:

			movem.w	(a0)+,a2-a5	; Fetch 4*2 pixels
			move.l	64(a2),d0	; Convert to bitplane data
			or.l	(a3),d0
			move.l	64(a4),d1	; Remember the tables are
			or.l	(a5),d1		; interleaved now, hence 64
			movep.l	d0,ofs(a1)	; Write out 4*2
			movep.l	d1,ofs+1(a1)	; double pixels
			...

		now beat dis!!! i believe there can't be any faster byte-c2p ;).
		however, i will check it out tomorrow. if it works i'll	count the
		cycles and give you a vbl/frame result, as usual. though i know
		it must be definately faster than the old version.
		
		fixed: sprite transformation & clipping. the positioning
		       "bug" occured due to a wrong projection formula,
		       i merely forgot to divide by z for calculating the
		       screen x coordinate of a sprite, quite dumb.

07-12-04	rude!! the new c2p works. it takes 1.4 vbls without, 1.824 vbls
		with linedoubling for a 160x80 screen (8mhz st, PAL). that's almost
		as quick as earx' fastest nibble c2p. i even managed to	run that
		stuff from magix and mint+multitos without a fucking up the system
		(don't forget i place a 16kb table at 0x00001010.w).
		i'll need to employ the pmmu on 030 machines in order to be able
		to place the c2p table in fastram if available for more speed,
		in the future.

		added: the sprite scaling routine interprets colorkeyed pixels
		       as transparant areas now.

		bug: strange, the whole thing crashes on steem (tos 1.62, 2.06)
		     but runs fine on my mega st, falcon030 and tt030.

07-13-04	optimized the sprite routines to use addx for prescaling the
		columns.

07-14-04	optimized the sprite scaling to take advantage of the fact that
		i don't need to to refetch pixels and check for colorkeying in
		case of repetitions. i.e.

			move.b	source(a1),d0
			bmi.s	*+6
			move.b	d0,dest1(a2)
			move.b	source(a1),d0
			bmi.s	*+6
			move.b	d0,dest2(a2)
			...

		becomes

			move.b	source(a1),d0
			bmi.s	*+10
			move.b	d0,dest1(a2)
			move.b	d0,dest2(a2)
			...

		as an obvious optimization.

07-15-04	fixed: runs from steem finally. so i assume/hope the new beta
		       runs ok on (mega) ste machines.

07-16-04	optimized the c2p for size, now that it is as speedy as	it gets.
		i don't see a point in spending some 44kb for unrolling the whole
		loop and saving about 2 scanlines skipping the dbra. i "wrapped"
		the routine into a nice rowloop now so that it runs even faster
		on cached machines.

07-17-04	optimized the sprite scaling routine to refrain from a jsr+rts for
		every column. the code gets directly compiled into a column loop
		and hence i don't need to jsr to the slice-scaling routine for every
		single column.


		hell what is that!X!?!!?X - MagX seems to have corrupted my wolf3d
		source directory...oh mama, why didn't i do any backups!! - hell :((

07-17/18-04	pheew, i were able to recover the sourcefile in a manual cluster
		search action leasting several hours (extra special thnx must be
		given to neo-rg, swe, cyclone-xtroll for their advises. without your
		help wolf3d would be dead now! since i never made backups not even of
		any old versions).
		this disaster has surely taught one thing: always keep your stuff
		backup'ed...noticing how much your sources mean to you only due a
		hdd-crash or data loss isn't really necessary at all.

07-18-04	i could save another 100kb optimizing and fixing the "per scanline
		palette" display routine which now fades it's palettes in realtime
		of using a generated chunk of prefaded palettes.

		bug: shit, the used palette fading procedure seems to take longer
		     than a scanline and hence i can't display the title screen
		     correctly on STs and the Falcon030...i'll have to optimize it.

07-19-04	today i've "stolen" some ideas of neochrome master's hbl system
		in order to make it run more stable and flexible. as before the
		colors are changed in the right border so rasters should be 100%
		stable even on TT030s and Falcon030s but this time a rasterline	is
		only grabbed if the palette is about to be changed for the next
		scanline. this way just as many cycles as necessary for syncing the
		rasters are wasted (not for 200 scanlines all the time as before).
		as it is completely irq based the system should even be flexible
		enough to be used during the game itself or menus and so on (whith a
		tune in the background) while letting screen elements appear more
		colorful...niceness.

		fixed: allright, i had to go for the memory consumptive fading
		       because there was no way for me to do the realtime fading in
		       less than one scanline on an 8 mhz st, eventually.

07-20-04	applied some minor optimizations on the 3d engine.

07-21-04	added support for multiple statics i.e. i extended the engine to
		detect visible sprites and draw them from back to front.

07-22-04	i have implemented a simple sprite spawning procedure so that i can
		manually place statics here and there.

		added: function keys to resize the gamewindow in realtime.

		i optimized the sprite scaling a bit so that invisible sprites get
		sorted out before any prescaling is performed.

07-23-04	optimized the collision routines a bit, added support for collision
		detection with sprites. i'm just ready for placing some statics now.

		done!