a thread for updating attributes, another thread for rendering
Author
i just read this idea from an article but it didn't really specify its advantages and disadvantages. does this process eats running time? or memory? do you have to synchronize the two, or just let them free to execute? i think this really helps rendering stuff because the calculations may take slower than the rendering itself. if you separate the two routines and run them in parallel, the two routines becomes independent of each other. but i've got issues with efficiency. i'm doing mobile.
or am i talking right or just blaberring? come on, comments... thanks
Ok here are my views on this - so please no one quote me [smile]:
The design of having two threads to handle drawing and updating is just bad and inefficient. (Powerful words I know but rem my first line!). Anyways let me explain. Think about this - how does a game run the main loop? It calls Update and then Draw, and so on repeatedly until it is done. This is actually convient because you want to call update than draw, there is no need for update to be called more than draw or draw more than update.
If we were to accompish this with threads it would look like this:
Thread Update -> Runs
Thread Draw -> Waits for Update to finish
Thread Update -> Finishes, Activates Draw
Thread Draw -> Runs
Thread Update -> waits
Thread Draw -> Finishes, Activates Update
...
and so on. You can see the process. Now in this instance, we know that we want Update to be called once than draw - so why use threads when we can just call Update than Draw in the main thread? As you can see, we will add overhead and waste precious CPU cycles making threads wait and do nothing.
This design principle mainly applies to non-networking games! If you start networking, I would not say what I just did about this design. I hope you can see what I mean and I hope this helps out a bit - I too asked the concept of using threads like this and learned that it is really pointless.
As for your questions - Yes, you have to snyc them. What mobile uses threads, WinCE? I'm not familure with mobile code.
- Drew
The design of having two threads to handle drawing and updating is just bad and inefficient. (Powerful words I know but rem my first line!). Anyways let me explain. Think about this - how does a game run the main loop? It calls Update and then Draw, and so on repeatedly until it is done. This is actually convient because you want to call update than draw, there is no need for update to be called more than draw or draw more than update.
If we were to accompish this with threads it would look like this:
Thread Update -> Runs
Thread Draw -> Waits for Update to finish
Thread Update -> Finishes, Activates Draw
Thread Draw -> Runs
Thread Update -> waits
Thread Draw -> Finishes, Activates Update
...
and so on. You can see the process. Now in this instance, we know that we want Update to be called once than draw - so why use threads when we can just call Update than Draw in the main thread? As you can see, we will add overhead and waste precious CPU cycles making threads wait and do nothing.
This design principle mainly applies to non-networking games! If you start networking, I would not say what I just did about this design. I hope you can see what I mean and I hope this helps out a bit - I too asked the concept of using threads like this and learned that it is really pointless.
As for your questions - Yes, you have to snyc them. What mobile uses threads, WinCE? I'm not familure with mobile code.
- Drew
OT:
Speaking of threads, while i think for most games they are pretty pointless with the exception of animated loading screens/on-the-fly loading/sound/networking.
However as we all know(or should know) that processors are reaching their limits and not long from now, future PCs will have 2 processors on 1 chip. PS3 will be using Cell processors and the next XBOX is supposedly going to have 3 3ghz CPUs(Yes 3!). For current games, they will still run faster because 1 processor will be able to take the load of Windows/background programs(which i presume is quite alot of processing power). But besides that, developers will have to innovate and come up with ways to make full use of 2 processors at once if they want the additional power. As Drew has pointed out, games need to do things sequentially and i believe it is going to require a major change in the way games are programmed in the future if we are to take advantage of the new hardware.
Side Note: This is not the first time games have been developed on multi-processor based systems, the Sega Saturn had 2 processors and was deemed a nightmare for most programmers to program for. But Sega did manage to do some amazing things with it(Virtua Fighter2/Daytona/Panzer Dragoon).
Speaking of threads, while i think for most games they are pretty pointless with the exception of animated loading screens/on-the-fly loading/sound/networking.
However as we all know(or should know) that processors are reaching their limits and not long from now, future PCs will have 2 processors on 1 chip. PS3 will be using Cell processors and the next XBOX is supposedly going to have 3 3ghz CPUs(Yes 3!). For current games, they will still run faster because 1 processor will be able to take the load of Windows/background programs(which i presume is quite alot of processing power). But besides that, developers will have to innovate and come up with ways to make full use of 2 processors at once if they want the additional power. As Drew has pointed out, games need to do things sequentially and i believe it is going to require a major change in the way games are programmed in the future if we are to take advantage of the new hardware.
Side Note: This is not the first time games have been developed on multi-processor based systems, the Sega Saturn had 2 processors and was deemed a nightmare for most programmers to program for. But Sega did manage to do some amazing things with it(Virtua Fighter2/Daytona/Panzer Dragoon).
Author
Quite serious replies. Thanks for that. Now I'm guaranteed that what I've been doing is right after all. I use a thread in J2ME. It acts as the mainloop with its sleep routine giving time for other processes. I think every animated game in J2ME/Java is done this way.
Quote:Original post by GamerSg
However as we all know(or should know) that processors are reaching their limits and not long from now, future PCs will have 2 processors on 1 chip. PS3 will be using Cell processors and the next XBOX is supposedly going to have 3 3ghz CPUs(Yes 3!).
First, no, processors aren't reaching their limits. The clock speed isn't rising exponentially any longer, but there's still plenty of room for improvements in efficiency and performance. Second, the XBox 2 rumor was just that, a rumor. For the record, it wasn't 3 3ghz cpu's, it was 3 dualcore 3ghz cpu's. This is ridiculous for several reasons. 1) no game can take advantage of 6 cpu's. At the same cost you could make much more efficient improvements to a gaming system, and 2) I don't know how you would cool it, but we'd be talking about some 500 W of heat.
All that is known (as far as I know) is that it will use PowerPC cpu's, and as far as I know, they're not even available at 3GHz yet anyway.
Quote:Nope.
For current games, they will still run faster because 1 processor will be able to take the load of Windows/background programs(which i presume is quite alot of processing power).
Hit ctrl-alt-del and see how much cpu power other tasks than your game takes. The Task manager might take 5% or so to display this list, but apart from that, everything is shown using 0% cpu. That's not entirely accurate (More like 0.001%), but the point is that it hardly has a major performance impact.
For current games, dualcore chips won't offer any improvement at all (On the other hand, they'll generally have lower clockspeed than singlecore cpu's, so you might see a performance loss instead). Of course, if you want to run other tasks in parallel, a dualcore chip is going to come in handy. And when games start taking advantage of it, performance should go up as well.
Quote:Original post by Spoonster
Nope.
Hit ctrl-alt-del and see how much cpu power other tasks than your game takes. The Task manager might take 5% or so to display this list, but apart from that, everything is shown using 0% cpu. That's not entirely accurate (More like 0.001%), but the point is that it hardly has a major performance impact.
True, although perhaps a better way of measuring system time would be to record it while running the game.
Quote:
For current games, dualcore chips won't offer any improvement at all (On the other hand, they'll generally have lower clockspeed than singlecore cpu's, so you might see a performance loss instead). Of course, if you want to run other tasks in parallel, a dualcore chip is going to come in handy. And when games start taking advantage of it, performance should go up as well.
Clockspeed is high enough anyway since it isn't the bottleneck, and the dual core would also serve towards eliminating the irritating little "nags" when running many if small background tasks.
edit:
It all comes down to the sequentialization of the drawing and the calculation. In a perfect world, the calculation would always take place behind the scenes, when there was something to do, whereas the drawing process only has to satisfy the human eyes by updating at a steady rate.
/dc
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
