Join us on Discord!
You can help CodeWalrus stay online by donating here.

[gLib][3d][z80][ez80] gLib a fast 3D asm/axiom library

Started by TheMachine02, January 19, 2015, 05:10:01 PM

Previous topic - Next topic

0 Members and 5 Guests are viewing this topic.

Dream of Omnimaga

I am curious about how fast pixel shading would be, considering my 2006 graphic card (previous computer) didn't even support them.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Snektron

That's quite surprising actually, pixel shaders are a big part of modern games.
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


Dream of Omnimaga

Yeah true. I guess maybe the card just had minimal support for such stuff. It was a lower end card too (the last video card to support PCI cards IIRC, since by then everything was for PCI-E and AGP and my computer lacked those). It could have been the games not taking my card into account, though, and thus, thinking it lacks pixel shading.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Snektron

  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


TheMachine02

They are as fast as usual filling is fast  :P + speed of the shading itself of course. But there is no overhead to use or not a pixel shader.
However, they are no where close to the pixel shading from openGl or directX of course. They are limited to 16 bytes of asm command, and call is allowed but pretty much to slow to be pratical. They scale well for stencil/zbuff or such algorithm though.

Dream of Omnimaga

If you can get 2 FPS from this I am definitively curious about how an Illusiat 3 clone would look like in this. Since the original game has the character move across an entire room instantly with just one arrow keypress, then a 3D remake could probably do the same and rotate by 45° at a time. Perhaps for walking it should be 1.5 FPS, though, because moving across two entire rooms in just one second might look a bit unrealistic. :P
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

ben_g

So, I've been playing around with this again.

I'm trying to add in billboards (using Matref's scaled sprites axiom), but I'm a bit stuck at calculating the scale.
I know that gVBOVertex(id) returns the coordinates of the point on the screen in {°GScreenX} and {°GScreenY}, but {°GScreenZ} doesn't exist, so I have no idea how I should calculate the distance between a point and the camera. Without the distance, I have no idea how I should calculate the scale.

Snektron

Yeah, screen coords are 2d only. They dont need a z pos (were leaving the z-buffer out of this). You'll need to find a way to use it from the position you supply
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


ben_g

Screen coordinates are usually 3D, and the z coordinate indicates how far a point is from the screen.

gLib probably calculates points in all 3 dimensions (since that's how most 3D to 2D conversions work), but it either isn't returning it, or it's returning it with a different name.

Dream of Omnimaga

Ohai ben_g, long time no see :). Hopefully @TheMachine02 can help you there. Or maybe @matrefeytontias could help a bit if he looked into gLib before.

By the way is this for the 3D thing you used to work on several years ago?
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

matrefeytontias

gVBOVertex(id) also put the 3D coordinates in GVertexX, GVertexY and GVertexZ if I remember correctly, or something like that.
  • Calculators owned: TI-83+.fr, TI-Nspire CAS prototype, TI-84+ CSE, TI-Nspire CX
My TI games (some got their own article on non-calc websites !) : http://www.ticalc.org/archives/files/authors/112/11202.html

My moozik (100% free metal) : http://www.soundcloud.com/matrefeytontias

TheMachine02

gVBOVertex(id) does only put the full-3d coordinate in the new gPositionX,Y,Z structure, and doesn't give screen position.
The gVBOPoint(id) does give the screen position (wich are now 1 byte) and the clipCode in hl.
The new gVBOGetData allow retrieve evrything in one pass though. the syntax is gVBGetData(destination_adress, size, offset, id), so I guess you most likely want to call it like that : gVBGetData(°GscreenX, 8, 0, id)
The screen coordinate will be in °GScreen, and the vertex coordinate in °GPosition. This is basically the "bottleneck" I  talked about. VBO are pretty badly implemented, and need a pretty much whole refactoring. gLib spent to much time in those vertex data manipulation  :P
So yeah, this is the current syntax, but that will most likely change.

ben_g

Quote from: DJ Omnimaga on May 03, 2015, 06:16:14 AM
Ohai ben_g, long time no see :). Hopefully @TheMachine02 can help you there. Or maybe @matrefeytontias could help a bit if he looked into gLib before.

By the way is this for the 3D thing you used to work on several years ago?
Well, I've been more or less active on omnimaga lately, but I kind of forgot about this site. I'll try to be more active here too.

And this isn't really for anything I've already worked on (I'm mainly just trying stuff out, looking at what stuff I can get together), but I might pick up one of those projects when I can get enough things working.

Quote from: TheMachine02 on May 03, 2015, 09:19:43 AM
gVBOVertex(id) does only put the full-3d coordinate in the new gPositionX,Y,Z structure, and doesn't give screen position.
The gVBOPoint(id) does give the screen position (wich are now 1 byte) and the clipCode in hl.
The new gVBOGetData allow retrieve evrything in one pass though. the syntax is gVBGetData(destination_adress, size, offset, id), so I guess you most likely want to call it like that : gVBGetData(°GscreenX, 8, 0, id)
The screen coordinate will be in °GScreen, and the vertex coordinate in °GPosition. This is basically the "bottleneck" I  talked about. VBO are pretty badly implemented, and need a pretty much whole refactoring. gLib spent to much time in those vertex data manipulation  :P
So yeah, this is the current syntax, but that will most likely change.
Using GPosition seems to work, thanks.

CKH4

Pretty cool effect, maybe you could make a solar system like that.
  • Calculators owned: TI-83+, TI-84+


Snektron

Or maybe a... FBO particle system?
Though i dont think there are real FBO's in gLIB... though they shouldnt be too hard to implement (i guess its already implemented if you can render
to a different buffer... though you'd need to be able to use it as texture too)
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


Powered by EzPortal