Process / Graphics threads

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.

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!

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.

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.

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.

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?

quote:

---

Original post by Mafian
Ive read the game books, that suggest you move things according to the current fps, but I didnt buy it.

---

Time to buy it, http://www.gamedev.net/reference/articles/article1382.asp

[edited by - randal on January 30, 2003 2:52:11 PM]

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.

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.

It''s an interresting approach, but one question about this: What data do you transfer to the client with the messages? I guess that all world vertices and models are part of the client, and that you transfer positions and special events (ie: movement, death or damage) to the client with the messages. I understand that you don''t want to transfer too much data.
But now, I run into a problem: my terrain class... it contains the vertices of the map, that are used both for rendering and collision detection. Or, a model, also with poly-level collision detection. You require to keep a copy of both on each side, and if my map is even a bit big, you might get quite a problem with the amount of memory you use.
Or am I overreacting here?

I can see how you would use the idea of FPS to scale movement, but this would require a more sophisticated collision system. Instead of moving objects one bounding area at a time and then testing for collisions each frame, you have to map the objects path as a FUNCTION.

Ive read that, and it makes sense. If two objects collide, their functions intersect, right? This would help those instances where objects skip past other objects due to low framerates, because as a function, all of its positions from point a to point b are mathematically defined. However, integrating this kind of system is not easy, and most likely takes up a little more CPU. It will also involve some calculus Im sure.

The server/client method would also probably work great for games. The trade off, like Structural seems to say, would be the necessity of memory duplication. But its almost a traditional tradeoff, memory for speed! The more memory you can ensure as "given" information, like maps, character models, etc etc.. the less the client has to figure out. If I spent enough time implementing this method, it sounds like it could easily be ported into a multiplayer game as well. Good idea.

>> I can see how you would use the idea of FPS to scale movement, but this would require a more sophisticated collision system. Instead of moving objects one bounding area at a time and then testing for collisions each frame, you have to map the objects path as a FUNCTION.<<

Yup! You need to solve things over time, rather than at an instant in time. There are numerous methods to go about simplifying the calculations of things like this.

For example, for collision detection over time you generally re-arrange the data so that you have all of the volume of both objects as one node and all of the motion as the other node(a ray). Then you have a ray-sphere, ray-bbox, etc test instead of two moving spheres over time, two moving boxes over time, etc.

-John

>>The key here is that the world data is stored in *two* places, once on the server and once on the client.

I would have thought that the world data has to be stored in *three* places, no??

The physics updates the world data in place 1. When the physics computed the new position for every object in the world, the entire world data is copied to place 2 by the physics thread. Every time the rendering thread is about to render a scene, it copies the data from place 2 to place 3. Then the rendering thread uses the data from place 3 to render the scene.

If you have only two places, which thread copies the entire data from one place to the other? the rendering thread? No because the physics thread might still be modifying the data in its place.
The physics thread? Neither, because the rendering thread might just be reading through half of its data.

I guess you need 3 places, no? Or did I misunderstood something?