Digital Paint Discussion Board
Development => Bugs, Feature Requests, and Feedback => Official Feature Votes => Topic started by: jitspoe on February 16, 2011, 10:28:00 PM
-
http://dplogin.com/dplogin/featurevote/feature.php?id=10251
This would effectively "fake" higher FPS rates. Instead of waiting for the graphics to finish rendering, the rest of the game logic (inputs, network, sound, etc.) would run continuously, and rendering calls would only be made when a frame finished rendering. If you had a crappy graphics card that only rendered at 10fps, you could still potentially run the game at 100fps, but only 1 in every 10 frames would be rendered.
I think I have a clever way to implement this by simply putting the qglSwapBuffers in a separate thread and not making any OpenGL calls until it finishes. Of course, it will probably end up being more complex than that.
-
Wouldn't that need more cpu power and looks ingame, like the other players are lagging?
-
Actually, it would smooth out the movements of laggy players (if they were laggy due to low framerate). The game would be more responsive, and network updates would be more frequent, you would just be limited to seeing them by your video card framerate. It would be like you're playing at 100fps, but you only see every Xth frame.
-
That make paintball more optimised for 2cpu processors.. +1. I'm surprised, because i think that was already done... What paintball uses 14 threads for? -.-'
-
Ok, why not.
-
That make paintball more optimised for 2cpu processors.. +1. I'm surprised, because i think that was already done... What paintball uses 14 threads for? -.-'
14? o.O. I think the only thing I use multithreading for is the server browser, so it can run through and ping servers without freezing up the UI. Maybe some login stuff, too.
-
14? o.O. I think the only thing I use multithreading for is the server browser, so it can run through and ping servers without freezing up the UI. Maybe some login stuff, too.
Yes, 14, watch attachment ('Wątki' mean threads. I love Polish too).
With my testapp which had 3 threads it says 4 threads... So Windows7 lies. But i guess that in menu paintball have something like 8 threads? OpenGL? Sound? Everything could create thread... But one thread uses most CPU time (like 50% ingame on 2x2,5Ghz).
-
With my testapp which had 3 threads it says 4 threads...
Maybe your app spawned 3 threads? If it did, then it would have 4, because even if you spawn none, you still have 1 thread.
-
Well, the number of threads doesn't really matter. There's probably some libraries creating threads under the hood or something. Paintball2 is almost entirely single threaded. Waiting for the render to finish in its own thread would allow the game to run at a much faster "framerate" and stop choppy sound and movement (I think).
-
Maybe your app spawned 3 threads? If it did, then it would have 4, because even if you spawn none, you still have 1 thread.
1.Mainthread
2.SendThread
3.RecieveThread
so 3... first one is main (that i didn't spawned).
Waiting for the render to finish in its own thread would allow the game to run at a much faster "framerate" and stop choppy sound and movement (I think).
...And make it more optimised for dual cpu, so yes, thats good idea. But when talking about laggy computers, then i guess that graphics card isn't mostly used component. CPU is, so creating two threads on one core could lag more than one thread. But there is no sense to speak about that (because no one really knows what will happen), you need to check this.
-
And make it more optimised for dual cpu...
+ quad core cpu :P
-
Do it. ;)
-
Would you call this a feature or a tweak? I notice jits marked it as a feature but it sounds more like a tweak to me.
-
It requires new functionality, so I'd call it a feature. Multithreading isn't trivial.