The shoutbox is currently out of service. Join us on Discord instead.
You can help CodeWalrus stay online by donating here.

[gLib][3d][z80][ez80] gLib a fast 3D asm/axiom library

Started by TheMachine02, January 19, 2015, 05:10:01 pm

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DJ Omnimaga

Quote from: TheMachine02 on June 09, 2016, 07:27:07 pm
Wasn't tested, but given the model I found on the net (36 vertices, 52 faces), it is quite fast :


(512 frames for one turn)

EDIT : and yeah, it broke z-sorting too.
Would there be a way to make z-sorting work with every type of model? Also this looks kinda nice despite the glitches. :)

TheMachine02

Well, I don't know. Z-sorting wasn't ever meant to be 100% correct (with the exeception of much more complicated algorithm...). I'll try something else than Z-average.

DJ Omnimaga

Oh ok, I thought it was just compatibility-related, as in a different model format or something.

ben_g

Basically, the only way to do it correctly in any case is Z-buffering instead of Z-ordering, because you can't correctly render special cases like intersecting triangles or cyclic overlap by just changing the drawing order.

DJ Omnimaga


ben_g

It depends on the polygon count. If there are a lot of polygons, it will be faster. It requires a ton of memory though.

TheMachine02

I am pretty sure it would be a magnitude slower, because we'll need to interpolate the Z value inside the rasterizer loop - which is kinda bad - and we'll alos need an other 320x240 buffer (and with a width of 16bits min, cause precision = 156KB = all the RAM we have). So, no, it isn't a good idea  :P

EDIT : the correct way with z-sorting  would be to slipt the triangles which might overlapse, and it is a slow process. (and sort with zmin/zmax of every triangles)

tr1p1ea

Yeah z-buffering (or s-buffering) is the real way to handle things but too memory intensive. I'm sure there are some other ways to achieve this but perhaps a different model could help? (ie; keep intersecting polygons in mind when modeling).

rwill

If your model is static, you want good sorting, cannot afford a Z-Buffer, and can live with
a higher polygon count you might want to apply Binary Space Partitioning to a model and
render accordingly.

But really, the way to go is to keep sorting problems in mind when creating the model,
maybe making manual splits of large polygons and keep parts of the model kind of convex.
I remember that a lot of the first 3D Games had sorting problems.

You really should apply backface culling.

TheMachine02

yeah, backface culling is a must. It almost implemented though  :P BSP however might be a bit overkill.

tr1p1ea


grosged

Quote from: TheMachine02 on June 10, 2016, 01:05:08 pm
Yeah <_<. This is about 76800 bytes to clear at 7 TStates/bytes. (Actually it is more 540000TStates)

I recommend you the "Push" method  ! only 258 832 States :thumbsup:
( https://codewalr.us/index.php?topic=1395.msg40164#msg40164 )

TheMachine02

Quote from: tr1p1ea on June 12, 2016, 04:46:34 am
Did you decide to go with proper bfc or quick bfc?

Not really decided for the moment, quick bfc seems enough, but proper bfc is nice thing to have  <_<. Proper bfc come with quite a huge cost though (since the polygon/eye vector need to be reduced).

And yeah the fast clear screen might find is way to the lib, one day  :P

DJ Omnimaga

* DJ Omnimaga wonders how a 3D Reuben would look like

TheMachine02


Rough lightning and backface culling  :P  (this screen is 256 frames/turn)

Powered by EzPortal