base:spritevectors
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
base:spritevectors [2016-12-09 17:03] – [The data exporter] bitbreaker | base:spritevectors [2020-07-28 08:42] (current) – bitbreaker | ||
---|---|---|---|
Line 1: | Line 1: | ||
===== Sprite vectors ===== | ===== Sprite vectors ===== | ||
- | Basically | + | 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/ |
+ | |||
+ | So as you see, basically | ||
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. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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. | ||
{{: | {{: | ||
Line 91: | Line 97: | ||
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/ | 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/ | ||
- | ====== | + | ====== |
- | 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 happen. Also 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 160x160. Also 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.txt · Last modified: 2020-07-28 08:42 by bitbreaker