Pacemaker by Paradox [web]
:::::::
- - - - - - - - - - - - - - - - - - - - - - - - - -:::::::- - - - - - - -
:::::::
::::::: :::::::
::::. ...... ...... .::::
::::::. ::::::::... ...:::::::: .:::::
_____ _____::::: _____:::::_____:::::::::_____:::____ _______
_\ \ / /_:::: _\ \:::/ /_:::::__/ /:_/ \ __\ /
/ \____\ /____/ \:::/ \____\:/____/ \:::/ /____/:/ \____/ \ /_____\
/_____/ \____\:/_______\ ::::\____\:/____/ :\____/ /______\
::::::: .::::::::::. :::::::
::::::: . .::::::::::::::. . :::::::
:::::: ::....::::::::::::::::::....:: ::::::
::::: :::::::::::::'' ''::::::::::: ::::: > RA
:::::: ::''''''' ''''':: :::::: > Zweckform
::::::: ' ' ::::::: > 505
::::::: > Paranoid
- - - - - - - ::::::: - - - - - - - - - - - - - - - - - - - - - - - - - -
:::::::
. . .. ::::::: _presents_
. . . .........
. . ... . . . ...
. . . . .. ............
. . ... . . . . . . .....
_____ . . . .......__ __ __ . . ...__
/ ____ ____ ____ / / / ____ / __ ____ ___
/ _/ / / / __/ / _ / / / / / / / _/ / _ / / __
/ ____/ / _/ / / __ / __/ / __/ / / _/ / / _ / __/ / /
/ ___/ ___/ ___/ __/ __/ ___/ /_ ___/ /
. . . ... . . . . .. ........__/
. . .
. . . . . ..... Version 1.0 .
Prologue
~~~~~~~~~~
This little document is supposed to accompany the demo named
>> Pacemaker << by Paradox, released 2005. It is meant to give
some background information, supply a few facts and details
about the demo and probably set a few things straight.
It will also highlight changes from the party-preview to the
released version 1.0.
Legal Stuff
~~~~~~~~~~~~~
No member of Paradox can be held responsible for any kind of
damage that occured to your hardware, software, mental or
physical health or anything else related to you in any
obscure way, while, before or after running this demo.
The demo named >> Pacemaker << may be copied as long as it
is distributed free of charge. If there is one Public Domain
Service left in the whole wide world still supporting the
Atari community - feel free to offer it but don't expect
anyone to pay anything for this.
It should be copied without excluding or adding any of the
related files.
Hardware Requirements
~~~~~~~~~~~~~~~~~~~~~~~
The minimum requirements currently are
- An Atari STE compatible computer
- At least 2MB of free RAM
- A colour monitor or TV set capable of displaying the low
resolution of 320 x 200 pixels (plus a few additional ones
in RA's routines)
- A double sided disk drive
- A clockspeed of 8MHz
The demo has been designed with other machines in mind as well,
but due to the fact that most of the additional capabilities the
STE has been given are explicitely used, it will definetly not
run on the following machines:
- An Atari ST computer
- An Atari TT computer
- An Atari STE computer with 512KB or 1024KB RAM
Then there is also a set this demo runs on but will probably not
present all effects in the exact same quality as it does on the
machine mentioned first in this chapter:
- An Atari Falcon030
Slight hick-up has been observed in a few critically timed screens
The Endpart does not run very well on the Falcon on VGA. Overscan
and multiple screen splits prefer RGB.
- An Atari MegaSTE
No restrictions observed
Additionally, this demo should cooperate with other extensions your
system might have. It has been tested on
- An Atari Falcon030
Nemesis, Videlity, Screen Blaster, NVDI 4.11, TOS 4.04, 14Mb RAM, FPU
- An Atari MegaSTE
NVDI 4.11, 16MHz, Cache On, 4MB RAM
- An Atari 1040 STE
Clean machine, 4MB RAM
And as a final note, since it has gotten very popular by now, this
demo does _NOT_ run correctly on a Falcon with a CT60 equipped.
It might if you turn all caches off, but then it might run even
slower than on an original 030-Falcon without any additions.
I am sorry about this, but it seems that the CT60 does not go
along well with extensive Blitter arrangements. Unfortunately, i
had no time to take a closer look at this and also, it was not the
main purpose of this demo to run well on this tuned machine but to
run well on the machine it was aimed for.
Party Version
~~~~~~~~~~~~~~~
As you might have guessed, the party version has been put together
in a terrible hurry, like _all_ party versions are. Zweckform had
finished the graphics just a few days before, RA has still found
several bugs in the endpart during the party, i had just put the
demo together, there were neither transitions nor any kind of
timing, and 505 started working on the soundtrack after having
watched the demo for the very first time - On the party.
A few relics from the party version made it to the final version
as well, so here's a small list:
- 2 MB Limit
Everything is kept in RAM right from the beginning ... Sorry.
- Transitions
All Effects are faded in and out. RA actually coded beautiful
transitions but that would have required to do the whole timing
anew, so we decided not to.
Full Credits
~~~~~~~~~~~~~~
Main Graphics:
Zweckform
Music:
505
Add. Code:
RA
Main Code:
Paranoid
Some Textures:
TNT of Paranoia
Music Replay:
Dark Angel / MusicMon 2.1
Effect Timing:
Zweckform
505
Paranoid
Additional credit must be given to Evil of Dead Hackers Society
as he made the demo-engine i initially started with. While the
engine has been transformed several times, the startup- and
exit-code has remained the same so that this still belongs to
Evil - Many thanks for having shared this engine.
Also, the roto-zoomer, while transformed and changed many times
as well, is based on Gizmo's original roto-zoomer for 68881 and
68030. Thanks to Gizmo of DHS for the original routine.
The C2P-Code (Chunky-to-Plane conversion) is losely based on the
algorithms by Kalms, Llama, Dynacore and Ultra.
The tables in this demo have been generated by an offset-generator
by Evil of DHS, again modified to suit our needs.
Technical stuff
~~~~~~~~~~~~~~~~~
So this demo is an STE-only demo. And STE-fanatics always want to
know what features are used of the STE and to what extent. So here's
a little wind-up list about what STE features are actually used and
why we don't think that the ST could compete in these aspects.
STE palette:
The demo does not only feature static STE palettes for pictures
and effects but also smooth transitions between palettes using
the extended STE palette. For alpha-layer effects, 16 greyscales
look so much better than ST-transitions from black over blue to
white or similar. For fading, the STE-palette provides a softer
transition that lasts longer without having to introduce visible
delays.
Blitter:
In our opinion, the BLiTTER has been underestimated in many
aspects. Therefore, we tried to think of new ways how to use the
BLiTTER in our demos without jumping the sprite-record-bandwagon.
We were lucky in a few ways. We actually made the BLiTTER perform
many add-operations for us quicker than the CPU could, we got the
BLiTTER to perform underflow-protected decrements for us and we
also use it for Melt-O-Vision effects, for zooming, to quickly
clear buffers and, of course, to display real-time generated
and therefore non-preshifted sprites.
It seems that the BLiTTER actually _can_ be used in new-school
effects.
Hardware-Scrolling:
The STE Shifter's hardware scrolling is being used to support
hires new-school effects on the STE. And naturally, it is being
used to smoothly move graphic objects around. Also, it is the
basis for the vertical overscan scroller in the end part.
Screen-Splitting:
Screen Splitting, the modification of screen line address in
the middle of the screen build-up, made it possible to have
individually moving, separate effects and naturally, without
it, the vertical overscan scroller in the end part wouldn't
have been possible without.
DMA-Sound:
While the main music of the demo is being replayed on the
YM2149 without using any DMA-Sound effects, the end part badly
relies on the fact that DMA-Sound can be replayed without any
kind of CPU-interference - Naturally, the samples are packed
and are being depacked in real time.
The effects in detail:
~~~~~~~~~~~~~~~~~~~~~~
All music throughout the whole demo: 505
0. Lens-Effect
A hires offset chunky effect, converted on the fly to
plane and brought onto the screen using the BLiTTER of
course.
Graphic/Colours: Zweckform
Offset-Table: RA
Code: Paranoid
1. Double Hires-Bumpmapper
This effect is based on hardware scrolling and screen
splitting. Two individial bump-mappers are rendered and
brought on screen to the correct position using the hard-
ware-scrolling, and in the middle of the screen, the
second bump-mapper's screen is shuffled in.
No chance to do it this quickly with a 320 x 200 bumpmap
on the ST in this resolution.
Graphic/Colours: Zweckform
Code: Paranoid
2. Fake Radial Blur Rotozoomer
Even though it might sound odd, this effect is more or less
a pure BLiTTER effect. The CPU does the rotating and zooming
of the original texture, but the BLiTTER does the rest. It
zoomes, reduces brightness and correctly adds the result of
this operation to the original texture - Twice!
Graphic and Code: Paranoid
Fine-tuning/Colours: Zweckform
3. Smearing 3D Blobs
This effect plots 49 3D-Blobs on screen and moves them
with a motion blurring effect performed using the Blitter.
This allows us to display greetings just along with the
3D-Blobs that fades down just the same, and naturally,
we can rotate the blobs around all 3 axis.
Greetings: 505
Code: Paranoid
Fine-tuning/Colours: Zweckform
4. Smearing Bouncing Blobs
Basically the same effect as above, this time the blobs
rotate only around 2 axis but got an additional bouncing
movement. Fade-Down again performed using the Blitter.
Code: Paranoid
Colours: Zweckform
5. Double Alpha-Layer Tunnel
The basic effect uses no STE advantages, but the fiery
light-blob with the fizzing dots emerging from it is being
renedered with BLiTTER cooperation.
Texture: TNT of Paranoia
Colours: Zweckform
Code: Paranoid
6. Linear Melt-O-Vision Blobs
This effect heavily relies on the BLiTTER once again as the
BLiTTER performs the fading, zooming and naturally, the
melting all at once.
Colours: Zweckform
Code: Paranoid
7. Running Sonic
Again, this is basically a BLiTTER-effect. The landscape and
the sprite are generated by the CPU, but the BLiTTER handles
the resulting sprite(s). The BLiTTER makes it possible to
handle the sprite in 100% realtime. Using preshifting - which
is popular on the ST - the sprite itself would have required
roughly 16MB of RAM for the exact same behaviour.
Sonic-Sprite and Ring-Sample: Sonic Team (Sonic 2/MegaDrive)
Graphics and Code: Paranoid
Fine-tuning: Zweckform
8. Endpart
Overscan Code, a bunch of Rasters using 4096 colours of
course and a freaky distorting scroller in 3 bitplanes
heavily using the STE's screen splitting ability plus an
exclusive Soundtrack by 505, being depacked, interpolated
and replayed in realtime based on RA's newest packing
technique.
Font: Pursey
Music: 505
Code: RA
x. Hidden Screen 1
Oh well ... Just a variation of an effect featured anyway.
Additional Graphics: Sonic Team
Code: Paranoid
y. Hidden Screen 2
A slightly different family reunion with a tragic ending.
Overscan code, but not very much more.
Graphics: Zweckform
Sample: 505
Ugly Logo: Paranoid
Code: RA
Changes to the Party-Version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The demo has been severly revised and reorganized since the party-
version in order to make it a better demo. Here's what we changed:
- Timing
All effects have been re-synchronised to the music
- Effect presentation
The way the effects behave has been completely redone
- Technical Improvement:
+ 2 Bumpmapped Lightflares
+ Additional effect on the Paradox Logo
+ Improved Speed on the radial-blurr Rotozoomer
+ Improved Speed slightly on the 3D-Blob effects
+ Added additional Sprite in the last effect
- Greetings
- Graphics
The pictures have been revised and improved
- Music
The music has been reworked
- End-Scroller
Lots of text added to this
FAQ
~~~~~
? Where are the sprites ? I thought Demo-making is about 16x16,
2bitplane, non-masked sprites ?
! And cooking is about how to boil eggs the quickest way.
No, seriously. Demo-making is about how to impress the viewer.
This can be achieved in several ways, by very technical effects
(i.e. Sprites), by well looking effects (i.e. Design), by
presenting naked women (i.e. C-Rem) or by badly detuned music
(i.e. French Kiss). This demo attempts to impress the viewer by
presenting effects seen before in a new way and showing a few
effects not seen yet on the STE.
? Bah. Doesn't run on my CT60
! True. But hey, CT60-Demos don't run on my STE either. And my
Mega Drive games don't run on my Super Nintendo. This demo was
meant to run on an STE and it already covers every other,
compatible hardware, like the MegaSTE and the Falcon030. Switch
your CT60 in 030 mode and there you go.
? Why is this demo STE-only ? All of it can be done on an ST, too!
! Feel free to try it. This demo needs the Blitter, hardware-
scrolling, screen splitting, extended palette and DMA-sound for
a good reason and while the ST surely can perform the same
tricks in general, it will not in the same quality.
? But then, why does it play chipmusic ?
! Unfortunately, MODs cost a lot of CPU time and sample-sets a
lot of RAM. New-School effects like neither of them. Besides
that, our musician prefers chipmusic.
Additionally, the end-part features RA's newest approach to
well-sounding DMA-sound. His real-time packing and interpolating
costs less than 30% CPU time and delivers high quality sound.
? Isn't Paradox a cracking group on the Amiga ?
! Yes, i think so. But frankly, we have no contact with them.
We are also not a subdivision of them. Paradox on the Atari is
a completely independant group. Whether they like it or not.
? Sometimes, on startup, bitplanes are screwed.
! Unfortunately. Haven't found a cure for that yet.
? Another party version ? No design again ?
! Unfortunately, yes. But also, we didn't want to spoil it all
again just because a few design-fanatics might complain about
uninspired transitions and mediocre synchronising to the music.
After all, we owed the Atari community a demo this easter after
we mentioned one already for last year, and we weren't willing
to cancel it again.
? I don't mind that, but in the end, "final versions" are never
released.
! That's not true. While many party versions stayed final, don't
you still prefer that over getting no new demos at all ? And
also, Dune and Sector One, Paranoia and a few others have shown
that party versions must not be final at all.
And here it is.
Shared Wisdom
~~~~~~~~~~~~~~~
How about some more technical details and maybe even a little
tutorial for your own games or demos ? Here goes ...
Real-time palette fading from any current to any target value
actually turns out to be really ugly. Why is that ? Because
the STE stores the bits making up each colour entry in a very
individual way that makes ordinary math slightly difficult.
Now, each palette entry is a word long and consists of 3
nibbles. On the ST, only 3 bits of these nibbles are being
used and make up the red, green and blue shares of the
desired colour:
Palette entry:
Bits: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|_________| |______| |______| |______|
unused red green blue
Now, that automatically explains why "white", where all 3 basic
colours reach their maximum, implies a hexadecimal value of $0777
on the ST. Let's look at how the bits are ordered, especially
when judging their significance:
Bits: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|_________| |______| |______| |______|
unused 2 1 0 2 1 0 2 1 0
This means that the least significant bit, i.e. the one making
the smallest changes to the resulting colour when setting or
erasing, is on the right while the most significant bit, i.e.
the one with the largest contribution to the resulting colour,
is on the left side of each nibble.
When Atari introduced the STE, they expanded the palette to 4096
colours. However, since the ST already spanned the whole Spektrum,
the extension of the palette on the STE naturally meant softer
shades - the STE palette is more or less in between the ST colours.
And instead of 3 bits per red, green or blue, the STE now requires
4 bits - the full nibble.
However, to not lose compatibility with existing ST software,
the ST-compatible bits 2, 1 and 0 had to remain exactly where they
were for the software to manipulate these.
Therefore, Atari decided to introduce a new "least significant" bit,
but to place it in the only free bit of the nibble:
Bits: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|_________| |_________| |_________| |_________|
unused red green blue
Sign.: X 2 1 0 X 2 1 0 X 2 1 0
with "X" referring to the new least significant bit.
I.e., Bit X contains half the value of Bit 0.
As a result, the transition from "black" to "white" on the STE
looks slightly different to the one on the ST:
ST STE
$0000 $0000
$0888
$0111 $0111
$0999
$0222 $0222
$0AAA
$0333 $0333
... ...
$0EEE
$0777 $0777
$0FFF
While this is easy to handle when treating fixed values, it
gets kind of difficult when trying to dynamically generate
palettes on the fly, i.e. to interpolate.
Why is that ? Simply because ordinary math can't work because
the bit ordering is non-linear. For example, the colour $0888
is significantly darker than $0777, but when just looking at
the absolute number, $0888 is larger than $0777. When trying
to dynamically fade however, it is necessary to judge the
direction to "fade" by comparing current and target value
and then adding or subtracting "1" from the current value.
Again, this can't work on the STE palette. Subtracting "1"
from $0888 results in $0777. But $0888 was a very dark grey
and should fade to $0000 while $0777 is bright white.
How to conquer this problem ? By introducing tables, what
else. Actually, the resulting procedure is quite easy once
you have understood the problem and its consequences from
above.
First, we need a table to turn the values from the palette
register - with the non-linear bit-ordering - into values
with linear bit-ordering - Which is easy to do with a table.
We use the current read value to look up the linear ordered
value from the table - for both the current and the target
value. Now we really know whether to increase or decrease
the current value to get closer to the target value.
By having two additional tables, one for fading up, one
for fading down, we can simply use the current value to
look up the desired, non-linear ordered value to write back
to the palette register.
The first table is rather simple. Let's look at an example
for blue:
dc.b 0,2,4,6,8,10,12,14,1,3,5,7,9,11,13,15
Now you read a current "blue" value (4 bit) and use this
as an index to read from the table above. The result is
the linear-ordered value of the initial colour, in which
$0008 is the half-brightest blue and not the darkest one.
After comparing the linear-ordered current with the linear-
ordered target, we can actually decide to fade up or down
one step, using the current value as lookup for one of the
two following tables:
fadedown:
dc.w $0000,$0000,$0008,$0001,$0009,$0002,$000A,$0003
dc.w $000B,$0004,$000C,$0005,$000D,$0006,$000E,$0007
fadeup:
dc.w $0008,$0001,$0009,$0002,$000A,$0003,$000B,$0004
dc.w $000C,$0005,$000D,$0006,$000E,$0007,$000F,$000F
In the first case, 0 can't fade down anymore so it's
listed as 0 again and the first real value, $0008, leads
to "0" as well. In the latter case, it's exactly the
other way round and $000F can't fade up so that it stays
at $000F.
And that's basically it. Now all you need to do is expand
the scheme for green and red as well. You could introduce
additional tables, you can use shifting to make sure the
resulting value is written to the correct nibble.
All in all, it costs just a few hundred bytes ( 224 Bytes
for a rather linear approach), not too much CPU-time and
it really looks a lot better than ST-fading.
By the way, the scheme that Ray proposed for fading True
Colour also works on the STE - Which implies using the
BLiTTER. However, since the palette is only a few entries
in size while Ray's scheme targetted every True Colour
Pixel on screen, i.e. 64000 or similar, it is not really
required on the STE while it is very sensible on the
Falcon in True Colour.
Fin.
The Paranoid
Paradox 2005
[ back to the prod ]