Questions about C64 effects
category: code [glöplog]
I just binged on some C64 demos and I was wondering how are some of the effects actually done. I have some very rudimentary knowledge on C64 coding, but that's as far as it goes.
1) X-rotators
My first instinct told me that they're done using the raster and setting the background color to a different value exactly at the correct time. You could achieve stable raster, then have a bunch of precalculated routines for different slope values and after each rasterline changes, jsr into the appropriate one (fetch the address from the table or something), so in effect the loop would be something like nop nop nop nop nop nop set background color wait for X cycles nop nop fetch address for the next value jsr code. On the other hand, that seems really cycle consuming and is probably really hard to get right, plus it doesn't account for textured ones. So, are they done using a method like this or do they use something simpler like a charset (you have precalculated each variation of the slope at the end of the tube and then just pick from those, but then having it zoom would be quite tricky and there's a lot of different geometry seen in them)
2) high-res movetable effects
I guess it's pretty easy to make a simple 8x8 movetable effect since they were all the rage at some point, but how are the ones with the higher resolution done? Using a character set with a higher resolution? You could pack a 4x2 character set if you'd address a single "pixel" with one bit, but I recall seeing 2x2 ones somewhere? Do they draw to the character set itself, or something like that?
3) Fast plotters
What I mean is something like a 3D starfield or one of those dot record rotator things. How is it possible to address and plot so many pixels so fast if the screen memory is not linearly accessible and what kind of screen modes do they use? And something like one of those 3D dot scrollers like in the new Censor demo, lots of tables that map memory into screen coordinates?
Thanks for any info. The quality of new C64 stuff is so high that it boggles my mind...
1) X-rotators
My first instinct told me that they're done using the raster and setting the background color to a different value exactly at the correct time. You could achieve stable raster, then have a bunch of precalculated routines for different slope values and after each rasterline changes, jsr into the appropriate one (fetch the address from the table or something), so in effect the loop would be something like nop nop nop nop nop nop set background color wait for X cycles nop nop fetch address for the next value jsr code. On the other hand, that seems really cycle consuming and is probably really hard to get right, plus it doesn't account for textured ones. So, are they done using a method like this or do they use something simpler like a charset (you have precalculated each variation of the slope at the end of the tube and then just pick from those, but then having it zoom would be quite tricky and there's a lot of different geometry seen in them)
2) high-res movetable effects
I guess it's pretty easy to make a simple 8x8 movetable effect since they were all the rage at some point, but how are the ones with the higher resolution done? Using a character set with a higher resolution? You could pack a 4x2 character set if you'd address a single "pixel" with one bit, but I recall seeing 2x2 ones somewhere? Do they draw to the character set itself, or something like that?
3) Fast plotters
What I mean is something like a 3D starfield or one of those dot record rotator things. How is it possible to address and plot so many pixels so fast if the screen memory is not linearly accessible and what kind of screen modes do they use? And something like one of those 3D dot scrollers like in the new Censor demo, lots of tables that map memory into screen coordinates?
Thanks for any info. The quality of new C64 stuff is so high that it boggles my mind...
The answer to all three questions are "heavy faking".
In the Censor demo we can see the ball after the scrolls, maybe it's a precalc, with 1 slice that is like 1 or 2 deg X rotation, enough for the animation. Then it use the X,Y position like leds for the text. So it read the scrolltext by pixel and use the ball coordinates. Of course the balls also move, I don't know if it's possible to "record" this in memory.
Please point to some concrete examples. I'm not sure what you mean, especially about X-rotators.
High-res movetable effects can be done in a number of ways, depending on the gfx mode and the effect. E.g. if you want to do a 2x2 effect in 4 colors, you can store it into y-expanded sprites, so each byte is 8x2 pixels in size. Then to fetch/store the 4 multicolor pixels in a byte you can do it like this:
lda pixels0,x
ora pixels1,x
ora pixels2,x
ora pixels3,x
sta target
This takes 20 cycles, and on a 1 MHz CPU this gives you roughly 1000 bytes per frame. But since the VIC steals a lot of cycles for DMA, and you need time for music, the real number is more likely about 700. This means a size of about 13x13 chars. Or more if you lower the framerate. Then you can of course optimize it, e.g. if you can combine some of the pixel tables so you can load more than one pixel at a time. Or you could skip storing to empty areas. Or store the same bytes twice if the effect is mirrored. And so on. It's all about finding the shortcuts that work for the specific effect.
Censor demos is a chapter of its own. Most of their effects are done with bitmap colorcycling. Basically you precalc a bitmap screen with different tiles that can be set to individual colors. That way you can create fast and colorful wavy scrollers, rotating balls, etc. To make it less obvious how it's done you can switch between different bitmap screens or scroll the screen.
High-res movetable effects can be done in a number of ways, depending on the gfx mode and the effect. E.g. if you want to do a 2x2 effect in 4 colors, you can store it into y-expanded sprites, so each byte is 8x2 pixels in size. Then to fetch/store the 4 multicolor pixels in a byte you can do it like this:
lda pixels0,x
ora pixels1,x
ora pixels2,x
ora pixels3,x
sta target
This takes 20 cycles, and on a 1 MHz CPU this gives you roughly 1000 bytes per frame. But since the VIC steals a lot of cycles for DMA, and you need time for music, the real number is more likely about 700. This means a size of about 13x13 chars. Or more if you lower the framerate. Then you can of course optimize it, e.g. if you can combine some of the pixel tables so you can load more than one pixel at a time. Or you could skip storing to empty areas. Or store the same bytes twice if the effect is mirrored. And so on. It's all about finding the shortcuts that work for the specific effect.
Censor demos is a chapter of its own. Most of their effects are done with bitmap colorcycling. Basically you precalc a bitmap screen with different tiles that can be set to individual colors. That way you can create fast and colorful wavy scrollers, rotating balls, etc. To make it less obvious how it's done you can switch between different bitmap screens or scroll the screen.
Please excuse my ignorance, but what is a movetable effect? Googling for "movetable effect demo" comes up with some older Pouet comments from Preacher :-) but no explanation.
Could someone point to an example (C64) demo? Thanks!
Could someone point to an example (C64) demo? Thanks!
Movetable effect: a tunnel :)
A move-table is basically a look-up table (LUT) with data that tells you what movement occurs on what position. E.g. a move-table with only "right direction" cells would scroll the the bitmap from left to right.
Quote:
The answer to all three questions are "heavy faking".
Of course. I am interested in the specifics of the heavy faking :)
What I mean by x-rotator: We Are New at 2:45. I don't know the proper name for this effect, if it has one. There's also one in Zeropage Gravity but it's different (maybe done with characters or something, it looks like that to me), and a great textured one in Dawnfall. Lots of other demos as well. Making this on the PC would be easy (I've made several back in the day, and also vertical ones), but the methods that would be usable there don't work on 8-bit machines.
And yeah, by movetable effects I meant the tunnel. Basically your usual "for entire screen do pixel = texture[precalctable[pixel offset + time]]". Using sprites for it in this way makes a lot of sense.
For the rotators you can basically calculate a few different lines, and on each rasterline switch d018/dd00 to select another of your precalculated lines.
Speaking of effect explanations: How are the big balls / filled circles in Sharp and Mathematica being done?
Preacher: That's just an ordinary texture look-up. At least by my arbitrary definition. ;)
Preacher: That's just an ordinary texture look-up. At least by my arbitrary definition. ;)
What puzzled me in the past was the bitmap stretcher in Parts. But I got a clue by asking at csdb at the time and that inspired me to make an optimization for an X-rotator on X-kore. While it looks as pixel per pixel stretcher, it's faster by using as a look up 3 versions the bitmap gfx, original, moved to one pixel to the right, and 2X stretched, because in Mode 0, 1 byte is 2 pixels, so with careful direct read and write of bytes, it's possibe to have fast pixel alike effect but without ANDing your indiivdual pixels. Anyway,. now the big difference of the Part rotator is that they use more version of the bitmap in char mode, chars with different X stretch versions of chars or something like that I tihnk (and hardware effect for Y stretching I guess). So, copy whole char, much more faster. But I guess for their X-rotators, where it's line has a different stretch value, you still gotta go for byte multicolor, 1 byte = 4 pixels at once.
Now, what puzzle me recently in C64 demos, is some very fast chessboard or bitmap rotators, fullscreen 1 pixel, I was blown by Mekanix at 6:20 but there are more recently, also X/Y distorters, etc. Where I kinda see sometimes some artifacts, reminding me maybe it's another tons of char based effect that looks like pixel effect. Is it? How many chars you would need for what size of bitmap to get different compinations of possible gfx?
Now, what puzzle me recently in C64 demos, is some very fast chessboard or bitmap rotators, fullscreen 1 pixel, I was blown by Mekanix at 6:20 but there are more recently, also X/Y distorters, etc. Where I kinda see sometimes some artifacts, reminding me maybe it's another tons of char based effect that looks like pixel effect. Is it? How many chars you would need for what size of bitmap to get different compinations of possible gfx?
For such an effect, all you need is all possible X coordinates (I think there are 8), and all the possible Y coordinates (8 again). So, 64 chars are enough, plus inversion. But if you want rotating text, as in Mekanix 0:50, you need 4 times more chars or less resolution. Effects of this type were used in ZX Spectrum demos The Board and New Wave 48K (pseudo "text mode" emulated by software).
1) X-rotators
there are 2 kind: if the texture is small (repeats often vertically) and the speed is high (50fps) then you are dealing with raster line trickery: it is possible to achive several kinds display any-line - any-place HW trickery on the VICII.
the second kind is brute force, the trick here is, that the code is not collecting pixels individually. instead its possible to achieve pixel fine horizontal scaling by stamping whole bytes at once. the texture is stored shifted 4 times, and from the 4 versions you can mix out (in certain limites) pixel fine horizontal versions.
2) highres movetable effects:
probably here you are referring to the stuff shown in censor demos. these loop animate bitmaps (2 or 4), and when wrapping around they change the attribute / color memory. its like palette rotation effects on PC, but you even throw in a few phases of picture animation too. Here the "palette" has to be rewritten manually using precalculated asm code.
3) Fast plotters
dots only move horizontally which makes it enough to move them by reloading an index register only. now the same dotmask and index register offset is reused a few times on different parts of the screen. so one dotmask load is enough for several dots, also you can skip OR-ing the pixel into the screen, if you choose a movement which can hide this.
sphere dots have many many simmetries, only a few dots has to be really rotated, doing so only about 2 axises spares you even more. the rest is changing signs and exchanging coordinates for mirroring, and scale tables. To scale the same dot ring smaller and smaller making up the sphere. Half of the whole sphere can be achieved by just exchanging x/y coords.
how to adress the screen fast ? its not so hard, you can get the vertical adress of a bitmap with 2 table lookups, and only 1 more load into an index register to move horizontally, 1 more load to get the bitmask. now if you have a constant NR of dots you can also right away store the adress in a sta sta sta sta... code which will clear it later for you.
you can use character sets to build your own screens, 16x16 is the most common, but 32 char wide screen is also usefule since each span is exactly 256 bytes. to achieve fullscreen with the later you need to change character set 2 times mid screen aswell.
there are 2 kind: if the texture is small (repeats often vertically) and the speed is high (50fps) then you are dealing with raster line trickery: it is possible to achive several kinds display any-line - any-place HW trickery on the VICII.
the second kind is brute force, the trick here is, that the code is not collecting pixels individually. instead its possible to achieve pixel fine horizontal scaling by stamping whole bytes at once. the texture is stored shifted 4 times, and from the 4 versions you can mix out (in certain limites) pixel fine horizontal versions.
2) highres movetable effects:
probably here you are referring to the stuff shown in censor demos. these loop animate bitmaps (2 or 4), and when wrapping around they change the attribute / color memory. its like palette rotation effects on PC, but you even throw in a few phases of picture animation too. Here the "palette" has to be rewritten manually using precalculated asm code.
3) Fast plotters
dots only move horizontally which makes it enough to move them by reloading an index register only. now the same dotmask and index register offset is reused a few times on different parts of the screen. so one dotmask load is enough for several dots, also you can skip OR-ing the pixel into the screen, if you choose a movement which can hide this.
sphere dots have many many simmetries, only a few dots has to be really rotated, doing so only about 2 axises spares you even more. the rest is changing signs and exchanging coordinates for mirroring, and scale tables. To scale the same dot ring smaller and smaller making up the sphere. Half of the whole sphere can be achieved by just exchanging x/y coords.
how to adress the screen fast ? its not so hard, you can get the vertical adress of a bitmap with 2 table lookups, and only 1 more load into an index register to move horizontally, 1 more load to get the bitmask. now if you have a constant NR of dots you can also right away store the adress in a sta sta sta sta... code which will clear it later for you.
you can use character sets to build your own screens, 16x16 is the most common, but 32 char wide screen is also usefule since each span is exactly 256 bytes. to achieve fullscreen with the later you need to change character set 2 times mid screen aswell.
@ "dots only move horizontally"
this part refers to sine-dot stuffs :)
this part refers to sine-dot stuffs :)
"How are the big balls / filled circles in Sharp and Mathematica being done?"
the first is done like on amiga: you can pick freely a line from a predefined gfx set, fex. a pyramid and make it a sphere. any line-any place.
mathemathica, is rather sprite multiplexing, with only animating the different sizes, and even one sphere made of chars thrown in. but this is just a wild guess :)
the first is done like on amiga: you can pick freely a line from a predefined gfx set, fex. a pyramid and make it a sphere. any line-any place.
mathemathica, is rather sprite multiplexing, with only animating the different sizes, and even one sphere made of chars thrown in. but this is just a wild guess :)
Great explanations, Oswald! Couldn't have done it better.
Indeed, thank you. It makes a lot of sense... maybe it's time to go disassembling :)
Awesome simple trick for hires table effects, which Oswald taught me in Soiled Legacy note is to render odd/even lines alternately using
sta $xxxx, x
Saves cycles, memory and frequently improves look of effects by bluring and/or producing gradients :)
sta $xxxx, x
Saves cycles, memory and frequently improves look of effects by bluring and/or producing gradients :)
Pretty standard thing of the DOS days, too. :)
What examples are there of DOS demos that render odd/even lines alternately?
