You need another thread.
Basically, you should never need anything to be done more than once per game loop. Games are not real-time, the user won't be able to know if you are running at 60fps and emitting a particle every 5ms or if you simply emit 3 per loop.
If you want twice the particles if the game was running at 30fps, then I'd argue against the idea since you're only getting 30fps. But to simulate 5ms timing, divide your frame time by 5ms, and emit that many particles. Then at 60fps you will get 3, at 30fps you will get 6, etc.
But I'd strongly suggest re-thinking what you're trying to do. Odds are you can achieve the same thing for much less work and overhead that will give the end user the same experience.
Accurate timing in the game loop
You need an accurate timer; and then make a separate calculation loop and a render loop. You call these in your main loop and you can call these at any time interval. No need for threading imho. Of course threads can; but will make things complicated.
Author
Quote:Original post by gekko
But I'd strongly suggest re-thinking what you're trying to do. Odds are you can achieve the same thing for much less work and overhead that will give the end user the same experience.
This is mostly theoretical thinking. In the games I've created so far (pong, snake, tetris), the naive approach I described in my original post worked just fine (or seemed to work just fine. Some of the posts in the link I gave earlier show that this stuff can be tricky to get right, and you might not even notice if it's wrong).
I was just trying to think ahead for more complex games. For example, if you have a machine gun, it should fire at a very high rate of fire, so maybe firing just one bullet per-frame won't be fast enough.
This is also an attempt to better understand the discussion over here.
I guess I need to try and implement this, and when I'll actually encounter a problem I'll know what questions to ask.
Thanks everyone for their comments.
The code MJP posted will solve that issue, as it will execute the code x times each frame to compensate for the fact that your game is running at 60 hz instead of say 200 which is the machine-guns rate of fire.. The user won't notice this and he can't, the world state is only rendered at 60 hz anyways.
Quote:Original post by Gage64
I was just trying to think ahead for more complex games. For example, if you have a machine gun, it should fire at a very high rate of fire, so maybe firing just one bullet per-frame won't be fast enough.
That's not the way to go about doing this. Just fire more bullets per frame in that scenario.
Quote:Original post by Gage64Quote:Original post by gekko
But I'd strongly suggest re-thinking what you're trying to do. Odds are you can achieve the same thing for much less work and overhead that will give the end user the same experience.
This is mostly theoretical thinking. In the games I've created so far (pong, snake, tetris), the naive approach I described in my original post worked just fine (or seemed to work just fine. Some of the posts in the link I gave earlier show that this stuff can be tricky to get right, and you might not even notice if it's wrong).
I was just trying to think ahead for more complex games. For example, if you have a machine gun, it should fire at a very high rate of fire, so maybe firing just one bullet per-frame won't be fast enough.
This is also an attempt to better understand the discussion over here.
I guess I need to try and implement this, and when I'll actually encounter a problem I'll know what questions to ask.
Thanks everyone for their comments.
Interesting...I suppose are cases where simulating concurrency will break down quite quickly. Unfortunately I don't really know of any sure-fire solutions, so I can't really help you out. If you do come up with anything, be sure to share with us. [smile]
Quote:Original post by Gage64
Then I'll repeat my earlier question: How do you determine what time-step to use?
Say you want the machine gun to fire 200 times per second, if float dt is in seconds your timestep for the bullet fire code should be float timestep = 1.0/200.0
Author
Quote:Original post by lexs
Say you want the machine gun to fire 200 times per second, if float dt is in seconds your timestep for the bullet fire code should be float timestep = 1.0/200.0
Quote:Original post by Gage64
That can't be right. I can have many actions, some of which will be performed every 5 ms, some every 50 ms, etc, so the time step has to be based on something else.
Quote:Original post by Gage64
I was just trying to think ahead for more complex games. For example, if you have a machine gun, it should fire at a very high rate of fire, so maybe firing just one bullet per-frame won't be fast enough.
Even the typical machine gun probably won't need to fire more than 20 times a second. But remember the aim of a game isn't necessarily to simulate every single bullet.
Your original suggestion is good enough, with a small modification. If you need to do something every 10ms, but 16ms has elapsed, then you do whatever needs to be done, and you cut 6ms off the schedule for the next one. It's a tiny bit more complicated when your timestep is big enough to encompass two sequential events rather than just one. The system perhaps needs to repeatedly ask the event generator (eg. the gun in this case) for the next event, and if it's due, handle it, and if it's not, leave it for the next frame.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
