Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Mafian

Process / Graphics threads

This topic is 5619 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, I dont know too much about multi-threaded coding yet, but I am under the impression that this enables two lines of code to execute psuedo-simultaniously, seperate from each other. Now, people seem to try so hard to lock their framerates at a specific number, and calculate game physics inbetween frames, etc etc etc... But what if you just had two sperate threads? Could you, say, have one thread calculating the finite state machines, where they are, what theyre doing and the like, and then have ANOTHER thread that just constantly displays their position? It makes sense when I think about it. That way, the frame rate doesnt suffer from a slowdown in game processing and game processing doesnt slow down due to graphics processing. Right? I feel like a genius, but kindred spirits tell me its not so easy. Does anyone else think this idea is feasible?

Share this post


Link to post
Share on other sites
Advertisement
Your idea has merit. In fact, SGI implemented multithreaded rendering/processing in their Performer library (somewhere in the late 80''s to early 90''s). There are up to 3 threads possible: APP, CULL and DRAW. It''s designed to run on multiple processors. One thread per processor (with non-degrading priorities). This arrangment gives the performance increase that you are envisioning.
On single processor machines, however, will not give you performance boost that you think. The one processor has to do both jobs that you mentioned, regardless of the threads.

Share this post


Link to post
Share on other sites
Like the previous poster said, your idea is good but there are some issues you''ll have to deal with, mainly synchronization of access so that you''re not trying to display an entity that''s being updated by the other thread! I can see places where an object may be locked for update by one thread and miss getting rendered for a couple of frames, there are ways to fix this but you start to lose the advantages of multithreading by implementing complex lock and state-safeness code.

Probably be cool to try just for fun, though!

Share this post


Link to post
Share on other sites
I recommend strongly against having two CPU-bound threads fighting for the same processor. If one thread was doing I/O and the other some CPU-heavy task, that''s OK and may even simplify things for you. But graphics and physics are both CPU-bound tasks and are better off living in the same thread.

Of course, you could target dual CPU machines with two different threads if you like, but who has a dual CPU machine these days?

If I had my way, I''d have all of you shot!


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
If your graphics rendering isn''t really pushing the CPU because of vsync synchronization, then it''s not CPU-bound. My game uses this method.

Share this post


Link to post
Share on other sites
Here''s the main problem with threading in a graphics app like you''re talking about.

Both threads are working on the same data. One is updating the data states and another one is reading those states to draw the data to the screen.

Because of this, you end up needing to put TONS of locks around your data accesses to insure no dirty reads or writes. What that will end up doing is *slowing down* your game because of all the additional synchronization calls. Not to mention the fact that on a single processor machine, the CPU will be task switching between the threads constantly, slowing it down even more.

You''re better off just using a single threaded game loop to do all this stuff.

However, there may be points at which starting a separate thread to do some work is worthwhile, but that really depends on what the work is and how it interracts with the other data.

Most graphics apps don''t need to rely on threading to increase their processing speed, since most of the actual drawing is done on the video card. That''s what hardware acceleration is, you know. The CPU isn''t doing the drawing, the video chip is. So, you really are only doing your state updates on the CPU and not your drawing.

To summarize, only use threading if the two threads are working on completely different sets of data.

Share this post


Link to post
Share on other sites
I didnt think about locking the data to protect it from the other thread... now that you mention it, it could get complicated.

But at the same time, how is it that all the Quake based games (probably any 3d shooter, for that matter) easily "seperate" the two processes? When you play Half-Life, for example, you can be crunching 150 fps, but at the same time, the movement and timeline in the background remains constant. Even if you run at a trajic 20 fps, the game looks choppy, but the timeline remains. Ive read the game books, that suggest you move things according to the current fps, but I didnt buy it. Sure that method works ok if youre playing something like pong, but how well will it fare in a complex environment, consisting of hundreds of finite state machines in a 3d world?

How else could you achieve the effect that the simulated world is indeed consistent, and the rate at which you peek at it depends solely on your graphics capabilities?

Share this post


Link to post
Share on other sites
I''ve been thinking about having a seperate physics thread too, but I didn''t do this yet because I had doubts.
At this moment I use the time between the frames to calculate the speed of the physics.

For example: I define that my player can move 3 units to the right in one second, and I see that the time between the last frame and this frame was 0.01 seconds, then I multiply the movement with the time that has passed, resulting in 0.03 units movement. I update all physics every frame before everything is being drawn.

The only problem with my method arises when the framerate is very low. This means that physics and AI become delayed and actually effect the gameplay. For example, a pong game: if you have a very low FPS (1 frame per second) and you want to see if the ball has hit the wall, the ball could have moved BEHIND the wall in that one second. This doesn''t look very nice ofcourse, but who the hell plays a pong game on 1 FPS.
Another example, a FPS... imagine you have a rocket, that is traveling at 20 units per second, and your opponent is 2 units wide. If the rocket is 1 unit infront of the opponent the first frame, then the frame takes 1 second to be drawn the rocket will be 19 units BEHIND the opponent the second frame (it moved 20 units in the time of being rendered).
There are solutions to this problem like raytracing/shooting, but they can be quite a problem if not worked out properly.
The hit that AI takes in this situation is even worse and I don''t know how (or "if") these are being solved in games.

Anyway, what I would like to know is if my personal approach is somewhat right. As I''ve said, I have doubts about multithreading the physics because of the potential problems of data integrity that have been discussed in this thread.

Share this post


Link to post
Share on other sites
One way that a lot of games handle this is by separating the drawing "client" from the game state "server" - i.e. client/server programming.

The server and client can be in two separate threads, in two separate processes or even on two separate machines. However, the different here is that the communication between the two is done through a messaging subsystem, rather than through critical sections. This is one place where threading could work because of the data separation.

The server constantly updates the game state, not worrying about the graphics capabilities of the clients. Connected clients retrieve game state updates after each rendering loop and update their displays accordingly.

The key here is that the world data is stored in *two* places, once on the server and once on the client. The client''s world state, however is not authoritative and must constantly be checked against the server world state by use of the messages it periodically receives. So, it''s kind of like having a checking account at the bank. The bank''s books are authoritative. You keep your own records, but you also reconcile them with the bank''s records every day or so.

This removes the problem of thread synchronization and locking data that I talked about before and can also deal with problems like the missile ending up on the other side of the wall rather than striking it. This is because the server is not limited by the graphics abilities.

Hope this gives you some ideas.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!