🚀 go-pugleaf

To Stephen Cyberman :
	Sorry I had to post here ... the mail I sent you bounced
	(what's your address ? Can you e-mail me ?)
	Anyway, this is a FAQ I've been working on quite some time
	ago. It hasn't been quite finished (in fact, I havent
	done almost nothing except correcting mistakes, I just
	collected a bunch of posts that are likely to be real FAQs
	but ran out of time)

Anyway, I hope this helps somebody out there, and people who
are willing to contribute are welcome to post here or can just
e-mail me.

-----------------------------------------------------------------------------
rec.games.programmer FAQ proposal - whatever works !
-----------------------------------------------------------------------------
 
Note that this is VERY unofficial. I cannot guarantee the correctness
of the contents of this post. There's bound to be lots of errors
and gaps, so I hope everybody willing to participate would fill in
the gaps & add to this doc.
I apologize for any mistakes / inaccuracy of the contents of this doc.
I hope this is going to be a long list soon.
 
 
Structure :
 
Part 0 : Terminology (what is ...?)
Part 1 : Tutorial (& tech reports --- Computer games - A Quantitative Approach
	 	   :) :)
Part 2 : Code, libraries ... - what ? where ? does anybody have ...?
	 Basically a list of files to hunt down. (Maybe we need an ftp site!)
Part 3 : everything else. Suggestions ?
	 Howabout : maze algorithms, pac man discussions,
	 hexmap generations (I still don't see what the purpose of this is),
	 game languages, collision detection, 3d object math, etc, etc.
 
 
 
 
 
 
 
 
-----------------------------------------------------------------------------
Part 0 : Terminology (Glossary ?)
-----------------------------------------------------------------------------
 
*.  .MOD files.
    Standard AMIGA music files. Contains raw digital sound data
    which represent instruments, and are sequenced & mixed while
    processed to produce musical notes.
 
*.  Bitmap.
    Representation of image in bits. Can be used as a sprite.
 
*.  Flicker.
    (1) CRT
     CRT displays refreshes the screen at a rate of at least 30 updates/sec.
     CPUs write to memory much faster than that. Consider this :
     the CPU starts clearing the screen to a red color from a blue background.
     The CRT is in the middle of a vertical trace. So the screen looks halfway
     blue. The CPU quickly changes the whole frame buffer to red. The CRT
     continues the trace, reading red colors for the remainder of the screen.
     So for a while, it looks like the screen is 'split' into blue-red
     sections, & there is a clear line that separates them, which is
     very noticeable to the human eye.
    (2) Sprite
     A sprite is put on the screen. The background is restored.
     It is put on the screen again at a different location to emulate
     movement.
     Because the background is always visible when the sprite is removed,
     the sprite just seems to appear and disappear at different locations
     rather than moving. At fast update rates, the sprite appears to be
     'transparent'. To make a sprite solid, flicker must then be eliminated.
 
*.  Frame buffer, Video memory.
    Memory that contains image data that is translated to the image
    on your screen.
 
*.  Mode X.
    IBM PC/Compatibles.
    Undocumented standard VGA mode which allows faster video I/O access
    via DAC. Term first introduced in an article by M. Abrash in
    Dr Dobb's Journal Magazine.
 
*.  Mode Y.
    IBM PC/Compatibles.
    The same as mode X, but has double vertical resolution.
 
*.  Snow.
    IBM PC/Compatibles, CGA
    Old CGAs allowed video memory access during retrace. When memory
    read/write clashed, small lines appear on display, looks like snow!
 
*.  Sprite.
    An image of something, usually animated around the screen.
    Usually represented by a generic structure containing
    width & height of the image and the contents of the image
    (colors) represented by a stream of data or a 2-dim array.
 
*.  Vertical Retrace
    CRT displays refresh at about 30 Hz minimum. (Tweaked VGAs can
    have much lower rates so that the screen flickers a lot)
    After the electron beam stops at the bottom, it goes up again.
 
*.  SB / SoundBlaster.
    IBM PC sound card. Includes an FM synthesizer & DAC/ADC for digital
    sound sampling/playback.
 
*.  VGA (Video Graphics Array).
    IBM PC standard display adapter. SVGA = super vga, extensification
    of VGA. (etc ...)
 
 
-----------------------------------------------------------------------------
Part 1 : Tutorial
-----------------------------------------------------------------------------
 
Standard animation techniques
 
1. Beginner's animation
   One of the things a beginner usually encounters is the standard
   GET and PUT routines provided by standard language compilers.
   The type of animation that can be accomplished by using these
   routines is rather limited. Old graphics books often discuss
   issues on using these GET/PUT routines which usually involve :
   a. Flicker-free animation.
      One technique for creating a flicker free object that
      can move around a screen is by doing a brute force PUT.
   b. Preserving the background.
      Brute force puts obviously ruin the background.
      Another smart technique is by first doing a XOR put
      two times, then GETting the result to be put as the image.
      As that image is put on the screen, the previously existing
      image is erased, while a new one is drawn.
      (ref. Graphics Made Easy by M. Guerra)
 
2. More advanced approaches
   As game demand grew more and more complex, programmers
   demand more and more complex animation techniques. XOR PUT
   techniques can create flicker free animation and preserve backgrounds,
   but it does not preserve the sprite image -- the images seem to
   go 'through' the background rather than over it. Furthermore,
   putting an image always makes the rectangular area in which the
   image is contained to be always visible.
 
   Problem 1: Preserving the sprite image
     - Masked Put
       One solution to the problem is to create a 'mask' for the
       image to be drawn. One rectangle is the actual image to
       be drawn on the screen. Another one is defined to specify
       wether the pixel at that location of the first image is
       to be put or not.
 
 
       ...XXX...       ...***...         XXX
       ..X.X.X..       ..*****..        X.X.X
       ..XXXXX..       ..*****..        XXXXX
       ..XXXXX..  AND  ..*****..  -->   XXXXX
       ..X   X..       ..*****..        X   X
       ..XX XX..       ..*****..        XX XX
       ...XXX...       ...***...         XXX
 
 
     - Color exception
       Another easier solution is defining a 'color' value that
       is not to be put on the screen. This is quite practical
       with the standard 256 colors - who is going to miss 1
       color out of 256 ? Doing it on 16 color systems is also
       practical, but it limits a sprite to 15 color values.
 
   Problem 2: Still preserving the background
 
     - Buffering techniques
       One way to preserve background is storing the whole background
       image. This image is each time transferred to the drawing area,
       before any sprites are put onto it. It can't be put onto the
       screen directly, because it would create full-screen flicker !
       Rather, all the images (the background, etc) are put into
       a buffer. The buffer is then transferred to the screen in one
       single memory transfer. Therefore, this eliminates flicker
       and preserves the background.
 
 
			sprite
 
			 /-\
			 \-/
 
			  |
			  |
			  v
 
	BACKGROUND      BACKGROUND      BACKGROUND
	BACKGROUND      B/-\GROUND      B/-\GROUND
	BACKGROUND      B\-/GROUND      B\-/GROUND
	BACKGROUND ---> BACKGROUND ---> BACKGROUND
	BACKGROUND      BACKGROUND      BACKGROUND
	BACKGROUND      BACKGROUND      BACKGROUND
	BACKGROUND      BACKGROUND      BACKGROUND
 
	background        buffer          screen
	  image
 
 
       Of course, there is always optimizations to everything.
       This description is just a general idea on memory buffering.
       Of course, the whole background is not always transferred to
       the buffer, only portions of it is usually transferred to
       erase smaller sprites in the buffer.
 
 
 
3. Current approaches
   Newer, more advanced graphics boards create new possibilities for
   creating faster animation, but they also pose more problems.
   Current issues include :
 
     - Double buffering implementations
 
     - etc
 
4. Common problems
 
     - Scrolling background
 
     - Collision detection
 
     - Bitmap scaling
 
     - Bitmap perspective, stretching.
 
     - 3D object manipulations
 
     - Text Parsing, Natural language processing
 
 
(fill 'em out!)
 
 
 
 
 
 
 
-----------------------------------------------------------------------------
Part 2 : Libraries, Code, etc.. The WWWW
-----------------------------------------------------------------------------
 
(*)  library    = set/collection of routines
(**) executable = executable binaries
 
Hopefully the many errors/incompleteness can be corrected,
especially the 'I forgot' phrases.
 
AMIGA : Yet to be filled
 
ATARI : Yet to be filled
 
IBM PC :
 
 --------
 Graphics
 --------
 
*.  Executable
    File(s) : TWEAK06.ZIP
    Who     : Robert Schmidt (robert@solan.unit.no)
    When    : 1992
    What    : A program to experiment w/ VGA registers, very useful
	      if you want to define new modes (like mode X & 360x400 modes)
    Where   : simtel & mirrors
 
*.  Executable, (source code)
    File    : SPRITE.ZIP
    Who     : Billy Dalrymple
    When    : 1989
    What    : A sprite editor, produces sprites w/ mask in files.
	      info available for $10
	      source code available for $25
    Where   : I forgot
 
*.  Executable, Source Code
    File(s) : VGA.ZIP
    Who     : wardt@a.cs.okstate.edu
    When    : 1992
    What    : A sprite editor, includes full source (.ASM & .C)
    Where   : I forgot
 
*.  Source Code, Library
    File(s) : DDJ****.ZIP, XSHARP**.ZIP
    Who     : M. Abrash
    When    : Aug-Dec 1991, Jun-Aug 1992
    What    : Mode X introduction. Sources to do animation,
	      polygon plotting, anti-aliasing, etc, on Mode X.
    Where   : SIMTEL and mirrors, 
	      ftp.mv.com (Official DDJ site) in pub/ddj
 
*.  Source Code
    File(s) : article 7198 of rec.games.programmer
    Who     : Frederick J. Haab (otto@nevada.edu)
    When    : 26 Jun 92 00:17:52 GMT
    What    : Scrolling in mode 13h, C program
    Where   : USENET archives
 
*.  Source Code
    File(s) : article 7716 of rec.games.programmer
    Who     : Joshua C. Jensen (sl8nl@cc.usu.edu)
    When    : 30 Jul 92 00:02:36 GMT
    What    : Bitmap manipulation (scaling + perspective), Turbo Pascal
	      source w/ inline assembly.
    Where   : USENET archives
 
*.  Source Code
    File(s) : VESAVGA.ZIP
    Who     : Randy Buckland
    When    : 6/18/92
    What    : .ASM & .C source to provide fast routines for VESA VGA modes.
    Where   : garbo
 
*.  Sprite Library, Code
    File(s) : STK110.LZH
    Who     : Jari Karjala
    When    : 1991 (v 1.1)
    What    : Sprite library & toolkit for Hi-Res EGA, BW
	      includes C source, demo & good docs.
    Where   : simtel & mirrors
 
*.  Sprite Library, Source Code
    File    : SPRITES.ZIP
    Who     : Marius Kjeldahl
    When    : 1991
    What    : Sprite library for VGA mode $13
	      includes TPU, .PAS source.
	      (shareware, $69 ?)
    Where   : garbo

*.  Sprite Library, Toolkit
    File(s) : WGT_SPR2.ZIP, WGT_TC21.ZIP, WGT_TP2.ZIP
    Who     :
    When    : 1992
    What    : Shareware Sprite toolkit for VGA mode $13
              includes TPU (WGT_TP2.ZIP), example programs for usage
	      Nag-shareware program
    Where   : wuarchive, if somebody hasn't erased it yet
 
*.  I'm sure theres TONS more, but I can't search for all of them.
    Any corrections / additions is great.
 
 -------------
 Sound & Music
 -------------
 
*.  Documentation
    File(s) : Article 6077 of rec.games.programmer
    Who     : Jeffrey S. Lee (jlee@smylex.uucp)
    When    : 25 Feb 92 15:02:02 GMT
    What    : Programming the AdLib/Sound Blaster FM Music Chips
    Where   : usenet archives, also at the SB project site
	      (tybalt.cco.caltech.edu), & SB mailserver
	      (listserv@porter.geo.brown.edu)
 
*.  Executable, Runtime Library
    File(s) : MODTECH.ZIP
    Who     : Mark J. Cox (M.J.H.Cox@bradford.ac.uk)
    When    : 1991
    What    : TSR Library to play .MOD files in the background
	      Supports PC Speaker, SB, DisneySS, LPT DACs, etc
    Where   : ftp.brad.ac.uk in /misc/msdos/mp

*.  Library
    File(s) : MODOBJ.ZIP
    Who     : Mark J. Cox (M.J.H.Cox@bradford.ac.uk)
    When    : 1992
    What    : .OBJ file w/ routines to play .MOD files in the background
	      Supports PC Speaker, SB, DisneySS, LPT DACs, etc
	      Includes examples in TC & TP
	      (shareware, $30)
    Where   : ftp.brad.ac.uk in /misc/msdos/mp
 
*.  Source code
    File(s) : NH10SRC.ZIP
    Who     :
    When    :
    What    : Eliminate noise on sound samples, incl. .C source
    Where   : SB project site & mailserv site
 
*.  Source code, Executable
    File(s) : SB_OSC.ZIP
    Who     :
    When    :
    What    : SB input scope / oscillator. Incl. .ASM source
    Where   : SB project site & mailserv site
 
*.  Source code, Executable
    File(s) : SBDAC.ZIP
    Who     : Jeff Bird (cejjb@marlin.jcu.edu.au)
    When    : 12 Feb 92
    What    : SB DAC programming using DMA. Incl. .ASM & .C source
    Where   : I forgot (probably on SB project sites too)
 
*.  There's LOTS more, I haven't the time to data all of them, but much
    are at the SB site (tybalt) and files can be requested to the
    mailserver at listserv@port.geo.brown.edu, include the string
    HELP or INFO on how to get the files.
 
 
MACINTOSH : Yet to be filled.
 
Microsoft Window Systems : Yet to be filled.
 
Sun/SPARCs :
 
 --------
 Graphics
 --------
*.  Library
    What    : Standard PIXRECT library
	      Bitmap manipulation routines for frame buffer.
 
 -------------
 Music & Audio
 -------------
*.  Source code
    File(s) : tracker.tar.Z
    Who     :
    When    :
    What    : .MOD file player through the audio device. Works on SPARCS
	      w/ audio devices.
    Where   :
 
*.  Source code
    File(s) : csound.tar.Z
    What    : FFT & signal processor
 
*.  Source code
    What    : MixView
 
 
X Window Systems : Yet to be filled.
 

--------------------------------------------------
Thanks to the following people who replied to me :
--------------------------------------------------

Mark. J. Cox		M.J.H.Cox@bradford.ac.uk
			rahmanqi@brise.ERE.UMontreal.CA
Joshua C. Jensen	SL8NL@CC.USU.EDU
Marko Mikkola		MMIKKOLA@tnclus.tele.nokia.fi

-- there could be much more, but I didn't have the time to dig
   up my old mail. I revised this for posting.


New releases I haven't included yet :
	HOBOBJ.ZIP, HOBSRC.ZIP (Hobbes Mode-X Graphics Library)
	(was on comp.binaries.ibm.pc)

	XBLT02.ZIP - same author as XLIB**, fast sprite blits w/ source on 386.
	was on wuarchive.

	XLIB03.ZIP, XLIB02.COM, XLIB01.COM - the new mode X graphics
	library (posted on rec.games.programmer, & was on wuarchive)

	SKYLAND.ZIP - a text adventure game library, haven't tried it yet
	was on wuarchive.

	PPS110.LZH - newer version of ProTracker source
	was on wuarchive.

	SCROLDEM.ZIP - was a scrolling demo back from wuarchive