Writing OS-Friendly Games

by Chris Green & Spencer Shanson

(c) Copyright 1992-93 Commodore-Amiga, Inc. All Rights Reserved

Many Amiga programmers believe that the only way to write a whiz-bang, speed-of-light games is to bypass the operating system and go straight to the metal. A better approach is to write games that are OS-friendly. The combination of OS 3.0 and the AA chipset makes this more possible than ever.

Reasons to use the OS for games:

Things the OS can't currently do:

All these are planned to be addressed in future OS releases. One of our goals is to make it possible to perform as many amiga tricks in normal intuition screens as is possible.

ECS-AA incompatibilities that the OS handles:

Future envisioned chip changes that the OS will handle correctly:

Game programming problems and solutions:

Q: What is the graphics rendering routines are much slower than my own blitter code?

A: Use the blitter yourself. Call OwnBlitter, do setup, call WaitBlit(), poke the blitter registers, and then DisownBlitter() when all blits are done.

Q: What if input.device eats too many cycles?

A: Install a high priority input handler which chokes off all events. This handler is also a convenient way to get keys and mouse events yourself. Simply store the raw keypresses and mouse moves in your own variables.

Q: How do I change both bitmap pointers and colors in sync?

A: Use a user-copper list to cause a copper interrupt on line 0 of your viewport. The copper interrupt handler will signal a high-priority task which calls LoadRGB32 and ChangeVPBitMap (or ScrollVPort) to cause the changes. This allows perfect 60hz animation on an A1200, even while moving the mouse as fast as possible, and inserting floppy disks.

Under 3.0, you can also do this in an exclusive screen. You can tell if it was your screen which caused the copper interrupt by checking the flag VP_HIDE in your ViewPort->Modes.

Q: I need to use the blitter in an interrupt driven manner instead of polling it for completion. Aren't the QBlit routines too slow?

A: The QBlit/QBSBlit system was completely re-written for 3.0, and now has quite low overhead.

Q: How do I determine elapsed time in my game?

A: A simple, low overhead way to determine elapsed time is to call ReadEClock. This returns a 64 bit timer value which counts E Clocks, and returns how many EClocks happen per second. If you use these results properly, you can ensure that your game runs at the proper speed regardless of CPU type, chip speed, or PAL/NTSC clocking.

A1200 speed issues

The A1200 has a fairly large number of wait-states when accessing chip-ram. ROM is zero wait-states. Due to the slow RAM speed, it may be better to use calculations for some things that you might have used tables for on the A500. Add-on RAM will probably be faster than chip-ram, so it is worth segmenting your game so that parts of it can go into fast-ram if available.

For good performance, it is critical that you code your important loops to execute entirely from the on-chip 256-byte cache. A straight line loop 258 bytes long will execute far slower than a 254 byte one. The '020 is a 32 bit chip. Longword accesses will be twice as fast when they are aligned on a long-word boundary. Aligning the entry points of routines on 32 bit boundaries can help, also. You should also make sure that the stack is always long-word aligned. Write-accesses to chip-ram incur wait-states. However, other processor instructions can execute while results are being written to memory:

	move.l	d0,(a0)+	; store x coordinate
	move.l	d1,(a0)+	; store y coordinate
	add.l	d2,d0		; x+=deltax
	add.l	d3,d1		; y+=deltay
will be slower than:
	move.l	d0,(a0)+	; store x coordinate
	add.l	d2,d0		; x+=deltax
	move.l	d1,(a0)+	; store y coordinate
	add.l	d3,d1		; y+=deltay

The 68020 adds a number of enhancements to the 68000 architecture, including new addressing modes and instructions. Some of these are unconditional speedups, while others only sometimes help.

Adressing modes

New instructions

Hardware resources

Do's and Don'ts

CPU Differences


Writing OS-friendly games benefits you, the developer, and the gamers who buy your games. It ensures the viability of your code on all Amiga platforms, not just the one you used for development. By allowing the OS to do the mundane details of opening screens and windows, you give yourself more time to do the creative portions of your game. It does not matter how fast your game is if the gameplay is lousy and the artwork looks like a finger painting from a pre-schooler.

An OS-friendly game is no longer something to be avoided. We've provided ample tools in the OS to support your gaming needs, and we will continue to do so. The sooner your write OS-friendly games, the sooner you'll be prepared for the future.

Uploaded on Sunday 2021-02-14