User Tools

Site Tools


base:spritevectors

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
base:spritevectors [2016-12-09 16:39] – [Precalced flat slopes] bitbreakerbase:spritevectors [2020-07-28 08:42] (current) bitbreaker
Line 1: Line 1:
 ===== Sprite vectors ===== ===== 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.+In 2010 Glance presented a vector in there Demo Snapshot, that updated at 50 frames per secons. The technique used therefore was originally named SMGF (Sprite Masking Gap Filling), yet only black blackground was used and no x/y-movement. 
 + 
 +So as you see, basically one can also draw edges by displaying sprites and manipulating their 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 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. 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.
 +
 +{{:base:sprite_base.png?96|}}
 +
 +This is what sprites look like unexpanded. If only first line is stretched, nothing is displayed, if first line is skipped, display of solid lines start until also this line is skipped in the stretcher.
  
 {{:base:spritefiller_step01.png?768|}} {{:base:spritefiller_step01.png?768|}}
Line 61: Line 67:
 ====== Y-movement ====== ====== 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.+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. The entry can only happen on full charlines, as sprite display and badline supression can only work from there on. So some offsetting wizardry has to be added (rough y position charline-wise, y & 7 as an offset to the object's y-position). Upon leaving of the display code badlines are again allowed and the invisible sprites will be displayed until line 21 is displayed on each sprite, no more stretching happens from there on.
  
 ====== Precalced flat slopes ====== ====== Precalced flat slopes ======
Line 75: Line 81:
  
 Thus we save on code and only need unrolled code for increasing and decreasing slopes. Way less than for the steep case! Thus we save on code and only need unrolled code for increasing and decreasing slopes. Way less than for the steep case!
-====== Bresenham vs. fixed point math ======+====== 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.+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. 
 + 
 +<code> 
 +      sbc frac 
 +      bcs + 
 +      inx 
 +
 +      stx sprite1_pos + .x * dcode_size 
 +</code>
  
 ====== The data exporter ====== ====== 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. +The nifty part is to write a data exporter that runs through all edges from left to right and finds out about the right order to build up the object with sprites with the right order/priority. It also calculates the dimensions of the gap sprites. Also all data should be as tiny as possible. In fact, it uses two passes (slope generation, edge sorting) and is that butt ugly and bad documented that i do not know if it is good to share, and that means something :-D But it is worth an exercise in our nowadays world of cross-development.
  
-====== Adding the Wurstglanz ======+====== Future work / outlook ======
  
-to be continued soon...+If the badline-supression is done per frame and not per line (but black background then) the ratio of edge building sprites and gap sprites can be shifted towards more edges, as more x-position writes can happenAlso this technique peaks on frames where a lot of nearly 45° slopes happen, else quite some rastertime is left, but on peaks (SID included) only 3 rasterlines are left at maximum size of 160x160Also if going one pixel beyond in size, 3 gap sprites are needed for a single face and we run out of sprites anyway :-)
  
 +====== Adding the Wurstglanz ======
  
 +to be continued soon...
base/spritevectors.1481297984.txt.gz · Last modified: 2016-12-09 16:39 by bitbreaker