July 11, 2020, 01:27:33 pm

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

WARNING: DO NOT UPGRADE your TI-83 Premium CE or TI-84 Plus CE to OS 5.5.1 and higher. It removes all compatibility with most games and removes ASM/C programming! DOWNGRADING IS IMPOSSIBLE. BE WARNED! Likewise, do NOT update your TI-Nspire CX past OS 4.5.0, else using Ndless and ASM/C programs will be impossible.

[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 2 Guests 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. :)


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.


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


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


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)


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).


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.


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



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 )


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


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

Powered by EzPortal