Skip to main content
Retrocomputing

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

6
  • 4
    What you've described is usually called a "display list". Interestingly, you have almost precisely described a system that I intend to build at some point... just add the idea that a transition can switch to a different encoding scheme (e.g. to text only, or to different colour depths of raster data, the idea being that screen sections that don't need as much data to store can use a more optimal format) and it's exactly what I'm planning. AFAIK the Atari 7800 was the only system similar to this. See: atarihq.com/danb/files/7800vid.txt for details of its capabilities. Commented Mar 16, 2018 at 23:44
  • 1
    (In my design, the minimum distance between transitions is unnecessary, because the display hardware renders each scan line into a small static RAM buffer while the previously line is being displayed from another buffer, then the two buffers are swapped... the only constraint is that there's enough time to fill the buffer before it's needed) Commented Mar 16, 2018 at 23:47
  • 1
    I'm not persuaded the described system would work as well as described. If I want to insert a four pixel sprite at position X, how do I know what to write as the transition at X+4? Prima facie I need to traverse the existing list to the final transition prior to or on X+4, which will become a lot of work in practice. Also, dealing with transparent sprites is going to be a hassle? Commented Mar 17, 2018 at 3:23
  • @Tommy Yes, it would be more work for the programmer and the CPU dealing with those issues; that would be a tradeoff. Commented Mar 17, 2018 at 8:49
  • 2
    @rwallace apologies; I could have been more explicit: I spent a while pursuing a sufficiently efficient way to create the sort of result you describe for software rasterisation of polygons on a Z80. I wanted to draw front to back, end up with a sorted list of non-overlapping spans, compare to the spans from the last frame, draw only the differences. My best solution was an [average] O(log n) binary-tree based insertion; binary search cost too much in terms of actual byte movement. Even then it still wasn't much better than brute forcing back-to-front with overdraw. Hence my scepticism. Commented Mar 20, 2018 at 20:42