Email or username:

Password:

Forgot your password?
Joshua's posts Post Back to profile
Top-level
Joshua Barretto

@smochi I'm familiar with the general approach, it's more an issue of micro-optimising. I'm on a very resource-constrained platform, so every little trick helps. I'm mostly interested in ways to cut down on unnecessary interpolation steps (i.e: because another plane will clip the interpolated section anyway)

28 May at 8:11 | Open on social.coop
6 comments
Räucherkäse

@jsbarretto Are you using a Z buffer? It won't avoid geometry processing, but will at least eliminate overdraw of occluded surfaces.

28 May at 10:00 | Open on sakurajima.moe
Joshua Barretto

@smochi Sadly not! Not enough fast memory for a z buffer (nor grunt for computing per-pixel z). A coverage buffer + presorting is the best I've got.

28 May at 10:25 | Open on social.coop
Räucherkäse

@jsbarretto Ok, that explains why you're so afraid of overdraw. :blobfoxlaughsweat:

Here's a few more ideas that you could try:
* Avoid intersecting triangles. This should be easier if you don't need intersecting geometry in the first place. Use bounding boxes or some other simple algorithm to avoid collisions between objects, and make sure none of your objects are self-intersecting.
* If you're not doing that already, cull back faces of closed objects. There's a standard algorithm that works with vertex order to determine which side is "inside", or you could use face normals.

Keep in mind that extensive geometry processing may be expensive too, so doing too much or using an inefficient algorithm could be worse than a bit of overdraw. Since you talk about performance issues with z buffering, I'm wondering if geometry processing on the CPU + transfer to vmem on every frame isn't gonna hurt more anyway? Then again, I don't know your target platform and how much vertex data you have.

@jsbarretto Ok, that explains why you're so afraid of overdraw. :blobfoxlaughsweat:

Here's a few more ideas that you could try:
* Avoid intersecting triangles. This should be easier if you don't need intersecting geometry in the first place. Use bounding boxes or some other simple algorithm to avoid collisions between objects, and make sure none of your objects are self-intersecting.
* If you're not doing that already, cull back faces of closed objects. There's a standard algorithm that works with...

28 May at 13:17 | Open on sakurajima.moe
Joshua Barretto

@smochi All being done, thankfully. My target platform is the Gameboy Advance: everything is being rasterised in software using fixed point ( the GBA has no GPU nor support for floating point). If you're curious: youtu.be/RDrjsrKmeOs

I do think I'm rapidly getting into diminishing returns at this point. I'm down to optimising things down to the instruction level (and below) in many of the inner loops. Over the past few days I rewrote the clipper & it now seems to no longer be the bottleneck.

28 May at 18:30 | Open on social.coop
Räucherkäse

@jsbarretto Heh, that's pretty cool! Reminds me of PSX graphics, particularly FF9. They also had very limited precision, which led to slight distortion when objects were being rotated.
FF9 didn't have stitching issues though, as far as I can remember. Maybe that's something you can still improve with a better coverage algorithm?

28 May at 21:58 | Open on sakurajima.moe
Joshua Barretto

@smochi I've actually improved a lot of that distortion recently as a result of revising the clipping code, but I've not yet posted an update.

29 May at 5:30 | Open on social.coop
Go Up