About the undocumented Depth Buffer

[Weeppiko]

Some people made me aware that TIC-80 actually has a depth buffer (as shown in this cart: https://tic80.com/play?cart=3277). The question is why? There is no mention about it in the wiki, the ttri page only says about Z values being used for perspective correction, no mention about a depth buffer at all. It doesn't exists anywhere in RAM (afaik), and there is no API for it. This is again the same issue that OVR had before, it magically exists somewhere, somehow, without any explanation or control over it. You can't clear or disable the buffer, you can't directly read from or write to it.

I pretty much prefer to not have a depth buffer at all to keep the sense of a retro computer, but if it still desired to be there it should be done properly at least.

[Skeptim]

Concerning the wiki: The wiki is maintained by the community. It is not easy to keep it up-to-date, that is a lot of work. I hope I will have more time to spend on it next summer but I am not competent for the too technical part, like the depth buffer.

It will probably help others if you add a note to the wiki page(s) that are missing information, indicating what should be added.

[joshgoebel]

Could you please define depth buffer or give a code example? All I see here is a visual effect. There may be a depth buffer, but this animation doesn't prove that.

[Weeppiko]

@joshgoebel if you look into that cart's code and remove the Z arguments on ttri calls you will notice that the depth doesn't appear anymore (blue always appears on top, and it's back faces also shows up in front of it), so it is clearly tied to ttri, unless that cart do some black magic to change how ttri behaves without writing any code for that.

The code:

With depth:

Without depth (commenting out that args):

[nesbox]

@Weeppiko I agree, that the depth buffer is a little out of the retro computer concept; on the other hand, we want to do things easily and quickly without a huge setup and unnecessary actions, also it's a "fantasy" retro computer after all :) Also, the depth buffer can be controlled, it can be cleared using the cls() function https://github.com/nesbox/TIC-80/blob/main/src/core/draw.c#L397. Btw, as for OVR, it does not magically exist somewhere, it works using vbank switching vbank(0)/vbank(1) and you can write/read to them whenever you want.

[joshgoebel]

I'll vote with @Weeppiko here for whatever it's worth - we should avoid adding "magic" features that don't map back onto the defined memory/virtual hardware. In a perfect world one would be able to write a "pure" gfx lib where all the built-in functions could be re-created (just slower) by only reading/setting various memory locations.

I'm not saying the TIC-80 hardware spec needs to be static - far from it. But if we desire to add features we should start by talking about "how does the hardware do this", "how is this mapped into RAM" - not just throw it into the C codebase as if the hardware is magical.

[Skeptim]

I added mention of the depth buffer to the ttri page. Not sure what I wrote is clear enough for the wiki which should be accessible to beginners, but I don't understand it enough myself to add more details.

Also, there was a paragraph saying that it does not perform perspective correction. I removed this paragraph because I believe it is not true any more (commit https://github.com/nesbox/TIC-80/commit/747bd73d3ce30a496b222d4de31b09800c488fbf).

[joshgoebel]

I'm not sure I follow what this is saying:

The depth buffer uses vbank switching vbank(0)/vbank(1) into which you can write/read.

[Skeptim]

Oh indeed, I might have misunderstood what nesbox said. I think it's for OVR not the depth buffer.

Btw, as for OVR, it does not magically exist somewhere, it works using vbank switching vbank(0)/vbank(1) and you can write/read to them whenever you want.

Thanks for the proofreading!

I corrected it. Do not hesitate to modify what I did if something remains unclear.

[Skeptim]

I think this issue can be closed.

[Weeppiko]

The other concerns about it still there, the issue is not only about the wiki: The buffer is magic (exists somewhere completely hidden from the user); Tied only to ttri, when it could be actually useful for all the other drawing apis; Tied to the perspective correction arguments, where one may want to use the perspective correction without writing to the depth buffer.

A proper API for it should have a way to set how should a drawing process compare to the buffer, and whether it should write or not to it, as example:

-- usage: setdepth( compare, write )
setdepth('lequal',true)
ttri(...)
tri(...) -- if we add z args for it

-- for apis without z argument, we could add an extra arg:
-- setdepth( compare, write, write_value=0 )
setdepth('greater',true,5)
spr(...)
setdepth('greater',true,0)
spr(...)
-- which means sprite priority without the need to sort them

-- other combinations:
setdepth(nil,true) -- write without comparing
setdepth('less',false) -- compare, but doesn't write
setdepth() -- disables it entirely

These are just thoughts, don't take it as a real suggestion. And I know that it is supposed to be easy to use and work with 3D, but the way it currently is not ideal and might break expectations about how ttri works, considering a hidden depth buffer will take effect without the user being aware or in control of it. But honestly, I still inclined to not have the buffer to exist at all.

[joshgoebel]

The buffer is magic (exists somewhere completely hidden from the user);

It's not, it's addressable in VRAM as mentioned earlier.

[Weeppiko]

@joshgoebel what? Where? I'm talking about the depth buffer, I would expect it to be larger than the entire VRAM, how could it be addressable there?

[joshgoebel]

Oh I was quoting nesbox but I think he was talking about OVR... sorry, I'm not even sure I'm following what this whole depth buffer thing is.