May 26, 2020, 11:47:28 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 programming!


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


September 13, 2017, 11:56:46 pm #480 Last Edit: September 14, 2017, 12:03:24 am by tr1p1ea
A SM64 level test would be great - but there could be an issue with N64 levels/models due to the size of polygon size and the lack of perspective correct texture mapping is all. You can see how affine texture mapping causes distortion when close to the camera and at angles and such. The PS1 got around this by not using large textured polygons - instead breaking them up into smaller ones to combat this. That being said, a game of that level of visual complexity is not really a realistic target if you want a playable framerate. BUT through some clever level optimization and thinking ... maybe it could be possible to an extent?!!!

If anyone can do it, it's TM02 :).


September 14, 2017, 09:31:24 am #481 Last Edit: September 14, 2017, 11:55:13 am by TheMachine02
A second issue may arise, that is the N64 use a lot of repeating texture. And my engine doesn't support texture repeating at boundary. The fix is quite simple ; and fall in the same categorie of the issue discuted by tr1p1ea, break large polygons into smaller one. For the visual complexity of the game, well I must said that the previous screenshot doesn't include ANY way of doing thing proprely, it just send all polygons through the library (and vertex as well), which is, well, a bad way to do thing :P One of the primary optimization one can do in such context is bounding boxes, test a whole sub level part against frustrum with 8 vertices et skip it enterily if it is outside. Given that the library can handle different stream of polygons/vertex from different location and doesn't expect only one consecutive stream, this is a very interesting thing to do. Second optimization that may be doable is to reduce the far plan visibility, ie how far can you see polygons. PS1 used this technique very often, using some fog. We won't be able to do fog here, but it is still a good thin to have given that depth is computed for sorting anyway. Third reside in library optimization itself, which aren't at all done :P
As a side note, I need to also said that the current pipeline must process all vertex (this is mandatory due to clippping). So removing some vertex through the bounding boxes is even a better idea than before (2000 vertex process in the last screenshot IS heavy, at about 90ms).

Just to give you an idea, through code refactoring color glib is almost 400% faster than early version - and it is mostly through new algorithm / better pathway, not much from code micro-optimisation, apart from the texture mapping routine, in which I've already put a lot of work. So given the opportunity, (and mostly because two of the three optimization ins't glib work, but instead more of the user work, and I don't use my library well  :P ), the complexity may be pretty high. I also may start to do a more advanced use of the library for following demo because well I want more speed obviously.

To finish, well if one have the level, I can simply convert it and load it up in the engine  :)

EDIT : huh, I forgot to include last eye-candy, shame of me  :P

EDIT 2 : well I said that bounding should be user made, that is not totally true, as I could also make it mandatory, but I fear I may lose in flexibility. What do you think ?


Well the engine is already amazingly fast, I feel that making 3D models and levels SPECIFICALLY with the calc in mind could yield good results.



Sure thing. Those level are end of life PSX quality grade, so don't wonder why there a bit heavy for the calc  :P Even considering the fact I have no (or limited vs PS1) lightning, the simple fact that it run *only* 8x slower (30fps vs 4-3fps) make me happy  :D (since the ez80 definitly doesn't have PSX hardware  :P )

DJ Omnimaga

Did the PS1 have a graphics card? I forgot, but this can play a big role in graphical performances


It has a dedicated GPU with 1Mb of VRAM indeed, which was quite efficient (well, for the time). It only supported linear mapping though. So yeah, pretty good  :P


I have a render request.

You should come up with a gLib logo, with a lot of poly, and use it as a benchmark.

I also want to see a render of a CE rendering a CE.
Please spam here:

"walruses are better than tuxedo chickens, all hail the great :walrii:" ~ me
Evolution of my avatar:

DJ Omnimaga

Quote from: TheMachine02 on September 16, 2017, 12:52:51 pm
It has a dedicated GPU with 1Mb of VRAM indeed, which was quite efficient (well, for the time). It only supported linear mapping though. So yeah, pretty good  :P
That's impressive. I assume it also supported minimal shading?


It did supported some advanced stuff for the time, mainly gouraud shading along side with texture. Filtering was pretty minimal though, vs the N64 for example, but it has plenty of RAM.

Anyway, I started to implement bounding box, as they are finally quite easy to make them working in the pipeline, and hopefully should improve performance quite a bit  :P


sooo full support for my 4k VR Pr0n estimated by the end of next week?  ;)

seriously man, what you're doing there is magic  :thumbsup:
Also it'd be great to see a comparison of speed, like re-rendering one of the old demos with the current state of ur program so we can see the actual difference ^^
Guess then it'd probably be even more impressive than the more and more complex models (that are impressive enough already) ;D
Anyway war sucks. Just bring us your food instead of missiles  :P ~ DJ Omnimaga (11.10.2016 20:21:48)
if you cant get a jframe set up, draw stuff to it, and receive input, i can only imagine how horrible your game code is _._   ~ c4ooo (14.11.2016 22:44:07)
If they pull a Harambe on me tell my family I love them ~ u/Pwntear37d (AssangeWatch /r/)
make Walrii great again ~ DJ Omnimaga (28.11.2016 23:01:31)
God invented the pc, satan the smartphone I guess ~ p4nix (16.02.2017 22:51:49)


Yeah I really should indeed. There wont be much improvement to flat filling though - havent touch the routine in ages - but texturing is an order of magnitude faster now.
I need to grab an old demo with some timing though to measure exactly the improvement. Maybe midna with the skybox ? (I need to see if I can fit texture in now caise the slybox I used was pretty huge, and I hard limited texture to 256x256)


September 25, 2017, 09:08:24 pm #491 Last Edit: September 25, 2017, 09:14:16 pm by tr1p1ea
Cool indeed!

Do I remember correctly that you said you had 'texture read + write + pointer updates (buffer+texture)' down to 7cc per pixel?!

If so no wonder it's so fast!


The 7cc is for flat shading, it is just a ldir. Texturing come at about 26cc for unlighted, 32cc for lighted.


September 26, 2017, 10:21:49 am #493 Last Edit: September 26, 2017, 10:23:21 am by tr1p1ea
Okay well that makes more sense lol, amazing fast work man!

This is taking wait states into account?

(*shakes fist at wait states!*)

Any further updates?


<sarcasm> i heard modern RAM has wait states of a couple dozen nanoseconds, you should upgrade! </sarcasm>

Anyways, great job on the renderer. Now i just want to see a playable game use this :D

Powered by EzPortal