I wish I could show you the article I read in Game Developer magazine last month. It went into a large amount of detail about the many ways you can manage your code on a multicore processor. Do you want me to summarize it?
Ok. Well, firstly you could fragment your code and specify which chunk goes on which core. This is bad, for many reasons. It could make you get ridiculously out of order, causing the worst bugs to track down as well as make all of your variables be unpredictable. Next thing you could do is split it up into giant chunks, 3-4 of em. Lets say you have a chunk for physics, logic, and rendering. You could then easily seperate them onto different cores, right? Well, what if your physics code says you were shot but you game logic is already doen for that frame? Your character could be running around as a dead body just shooting stuff without being able to be shot. A solution for this would be to work one core delayed by the other. For example, you put physics code on one core, logic and rendering on another. The physics would fire off first for that frame, save its date, then next frame you do the logic and rendering code for the previous frame. You would still benefit from the speed of multiple core at the cost of the first frame of the
( ... )
Comments 5
Reply
Reply
Reply
Reply
Leave a comment