_ _____
| | !___ |
| | CHAPTER 9 : USEFUL STUFF __! |
| | | __!
'-' '-'
.-. .-.
'-' '-'
Just some tricks to help you on your way to make demos, games, whatever.
EVEN directive:
This is not for structurising or anything. This is used to put the following
data on a word-edge. The basic 68000 generates an error when it reads/writes
(long)words on byte boundaries. So when you use many single bytes or buffers
that contain an odd number of bytes, you should make sure all following
labels are word-aligned!
The usage is very simple:
byte: DC.B 0
EVEN
label: DC.L "THIS IS EVEN"
In the TEXT section this isn't necessary. The assembler automaticly word-
aligns everything there.
Assembler options:
In for instance DEVPAC you have the OPT directive:
OPT D- * Don't put labels in PRG.
This is very handy for release versions of your stuff as well as for reducing
the size of your executable. The labels labels in the executable take up some
extra space.
OPT P=68000 * No CPU instructions >68000
This is handy when you develop on a 68020 or higher and also want to make
executables for simple and plain 68000. Sometimes you don't even notice using
some 68020 addressing modes, when in fact these don't work on 68000. Now the
assembler will process error-messages when it encounters these.
COMMENT HEAD=%111 * code, alloc and data in TT-RAM
When you've got a TT, Falcon with TT-RAM or a clone, this is very nice stuff.
TT-RAM is always faster than using ST-RAM, especially so on the Falcon when the
VIDEL is in a high resolution and the SDMA is on.
But beware!!! You should never put soundbuffers or screenbuffers in TT-RAM!
The videochip and soundchip can only access ST-RAM. They have 24-bit address-
space you can address from 0 to 16MB.
This is come accross by using the Mxalloc gemdos call:
move.w #0,-(sp) * Indicate ST-RAM only!
move.l #10000,-(sp) * Give buffersize.
move.w #$44,-(sp) * Give gemdos code.
trap #1 * Execute gemdos-trap.
addq #8,sp * Get parameters off the stack.
Random routines:
A machine can't actually figure out some random number. It's not as chaotic as
the human mind and especially not as weird as mine =) but you can use simple
tricks for simulating random numbers.
To initialize the random routine:
move.l #$3e8f356b,d0 * Just as a startvalue.
When needing a new random value, execute this:
rol.l d0,d0 * Rotate it d0 MOD 32 times.
addq.l #7,d0 * Add 7 to it.
It's not very exact, but it's ideal for quick and dirty stuff. It's ideal stuff
for simple things like starfields, simple textures and more. I have the amiga
dude Azure to thank for this. It's dead smart.
A more accurate approach would be this:
move.l d0,d1 * Store d0 temporarily.
mulu.w d0,d0 * Multiply d0*d0.
eor.l d1,d0 * Exclusive OR it.
addq.l #7,d0 * Add constant to it.
A bit more intensive, but far more exact noisegeneration.
Triple buffering:
How do coders achieve smoother framerates in flexible graphics engines? In
realtime graphics you want to move from 50fps straight down to 25 fps when
something more happens on screen. This is the problem with waiting for the VBL
to occur every animationframe.
When your engine needs just over the interval between two VBLs. Say only 1.1
times that amount, the waiting for the VBL will increase this amount to 2.
That means that 50/2 = 25fps. Hhhhmmm. That's lousy. And it looks especially
jerky when it drops from 50fps downto 25. uGlY!
Hhhmmm.. Wasting a relativily large amount of time sucks, but how do not wait
for the VBL to occur? Surely this means introducing flickering into our screen?
Not true! By using an additional screenbuffer and swapping through your three
screens you won't overdraw the active physical screen => no flickers!
Doing this is easy and why some demo-coders still haven't implemented this
technique is a big question. Simply rotate through your screens like so and
don't wait for the VBL anymore!
move.l screenaddress1,d0
move.l screenaddress2,d1
move.l screenaddress3,screenaddress
move.l d1,screenaddress3
move.l d0,screenaddress2
If you drew to screenaddress1 this frame, then you can use d0 to install the
new physical screen:
lsr.w #8,d0 * Get mid byte in low byte.
move.l d0,$ffff8200.w * Kick in the new screen.
Illegal instruction:
This is for debugging purposes only! When you want to be absolutely sure
about your programflow not getting into any nasty corners, illegal
instructions are a must! When the CPU encounters the "illegal" opcode it
executes an exception. Normally this throws four ugly boms on your tube =)
Illegal instructions can (should) be used like this:
bsr DO_NASTYSTUFF * Call a routine.
tst.w d0 * Test if returned ok.
bpl.s all_clear * If positive -> ok!
illegal * Unexpected result!
all_clear:
Take note that bombing your machine doesn't have to cause anything bad, but
when you've replaced all kinds of interrupt routines and taken you own
screen this might not be real nice. The 4boms exception doesn't restore
screenaddresses or interrupt-routines, so watch out!
Also, when you've debugged your code, you should ultimately replace the use
of "illegal" with error-handling calls.
Summary:
Even directive: Allows the coder to always make data word-aligned.
Opcode: Short for "operation code". This is the code a
certain instruction is assembled into.
OPT: Assembler directive that can be used to enable/
disable certain assembler options.
Random routine: More like pseudo-random actually. This is a way of
simulating chaos. One specific "seed" value inputted
in the random routine always results in the same
result.
Triple buffering: Often used in realtime games or demo-effects. This
is flickerless and gives a smoother display than
double buffering. Triple buffering owes it's name to
the use of three screenbuffers.
TTram: Happy owners of an Atari TT (hence the "TT" in TTram)
or a good Falcon-accelerator can be souped up with
fast-ram. This RAM is free from accesses by the video
and soundchips and can be accessed with full 32 bits
at once. Atari has provided some bits in the
executable-header that enables to use or neglect the
TTram.