NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/programm/17960

Text File | 1992-12-30 | 4.9 KB | 120 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!news.cs.indiana.edu!nstn.ns.ca!psinntp!psinntp!viper!news
From: [e-mail] (Brett Bourbin)
Subject: Re: Going to the metal
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 30 Dec 1992 16:43:49 GMT
Reply-To: [e-mail]
References: <[e-mail]>
Organization: Visix Software, Reston, Virginia
Lines: 107

In article <[e-mail]> [e-mail]
(Chuck McManis) writes:
[interesting article deleted]

Chuck talks about development time differences in coding "to the metal"
and using the OS. While his example of reading the joystick port is
effective (although not using the correct processor 8^) ), there are
things that go into creating a game the seems to be ignored by most people
in these newsgroups (since most are NOT using a low-end Amiga with minimum
resources).

When writing a game, the first thing you must do is identify who your
customer is going to be. Many people here think that should be EVERY Amiga
owner, which would be really nice, but sometimes, not realistic. With this
in mind, when I write games, I first think about the majority of Amigas.
This happens to be 68000-based 512K machines, with 1M machines starting to
make its way to the top. So now I have a "target" machine to develop for.

The first thing I did when starting to write games is I learned the OS. I
did things with graphics and exec and input and gameport OS calls. Know
what, it was too slow to take on what was being done on other machines and
other games on the Amiga (the competition). I guess I might add the type
of games I write are 3D perspective, arcade-type action titles (not
everyones "cup of tee").

So what I did next (and I will try to give some pointers here, so this
article has some validity) was create a new OS. This OS takes over at boot
time and gives me a basically empty machine. A quick list of some of the
functions my OS has are:
    Kernel manager
        revectoring kernel functions
        timing
        vertical blank processing and hooks
        processor cache manipulation
    Display manager
        can create an build "Views" like the AmigaOS
        color control (fading and such)
        can create special Copper tricks
        double-buffering
    Event manager
        handles mouse, joystick and keyboard inputs
    Process manager
        handles multiple process for "multi-tasking"
    Object manager
        maintains image objects
        handles animation language programs
        efficient use of Blitter for sprites
    Memory manager
        clearing memory
        filling memory
        drawing lines and plotting points
        scaling, shearing and rotation image memory
    Math manager
        handles trig functions
        matrix operations
        random numbers
    Debug manager
        revectors processor exceptions
        serial debugging between target->host
    Disk manager
        handles floppy disk reads and writes
    etc...
All of this fits in 8K of code (excluding buffers and images), is written
in assembly and can be assembled for different 68K-based machines. It also
uses the whole memory map for its use (remember there is no AmigaOS
running at this point).

So how does it get started? During the boot process:
    allocs a section of CHIP memory for the kernel
    reads the tracks that have the kernel into this memory
    extracts what type of machine we are on
        gets ExecBase->AttnFlags
        gets VBR
        figures out how much and type of memory
    opens graphics library
    loads NULL View
    waits a few frames
    shuts down the AmigaOS
    saves all the info gathered in kernel memory
    clears caches if needed
    jumps to kernel
    relocates kernel to its home and initializes

Yes, I have already passed the point of no return (almost). I also have a
boot loader that works from my harddrive that will do all the same things
that the bootblock loader does and save state so it can restore on exit.

Now all of this was not "easy" but it does go down to the metal. It also
works on all the machines I have tested from 68000 to 68040s and A500 to
A3000s. All my games (application code) is written to my gameOS (kernel)
and is reused. I paid the development cost once. The application is free
to use the extra memory for its own caching (disk tracks, images, sounds,
etc.)

I am very sorry that C= is not releasing info on the AGA chip set, since I
would add support in the kernel for it.

So, as you see, going to the metal may not be always easier, but it does
allow writing a game that will work almost as good on a A500 as on a A3000
with extended resources. This is the MAIN reason why I wrote my kernel as
the hardware level and not the AmigaOS level (along with being able to
write for SEGA machines).

--             _  _    _      _
Brett Bourbin        (_ |_ | /__ | |(_  4431 Lehigh Road, Suite 151
  [e-mail]    __)|_ |_\_/ \_/__) College Park, Maryland 20740
  ..uupsi!visix!brett          LIMITED       703.758.2733