Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: TheMachine02 on October 10, 2012, 09:13:11 am

Title: Glib : a 3D graphics axe library
Post by: TheMachine02 on October 10, 2012, 09:13:11 am
hello everyone.

I would like to present a new axe librairy I devellope for my game NEMESIS.

The main goal of it is to create real-time 3D environnements, and this even at 6MHz
It is always in developpement, so you can wait new updates  :P

enjoy


LAST UPDATE : http://www.omnimaga.org/ti-z80-calculator-projects/glib-a-graphics-axe-3d-librairy/msg383996/#msg383996
TUTO : http://www.omnimaga.org/ti-z80-calculator-projects/(axe)-glib-tuto/ (http://www.omnimaga.org/ti-z80-calculator-projects/(axe)-glib-tuto/)

lot of things have change ... make sure to read the topic =)

What is implement so far:
-texture    (but outdated)
-rotation/projection
-perfect 3D cliping
-vertex/pixel/geometry shader (!!!)
-polygon drawing

TODO
-light
-backface culling
-implementation of texture shader and precalculated normal, binormal and tangent
-polygon sorting
-reimplement proprely polygons drawing and pixel/geomety shader
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on October 10, 2012, 03:19:40 pm
What are the controls?
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on October 11, 2012, 09:04:29 pm
The arrows move around, i think it starts out where you cant see a wall, but moving around (turning right i think) and you can see it.

Very nice work TheMachine02!
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on October 12, 2012, 01:26:55 am
One quick thing: You should have the lines for the tops and bottoms draw even when one of the vertexes it connects to isn't visible. If one of them is there, it should draw.

Oh, and it's not really 3D... :P Raycasting is the word, but it's pretty fast.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on October 15, 2012, 06:31:23 am
Oh, and it's not really 3D... :P Raycasting is the word, but it's pretty fast.

well... it's not real 3d, but it's not raycasting to...
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on October 15, 2012, 08:32:16 pm
wow, this is sounding far to awesome!
hopefully with this a lot more new 3d games will be made :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on October 16, 2012, 11:11:40 am
I hope so.  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on October 25, 2012, 03:50:18 am
hey fire work !!   ;D

else, I have little probleme with a scaling spirite routine that allow scale something like that

 
 /!
/ !
--

-> the side of the surface doesn't need to be vertical or horizontal

->it's very buggy, and I am not sure of the algorithm....

if anyone have a little idea to do this , it's will be really helpful !  :)
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on October 26, 2012, 04:35:44 pm
You should probably ask in the proper sub-forum, else fewer people will find your question.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 12, 2012, 06:41:45 am
You should probably ask in the proper sub-forum, else fewer people will find your question.

it's true.

Update :
-fire
-new polygones
-a first screen
-buggy clip line
-more Z precision


Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on November 12, 2012, 01:52:21 pm
The fire looks cool, but the engine itself looks a bit slow. Is the screenshot taken at 8 or 15 MHz and does it slow down a lot when adding more polygons and game mechanics?

Also, I like the splash screen.

And:
else, I have little probleme with a scaling spirite routine that allow scale something like that
 
 /!
/ !
--

-> the side of the surface doesn't need to be vertical or horizontal

->it's very buggy, and I am not sure of the algorithm....

if anyone have a little idea to do this , it's will be really helpful !  :)
If you mean textures by that, I have some code lying around, but it's in asm. But I can give you the algorithm if you want too.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2012, 11:28:56 am
Also, I like the splash screen.

thank you.

The fire looks cool, but the engine itself looks a bit slow. Is the screenshot taken at 8 or 15 MHz and does it slow down a lot when adding more polygons and game mechanics?
the screenshot still in 6MHz and in the principal loop I have put a pause 200;
for the walls, if walls are very close and all visible, yes it will slow, but if walls are distants, then it will not slow down.
I don't extensively test the fire (he is not totally finish), but I think it's little slow routine (so I will try to speed up it).

If you mean textures by that, I have some code lying around, but it's in asm. But I can give you the algorithm if you want too.

yes it's texture. If you can give me the algorithm it's will be great and really helpfull. :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on November 13, 2012, 02:28:06 pm
I actually think that at 15 MHz the rotation speed might have to be slowed down lol. Also you got animated graphics?? O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on November 13, 2012, 02:40:33 pm
I already explained it earlyer by PM too someone else. I hope you don't mind that I basically just copy-paste it here.

Quote from: PM
The most frequentely used shape for mapping textures is a triangle, so first off all, we are going to need a triangle drawing routine. For that, we need the points. We'll define point1 as (x1, y1, u1, v1), point 2 as (x2, y2, u2, v2) and point3 as (x3,y3,u3,v3). The u's and v's represent texture coordinates. We don't really need then yet, but implementing them now will make things easyer later on. The variables are all integers, preferably 8-bit.

We are going to draw the triangle using a horizontal scanline than moves down. To do this, we first need to sort the three points based on their Y coordinate, from smallest to largest. You can do that like this: (pseudocode)
Code: [Select]
if(Y1>Y2){
  exchange X1 and X2
  exchange Y1 and Y2
  exchange u1 and u2
  exchange v1 and v2
}
if(Y2>Y3){
  exchange X2 and X3
  exchange Y2 and Y3
  exchange u2 and u3
  exchange v2 and v3
}
if(Y1>Y3){
  exchange X1 and X3
  exchange Y1 and Y3
  exchange u1 and u3
  exchange v1 and v3
}
Now the points are sorted. Before we start drawing, we need to calculate some values. Similar calculations will have to be done with the texture coordinates, but we'll leave those for later. For these calculations, you need at least 8.8 fixed point numbers. Higher accuracy might be needed if you're drawing big textured surfaces which are for a large part outside of the screen. When it will be almost fully inside the screen, 8.8 should be fine.

Code: [Select]
du1 = (x2-x1)/(y2-y1)
du2 = (x3-x1)/(y3-y1)
du3 = (x3-x2)/(y3-y2)
These values represent the angle of the edges of the triangle. This is used to check how our scanline should change when we move a row down.
Before we start the drawing loop, there are still 4 more variables to initialize: tx, tx1, tx2 and ty.tx1 and tx2 are the x of the start and end of the scanline. They are fixed-point variables, to keep it reasonably accurate. ty and tx are integer values. ty represents the Y of a scanline, tx represents the x of the pixel we're drawing in the scanline. We'll initialize those the following way:
Code: [Select]
tx1=tx2=x1
ty=y1

Now, we can finally start with the drawing loop:
Code: [Select]

Drawn = 0

DrawingLoop:
while (ty < y2){
  //draw the scanline
  //to see if the rest is working, you can use axe's built-in line drawing routine, to see if the rest is working. Replace the code below this line by Line(tx1,ty,tx2,ty)
  tx = min(tx1,tx2) //only take integer part, or round.
  while (tx<=max(tx1,tx2)){
    SetPixel(tx,ty)
    tx += 1
  }
  //the code below this line is important even if you have used axe's line drawing routine
  tx1 += dx1
  tx2 += dx2
}

if(drawn == 0){
  y2 = y3
  dx2 = dx3
  drawn = 1
  goto DrawingLoop
}
Now you should have a working triangle drawing routine. If the triangle looks weird, try exchanging some dx variables. If it draws nothing at all, or fills the entire screen or gets stuck in an infinite loop, check if the points are ordered well. When you got it to work, don't forget to change the Line( instruction by the pixel-by-pixel scanline drawing code. You'll need this for the textures.

To draw the textures, we need some additional variables for the texture coordinates. Those are calculated very simular to the variables to change the x-position for every scanline.

We'll start by adding something to this code:
Code: [Select]
du1 = (x2-x1)/(y2-y1)
du2 = (x3-x1)/(y3-y1)
du3 = (x3-x2)/(y3-y2)

I just noticed I made a mistake yesterday. The du's should be renamed into dx's. Then we'll add similar code with u's and v's instaed of x's. So the code will become this:
Code: [Select]
dx1 = (x2-x1)/(y2-y1)
dx2 = (x3-x1)/(y3-y1)
dx3 = (x3-x2)/(y3-y2)

du1 = (u2-u1)/(y2-y1)
du2 = (u3-u1)/(y3-y1)
du3 = (u3-u2)/(y3-y2)

dv1 = (v2-v1)/(y2-y1)
dv2 = (v3-v1)/(y3-y1)
dv3 = (v3-v2)/(y3-y2)

The du's and dv's stand for differences in texture coordinates.
Behind that code, there was this:
Code: [Select]
tx1=tx2=x1
ty=y1

Now, we'll add the texture coordinates to it:
Code: [Select]
tx1=tx2=x1
tu1=tu2=u1
tv1=tv2=v1

ty=y1

The rest of the code is a bit different, but it shouldn't be too hard to implement in your program
Code: [Select]
Drawn = 0

DrawingLoop:
while (ty < y2){
  //initialize some variables for the texture
  if(tx1<tx2){
    tdu=(tu2-tu1)/(tx2-tx1)
    tdv=(tv2-tv1)/(tx2-tx1)
    tu=tu1
    tv=tv1  //unlike tx and ty, tu and tv are fixed-point variables
  } else {
    tdu=(tu1-tu2)/(tx1-tx2)
    tdv=(tv1-tv2)/(tx1-tx2)
    tu=tu2
    tv=tv2  //unlike tx and ty, tu and tv are fixed-point variables
  }
  //draw the scanline
  while (tx<=max(tx1,tx2)){
    #if(8x8_texture) //whit this, I mean that you have to shoose between 8x8 and 16x16 for textures. Don't actually code it as an if.
      if(bit(round(tu),(Texture+round(tv))){
        setPixel(tx,ty)
      }else{
        resPixel(tx,ty)     //res means white, set means black
      }
    #else if(16by16_Texture)
      if(bit16(round(tu),(round(tv)*2+Texture)){  //IMPORTANT: use a 16-bit bit checking instruction (make it yourself if you're programming in asm)
        setPixel(tx,ty)
      }else{
        resPixel(tx,ty)
      }
    tx += 1

    tu += tdu
    tv += tdv
  }
  tx1 += dx1
  tx2 += dx2
}

if(drawn == 0){
  y2 = y3
  u2=u3
  v2=v3
  dx2 = dx3
  du2=du3
  dv2=dv3
  drawn = 1
  goto DrawingLoop
}

If you need help with this, just ask.
Title: Re: GLIB a graphics axe 3d librairy
Post by: squidgetx on November 13, 2012, 04:15:30 pm
Lol, that looks familiar, ben_g

TheMachine, is it possible to increase the amount of precision when moving? It seems that the camera 'jumps' a lot :(
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 14, 2012, 10:21:07 am
thank you a lot for the algorithm !

TheMachine, is it possible to increase the amount of precision when moving? It seems that the camera 'jumps' a lot :(

yes, this is easy it's just a number to change. (for the moment he add 16 for the angle, I can change it to 8)

Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 08, 2013, 06:21:01 am
a LOT of update !!!

it's now real 3d  :o  (using rotation and projection).

it's really fast, more than the last thing I use for 3d (using a LUT, still at 6MgHz,13 vertices);
and thanks to ben_g's algorithm, I was able to do a routine to fill a triangle (but this is a lot more slow  :P )(maybe decrease the precision is the solution...)

here the test prog and the commands
-rotation y axis [<-],[->]
-rotation x axis [del], [mode]
-zoom/dezoom [F1],[F5]
-up/down [F2],[F4]
-go forward/ [up],[down]
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on January 08, 2013, 06:57:13 am
It still bothers me that you don't draw lines to offscreen vertexes, even if the other is on screen.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Keoni29 on January 08, 2013, 07:33:18 am
Will this result in playable games any time soon? Or will it be too slow?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 08, 2013, 11:51:26 am
It still bothers me that you don't draw lines to offscreen vertexes, even if the other is on screen.

that the axe line routine and I'm too lazy to do one...

I prefer concentrate on speed, ligthning, and texture.

Will this result in playable games any time soon? Or will it be too slow?
for the moment, many thing can be optimised, but the speed allow me to try to make a demo of my 3d game Nemesis. I don't think I will finish this soon but you can be sure that I will finish it.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on January 08, 2013, 08:33:04 pm
That are some nice updates! I like the speed :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on January 08, 2013, 10:46:41 pm
Just wondering what method you are using to store your rotations for each object? Euler angles? And will this be a full 6-dof engine? (like walking around engine or flight-sim?).

Also cohen-sutherland is a pretty straight-forward method for clipping lines if you're interested.

Either way it looks nice and fast! Great work :).
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on January 09, 2013, 01:55:27 am
Glad this is still alive. Still hoping that you finish your game too :)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 09, 2013, 09:19:21 am
Glad this is still alive. Still hoping that you finish your game too :)
thanks. I know I could do the demo  :P but for the whole game maybe I will need some help (like spirite or creating the vertices of the world...)

Just wondering what method you are using to store your rotations for each object? Euler angles?
yes, I use it. In fact I store rotation for all the world, and when I render, I use pos cam and the angle to rotate each vertex, and then disp on screen using projection. that easy and fast  :)

And will this be a full 6-dof engine? (like walking around engine or flight-sim?).

errrrr.... ??? what is 6-dof engine ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 09, 2013, 09:49:44 am
will this work with AXE? It's a really cool library!

Edit: It IS an AXE library, my bad!

Edit2: how do I use this in my program? (How to use as library?)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 09, 2013, 10:57:40 am
for the moment, I didn't upload the last version ; but when I've done that,you download it and add at the begin of the programme

Code: [Select]
.GTEST
prgmGLIB
...
your code here
...

and you can use the function provide by the library. (describe in the readme)
(all of this make me thought that I must post the file  ;D ; but many function is not finish)
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 09, 2013, 02:16:52 pm
I'm talking syntax and what do the functions do... I know how to USE the library, just not how to program with it.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on January 09, 2013, 03:34:24 pm
Sorry when i say 6-dof i meant '6-degrees of freedom' as in you can reliably move in all directions in 3d space.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 10, 2013, 11:06:10 am
Sorry when i say 6-dof i meant '6-degrees of freedom' as in you can reliably move in all directions in 3d space.
ok. Basically I can do it but I haven't implemented this yet.

I'm talking syntax and what do the functions do... I know how to USE the library, just not how to program with it.
And here we are. The new library.

There is 4 important function.
GpGet() : handle the getkey
arguments : none
return : none

-rotation y axis [<-],[->]
-rotation x axis [del], [mode]
-zoom/dezoom [F1],[F5]
-up/down [F2],[F4]
-go forward/ [up],[down]

GpBegin(FLAG) : init the declaration of vertices
arguments : FLAG
choose between
GPQUADRI : the next vertices will be traited as an rectangle (need 4*nb poly vertices)
GPTRIANGLE : " as a triangle     (need 3*nb poly vertices)
return : none

GpVertex(X,Z,Y) : define a vertex
arguments : the position of the vertex
return : none

GpEnd() : finish the declaration of vertices and draw with black shape (you will can change this in the future)
if the number of the vertices is not good compare with the FLAG, return directly without drawing anything
arguments : none
return : none

If you look at the librairy, you will see many other functions. (GpRotated, GpPerpective,GpFace)
there are useless for the moment, so please don't use them !

The librairy use L1, compilated it does 4507 octets (big I know, but I am working on) and use pic1.

must use with axe 1.2.1a, (do to the 13 characters long and #ExprOn)

here an example prog :

Code: [Select]
.TEST
prgmGPLIB
While 1
GpBegin(GPTRIANGLE)
GpVertex(0,-10,0
GpVertex(0,10,0
GpVertex(20,10,0

GpVertex(20,-10,0
GpVertex(20,10,0
GpVertex(0,-10,0

GpEnd()

DispgraphClrDraw
Repeat getkey(0)
End
GpGet()
EndIf getkey(15)
Return

(I know this is slow but it's in 6MgHz  ;D)
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 10, 2013, 12:51:59 pm
Awesome!!!

Thanks for the help and the update!
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on January 22, 2013, 04:19:31 pm
Gave it a test and it runs really nice so far!
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 24, 2013, 03:23:14 am
thank you a lot !

by searching on net some algorithms to create illusion of sorted polygons, I found the usually z-buffer but it's seems that there is a lot better algorithms for speed : s-buffer (and it look like it's work with line of polygones, exactly the way I render them)
the problem is that I don't really understand how it's work (maybe my english level is too slow  ;D)

Yet, I think I found a good tuto :http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/s-buffer-faq-r668 (http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/s-buffer-faq-r668)

so if anyone can help me ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 24, 2013, 10:06:19 am
Hey, what version of AXE do you use to compile this? I'm using 1.2.1a, and I'm getting black screens at different locations.
Title: Re: GLIB a graphics axe 3d librairy
Post by: squidgetx on January 24, 2013, 10:33:36 am
Pretty impressive work so far TheMachine :D Looking forward to some more implementations of other textures and clipping
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on January 24, 2013, 03:20:14 pm
Im not sure the calc has enough memory to constitute a z-buffer or s-buffer. The way i usually do it is to sort each polygon by average z-value if that helps.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 25, 2013, 12:10:28 pm
Hey, what version of AXE do you use to compile this? I'm using 1.2.1a, and I'm getting black screens at different locations.

it's axe 1.2.1a. That strange you have black screen (can I see a screenshot please ?)
(errr.... don't forget that the plolygones are render with black shapes...)

Im not sure the calc has enough memory to constitute a z-buffer or s-buffer. The way i usually do it is to sort each polygon by average z-value if that helps.
The big problems of this methode I haven't succed to create a fast sort routine ; and because I just can't sort it by the way I render things.
That's why I was looking for something else.
(and as I have understand of s-buffer, it's not taken so memory (but maybe I'm wrong))
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 25, 2013, 02:32:40 pm
This Happens when I turn right (just one triangle supposed to be on the screen):

A black bar appears randomly!
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on January 25, 2013, 05:32:11 pm
That's all good, its just because he hasn't finished the clipping on the triangle routine yet.
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 25, 2013, 05:38:12 pm
It happens when there is a quadrilateral, too
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on January 25, 2013, 06:22:54 pm
Yeah, it seems to be a clipping issue as it only happens if you go off the screen.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 26, 2013, 12:20:26 pm
yes ; it's just a clipping issue due to axe numbers.
I will try to fix this soon  ;D

A litlle update :
GREYSCALES and faces definitions (you can choose the color of the face !)

3 levels greyscales and I reduce the size from nearly 4000 bytes to 3000  :thumbsup:
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on January 26, 2013, 01:46:52 pm
yes ; it's just a clipping issue due to axe numbers.
I will try to fix this soon  ;D

A litlle update :
GREYSCALES and faces definitions (you can choose the color of the face !)

3 levels greyscales and I reduce the size from nearly 4000 bytes to 3000  :thumbsup:

Looking at the screenie, I see that the grayscale is a bit different when changed

I suggest using Pt-Change()r
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on January 28, 2013, 05:09:21 pm
Looking cool!
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on January 28, 2013, 05:24:06 pm
Wat, that is to awesome :P
Now make it work better also when moving >.<
JK, it's awesome :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on February 23, 2013, 02:34:09 am
Quote
(http://www.omnimaga.org/index.php?action=dlattach;topic=14592.0;attach=14565;image)

You even have translucent walls?? O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on February 23, 2013, 02:40:48 am
I think it does render invisible walls. So with grayscale, you get transparence.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on February 26, 2013, 06:37:30 am
I think it does render invisible walls. So with grayscale, you get transparence.

no, this version doesn't rendering invisible walls  :'(
it draw all the wall, and don't clean buffers (distance rendering was not here), so it look like there is translucent wall....


.... but, I work on the engine !
-distance rendering (some bugs still here ...)
-"wired aspect" -> if all work correctly, the user will can choose the display mode
-pass from 3000 bytes to 4000 !  ;D
-translucent walls (and true translucent...)  ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)

(sorry, I can't upload the librairy rigth now  :( )

next step : textures !
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on February 26, 2013, 12:01:15 pm
It still doesn't draw lines whose endpoints are offscreen. Are you planning on changing that or should I stop pestering you about it? :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Runer112 on February 26, 2013, 12:09:12 pm
It still doesn't draw lines whose endpoints are offscreen. Are you planning on changing that or should I stop pestering you about it? :P

That's a little bit my fault really... Axe needs proper line clipping still, it's just a pain to get right and optimized.
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on February 26, 2013, 12:20:10 pm
Oh, ok. Sorry to place the blame wrongly.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on February 26, 2013, 12:36:03 pm
It still doesn't draw lines whose endpoints are offscreen. Are you planning on changing that or should I stop pestering you about it? :P

yes, I planing to change that ; but I need first to optimize the engine itself (and after I will see for this)
However, it's true that doing a very optimized clipping line routine is a little hard...
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on February 26, 2013, 01:39:58 pm
Looks pretty cool. How fast is it when rendering an entire room of, let's say... 10 walls (including exit)?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on February 26, 2013, 06:59:10 pm
Yeah, it's looking pretty cool!
And that is 42 frames per second, right? ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on February 27, 2013, 03:38:10 pm
According to the screenie, I would say more like 4.2 or 5 :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on February 27, 2013, 09:17:31 pm
What does the 42 mean then D:
(except the answer to life, the universe and everything)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on February 28, 2013, 03:43:49 am
What does the 42 mean then D:
(except the answer to life, the universe and everything)

it's the FOV use to render.

According to the screenie, I would say more like 4.2 or 5 :P

no, for the frame, it's more 10fps (the screenshot is more slow than the real calc  :P)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 18, 2013, 01:49:38 pm
BIG UPDATE    :w00t:

-new command
-syntax command have change
-full support for 3,4 greyscale lvl and blck and white
-some very basic lightning stuff
-sorry no texture  :-\

List of command
-special command :
must be the first thing after the axe header, and they all must be here
-0/1->°LightOn    toggle on/off the lightning engine (save weight if you don't need it)

-0/1->°GBW
-0/1->°G3GreyLVL
-0/1->°G4GreyLVL     one of these three command must be on, and only one : choose the mode of display

-commands :
-GInit(FLAG)
init the declaration of vertex
FLAG is °GTRIANGLE or °GQUADRI

-GVertex(X,Z,Y)
define a vertex
draw when there is 3,or 4 vertices defines, depend on the FLAG option

-THE GEND() FUNCTION HAS BEEN REMOVE

-GRestoreID(NB_OF_FACE)
restore the list use for GDrawArray

-GSortID(ADD,NB_OF_FACE)
sort the faces  depending of the distance from the point in ADD and the pos of camera
ADD have the following format :
Data(X,Z,Y,X2,Z2,Y2 ...

-GDrawArray(ADD,NB_OF_FACE)
draw an array of vertex who have the following format :
Data(Norm,COLOR
Data(X,Z,Y
....
The number of vertex depend of the FLAG use to init
you can skip the second parameter if you have used GSortID() just before
color is all the following FLAG+ the flag °GLAMBERT, if you want to use light


FLAG->GColor
set the current face color

FLAG is :
in B&W mode
°GWHITE
°GBLACK

in 3GreyScale LVL
°GWHITE
°GGREY
°GBLACK

in 4 greyscales LVL
°GWHITE
°GGREY30
°GGREY60
°GBLACK

in all mode :
°GTWHITE   (wired aspect)

to use a light:
before the main loop put :
-1->{°GLIGHT}^r
in or before :
X->{°GLIGHT+3}
where x is the norm of the light

after, before the vertices def., you place GCalcLight(NORM_OF_FACE)->GColor at the place of FLAG->GColor
or use °GLAMBERT Flag if you use GDrawArray()

-GGetkey()
handle all the getkey


next step :
-Light at the same time than a Color definition (add the two)
-Texture

and two screenshot, B&W mode; 3 GreyLVL Mode, the  lib (ver 0.1) and the example prog  (note that I temporaly remove the Splash screen)

Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on March 18, 2013, 02:10:21 pm
-0/1->°GBW
-0/1->°G3GreyLVL
-0/1->°G4GreyLVL     one of these three command must be on, and only one : choose the mode of display
Why isn't it simply 2/3/4->°Grays ? That would prevent one from making a mistake and be easier to read. ;)
Other than that, this thingy looks very nice. Keep up the good work. :thumbsup:
Good luck with textures. You'll probably have a hard time with them, as you'll have to work on a sprite deformation routine and this might affect performance greatly.
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on March 18, 2013, 02:47:06 pm
Cool!

/me downloads
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on March 18, 2013, 06:22:30 pm
Looking awesome as usual! :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 19, 2013, 01:35:00 pm
2/3/4->°GGrey is a good idea. I will implement it in the next version  :)

and thanks for all support !
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on March 19, 2013, 01:36:53 pm
Looks very great TheMachine02. By the way does your engine support horizontal polygons, so for example you could make that box like a cube?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 19, 2013, 01:39:29 pm
yes. for the engine, polygon is just 3 or 4 points, so you can perfectly do some horizontals faces
The only problem with horizontal face is that the lightning engine doesn't support this type of face (but I will fix this)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 23, 2013, 12:24:12 pm
the next things I have to do (light, portal,textures...) are ... difficult for me alone  :angel:

That why I call for good axe programmeur to join me and work on this ! :thumbsup:

Tell me if you want to be in part of the librairy...
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on April 23, 2013, 11:18:15 pm
Sadly this might be hard to get anyone, unless you sent a PM to tr1p1ea or Runer112 so he can help you on some techniques, because a lot of people have projects or are not fluent with 3D and such stuff. But I hope someone is interested (and that if nobody is that you still plan to work on this lib regardless).

Glad to see you again by the way :)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 24, 2013, 06:03:17 am
Maybe I can help with texturing, and still, I'm not that good with 3D. But since I have, well, no problems with Axe, maybe I'll be of some help :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 24, 2013, 09:01:06 am
That could be very great thanks ! Optimized texturing is something very hard to do.  :P

are not fluent with 3D and such stuff

In fact I now have trouble with some 2d technique and not with 3d  ;D ; especially with cliping against a polygon (picture level) or texturing. Lights will not be so hard to implement, thought.
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on April 24, 2013, 09:18:15 am
I'd be happy to join, so long as I get well commented code to help me understand what's going on.

I came up with a clipped shading routine that I think you'll be able to use!
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 24, 2013, 09:27:59 am
that very great !
I sending you right now a very well commented code (the last  :P ), but I don't think I will use your routine, because I need a moar complex one...
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 24, 2013, 09:40:51 am
Can you send me your code too, and make a quick brief of what's left ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 24, 2013, 09:42:24 am
It was planned  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 25, 2013, 01:34:12 pm
the current source (DEVLOPPERS ONLY)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 25, 2013, 03:22:52 pm
Can you make a readme/doc for this lib that you'd update each version ? It makes using it very easier.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on April 25, 2013, 06:58:25 pm
Super impressive! I love 3D stuff on calc :).
Title: Re: GLIB a graphics axe 3d librairy
Post by: Dapianokid on April 25, 2013, 08:09:14 pm
tr1p1ea you wanna finish that game? :) or solidframe, make it easier to understand! ha
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on April 25, 2013, 10:54:36 pm
Why would anyone but a developer want the source?
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on April 26, 2013, 12:19:41 am
Why would anyone but a developer want the source?

To steal it and release it as his own work on ticalc.org. :trollface:
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on April 26, 2013, 12:52:56 am
They would have to figure out how it works first, so they could modify it enough to make it look different.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 26, 2013, 11:40:30 am
Why would anyone but a developer want the source?

it was just to prevent not to download it  ;D
else, here the readme
Title: Re: GLIB a graphics axe 3d librairy
Post by: Dapianokid on April 26, 2013, 03:51:26 pm
This is amazing. Somebody write a game already ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 28, 2013, 12:48:00 pm
If someone want to make a game of it, just ask me if there is a problem, or something is not clear...  :)

And of course I will be happy if you credit me and the other developpers  :P .
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 28, 2013, 04:13:05 pm
By seeing the source, it appears that what I can do is already done :/ so I can't really help.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 29, 2013, 10:01:00 am
I'm sure you can do something. Maybe speed up the GSort() command by changing the sort algorithm ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 29, 2013, 12:49:26 pm
What does it do already ? Sorting a 2-bytes list ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on April 29, 2013, 06:10:06 pm
Sorting large lists of vertices can take an annoying amount of time. You may have to experiment with different sorting algorithms to see what gives the best results.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 30, 2013, 08:50:48 am
The Gsort() command create a 2 bytes list of distance, sort them and give a list of ID like :

{1000,2500,5000,100}  -> list created
{2,1,0,3}  -> list of ID

I'm currently using a O(n²) algorithm, so it's sure it can be optimized  :P

as side part, I work on portal and run some speed test, with a constant speed for clipping :

a large world (256 vertices with 16 portals,16 vertices by sector) are rendering at the speed of +-17 fps  (in wired mode)
so it's perfectly playable !!
I hope the clipping will not be too much slow, tough.

Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on April 30, 2013, 09:07:50 am
Then, the sorter arranges from highest to lowest. Why do you create a second list? It seems like it would be more efficient in later steps to simply iterate over the list, as opposed to searching through a number list to find the priority.

A good option could be timsort, the sorting function implimented in python. It's one of the best available, and as a bonus, isn't implemented recursively. (IIRC Axe doesn't support recursion, and I blame no one for that) Edit: I'm fairly sure I'm crazy, and timsort probably IS recursive.

Although, it may be better to go with a different route, since these lists will never be longer than 30 or 40 elements. Any faster would probably kill the calc. If we assume this, big-O becomes far less important than the actual equation for the speed.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 30, 2013, 09:16:24 am
So in GSortID, you build a list of X^2+Y^2, and then sort it from greatest to lowest ?

Also, these speed tests are made at 15MHz obviously ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 30, 2013, 09:21:08 am
yes that the goal of the GSort()

but, if I delete the cmd, add a GDrwSortArray() cmd, who include direcly the sorting algo with somethng like as willrandship say (if I well understand):
Code: [Select]
for(nb_poly)
CALCULATE DIST
end

for(nb_poly)
for(nb_poly)
find the greatest value in dist list and retrieve ID
end
draw The ID e poly
make the IDe dist value be 0
end


it will be more optimized. (save data)

BUT the algorithm still in O(n²) and optimizable  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on April 30, 2013, 09:26:42 am
You don't need to draw during the sort. Just sort the list in-place as opposed to creating a new, still unsorted list.

Are there any assumptions we can make about the output list?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 30, 2013, 09:29:36 am
ahh ! so It's when I create the dist list that I sort it ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on April 30, 2013, 09:45:54 am
That's the idea. See, right now, you are creating a list. That's one n. Then, you are sorting that list using an n^2 method. After that, you effectively sort the resulting ID list as you parse through it, presumably with a "Go until you find the right one" approach, which , when sent through the list n times for n vertexes, is sum(1,n).

Altogether this comes to n+n^2+sum(1,n). For a 6-member list this is 6+36+21=53. n^2 is 36.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 30, 2013, 09:54:14 am
that not exactly this

I create my list : n
I sort it, and directly create the id list : n²
then I read,to the id list to render :n

I have 2n+n² in all,wich is ... slow.
But how can I sort and create the ID while creating the distance list?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 30, 2013, 11:12:09 am
Then don't create any ID list, but directly sort the distance list instead. So you'll come up with a single sorted list.

I'll try to implement the sorting method I used with AxeJh3D.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 30, 2013, 01:05:11 pm
I need the id list to render polygon, I can't skip it  :P

but it's sure that optimization is possible
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 30, 2013, 01:37:07 pm
I see what I think is an optimisation, I'll just make an Axe-like algorithm out of it :

Lbl GSortID
...
GDB1ZFACE is a nbFaces*2 large free area
GDB1FACE contains the face definition in the form of Data(0,4,2,...)
GDB1ZVERT contains the 2-bytes Z coordinate of each vertex
GDB1SORT is a nbFaces large free area
...

.Z-average value for each face
For(r2,0,nbFaces)
  0→{r2*2+GDB1ZFACE→r3}r
  For(r1,0,nbVerticesForThisFace)
    {{r2*nbVerticesForThisFace+GDB1FACE}*2+GDB1ZVERT}r+{r3}r→{r3}r
  End
  {r3}r//nbVerticesForThisFace→{r3}r
End

.Sort
While 1
  0→F
  For(r1,0,nbFaces-1)
    If {{r1+GDB1SORT}*2+GDB1ZFACE}r<<{{r1+GDB1SORT+1}*2+GDB1ZFACE}r
      1→F
      Exch(r1+GDB1SORT,r1+GDB1SORT+1,1)
    End
  End
End!If F
Return


With that you have your list in GDB1SORT. I can't really test it since I'm really not familiar with GLib's environment, so I let you test. Ask if you don't understand something.
Title: Re: GLIB a graphics axe 3d librairy
Post by: willrandship on April 30, 2013, 07:01:17 pm
If we implement the in-place sort, the ID list becomes unnecessary, as it's implied that it goes {0 1 2 3 .. highest ID}
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on May 01, 2013, 10:02:15 am
Matrefeytontias you're code work perfectly, I just need to do speed test.

If we implement the in-place sort, the ID list becomes unnecessary, as it's implied that it goes {0 1 2 3 .. highest ID}

I really don't know how to do in-place sort...
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on May 01, 2013, 02:06:43 pm
What he means is that instead of using a list containing all offsets to vertices in a sorted order, just sort the vertices themselves. With that you can access vertices directly, thus retrieving a significant number of calculations.

I'll rewrite my algorithm to use this method.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on May 10, 2013, 05:51:31 am
I test one place sort,and... forget it. The speed is just horrible  :w00t:

But you will be happy to know that I work on this, and a update will come soon, with some  new commands.... who are just awesome  ;D
I will upload it when I can.

(ohh, and Matrefeytontias can you send me the data you use for the omnimaga logo (test program of your axiom) ?   ;) )
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on May 10, 2013, 08:03:07 am
I can, but 1) in a bunch of hours 2) there are no faces, it's just a bunch of Data(Xr,Yr,Zr).
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on May 10, 2013, 01:15:17 pm
Bump,

There you go, all the 20 vertices :

:ΔList(-40r,40r,5r)→GDB1IN
:ΔList(-40r,-40r,5r)
:ΔList(40r,-40r,5r)
:ΔList(40r,30r,5r)
:ΔList(60r,30r,5r)
:ΔList(60r,40r,5r)
:ΔList(-30r,30r,5r)
:ΔList(-30r,-30r,5r)
:ΔList(30r,-30r,5r)
:ΔList(30r,30r,5r)
:ΔList(-40r,40r,-5r)
:ΔList(-40r,-40r,-5r)
:ΔList(40r,-40r,-5r)
:ΔList(40r,30r,-5r)
:ΔList(60r,30r,-5r)
:ΔList(60r,40r,-5r)
:ΔList(-30r,30r,-5r)
:ΔList(-30r,-30r,-5r)
:ΔList(30r,-30r,-5r)
:ΔList(30r,30r,-5r)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 01, 2013, 12:31:08 pm
Necro ..? I hope not.

Is this still being worked on ? It would be too bad that it died.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 02, 2013, 04:58:46 am
no don't worry, it's not dead at all  ;)     I currently work actively on it....
It's just I prepare you a super mega update of the death  :P

Anyway, here is the last progress :
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on July 02, 2013, 05:10:02 am
And that on 8-9FPS? Impressive! :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 02, 2013, 05:39:36 am
O_o I forgot to precise it's a 6Mhz screen and there is a pause 100 in the principal loop (principally to catch  bug)  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on July 02, 2013, 05:40:48 am
wow, that means it is even faster O.O EPIC
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on July 02, 2013, 11:28:47 am
/Totally/ epic. :thumbsup:
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on July 02, 2013, 01:54:35 pm
This seems to be able to do what my 3D engine kept failing at, and at a thrutely great speed.
It really looks like an epic library. I think I'm going to get started with axe again for this.
I can't wait untill the next release.

BTW: is this open-source?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 02, 2013, 02:03:50 pm
Looks great :D

How are you handling the frustum culling ? Because it's something I could never figure out how to do.
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on July 02, 2013, 03:12:15 pm
THat really looks nice TheMachine02! O.O Will collision detection be hard to implement btw?
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 02, 2013, 07:30:31 pm
Im not sure its frustrum culling (in 3D) rather its line clipping in 2D. Either way it looks great and the speed is impressive!

What method is used for clipping? Cohen-Sutherland? Do your filled surfaces clip as well?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 02, 2013, 07:35:44 pm
I asked him, he uses frustum culling. Didn't ask how though.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 02, 2013, 07:39:14 pm
It would be cool to get an explanation of the method used ... plus more screenies :).
Title: Re: GLIB a graphics axe 3d librairy
Post by: TIfanx1999 on July 02, 2013, 07:57:53 pm
Wow, this is looking quite impressive. :) Nice work TheMachine02!
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 03, 2013, 09:25:42 am
Well,well...

I use a 2d method and a 3d one.
The clipping line routine first check if the 2 point we want to draw is not behind the camera.
If so, it's apply the cohen sutherland algorithm to clip the line in 2d
If one point is behind camera, it's calculate the 3d coordinate of the two needed point and then clip in 3d. (clip against the camera x,y plane)
It's simply after render with the 2d clipping line routine.

The result is a good clipping, but a very slow thing when calculating the 3d clipping. I have optimizations in mind, though  :P
Filled surface is not clip for the moment

This seems to be able to do what my 3D engine kept failing at, and at a thrutely great speed.

I am not agree with that. You have texture, and they give me a very hard time !

Else :
*You can of course take any part of the librairy you want at each update, as long you credits me  ;D
*I don'y (currently) know how to handle collision (but you can be sure I will find a way)
*I can't currently make screenshot, sorry
*And of course thanks for all support  :D

EDIT: 200 posts  :w00t:
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on July 03, 2013, 05:10:30 pm
This seems to be able to do what my 3D engine kept failing at, and at a thrutely great speed.
I am not agree with that. You have texture, and they give me a very hard time !
Well, my 3D engine failed missarably at clipping in indoor scenes. But I didn't do any 3D clipping when only one point is behind the camera.

Anyway, if you want help with textures, I can always see if I can modify my texture drawing code to make it compatible with axe.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 03, 2013, 06:04:19 pm
Sounds like a great solution for wireframe clipping.

So i guess you clip coordinates to positive 3D space and then utilise 2D clipping when drawing (cohen-sutherland clipping against a 2D viewport). Very impressive and i agree that clipping filled surfaces can be a bit of a pain.

That said i guess you could try to clip each endpoint if z<=0 in a similar way? It would however require that your triangle drawing routine be able to handle shapes with > 3 sides.

Can i ask if this will likely be used for indoor scenes?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 06, 2013, 08:01:02 am
Yeah of course. Clipping are mainely for indoor scene, as well as portals.

A very very very very  :P  super good new :

TEXTURES WORKS !!!!  :w00t:

but it's slllllllloooooooowwwwwwwwwwwwwwwww  :crazy:
Title: Re: GLIB a graphics axe 3d librairy
Post by: Hayleia on July 06, 2013, 10:46:43 am
Congratulations !
And you say it is slow, but at least it works, and it is easier to optimize a working code than to create and optimize a working code, so I'm sure you'll manage.
All I can do is wish you good luck (and give you a +1) to encourage you to keep making that lib awesome.
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on July 06, 2013, 01:56:05 pm
Yeah of course. Clipping are mainely for indoor scene, as well as portals.

A very very very very  :P  super good new :

TEXTURES WORKS !!!!  :w00t:

but it's slllllllloooooooowwwwwwwwwwwwwwwww  :crazy:
Awesome!

BTW is the texture drawing done in axe? If so, you might want to consider converting it to assembly. Axe is a good and fast language, but for stuff like per-pixel drawing, assembly usually gets faster results.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 06, 2013, 03:45:48 pm
But ASM gets faster results than Axe for everything :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Hayleia on July 06, 2013, 03:49:46 pm
Except for coding time. But of course, an Axe code written in a rush is not worth an ASM code written after optimization reflexions.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on July 06, 2013, 06:12:02 pm
wow, that's looking awesome!
I'll bet you'll be able to optimize it somehow :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on July 07, 2013, 02:33:57 am
Yeah of course. Clipping are mainely for indoor scene, as well as portals.

A very very very very  :P  super good new :

TEXTURES WORKS !!!!  :w00t:

but it's slllllllloooooooowwwwwwwwwwwwwwwww  :crazy:
(http://www.omnimaga.org/index.php?action=dlattach;topic=14592.0;attach=15594;image)

*.*

But something I am wondering is what is the speed when drawing something like 6 walls and how fast does it get if you reduce the resolution so that it looks like 48x32, 96x32 or 48x64 instead of 96x64? In the past, I saw 3D engines reduce their resolutions in order to save speed, but I wasn't sure if this would help in your case.

Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 07, 2013, 04:56:39 am
no, it' won't help. Resolution of screen is independent from the calculation process  :P
But in order to get speed I can decrease the drawing resolution of the texture, and they will be ugly  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on July 07, 2013, 02:06:35 pm
Can we see a example of a bit more complex textures, please? :D (like more complex then a checkboard :P )
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on July 07, 2013, 04:22:55 pm
Epic work, as always.

When is the next binary coming out?
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on July 08, 2013, 12:02:02 am
no, it' won't help. Resolution of screen is independent from the calculation process  :P
But in order to get speed I can decrease the drawing resolution of the texture, and they will be ugly  ;D
Do you mean reduce the actual texture size or just make it more pixelated while making the outline standard? Reducing the texture size would probably look too ugly since it's already very small to begin with. >.<
Title: Re: GLIB a graphics axe 3d librairy
Post by: Keoni29 on July 08, 2013, 03:53:23 am
Just plain black and white walls or even grayscale walls would do just fine.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 08, 2013, 04:09:37 am
no, it' won't help. Resolution of screen is independent from the calculation process  :P
But in order to get speed I can decrease the drawing resolution of the texture, and they will be ugly  ;D
Do you mean reduce the actual texture size or just make it more pixelated while making the outline standard? Reducing the texture size would probably look too ugly since it's already very small to begin with. >.<

No, it's just make more pixelated when drawing.
I was thinking tomorrow for the next update, I hope I will have time to finish everything I want to do  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on July 08, 2013, 09:58:26 am
How about you make each pixel of a texture a border-less wall within the drawn wall? (just do a bit of one-time division for scaling)

would that potentially make it faster?
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on July 08, 2013, 03:13:49 pm
How about you make each pixel of a texture a border-less wall within the drawn wall? (just do a bit of one-time division for scaling)

would that potentially make it faster?
I think it would be way slower, since you'll have to do a lot more calculations during the drawing and some standard scanline optimisation techniques won't work as well.
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on July 08, 2013, 03:18:39 pm
How about you make each pixel of a texture a border-less wall within the drawn wall? (just do a bit of one-time division for scaling)

would that potentially make it faster?
I think it would be way slower, since you'll have to do a lot more calculations during the drawing and some standard scanline optimisation techniques won't work as well.

But what if the textures were calculated beforehand with the rest of the room, and then rendered like the walls?
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on July 08, 2013, 03:42:29 pm
Even then it would take more time. If he handles the drawing in a simular way as I do, some constants are calculated for each wall/triangle. For the rest it just relies on simple additions. Drawing a textured wall requires approximately three times the calculation time for the calculation at the start, and the additions that need to be done take almost three times the calculation time as well. Actually drawing a pixel takes approximately four times time on a textured wall than on a solid wall.
Creating a textured wall by positionning 64 tiny walls (an 8x8 texture has 64 pixels. For a 16x16 texture, you'll need 256 walls) in a rectangle means that the calculations of the constants for each wall has to be done 64 times. And as those calculations are quite slow, this would cause a huge slowdown (21.33 times slower than a texture).
Then, the calculations at the start of each scanline (a getPixel call and some additions) has to be done 8 times more (or 16 times more if you want 16x16) than on a regular wall (which makes this part 2.67 times slower than drawing a textured wall.
But acually drawing a pixel will take the same amount as a regular wall (because in this part, it actually is a regular wall) (so this part is four times faster than a textured wall)
When you add all of that up, it will be a lot slower, mainly because the slowest part has to be done 21.33 times more than when you use a texture.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 08, 2013, 07:40:19 pm
Exactly, when drawing a solid wall you dont have to transform each pixel into texture space ... you are just drawing horizontal lines!

Either way it looks great ... but i was wondering how the texture is mapped. It looks like an 8x8 texture but it appears to have taken a triangle slice of the texture? Or is the whole 8x8 texture not mapped to a single triangle (since it should look distorted when you map a square to a triangle).
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 09, 2013, 07:42:25 am
Thanks to tr1p1ea, I managed to perform backface culling in Axe :)

(http://www.mirari.fr/CaWh)

I don't know if you already do it, but if you don't, I'll be glad to explain how it works. It's pretty fast (although you don't see it because I optimized nothing ;D ), and only consists in one formula (but the conditions in which it works are just a PITA to set up).
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 09, 2013, 09:25:40 am
Either way it looks great ... but i was wondering how the texture is mapped. It looks like an 8x8 texture but it appears to have taken a triangle slice of the texture? Or is the whole 8x8 texture not mapped to a single triangle (since it should look distorted when you map a square to a triangle).

It map a texture according with the U,V coordinate in texture space given at the 3 points who made the triangle

Matref, your backface culling is very interesting. Since I rewamp the polygons sytem, I was forced to remove z-sorting, and I start to study this method in fact  ;D. I will be happy if you can explain me this.

Anyway, some new screeenshots (and I work now hard on the lib to release it as fast as I can !)
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on July 09, 2013, 10:34:08 am
That looks AMAZING!!!

Keep up the good work, as always!
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 09, 2013, 01:25:04 pm
That looks AMAZING!!!

Keep up the good work, as always!
thanks  :D

Matref, I finally don't need your backface culling, because I manage to create something user-friendly (well I hope so  XD ) and which can manage backface culling, as well as a LOT of other things  ;D
But, I really want to see how you do it  :)

Anyway, I am close to the update, but there is some very bad bugs I want to correct before the release, so maybe tomorrow. I don't think I will have the time to correct everything this evening, though  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on July 09, 2013, 03:33:47 pm
I love the opaque cube and the smile texture especially. I wonder if that engine could be used for some sort of Starwing/Starfox/Lylat Wars game  but with fewer polygons (such as ships being flat but able to rotate and stuff)?
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 09, 2013, 05:12:55 pm
The textured face looks really good, and it runs at a decent speed too!
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on July 09, 2013, 05:40:32 pm
Yeah, I like that face and it is running pretty good IMO! :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 10, 2013, 11:25:31 am
A litlle screenshot to show the backface culing thing. Note that a lot of lines can be remove, I currently work on this.  :P
Vertex isn't process if face is remove.

It's currently run at +-31 fps, but I hope gain more speed.

Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 10, 2013, 11:53:26 am
Looks good :)

So how do you perform it ? Because we with tr1p1ea had to find a horribly inaccurate and unflexible workaround, so I'm wondering.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 10, 2013, 12:59:43 pm
I simply perform the normal vector of each faces using a cross product. With that, I have the plan equation of the face, and I check the camera pos according to this equation. The result is positive or negative, and I hide face according to data definition. The only thing that we have to worry is  when all the points of the face is not on the same plan (sqare only), but one workaround is to increase geometry complexity (or simply be careful)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 10, 2013, 01:16:25 pm
and I check the camera pos according to this equation.
What do you mean by that ? What's the calculation performed ?

EDIT : did you use this method : http://flipcode.com/archives/Building_a_3D_Portal_Engine-Issue_06_Hidden_Surface_Removal.shtml ? If yes, how did you manage to get rid of the overflow that I always encounter when normalizing the vector with sqrt(x²+y²+z²) ?

In either way, how did you do that ? >_>
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 10, 2013, 05:39:31 pm
Yeah he is doing it a more traditional way (and thus more accurate). The method we used was the 'quick and easy' way, with the tradeoff being accuracy (though it is minimized if you sort faces, though with proper culling you may not need to sort if you are using convex objects).
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on July 10, 2013, 06:35:50 pm
That still doesn't tell me how he does it, since I miserabily failed at doing so :/
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 11, 2013, 05:30:38 am
This tuto is weird. I use this method, but I only do the cross product. Taking the tuto code, I remove the

Code: [Select]
         double len=sqrt(A*A+B*B+C*C);
         A=A/len; B=B/len; C=C/len;

line, since by definition, the cross product give one of the possible normal vector of the face. No need to normalize the vector. This vector give automatically the plane equation of the face, ax+by+cz-d=0. I then replace the x,y,z value by the x,y,z camera position , and check the sign of the result.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TIfanx1999 on July 11, 2013, 09:40:37 am
A litlle screenshot to show the backface culing thing. Note that a lot of lines can be remove, I currently work on this.  :P
Vertex isn't process if face is remove.

It's currently run at +-31 fps, but I hope gain more speed.



That looks fantastic! :) Very nice work there!
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 12, 2013, 07:16:24 am
MEGA UPDATE OF THE DEATH !!!!    :P

I splited the librairy in two part, mostly to decrease the total program weight
GCORE : the main lib, contains most of basic 3d function
GPOLY : the polygons handling lib

I simply rewamped all the librairy. Polygons gestion is now a LOT better, as well as 3d processing.

A lot of things is planed :
A GOBJCT lib, to have an object gestion
GPORTAL lib : portal rendering !
some new function in the GPOLY lib...

I you have any problem, just ask me.

In the zip, you can find:
prgmGCORE and prgmGPOLY, the lib
prgmGEXAMPLE : GPOLY lib example
prgmGCUBE : GCORE lib example

compile with  axe 1.2.1a !

Last thing to say : I have not fully tested all the commands, so there can still bugs.
MAKE SURE TO BACKUP ALL YOUR DATA BEFORE USING GLIB !
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on July 12, 2013, 09:14:32 am
Epic! You got my download!
Title: Re: GLIB a graphics axe 3d librairy
Post by: Keoni29 on July 13, 2013, 04:16:18 am
Can you draw stretched sprites in 3d space that always face the player and optimize those routines so they aren't just transformed walls with textures on them? Might make the overall experience smoother.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 14, 2013, 01:04:54 pm
Yeah that could work. I don't know if this will be faster, though  :P . I think I will give it a try
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on July 14, 2013, 06:20:09 pm
Hopefully Keoni's suggestion could help. That's how sprites are in DOOM (and even some Nintendo 64 games, such as trees in Super Mario 64) and it doesn't remove much from the game experience, especially at lower resolutions where it isn't as noticeable.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 14, 2013, 10:49:27 pm
Well it should be pretty straight forward, just 1 point for a sprite and then the actual scaled sprite routine itself.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Keoni29 on July 15, 2013, 05:39:23 am
Indeed. You save 3 vertices per sprite if you do it this way instead of using textures on a wall that's facing the player. It also saves you some calculations regarding the translation of the wall in order to appear orthogonal to the player's view direction.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 24, 2013, 10:09:41 am
Just a little post to tell you my progress.

I have currently a basic light engine which work fine (It a little slow, however ) , and I start the portal things  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on July 24, 2013, 08:55:08 pm
Do you mean stuff like dynamic lightning depending of your viewing angle or walls being darker when opposed to the sun??
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on July 24, 2013, 10:14:46 pm
A bi-product of backface culling code can be utilised for simple lighting effects, if thats what he is getting at?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on July 28, 2013, 08:47:58 am
I dynamic light depending of the view point, and I reuse part of backface culling
Title: Re: GLIB a graphics axe 3d librairy
Post by: nikitouzz on September 09, 2013, 02:45:26 pm
the machine had make this with his librairy : (http://i.imgur.com/LdbUF35.gif)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on September 09, 2013, 03:02:20 pm
It's not an axiom, it's an Axe library.

Apart from that, OMGWTFLOLBBQ O.O O.O O.O O.O O.O

Seeing the speed, I think this is 15 MHz ... Because a single textured face was around 6 FPS at 6 MHz.

Either way, I have to create a new word to describe the level of awesomeness of this.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on September 09, 2013, 03:33:26 pm
wow, that is.....FREAKING AWESOME O.O :crazy:
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on September 09, 2013, 05:23:00 pm
Magnificent!

The speed looks really good (although the fps counter doesnt seem to change?).

Awesome work!
Title: Re: GLIB a graphics axe 3d librairy
Post by: nikitouzz on September 09, 2013, 05:47:11 pm
thz speed counter is correct, i have verifed myself same isn"t a real reference :p
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on September 09, 2013, 06:05:35 pm
So is it 15 MHz or not ? <_<
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on September 09, 2013, 06:08:00 pm
I think he said on omnimIRC that that was 15MHz. But still, 7fps for a textured cube is very good for pure axe.
Title: Re: GLIB a graphics axe 3d librairy
Post by: tr1p1ea on September 09, 2013, 06:38:24 pm
Its very good, but its strange that when zoomed out the fps doesnt change? Although the cube appears to rotate quicker/is more responsive.

Either way its amazing, and the speed is great!
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on September 10, 2013, 12:44:57 am
Darn that is crazily awesome! O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 10, 2013, 04:37:07 am
Its very good, but its strange that when zoomed out the fps doesnt change?

yeah, sometime, fps counter stop be updating when using wabbitemu, but on real calc he work well. I don't know what causing this, though.
I also comfirm that this is a 15Mhz screenshoot ( it's +-3 fps at 6Mhz...)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on September 10, 2013, 02:43:30 pm
*.* Holy freaking crap that's awesome O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on September 11, 2013, 01:08:13 am
Amazing little piece full of win! And how do ylu do the FPS counter?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on September 11, 2013, 09:41:44 am
Interrupts I guess. They're a pretty good timer. ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 11, 2013, 09:43:54 am
good guess  :P

One variable who increment in the main loop, and every second, I save it and put it back to 0. Every frame, I display the saved value.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on September 11, 2013, 12:04:15 pm
How, I though they were almost no method which would act as a RTC...
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on September 11, 2013, 12:54:21 pm
Interrupts occur for a fixed amount of time per secound. It isn't exactely the same on all calcs, and it isn't as acurate as the clock or crystal timers, but it's good enough for a frame counter.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 12, 2013, 12:58:00 pm
Yeah it's not a perfect fps counter, just a thing to gave an idea of the speed  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: nikitouzz on September 12, 2013, 02:32:20 pm
When i have make the screen, the fps on wabbitemu been the same on the calculator.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on September 12, 2013, 02:36:57 pm
Just a thing though : the text actually slows down the program. :P Try removing it and test it again in wabbit. ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 12, 2013, 02:40:51 pm
yeah text command slow down the program a lot. But in comparaison of th texture routine, it's almost nothing  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on September 26, 2013, 02:28:58 am
By the way I just saw the screenshot at http://tiplanet.org/forum/archives_voir.php?id=20611 and it looks really great O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on September 26, 2013, 10:33:49 am
that's looking awesome O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 26, 2013, 11:27:34 am
this is the exact screen that as been posted by nikitouzz a few post ago, but I am glad that you like it  :D

EDIT : by the way, I forgot to tell you that a little update is coming =)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on September 26, 2013, 01:48:50 pm
New update? Will it support shaders? : ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 27, 2013, 01:05:48 pm
What do you exactly want as shader ?  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on September 27, 2013, 03:04:17 pm
/me pokes TheMachine to add OpenGL support
/me runs
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on September 28, 2013, 08:59:27 am
lol  :P I am getting close, you know ?
*TheMachine02 run too

Ok, I work a little on shaders, and I have add a vertex shader and a pixel shader  :)

EDIT : I also got idea on adding skybox
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on October 01, 2013, 03:49:29 am
Just a little question to all of you :

What do you want me to add to the library?  (new feature .... )  :P

Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on October 01, 2013, 03:06:40 pm
Just a little question to all of you :

What do you want me to add to the library?  (new feature .... )  :P


The following shaders/effects: Fog, Water, real-time shadow casting, DOF, God rays, motion blur, bloom

Now serious:
Better documentation and more examples: The current documentation is a bit hard to use, and (not meant offensive), it kinda feels incomplete and like it was written in a hurry. And the examples do demonstrate what the engine can do, but it would be very usefull to programmers if you'd add comments (maybe in a .txt file so it can be read on a computer) for everything that uses a part of the library to describe in detail why it's there and what it does. A simple tutorial to get started might be nice too.

Finally, a real feature: It would be nice to have some basic collision detection. It would be okay for me if it could only handle rectangular shapes, even if they are alligned to the x and y axes. This is easy to program and doesn't require a lot of calculations so it is not slow.
If you're unsure of how to implement collision detection, I wouldn't mind to help.

BTW: About the documentation: It can be hard to write clear documentation because even when it's incomplete, it will be clear to you because you know how it works. Therefore, it helps if you let someone read it who hasn't used the library yet, and if he(/she) understands it, then you can be almost sure that most other people will understand it too.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on October 01, 2013, 04:27:10 pm
^ That. Although I tried, I've never been able to do anything with the lib. Too complex and bad documented, that is. The doc seems like notes you left for yourself.
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on October 02, 2013, 12:26:01 am
What do you exactly want as shader ?  ;D
I think he wants you to make Crysis for calcs.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on October 02, 2013, 11:51:17 am
Readme thing : Yeah I realized this a few week ago, and I started to write news one  :P .... but after 2-3 tries I afraid that I really suck at making a readme ><
The lib is complex in itself to gain speed. It's very low-level in some part, and as I write it, I don't really succed to explain these difficulties.

Tuto thing : In fact I  never though to make a tuto : it's a reallty good idea, and I see what I can do.

3d thing : Well I totally forgot the collision system  ;D  the point is I have no idea how to do it. Help is appreciated  :)

The following shaders/effects: Fog, Water, real-time shadow casting, DOF, God rays, motion blur, bloom

Well  I guess Fog, DOF, God rays, motion blur, bloom is not really calc level.
But I work on some real-time shadows casting, and now I can have a sun with shadows ! (pretty limited for the moment though : shadows only on the ground (no
user-defined plane) , and the light source is multi directionnal and must be the most higher point in the decor)
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on October 02, 2013, 03:21:12 pm
Well  I guess Fog, DOF, God rays, motion blur, bloom is not really calc level.
But I work on some real-time shadows casting, and now I can have a sun with shadows ! (pretty limited for the moment though : shadows only on the ground (no
user-defined plane) , and the light source is multi directionnal and must be the most higher point in the decor)
You really have shadows? That's actually pretty awesome for a calc engine. The suggestion of those effects was just a joke.

For collision: if a simple system like the one I used in my racing game, it's not hard at all:
This is how the collision with the ground is done:
The player should have a variable that represents the speed at which it falls. At the beginning of the update loop, increase that variable with a value that represents the gravity, and make sure it doesn't go above a certain value (let's call that value the terminal velocity) to make sure that if the player falls a long way, it still won't go so fast that the collision checking may miss it. Play around with that value to see what looks realistic (depends on the size of your units and the framerate). At the end, substract the falling speed variable from the Y-coordinate of the player(Y is the up axis, right? Otherwise, use the axis that points up). You can repeat this for other objects that need collision checking, but every one of those needs it's own falling speed variable.
For a simple collision with an infinite and flat ground (the simplest and fastest kind), you basically do this:
If(Y <= [Ground level]){
    FallSpeed = 0;
    Y = [Ground level]
}
In words: if the player/object is at or below the grown level, set the fallspeed to 0, and set the Y position of the player (or object) to the ground level (so that if the player hass fallen slightely further than ground level, the player will still end up on the ground). This method is quite fail-safe because it's impossible for the player to fall trough this floor, even when the player fals at a high velocity.

You can also add position parameters to the above method. This can be used in the combination with the previous method to create a raised area in the otherwise flat world:
if(X >= Floor.Xstart && X <= Floor.Xend && Z >= Floor.Zstart && Z <= Floor.Zend && Y <= Floor.height){
    FallSpeed = 0;
    Y = Floor.height
}
With this kind of platform, it is also impossible to fall trough it, but it needs additional collision checking for the sides, because otherwise, a player walking into the edge of the platform will be teleported to the top of the platform. It's also possible to do this with platforms that aren't rectangular or aren't alligned with the X/Z axes, and for that, you replace the if above with one that checks if the player is inside the 'shape' of the platform. This does need a lot more processing power, though.

I'll explain some other things, like simple walls and 'floating' platforms (where you can walk underneath and stand on top of them) tomorrow.

BTW: The FallSpeed variable can also be used for an other application than falling: jumping. Set it to something negative, and the player will go up, decellerate, accelerate again towards the floor, and stop when it hits the floor. By setting this to a large negative value, the player will fly up really high.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Dapianokid on October 02, 2013, 03:38:16 pm
I can see about maybe attempting to document the features of the lib better, if I ever get around to testing it myself. I may use it for a flying camera Rubik's cube sim for the 83+SE... It's very promising and extremely impressive. I wish Axe was for the CSe, too...
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on October 02, 2013, 04:36:41 pm
Axe for the CSE would probably not be able to handle 3D this complex, though. Textures would have to be made of small lines rather than an entire filled area.
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on October 14, 2013, 02:42:20 pm
First of all, sorry for the late reply, I promised this post over a week ago, but something came inbetween and after that, I kinda forgot about it...

Anyway, I'll start with the final platform, the one you can walk under. It's basically the same as the previous one, but with an added condition:
if(X >= Floor.Xstart && X <= Floor.Xend && Z >= Floor.Zstart && Z <= Floor.Zend && Y <= Floor.height && Y > Floor.height-Floor.thickness){
    FallSpeed = 0;
    Y = Floor.height
}
This will give you a platform with the top at floor.height, and it isn't infinitly thick anymore. It is reccomended to give each platform a thickness of AT LEAST the terminal velocity (or the maximum speed the player can fall in that area of the level), otherwise, it is possible for the collision detection to 'miss' this platform, causing the player to just fall trough it.
If you don't add anything to this collision detection, it will act as a 1-way platform, which means that if you jump while you're beneath it, you will go trough and land on the top. If yoou don't want this, you can add a 2nd collision for the bottom, or a 2nd platform right beneath it, which on collision only sets the fall speed and doesn't set the Y-coordinate.

Before we start with walls, there's still something platform-related that may also be usefull for some games: ramps and tilted platforms.
It's actually quite simple: Where you first used a fixed value to determine the height of the platform (in the example: Floor.height), you use a simple calculation based on the X and/or Y coordinates. So, if you want a ramp with a 45° angle around the X-axis, you check if Y<Floor.geight+Z, where Floor.height is the lowest part of the ramp. If you want a different angle, you can divide the Z by a number, if you want it more steeph, multiply the Z by a number (multiply Z by the tangent of the angle, if you like angles better). You can also use a different axis than the Z-axis, and you can also use other functions than simple linear ones, but keep in mind that more complex functions take longer to compute.
Also, this is still simple, vertical-only collision detection, not a physics simulation. It wil allow you to walk up any ramp, no mather how steep, but it won't let you slide down a ramp.
If you want to use this for tilted platforms, it's often best to use the same function for both the top and bottom of the platform, to give it the same thickness everywhere.

If you still want some other kind of platform, feel free to ask, and I'll look into a way to code it.

Now, the walls. They are pretty simular to the platforms, just using other axes and you don't have to mess with the fallspeed.
Let's start with the most simple kind, as we did with the platforms:

World borders
This one is basically the same as the first 'platform', as it is an infinite plane and it's impossible to walk trough. The only practical use is 'locking' the player in a certain area. It might seem rather useless at first, but considering the limited hardware of the calc, overflows will occur if the player moves to far from the center of the world, so you might want to keep him close to the center.
The code is very simple:
if(X > Xmax){
    X = Xmax
}
This makes sure that the player can't move beyond Xmax on the X-axis. You can use 4 of those walls to define the uncrossable world borders.

single-sided walls
Because walls with infinite thickness are rather useless, we'll move straight to single-sided walls.
The code is quite similar to that of the one-way platform:
if(X > wall.X && X < wall.X+wall.Thickness && Z >= wall.Zstart && Z <= wall.Zend && Y >= wall.Ystart && Y <= wall.Yend){
    X = wall.X
}
You can leave out the part dealing with the Y-axis if you don't need walls with a particular height. It's reccomended to do this if you don't have an open space above or below the wall.

This will create a wall alligned to the Z-axis. To allign it to the X-axis, replace all Z's by X's and vice-versa. The thickness of the wall should be at least the (max) walk speed of the player, to avoid the player walking trough it. To avoid graphical glitches, offset this wall slightely from the graphical wall.

double-sideed walls
Simular to the platform, the single-sided wall will only stop players comming from the right way. If you need a full solid wall, you have to use two walls, like this:
if(X > wall.X && X < wall.X+wall.Thickness && Z >= wall.Zstart && Z <= wall.Zend && Y >= wall.Ystart && Y <= wall.Yend){
    X = wall.X
}
if(X < wall.X+wall.Thickness && X > wall.X && Z >= wall.Zstart && Z <= wall.Zend && Y >= wall.Ystart && Y <= wall.Yend){
    X = wall.X+wall.Thickness
}
This creates a wall that is solid from two sides, but if you walk into the ends, you'll ennd up at one side of the wall, instead of stopping there. If you want to stop there, add single sided walls at the ends, alligned to the other axis than the main wall.

You can make the top and/or bottom of a wall tilted, or follow a function, in the same way as with the platform. If you want to use walls as sides of a platform with a non-level top, it's reccomended to do so. And if you're dealing with a ramp, don't add a wall where the tilted edge connects to the ground, and if you make the walls of the triangular side stop a bit in front of that angle, then you don't have to walk up the ramp from the edge where it connects to the ground, but you can then also walk onto it from the sides where it is still low.

This ends the walls part. If you have any questions or if you want me to look into an other type, feel free to ask.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 05, 2013, 12:30:30 pm
Well some screen about what I've done recently  :P  : polygon clipping

The shadow thing strangely make everything crash in Wabbit (it open the debugger automatically each time), whereas the prog work fine on the calculator  :crazy:
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on November 05, 2013, 12:53:51 pm
This looks great, and it seems to be fast too.

However, sometimes, there seem to be glitchy horizontal black or white lines. Does this happen on a real calc as well or is it because of the screen capturing software?

BTW: does this already work for all polygons or only solid black ones?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 05, 2013, 12:58:06 pm
no, the glitchy line appears everywhere, due I think to a value who become is some case negative in the triangle draw routine and mess up everything  <_<
The clipping however work for every polygon, except quad in some rare case, when the clipping algo gave me 5 vertices, it's just draw only one triangle and exit.
Title: Re: GLIB a graphics axe 3d librairy
Post by: nikitouzz on November 05, 2013, 01:47:18 pm
Mais ton clipping ne marche pas en hauteur ca vient aussi de ca le bug non ?

sorry i can't say this in english ^^
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on November 06, 2013, 01:27:23 am
Looks quite good :). I hope you can fix the bugs without too much trouble.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 06, 2013, 08:01:21 am
Do you use a rom-dumped rom for wabbit? If not, do it, the others have some wierd bugs.

So yeah, looking awesome :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 06, 2013, 10:19:39 am
Do you use a rom-dumped rom for wabbit? If not, do it, the others have some wierd bugs.

yep it's a calc dumped rom  :P, but this bug still weird
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 11, 2013, 07:47:30 am
Update of the main lib !!  (the readme is not finalized, so please refer for the moment to the tuto)

*multiple camera handling
*vertex shader
*better system in general
*lot of optimisations

EDIT fixed version !!! shader now work proprelly, and file is clean : This is the final version =)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 11, 2013, 09:24:45 am
Awesome :D

Is GCORE fully functional and finished now ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 11, 2013, 09:30:36 am
Is GCORE fully functional and finished now ?

Well there will have just some little modification in the shader code, but this is almost nothing  (and if I find optimization, I'll made update)
So, we can consider the GCORE as fully functionnal, yes
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 12, 2013, 01:28:35 pm
some screen using vertex shader
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 12, 2013, 04:50:25 pm
ui, that is looking awesome! How come you are so amazing O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2013, 11:26:44 am
a little stress test to see how far the engine could go :

--15MHz -- 4.5fps -- model view -- 512 vertices
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 13, 2013, 11:50:22 am
:o :o :o :o :o this is so amazing !!! Does this use a vertex shader ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2013, 11:52:27 am
no vertex shader for this one, it's some vertex generation  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 13, 2013, 11:53:16 am
Total badass O.O you got your well-deserved +1 :D
/me tries something similar with its own engine
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 13, 2013, 12:10:06 pm
wow, that is so awesome! O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2013, 12:59:00 pm
I will try to do a sphere to  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 13, 2013, 01:01:06 pm
I already did o/

(http://www.omnimaga.org/index.php?action=dlattach;topic=16857.0;attach=15982;image)

And that is 6MHz ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2013, 01:01:47 pm
I know you did. But mine will be moar precise and dot  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 13, 2013, 01:01:51 pm
wha, awesome!
Now make it have some awesome texturing :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 13, 2013, 01:02:36 pm
I know you did. But mine will be moar precise and dot  :P
More precise ? I don't think so. Made with dots ? Less amazing :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2013, 01:04:00 pm
dots could be amazing  :P. And more precise if I put 512 vertices in it  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 13, 2013, 01:05:09 pm
But then the program will only run at 15 MHz, and that is weak :P

Good luck anyway. Nice visuals never hurt ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 13, 2013, 01:06:36 pm
I can run the prog at 6MHz ... but then I will have 1 or 2 fps /me run
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on November 13, 2013, 02:33:43 pm
wha, awesome!
Now make it have some awesome texturing :P
/me thinks of Amiga Ball.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 23, 2013, 12:11:27 pm
a 15 MHz texture thing  ;D   :     spherical  texture mapping !!!
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 23, 2013, 12:12:50 pm
stop being so awesome :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 23, 2013, 12:14:53 pm
Well I jut can't  :p . I know Matref works a little on this too, but Idk what he gets.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on November 24, 2013, 03:03:10 am
/me smacks TheMachine for so much awesomeness. :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 24, 2013, 05:23:25 am
><  anyway I optimized this thing, and now it 2.5 time faster  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 24, 2013, 05:51:54 am
/me wants a visual proof :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 24, 2013, 10:12:06 am
here it is  :P  all is 6MHz
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on November 24, 2013, 10:15:51 am
Oh gawd. O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 24, 2013, 10:16:25 am
Tell me you faked this O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 24, 2013, 10:20:53 am
Tell me you faked this O.O

nope it's not faked  ;D. I put the executable in attachment, it may crash, so be carefull.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 24, 2013, 10:23:15 am
wow, just wow O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 24, 2013, 11:15:04 am
However, I am not totally satisfied cause as you can see, the process get rid of the first line of the spirite  <_<
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 26, 2013, 12:40:37 pm
Okay so here is my 6 MHz version, apparently faster and more accurate. It's 739 bytes with #ExprOff and 823 bytes with #ExprOn. Here's the screenshot with #ExprOn (a tiny bit faster) :

(http://img.ourl.ca//sphere.gif)

ARCCOS.8xp is the source and SPHERE.8xp is the executable.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 26, 2013, 01:06:18 pm
anway, I forgot to post the last ver I've done. Your sphere is pretty good matref, indeed with more precision (but with less feature  ;D)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on November 26, 2013, 01:12:47 pm
Is that still 6 MHz ? It looks rather awesome :D

I know an optimization that can more or less double the speed, but it implies to rewrite half of the code and I'm sooooooo lazy <_<
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 26, 2013, 01:15:03 pm
yup 6MHz +-6fps. As you can see I can zoom (and this is a very important feature, if I want to be able to implement this in the lib)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on November 26, 2013, 03:31:20 pm
Wow, that is pretty awesome for 6MHZ O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on November 26, 2013, 03:43:48 pm
Eyup.
/Big Macintosh mode
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on November 26, 2013, 03:44:31 pm
Eiyo*

You are nonstop stunning me guys! It's for when the new demo?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on November 27, 2013, 10:44:38 am
Eiyo*

You are nonstop stunning me guys! It's for when the new demo?

Well, I don't really know. I am actually working on polygon Library, maybe I will try to do a demo after  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 09, 2013, 06:39:22 am
some test with the pxl and the geometry shader.
The first screen, I only pass one primitive (only one quad) as argument, the shader create a new piece of geometry from the one already there.

(http://i.imgur.com/rd6DUCm.gif)
+-20fps

this is th pxl shader test, a full cube (6 quad) and in each line a pxl who get randomly off.

(http://i.imgur.com/8iBozt9.gif)

+-4 fps

all is at 6MHz
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on December 09, 2013, 08:04:31 am
that is awesome O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: ClrDraw on December 09, 2013, 11:24:12 am
That is really cool, good work. +1
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on December 09, 2013, 01:38:42 pm
some test with the pxl and the geometry shader.
The first screen, I only pass one primitive (only one quad) as argument, the shader create a new piece of geometry from the one already there.

(http://i.imgur.com/rd6DUCm.gif)
+-20fps
If you'd deform the reflection by a sine or such, you could make a water shader of this.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 10, 2013, 04:54:13 am
If you'd deform the reflection by a sine or such, you could make a water shader of this.

Yes guess so. A shadow shader would not so hard to do too, though.
Anyway, I started play with the pixel shader in this area (distorsion), and here what I've got so far (yay pseudo vector slime !  :D )

(http://i.imgur.com/ORetUXz.gif)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on December 10, 2013, 06:22:09 am
ok, that is looking awesome o.o
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on December 10, 2013, 02:25:39 pm
Wow I love it! With a very large shape, does it slow things down a lot?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 11, 2013, 10:03:34 am
there is very few speed loss, and even if the speed decrease more when a big shape is drawn, it's more because of the triangle routine than the pxlshader actually  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 13, 2013, 12:19:20 pm
some progress in the lib  :D, however I can't upload anything due to how crappy the connexion is  <_<

anyway, I sightly modified the shader, made them more secure (this one is for you matref  :P ), and a bit more powerful.
what next :
-reimplement texture (16*16) and add some new function to handle them proprely + make them even more faster (by the way, I was wondering ben_g, do you think we can do only one division per triangle ? cause right now I do one division by scanline)
-an new lib, combaining some usefull shader.
-a proper  documentation

any suggestion ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on December 13, 2013, 12:29:10 pm
(by the way, I was wondering ben_g, do you think we can do only one division per triangle ? cause right now I do one division by scanline)
I only did the divisions for the top 2 scanlines. The intervals that have to be added to the u and v coordinates are constant for every scanline (as long as you use affine texture mapping, instaed of persfective corrected texture mapping), so you can just re-use the results from them for every other scanline.
Oh, and the reason that I use the results from the 2nd scanline is that the first scanline is very short (often only 1 pixel), so the intervals calculated in it are often inaccurate.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 13, 2013, 12:30:59 pm
well, I'll try implement this method  :P . The speed will be a lot better then.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 14, 2013, 08:54:45 am
just  :hyper:    .... at 6MHz

(http://i.imgur.com/brFMLJr.gif)
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on December 14, 2013, 10:38:06 am
/me bows down humbly to the 3D master overlord!
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 15, 2013, 08:36:58 am
texture have been reimplemnt  :D   (well not totally because quads still bugging)

(http://i.imgur.com/evf6Q4C.gif)

runnig from 9 fps to 20  :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on December 15, 2013, 10:42:53 am
so you have three colors, black, white and transparent? awesome! :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 15, 2013, 12:12:29 pm
well ... no. But I guess I can simply implement it  :)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 17, 2013, 05:44:19 am
Quads now working fine , with support for 16*16 texture (and do you recognize the one I put it in ? :P) ! now I currently implement shader in texture. One thing left after, sorting  <_< .

Title: Re: GLIB a graphics axe 3d librairy
Post by: Runer112 on December 17, 2013, 11:38:07 am
Quads now working fine , with support for 16*16 texture (and do you recognize the one I put it in ? :P) ! now I currently implement shader in texture. One thing left after, sorting  <_< .

/me raises his hand!

Looking nice. ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on December 17, 2013, 12:10:35 pm
Hehe nice! Could you do a flag like this?
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on December 17, 2013, 12:19:27 pm
Nice, as always. Wasn't I the one who originally wanted to do a 3d portal, anyways? :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on December 17, 2013, 12:26:28 pm
I guess portal? (only palyed the calc version :P)

Also, looking nice :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 17, 2013, 12:39:10 pm
Hehe nice! Could you do a flag like this?

I guess with a simple pxl shader (from the pseudo vector slime), this can be achieve pretty easly.
Nice, as always. Wasn't I the one who originally wanted to do a 3d portal, anyways? :P

 :P  if only that can be true ......

And thank for support !
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on December 17, 2013, 03:02:21 pm
Very good TheMachine02! :) Still at 6 MHz, right?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 18, 2013, 11:08:47 am
yep, of course. I have got some idea to speed it up the texture routine (again  :P ), I will see when I can if that work. Anyway, I am close to an update now  :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on December 20, 2013, 07:54:56 pm
Any new progress?

/me wants to see a demo of a potential game :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: 3_bit on December 21, 2013, 12:17:54 pm
This is pretty cool... I can't wait to play around with it.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 23, 2013, 09:00:33 am
This is pretty cool... I can't wait to play around with it.
You can already start playing with it here  http://ourl.ca/20032/366887  ;)

Anyway, sorry for the respond time, but I got pretty sick. Hopefully, I am better now, but I haven't really progressed.  :(
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on December 23, 2013, 12:35:54 pm
Glad to see you back. Sorry to hear about your sickness D:
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 28, 2013, 05:18:03 am
backface culling as been reimplemented ! However, I started to have a big (!) problem : compiled source, with all option activated (texture+shader) are being pretty large : almost 6500 bytes....  <_<

Anyway, a little screen : (and yes this is at 6MHz +-5fps , pretty cool isn't it ?)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on December 28, 2013, 05:41:11 am
The texture moves a bit funky when you move the perspective. Take a look at it.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 28, 2013, 05:44:45 am
yeah, I know. It's due to affine texture mapping - and there isn't many way to correct it ( there is one but it slowwwww).
So, with this resolution, I guess it's still ok.
Title: Re: GLIB a graphics axe 3d librairy
Post by: pimathbrainiac on December 28, 2013, 11:58:57 am
TheMachine: you might want to compile it as an app with #ExprOn (if you haven't already)

See what happenes to the speed after that, and if it's too slow, use crabcake for the huge binary.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on December 28, 2013, 12:49:39 pm
See what happenes to the speed after that, and if it's too slow, use crabcake for the huge binary.

Guess anyway that 3D will mostly be used in very big project, so crabcake is fine  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on December 31, 2013, 12:36:44 am
That looks pretty cool TheMachine02 :)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 02, 2014, 10:48:46 am
dithering and lightning ! , 6MHz thing.

(http://i.imgur.com/xytznLy.gif)
Title: Re: GLIB a graphics axe 3d librairy
Post by: nikitouzz on January 02, 2014, 10:51:45 am
And dithering and lightning with texture ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 02, 2014, 10:53:11 am
I am on it, as well as some sort of gouraud shading : one lightning value at each vertex, and some interpolation in the triangle  ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: nikitouzz on January 02, 2014, 10:53:57 am
You are on it O_o OMG
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 02, 2014, 10:56:26 am
yes, basically, it's not so diffcicult, because the dithering I apply is on pxl level. If I treat black texture part as a maximum lightning value, and white as the lowest + ambient value, applying the dithering algorithm will give me a combinaison of texture and lightning :P . However, speed will be very affected.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Xeda112358 on January 02, 2014, 10:56:51 am
Wow, the progress here looks excellent since the last time I checked this out!
:thumbsup:
:thumbsup:
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 02, 2014, 11:14:23 am
combinaison of both dithering and texturing. Note that this is at 15MHz. 6MHz is not *that* slow, but the screen is  faster and look better like this  ;D

(http://i.imgur.com/gLNggbl.gif)

and thanks Xeda !
Title: Re: GLIB a graphics axe 3d librairy
Post by: TIfanx1999 on January 02, 2014, 11:18:06 am
Wow, the progress here looks excellent since the last time I checked this out!
:thumbsup:
:thumbsup:

^This

;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 02, 2014, 11:28:18 am
combinaison of both dithering and texturing. Note that this is at 15MHz. 6MHz is not *that* slow, but the screen is  faster and look better like this  ;D

(http://i.imgur.com/gLNggbl.gif)

and thanks Xeda !
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 02, 2014, 11:31:46 am
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?

well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 02, 2014, 11:36:44 am
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?

well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult  :P
would it be slow/hard to recalculate the light direction based of a certain point for every vertex or for every 4*4 pixel area?
Title: Re: GLIB a graphics axe 3d librairy
Post by: fb39ca4 on January 02, 2014, 03:11:50 pm
Amazing what you can do with a 15MHz z80! You could also use the dithering for depth fog, like Doom did.
Title: Re: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on January 03, 2014, 03:29:38 pm
This totally looks impressive. Would it be practical inside a game?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on January 04, 2014, 06:03:29 am
wooooooow, that is just awesome O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 04, 2014, 12:36:01 pm
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?

well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult  :P
would it be slow/hard to recalculate the light direction based of a certain point for every vertex or for every 4*4 pixel area?

I am not sure for what you mean, but if you think of a sort of per-vertex lightning ; a modification of the texture routine allow me to do some sort of gouraud shading.

Would it be practical inside a game?

I guess it would be better than texture, as it is faster ; and a bit cleaner  :P

anyway, since cliping reallly annoy me, I decide to go to the hard way  :P  perfect 3D clipping : many improvement expected :
-2D commands won't need clipping anymore
-I am thinking of a new way to do it, so it *may* be faster than the actual clipping routine
-all overflow due to this will be remove
-command will clip in a much more agressive way, cutting lot more of geometry  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 05, 2014, 08:18:00 am
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?

well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult  :P
would it be slow/hard to recalculate the light direction based of a certain point for every vertex or for every 4*4 pixel area?

I am not sure for what you mean, but if you think of a sort of per-vertex lightning ; a modification of the texture routine allow me to do some sort of gouraud shading.
Yes, that's what I meant. And for the pixel area, I  meant some kind of per-pixel lightning, but since that would be too slow, it could be done for every 4*4 area of pixels.
But vertex lightning would probably be faster, and the higher accuracy of per-pixel-lightning is probably useless because of the dithering and the small amount of shades (compared to a good screen) anyway.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 05, 2014, 08:58:35 am
per vertex lighting wouldn't be *that* slow. I guess you can use a vertex shader (or geometry shader) / combine with a texture shader to achieve per vertex lightning. I could also implement this directly in the lib, but the total weight will become even more big  :P. Shader is good though.
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 05, 2014, 10:33:01 am
Yea, not everyone would need lighting for his project, so I guess a shader for it is indeed the best option.

BTW, have you made any progress on backface culling and z-ordering?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 05, 2014, 10:40:30 am
well backface culling work well, but sorting is pretty difficult due to data structure - and so I have a buggy routine, but it doesn't work  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 06, 2014, 09:55:56 am
Feature request: could you add billboards? (basically sprites that always face the camera)
Because they always face the camera, only their scale changes based on the distance, not their persfective. Because of this, they only need 1 point to be transformed to get the on-screen coordinate of the sprite, and then you just draw a scaled sprite at that location. For the Z-ordering and finding the location and scale, you can probably re-use some code of the sphere drawing routine.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 06, 2014, 10:20:23 am
Z-ordering isn't really that hard, but it requires caching rotated vertices. I can help you with that as it's how I do it with AxeJh3D.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Vogtinator on January 06, 2014, 12:51:00 pm
Z-Ordering? And what about http://commons.wikimedia.org/wiki/File:Painters_problem.svg?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 06, 2014, 01:02:31 pm
baf   :P . The scene complexity on this calc is not so high so z ordering is enough. Z buffer couldn't be achieve, cause it require a way to much ressource (per pixel check , and a big ram buffer (+-12000 bytes for 16-bit precision...)

ben_g : I will add that then  :)

Since 3D clipping and z-ordering require caching vertices, I guess I will do that  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 06, 2014, 01:05:19 pm
Z-ordering is indeed not perfect, and (while the problem seen in that image is very uncommon) it won't be able to draw intersecting polygons correctly. If you want to draw it correctly, you'd need Z-buffering, which needs a lot of RAM. And unfortunately, the 83+/84+ hasn't got much ram.

EDIT:  :ninja:
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 07, 2014, 06:29:01 am
program example of vertex buffer object or VBO for short. Does syntax is good ? It is cleaner ?

Code: [Select]
.TEST
prgmGCORE

Data(40r,-40r,40r)→GDB1
Data(40r,40r,40r
Data(-40r,-40r,40r
Data(-40r,40r,40r
Data(40r,-40r,-40r
Data(40r,40r,-40r
Data(-40r,-40r,-40r
Data(-40r,40r,-40r

Data(0,1,2,3,4,5,6,7)->°LinkList
Data(0,2,2,4,4,6,6,0
Data(1,3,3,5,5,7,7,1


GNewCam(°GMODELVIEW)
GGenBuffer(8)→G    //take in argument number of vertices and return an id OR 0 if fail
Return!If

GBufferData(GDB1,G,8)   //data to copy, id, size in vertices.

While 1

GUpdateBuffer(G)   //take id

For(M,0,11)    .there is 12 line to draw in a cube
GClipLine({M*2+°LinkList},{M*2+1+°LinkList}
End


GGetkey()

DispgraphClrdraw
EndIf getkey(15)

note too that I have slighty change GGetkey() syntax.
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on January 07, 2014, 12:22:28 pm
so, GUpdateBuffer(id) transforms all the vertices? That seems like a quite simple syntax, but when the amount of vertices changes, do we have to generate a new buffer every time? Because that sounds kinda slow
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 07, 2014, 12:24:20 pm
I guess creating a buffer is actually creating an appvar, so doing it on-the-fly is kinda slow yeah. There's also the fact that you can arrange your code so that you don't actually generate VBOs on-the-fly.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 07, 2014, 12:25:40 pm
indeed, I didn't think about this. So something like :

Code: [Select]
GBufferUpdate(id, start_update,end_update)

with start_update the first vertex to update, to end_update ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 07, 2014, 12:26:56 pm
I think it shoud do yeah. But you can actually have several VBOs running at once ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 07, 2014, 12:30:04 pm
yep, you can generate up to 255 VBO, and choice wich one to activate with id . You can also delete them - but this only free memory ; meaning that even if you have suppress some VBO ; you will not be able to generate other if in total you have generated 255 VBO. Hope you will understand me  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 07, 2014, 12:31:48 pm
Yeah, if you generate 255 VBOs then delete one, you still can't generate any more.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 07, 2014, 12:32:55 pm
exactly that  :P cause handling remplacement woud be a way to much difficult (and heavy).
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 07, 2014, 12:34:52 pm
Well, I don't know how you handle them, so I can't really say. I don't think anyone will need to generate more than 1 or 2 VBOs though :P

Something that I just thought of : are you able to rotate a vertex around a custom point ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 07, 2014, 12:45:00 pm
using custom camera, yes. Basically , you create a new camera ; rotate point around this camera , go back to the classic camera , and render point.
For example ; if I want rotate point 10,10,10 around X,Y,Z, with angle A B and have a world camera, I could do something like that :

Code: [Select]
GNewCam(°GWORLDVIEW)

While 1

GNewCam(Data(Ar,Br,Xr,Yr,Zr,0r))

GRotate(10,10,10)
GDelCam()

GVertex({°GVertex}r,{°GVertex+2}r,{°GVertex+4}r)
Pxl-on(,{°Gvertex+2}r)

GGetkey()

DispgraphClrdraw
EndIf getkey(15)

however ; in the next version of GCORE , the format of the camera will slighty change (nothing big) ; that why I still doesn't made a tuto about it.
The engine in itself can handle 2 different camera.

EDIT this code work for the "old" version though
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 07, 2014, 12:47:24 pm
Okay, that'll be helpful for full models animations, things like wheels and stuffs.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 07, 2014, 02:00:24 pm
After some test, seem that VBO is almost as fast as "classic" code. So I will keep that  :P . I have to try with dot point, though cause acessing it will be more slow


EDIT : ok so it seem that with dot , VBO run at 53-54fps (classic cube) ; and without it run between 55-56 fps (without any super secret settings :p). However, I didn't optimize *yet* the VBO's code
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 11, 2014, 09:41:11 am
finally achieve *perfect* 3D cliping !
however, it's kinda more slow than only doing z plane cliping so, I have to still work on it.

Some pic who will speak better than me  ;D

BEFORE  :                             AFTER:
(http://i.imgur.com/hXFVvoZ.gif)  (http://i.imgur.com/hTNfMJv.gif)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on January 11, 2014, 10:06:40 am
Great ! :D It has been something that I had never get rid of, the clipping bug.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 11, 2014, 10:09:30 am
yep, it really annoy a long time.

I've just done speed test :
-34 fps for buggy cliping
-23 fps for perfect one.

The drop is important ; and I understand it seing all the calculation engine has to do. I will see if I can cache one to get speed.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on January 11, 2014, 12:38:25 pm
wow, that is amazing O.O
I bet you'll make it possible to render faster than light :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 12, 2014, 05:32:34 am
I bet you'll make it possible to render faster than light :P

Wish granted  :P I love trivial accept.

(http://i.imgur.com/ylgmisY.gif)
32.5fps !!!!!!  :crazy:
Title: Re: GLIB a graphics axe 3d librairy
Post by: Eiyeron on January 12, 2014, 09:16:35 am
That's so beautiful! OpO
Title: Re: GLIB a graphics axe 3d librairy
Post by: Xeda112358 on January 12, 2014, 09:48:22 am
Wow, that is fantastic! I have no idea how y'all get this stuff to work so fast and smoothly!
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on January 12, 2014, 01:51:24 pm
yay, that is awesome! :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 13, 2014, 06:24:44 am
thanks  :D

So, I included all of this new stuff (cliping, vbo) Inside GCORE Library. One good thing with VBO is that now all main function are compatible with app  :p  (except for shader and double camera, but I have to reprogram shader anyway, and camera fix is easy).


The size is now +-3200 for a test program, wich I think should be the limit for the main Library, but I don't really know what should be part of it. So I am putting a poll  about what I have to concenter next ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 14, 2014, 02:29:17 pm
Main Library finally completed ! ( exepct for minor updtae such as little optimization) ; but the whole syntax will not ever change  :D
I started to update tuto is consequence too.
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on January 14, 2014, 04:25:24 pm
Good job on the 3D clipping :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on January 20, 2014, 01:02:06 pm
minor update that should hopefully fix a bug with double camera. Also optimize some commands.
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on February 05, 2014, 06:07:45 pm
What is the double-camera feature?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on February 06, 2014, 12:25:30 pm
basically some sort of opengl's stack operation (glPush(), glPop() ), but I simplified it and make only two camera slot avaible. I think it enough for mostly everything (including model rotation and then world rendering).
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on February 07, 2014, 12:57:36 pm
Ah ok, I thought it was something involving 3D, except that didn't make much sense with a monochrome calc unless it was cross-eye view (split-screen), although I guess that could have been an idea for the color 84+ (although unfeasible?) :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on February 24, 2014, 10:19:43 am
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  :P ), 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 ?
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on February 24, 2014, 01:21:04 pm
SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOW *death metal*

So many checks. Also, if you modified GCore again I'm going to kill you.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on February 25, 2014, 05:36:00 am
you know what ? GCORE won't be modified. I am talking about GPOLY lib and GCORE's function allows me to have such pipeline.

Also why are you telling it is slow ? There aren't many check. Even if I put in place a z-buffer, it will be only a 1536 bytes buffer, requiers only one check per 8 pixel (artifact may show up, but it mainly works great).  Stencil buffer is simply implemnted using a 8 bit and per 8 pxl.
Fragment shader could also implement this by there one.
This pipeline is not slowest than the previous I use - exept for the triangle routine. I've made test : it is slighty slower than "normal" (balck/white) filling - but faster then texturing and allow generating fragments.
Ok, one thing is kindy bothering me : slice shifting (like in pseudo slime I've made) will be much more difficult. But I can add an other special shader for it.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 02, 2014, 02:44:43 pm
Sooooo... here my last result, and I am pretty proud of it. This a standard cube runing at almost 37fps  :crazy:

The max is 38.28 fps at some particular position  :P

(http://i.imgur.com/s9ny5pN.gif)

More is coming soon ....
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on March 02, 2014, 02:51:36 pm
Nice :thumbsup: having seen the source, I wonder where you find stuffs to optimize.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on March 02, 2014, 06:59:44 pm
Ok, this is crazily fast O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on March 07, 2014, 02:24:08 am
Good job! :D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 13, 2014, 05:09:16 am
I have improved the vertex shader thing, so now it's allowing making a particule system only based on shader.
And a little screen  :D   (very simple : read random, particule system)
 
(http://i.imgur.com/Sg7U8uC.gif)
Title: Re: GLIB a graphics axe 3d librairy
Post by: Sorunome on March 13, 2014, 09:40:33 am
Wait, 3D flames? O.O
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 13, 2014, 02:17:01 pm
that wasn't the main goal, but life timer and random mouvements have made it yeah  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: TIfanx1999 on March 13, 2014, 07:07:05 pm
Both of the recent screenies have looked quite impressive. Great job! ;D
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 16, 2014, 08:07:25 am
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  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on March 16, 2014, 09:25:35 am
It sounds good, but what is this test really based on? Is it only transforming vertices from world space to screen space or is it drawing stuff too?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 16, 2014, 09:27:17 am
Transforming the vertices and drawing 2*2 black square at the screen position.
Title: Re: GLIB a graphics axe 3d librairy
Post by: Vogtinator on March 16, 2014, 09:51:32 am
What if you display 8 spinning cubes (filled)?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on March 16, 2014, 10:15:04 am
Filling still doesn't work great with my current update. I have to fix it  :P , and it always have been slooow.
However, if I display 8 standard cubes (wired), the speed is 7.4 fps (96 lines, 64 vertices)
 
Title: Re: GLIB a graphics axe 3d librairy
Post by: DJ Omnimaga on April 04, 2014, 02:14:13 am
I'm a little late, but I'm really curious how fast it would get with many objects on the screen, like in a Star Fox game, for example. Also, would collision detection slow games down?
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 05, 2014, 09:19:12 am
that really depend if the object share a lot of vertices or not I guess. As long as object aren't vertices consuming or link consuming, I guess it could be possible to have something in real time.

As for collision detection, it really depend on game itself. Some will need simple collision (a tilemap could do the job), or some other need plane collision detection, who is pretty much time-consuming.

So, this really depend of the final goal  :P
Title: Re: GLIB a graphics axe 3d librairy
Post by: Matrefeytontias on April 08, 2014, 06:58:56 pm
Bump,

Don't know if it's intentional or a bug, but the camera will block to a perimeter of 256*256 in X and Z. I'm kinda not okay with that, as it's very small - see GGetKey, where getKey(1)-getKey(4) is checked against trig and ±16384.
Title: Re: GLIB a graphics axe 3d librairy
Post by: ben_g on April 08, 2014, 07:38:15 pm
Bump,

Don't know if it's intentional or a bug, but the camera will block to a perimeter of 256*256 in X and Z. I'm kinda not okay with that, as it's very small - see GGetKey, where getKey(1)-getKey(4) is checked against trig and ±16384.
TheMachine once told me that it is to avoid overflows. If that area is to small for what you need, then you can just move the player and the world when the player comes close to an edge.
Also keep in mind that 3D graphics are a form of vector graphics, meaning that they can be scaled easily. So it is possible to scale your world down, and make the camera more zoomed-in witouth any loss of quality.
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on April 17, 2014, 10:03:09 am
Not really an update, but I spot nice optimization to do in VBO code, and currently trying to get these working  :P
I also made vertex shader a lot more powerfull, for example, you can now do this :
 
Code: [Select]
Lbl Shader
in °r1
in °N,6
max(dot(°N,vec3(0,0,-64)),0)r->L
gRotate(r1,r2,r3)
Lbl SubShader
gProject
Return

I still need to find a way to pass value to the rest of pipeline though ><
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on May 04, 2014, 05:01:15 am
So, I have reimplemented the polygon engine, with the new version of Glib.
It is pure axe, so there isn't really some astonishing performance, but there still great.
Two polygons ~20 fps :
(http://i.imgur.com/s97jWzl.gif)(http://imgur.com/J81h0Y0)
 
Backface culling (from ~30 fps to 38fps)
(http://i.imgur.com/J81h0Y0.gif)
 
 
Title: Re: GLIB a graphics axe 3d librairy
Post by: Streetwalrus on May 04, 2014, 05:07:04 am
Aren't there four triangles in the first screenie ? ???
Pretty nice anyway. ;)


Oh BTW the topic title keeps bothering me. :P Should be : "Glib : a 3D graphics Axe library". ;)
Title: Re: GLIB a graphics axe 3d librairy
Post by: TheMachine02 on May 04, 2014, 05:08:54 am
I only made two call to draw primitive, since I treat polygon as quadrilaters : so two polygons :p . This can be changed, and currently I support every polygons possible, as long as point given are in right order and coplanar.
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on May 18, 2014, 04:40:55 pm
I started to play around with GLib again and I noticed that clipping sometimes behaves rather weird with moving vertices. I'm not sure what's causing this behaviour, but I guess the clipping information of the vertices isn't updated every frame, since clipping between static vertices at the same location works well (see the square at the top of the room).
Is there any way to force GLib to update the clipping information of the vertices that are moving? Or if something else is causing the problem, what would you suggest as a fix or workaround?


Here's the screenshot:
(http://img.ourl.ca/weird%20clipping.gif)
Title: Re: Glib : a 3D graphics axe library
Post by: GinDiamond on May 18, 2014, 07:38:00 pm
I really need to get around to using this
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on May 19, 2014, 01:41:22 am
mmmhhh.... I do think there is something else, cause cliping is performed every frame (basicaly, compute a visible code at the end of vertex rotation, and when a line is draw, GLib check the code and performe cliping between the two point of the line if necessary.
It mostly look like that GLib fail at retrieving some pre cliping vertex information.
How do the vertex are moved/rendered ?
Title: Re: Glib : a 3D graphics axe library
Post by: DJ Omnimaga on May 19, 2014, 01:47:36 am
I started to play around with GLib again and I noticed that clipping sometimes behaves rather weird with moving vertices. I'm not sure what's causing this behaviour, but I guess the clipping information of the vertices isn't updated every frame, since clipping between static vertices at the same location works well (see the square at the top of the room).
Is there any way to force GLib to update the clipping information of the vertices that are moving? Or if something else is causing the problem, what would you suggest as a fix or workaround?


Here's the screenshot:
(http://img.ourl.ca/weird%20clipping.gif)
I would certainly like *.* (although maybe with less clipping glitches)
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on May 19, 2014, 02:27:04 am
So it does look like that I have already correct this bug, I can't reproduce it on the version I currently have. I'll send you an alpha version of the new version when I will have some time  :)
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on May 20, 2014, 04:00:32 am
Plop, here the version that shouldn't cause problem.
If the issue still there, I guess that something is unexpected in your code, and I will need the source to spot it  :P
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on May 20, 2014, 12:09:21 pm
Plop, here the version that shouldn't cause problem.
If the issue still there, I guess that something is unexpected in your code, and I will need the source to spot it  :P
That did indeed fix it. Thanks.
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on June 09, 2014, 05:26:16 pm
So, as you may have guessed it already from the above screenshot, I'm working on a collision detection library. It is mainly meant to be used with GLib, and I hope that it will make calculator-3D programming more user-friendly, especially for programmers with few or no experience with 3D programming.
It's not ready to be used for a game yet, as it only supports a few basic things. The basic engine is already working though, which makes it easy for me to add more into the engine.
I mainly want to say this so that double work can be avoided. Further updates when the engine will be almost game-ready will be posted in a different thread, since this is not an official part of GLib, to avoid highjacking this one.

Anyway, have a screenshot:
(http://img.ourl.ca/screenshot001-1.gif)
Title: Re: Glib : a 3D graphics axe library
Post by: Matrefeytontias on June 09, 2014, 05:33:44 pm
Wow nice O.O and that looks smooth too !
Title: Re: Glib : a 3D graphics axe library
Post by: Streetwalrus on June 09, 2014, 06:00:53 pm
Indeed, it looks pretty great ! :D
Title: Re: Glib : a 3D graphics axe library
Post by: bb010g on June 09, 2014, 10:03:32 pm
So...DOOM? :P
Title: Re: Glib : a 3D graphics axe library
Post by: DJ Omnimaga on June 09, 2014, 10:08:57 pm
This reminds me a bit Benryves engine, but slower (most likely since it's in Axe). It looks really nice and seems like it could be used in-game, though. :)
Title: Re: Glib : a 3D graphics axe library
Post by: tr1p1ea on June 09, 2014, 11:08:14 pm
Wow looks great!

How big can the worlds be?
Title: Re: Glib : a 3D graphics axe library
Post by: Hayleia on June 10, 2014, 12:44:36 am
Ideed, it looks great :D
I especially like the elevator. effect.

So...DOOM? :P
There are already a few Doom clones available. Plus, they "only" need a raycaster, not a full 3D engine.
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on June 10, 2014, 04:38:15 am
Yay collision  :D !
Actually, it was one of the only thing that I haven't succed to put in place. So, yeah, having a lib who can do this is super great  :P

How big can the worlds be?

I do think that world is mostly limited by GLib, so a cube of [-128,+128]
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on June 10, 2014, 04:51:37 am
It's indeed in a cube of [-128,128], both because of GLib and because I decided to use 8bit numbers for the worldborder values. If I get rid of the world border, it could handle a much larger area, but when you have to deal with a large area, you're better of dividing it into multiple sectors, since too many objects will slow it down (for every object that has collision detection, it has to loop trough all solid objects (like walls or the pillar in the screenshot) to apply the collision detection to it.
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on September 26, 2014, 09:29:21 am
Sooooooo it is quite a long time that I've haven't post anything,but don't worry I am not leaving calc community  :P ; it is just that I've been really busy this last few week (and it will be all the year like this  x.x )

However, I still work on this project as you might see on the next screen :  >:D

(http://i.imgur.com/HxskaVA.gif)

yay !
something big is also coming, but I won't tell you more  :P
Title: Re: Glib : a 3D graphics axe library
Post by: pimathbrainiac on September 26, 2014, 09:53:53 am
YAY Lighting!
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on September 26, 2014, 10:44:09 am
- Sooooooo it is quite a long time that I've haven't post anything,but don't worry I am not leaving calc community  :P
 - (http://i.imgur.com/HxskaVA.gif)

 - something big is also coming, but I won't tell you more  :P
- That's good to hear. I was thinking about not having heared about you for a while yesterday.
 - Is that per-pixel lighting you're showing there? Or high-res textures/textures with dither patterns? It's kinda hard to see, and it seems to be a bit broken on my computer, as some parts appear as white (not calculator green white, but real white) and shades of grey. Anyway, it looks cool, good work.
 - Does it start with an A? I think I know what it is :P

BTW: Are billboards planned? If not, then I'll probably try to 'mod' them in after that 'something big'.
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on September 26, 2014, 11:10:28 am
well if gif is broken, you can see it there : http://i.imgur.com/HxskaVA.gif (http://i.imgur.com/HxskaVA.gif)
Strange that the gif appears odly, since it look fine on my computer.

Actually I don't think per pixel light calculation are possible on a calculator, sooo it is indeed high res texture with dithered pattern (I even added magnification, but it run so slowwwwww)
- Does it start with an A? I think I know what it is :P

shhhhhh it is a secret  :P

also, billboard are planned, even if I don't think I will ever succed to code them ><


EDIT : attached the gif
 
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on September 26, 2014, 12:37:18 pm
apparently, the gif was just chrome acting weird. It works fine in the image viewer on my computer.
Title: Re: Glib : a 3D graphics axe library
Post by: DJ Omnimaga on September 27, 2014, 10:43:29 am
I think the GIF issue is that the black color is transparent in it. I tried in Firefox and Opera 12.17 because I had the same issue in Chrome and Opera 24 and neither the other browsers could display it right, not could the image viewers. So to see it properly you need to use a black background.

Here is a fixed GIF (unless the white part was supposed to be green?), but it's like 800 KB large >.<

(http://img.ourl.ca/HxskaVA.gif)

Looks nice by the way. It seems a little slow though so perhaps it shouldn't be something implemented by default in every game using GLIB but rather an option if the programmer chooses to include it. Nice job nonetheless though :)

Also nice to see you back :D
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on October 01, 2014, 03:51:48 pm
actually, with all the optimizations I done, it is even faster tahn the "normal" texture routine .... and it still pure axe  :P
Title: Re: Glib : a 3D graphics axe library
Post by: DJ Omnimaga on October 01, 2014, 04:01:48 pm
Ok good to hear :)
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on April 05, 2015, 06:50:37 am
Soooo. I need help of asm guru  :3
I was doing a multiplication routine in asm, and since it is in sensitive code, I need the max speed. However it is a mul BC*A/8
So a bit more tricky, and I couldn't optimize more than this :

Code: [Select]
_gFMulAxBCdiv16:
ld hl, 0
or a
ret z

rra \ jr nc, $+8 \ ld h, b \ ld l, c \ sra h \ rr l
rra \ jr nc, $+3 \ add hl, bc \ sra h \ rr l
rra \ jr nc, $+3 \ add hl, bc \ sra h \ rr l
rra \ jr nc, $+3 \ add hl, bc \ sla c \ rl b
rra \ jr nc, $+3 \ add hl, bc \ sla c \ rl b
rra \ jr nc, $+3 \ add hl, bc
rra \ rra \ ret nc
sla c \ rl b
or a
sbc hl, bc
ret


Note that DE should be kept intact, BC can be destroy and A is in [-63,63]
So if anyone can hep me ... :D
Title: Re: Glib : a 3D graphics axe library
Post by: c4ooo on April 26, 2015, 08:19:43 pm
Ahh... The wonders of mathematics!... It's nice you made this into lib form, but I still think that making a custom engine for a game is always more efficient.  ;)
Also this can aply textures and lighting? Or just fill polygons with a color?
Exit: did not notice the new axiom thread for this. :(
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on April 27, 2015, 05:14:05 am
Actually, not. I've taken care the fact that an optimized engine as to be made for each game. That's why gLib doesn't offers a game engine, only the essential set of routine to get basic 3D runs, and optimized data manipulations. (setting matrix, rotation,cliping...) (even if I still have to add 2D rotation commands)
I even let's the user do what he wants in 3D calculation with shaders. I do think that is much powerful than an big engine taking care of all - wich gLib isn't - and pretty much close of a very particular engine.But after, we'll have to see. I am currently programming a game with it, I pretty much will see if it is feasible or not.
Title: Re: Glib : a 3D graphics axe library
Post by: c4ooo on April 27, 2015, 04:00:19 pm
Actually, not. I've taken care the fact that an optimized engine as to be made for each game. That's why gLib doesn't offers a game engine, only the essential set of routine to get basic 3D runs, and optimized data manipulations. (setting matrix, rotation,cliping...) (even if I still have to add 2D rotation commands)
I even let's the user do what he wants in 3D calculation with shaders. I do think that is much powerful than an big engine taking care of all - wich gLib isn't - and pretty much close of a very particular engine.But after, we'll have to see. I am currently programming a game with it, I pretty much will see if it is feasible or not.
Well yes... if its really basic then yes. But still, how easy (using this) is it to make the engine share interacting vertices/vectors so the same points will not have to be computed more then once? :ninja: Or maybe some game would be more efficient with textured quads instead of triangles.(TI-Craft 3D *cough cough*) (I know you can get a textured "quad" in libs like openGL by using two textured triangles, but its not like OpenGL is actually optimized to work with quads and not triangles) Another thing, this can actually draw textures right?
Title: Re: Glib : a 3D graphics axe library
Post by: ben_g on April 27, 2015, 04:08:04 pm
... Another thing, this can actually draw textures right?
I don't think it can.

/me should really blow the dust of his calc projects and finally mod that in
Title: Re: Glib : a 3D graphics axe library
Post by: TheMachine02 on April 28, 2015, 06:24:14 am
... Another thing, this can actually draw textures right?
I don't think it can.
I do have code to draw texture, but it never really made to the library itself.

EDIT : didn't see your message above. Sharing vertices is really esay, since vertex computing and primitive rendering are disconnected. Also, you won't be ever able to put texture in a game, I am afraid (or maybe for some cinematics at 5fps ...). Also, gLib does support both triangle and quads, quads are however still rendered as two triangle (but clipped as quads).