Codebase64 wiki

User Tools

Site Tools

Trace:
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
Last revisionBoth sides next revision
base:spritevectors [2016-12-09 17:09] – [Sprite vectors] bitbreakerbase:spritevectors [2016-12-09 17:17] – bitbreaker
Line 6: Line 6:
 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?24|}}+{{: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. 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 94: Line 95:
 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. 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 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