light position question
Author
This is a performance related question i think...
I have a simple 2d car that moves around the screen. Everytime it is updated I also update the position of a light so that it is within the bounds of the current viewing area. Therefore, to me that would mean the light should be flickering around the screen at a seizure inducing rate, pretty much when the car moves, the light should move. Instead, the light seems to move about once per second, whereas I have had the car clamped anywhere between 22 fps and 80 fps (ie the car is getting updated that fast, but the light doesnt seem to be ). My question is: does changing the position of the light have a drastic performance hit in regards to the fact that my machine would not be able to handle the light changing position 22 - 80 times a second.
I am very interested in your responses.
Author
does anyone have any ideas on this . . . someone has had to have some experience with this perhaps . . .
I have no idea what is causing your problem; your description seems unclear. It is nothing to do with performance anyway; if updating the position of the light took a second, it would affect the overall framerate (ie, the car would update at 1fps).
I suspect the problem lies in your code which updates the light position.
Just out of interest, how are you implementing lighting in 2D? 2D usually implies uniform normals (straight down the Z axis), and that makes lighting pretty pointless, since the light distribution would be uniform too.
I suspect the problem lies in your code which updates the light position.
Just out of interest, how are you implementing lighting in 2D? 2D usually implies uniform normals (straight down the Z axis), and that makes lighting pretty pointless, since the light distribution would be uniform too.
Author
sorry, didnt mean 2d, the car itself is a flat polygon and the camera is lookng top-down, so in my mind, everything is pretty flat and well 2d. I understand what you are saying. i just realized that the headlights of the car are updated every frame properly, so i must be updating my other lights position incorrectly. I want to say that the car''s lights move with it because I update them in the car''s draw method, whereas the other lights are updated in the glutTimerFunction. what do you think about that . . .
Don''t use the glutTimer function to update your lights. Do it once per frame in the main loop.
Author
in my timer function i keep track of a boolean that tells me whether or not the right click menu has been accessed. If it has not then we are animating and in that function i move everything, the car, other objects, and the lights.
What main loop do you mean.
I have my display function, timer function, mouse, keyboard, and special char functions.
What main loop do you mean.
I have my display function, timer function, mouse, keyboard, and special char functions.
I meant somewhere in the glut main loop. The display function is probably a good idea.
Just make sure you''re not putting anything which needs to be done per frame in the timer function. This includes updating animated light positions, drawing code, physics etc. The timer function, as you probably know, isn''t guaranteed to be executed once per frame.
Just make sure you''re not putting anything which needs to be done per frame in the timer function. This includes updating animated light positions, drawing code, physics etc. The timer function, as you probably know, isn''t guaranteed to be executed once per frame.
Author
well that is my problem them. I was actually under the impression that the timer function is what controlled the frame-rate, therefore it would have to be invoked once per frame. In my mind I was thinking timer() --> move() --> draw() --> timer() --> move() . . . etc.
Would you care to elaborate more on the more probably flow of events.
thanks again.
Would you care to elaborate more on the more probably flow of events.
thanks again.
THe event structure has nothing to do with your issue. But rather that you are using glut and its timer. the timer will update at the time you say give or take 1.00001 second or something. just because the drawing is occuring does not mean that your lights will be updated in that frame. because if you have something like a your car that is running at 80 fps then your timer would have something like 0.012 seconds to update the lights and return.
Note: that it is best to update your values while in the main loop of your program. the main loop is the control loop or what ever someone might call it.
while(!done){
draw(*myObject);
}
The way you are building your application you must have hundreds of global variables. that have keystate, mouse, menu and render state.
It would be best to not use glut. but obviously this is not going to be a highend game so it should be ok. However functions with parameters and pointers to data structures should be used when ever possible. Its easier to push a pointer unto the stack of a function than copy the whole variable from one function to another.
Before continuing RTMF .... ANSI C v2 ... or better known by the best c programmers as R&K reference manual. They wrote the language at AT&T. So best to read from the guys who thought of it first than to read a interputation of the original.
Note: that it is best to update your values while in the main loop of your program. the main loop is the control loop or what ever someone might call it.
while(!done){
draw(*myObject);
}
The way you are building your application you must have hundreds of global variables. that have keystate, mouse, menu and render state.
It would be best to not use glut. but obviously this is not going to be a highend game so it should be ok. However functions with parameters and pointers to data structures should be used when ever possible. Its easier to push a pointer unto the stack of a function than copy the whole variable from one function to another.
Before continuing RTMF .... ANSI C v2 ... or better known by the best c programmers as R&K reference manual. They wrote the language at AT&T. So best to read from the guys who thought of it first than to read a interputation of the original.
You mean you have your glutPostRedesplay call in your timer function? In that case, yes, it should be called once per frame. However, that approach is likely to have a negative impact on your framerate overall, as event driven timers are not usually very accurate. Whenever I''m forced to use GLUT, I put a glutPostRedisplay int the display function. The reason is, when you''re coding a game, you always want the window to be redrawn every frame. I''m not sure what the cause of your problem is, but perhaps you should try this approach.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
