Posted By
Degauss
on 2012-08-14
08:27:08
|  Re: Insane new demo in Bauknecht quality
Some details about my effects:
The Vertical Twister:
---------------------
The twister operates in DFLI-Mode and its size is 80x50 (or 80x60) pixels. The checkerboard-texture has 50 rotation-angles and is 2 pixels wide. There are no constraints about the colors, every color could occur on every pixel.
Tricks i used to speed it up:
1. If you work on an 80 pixels-per-row screenmode, you would normally need to OR the two colors of a videomatrix-cell together - in the end you work on two pixel-columns per byte. That slows things down heavily. My idea was to put constraints on how big the stride between two rotation-angles can be. If the texture gets "unrolled" or "cooked" in a way that all possible combinations of "rotation-angle" + "stride" get covered, i could get rid of the ORA-instructions. I constrained the strides (maybe "delta" is the better term here) to be -2, -1, 0, 1 and 2 - thats five "versions". So to address these i need a value range of 50 * 5 = 250. Fits in one byte. A piece of pseudo code shows this better i guess:
NUM_ANGLES = 50
LEFT_COLUMN_ROTATION_ANGLE = 4
RIGHT_COLUMN_ROTATION_ANGLE = 5
STRIDE = [RIGHT_COLUMN_ROTATION_ANGLE - LEFT_COLUMN_ROTATION_ANGLE]
STRIDE = STRIDE + 2 ; make sure this is between 0 and 5
ldx #[LEFT_COLUMN_ROTATION_ANGLE + [STRIDE * NUM_ANGLES
ldy #[WHAT SCREEN_COLUMN]
lda texture_row0,x
sta vmem0,y
lda texture_row1,x
sta vmem1,y
lda texture_row2,x
sta vmem2,y
lda texture_row3,x
sta vmem3,y
lda texture_row4,x
sta vmem0 + 40,y
...
2. Additionally i extended the border in the empty areas of the screen. TED switches to double-clock-mode here, so i have a lot more free cpu-cycles
The Zoomer:
-----------
The effect displays 160x190 (or 160x180, i forgot) pixels and works pixel-precise with 8-bit fixed-point precision. The texture is 32x32 pixels in size. It has one fixed color (black, obviously) and three free-to-choose colors per pixel-row. Should sound familiar: Thats character mode, not FLI. The texture is scattered around 4 charsets - again, "cooked" to support the effect. The effect works surprisingly simple, yet its a bit hard to explain. I'll try my best:
The y-stretching is more or less common raster-stuff: I just need to set $FF13 and $FF1F for every rasterline to pick the right pixel-row from the charset. $FF13 = [texture_row DIV 8] and $FF1F = [texture_row MOD 8]; I also need to prevent badlines by settings $FF06 accordingly to not trigger the DMA-cycles. Thats all.
Theres a bit more to tell about the x-stretching: I said i'm preventing badlines but the first two badlines get executed in any case. That means the very same characters from the first row of characters get repeated over the screen over and over. Every char on the screen holds four pixels. The character encodes the stretching of the contained four pixels this way:
bits 0 to 4 : starting pixel-column within the texture (0..31)
bit 5 : repeat or advance previous column
bit 6 : repeat or advance previous column
bit 7 : repeat or advance previous column
So there is a constraint on how much we can zoom (and ofcourse how wide the texture can be). The allowed zoom-factors are in a range between 0.0 and 1.0. So i need to write 40 bytes to stretch along 160 pixels. Summary: The texture got "cooked" into four charsets to support a) the y-stretching via two TED-registers and b) support that "stretch-encoding" for the x-stretch.
However i complicated things a bit by introducing the three arbitrary colors per row and by extending the value-range to work with factors between 0.0 and 2.0. For values between 1.0 and 2.0 i used another set of 4 charsets and this encoding:
bits 0 to 4 : starting pixel-column within the texture (0..31)
bit 5 : advance by 1 or by 2
bit 6 : advance by 1 or by 2
bit 7 : advance by 1 or by 2
The Tunnnel:
------------
Yes, this is a straight movetable-effect. However i tried to make it a bit more hi-res and a bit more fluent. It works in almost-DFLI. That means 80x70 (i think) of luminance values but only 80x35 color-attributes; every second color-attribute-reload is skipped. A trick bubis has invented. The idea is that you notice differences in luminance more than color-differences. Contrasted edges get a bit washed out though, but you almost can't see it.
There is no real movetable, the mapping is rolled out to speedcode on PC. However i tried to improve that speedcode to prevent unnecessary loads from memory. To do this i'm not walking along the movetable in the usual way (top-left to bottom-right) but in "strings" that share the same texture-pixels. Instead of loading the same texture-pixel over and over again, i packed all its "occurences" in one string:
; "left-string" starts
lax left_pixel
ora right pixel
sta here
sta there
sta somewhere
and #$0f
ora next_right_pixel
sta xyz
; switch over to a "right-string"
and #$f0
ora some_other_left_pixel
sta abc
sta def
and #$f0
ora some_other_left_pixel
sta ghi
; get back to the "left-string"
txa
ora another_right_pixel
...
So for most of the time i can circumvent reloading the texture-data from memory. A funny side effect is that the effect looks like 25Hz because the screen-updates occur randomly on the screen.
Additionally i extended the border (like in the twister) to gain more free cycles.
|
