GP32 3d Routines/engines To Use


pea

developer
Joined
Oct 3, 2004
Messages
1,089
Age
45
Location
New Zealand
Website
www.projectitis.com
Hi all,

I am wondering if anyone has any experience with the 3D libraries out for the GP32. I have read about a few. I am wondering which are the fastest and most powerful.

Klimt is openGL based, which is nice. But is it fast? Is it stable? Are the 'reversed' textures useable?

Yeti - I have read lots of good stuff on their website, about how they do all this fancy clipping, and converting operations to use addition instead of multiplication etc all in the aid of speeding it up on mobile devices, but I have also read that it is still slow!! Is this true?

Are there any others?

Thoughts please :)
 
Well, Klimt is what was used on MGS: VR missons. I think you
can get that game from 16days or gp32x.de. Klimt is the official
Gamepark one, I think...
 
OMG I just downloaded yeti3D (from the downloads section, EvilDragon - you may want to add it to your site too) and played the demo that comes with it.

I was so impressed! That thing 's got wings! It goes at some horrible rate of knots, I couldn't even keep up :p

Anyone know:
1) What clock speed the demo runs at (the source of the demo is not included)
2) Whether any updates have been made to the GP32 version of yeti3D
 
Firstly, Klimt isn't official (there isn't an official 3D solution) - its another ported library, and considering its OpenGL, its remarkably good (even if it does run slower than a 3-toed-sloth on some sleeping pill or other).

Secondly, I was fairly sure there was a zip released that did include the source. Indeed, the archive is here. You might also be interested in the archive of yeti news on GP32news (I think more extensive than here, not sure) - just go to the site, and search for Yeti at the bottom of the page. There's some tutorials, proggies to help with yeti creation, etc.

Might also want to contact ThunderZ and ask if there's been any progress beyond the initial release, seeing as essentially its his project, so far as I know.
 
Thanks Tobriand

I have the source for yeti, just not for the demo, so I am unable to see what the clock speed is set to for the demo.

Thanks for the heads up on GP32news... I'll check it out
 
The last GP32 version of Yeti was based under the Yeti Pro version.

_ Curved surface
_ MD2 model + animation + interpolation
_ mipmap
_ corrected texture mapping
_ slope
_ shadows more acurate
_ and lot more....

You could use easily GP32 GPL version.
You have :
The code source of the engine.
A level editor
Code of the demo
Convertor tools
Some map an exemple done.

Well you have all :)
 
Hello,

aucune chance de voir au moins une demo de la derniere version gp32, TZ ?
any chance to see at least one demo of the last GP32 version, TZ ?

Thor
 
Salut,

ca fait plaisir de te revoir :)

Pour une demo de Yeti, je suis même pas sur que ca intéresserais quelqu'un donc bon ....
Actuellement je bose pour Int13 (www.int13.net) et je compte bien en profité pour pouvoir faire sortir les futurs jeux sur GP32.
Je vais bosser après mon projet actuel sur un gros gros moteur 3d ecrit depuis rien.
Ce qui est prevue :
_ landscape
_ objet 3d animé
_ lumière dynamique
_ microbsp pour les scenes intérieurs
_ et des outils type plugins exporteur pour 3DSMax
_ .....

Voila :)

-------------------------
Yop,

Nice to see you again.

For a demo of Yeti, i'm not sure that this will be interesting for anybody so ...
Actually i work for Int13 (www.int13.net) and i'll try to profit of this to add more game for the GP32.
I'll work after my actual project on a big big 3D engine writing from scratch.
Some of the feature plan :
_ landscape
_ 3d object animated
_ dynamic lything
_ micro bsp for the internal scene
_ and tools like 3DSMAX plugin for export our object
_ ...

That all.
 
Cool, thanks TZ.
Just to clarify, this is the version that has in the readme:

GP32 Specifique port - 19:37 PM 05/11/2003

Is this the latest version?
 
For a demo of Yeti, i'm not sure that this will be interesting for anybody so ... <- i would be intrested, jsut to see that ti works, no matter how slow
 
I would too! The one currently with the GPL version for GP32 is very cool, but doesn't have curves or slopes, and i would love to see an outdoor environment!
 
I'd also like to have a look at yeti, because I wan't to start 3d programming but I don't feel I can write my 3d engine yet...
 
yea me too, its always cool to see some demos just for the eyes ;)

@TZ: one another 3d engine from scratch? so, whats happening with yeti then :huh:
(im gonna try in francais too :p im learning this language right now, so just for fun: une autre 3d enginé (oO) de "scratch"? mais, qu'est-ce que yeti fait quand tu developes la nouveau engine?)
 
I want to make a new engine with very fast draw routine for use it on my project and using it like a lib.

I want to make it with is proper capacity to do a lot of different game type.
So it's for that i'll rewrite a complete engine. :)

Maybe you see in some month some great 3D game under GP32 ;)
 
I want to make a 3d engine, but I don't know how to start. The only 3d related stuff I've done was a simple raycaster in VB that drew grey walls (rather jaggedly) from a bitmap image with the walls drawn in. Now I know 3d engines require a coordinate system, so you can incorporate textures and smooth lines and edges and stuff, but I'm stumped. How do you clip the walls that are farther away? A raycaster that detects walls maybe, and then it'd draw the "visible" walls from far to near, to layer them properly to the screen. Wouldn't that be kinda slow though? o_O

Oh well. As a programmer I've just always wanted to try this. Now I have motivation to, to possibly develop a simple and fast 3d engine for the gp32.

I am learning C++ (in console form, but windows form would just require knowledge on how to make a window come up and draw lines and stuff).

Yeah... not directly related completely to the gp32, but what the heck, it's a start. :)
 
The most easy way is the "Painter Algorithm".

Draw back to font the polygon.

This is the most easy way i think.
 
You could create your own z-buffer?

This means you would reserve an area of memory equal to the size of the viewport (read:screenbuffer), so 320x240. Then You draw your polys Nearest to furthest.

For each pixel you render:
1) Check the z-buffer, if the z-value of the pixel already drawn at that screen location is CLOSER than the one you are going to draw, discard it.
2) otherwise, draw the pixel and write its depth into the buffer.

To speed it up:
Don't calculate the z-depth of every pixel, just the average over the poly, and use that for all pixels in that poly. Of course this could cause clip[ping issues in complex scenes or intersecting polys at funny angles (especially large polys), but could be ok.

To conserve memory:
Use 8bits for the z-buffer and convert z values to byte (you will loose accuracy, but it will still be good enough for comparison). The problem is that this will increase the math for each pixel, as you will need to SHR (to divide).

Hope it helps
 
I agree with pea; a z-buffer's the way to go. Check out "Tricks of the 3D Game Programming Gurus" for more information; it goes over the basics of software rendering well, and builds on a semi-API independent base which can easily be ported to the GP32.
 
Back
Top