Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Qube

GLBasic - en / Re: 3D GUI?
In my 3D game I would prefer to have a 3D HUD which requires a few models at certain 2D screen coordinates. I can use the X_SCREEN2WORLD to get the 2D to 3D coordinates but naturally these objects rotate when the camera moves. As mentioned, using math to point the objects at the camera works fine but over distances you get wobble and vibrating of the 3D HUD objects as the math isn't perfect precision.

A 2D HUD / GUI is currently what I am doing but it would open up for improvement if I could draw all my world objects, reset and then draw my 3D HUD / GUI.

I was thinking on the lines of a secondary camera whereby you do your game as normal, then call the secondary camera and overlap the GUD / GUI on top.

Is that possible? or just best to skip the idea and stick to the common practice of a 2D HUD on top of a 3D world?
GLBasic - en / 3D GUI?
My main reason for this is to be able to do a 3D GUI on top of the current 3D world I've drawn. I've tried with math but after a while objects begin to bounce and vibrate, which is not good  :'(

For example, say you wanted to have a spinning cube at the bottom left of your screen while allowing the camera to fly around a model of a car. If you use X_SCREEN2WORLD and then math to point the model at the camera it works great until the camera location is far away then we get object bounce and vibrate.

Is there any way to reset the 3D world in order simply overlap a 3D gui?

I've noticed the outlines of particles when I use particles of vastly different sizes together. Luckily for what I need right now I'm OK with the above method as I only need a very basic particle system.

When my current game is finished though I *must* revisit this area as it's been driving me nuts and I *will* get it working properly  :P

Yay!! sorted out my particles using x_sprite and getting past the z-ordering issue  :good:

The z-ordering was a pain and wasn't making sense. What works for me is to draw all your 3D objects first. Then the last thing you draw is your particles. However, in order to get past the z-ordering issue I have to do a custom sort which is :

Code (glbasic) Select

// Particle[] is my array of type tParticle

SORTARRAY Particle[], ADDRESSOF(z_sort)

FOREACH blob in Particles[]
.... do your drawing of all particles - in my case X_SPRITE

Code (glbasic) Select

// tParticle is the type definition

FUNCTION z_sort:a AS tParticle, b AS tParticle
// CamX, Y, Z refers to the camera position
// Compare distance from camera particle to camera.
LOCAL temp1#, temp2#

temp1 = QSQR(((a.x - camX) * (a.x - camX)) + ((a.y - camY) * (a.y - camY)) + ((a.z - camZ) * (a.z - camZ)))
temp2 = QSQR(((b.x - camX) * (b.x - camX)) + ((b.y - camY) * (b.y - camY)) + ((b.z - camZ) * (b.z - camZ)))

IF temp1 > temp2 THEN RETURN -1
IF temp1 < temp2 THEN RETURN 1

Works spot on for me  :good:
Thanks for the tips :)

I did think about using a plane instead of x_sprite but wondered if there was a quicker way to keep x_sprite centred at x,y,z coords. I'll have a play and see what happens =D
I'm currently doing a simple 3D particle system for my game and it would be very handy to be able to have the X_SPRITE handle to be centred rather than bottom middle as it is at the moment.

Is there any way to use / have X_SPRITE draw images with the x,y coors referring to the middle of the image rather than the bottom middle?
I tried iOS5 beta on my iPhone 4. I really like where it's heading but the beta was far too buggy for my liking with apps just quitting at random points.

So I went back to iOS 4.3.3. I'm quite looking forward finished version though as it's definitely a step in the right direction.
Probably a silly idea but which version of XCode are you using? - I know there's an issue with XCode 4 iOS 4.3 with apps working fine locally but crash for Apple. This appears to be with GLB and Unity3D - Recommendations until it's sorted out are to use XCode 3.2.5 and iOS 4.2 SDK.

Another possible solution (again, assuming it's an XCode iOS 4.3 issue) is detailed here

X_GETMATRIX command, woohoo, many thanks for adding that in, fantastic help  :nw:
I find I tend to use a lot of global variables in games. My main train of thought on this is that if I need a variable to be used across a lot functions then it's much neater to use globals rather than passing variables over and over again as that would lead to a greater chance of mistakes.

Local variables I tend to use in for-next loops, temp variables for working out stuff or in functions that don't need those variables to be accessed outside of that function.

I also use the option in GLB to alert me if I have undeclared variables which pretty much puts a full stop to incorrect naming of global variables in routines where you scratch your head for days wondering what's wrong only to figure out you had x instead of X :p

Overall though, use what ever suits your coding the best, what ever you find the easiest to get along with. The only rule I do force myself to follow is commenting blocks of code so i can easily follow it when viewed weeks / months later.

Perfectly neat and compliant code to match the nit pickers of this world won't make your game any better :)
X_GETMATRIX - Sweet!!! - Can't wait to get my hands on that command. Many thanks indeed, Gernot, for adding the command in. It'll be a great help for the 3D side of things  :good:

Now all I need is sphere mapping support for iOS  =D
I'll implement X_GETMATRIX for you.
That'd be brilliant if you could. Woohoo, thanks  :good:

You want to push, push, push and transform the matrix and get the "final" position of the model then?
Yes, I want/need to be able to draw an object as normal then pushmatrix and then be able to get various real world coors from various movements, for example :

1.. rotate an object at various angles
2.. draw it on screen
3.. pushmatrix
4.. movement -1,0,0
5.. get real world coors if I were to draw an object here
6.. movememt 0,0,-1
7.. get real world coors if I were to draw an object here
8.. popmatrix

Hope that makes sense. You can then use such data in chasecam routines, special fx where you don't need to draw immediately during the push/popmatrix (cuts down on heavy cos/sin usage).

I'd find (and sure others) the ability to get the real world coors after x_movement in push/popmatrix a huge help in 3D land  :good: :good:
[Edit] My bad!  My code doesn't take rotation into account, which is probably why you are asking!  Hmm . . . tricky!
Yeah, not as easy as I was hoping either  :S

bet there would be an OpenGL call you could do to return / convert the current local and world space.
Any such call would have to work in iOS - Can't believe no one has ever wanted to get the coors of an object drawn in push/pop matrix  O_O

Anyone out there with a solution?  :giveup:
Me stuck :(

Lets say I've drawn a 3D object which is rotated and then placed with X_DRAWOBJ 1, 10, 10, 10 - I then use X_PUSHMATRIX / X_POPMATRIX to draw an object just behind it with X_DRAWOBJ 1, 0, 0, -1

Is there a way to get the real coordinates of the object I drew using push / pop matrix? - Or do I have to do some whizzy math?

Enough of the teaser shots  :P - Get that little beauty up to speed and release it :good:

I'd love to see a MAC IDE with the features and quality of the Windows IDE. I think it's needed being GLB is a multi-platform language. Hell, I'd even pay the same price as GLB itself to get a decent MAC IDE. Go Go Go  :good: :good: :good: