Newsgroups: comp.sys.ibm.pc.soundcard
Subject: THE README FILE (FRING11.lZH)
From: nunn@it.ntu.edu.au (JsNO  BAR---NUNN)
Date: 23 Dec 92 11:25:01 +0900
Reply-To: nunn@it.ntu.edu.au
Distribution: world
Organization: Information Technology, Northern Territory University


                        READ.ME FILE
           FRINDGUS (An incomplete game) (14/11/92)
           ----------------------------------------
             By Jason Nunn (JsNO BAR----NUNN)
                 nunn@pandanus.cs.ntu.edu.au

    (Note: This is a quick "slap-up" documentation, I'll do
           a better job later.....but for now)


                        A VGA GAME
                        ----------

 Hello,


I started this game "FringDus" a couple of months ago. Due
to the fact that I've completed my degree (hence unemployed),
I have to find a job. I'm also nackered after my computing
project which clocked up 25000 lines of Pascal code in 10
weeks and MONTANUS is still isn't finished!.

  Basically I'm getting too old for this sort of stuff,
and now giving it to someone else; the idea's and concepts
to write a game. Another reason why I'm "throwing it in",
is because I have absolutely NO artistic talent what's
so ever!. When it comes to programming, I'm good, but when it
comes to designing graphics- I'm absolutely shithouse.

All code is totally freeware. YOU CAN DIRECTLY USE THIS CODE
IN GAMES ETC.


                          LEGALS
                          ------

 - I do not take any responibility of any hardware/software
loss or any other loss that is the direct/indirect consequence
of seeing/using this code/executables.

(To my knowledge, this code is completely safe. The only
reason I'm giving this warning it because everybody else
does!.)

- You may freely use is code. You may use it directly in your
source, even if you make Millions of Dollars on a game you made
using this code. It only took me a night to write the basic code
so it's no skin off my nose (I took me alot longer to design the
graphics though!).


                        DISTRIBUTION
                        ------------

This distribution comes with:

   fringdus.pas   <game source>
   pic_make.pas   <sprite maker source>
   map_mak2.pas   <map maker source for editing the FRING1.MAP file>
   pack.pas       <transforms *.PIC (sprite graphics) to
                   the FRINGPC1.PIC file>

   fringdus.exe   <the excutables>
   pic_make.exe
   mak_mak2.exe
   pack.exe
   pack.ini       <the pic list that pack reads to dtermine which
                   pic files to append to "fringpc1.pic">

   flr1.pic thru to-
   flr32.pic      <the individual sprites>

   b_scr.bmp      <The base screen file (in windows format)>

   bs.bat         <Boot scrap compiling sequence, with the relevent
                   flags etc>


              Very Techical Notes & Discussion Notes
              --------------------------------------

FRINGDUS.PAS:
-------------

Have you ever heard of Paradroid?. It was a game I used
to play on a friends C-64 a long time ago (1987). I reckon
it was the best game ever written. Fringdus has the same
scrolling effect of the graphics as Paradroid. It looks really
good!, I'm really impressed with what I have done. As you operate
the key-pad keys, it looks like the "ground floor" is moving
under you. It looks very smooth, but still needs some
modifications so that it is faster. The computing solutions are
the first solvable solutions, not the best ones.

Basically, the code that resides in the Pascal source:
"FringDus.pas" is like a Database Manager. It manages a
2 entity 1-N relational database. The ERD (Entity
Relationship Diagram) is below:



                         ^
----------------        / \        ---------------
|              |   1   /   \   N   |             |
| FRINGPC1.PIC |------/ HAS \----->| FRING1.MAP  |
|              |      \     /      |             |
----------------       \   /       ---------------
                        \ /
                         .


It copies blocks of graphics contained of the "FRINGPC1.PAS"
(FRINGdus PiCture 1) file (which is stored in memory), according
to what the "FRING1.MAP" tells it (also stored in memory). The
"FRING1.MAP" file is really the "map of the floor", which only
contains position references to the blocks of graphics in the
"FRINGPC1.PAS" file.

(Note/ From now on, we'll call the blocks of graphics: "Sprites"-
from my good old C-64 days :) ).

When "Fringdus.exe" is executed, the computer reads a
section of the "FRING1.MAP", It reads the relative locations
of the sprites in the "fringpc1.pic file. It then reads the
sprite and then copies it the video memory located at decimal
address 40960 (A000h). The screen dimensions for Fringdus are:
320*200 pixels (or 64K of memory).

(Note that this for VGA only. You will have to make the relevent
changes to the code to turn it in to a EGA or CGA game.)

Fringdus provides a quick assembly base to copy chucks of data
to the video (invisible) memory. As you will see, many of these
assembly routines are tailor made for certain situtions.
The problem is with graphic libraries is that they are standardised.
The problem with standardised anythings, is that they compensate
for any kind of situation (philosophically speaking). Hence they are
slow. If you want speed, you need to custom make routines for only
certain situtions in assembly. Disassembled 3GL's like Pascal are
very Stack intensive. There is alot of overhead in preparing values
for the registers. Analagously, they "have a few drinks, watch a
few porn's, have a couple of games of pool, then go to sleep" before
they do they they useful. With assembly, you can "contain" the
processing, within the action registers AX, DX, CX, BX, so that
processing is very fast.

These routines are in no way efficient. I don't consider myself an
assembly expert. An assembly expert will look at these routines and
speed them up by 5 times, because they know what intructions are fast
and what instructions are slow. A lot can be said about Assembly
experts, but we won't go in to that now.


NB/  A detailed look at how they work, is in the source documentation.
If your still having problems with how they work, write me. I haven't
documented them properly, but will. Remember!, I might be documenting
for a living, so please remember that cooks don't like cooking when
they get home :).


  The sprites are 30 pixels by 30 pixels, as follows:


                        (NOT TO SCALE)


                             30 X
                -------------------------------
                |    o        o       o       |
             3  |   o o      o o     o o      |
             0  |    o        o       o       |
                |    o        o       o       |
             X  | oooooooooooooooooooooooooo  |
                |    o        o       o       |
                |    o        o       o       |
                |    o        o       o       |
                |   o o      o o     o o      |
                |  o   o    o   o   o   o     |
                | o     o  o     o o     o    |
                -------------------------------



Each pixel (due to being VGA) consists of 1 byte to define it.
As said before, these will get copied to the memory block:
40,960-106,495 (320*200 256 colour). These sprites are 900 bytes
in length. I don't know why I chose 30x30. It looked a pretty
optimal matrix. As you move smaller blocks, you get a high CPU
load but the less blocks you have to store, the more diversifable
grpahics you have because you can make more graphics with smaller 
blocks. As you move bigger blocks, copying becomes more efficient, 
BUT you need alot of memory to have a diversifed array of graphics.


Fringdus reads the fring1.map (now in memmory), to determine what
sprites to copy. It looks simliar to this:



                    (AGAIN, NOT TO SCALE)


                        100 X
            --------------------------------------
           |   shhhhu                             |
         1 |   d    d       aaaaau                |
         0 |   d    d            d                |
         0 |   d    d            d                |
           |   d    d            d                |
         X |   hffffl            d                |
           |                     d                |
           |                     d                |
           |                     d                |
           |                     d                |
            --------------------------------------


It is a 100x100 bytes. Each byte presents a sprite. As you may be
wondering, this is a huge area. In real terms it is 3000*3000 pixels.
Again, each byte contains a reference to a given sprite in the
"fringpc1.pic" file. For example, if the value of a given
position in the above map was say "4" (the 5th sprite), then
the position of the fifth sprite would be at offset 4 * 900 =
3600...simple. It would go to postion 3600, copy 900 bytes
from that offset, and then paste it to the screen (in a simple
sense).


  35 sprites are copied on the screen to define the floor surface,
starting at coorinates (50,30). It look as follows:


                    (NOT TO SCALE)


                -----------------------
                |   /- starts at 50,30|
                |   |                 |
                |   x x x x x x x x   |
                |                     |
                |   x x x x x x x x   |
                |                     |
                |   x x x x x x x x   |
                |                     |
                |   x x x x x x x x   |
                |                     |
                |   x x x x x x x x   |
                |     ^ sprites       |
                -----------------------


If the sprites are not at their discrete postions, they will be
scrolled. The assembly algo's, cut the border sprites so that
they don't leak out from the painting area (this unfortunatly,
takes up alot of O/H).

The key-pad keys, change the value of a marginal dx & dy values
that change the value of the real x & y values. These values
determine what sprites to copy when compared with the map file
(fring1.map). For example, if real x and real y were 244 and
345 respectively then fringdus will refer to the map file at
postions:

  x: (244 / 30)  thruto   (244 / 30) + 7

  y: (345 / 30)  thruto   (345 / 30) + 5

When "mod"'ed (eg X mod 30, Y mod 30), they determine the degree
of scroll from the offset discrete position of a given sprite.


  The operation keys are as follows:


                   home    pgup
                     \  |  /

                    -       -    (key pad)

                    /   |  \
                   end     pgdn


PIC_MAKE.PAS:
-------------

I had to make my own sprite graphics program to make the sprites.
The code is obvious, therefore I'm only going to briefly explain
it here.

This program makes a 30x30 256 colour sprite that PACK.EXE will
pack into "fringpc1.pic".

To execute this utility type in:
 

Command: PIC_MAKE <sprite file>


NB/ You don't have to have the PIC extension, it can be anything you
like.)


  The operation keys are:

                        |

                    -       -    (key pad)

                        |

  Enter Key: To write a pixel in the sprite the selected colour.

  -: GO up one colour
  +: Go down one colour

  /: Go up 10 colours
  *: Go down 10 colours.

  `: Fload full sprite with colour

  Esc: Exit (Abend)

  s: save present sprite
  f: flip sprite and save (flips vertically)
  t: turn sprite and save (flips horzontally)


Once you have composed something, then you ever hit 's' for save or
'f' or 't' to save. Once saved, then you hit 'Esc' to exit.

The reason for the 'f' and 't', is that it saves you alot of work
recomposing a drawing that that only needs to be "turned around" etc.
If you want a mirror image of something, just create a clone copy
of the sprite you want to flip or turn (eg IN DOS:
copy jas1.pic jas2.pic), then load it up (eg pic_make jas2.pic). Once
loaded, you can turn or flip it with the appropriate 'f' or 't' key.
Once done- hit 'esc'.

PACK.PAS:
---------

Creates the "fringpc1.pic" file whichs contains the sprites that
Fringdus reads. Pack read a list of pic files (*.pic - doesn't have
to have the PIC extension, it can be anything) and then appends them
to "fringpc1.pic".

command: PACK

Once executed, pack reads the 'PACK.INI' file, and moves/appends the
files that are in this directive file, to the 'fringpc1.pic'.


MAP_MAK2.PAS:
-------------

This program edits the map file: "fring1.map". There was a
map_make.pas, but that was an initiating program that was really
shity. This program allows you to change the sprite references-
hence the sprites to be displayed.

To execute, type in:

Command: map_mak2



  The Operation keys are:

                        |

                    -       -    (key pad)

                        |       :This is a block scroll



                        i

                    j       k   :Once positioned with keypad, you
                                 move around with these keys
                        m


   enter: When you want to change a value in the map file matrix
          simply hit this key. You then enter in the new value.
          If you were repeating the same value (the same value last
          entry), then just hit enter without entering in the value
          again- this makes entring data alot faster (and less
          frustrating).

   s: 's' saves fring1.map. Once saved, it immediately exits.


bs.bat:
-------
Boot strap compiler sequence. With tpc (Borland Turbo Pascal V6) in
your path just type in: bs. Fringdus will be built with the relavent
compiler flags.



b_scr.bmp:
----------

The base screen. Fringdus writes this file in video memory initially.
You can edit it this file to your needs using windows "paint Brush"
for example.

(Note, I don't know the BMP format, I've just took a rough stab, just
by displaying BMP's raw, and determining the format. Please send me 
the correct BMP format)

*.pic:
------

The Individual sprite files before being packed.




Enjoy :). Feel free to contact me if you don't understand something,
or can't that something working.


                               ooo0ooo

-----------------------------------------------------------------------------
                              JsNO BAR----NUNN

         Spelling Disclaimer: "MY SUN keyboard is a chunk of shit"

   "Computer Science students learn how to become computing professionals,
   Business Information Systems students are users learning about themselves"
                              NTU, DARWIN, OZ
                        nunn@pandanus.cs.ntu.edu.au
-----------------------------------------------------------------------------


  or
  snail:

    8 Winton Street,
    Jingili, Darwin,
    NORTHERN TERRITORY,
    0810,
    AUSTRALIA.

Newsgroups: comp.sys.ibm.pc.soundcard,comp.os.ms-windows.setup