TIM1T by Cluster & DMA [web]
TIM1T, by Cluster and DMA My first attempt at becoming a productive member of the scene. Atari VCS 2600, no extra RAM (128 bytes only), no framebuffer, 32k ROM. 90% party version; sadly, the credits part is far from finished. Code and design: Kylearan/Cluster ([email protected]) Music and player: KK/DMA ([email protected]) Zooming square: Since one goal for this demo was to focus on flow and do proper transitions, I wanted an opening that doesn't simply throw the first effect into the face of the viewer, but a slower one with a build-up instead. So I came up with the idea of a square that flies by, spots the viewer, quickly hides, resurfaces again and then zooms in. All I needed for that is a routine that can prepare a horizontal, hi-res line with an arbitrary length starting at any position. Is there *any* system where drawing an arbitrary horizontal line is more complicated than on the VCS 2600? You have to combine hi-res sprites for the start and the end of the line with lo-res playfield for the middle, while of course the playfield registers are of different sizes (4 and 8 bits) and different orientations (draw bits 4..7, 7...0, 0...7). Ugh, what a mess... Intro screen: A simple intro screen, and yet the only kernel in this demo that needed to be run in zeropage because I needed the extra cycles from self-modifying code. The black, vertical lines are actually the ball I had to reuse each scanline, which made things a bit tedious to set up. The rectangles zooming back are a re-use of the line-drawing routine of course. Logo build-up: A rather simple effect (Blocks moving in from above and below build up the logo of the demo) required a somewhat complex kernel because of the lack of a framebuffer. Speed or RAM is not the problem here, but correct hand-overs between different parts of the kernel while keeping the total scanline count constant. The kernel first displays the falling squares, then the top line of the logo that gets currently built from RAM, then the lines of the logo that are finished already from ROM, then the bottom line that gets currently built, then the rising squares. Coding was more time-consuming than hard, with lots of details to take care of and fiddling around. Doing everything for transitions! 3D Starfield: Since seeing my first (2D) starfield on the C64 in 1987, I like starfields a lot - them being oldschool or not. They just look nice. 2D starfields have been don before on the VCS (e.g. 2600 by Vantage) and they are easy anyway, but I haven't seen a 3D starfield before. Can't be so hard, as that's not exactly rocket science, right? With no framebuffer and only 128 bytes of RAM, I hit some unexpected obstacles on the way. First, the kernel. Arbitrary object positioning with no empty scanlines inbetween, plus setting star color and playfield had a consequence: The name of the demo had not only to be a palindrome, but the left and right side of the word had to be an exact graphical mirror as well - no time for an asynchronous playfield. Oh, and hooray for the illegal ISC opcode! Second, having no framebuffer means I have to sort the list of stars each frame to be able to display them. Here I take advantage of the fact that the list is partially sorted already. Third, I cannot display two stars on the same y position, so they flicker, er, twinkle, in that case. No problem though - that's what stars do, right? :-) Last but not least, RAM. Each star has x, y and z coordinates, screen x and y coordinates, plus two indices in lists I have to maintain for sorting. With some creative data structures and a little bit of faking, I'm able to display 34 stars. RAM is the bottleneck here, so the projecting and sorting routines are not very optimized for speed - although I use a lot of tables for the 2D projection (sue me - this was never meant to be a 4K demo!). Plasma: Until now, plasma on the VCS either has either ugly gaps between lines (e.g., Liquid Candy/Noice) or doesn't allow arbitrary colours and positions (Stella Lives!/Tjoppen, although his approach is really clever!). My goal was to give up on fullscreen in exchange for improvement on both fronts. The result is a solid 9x11 plasma with arbitrary colours - 9 wide because my kernel can "only" display 9 arbitrary colors per scanline, and 11 high because available RAM doesn't allow for more. The first plasma displays these capabilities before the other plasmas use interleaving lines for better visual quality. Actually, I lied a little bit - some colors are not completely arbitrary. If you pay close attention, the middle column appears slightly darker and the rightmost column slightly lighter sometimes. Colors on these columns must have bit 1 cleared/set respectively - experienced VCS coders can make an educated guess why. ;-) Four in one: The four individual effects used here are simple, but it was a nice little challenge to combine kernels to make two at a time happen side by side. That meant I have to pre-calculate data for two of the effects per frame: For the sine waves and for the twister in this case, while plasma bars and raster splits are calculated in the kernel on the fly. Twister pre-calc needs 19 scanlines, so that explaines the size of the vertical gap between the upper and lower effects. Very simple effects used by classic VCS 2600 4K demos (hi Tjoppen, JAC!, and others! :-)), but I wanted to have a relaxed and fun part that plays with the audience a bit. Chessboard credits: I ran out of time here unfortunately. The idea was to have several perspective chessboards rotating in and out of the screen in a big sine movement, with up to three boards on screen at the same time. The code base is there, but that's something for the 100% version. Credits upscroller: The biggest Kernel (code-wise, without data or init code) in the whole demo. Having the Cluster logo only on one side means I have to set PF1 and COLUPF twice per scanline at specific cycle intervals, and do everything else inbetween. The kernel seamlessly and cycle-exact switches between different modes: Displaying one row of font pixels; setting up the next row of pixels; setting up the next char; setting up the next effect. I like the twirling effect. However, half-way through coding this part, I saw "We are all connected" by Fairlight/Offence/Prosonix. Ah well, different machine, so... The Transitions in and out were not very difficult, but add to the flow IMHO. End part: Simple and calm ending. Not much to say here.
[ back to the prod ]