paulb_nl wrote:
This would be difficult to test because...
I forgot that your test was using sprites to indicate what had been written. My own tests would prefill OAM with predetermined patterns, perform the reads or writes then display the numeric values to indicate which addresses had been read or written. It's a different approach, but it seemed like an easy way to pinpoint addresses.
I've gone ahead and modified my write test, and it shows identical results on line 224 as to those before it. That seems to indicate evaluation happens as usual at the very least.
I suppose we could have reasoned that away by realising that enabling overscan at the last second wouldn't appear to have any effect on sprites.
Nevertheless, I repeated the test with overscan enabled and 239 behaved the same, so there we are. Final line same as every other line, as far as we know.
Quote:
The buffer used during in range evaluation would be different from the render line buffer. It would be like secondary OAM on the NES but it does not seem to be like the NES if we can affect sprites by writing to OAM during tile fetching.
Right. Evaluation buffers indexes only. Fetching uses those indexes to buffer some data from OAM and pattern from VRAM. The writes that happen during fetching affect the buffering at that point only.
Something like:
Eval -> OAMi -> Fetching -> OAM2 -> Render
An edge case would be whether disabling a sprite during fetching would allow for another sprite or sprite tile to be displayed that would not otherwise be displayed, providing they had already passed evaluation?
I've only just realised after all this time that tile overflow cuts off the lowest indexed sprite instead of the highest. anomie_regs mentions it, but perhaps not as prominently as it should. I feel as though I've been working with a handicap by being unaware of that. With that scrap of information a lot of other things fall into place very easily. How frustrating.
Quote:
I have read that it uses a 256 pixel line buffer.
A line buffer sounds conceptually far more awkward than a series of counters. It seems something of a leap to diverge from established canon. Where have you read such things? Is it from a patent? Is there reasoning? Is it..convincing?
As to functionality, the only relevant part might be the behaviour of sprite to sprite priority which always favours the combination of index and width over presence.
Let's see.. We have our buffer of up to 34 tile rows, each with an associated X, palette and priority. For a line buffer it would be incredibly wasteful to have copies of any of that data, so we can't do that. A better way might be to work by index again. For each of the 256 slots, use the entry with [index].
That might work but there are caveats. Setting eight slots per fetch is perhaps odd but might work, and backwards fetching perhaps makes it all seem too convenient. A limit of 34 is a big concern for indexes since it's such an awkward number. The resulting 5 * 256 seems excessive. X=256 isn't explained away as nicely either.
I suppose it wouldn't matter much for an implementation if the end result is the same.
Is there a simpler model?