I have been chasing a problem with my grenade throwing code. They would disappear unexpectedly or explode at the wrong time or place.
I have lots of visualisation to confirm that the calculations are being performed and that the positions were correct and in view!
It turns out that the confusion was because I had unconsciously assumed that my update thread was always in advance of my draw thread.
Nearly everywhere else in the code the update does not matter if it runs out of sync with the draw thread but for grenades that have to bounce, the difference was noticeable. The collision is calculated in one thread but the grenade is drawn in another thread in real time.
Overall the update thread does less work and so has plenty of spare performance therefore it seamed logical in the back of my mind that it would process the collision faster than needed. What I had not allowed for is that it might have started after the draw thread.
I had varying results that I could not explain. Sometimes working and sometimes not which I now know is because it is multi-threaded. The launching of the grenade could sometimes be picked up instantly by the draw thread because that is where it was in its cycle but the update thread could be a few milliseconds or even a frame behind that draw.
Problem solved and another lesson learnt :-)
Posts
3 comments:
...speaking as the person John shares a home with, thank goodness that's sorted, he's been a complete nutcase all week!!
Why do your Update and Draw calls run in separate threads, does XNA behave that way by default?
No. By default XNA does everything on one thread.
The Xbox is not capable of running this game on just one core but there are 3 cores each with 2 hardware threads. 4 of those 6 hardware threads are available to XNA developers.
At the moment I try to have only draw code on the draw thread. Collision, AI, pathfinding and other stuff all run on separate threads.
Even with that split it has been a struggle to maintain a good frame rate.
Post a Comment