A long time ago I read a page that explained the "s-buffer" technique for hidden surface determination. I can't find it anymore, sadly.
The general idea is to keep an array of "segments" per each horizontal line in the display (making 128 arrays total). A segment is just a left x-coordinate, a right x-coordinate, left+right z-depths, and colour. Each array of segments is kept in order.
The polygon filling code is my own method, but it was largely adapted from the method outlined in the graphics programming black book: https://www.jagregory.com/abrash-black-book/#chapter-38-the-polygon-primeval
A few extra notes:
- You can get 30 FPS with about 75 visible polygons
- The fox model (downloaded here: https://opengameart.org/content/5-low-poly-animals) only hits 15 FPS. In general there are about 100 visible polygons at any given time
- All polygons must be convex and planar, but the s-buffer technique completely deals with hidden surface determination (i.e. your models don't have to be convex, and you can have multiple objects in the scene)
- There are still a few visual glitches for corner case polys that are a single line
EDIT: Thanks to @freds72, I was able to track down the original S-buffer article:
Excellent! I tried something similar (using Abrash sorted edge)
some time ago only to realize it's totally impractical on pico :/
The cost of per span operation far outweight overdraw or regular sorting...
Note: I suspect the page you are looking for is: https://www.flipcode.com/harmless/issue01.htm
Note: using convex objects is the worst idea to demo the effect!
Abrash "z-buffer" for Quake, see: https://www.phatcode.net/res/224/files/html/ch66/66-03.html
Bug report: pressing left/right keys breaks the demo
@freds72 You have great insight! I ran a few stat(1) printouts earlier and found that about 80% of cycles are split roughly evenly between scanpoly (the function that find the left+right edges of polygons) and poly2sbuf (the function that inserts all the segments).
The first few objects are convex (they were there before I implemented the s-buffer) but the last two are nonconvex.
Anyway, it did end up being useful to try the s-buffer to have something to compare against. Until I tried it it was unknown whether it was better than the classic sort+draw, which is probably better for pico-8 anyway.
thanks for getting me started again on s-buffer :)
(started from scratch to avoid the collect then draw approach from original article + faster!)
[Please log in to post a comment]