Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re:   Lemmings - a tutorial Part V (last)
Message-ID: <1991Mar31.003933.1483@mintaka.lcs.mit.edu>
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Organization: The Internet
References: <mykes.0374@sega0.SF-Bay.ORG> <781@tnc.UUCP> <mykes.0774@amiga0.SF-Bay.ORG>
Date: Sun, 31 Mar 91 00:39:33 GMT
Lines: 392

  Hmm. TIme to open my mouth again.

In article <mykes.0774@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>Sorry to paste this whole thing again, but it is the best article
>done so far.
>
>In article <781@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes:
>>
>>[As much as I've been trying to ignore this discussion, now I'm going
>>to open my big mouth ...]
>>
>>I, too would like to see sources for both permanently taking out the
>>operating system (for a high performance game), and for suspending and
>>resuming multitasking properly.  How about a list of trade-offs (what
>>parts of the OS you can and can't use, and how v2.0 impacts the whole
>>scheme).  This would be useful information, no matter which "side" of
>>the discussion you are on.
>>
[Munch...]
>
>The two tracks that I read in contain an 8K kernel of code that replaces
>ALL of the ROM Kernel routines that are needed for a game.  Consider it
>a BIOS of sorts.  In addition to this 8K of KERNEL code, there is another
>12K of floppy disk drivers, because I will not have the operating system
>running to read any further data from the floppies.  As soon as the 2
>tracks are read in, I turn off interrupts and dma and the OS is officially
>dead.  I then jump to the beginning of the allocated block which contains
>the KERNEL.  The first thing the Kernel does is to copy itself down to low
>memory ($200).

  Poof! You just passed the point of no return. Couldn't you spare an
extra 1k of code to test for people with an extra 512k of ram? If on a 
 >512k machine, then save the state of the OS. It doesn't much matter
about returning to the OS, since your game REQUIRES a reboot to load.
 Tell me Mike, have you ever programmed a game other than a action
game? I find that todays game designs just plain suck. I'd still play
Tetris, Donkey Kong, Pac-Man over shadow of the beast. I'm willing to bet
that your game would be boring except for the ohh-ahh of pretty
graphics. Games like Bards Tale, Ultima, Pool of Radiance, and Neuromancer
should multitask.

OB>
>So what are the benefits of taking over?  
>
>Well, I am guaranteed that ALL 512K are mine to use.  I can ORG any 
>graphics, code, or audio data at any hard coded location I want.  This
>practice allows things like blitter routines to have hard coded constant
>addresses in them, which saves CPU cycles where you need them the most.
>
>I can put graphics screens and the stack anywhere I want.  For a 16 
>color game, I put the stack at $80000 and a screen at $78000.  The 
>stack needed for any program I write is < 512 bytes.  The resulting 
>memory map gives me from $100 to $78000 to squeeze the game into.  And
>I do mean squeeze.

 The majority of these benefits are just laziness. Sure, it's nice to ORG
code instead of worry about dynamic memory, and wasting a few extra cycles
to plot graphics, but unless it's absolutely needed it's wrong.

 Consider this. You start writing a game, and optimize it as much as you
can, shaving cycles, memory, etc And end up with 64 BOBs moving at 60fps.
It's possible to degrade the game to 60 BOBs instead of 64 with no
recognizable loss in quality.

  My guess is, when you do a game, your don't have a full design on paper
or know how much performance you need, therefore you just take the 
easy route and go for all out performance. Once you achieve your
game design goal and you find out you still have extra BOB/raster time
left, you go back to the game design and ADD more objects in, thinking
'hey, these extra objects are going to make the game alot more exciting.'
Either that, or you throw in a rediculous animation sequence, or
sampled sound.
  I'm going to go out on a limb and say that Budokan did not need
100% of the Amiga's CPU power to animate the combatants. It may have needed
all 512k of ram for player objects, but not the entire CPU.

>EVERY single instruction that ever gets executed is my own code.  When
>I single step through routines, I get symbolic information for every
>single instruction.  I never see jsr offset(a6) and wonder what the
>heck is going on.  When I do use the OS and step partway into one
>of the ROM routines, I am apalled by how ugly and inefficient the
>code is.  When I write the code myself, I am in full control of
>every clock cycle and byte that is used by the program.

  That's what compiled C code looks like. C is used for large projects
that an Assembly programmer could never accomplish in a resonable
amount of time. I programmed Assembly for 7 years, and I can do things
in C++/LISP that would take insurmountable time in assembly.
I do wish C= would optimize certain parts of the OS with AssemblY.
(Optimize Layers Library clipping code in assembly, and Exec's dispatcher,
and the vertical blank interupt handler. Intuition should stay in C, but
stuff like WritePixel should be in Asy)

>I NEVER need to do dynamic memory allocation, so my memory never fragments.
>Under the OS, if an application doesn't respond quickly enough to 
>Intuimessages, or you have enough windows opened, the OS starts allocating
>memory and never frees it up.  And the OS has serious problems with
>low memory situations (mostly it gurus).  

  I'm willing to bet that all of the memory leaks are fixed in 2.0.
Give the CBM some credit!

>I implement my own BOBs and Multitasking routines.  I preallocate
>eOAnough memory to hold 80 task structures and 80 bob structures by just
>reserving part of the memory map for them.  It takes exactly 4 instructions
>to allocate a task or bob structure and 4 to free it up.  Typically, every
>OBJECT in the game is implemented as both a bob and a task.  The task
>code is a finite state machine that controls the animation and movement
>of the object in the game.  Anytime you fire a bullet, a new BOB and
>new task is created, for example.  A task switch takes about 10 instructions.
>My tasking scheme easily supports 80 tasks getting a slice of the CPU
>in a 60th of a second.  The BOBs system is dependant on the number and
>size of the BOBs, naturally.  All tasks share the same stack, which again
>is < 512 bytes for the whole game.

  Are you really mulTitasking? It sounds to me like your VB interupt
is just looping on a state machine dispatching sub routines. (e.g.
Grab state, look up routIne in lookup table, jump to it if the state is
enabled) This is more like coroutines than real time-slicing. Is it 
possible for one of your BOB tasks to be interupted by another?

>Playtesting is a piece of cake.  You don't have to try too many hardware
>configurations of Amigas to see how compatible the code is.  There
>are only a few software configurations to check out, too (like 1.0, 1.1,
>1.2, 1.3, and 2.0).  If the game were written under the OS, you'd have
>nightmares testing all the possible software configurations.  For example,
>does the game work with GOMF installed?  How about GOMF and DMouse?  How
>many possibilities do you see?  I see bazillions :)  And what if you
>allow multitasking and some CHIP RAM pig program (like DPaint) is already
>running?  GURU.  And you need to test with 4 floppy drives under the OS,
>just to make sure the OS hasn't taken more memory than you can allow.

 No. If the game was written properly for the OS there would be no
problem. If a user runs BROKEN programs like GOMF, then it's his fault, not
the game programmer's.

>>I, too have been involved with writing high-performance games on the
>>Amiga (no, you won't find my name in any credits; I was a technical
>>advisor and algorithm guru rather than a programmer --- most of the
>>programmers I worked with were high-school or college kids who taught
>>themselves everything; lots of raw talent, and most of them handn't
>>the foggiest idea how to figure out a blitter minterm, so I taught
>>them).  At the time, the only way we knew of to get effective arcade
>>games was to kill the OS at boot-up time; I would have preferred to be
>>able to suspend and then resume the OS, but couldn't figure out a way
>>to do it without causing a crash later on.  Most of the 
>>"whiz-kids" working with me thought of the OS as an obstacle anyway.
>>
>
>No sh*t sherlock!  The blitter is a very powerful coprocessor and
>is no piece of cake to learn.  On the other hand, the OS routines
>are PIG slow.  In many cases, you have to restore the hardware to
>a state that the OS needs so the system won't crash.  Once you start
>using the floppy disk hardware directly, for example, you must put
>the CIAs back into a state that the OS wants them in.  What state is that?
>The ROM Kernel manuals LIE.  Have fun finding out what page they lie on,
>because there is NO index.

  I found that the blitter is very easy to learn with the help of 
Tom Rockiki's BlitLab manual.  The difficulty with the blitter is 
learning the tricks with masking, and the bltadat stuff to perform
arbitrary blits anywhere. Also, the fact that the Hardware Manual
(v1.1 that I have) is WRONG in a loT of places and non of the example
code works (it assumes NO OS). When I was first fooling with the blitter
I didn't know how to do a barrel-shift to the left (for a smooth
scroller of course) This is because the HW manual didn't mention
the difference in the way the barrel shifter works in asc/descending modes.
Thank god to Tom Rokiki's and Jeremy San's improvements to the 1.3 HW manual
and for the BlitLab Manual in those early days.
  The Amiga hardware seems to have a lot of quirks that have to be overcome
by tricks. Like stopping a Audio DMA sample, using Disk DMA, programming  
the blitter for 'bit blits' instead of word blits.
  It reminds me of the C64 days of polling the serial/disk ports, timing
out raster's to the cycle, and tricking the video chip to hardware scroll
the screen up and down or provide interlace.



>>On the other hand, games like Sim-City and Lemmings have no real use
>>for that kind of environment.  I agree that the game comes first,
>>*BUT* if you don't need total control, *DON'T* take it.  With the OS
>>comes a lot more flexability (HD installation, a real file system,
>>multitasking, and lots of "Wow!  What a neat game, and it multitasks,
>>TOO!").  Take what you need, bit be sure you need it before you take
>>it.
>>
>
>I agree with this 100%.  If you don't need to take over the machine,
>don't.  If you want to push the machine to its limits, there is NO
>other way.  Let the game come first.  If you know you can do the
>game in a small amount of RAM and that performance is not an issue,
>go ahead and use the OS.  In my approach, if I have RAM left over,
>I use it for more sounds or instrument samples to make the music
>better, or to cache more data from the floppy drives.

   This confirms what I said above. You don't design the game in the
beginning. You program the game according to your ideas, and when you have
finished, if you find ANY Ram/CPU time left, you TAKE IT ANYWAY.
Let's assume you find you have 150k of ram left over after all game
graphics and sound is loaded. There is no reason to use this extra ram
for a rediculous animation/sample. It doesn't improve the playability of
the game. Using this 150k of extra ram, you can save the state of the OS
for restoration.

>>There is no excuse for software to break on 68010, 68020, and 68030
>>machines, and too many programs (most of them games, but does anybody
>>remember TDI Modula-2?) break on accellerated systems.  Be aware of
>>what you are doing when your write your code, and make it upward
>>compatible.  For timing, use one of the many timebases supplied by the
>>OS, or if you have killed it, then program one of the CIA's directly. 
>>Pay attention to compatibility; it will ensure that royalties come
>>trickling in for years to come, instead of months.  
>>
>
>In most cases, the things that break on 680x0 (where x >= 1) are not
>dependant on whether you are using the OS or not.  Self modifying code
>breaks in either case.  Using the CPU for timing breaks either way.
>Use VBL for timing, or the beam position register, but don't use
>a software loop.  Don't use the upper byte of address pointers (either
>in RAM or address registers) for flags/variables.  Read your AmigaMail
>(sent to registered developers) because they constantly remark on
>what practices are invalid.  I sure wish Commodore would collect all
>this information in one place and post it to the net and publish it
>in all the manuals, etc.
>
>Unfortunately, the sales life of a game is about 3 months.  Royalties
>don't keep trickling in.

 I bet a game written for 2000/3000 machines would sell for a long time.
Why? Because there's a niche there that no one has tapped yet, and
the majority of A2000/3000 owners are not pirates, obviously if they can
afford an A3000, they can afford a $30 game. 

>>*NOT* learning how the OS works is a kind of intellectual lazieness,
>>even if you take the effort to "roll your own".  There is always a
>>programmer or program out there who can show you a trick or two, and a
>>lot of clever people spent a lot of time working on the AmigaOS (I
>>have nothing but respect for people like -=RJ=- and the rest of the
>>Amiga crew).  The OS is decidedly *NOT* full of bugs (and if the last
>>time you looked at it was in v1.1, take another look!) and can be your
>>ally, if you learn to control it ("Use the OS, Luke ... Use the OS!"
>>;-)
>>
>
>I agree here too (except about Use the OS).   But I know it too well...
>The OS does have bugs, however.  I spent weeks finding them for other
>people at EA.  Ever hear about the trackdisk bug?  It seems that if
>you have an external floppy drive and have no disk in it, and do intensive
>disk access to the internal drive, it gurus after a random (long) amount
>of time.
>
>Did you know that LoadRGB4() takes a full 60th of a second on a 68000?  
>How long does MrgCop() take (pick random number).  How long does 
>RethinkDisplay() take (seconds)?  How long does BltMaskBitMapRastPort() 
>take? 

  Probably because LoadRGB4 recomputes the copper list. Remember 
screens/views are a sharable resource. Nothing is preventing you from
making a screen, disabling the inputdevice (Amiga n/m screen switch)
and Owning the Copper and Blitter on that custom screen.
  Mike, take alook at Tom Rokiki's RadBoogie. Granted, it doesn't have 
a SoundTracker playing, or filled vectors, but from a programming
point of view, it's an excellent example, and proof that you can program
fast action graphics and still leave the OS functioning.
(Rad boogie calculates multiple splines in real time, blits a huge Amiga 
logo, moves a large sprite, plays a Sonix music, and has a customcopper
going. Most all of those European Filled Vector scrolls/objects PRECOMPUTE
the object rotations and sin/cos paths with a C/Basic/Rexx program. Then
the Assembly code merely looks up table values, and uses the blitter
to draw lines/fill areas)

[deleted... The Amiga is not a C64. Mac's dont have any good actions
games because a game that takes over the MacOS won't sell. Period.]

>
>piece of work and I am not at all trying to bash it.  I am only saying
>that it is not good for games that need performance.
>
>>I'm not trying to flame or put down anyone, but better games than the
>>current crop can still be written!  Better both in terms of
>>awesome-take-over-the-machine-graphics, and better in terms of
>>awesome-playability-and-multitasking-code.
>>
>
>I agree here too.  Looking at most Amiga games next to C64 games
>makes me want to puke.  It is painful to see Amiga games run at 8
>frames per second while the C64 version of the same game runs at
>60.  There is no excuse for this.  If you can't achieve the performance
>under the OS, boot it by all means.  That is what the C64 guys do.  It
>is a proven technique.

  There is no secret why C64 games run at 60fps. That's because 98% of
all C64 games are totally sprite driven. Any backgrounds are merely character
graphics. The C64 doesn't have the horsepower to scroll bitmaps, or
full color character mapped screens in real time. (You can't do it
in 1/60 of a second.) It's a pity the Amiga sprites are smaller than the C64's.
If they were 24/32 pixels wide a lot of games could use them (all 8) instead of
attaching 2 or 4 together.
  The C64 was really pushed to it's limit in both programming a game design.
The Amiga has already been pushed to it's limit (mostly) What it really
needs is GOOD Design.

>You left out what I expect to see from games.  It is awesome-take-over-the-
>machine-awesome-playability-code.
>
>BTW, has anybody ever tried Music-X?  It is a performance oriented piece
>of midi software.  The first thing I did with it was to plug in my $175
>synth and tried to sequence in the built-in demo song.  Poof - guru.
>Damn software couldn't keep up with all those midi events... haha.
>Anybody doubt David Joyner's abilities?  I don't.  The program is
>extremely well done, just the OS can't keep up with 32K baud.

  If I recall correctly, David Joyner did the Amiga port of Faery Tale.
Faery Tale is an example of a game that does only a partial takeover of the
OS. (You can run DMouse before booting the game, and have a faster
mouse) 

>>I suggested earlier that Mike Farren expand and polish his articles,
>>include source code examples which make a complete, small game, and send
>>the whole thing off to AC's Tech.  I still feel very strongly that this
>>should be done.  I also would like to encourage Mike Schwartz to do
>>the same: write up his techniques for taking over the system and
>>programming down to the hardware, inclulde sample code, and send it
>>off to one of the technical magazines (like AC's Tech).
>>
>
>Mike already seems to have this idea in mind, except for the part about
>writing the game.  His Lemmings posts (which actually started this whole
>thread) were full of copyright notices because he expected his stuff
>to be published.  You will see something from me in the not so distant
>future.
 
  Mike, if you submit something to a magazine, put it in context. WHat I mean,
is that don't give the impression that the correct way to program the
Amiga is to boot the OS. Action games have their place, but there are
many types of games beside action games that don't need to boot the OS.
The Amiga is not a C64 (Even WOrd Processors on the C64 booted the OS)
 
  I know that the OS is a big overhead for using the blitter and disk to its
maximum abilities, but the fact that you said it only took you three days
to do that game code shows that you have put much work into it.

'Heart of the Dragon' has 192 color screens, real time action, sampled
sounds and works with the OS. It is not a slow game, I've seen a demo of it.

>>Wildstar
>
>--
>********************************************************
>* Appendix A of the Amiga Hardware Manual tells you    *
>* everything you need to know to take full advantage   *
>* of the power of the Amiga.  And it is only 10 pages! *
>********************************************************


  Let me take some extra time to say, that I used to be in Mike's camp.
I used to program 100% assembler, I used to flame C programmers for not
knowing assembler and programming essentially a 'Black Box'. I used to be
in demo groups and program hardware to its limits (C64). I know the
mentality. Most of the European and American demo coders have 'big egos' like
Mr Schaem. Just read the scroll text on any demo and you'll see groups
cussing each other out. What changed me, was when I got into REAL 
programming on Unix in C hacking interpreters, servers and mini-OS's.
I came to realize that operating systems and standards are there to
benefit the computer and hardware. When people spent $3000 on a computer
system, they expect software to work with it. Bypassing the OS is not
the way to do this, unless you plan on writing custom routines for
each hardware configuration. Assembler is nice to know, but its a huge
waste to use assembler for everything. As hardware gets more and more 
complex (parallel processing, risc, etc) the assembler programmer must
know more and more about the hardware. The hardware today is becoming so
complex that the ORDER of operations is becoming important. Certain
processors now require instructions to occur in precise order to insure
the pipeline is filled. Only compilers can keep track of register and
operation usage throughout the entire program.

  If you're an assembler programmer, the OS is especially annoying because
almost every OS function operates on C structures and linked lists. I became
annoyed because there were too many label names to remember for structure
offsets, and duplicate label names in different structures can't be done
in assemblers witouth collision. This is why C should be used for almost
all operations except speed dependent stuff. I'd suggest that most of
the 'kill the os' move over to CDTV when it hits the market. There you have
600 megs of disk space, and the ability to kill the OS and have no 
complaints.


--
/~\_______________________________________________________________________/~\
|n|   rjc@albert.ai.mit.edu   Amiga, the computer for the creative mind.  |n|
|~|                                .-. .-.                                |~|
|_|________________________________| |_| |________________________________|_|
