home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaUtilCD2.iso / Misc / CBMDevKit1.dms / CBMDevKit1.adf / tutorials.lha / tutorials / OS_Game_Techniques < prev    next >
Encoding:
Text File  |  1993-11-04  |  11.2 KB  |  337 lines
  1.  
  2.                OS Game Techniques
  3.                            ==================
  4.  
  5.     (c) Copyright 1992-93 Commodore-Amiga, Inc.  All Rights Reserved
  6.  
  7.  
  8. Reasons to use the OS for games:
  9.  
  10. o    Why reinvent the wheel? Spend your time doing things that only you can
  11.     do.
  12.  
  13. o    Compatibility with future chipsets. For instance, some planned future
  14.     chipsets are not register-level compatible with AA.
  15.  
  16. o    Easier adaptation to future hardware. For instance, it takes
  17.     less time to convert a 16 color ECS game which uses the OS into
  18.     a 256 color AGA game than it does to convert a hardware-banging
  19.     ECS game.
  20.  
  21. o    RTG compatibility possible for some games.
  22.  
  23. o    The OS automatically supports pre-ECS, ECS,
  24.     AA, and future chips.
  25.  
  26. o    Easier integration with other system components (CD-ROM, networks,
  27.     serial ports, etc).
  28.  
  29. o    Easy hard-disk install.
  30.  
  31. o    Less code to write. OS has routines for handling all screen positions
  32.     and scrolls, mouse movement, etc. = less development time. You can spend
  33.     more time making the game more playable and less on getting the hardware
  34.     to work.
  35.  
  36. o    More robustness. For instance, the OS floppy-disk code is far less
  37.     picky about drive parameters than 99% of custom floppy i/o code.
  38.  
  39. o    Hides bugs and quirks of the chipset.  The AA chip set has a few bugs which
  40.     the OS hides from you.
  41.  
  42. o    The code runs out of ROM, which is faster than running the code out of
  43.     CHIP RAM.
  44.  
  45. o    Multiple platforms. OS code will run on all Amiga-based machines,
  46.     whatever their flavour.
  47.  
  48. o    Tools exist to help you debug your code rely on the OS being around (eg
  49.     Mungwall and Enforcer).
  50.  
  51. o    A properly written game can be promoted, and thus work on cheap VGA
  52.     monitors.
  53.  
  54.  
  55.  
  56. Things the OS can't currently do:
  57.  
  58. o    Scroll individual scanlines of a viewport
  59.  
  60. o    AA colour copperlist fades
  61.  
  62. o    dynamically update user copper lists.
  63.  
  64.     All these are planned to be addressed in future OS releases.
  65. One of our goals is to make it possible to perform as many amiga tricks
  66. in normal intuition screens as is possible.
  67.  
  68. ECS-AA incompatibilities that the OS handles:
  69.  
  70. o    Vertical counter behaves differently in programmable beam modes.
  71.  
  72. o    No SuperHires color scrambling.
  73.  
  74. o    Bitplane alignment problems.
  75.  
  76.  
  77.  
  78. Future envisioned chip changes that the OS will handle correctly:
  79.  
  80. o    Chips with no fetch-mode selections. All selections automatic.
  81.  
  82. o    Different DDFSTART/STOP calculations.
  83.  
  84. o    Color loading differences
  85.  
  86. o    Exact copper timings differences
  87.  
  88. o    No SuperHires
  89.  
  90. o    Multiple blitters
  91.  
  92.  
  93. Game programming problems and solutions:
  94.  
  95. Q:    What is the graphics rendering routines are much slower than my own
  96.     blitter code?
  97.  
  98. A:    Use the blitter yourself. Call OwnBlitter, do setup, call WaitBlit(),
  99.     poke the blitter registers, and then DisownBlitter() when all blits are
  100.     done.
  101.  
  102.     Note: OwnBlitter() is only 3 instructions (counting rts) when no-one
  103.     else is trying to use the blitter.
  104.  
  105.  
  106.  
  107. Q:    What if input.device eats too many cycles?
  108.  
  109. A:    Install a high priority input handler which chokes off all events. This
  110.     handler is also a convenient way to get keys and mouse events yourself.
  111.     Simply store the raw keypresses and mouse moves in your own variables.
  112.  
  113. Q:    How do I change both bitmap pointers and colors in sync?
  114.  
  115. A:    Use a user-copper list to cause a copper interrupt on line 0 of your
  116.     viewport. The copper interrupt handler will signal a high-priority
  117.     task which calls LoadRGB32 and ChangeVPBitMap (or ScrollVPort) to
  118.     cause the changes. This allows perfect 60hz animation on an A1200,
  119.     even while moving the mouse as fast as possible, and inserting floppy
  120.     disks.
  121.  
  122.     Under 3.0, you can also do this in an exclusive screen. You can
  123.     tell if it was your screen which caused the copper interrupt by
  124.     checking the flag VP_HIDE in your ViewPort->Modes.
  125.  
  126.     
  127. Q:    I need to use the blitter in an interrupt driven manner instead of
  128.     polling it for completion. Aren't the QBlit routines too slow?
  129.  
  130. A:    The QBlit/QBSBlit system was completely re-written for 3.0, and now
  131.     has quite low overhead.
  132.  
  133. Q:    How do I determine elapsed time in my game?
  134.  
  135. A:    A simple, low overhead way to determine elapsed time is to call ReadEClock.
  136.     This returns a 64 bit timer value which counts E Clocks, and returns how
  137.     many EClocks happen per second. If you use these results properly,
  138.     you can ensure that your game runs at the proper speed regardless of
  139.     CPU type, chip speed, or PAL/NTSC clocking.
  140.  
  141.  
  142. A1200 speed issues:
  143.  
  144.     The A1200 has a fairly large number of wait-states when accessing chip-ram.
  145. ROM is zero wait-states. Due to the slow RAM speed, it may be better to use
  146. calculations for some things that you might have used tables for on the A500.
  147.  
  148.     Add-on RAM will probably be faster than chip-ram, so it is worth segmenting
  149. your game so that parts of it can go into fast-ram if available.
  150.  
  151.     For good performance, it is critical that you code your important loops
  152. to execute entirely from the on-chip 256-byte cache. A straight line loop 258 bytes
  153. long will execute far slower than a 254 byte one.
  154.  
  155.     The '020 is a 32 bit chip. Longword accesses will be twice as fast when they
  156. are aligned on a long-word boundary. Aligning the entry points of routines on
  157. 32 bit boundaries can help, also. You should also make sure that the stack is always 
  158. long-word aligned.
  159.  
  160.     Write-accesses to chip-ram incur wait-states. However, other processor 
  161. instructions can execute while results are being written to memory:
  162.  
  163.     move.l    d0,(a0)+    ; store x coordinate
  164.     move.l    d1,(a0)+    ; store y coordinate
  165.     add.l    d2,d0        ; x+=deltax
  166.     add.l    d3,d1        ; y+=deltay
  167.  
  168.     will be slower than:
  169.  
  170.     move.l    d0,(a0)+    ; store x coordinate
  171.     add.l    d2,d0        ; x+=deltax
  172.     move.l    d1,(a0)+    ; store y coordinate
  173.     add.l    d3,d1        ; y+=deltay
  174.         
  175.     The 68020 adds a number of enhancements to the 68000 architecture, including
  176. new addressing modes and instructions. Some of these are unconditional speedups, while
  177. others only sometimes help:
  178.  
  179.     Adressing modes:
  180.  
  181. o    Scaled Indexing. The 68000 addressing mode (disp,An,Dn) can have a scale
  182.     factor of 2,4,or 8 applied to the data register on the 68020. This is totally
  183.     free in terms of instruction length and execution time. An example is:
  184.  
  185.     68000            68020
  186.     -----            -----
  187.     add.w    d0,d0        move.w    (0,a1,d0.w*2),d1
  188.     move.w    (0,a1,d0.w),d1
  189.  
  190. o    16 bit offsets on An+Rn modes. The 68000 only supported 8 bit displacements
  191.     when using the sum of an address register and another register as a memory
  192.     address. The 68020 supports 16 bit displacements. This costs one extra cycle
  193.     when the instruction is not in cache, but is free if the instruction is in
  194.     cache. 32 bit displacements can also be used, but they cost 4 additional clock
  195.     cycles.
  196.  
  197. o    Data registers can be used as addresses. (d0) is 3 cycles slower than (a0),
  198.     and it only takes 2 cycles to move a data register to an address register,
  199.     but this can help in situations where there is not a free address register.
  200.  
  201. o    Memory indirect addressing. These instructions can help in some circumstances
  202.     when there are not any free register to load a pointer into. Otherwise,
  203.     they lose.
  204.  
  205.     New instructions:
  206.  
  207. o    Extended precision divide an multiply instructions. The 68020 can perform
  208.     32x32->32, 32x32->64 multiplication and 32/32 and 64/32 division. These
  209.     are significantly faster than the multi-precision operations which are
  210.     required on the 68000.
  211.  
  212. o    EXTB. Sign extend byte to longword. Faster than the equivalent EXT.W EXT.L
  213.     sequence on the 68000.
  214.  
  215. o    Compare immediate and TST work in program-counter relative mode on the 68020.
  216.  
  217. o    Bit field instructions. BFINS inserts a bitfield, and is faster than 2 MOVEs
  218.     plus and AND and an OR. This instruction can be used nicely in fill routines
  219.     or text plotting. BFEXTU/BFEXTS can extract and optionally sign-extend a bitfield
  220.     on an arbitrary    boundary. BFFFO can find the highest order bit set in a field.
  221.     BFSET, BFCHG, and BFCLR can set, complement, or clear up to 32 bits at arbitrary
  222.     boundaries.
  223.  
  224.  
  225. o    On the 020, all shift instructions execute in the same amount of time,
  226.     regardless of how many bits are shifted. Note that ASL and ASR are slower
  227.     than LSL and LSR. The break-even point on ADD Dn,Dn versus LSL is at
  228.     two shifts.
  229.  
  230.  
  231. Hardware resources:
  232.  
  233. 1) Blitter.
  234.     Use OwnBlitter()/DisownBlitter() to claim and relinquish ownership of
  235.     the blitter.
  236.  
  237.     YOU MUST USE THE GRAPHICS.LIBRARY WAITBLIT(). This is as fast as
  238.     possible, uses no CPU registers, and knows about blitter bugs. You
  239.     cannot possibly write one that is more efficient and works on all
  240.     Amigas.
  241.  
  242. 2) Copper.
  243.     If you really have to take over the copper, get the LoadView(NULL),
  244.     do 2 WaitTOF()s, and then install your own copperlists in the cop1/2jmp
  245.     registers. I do not recommend this though. Future chipsets may have 
  246.     faster and more efficient coppers with 32 bits, and we will
  247.     want to use these. If you load the old    copper registers behind
  248.     graphics' back, we have no way of switching back to the old 16-bit mode.
  249.  
  250.     temp=GfxBase->ActiView;
  251.     LoadView(NULL);
  252.     WaitTOF();
  253.     WaitTOF();
  254.     /* custom.cop1lc = ??? */
  255.  
  256.     ...
  257.  
  258.     WaitTOF();
  259.     WaitTOF();
  260.     LoadView(temp);
  261.     custom.cop1lc=GfxBase->copinit;
  262.  
  263. 3) Audio.
  264.     Use the Audio device. There are functions to change the volume, period,
  265.     frequency, data etc that is played on any of the channels. If you must
  266.     hit the audio hardware, you can ask for the channel you need with the
  267.     highest priority (127), and the audio channel will never be stolen from
  268.     you until you give the channel back to the system.
  269.  
  270. 4) Timers.
  271.     Use the timer device. Some of the timer.device functions work as
  272.     libraries, and so are easy to use. This allows you to be compatible
  273.     should we use a 3rd cia time, say.
  274.  
  275.     The vertical blank can be used as a special low-frequency timer. See
  276.     below.
  277.  
  278.     CIA timers can be allocated via the resource allocation calls. The 
  279.     "Resources" chapter of the V37 RKM: Devices manual has a good example.
  280.  
  281.  
  282. 5) Input.
  283.     Input will usually come from keyboard, mouse, joystick, infra-red etc.
  284.     Mouse and joystick can be easily read from the hardware keyboard input 
  285.     could come from the keyboard.device, which knows how to handle keyboard
  286.     timings, but it is easier by far to open an intuition window and read 
  287.     either RAWKEY or VANILLAKEY IDCMP messages. These either give the raw 
  288.     key number pressed, or the character the key pressed represents
  289.     (useful for international games).
  290.  
  291. 6) Interrupts.
  292.     Set up interrupt servers with high priority. Your server will
  293.     then be the first called.
  294.  
  295. 7) Disk drives.
  296.     Just use the DOS.library. It's so much easier, works on all possible
  297.     drives, past, present and future, and makes s/w so much more friendly
  298.     to the user. Floppy based copy protection can be accomplished by
  299.     allocating the blitter and inhibiting the drive while checking for 
  300.     the key track.
  301.  
  302. Do's and Don'ts:
  303.  
  304.  
  305. o    DO clear unused bits when writing, and mask out unused or unneeded bits
  306.     when reading.
  307.  
  308. o    DON'T use timing loops. The reasons should be obvious.
  309.  
  310. o    DON'T write self-modifying code unless you know how instruction caches
  311.     work.
  312.  
  313. o    DON'T steal memory. You can always call CloseWorkbench().
  314.  
  315. o    If you are hardware banging, don't assume anything about the initial
  316.     contents of the display registers when your program is started.
  317.     Initialize everything.
  318.  
  319. o    If using ViewPorts, be sure to have a properly allocated ViewPortExtra.
  320.     Some graphics calls are faster when one is present.
  321.  
  322. o    DO NOTE WELL THE WARNING AROUND THE COPINIT STRUCTURE.
  323.  
  324.  
  325. CPU Differences:
  326.  
  327. o    Caches.
  328.  
  329. o    Copyback and write-through modes.
  330.  
  331. o    Access to CHIP RAM.
  332.  
  333. o    '020, '030, '040 instruction and effective addresses.
  334.  
  335. o    MMUs and FPUs
  336.  
  337.