Hi all,
I got two very interesting and different responses to my
threading problem. The first suggestion is to insert delays
into my code to free up the system multitasker. The second
suggestion is to drop the second thread and use the
millisecond timer to schedule my game logic and rendering.
Both suggestions are good in their own way, and reveal
something about threads I hadn’t really given much thought
about.
I’m going to experiment along both lines and see where it
leads. I’ve already followed the second line of thought a
bit, but by no means exhaustively. And I’m not quite ready
to give up on threads just yet - despite the overhead.
Along the lines of doing my own scheduling, well, there is
quite a bit of that already in my game engine (which is in-
tended to be as multi-purpose as possible.) Each individual
sprite maintains its own counter so that it can update as
often or as seldom as necessary. It’s as granular as it can
be, so that - theoretically - a sprite can update as often
as once per millisecond tick. If a game doesn’t need that
fine a grain then letting the thread sleep for 5 or 10ms
after each iteration would be alright.
I do recall having SDL_Wait calls in there at some point
(in the rendering thread, I believe) but I dumped them
as the engine started gaining some speed with threads.
The main reason I originally settled on a threaded model
was so that I could take advantage of the extra time between
a call to SDL_SwapBuffers() and the next VSYNC. Since we
don’t know what the refresh rate of the screen might be
(via SDL) there could be up to 59.99 60ths of a second lost
between the call and the actual buffer swap. In other words
the frame rate will drop from 60fps to 30fps once the game
logic takes just a smidgen longer than 1/60th of a second.
To be fair, I’m not sure how long it takes for an entire
loop through the game logic. (But it’s a bit faster since
I modified the pixel-precise level of my collision code to
use arrays in place of calling sin, cos, and sqrt!)
My one condition is that an entire “frame” of game logic
has to be run-through before rendering. No bailing out in
the middle.
I’ll continue to tweak and see where it leads. I dig the
"hands-off" nature of threads, so I hope I get to keep
them. Even with the added overhead my game engine handles
hundreds of colliding objects easily.–
Scott Lahteine <@Scott_Lahteine>
“No universe is perfect which leaves no room for improvement.”
(But, by all