home *** CD-ROM | disk | FTP | other *** search
/ DOOM Mania!!! / DoomMania.bin / doompk / die012 / die.doc < prev    next >
Text File  |  1994-04-02  |  10KB  |  224 lines
  1. /*********************** Doom Image Editor v1.2 ****************************/
  2. -Disclaimer:
  3.      By reading this file DIE.DOC and/or installing it, you hereby 
  4.      acknowledge you the reader are wholly responsible in every way 
  5.      shape or form for any effects the user (you) incur.  I have made
  6.      every reasonable effort to insure DIE executes correctly.
  7.  
  8. -DIE is FREEWARE.  
  9.      Use it, distribute it, upload it,
  10.      but don't exploit it.  Don't act like it's yours and make others
  11.      pay a fee (dollars) for you giving it to them.  That is not cool.
  12.      I released this as FREEWARE, and it shall stay that way.  If you 
  13.      think you need to have someone pay for you to sit on your butt
  14.      and copy it to diskette...that's bull.  However, if you need to milk
  15.      .50 cents out of 'em for a diskette, I suppose that makes sense.
  16.  
  17. -Updates for DIE v1.1:
  18.      - added mouse speed settings to die.cfg.
  19.      - added check for mouse on startup.
  20.      - added visual for image load\save status.
  21.      - the executable is now named DIE.EXE (no more version numbers to type).
  22.  
  23. -Updates for DIE v1.2:
  24.      - increased size of static image memory 
  25.      - added a more solid check for non compatible image format: 
  26.           You may notice some of the images you edited before, you may
  27.           not be able to edit now.  This is because some of the images
  28.           were not recognized as incompatible with DIE's current abilities.
  29.      - added a more solid pixel read/write algorithm 
  30.      - including a front end for DIE in the DIE package
  31.      - !!!! bitchin !!!!!!
  32.           You can use the -file param with doom to load .DIE files.
  33.           If you are afraid of fraggin-up your .WAD file, use the 
  34.           -file param when you run doom so you can test the new creation
  35.           out first before making the import with WT.
  36.  
  37.                     DOOM -file sky1.die
  38.  
  39. -What it is:
  40.      DIE (Doom Image Editor) is a utility for the seemingly endless 
  41.      tools for the DOOM wad.  
  42.      (The game DOOM ain't gonna die out for a looonnggg time.)
  43.  
  44.      You can Export an Image from WADTOOLS (c) Jeff Miller 1994, and
  45.      Import it to DIE.  Then you can paint all over it, Import it back
  46.      to WADTOOLS, and Shazam.  Custom walls.  You can also use the -file
  47.      param (as mentioned above) to test out the new image.
  48.  
  49.      !!! DO NOT EXPORT THE IMAGE TO A .LBM FILE. !! 
  50.      DIE only works with raw DOOM.WAD data.
  51.  
  52.      If you have the Shareware Version <sigh> (still..). Register DOOM.
  53.      DIE will not work with the Shareware version in keeping with
  54.      ID software's request to limit hacks to the registered version.
  55.  
  56.      At this point, DIE is a point and grunt paint program.  You are
  57.      limited to pixel by pixel painting.  If you wanna gripe, go ahead.  
  58.      Be glad all these DOOM hackers are keeping you griper leeches 
  59.      satisfied !
  60.  
  61. -How to use it:
  62.      (where this file notes < > for explaining configuration info, do not 
  63.       include the "< >".  They are used only for illustration.)
  64.  
  65.      There should be five files in the DIE012.ZIP package:
  66.           DIEFE .EXE - Front end to make typing less of a hassle.
  67.           DIEFE .DOC - Doc for Die's Front End.
  68.           DIE   .EXE - Doom Image Editor.
  69.           DIE   .DOC - What you is reading.
  70.           DIE   .DAC - Image of the DAC registers.
  71.           DIE   .CFG - DIE'S configuration file.
  72.  
  73.      Bark up your favorite text editor, and change (in DIE.CFG) the line:
  74.  
  75.           doomdir <path_to_wadfile\wadname>
  76.  
  77.      to be set to the path of your DOOM.WAD file with the name of your
  78.      main DOOM.WAD tacked to the end.  (doomdir c:\doom\doom.wad).
  79.      
  80.      I did this so you can have a separate directory for DIE, other than
  81.      your DOOM directory.  (Mine is soooooooo full of stuff.....).
  82.  
  83.      Also, set the desired mouse speed at the line:
  84.  
  85.           mouse <x_speed> <y_speed> <sensitivity>
  86.  
  87.                - x, y, and sensitivity can range from 1 to 100.
  88.  
  89.      go into WADTOOLS (c) Jeff Miller 1994, and find your image to EXPORT.
  90.      give it an extension too, if you want.
  91.  
  92.      Execute DIE like this:   DIE <Image_exported>
  93.  
  94.      If I exported SKY1.DOM from WADTOOLS, (I export mine with extensions), 
  95.      I would type
  96.  
  97.           DIE SKY1.DOM
  98.  
  99.      You will then see a checking of the mouse driver, and a status of
  100.      the image loading.  (or an error message if you made a mistake).
  101.  
  102.      If the file you are loading already exists in the current directory
  103.      with the extension of .DIE, you will be asked if you want to 
  104.      continue; this means the file will be overwritten if you save it
  105.      at the end.
  106.  
  107.      You should then have the image on the screen, a "color bar", and the
  108.      mouse cursor (yes, I KNOW it's ugly in mode 13h, but it turns off
  109.      when you are drawing).
  110.  
  111.      When you grunt on a color with the right mouse button, a small box
  112.      will appear in the lower left corner of the screen in the color
  113.      you chose.  This is the current drawing color.  You may also choose
  114.      a color from the image. 
  115.  
  116.      Use the left mouse button to color a pixel, and the F1 key will
  117.      redraw the screen (if you get sloppy).
  118.  
  119.      When you hit escape, you will be prompted to save the image.  This
  120.      is done regardless.  Even if you didn't change the image.
  121.  
  122.      You will then have a file in the current directory with the .DIE
  123.      extension. This is the file to import back into WADTOOLS.
  124.  
  125.      ONE LAST THING:
  126.           I DON'T HAVE SUPPORT FOR THE ENEMY IMAGES YET.  THIS IS A DIFFERENT
  127.           PIXEL FORMAT.  DO NOT EDIT THESE.
  128.           ---(may be coming soon to a theatre near you!)
  129.  
  130. -Q&A:
  131.      -When will you have the monster editing version out ?:
  132.           - It may be out soon.  I loaded one of the boss dudes, but it
  133.             was somewhat screwed up.  I wasn't reading the pixel data 
  134.             correctly.  Me thinkest I knowest howest to do it now, but
  135.             I don't see the connection between the pointers to the data
  136.             and the actual data. (for some things).  The way it looks,
  137.             it may be a fairly slow process loading a monster image.
  138.             but, what the hell, right?  (juz-do-it).
  139.  
  140.      -Why is the damn .exe so big?
  141.           - I started out with dynamic memory, but could not get the image
  142.             written back to the dest. file correctly.  (DGROUP sucks).  
  143.             malloc() SEEMS tempermental and just pisses me off. farmalloc()
  144.             is even worse.  After many lumps on my head from banging it into
  145.             my desk, I bought some Advil and went with static (fixed) memory
  146.             (....When the swelling goes down, I'll try malloc() again).  
  147.             All this means the actuall memory for the image is 'packed-up'
  148.             inside the .exe file.  Although the actual code may be only
  149.             20k or something like that.  This also puts a severe limit on
  150.             the size of the image you can edit.
  151.  
  152.      -Some images load, and look nothing like the one in DOOM.  Why?
  153.           - There are several pixel formats in DOOM.  Some have 'header'
  154.             info, some don't.  The point is, not all of them are the same.
  155.             DIE sometimes doesn't care what you load in - it will just 
  156.             paint the image from the format it expects it to be in.  This
  157.             IS something I will have to work out, but my info on the pixel
  158.             formats is scarce, and by the looks of it, some of the info
  159.             ain't even correct.  ***This should be more solid with v1.2.
  160.  
  161.      -I save an image, but when i imported back to WT it blew up. Why?
  162.           - As mentioned above, if you get away with loading in a 'non -
  163.             compatible' image, and save it, it has been saved in a
  164.             screwy 'non-compatible' format.  This means DOOM won't know                          
  165.             what it is, and either will WT.  I can't expect end users
  166.             to telekinetically sense when an image is not compatible, so
  167.             I am trying logic with key factors of an editable image
  168.             to decern if the image is loaded or not.  This has been 
  169.             enhanced with v1.2, and may be licked. 
  170.  
  171.      -Why haven't you included your source code with DIE?
  172.           - A lot of my function calls I code in assembly.  I do this
  173.             cause scanf() sucks, and I hate getch() for getting a 
  174.             'cursor key'.  Don't get me wrong, though. Borland C is great!
  175.             They only thing they did wrong is they should've called
  176.             it Bitchin' Borland C. Anyway, the point is I won't include
  177.             the source 'cause I don't want to make the libs public stuff.
  178.             If I don't release the libs, the code won't compile/link 
  179.             correctly.  I don't want to recode the asm stuff into inline
  180.             asm right now either.  
  181.  
  182. -Wuz next:
  183.      -after messing around more, thinking about a zoom-in feature
  184.      -Couple days ago finally figured out the Monster pixel format. (I think).
  185.       Looks like a major recode in the read/write scheme.  Haven't done my
  186.       homework yet.  
  187.       (Looks like it might have to wait a couple more weeks...I'm such a bum).
  188.  
  189.  
  190. /************************* Thanks go to: ************************************/ 
  191.  
  192. Jeff Miller 
  193.      -WADTOOLS.
  194.      THANKS!
  195.      Nice program Jeff. Without your exporting, DIE
  196.      would by dead. <pun, grin, grin>
  197.  
  198. Raphael Quinet quinet@montefiore.ulg.ac.be 
  199.      -NEWDEU  
  200.      THANKS!
  201.      Another cool program.  Good luck on the roll-your-own maps,
  202.      I WILL be watching for it.
  203.  
  204. Brendon Wyber (b.wyber@csc.canterbury.ac.nz).
  205.      -DEU
  206.      THANKS!
  207.      Your program was inspiring.  I've spent many hours in front of it.
  208.      
  209. Matt Fell (matt.burnett@acebbs.com)
  210. Hank Leukart (ap641@cleveland.freenet.edu)
  211.      -DMSPECS...
  212.      THANKS!
  213.      Without your specs, I would have given up on the pixel format a long
  214.      time ago.  These were a real HELP.
  215.  
  216. AND thanks go to any one else contributing to the Great Doom Hack, 
  217. may your BFG never go limp.
  218.  
  219. ****************************************************************************/
  220.  
  221.                                                  
  222.  
  223.  
  224.