::::::: - - - - - - - - - - - - - - - - - - - - - - - - - -:::::::- - - - - - - - ::::::: ::::::: ::::::: ::::. ...... ...... .:::: ::::::. ::::::::... ...:::::::: .::::: _____ _____::::: _____:::::_____:::::::::_____:::____ _______ _\ \ / /_:::: _\ \:::/ /_:::::__/ /:_/ \ __\ / / \____\ /____/ \:::/ \____\:/____/ \:::/ /____/:/ \____/ \ /_____\ /_____/ \____\:/_______\ ::::\____\:/____/ :\____/ /______\ ::::::: .::::::::::. ::::::: ::::::: . .::::::::::::::. . ::::::: :::::: ::....::::::::::::::::::....:: :::::: ::::: :::::::::::::'' ''::::::::::: ::::: > 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