pouët.net

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