Fujiology Archive/fujiology_archive_v1_0.iso/!FALCON/LINEOUT/OUT.ZIP/SOURCE.ZIP/SOURCE.TXT

Text File | 2004-01-16 | 8KB | 189 lines

=[ OUT source code ]========================================================
                              badly commented code, but here it is anyway...
============================================================================

- getting started ----------------------------------------------------------

if you want to get started and check out or modify some screens, read on.
the style of source code is 99% the same as with the 'delta' demo. a key
feature being the screens may be included with my demo system, but also they
can be used standalone. the screen source code has the extension '.so'.

a .so file can be assembled and ran standalone without any extra measures.
it just includes a test environment 'tester.s' (including a fps counter and
such) and takes off. mostly however, you need to press some stuff on the
numeric keypad to get things going. these keys directly access the custom
event routines of the screen.

if you want to assemble the demo as a whole you can open 'demo.s', assemble
it and run. the demo system primarily depends on sync commands from the
playing modfile, but can also be synced by keyboard input by changing an
equate.

- the libraries ------------------------------------------------------------

there are various, most with the extension '.i'. a few others use the '.s'
extension. the following are use by this demo:

dsp_fix  s : dsp bootstrapper by NoCrew
earxplao s : the 'multitasking' dsp modplayer
fscr2    i : video routines: palette, resolution, blitting and such
math     i : guess what
mem      i : dynamic memory management without the swiss cheese effect
object3d i : primitive 3d objects and damaging routs for use with human fly
s_flydsp s : the human fly rendering pipeline
sys      i : some cookie shit, cache crap
texture  i : perlin texture generator, some palettes

for a more detailed description of human fly, check out the other text
files, bundled with this package:

faq      txt : an early and incomplete faq
format   txt : description of humanfly's native 3d object format
flow_dsp txt : implementation details of dsp version of humanfly
paint    txt : humanfly's paintmodes and their implementation
rle      txt : description of humanfly's native rle sprite format

- the screens --------------------------------------------------------------

contourd so : dither-blurred multi frame rotozoomer
dspbilin so : bilinear filtered rotozoomer
dsprad   so : radial blurred logo '#atariscne'
fast     so : fast environment mapped crosses with background
gridspec so : wireframe city
kaleido  so : 3d environment mapped kaleidoscope
showpic  so : shows the intro picture
spiral4  so : texturemapped spirals (helix) and alpha blended sprites

- screen code layout -------------------------------------------------------

a screen contains a jump table of custom events. the demo system has a list
to the jump table of every screen. when running standalone, the table
address is put into a pointer, for instance:

    move.l    #Radial.table,fxAdr

the test environment then knows where to start.

a screen contains 4 compulsory first routines:

    DC.L    mainLoop
    DC.L    init
    DC.L    initRT
    DC.L    deinitRT

all routines are terminated by an rts. 'mainLoop' should be self
explanatory. 'init' is the routine that is called prior to running the demo,
i.e. the precalc stuff. 'initRT' is the routine that is called prior to
running the screen itself, this needs to be a little zappy unless you want
to pause with some still screen or whatever... 'deinitRT' is the routine
that frees up all memory reserved by 'initRT'.

a failure of init, initRT, deinitRT, i.e. returning a negative number in
d0, will cause the demo system to exit.

after these four the custom event routines start. the list is terminated by
a zero (dc.l 0).

as mentioned above, both in the demo system as well as in the standalone
screens, the numerical keypad may be used to access these custom events.

event | key
------+-------
 0    | (
 1    | )
 2    | /
 3    | *
 4    | 7
 5    | 8
 6    | 9
 7    | -
 8    | 4
 9    | 5
 A    | 6
 B    | +
 C    | 1
 D    | 2
 E    | 3
 F    | 0
10    | .
11    | enter

note: although only 18 events can be addressed by the keys, there may be up
to 128 for use by the demo system. a key matching an unimplemented event is
omitted.

- demo system --------------------------------------------------------------

the demo system consists basicly of only a few parts:

- the libraries
- initialisation of the libraries
- initialisation of the screens, their init routs are called
- the event sequencer

the useful parts amongst the library are the memory manager which is really
unmissable if you want to squeeze a demo in 4MB without a harddisk going
off every 5 seconds and delaying the flow.

the demo system initializes all screens. each screen says they want a block
of a certain size to the memory manager (Mem.register). after initialization
the memory manager takes the biggest registered block (aligned on long
boundary also) (Mem.take). when a screen enters it's realtime initialisation
it may call Mem.getBlock, which returns the block's address.

also the video part is very useful if you want to change resolution and
palette without stripes or other poo on your screen.

Screen.requestUpdate

this takes palette, resolution routine and screenbase addresses and changes
them in the following vbl. passing a zero for each parameter means no
change.

the event sequencer has two modes, controlled by the equate:
'MANUAL_CONTROL', which says all. Setting it to zero causes the mod file to
control the events, see the section below. otherwise screens can be switched
to by using the main part of the keyboard 0...9, Q..P (different in french
and german, but the order is still there. ;) after you switch to a certain
screen you can also control the screen's event by hammering on the keypad.

there's one more special thing: the 'testmode'. this equate can help with
debugging if your screens are coded in a special way. the idea is to put
every screen or palette or whatever critical action between:

        IFEQ    testmode
...
        ENDC

this is mostly useful when running a screen standalone. when it crashes, at
least you can see the desktop (or devpac) again.

it is useful, but admitantly, a watchdog would be a better solution.

- mod file event sequencer -------------------------------------------------

earxplao.s feeds itself with standard mod files, saved from protracker or
flextrax. the key is the 'unused' 8xx command. this provides a means of
synchronisation, yes, but instead of just using a $800 every so often to
jump to the next event in your list, this actually allows the musician to
control every event of the demo in what ever order he likes. the most basic
commands are the following:

$800        : exit demo
$801 - $87F : switch to screen 1 - 127

the switching is performed by means of the 'initRT' and 'deinitRT' routines
in the screens' jumptables. a command to switch to a non-existing screen is
ommited.

to fire some events:

$880 - $8FF : fire the current screen's event 1 - 128

events are handled from left to right, that means channel 1 is handled
first, proceeding to the higher numbered channels. all events on one 'row'
in a pattern are handled in between a animation frame of the screen, i.e.
one call to a screen's 'mainloop'.

============================================================= lineout 2004 =