Hi all, I've created a 3D World inhabited by cubes (stupid I know, but I'm going someplace with that). One could navigate that world in any direction by taking 90 degree turns sideways or up/down and by moving forwards and backwards. In order to achieve that I used 2 vars as a state machine storing the direction in which the person navigating the world stares and the person's normal to the world, where the normal initially points upwards. It seems a pretty stupid way of doing things, after all in a smooth flowing game you don't keep an infinite (OK, large) amount of state variables. Do any of you know of a better way to achieve consistant movement?

State machines are used suprisingly often in game development. You are doing OK, if I understand your question right.

Thats a pretty standard way of doing things. The camera in my engine uses three vectors ( the up and front vectors, + position vector ), and they're modified when needed ( for instance, a signal to move to the left, or something along those lines ). There's nothing "stupid" about it at all, it's pretty standard (and simple too). I don't know where you get the idea of having loads of state variables.

Quote: Original post by python_regious

I don't know where you get the idea of having loads of state variables.

What I mean is that I calculate the position of the objects in the world according to how I move my camera. That is, my world is centered around my camera and moving the camera or pointing it in another direction moves the objects so as to give the feel of the camera moving. In order to remember how the objects are offset by the camera's movement I record the camera's position with the help of two state variables. One stating which direction the camera is pointing at, and the other which direction the camera thinks is up. Since I only make 90 degree turns I have a cross product of 6*2 different states (I have two variables but in actuallity they act as 12 boolean variables). In a more reallike world the camera turns much more subtly. So if I go on like that I might have 2 state variables but dozens of cross product situations to address. That seems odd to me, but I am new at this. As for your icon, if its drinking Guinness I'm all for it. Slainte!

I'm not really sure what you're trying to do/are doing.

Ok, you have a camera. This camera has 4 vectors ( forward, side, up and position ). These 4 vectors are arranged to become the camera matrix, which is 4x4.

When it comes to rendering, you apply the camera matrix to the vertices of the world to transform them into camera space. In OpenGL, this amounts to multiplying the modelview matrix by the camera matrix.

When you move the camera, you change those 4 vectors. ( I personally use angle-axis methods to rotate the 3 basis vectors of the camera ). The position vector is a simple translation.

The hardest bit of it all is transforming the camera basis. As I said, I use an angle-axis method, but there are lots of other alternatives.

Not sure what you mean. If you consider an average FPS game there is an infinite (literally) number of positions a player can be located at represented by three variables (X, Y, Z). Such a game has an infinite number of potential states. Do I understand what you're saying correctly? If so, where's the problem?

Quote: Original post by CoffeeMug
If you consider an average FPS game there is an infinite (literally) number of positions a player can be located at

[irrelevant crap]
I'm just going to be pedantic has hell for some fun ( don't take offense :) ). Since the world is stored digitally ( talking about the fps here - not the real world ), it's quantised, and so can take a finite number of possible, descrete states.
[/irrelevant crap]

Anyway, I don't get what the problem is Yaniv. I've read your posts multiple times now, and I just can't seem to find it...

Quote: Original post by python_regious
[irrelevant crap]
I'm just going to be pedantic has hell for some fun ( don't take offense :) ). Since the world is stored digitally ( talking about the fps here - not the real world ), it's quantised, and so can take a finite number of possible, descrete states.
[/irrelevant crap]

[irrelevant crap]
Well, the memory chips and the processor can take a finite number of states. You could argue that the world itself can take an infinite number of states (after all, we do use floating points), but these states would be "rounded off" by the hardware :)
[/irrelevant crap]

[more irrelevant crap]
Well, the definition of digital is basically "quantised". To have anything run on digital system, it would have to be digital data ( i.e quantised ). The floating point format has a finite number of values it can take, as it's a descrete range of the real numbers.

...

I can't actually remember what my point is. Oh well! ;)
[/more irrelevant crap]

You've got no storage of the absolute locations of the objects? Only their location relative to the player?

I'd worry about rounding errors personaly. Especialy on rotations.


Or maybe I missunderstood you. That's very possible.