Seems pretty good 
I like the shark :p

Filling still doesn't work great with my current update. I have to fix it  , and it always have been slooow.
However, if I display 8 standard cubes (wired), the speed is 7.4 fps (96 lines, 64 vertices)
 

No eyes candies for the moment, but I've just run speed test.
 
Clock Speed : 6 MHz
VBO : No VBO active
 VERTICES     MAX      AVERAGE
1024 vertices   1.2 fps      1 fps
512 vertices     2.5 fps      2 fps
256 vertices     4.5 fps      4 fps
128 vertices     9 fps         8 fps
64 vertices       17 fps       15 fps
32 vertices       27 fps       25.5 fps
16 vertices       45.4 fps    41 fps
8 vertices         64 fps       60 fps
 
64 vertices are perfectly possible for real time 

that wasn't the main goal, but life timer and random mouvements have made it yeah 

Buy a time machine.

There is no time machine in sell.

Bon je sais pas si ça va vraiment résoudre le bug, mais voici l'axiom qui met fullscrndraw à 1  

Le token pour acceder à la commande est Boxplot.
Je vous donne aussi la source :

#include "ti83plus.inc"
#include "axe.inc"

.dw $C0DE

.dw _CmdEnd
.db AXM_NONAPP
.db 5, 0
.db 0
.db 0
.org 0

set fullscrndraw, (iy+apiflg4)
_CmdEnd:

.dw $0000

.db 10, 0
.db 11
.db "DispLetters"

sinon, bon travail pour cette version 

Soooo....  Because I have redesigned the GCORE system, the polygon gestion is kindy outdated. Methods I used *won't* work well with all the new stuffs. So I've just put in place a all new pipeline. Of course, it's kindy the ultimate pipeline to reach (if I ever do that, GLib will be finished and totally awesome, if I can say so  ), and some functionnality could get remove.

GLIB PIPELINE VER 2.0 omega

*PRE-PROCESSED*
1.Lightning processing
   1.Process a per-vertex based on light type and strenght
   2.Multiple pass, many as lights defined

*MAIN*
*USER CONTROL**call GUpdateVBO()*
2.Vertex Processing:
   1.Each vertex is acted upon by a Vertex Shader. Each vertex in the active VBO is processed. (turned into a point coordinate)

*USER CONTROL**call GPrimitive()*
3.Optional Geometry Shader primitive processing. The output is one or more primitives. Geometry shader function is always used to return from drawing
4.Primitive Clipping.
5.Scan conversion and primitive parameter interpolation, which generates a number of fragments.
   [1.Textures coordinates are interpolated if texturing is set. Use a common data set.]
   [2.Light intensity is interpolated if light is set. Use extra per-vertex informations.]
   [3.Depht is interpolated using VBO informations.]
6.A Fragment Shader processes each fragment. Each fragment generates a number of outputs.
7.Per-Sample_Processing:
   [1.Stencil Test]
   [2.Depth Test]
   [3.Occlusion query updating]
   4.Blending


Fragment sub structure:
-GDepht
-GFragX
-GFragY
-8 colors between 0-16   (0 is white,16 is black)
GFragX is multiple of 8.


Vertex sub structure:
-GVertexX
-GVertexY
-GVertexZ
-GScreenX
-GScreenY

Primitive sub structure:
-°TYPE
-VBO's id of vertex1
-VBO's id of vertex2
...

[] is modifiable options (set by extra functions)

So, what do you think about it ?