DOOM IT YOURSELF 4.4.2
======================



For general information on how to install DIY see the previous UpdateM* files
and the ReadMe file that came with the original DIY (except that the patching
phase is no longer relevant since DIY comes with full source code now).



News 4.4(.1):
-------------

- Switched to GCC 2.95.4 (the official release). I highly recommend that you
  use this version as well.

- Fixed bug in savegames stored in automap mode (this only seemed to make a
  difference in some Boom levels, though). The problem was that the automap
  wasn't initialized after the game was loaded, so it crashed. The savegame
  as such is OK.

- Some hacks to make WADs with missing or illegal patches work anyway (as far
  as possible, e.g. Fragport).

- Moved some memory fill code into the GameSupport module. In case part
  of your background isn't cleared properly, make sure you're running the
  most recent version of the GameSupport module that comes with this
  archive.

- During startup, the maps (playable levels) in each WAD will be listed
  after a "-->" prefix. No more wondering what bloody level the PWAD maker
  used.

- Fixed a long-standing Boom bug that manifested in masked segments and
  only appeared on non-RISC OS systems so far (due to the different plotter
  structure). The textures used to wrap around at the wrong point, so the
  outline was OK, but the texture was screwed up.

- 32bit compatibility for Iyonix users. Add -DAPCS32 to MPPBASEFLAGS to build
  a binary for 32bit RISC OS, or -DAPCS26 for a 26bit binary. If neither is
  specified (the default), a binary for all architectures (including ARM3)
  will be built. The support module GameSupp should work on all RISC OS
  platforms in its current version (0.02).
  Note that _all_ assembler files are now generated out of macros, so there
  is no s directory in the archive anymore. In case the assembler files can't
  be generated by mpp, create the s directory manually and try again.
  
  There is still one problem for Iyonix users and that's the sample rate
  issue. The Iyonix drivers show some pretty strange behaviour in this
  respect, I simply can't change the sample rate like I could on older
  machines and apparently nobody knows what exactly the matter is ATM.
  I tried various workarounds, but none of them gave to desired result,
  so until either Castle fix their sound drivers or someone can tell me
  _exactly_ how to work around this bug (I'm fed up with ``trying'' all
  sorts of things), Iyonix users are stuck with a fixed sample rate. That's
  not as bad as it sounds, because you can multiply the DIY sample rate
  (base value is 11025 Hz) by integer numbers using the freq_mult resource
  in doomrc. Most Iyonix machines appear to be stuck at 22kHz, so you'll
  want freq_mult=2 for correct playback speed.

  So how does the Iyonix fare with DIY? Quite disappointing, to be frank.
  Running some heavy duty Hell Revealed timedemos (the likes of HR24-849,
  HF24-359 and HF32-314) on a SA RiscPC (202MHz), an Iyonix and an Athlon
  XP2200+ system, it turns out the Iyonix is only around twice as fast as
  the SA RiscPC, whereas the Athlon XP2200+ machine is about 9--12 times
  faster than the Iyonix (yes, that's up to _12_ times). Also note that
  RISC OS engines actually have the unfair advantage of highly optimized
  assembler parts and not having to go through X11. Like I said, rather
  disappointing. I can only assume that the lack of 2nd level cache still
  throttles the Iyonix, since there's no FP to speak of left in Doom.
  Speedups around the factor 13 (PC vs. Iyonix) can also be observed in
  the CBM emulator Vice, BTW. To give you a general idea, here are demo
  timings taken with 32bpp engines at 320*240:
  
  Demo        Engine    RPC     Iyonix    PC/icc   PC/gcc

  HR24-849    32t       71231   33970     2794     2955
  (19008)     32rt      80620   36330     3832     4431
  
  HF24-359    32t       39264   n.a.      1455     1533
  (8647)      32rt      44721   24594     2070     2380
  
  HF32-314    32t       32335   n.a.      1185     1242
  (6853)      32rt      39256   n.a.      1852     2164
  
  Legend: RPC is my SA RiscPC (202MHz, 66MB, GCC), Iyonix is Stefan Bellon's
  Iyonix (600MHz, 512MB, GCC) and PC is my Linux PC (Athlon XP2200+, 512MB,
  using gcc or icc (the Intel compiler)). Machine timings come in pairs where
  the first one is for a regular engine (32t) and the second one is a fully
  resampling one (32rt). Values given are Doom tics (realtime = 35/s), the
  realtime tics for each demo are in parantheses below the Demo name. The
  demos can all be downloaded from TAS (see http://www.doomworld.com/tas)
  in case you want to verify the timings.
  
- I finally got around to doing _bi_linear resampling for things and masked
  segments as well, so the odd striped look of resampled sprites is a thing
  of the past, provided you also define -DDIYRESAMPLETHINGS (in addition to
  the regular -DDIYRESAMPLE switch). Looks phantastic, in particular the
  Archvile fire; needs some additional memory and processing power, though,
  but not too bad in either respect. Some demos actually appear to run ever
  so slightly faster, don't ask me how _that_ happened...

- I finally restructured my compression code into a separate library called
  fastlz (since it's a fast LZ77-based approach; fast for decompression, no
  LZ77 is actually fast for compression ;-) ). The main motivation for this
  was to eliminate the code duplication with armDeu and possibly add compression
  to DIY at some future point (for instance savegame compression). This library
  is part of the DIY release and is located in the subdirectory fastlz. It
  should be built automatically with the engine, but in case you're having
  problems due to a missing fastlz library, this is where you should look.
  If you have a newer GCC release, you'll have to replace ``makealf -o'' by
  ``libfile -C'' in the fastlz Makefile and use ``make -C fastlz'' rather than
  ``make -c fastlz'' in the top-level Makefile.

- I hadn't used the Linux version much so far and there were various issues
  with it (superfluous sleep() in vsync, sucky synchronous sound etc.).
  This is now fixed and the Linux engine really rocks in its current form.
  DIY with full resampling at 800*500, absolutely smooth on my Athlon XP2200+,
  drool... I don't think I'll be using the RISC OS version much from now on.

- Remaining on Linux, I added support for fullscreen mode using the vidmode
  extension (I hope I didn't pick an exotic extension, but AFAICS it's a
  pretty widespread one). It's enabled if the source is compiled with the
  macro VIDMODE_FULLSCREEN defined, which is the default for Linux targets.
  The engine will still run in the regular desktop unless you start it with
  the switch ``-fullscreen'', however. The engine will choose the closest
  resolution to the one the engine is using and center the display within
  the screen.

- Note that DIY will still run on old machines (just tested it again on my
  A5000 after a long time and it still works). So everything from
  Archimedes to Iyonix is covered right now (in blood ;-) ). Just remember
  that you have to disable dynamic areas on older machines by passing the
  switch -nodynarea to the engine (if you're using my frontend, you should
  enter this switch under ``Additional''.

- In case you're experiencing problems with the default Makefile, there is
  an alternative one by Peter Naulls in the contrib subdirectory. I will
  not support this Makefile, however, since I have a deep aversion against
  Unix filename translations in Makefiles. In case you have such a make
  utility, you may also be able to use the original Makefile after adding
  ``m'' and the object dirs you want to use (see the ODIR* variables in the
  Makefile) to UnixEnv$make$sfix. In case you get errors from the assembler,
  you could try replacing AS with gcc and ASFLAGS with -c in the Makefile.
  Unfortunately, my version of GCC doesn't support this, but newer versions
  require it.




News 4.4.2:
-----------

- RISC OS:
  * Fixed screenshot bugs:
    a) when running without frame buffers
    b) when in 8bpp mode
  * Fixed bug when running in very large screen modes (where there is only
    enough screen memory for one frame). Make sure you use the new GameSupp
    module supplied with this archive (same size as the old one, but different
    code!)
  (note that the Makefile hasn't changed since 4.4.1, so you can continue
  using that one if you had to make modifications).

- Linux:
  * musserv patch by Darren Salt which allows you to use a Doom music server
    as in LxDoom, Edge and some other engines. Add something like
    -DMUSSERV=\"/usr/games/musserv\" to your compiler flags to enable it.
    Please direct further question to Darren.
  * fullscreen patch by Darren Salt (the window wasn't positioned correctly
    on his system when the mouse wasn't grabbed).
  * Fixed mouse support under X (was rather dodgy, should now work OK). You
    must add -grabmouse to the command line (only useful in fullscreen mode
    IMHO).
  * optional code for screenshots in PNG format. You must compile the engine
    with HAVE_LIBPNG defined and add the necessary includes and link flags.
    This code is enabled by default for Linux targets.

- All:
  Screenshots are made by pressing the ``Print Screen'' key. RISC OS saves
  the screen as a sprite in Doom:Snapshots.sprite##; Unix engines need PNG
  support enabled for this and save as screenshot##.png
    




Andreas Dehmel, 6 Apr 2003




	Pernicious flow, redemptive perpetuity
	Unholy drive, the gods' arrogant grin
	If my world's a joke, do you see them smile?
	Hellbound me -- on a throne of gold
	
	Wastelands prey on dying cattle
	Desert sucks on poor man's thirst
	Glimpse of glory, walk ahead
	Slaves of Nazareth can not be fed
	
	Black Lava, drifting down the mountainside
	Black Lava, you can't fight

		Satyricon - Black Lava
