Objects movement in 2D

No, you are on the right path already.

OpenGl functions only do rotations and translations for the Video card, their results are sent to the screen but do not come back to the CPU(at least not cheaply) and are not permanent.

The gameplay physics representation Should be separate from the graphics routine. Calculating the car position updates 'manually' is exactly how it should be done.
(you wouldn't believe how many people get this backwards, and try doing all their position changes in opengl then wonder why it all goes back to the last spot when the screen refreshes!) congrats.



my only suggestion would be in the future to abandon sin/cos in favor of a vector and orientation Matrix representation; since those allow instant rotations via glMultMatrix (almost direct interface to your own data structures), instead of glRotatef angles and whatnot conversions..

Quote:

Original post by bartii Hi. My question concerns objects movement in OpenGL. I'm a beginner to this subject, so please, be tolerant and patient ;) I want to move an object, let say a rectangle symbolizing the car, from one location to another in 2D. What's the easiest solution to complete this task? My solution is to keep coordinates (x,y) locally in the proper class (i.e. Car) and manually perform some calculations to get the new position of the car, based on sin and cos. It seems ok, but this approach avoids using OpenGL functions designed for this purpose, like glRotatef and glTranslatef - that's why I'm confused. Is there any other solution to solve this task? Can it be done using OpenGL functions only? If so, how to get the coordinates of the moved object? Thanks for all answers, marcin

Your approach is fine. OpenGL functions such as glRotate*() and glTranslate*() aren't really intended for the purpose of maintaining the state of game objects; they simply modify the OpenGL matrix stack for the purpose of applying transforms to rendered geometry.

Object position and orientation should generally be maintained externally, just as you're doing.

[Edit: What haphazardlynamed said...]

Quote:

Original post by jyk Your approach is fine. OpenGL functions such as glRotate*() and glTranslate*() aren't really intended for the purpose of maintaining the state of game objects; they simply modify the OpenGL matrix stack for the purpose of applying transforms to rendered geometry.

If so, then how are the complex calculations of objects in 3D done? Let say, that instead of my 2D-car i have a 3D-truck and I want to move it to a different place on my map. Do all calculations need to be done manually? Sounds strange, cause I thought that such a "math things" have a direct OpenGL support.

You also mentioned about using matrices and vectors instead of sin/cos. Could you recommend me some articles or examples about it?

First you transform the complex model using OpenGL, to make it appear transformed on the screen, then you transform it's bounding volume (which is usually very simplified) manually, to use with your game logic.
That's how it works in most computer games.

As for matrices, I see no real reason to implement a matrix system just to transform a couple of bounding boxes.
In my OpenGL projects, I just use sine and cosine lookup tables.
It takes about 5 minutes to implement and works just as fast as matrices (if not faster).

However, understanding of matrices is essential for computer graphics, as they are very useful for many advanced things.
Just do a Google search and I'm sure you'll find a lot of information on the subject.

Quote:

Original post by bartii If so, then how are the complex calculations of objects in 3D done? Let say, that instead of my 2D-car i have a 3D-truck and I want to move it to a different place on my map. Do all calculations need to be done manually? Sounds strange, cause I thought that such a "math things" have a direct OpenGL support.

No, OpenGL doesn't really offer math support per se. It only provides an interface to an internal math engine which is geared specifically towards transforming rendered geometry.

So the short answer is that yes, the calculations involved in maintaining and updating the positions and orientations of game objects, whether 2D or 3D, should be performed manually outside of OpenGL.

Quote:

Original post by mrbig First you transform the complex model using OpenGL, to make it appear transformed on the screen, then you transform it's bounding volume (which is usually very simplified) manually, to use with your game logic. That's how it works in most computer games.

Hmmmm. Could you be more specific, please? More detailed explanation would be very helpful for me.

You apply transformations to your model using OpenGL commands, then apply the same transformations to your model's bounding box manually.
The model is drawn on the screen and the box is used for collision detection ect.

Quote:

Original post by mrbig You apply transformations to your model using OpenGL commands, then apply the same transformations to your model's bounding box manually. The model is drawn on the screen and the box is used for collision detection ect.

Shame to admit, but I still have a foggy idea on how it should be done...
Applying OpenGL transformations to my model won't allow me to get the new position of the object. It must be taken from the "bounding box" which is transformed manually, right?
Assume that I want to model a 3D truck which consists of several parts, like doors, windows, lamps, tires. How to model this object? Use the local coordinates related to one central point? Use vectors? ...

Could you recommend a sample game code, so I could see how it is done?

Quote:

Original post by bartii Shame to admit, but I still have a foggy idea on how it should be done... Applying OpenGL transformations to my model won't allow me to get the new position of the object. It must be taken from the "bounding box" which is transformed manually, right? Assume that I want to model a 3D truck which consists of several parts, like doors, windows, lamps, tires. How to model this object? Use the local coordinates related to one central point? Use vectors? ...

When having a heirarchial or multipart object, yes, having the smaller pieces defined from local coordinate system of the central body or 'root' is often used.

However, for something like a car, where the many smaller parts don't generally move separatly from one another, it is more typical to only represent those only as graphics, while the game physics represent the entire car as a simpler single object like a box(bounding box).

Remember that Physics and Graphics should be separate; graphics are 3d model data that are complex and look nice, while the physics are usually as simple as you can get away with.

Quote:

Original post by haphazardlynamed When having a heirarchial or multipart object, yes, having the smaller pieces defined from local coordinate system of the central body or 'root' is often used. However, for something like a car, where the many smaller parts don't generally move separatly from one another, it is more typical to only represent those only as graphics, while the game physics represent the entire car as a simpler single object like a box(bounding box).

But I need to know where to place those objects, so I have to describe them in relation from the center of the car for instance.

Quote:

Remember that Physics and Graphics should be separate; graphics are 3d model data that are complex and look nice, while the physics are usually as simple as you can get away with.

So how to represent physics? Should I keep it as a series of points in 3D and perform appropriate calculations if needed? Or vectors?