User Tools

Site Tools


base:spritevectors

This is an old revision of the document!


Sprite vectors

Basically one can also draw edges by displaying sprites and manipulating there x position per line. If done so from left to right and with rising priority, several edges can be stacked and thus a vector being build. The rightmost edge then needs to be drawn in background color. But faces might not get bigger than 24 pixels and higher than 21 pixels, a bit small. Also other restrictions hit in, like badlines which makes it impossible to manipulate all sprites each rasterline.

As a first step, we can expand all sprites in X and Y to achieve more effect area, but this is still not satisfactory. As we inspect the shape of a cube, we notice, that it maximum has 3 edges on the left side and a final edge at the right to separate it from the background. So if we manage to display those 4 edges with 4 sprites, we are already on a good way and only need to change 4 x-positions per rasterline, do we? As for the height, we can make use of the sprite stretching trick to make the sprites up to 200 pixels high or even beyond. Happily, this trick also gives us other advantages, as we can switch sprites on/off by omitting a stretch for a single sprite at any given line. Means, our timing over the whole screen will stay the same for each rasterline and thus we can easily use unrolled display code.

First edge being rendered

Second edge being rendered

Right edge/background added

First gap sprite with static x position being underlayed

And colored like first face

Second gap sprite with static x position being underlayed

And colored like first face

Still a small gap left, need to underlay another sprite

As the bright green rightmost edge has priority bit set to char underlay, it will vanish under any graphics that uses ink and will just peek through where paper is used. Now as there is a graphic behind that consists of bright green traces and a green background, the rightmost slope sprites only appear bright green on the traces, that are bright green anyway. Cookie cutter ftw \o/

Full display with altered colours for better visibility of the different elements the vector is made of. Spot the now red sprite under the traces and the gap sprites being colored differently (and with an ugly palette :-D)

The display code looks like this:

ldy #$ff
ldx #$ff
lda #$00          ;corresponding bit for each sprite is set here if we want to
                  ;advance one line in sprite -> on/off
sta $d017
eor #$ff
sta $d017
sty $d006
lda #$3b          ;value is advanced each line to supress badlines and repeat last screen line
stx $d004
ldy #$ff
ldx #$ff
sta $d011
sty $d002
stx $d000
nop

So what does the display code? It stretches all 8 sprites each rasterline, except if $d017 is written with set bits in the first round, then the sprites corresponding to the set bits advance one line. Means, they then display a solid line and are thus turned on on the first occasion. On the second occasion, they advance again to an empty line and are thus again invisible. The x-positions of the sprite are distributed that way that they are valid when being displayed and that writes do not clash and cause display glitches. This works pretty well for the visible range up to 255 (remember, we do not use the MSB, that would just be too much)

Y-movement

The display code is entered at the right offset at the right rasterline and is left after the full height of the object being displayed.

Precalced flat slopes

Flat slopes are stores in slope tables. To save space, each slope is references with a pointer. Thus, we have the possibility to also reference parts of other slopes in case of matches and save memory. The slope code plots directly into the ldx/y statements of the display-code one value per codeblock/rasterline. To offset to the values of the other three sprites, the write is x-indexed.

sbc (slope),y           ;other case: adc
iny
sta sprite1_pos + .x * dcode_size,x       

Thus we save on code and only need unrolled code for increasing and decreasing slopes. Way less than for the steep case!

Steep slopes - Bresenham vs. fixed point math

Bresenham can be done pretty fast, but when doing fixed point we are even faster and the accuracy bears still enough potential to not cause glitches. The unrolled code however is pretty much expensive size-wise. It works the same like the flat slope plotting, but 8 replicas are needed, 4 (max. 4 sprites/slopes/edges) for increasing and 4 for decreasing values.

      sbc frac
      bcs +
      inx
+
      stx sprite1_pos + .x * dcode_size

The data exporter

The nifty part is to write a data exporter that sorts all edges from left to right and calculates the dimensions of the gap sprites. Also this data should be as tiny as possible.

Adding the Wurstglanz

to be continued soon…

base/spritevectors.1481298342.txt.gz · Last modified: 2016-12-09 16:45 by bitbreaker