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 3 Guests are viewing this topic.

CKH4

Give it a try cumred. I would love to see the result.

Anyways what does gposition do? If its a variable does it return numbers for how far from the camera it is? Or is it a command like GPosition()?
  • Calculators owned: TI-83+, TI-84+


alexgt

That could be a start to textures?!
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Snektron

But my FBO particle system doesnt need glib since its only 2d... Though i could try to make the starfield i made for DarestEx
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


ben_g

#93
Quote from: Cumred_Snektron on May 03, 2015, 06:32:31 PM
Or maybe a... FBO particle system?
Unfortunately, this is still rather slow (the screenshot runs at 10fps@6MHz), so it's not really suitable for rendering a lot of particles.
The scale (0-255) is currently calculated with 8129/√(GPositionZ), which is rather slow (and the scale isn't perfect either). If I can find a better calculation, then it might be faster.

EDIT: The slowdown has been fixed. I had a pause 100 somewere in my code that I forgot to take out :banghead:

Quote from: CKH4 on May 03, 2015, 06:36:37 PM
Give it a try cumred. I would love to see the result.

Anyways what does gposition do? If its a variable does it return numbers for how far from the camera it is? Or is it a command like GPosition()?
GPosition is the location of a vertex in 3D screen space. GPositionX and GPositionY are the X and Y coordinates of a point on the screen (with (0,0) being the center), and GPositionZ is the depth (or, how far away the point is from the camera).

CKH4

So what numbers are the GPositionZ usually between?
  • Calculators owned: TI-83+, TI-84+


ben_g

GPositionZ varies between 0 and the distance between the camera and the point furthest from the camera.

Dream of Omnimaga

#96
Quote from: ben_g on May 03, 2015, 06:25:00 PM
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.

Looks very good! :) As for the site don't worry about it. IIRC tr1p1ea didn't even know it opened until like February, despite the big red countdown timer of doom on the front page in late December. :P

Quote from: Cumred_Snektron on May 03, 2015, 06:32:31 PM
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)
Actually is your FBO Particle system 2D or 3D? It seems to have 3D in it but I'm unsure. I am asking because AngelFish on Omnimaga did one for the TI-83 Plus once (I don't remember if he released it, though) IIRC
  • 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

My FBO particle system is 2D, though i want to make a 3d version too someday
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


TheMachine02

Quote from: ben_g on May 03, 2015, 06:42:37 PM
The scale (0-255) is currently calculated with 8129/√(GPositionZ), which is rather slow (and the scale isn't perfect either). If I can find a better calculation, then it might be faster.
I might immplement the fast square root routine I found one day on the net in gLib, because the axe one is definitly slow (as it wasn't speed optimized). Billboard definitly lokk great though :)

Btw, gLib does support layer rendering, at least for triangle code (not line for now, but I am on it :p)
gPosition usually vary between 0 and at max 8192, but that really depends on the user.... I've also extended gLib point range from [-256,256] to [-1024,1024].


ben_g

#99
Quote from: TheMachine02 on May 04, 2015, 05:40:27 PM
Quote from: ben_g on May 03, 2015, 06:42:37 PM
The scale (0-255) is currently calculated with 8129/√(GPositionZ), which is rather slow (and the scale isn't perfect either). If I can find a better calculation, then it might be faster.
I might immplement the fast square root routine I found one day on the net in gLib, because the axe one is definitly slow (as it wasn't speed optimized). Billboard definitly lokk great though :)
Well, I actually thought it was very slow because there was a 'Pause 100' in my code for debugging that I forgot to take out.... It isn't too bad now, it should be useable in games.

I still have 2 questions about this axiom though:
1) The GModelView camera (if it's still called like that) rotates in 'third person' around the center. Is there a way to keep all funtionality of that camera, but move the point it rotates around?

2) I'm trying to make an editor, and for that, I have a 3D cursor. I use vertex 255 to store the cursor coordinates, but it doesn't seem to work (the cursor is always in the exact center of the screen). I use this code:ᴇ4000→°Verts
ᴇ459A→°CurX
ᴇ459C→°CurY
ᴇ459E→°CurZ

0→CurX→CurY→CurZ

gGenVBO(°Verts,256)→G
ReturnIf GError
gVBOParam(°GVBOSET,G)

While 1

CurX+getKey(19)-getKey(35)→CurX
CurY+getKey(28)-getKey(26)→CurY
CurZ+getKey(20)-getKey(36)→CurZ

gVBOUpdate(255,255)

gVBOPoint(255)
Pt-Change({°GScreenX}-3,{°GScreenY}-3,°CUR)
//°CUR is a pointer to a sprite of a cross with the center at (3,3)

gGetKey

DispGraphClrDraw
EndIf getKey(15)

Am I doing something wrong here?

matrefeytontias

Well yeah, you can't write bytes outside of $8000-$FFFF. Anything before that area has no effect since it's Flash memory.
  • 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

ben_g

I swapped a RAM page in $4000-$8000, so it is in RAM. And I also move vertices based on the position of the cursor, and they work, indicating that the cursor values are indeed changing.

TheMachine02

Your code look fine, apart the fact that it need to setup a matrix to run (but I suppose you've done it), so I can't really tell  :-\
Also, there is no more camera, only a 3x3 matrix for scale and rotation, along with a 2x3 bytes vector holding translation. So you can just tra,slate your point using gTranslate(Data(0r,0r,0r)) or directly writing to it at {°GMatrix+9}r,+11,+13. gTranslate will most likely  diseappear though, cause it is pretty much an useless command.




Snektron

Quote from: ben_g on May 04, 2015, 06:47:07 PM
I swapped a RAM page in $4000-$8000, so it is in RAM. And I also move vertices based on the position of the cursor, and they work, indicating that the cursor values are indeed changing.
Actually, is it safe to use $4000-$7FFF? I mean the os uses it for flash pages all the time so you should just be able to push the current page, do anything with $4000-$7FFF and then pop the page back in without breaking anything right?
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


tr1p1ea

It's safe so long as you are careful with BCALLS and such. There are many programs that utilise this area without causing harm.

I for one am always looking for good screenies, are there are new ones for this project? :).

Powered by EzPortal