------------------------------------------------------------------------------
Dead Hackers Society Falcon demo system v13.
------------------------------------------------------------------------------
Quick introduction.
By Anders Eriksson (Evil/DHS)
Ok ok, first I want to say I'm sorry that this damn little demo system didn't
make it earlier than this. I promised STS almost a year ago to send him a
text file and source to our demosys for UCM.
Well.. I thought I should improve some bits, bugfix some stuff, write a long
good explanation for every part of the code. With that attitude there can be
nothing but delays. So in the end I decided to release what was already made,
and perhaps send an update sometime later if there is any interest at all.
There should be a package in this diskmag containing the sources and
binaries talked about in the article.
So here we go..
------------------------------------------------------------------------------
Part 01 - Files.
------------------------------------------------------------------------------
main.s the main source, has the demolist and include all the
other files as well.
menu.rsc gem startup interface.
sys/dspmod.s module-playing source, contains the filename for the
mod as well (needs enabling in main.s)
sys/dspmod.tce module-player binary (dsp code etc)
sys/exit.s restore everything and exit prg
sys/fps.s buggy fpscounter, ignore it (need enabling in main.s)
sys/init.s setup the machine, save everything and run inits
sys/loader.s general loadroutine
sys/mp2.s mp2-playing source, contains the filename for the mp2
as well (need enabling in main.s)
sys/mp2inc.bin mp2-player binary (dsp code etc)
sys/startup.s gem and text-menu startup (if enabled in main.s)
sys/video.dat video resolutions in a small binary file. It is
stripped down SCP-files merged together.
sys/video.s video-setting routines
------------------------------------------------------------------------------
Part 02 - General info.
------------------------------------------------------------------------------
This is the latest version of the demosystem first used in the "ATS" demo.
It's heavily changed since then though. Optimized, bug fixed and features
added. A more recent version were used in the "ATS v1.1" and Dream Dimension
v1.1" releases, although these also differ quite much from this version.
What the demo system does is simple:
It runs several demo parts after eachother, like a sequencer. Actually "demo
sequencer" would probably be a better name. Each part can have it's own MAIN,
VBL and TIMER routines.
Much effort have been made to have the demo system to behave friedly to many
types of hardware and operating systems. In fact, it seems to work with all
Falcons and operating systems that I've been able to test. If used in the way
it is designed, the demosys will automaticly run at better frame rate with
accelerated machines and fastram additions.
Shortly some good things about using this system could be;
* Works well with many (all?) Falcons.
* Takes advantage of more processing speed and FastRam.
* Works from all (?) TOS-compatible operating systems.
* Jumps back to the OS cleanly when exited (it seems).
* It is easy (in my opinion) to build a multipart demo and synchronize it.
And some bad stuff about using it;
* There is no built-in routines for DSP-code, DSP sync or other DSP related
functions, except the music players.
* The way it is made, might not suite you.
* Not Turbo-Assembler runable without some big (?) modifications.
* Some parts (FPS counter in particular) isn't finished and is buggy.
* Might very well be possible to optimize a bit more, although the core
parts is pretty OK I belive.
* No sync-feature to modfile special commands or mp2-file headers.
------------------------------------------------------------------------------
Part 03 - EQU's, opts and misc header stuff
------------------------------------------------------------------------------
In the 'main.s' source the main switches are available, just as some other
important settings.
* output .app
This shouldn't really need an explanation, but it gives the output file
the ".app" extension.
* opt p=68030/68882
To allow 68030 specific code as well as 68881/68882 FPU code.
* comment HEAD=%111
To enable Fastload, Malloc-grom-FastRam and Load-to-Fastram fileflags
gen.ttp is used stand-alone from the Devpac editor.
* scr_w (x pixels), scr_h (y lines) and scr_d (bytes per pixel)
These parameters tell how much ST-RAM should be reserved for the screen.
It will reserve three screenbuffers of the size specified by the formula;
screen_width*screen_heigh*screen_depth. 640*480*1 is the largest buffer
needed by any of the resolutions available and is the default value.
* startupmenu equ 0 (or 1)
0 = Start demo directly with the default monitor frequency selection.
1 = Start demo with a menu where the user can select monitor and frequency.
* fps equ 0 (or 1)
0 = No function.
1 = Enable an average fps value to be printed when exiting the demo.
it's buggy, so don't use it.
* dspmodmusic equ 0 (or 1)
0 = No module music.
1 = Play 4-8 channel .mod sound tracker music. If 8 channels, I think the
file header needs to be CD81 and not 8CHN, or perhaps the the other way
around ;) You need to fill in a valid filename for the module in
sys/dspmod.s as well. DSPMOD consumes between 10-25% cpu (approx)
depending on the module and number of channels used (also depends on the
surround/interpolation settings in the source).
* mp2music equ 0 (or 1)
0 = No mp2 music.
1 = Play mp2 music. it's presetted to 32 KHz playback, which is recomended
to use (as many falcons doesn't have a 44100 Hz external clock). The mp2
music will not consume any CPU-time at all. Please note that the entire
mp2-file is loaded to ST-RAM before playing. You need to fill in a valid
filename for the mp2-file in sys/mp2.s as well.
* pause equ 0 (or 1)
0 = Disable pause function.
1 = Enable pause of the demo on the left-shift key. Useful if you want to
study stills of some error that accour. The DSPMOD-music is paused but
the mp2-music will go on (to be fixed sometime).
* cputime equ 0 (or 1)
0 = Disable cpu useage function.
1 = Enable cpu useage function on control key. This looks very flakey and
might confuse more than help. It's a very quick hack. Something better
will be made later.
------------------------------------------------------------------------------
Part 04 - Init routines list
------------------------------------------------------------------------------
Far down into main.s (in the data section) there is a list with entries of
routines that shall be run before the demo starts. Precalcs or such stuff
which isn't suitable to do when the actual demo is running.
To add an entry to the list is simple. An example initlist can be like this;
inits:
dc.l video_2
dc.l blackpal
dc.l my_init_routine_1
dc.l my_init_routine_2
ifne dspmodmusic
dc.l dspmod_load
dc.l dspmod_begin
endc
ifne mp2music
dc.l mp2_load
dc.l mp2_begin
endc
dc.l 0
Each dc.l is an address to a init routine of some kind.
The list begins with setting the screen into video_2 (which is a bitplane
mode, but more about videos later) and then set the palette black. This to
avoid seeing eventual crap on screen or similar things during init.
Then we run our own init routines, which are all subroutines of course.
Later the musicplayers are initialised if enabled. And at the very end the
list is terminated by "dc.l 0".
NOTICE! The music inits should always be put last, as the music will start to
play immediately after the list has been run.
------------------------------------------------------------------------------
Part 05 - Demo parts list
------------------------------------------------------------------------------
The heart of everything. The list which tell what demo parts to run when and
for how long.
Each demo part entry consists of six longwords, describing which MAIN, VBL
and main routines to run. Also for how long it should run, how many screens
it should cycle between and last in which way it should wait for VBL.
An entry is built up like this;
dc.l Ticks,Timer_routine,Vbl_routine,Main_routine,Number_of_screens,Vblwait
Ticks = How many 100th of a second to run this part, 100 = 1 second.
Timer_routine = Address to the routine running at fixed timer-speed (100 Hz)
Vbl_routine = Address to the VBL routine (mainly res-set and pal-set)
Main_routine = Address to the Main drawing routine (runs as fast as possible)
#_of_Screens = Now many screen buffers to cycle. 1, 2 or 3 are valid options.
Vblwait = 0 = Only wait for new vbl if the effect is faster than
1 VBL. Otherwise swapscreen and continue on next frame
directly. Only useable with 3 screen buffers!
1 = Always wait for next vbl when mainloop is finished.
An example demo part entry can look like;
dc.l 1000,bumpmap_sinus,bumpmap_palette,bumpmap_draw,3,0
The effect we run is a simple bumpmap routine, which consists of three parts;
* The sinus increment for the flare moving
* The palette setting
* The actual bumpmap drawing routine
We place the sinus increment on the fixed 100Hz timer. Then the flare movement
will always be relative to 100 Hz frame rate. It assures, no matter how slow
the main loop runs, that the actual sinus position is the same on all
machines.
Palette setting is a good idea to have on VBL (no shit :)).
The bump drawing routine is the one doing the big job. It can take several
VBL's to draw, or under 1 vbl. It doesn't matter.
A demo that first show a bumpmap, and then a tunnel could have a demo part
list like this;
dc.l 5000,bump_timer,bump_vbl,bump_main,3,0
dc.l 150,tun_timer,tun_vbl,tun_main,3,0
That would run the bumpmap for 5 seconds and the tunnel for 1.5 secs.
It isn't harder than that, really.
------------------------------------------------------------------------------
Part 06 - Video modes
------------------------------------------------------------------------------
There are a bunch of videomodes available. All are written directly to the
Videl hardware registers. Every video mode is using the 25 MHz video clock,
which assures that any Falcon, accelerated or not can show the modes.
The has a consequence that on RGB, there is a really heavy overscan mode
sideways. I'm afraid this is not possible to adjust, except using the 32 MHz
clock, but then it will fail on Nemesis, CT2 and other over clocking accls.
However, to set a videomode is dead simple from the part list, example;
dc.l 5,dummy,video_2,dummy,1,0
"video_2" subroutine is located in the sys/video.s file, as all the other
resolutions that can be selected.
The available resolution subroutines are:
video_1 Sets 144*100 16bit on VGA, and 288*100 on RGB.
If your routines are using this resolution, they have to be
made to draw differently on VGA and RGB. Why? Simply for
optimizing reasons. A simple way to detect if we're using VGA
or RGB:
tst.w monitor
beq vga
bra rgb
video_2 Sets 288*200 16bit on VGA and RGB.
video_3 Sets 288*200 8bit pixelmode on VGA and RGB.
video_4 Sets 576*400 8bit pixelmode on VGA and RGB.
video_5 Sets 320*240 16bit pixelmode on VGA and RGB.
video_6 Sets 320*240 8bit pixelmode on VGA and RGB.
video_7 Sets 640*480 8bit pixelmode on VGA and RGB.
------------------------------------------------------------------------------
Part 07 - Music notes and tips
------------------------------------------------------------------------------
To create mp2-files that are suitable isn't hard, but a good idea is to
encode it in a way so all Falcons can play the song at correct speed.
The mp2.s is currently setup so it will ignore external DAC clocks, which
means it will play the same speed no matter of the external DSP clock. It also
means that a 44.1 KHz Hz mp2-file will play at 49.1 KHz which without doubt
will sound up-pitched a good bit.
So a recomendation is to make the file 32 KHz instead of 44.1. The Falcon play
a little higher than 32000 Hz, but the tune is very well replayed still. With
lower frequency, you actually gain some quality in lower bitrates too, as
there is less data to compress.
Which bitrate should be used? Tests show that anything below 56 kbit/sec at
32 KHz mono is really not worthwhile. Staying at 32 KHz mono, the sound-
quality is starting to get really OK at 64 kbit/sec. Going above 64 kbit/sec
seems mostly useable if the song is short enough so you can spend some more
space and memory. Using stereo seems pretty pointless unless again you
have some serious memory and diskspace to play with.
A golden rule is that the mp2-file+screen memory should fit inside 4 megs of
memory. Apart from that, the higher bitrate you can fit, the better.
------------------------------------------------------------------------------
Part 08 - Last stuff
------------------------------------------------------------------------------
Ok, almost done now.
Together with this issue of "Alive" you should have the original demo system
as well as an example "demo" using the demo system.
We are aware that this code is probably not what everyone likes as it is made
for DHS in first hand and everyone like his/her code different to others.
If you see some part or routine you like, feel free to rip it out and use it
separately.
The startup menu is far from perfect, it's a blocking dialogue and the code to
detect if it should use GEM or text output is.. well not what I want in the
final version. The "runlevel exit" works fine, however it will change later
to a flag-check exit instead.
Ok, that's all I think, if you want to use this demosys, it would be nice with
a little credit or so in eventual productions, but not a must. It's free to
use and modify as you wish.
Oh, and one last thing I forgot :-) When you write to screen, always do that
to the address found in "screen_adr" variable and that the source is made
with and for gen.ttp!
Any questions can be sent to ae@dhs.nu and I'll try to answer you.
Code on!
|
