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

hiya !

  again, i some found sparetime to work on my wolf3d conversion. not much
  has changed since the last version - i only added those so called 'push
  walls', this time. those are marked by some slimy yellow walls just to
  let you know where they are - in the original version those 'push walls'
  are doors to secret areas. this should be the case in the final version
  of my port, as well.

  concerning the controls, nothing has changed so far - just use space to
  activate the pushwalls.


  remaining/known bugs that will be fixed soon:

  - angle still exceeds table range at one certain facing like in the last
    beta
  - sometimes doesn't restore on the Falcon :/
  - doesn't run from MAGIC! (this os seems to have some malloc/mxalloc
    oddity i don't know of yet, maybe someone can help out with a doc
    or something ?)


  stuff to be covered in the next version:

  - static objects (chairs, tables, lamps...)


requirements/specs.:

	-any 512Kb+ ST/e/MST/e/Falcon/TT030 (dunno about accelerators/clones)
	-RGB/VGA
	-Fastram is supported
	-MiNT compatible

any urgent requests: ray@atari.org

ray//.tscc                                                            08-28-02
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

history of v0.3 beta:

08-27-02	started working on pushwalls - this should be a feature to be
		added easily, compared to doors as there can only be one 
		active pushwall at a time.

		added: pushwall module - after some hours of fixing something
		       still seems to bug as hell, though.

08-28-02	fixed: Pushwall bugs. time to include some texture to mark
		       those special walls for you.

		fixed: timingbase problem on 8Mhz machines.

		added: 256 color title picture + own display routine :P . how-
		       ever, i get bad interferences at the left border and some
		       new fading routines are needed, as well.

08-29-02	desperatly trying to fix the interferences - with 16Mhz+ it works
		but on a plain 8Mhz ST the CPU just seems to be too slow to update
		the palette left of the pixelized scanline. i will have to find a
		trick to update the palette at the end of a screenrow, hence

09-30-02	finally, and after several conversations with evl, keops and cyclone,
		(hi there!) i found a way to sync to the end of a screenrow (pixel-
		ized) on almost any machine, cpu speed independent ("almost" means i
		can't guarantee if it works with accelerators). it works by checking
		if the left border has been finished via $ffff8209.w and if the	right
		border has begun yet afterwards (because during the the borders this
		low byte of video address counter won't be incremented as no pixels
		are being drawn, of course - this way even other timers may remain
		active !).
		nonetheless, i have to use 2 diffrent sync-routs for RGB and VGA
		monitors, because a double-scan is done on the last ones, meaning
		each scanline gets read and drawn twice (so according to this i just
		have to use the sync method twice, logically).
		time to fix up some fading routs, now.
		

		removed: 256 color title-pic (bacause it seems like i need to reca-
		librate some nops depending on the machine though :( ) - this has to
		wait until the next version, so this one features the 16 color ver-
		sion of the piccy again, sorry !

		bug: the program doesn't restore on the Falcon for some strange rea-
		     son. but to me it seems like this was the case in the last ver-
		     sion, too.


		done!