It seems Doom has a 1D, 2-state occlusion test. While there are areas where Doom simpler than BM (and might help simplify BM too), there are definitely some areas where BM looks a bit better. Had some other thoughts about BM/Doom comparisons. And even if this is the case I'm not sure if the behaviour is any different with the cache-inhibit flag - it could be the same :-z. But I'm less sure about this one - will need to revisit the manual.
Udmx doom code#
At the very least it should reduce the amount of code needed to do that sort of thing on a plain Falcon booted into TOS, and it's one more thing explored that I don't need to think about anymoreĪctually I seem to remember another rule about d-cache and writes - if WA is disabled and there is a write 'hit' the associated cache entry gets invalidated anyway, even if it isn't filled. However I'll finish poking around with the PMMU to see if there are any advantages to keeping it. This leaves only large texture pages used for scaled-up drawing - in which case no read-inhibiting is needed anyway. Possibly even put the smallest pages on the DSP. OTOH even this case may become redundant with mipmaps introduced - because there won't be nearly so much drawing using scaled down textures, and it will be possible to prelight (convert from 8 to 16bits with light level already rolled in) the small mip pages for direct drawing. This can probably also be done with prefetching and freezing - but with more code. It's nice to have the lighting table in the cache (source 2), but keep the texels (source 1) out of the cache in this case.
The shadowing *should* be useful for a few things in BM - the one that interests me most is wall drawing where there can be 2 memory sources and one destination per pixel (at least for large, non-prelit textures which also don't live on the DSP), and where one of the sources may 'skip' addresses frequently (textures scaled down). Yes that's right - I didn't expect any change with WA disabled, but hoped to get some use out of it with WA enabled always.Īnd yes, it should be possible to do most of the same stuff without the PMMU using CACR manipulation (perhaps less efficiently and with more code scattered around). So, in case you don't read content of video ram (and I guess you don't), you can skip all the fun with PMMU tree and disable the WA bit only Mikro wrote:Your thoughts about the write-allocate bit reminded me of one thing: When a data write causes a cache miss, the 68030 will act as if it has no data cache and write directly to memory (except in write-allocate mode).
0 kommentar(er)
