A Series of Raster Effects by SMFX
/ /! \ / !! / \ / /
/ / ______/ ! ! \/ !! ! _____/ \/ /
:\ \ \_! ! !! ! /\ //___
::\______ \ \! !!! ____/:/ \\:::
::/ / /! !\/! !!! !::/ /\ \::
:/__________/:!_____!: !____!!_____!:/_____/::\_____\:
::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::[ SPKR TOM EXOCET FIVEOFIVE MODMATE XIA ]:::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::
P R E S E N T
......................................................
: :
: A SERIES OF R A S T E R EFFECTS :
: :
: 96k Intro for the 0 Bitplane Compo @ Sommarhack 24 :
: in Grado, Hedemora, Sweden :
: :
: Released July 6th, 2024 :
: :
:....................................................:
: :
: SYSTEM :
: :
: Atari ST 1mb :
: :
:....................................................:
: :
: CREDITS :
: :
: CODE :
: . spkr :
: . Tom :
: :
: GRAPHICS :
: . Exocet :
: . mOdmate :
: :
: MUSIC :
: . 505 :
: . mOdmate :
: :
: ADDITIONALLY :
: . Tat/Avena (Minimyser - tools and msx player :
: :
: :
:....................................................:
: :
: DISTRIBUTION NOTICES :
: :
: This intro can be distributed freely in :
: its unmodified binary form, with all :
: the following files included: :
: :
: . rasters.nfo :
: . rasters.tos :
: . readme.txt :
: :
: This production may NOT be distributed :
: in video form without our explicit :
: permission. :
: :
: Contact us at spkr@smfx.st :
: BEFORE making your video capture public :
: or we will issue a takedown. :
: :
: Permission for distributing video :
: capture granted to: :
: :
: . Evil/DHS :
: . Sommarhack party organisers :
: :
:....................................................:
: :
: A NON-TECHNICAL ESSAY ON THIS DEMO :
: FOR THOSE WHO WISH TO KNOW :
: :
: The basic way to display graphics on :
: the Atari ST is to copy some screen :
: data, in bitplane format, straight to :
: the area of RAM that has been set as :
: screen memory. The ST's video :
: architecture then gets to work and does :
: the rendering for you, fifty times a :
: second, like magic. If your graphics :
: do not then need to update, you can sit :
: back and your image will be displayed :
: on screen - no CPU needed! :
: :
: However!: :
: We made this intro for a special :
: competition at Sommarhack 2024 where it :
: was against dem rules to write *any* :
: screen data to screen memory *at all*. :
: A blank screen. A zero bitplane demo! :
: How can one make effects within this?! :
: :
: So the way we do it is through switching :
: the background colour, just like in old :
: fashioned rasterbars. Rasters use :
: interrupts to wait until typically the :
: beginning of a specific scanline, at :
: which point a tiny bit of code changes :
: the background colour. This produces :
: the visual effect of a horizontal :
: "line" of colour across the screen. :
: :
: Our intro uses exactly the same :
: principle. However, rather than :
: waiting until the beginning of each :
: line and then changing colour for the :
: whole line, we use some well known code :
: tricks to synchronise our code to the :
: electron beam first. This means we :
: then have absolute control over the :
: position at which we change the :
: background colour. We're no longer :
: limited to the very start of scanlines, :
: and can change colour much more :
: frequently with stability. This allows :
: us to "draw" little lines of colour on :
: the screen (e.g. 8x1 pixels), which we :
: can then stack up on subsequent lines :
: to form chunky "blocks" of colour - :
: big pixels! Effects are possible! :
: Whoop! :
: :
: But is it all that simple? Well....... :
: in short - no. :
: :
: The single advantage of this approach :
: is that we can display as many colours :
: as we like on screen from the ST's 512 :
: colour palette. Awesome! And we can :
: also do stuff in the left/right borders :
: very easily, without even having to :
: worry about overscan. Great! :
: :
: The disadvantages and limitations, :
: however, are major. They include the :
: following: :
: :
: 1) To make a longer/shorter tiny :
: rasterline on screen to build up our :
: chunky images, we use instructions of :
: different speeds to do the colour :
: writes. The more CPU cycles an :
: instruction takes, the longer the :
: "line" of the previous colour is :
: displayed for as the electron beam :
: moves across the screen left-to-right. :
: However, for technical reasons, these :
: "lines" are limited to multiples of :
: four pixels in width, starting with 8x1 :
: pixels. Even then, there are :
: additional limitations when using 8x1 :
: lines around how many colours we can :
: display each screenline. :
: :
: 2) Similarly, we can only "move" stuff :
: around horizontally (more accurately: :
: create the illusion of horizontal :
: movement) in 4 pixel intervals. :
: :
: 3) Look closely - you'll see some 4x1 :
: lines/blocks too amongst all the chunky :
: crap! This switch should be impossible :
: and uses a super smart method devised :
: by Mr. Nyh! But as awesome as it is, :
: the method comes with even more :
: limitations about what can be done :
: where. :
: :
: 4) And the biggest issue of all..... :
: Unlike when bitmaps are displayed, :
: where you can sit back and do what you :
: like with the CPU in the background :
: while the ST does the rest, all of :
: these display methods eat 100% CPU :
: while they're active. Unlike on :
: certain rival 16 bit computers, we :
: can't outsource this job to other parts :
: of the hardware! :
: :
: This is a tremendous pain in the ass, :
: especially when we're using the whole :
: of the visible screen area for :
: effects. This is because in these :
: instances, we're doing nothing but :
: using the CPU to change colour for the :
: vast majority of every screenline. :
: That means we have to fit our actual :
: effect code either above or below the :
: visible screen area, or when the :
: electron beam is off the edge of the :
: screen in the non-visible area. So not :
: much CPU to actually do stuff with. :
: Ballache! And you can forget using SID :
: voice/timer based music, unless you're :
: willing to make even more :
: concessions... :
: :
: To summarise: what you see here is a :
: combination of brute force CPU-burning :
: colour switching, packaged up with some :
: brave attempts at lateral thinking from :
: both a gfx and code perspective. We :
: hope you enjoy it! :
: :
: Real hardware is recommended to watch :
: this thing on. However, if you simply :
: must use an emulator, we recommend the :
: latest version of Hatari, as Steem does :
: not emulate this demo fully correctly :
: (hi Troed!). :
:....................................................:
eof[ back to the prod ]