home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / programs / games / diyupdate3 / UpdateM2 < prev    next >
Encoding:
Text File  |  1998-04-23  |  9.0 KB  |  210 lines
  1. WELCOME TO THE SECOND MAJOR UPDATE FOR DOOM IT YOURSELF
  2. =======================================================
  3.  
  4.  
  5.  
  6.  
  7. Don't forget to delete the directories NewDiffs and NewFull the first major
  8. update created in your DoomItYs directory before you merge this major update
  9. with your DoomItYs directory (if you updated; this second major update is not
  10. based on the first one but replaces it, as discussed in the file UpdateM1).
  11. Make sure you read UpdateM1 first because this file only contains the news
  12. since major update #1.
  13.  
  14.  
  15.  
  16.  
  17.  
  18. ************
  19. *** NEWS ***
  20. ************
  21.  
  22.  
  23. - 16 AND 32 bpp VERSIONS:
  24.   =======================
  25.  
  26.   I started with 16bpp because I can use that on my A5000 (thanks to the Colour
  27.   Card). The modifications necessary to make 16bpp run could all be used for 32bpp
  28.   (except for the assembler bits), so 32bpp was almost ``free''...
  29.   The base type for frame buffers is no longer byte but pixel_t. You have to
  30.   select the colour depth you wish to compile DIY for in h.doomdef by setting
  31.   the value of LD_PIXEL_DEPTH to 3 (8bpp), 4 (16bpp) or 5 (32bpp). Additionally
  32.   you have to specify the correct target when making the whole thing: !RunImage
  33.   for 8bpp, !RunImageH (high colour) for 16bpp and !RunImageT (true colour) for
  34.   32bpp. You shouldn't be able to link the wrong target, but better not try it.
  35.   So, to build 16bpp Doom set LD_PIXEL_DEPTH to 4 and type ``make -r !RunImageH''.
  36.   Basically I could have made the whole thing only depend upon the target but
  37.   that'd make it much too easy to mix object files compiled for different colour
  38.   depths with catastrophic consequences.
  39.  
  40.   Lighting: of course, since all data in the WADs is 8bpp higher colour depths
  41.   can only make a difference as far as lighting is concerned. The array
  42.   lightmultipliers in c.i_video contains a 16.16 fixpoint number for each of the
  43.   32 lighting-colormaps, giving the brightness this colourmap should have compared
  44.   to the brightest one. There are two principal ways to handle this: either you
  45.   analyse the actual 8bpp colourmaps to get the average brightness level of each
  46.   colourmap, or you use a simple, linearily decreasing model. In the latter case
  47.   you have to fiddle with the minimum level a lot to get a good result. Determining
  48.   the average relative brightness of the darkest 8bpp colourmap and linearily
  49.   interpolating in between is absolutely no good. After trying both ways I decided
  50.   that a linearily decreasing approach with a minimum relative brightness of 0x2000
  51.   (= 0.125) looks best. How lighting is handled is determined by the variable
  52.   LINEAR_COLOURMAP_LIGHT in c.i_video . If it is defined it has to be set to the
  53.   relative brightness of the darkest colourmap (fixpoint number!). Decrease the value
  54.   to make dark things darker and increase the value to make dark things lighter.
  55.   Comment out the definition to use the first alternative of calculating the average
  56.   relative brightness of each 8bpp colourmap. BTW, I can only speak for 16bpp in that
  57.   respect, maybe you have to tweak the values a little for 32bpp.
  58.  
  59.   Another thing that's different in 16 and 32bpp modes is that Fuzz is now actually
  60.   a real shadow rather than the cheap imitation Fuzz was in 8bpp. Oh yeah, and the
  61.   number of lightlevels has been upped from 16 to 32.
  62.  
  63.   The difference between 8bpp and 16bpp is pretty small most of the time in the
  64.   original Doom. Doom2, OTOH, is an entirely new game that way.
  65.   As far as speed goes 16bpp can at times (simple scenes) be faster even than 8bpp,
  66.   because I rewrote it to plot 2 columns in parallel whenever possible (within
  67.   reasonable scope). It will definitely be slower when there are lots of masked
  68.   textures or lots of jagged edges. Also it appears in 16bpp you can get missing
  69.   columns in very complex scenes, probably a side-effect of double-column plotting.
  70.   ATM I have no idea how that's possible but maybe I'll get to the bottom of it
  71.   eventually (not that I'm planning to look too hard, though). 32bpp should be
  72.   almost as fast as 8bpp on non-SA RiscPCs but is probably considerably slower on
  73.   SA ones due to its measly bus bandwidth.
  74.  
  75.   !SetMode was updated to handle different colour depths. There are two new switches,
  76.   -high (16bpp) and -true (32bpp). On RiscPCs these switches also set up the correct
  77.   screen mode whereas on old machines you still have to use the mode number for that,
  78.   of course. On any machine the variable Doom$Executable will contain the name of
  79.   the correct executable for that colour depth after !SetMode has finished.
  80.   NOTE for ColourCard users: CCModeDes seems to have tremendous trouble setting up
  81.   the VDU information for modes; wrong number of palette entries is a known problem,
  82.   but I found out it also codes the _depth_ wrong!!! So after you built a 16bpp mode
  83.   you have to set the variable log2bpp (number 9) to 4 (look for the sequence
  84.   &00000009 &00000003 around offset &110 and replace the 3 with 4).
  85.  
  86.  
  87. - MISC:
  88.   =====
  89.  
  90.   1) I rearranged some stuff in c.r_segs which should make it faster especially in
  91.      complex scenes by avoiding the division whenever possible. I also tried floating
  92.      point division on my A5000/FPA but it didn't make any noticable difference in
  93.      speed -- just in case you're wondering what the ``USE_FLOATING_POINT'' in c.r_segs
  94.      is all about...
  95.  
  96.   2) Don't abort when lumps aren't found but replace them with a default lump (0).
  97.      This is kind of crude but it's necessary in some Eternal III levels, for instance.
  98.  
  99.   3) f_wipe now uses frame buffers whenever possible instead of statically allocated
  100.      screens[2] and screens[3]. That saves you the memory for 2 screens if you're
  101.      running with 3 framebuffers and for 1 screen if you're running with 2 framebuffers.
  102.      Should be handy especially in high colour depths or resolutions.
  103.  
  104.   4) Games can now always be saved, no matter what size they are, I completely
  105.      rearranged that part of the code (actually it was a necessity after (3) ).
  106.      I tested it with some really big savegames (StarWars, each around 190k) and
  107.      they all worked fine so I'd say I didn't mess up in the process.
  108.  
  109.   5) Break key (un)pauses the game.
  110.  
  111.   6) Print key saves the currently displayed screen as a sprite to the directory
  112.      Doom:Snapshots . So make sure you created this directory if you want to make
  113.      snapshots of the game. Sprites are saved under the name sprite## where ## is
  114.      a two-digit decimal number. Thus a maximum of 100 snapshots is possible. After
  115.      that... well, just weed out the old ones, OK?
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123. ****************
  124. *** Bugfixes ***
  125. ****************
  126.  
  127. - Fixed Doom 2 startup message (bug was introduced when I changed the whole text
  128.   handling for DeHackEd).
  129.  
  130. - Fixed idclev bug in Doom 2 and made sure no key creates more than 1 event
  131.   (this was basically only a problem when using cheats, especially with idclev).
  132.  
  133. - Fixed R_PrecacheLevel. Now it doesn't cache if the Z_Zone's too small anyway.
  134.   That means that if your Z_Zone is too small for the level it will start up a lot
  135.   faster than before but you'll probably have lots of disc activity towards the
  136.   beginning. But that's still better than trying to cache a 10MB level in a 4MB
  137.   Z_Zone chunk which only results in swapping most of the cached stuff right out
  138.   again.
  139.   I also introduced rangechecks to avoid bugs in WADs completely bombing out your
  140.   machine. This proved absolutely vital when I played around with Eternal III
  141.   (which, BTW is also a good argument _against_ pre-cacheing with some levels in
  142.   the 10MB area). Try any Eternal III level but the first one without the range-
  143.   checks (i.e. DIY versions before this update) and the only thing that can help
  144.   you is the reset key. Very nasty bug indeed (luckily not mine ;-) ).
  145.  
  146. - Fixed bug that made Doom crash in F_BunnyScroll (end of E3E8, after you
  147.   killed the Spider Mastermind) in higher resolution modes. Sorry, I don't
  148.   normally _play_ in higher resolutions 'cause my machine is really old, so I
  149.   didn't notice before.
  150.  
  151. - Fixed position of ``New game'' string.
  152.  
  153. - The ENOENT-undefined symbol error when compiling c.dehacked shouldn't appear
  154.   with any version of the SharedCLib anymore.
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162. LICENSE:
  163. --------
  164.  
  165. This license only applies to "Doom It Yourself". For the original Doom
  166. sources see DOOMLIC.TXT in the doom.zip archive.
  167.  
  168. This release is Freeware. You may copy it freely as long as NO PART OF
  169. IT IS CHANGED and there's no commercial interest. You are not allowed to
  170. spread modified versions; if you want changes to be included in the official
  171. release submit them to me.
  172. This release comes with NO WARRANTY. I will not be held responsible for
  173. any kind of problems resulting from the use of this program, be it data
  174. loss, computer crashes, sleepless nights or running amuck with a chainsaw.
  175. Use it entirely at your own risk.
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184. Andreas Dehmel, 22 Apr 98.
  185.  
  186.  
  187.  
  188.  
  189. Contact:
  190. --------
  191.  
  192.     Andreas Dehmel
  193.     Am Schorn 18
  194.     82327 Tutzing
  195.     Germany
  196.     dehmel@forwiss.tu-muenchen.de
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.     I am the beast in passionate pain
  204.     I am the grim being of the highlands
  205.     Of the other side...
  206.     I am winter when you freeze
  207.     I am the hammer and you are the anvil
  208.  
  209.         (Satyricon - Immortality Passion)
  210.