• Glib : a 3D graphics axe library 5 1
Currently:  
« previous next »
Pages: 1 ... 22 23 [24] 25 26   Go Down

Author Topic: Glib : a 3D graphics axe library  (Read 93383 times)

0 Members and 1 Guest are viewing this topic.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: GLIB a graphics axe 3d librairy
« Reply #345 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?
Logged

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: GLIB a graphics axe 3d librairy
« Reply #346 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
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: GLIB a graphics axe 3d librairy
« Reply #347 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.
Logged

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: GLIB a graphics axe 3d librairy
« Reply #348 on: April 08, 2014, 07:38:15 pm »
Quote from: 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.
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.
« Last Edit: April 09, 2014, 11:59:44 am by ben_g »
Logged
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: GLIB a graphics axe 3d librairy
« Reply #349 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 ><
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: GLIB a graphics axe 3d librairy
« Reply #350 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 :

 
Backface culling (from ~30 fps to 38fps)

 
 
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: GLIB a graphics axe 3d librairy
« Reply #351 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". ;)
« Last Edit: May 04, 2014, 05:09:14 am by Streetwalrus »
Logged

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: GLIB a graphics axe 3d librairy
« Reply #352 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.
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: Glib : a 3D graphics axe library
« Reply #353 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:
Logged
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline GinDiamond

  • LV3 Member (Next: 100)
  • ***
  • Posts: 71
  • Rating: +2/-2
  • I dont always fail at life, but when I do, I dont
    • View Profile
Re: Glib : a 3D graphics axe library
« Reply #354 on: May 18, 2014, 07:38:00 pm »
I really need to get around to using this
Logged

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: Glib : a 3D graphics axe library
« Reply #355 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 ?
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Glib : a 3D graphics axe library
« Reply #356 on: May 19, 2014, 01:47:36 am »
Quote from: 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:

I would certainly like *.* (although maybe with less clipping glitches)
Logged

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: Glib : a 3D graphics axe library
« Reply #357 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  :)
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline TheMachine02

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 452
  • Rating: +105/-0
  • me = EF99+F41A
    • View Profile
Re: Glib : a 3D graphics axe library
« Reply #358 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
Logged
AXE/asm programmer - unleash the power of z80 //C++//C

epic 3D things http://www.ntu.edu.sg/home/ehchua/programming/opengl/CG_BasicsTheory.html

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: Glib : a 3D graphics axe library
« Reply #359 on: May 20, 2014, 12:09:21 pm »
Quote from: 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
That did indeed fix it. Thanks.
Logged
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated
Pages: 1 ... 22 23 [24] 25 26   Go Up
« previous next »