155 reputation
214
bio website
location
age
visits member for 4 years, 11 months
seen Jun 10 at 19:16

May
23
comment Using full resolution of depth buffer for 2D rendering
No, they wouldn't - by the time you get close to the far plane the Z resolution has dropped a lot, and the fixed increment will be less than the Z resolution, meaning lots of values end up with the same Z buffer value. @Panda Pajama posted the correct formula that shows why this is.
May
22
accepted Using full resolution of depth buffer for 2D rendering
May
22
comment Using full resolution of depth buffer for 2D rendering
@MattEsch: FWIW this is aimed at Intel integrated GPUs, which use system memory instead of dedicated GPU memory. This makes them pretty slow and liable to hitting fill-rate limits if overdrawing a lot of sprites. Intel recommended this approach to me as a way of working around it. Presumably their implementation of depth testing is well optimised and can save lots of fill-rate. It remains to be seen though, I haven't profiled it yet!
May
22
comment Using full resolution of depth buffer for 2D rendering
Ah, I see. Thanks for the answer, it's working nicely!
May
22
awarded  Commentator
May
22
comment Using full resolution of depth buffer for 2D rendering
Thanks for the answer! I'm a little confused how you got your final formula though. If I take z_buffer_value = k * (a + (b / z)) and simply rearrange to solve for z, then I get: z = b / ((z_buffer_value / k) - a) - how did you arrive at the different last formula?
May
22
comment Using full resolution of depth buffer for 2D rendering
Sorry, this isn't right - the Z buffer values are calculated non-linearly, so using a fixed increment will not use the full resolution of the depth buffer.
May
21
comment Using full resolution of depth buffer for 2D rendering
Sorry, that's not much help. I am already doing that. The question is about what Z positions to choose.
May
19
asked Using full resolution of depth buffer for 2D rendering
Dec
16
awarded  Popular Question
May
24
awarded  Scholar
May
24
comment Seamless tilemap rendering (borderless adjacent images)
OOh, thanks - the wrapping around the texture does explain it. I'll look in to those solutions!
May
24
accepted Seamless tilemap rendering (borderless adjacent images)
May
22
comment Seamless tilemap rendering (borderless adjacent images)
I don't think this will work well for us. It sounds like you're proposing that at 10% zoom we render an area 10 times bigger. This does not bode well for devices with limited fill rate. Also I'm still mystified why specifically GL_REPEAT only causes seams, and no other mode does. How could that be?
May
22
awarded  Nice Question
May
21
comment Seamless tilemap rendering (borderless adjacent images)
Thanks, but as I already noted the geometry is definitely exactly adjacent - in fact all the co-ordinates result in exact integers, so it's easy to tell. No atlases are used here.
May
20
revised Seamless tilemap rendering (borderless adjacent images)
added 143 characters in body
May
20
revised Seamless tilemap rendering (borderless adjacent images)
added 296 characters in body
May
20
revised Seamless tilemap rendering (borderless adjacent images)
added 296 characters in body
May
20
comment Seamless tilemap rendering (borderless adjacent images)
I already mentioned I tried GL_NEAREST (aka point filtering), and it doesn't fix it. I can't do #2 because I need to support NPOT devices.