Page 3 of 3

Re: Display drivers programming

Posted: Fri Feb 24, 2012 6:09 am
by Solar
A 3D engine that syncs physics with FPS is crap. The solution to motion tear is motion blur, not higher FPS, because no amount of FPS will solve the underlying problem.

Re: Display drivers programming

Posted: Fri Feb 24, 2012 6:40 am
by FallenAvatar
Solar wrote:The solution to motion tear is motion blur, not higher FPS, because no amount of FPS will solve the underlying problem.
I wasn't referring to motion tear, but screen tear. Which happens when a screen is in the middle of being displayed on the screen and a new screen becomes available. It causes a line to appear on the screen where the 2 screens have changed. VSync does not necessarily fix this problem. It is supposed to, but as for when it does and does not, there are just too many variables to rely on it actually working.

And sometimes, it is preferable (in fast paced action games, at the competitive levels) to screen tear, in the hopes that the newer part of the screen will let you react just that much more quickly.
Solar wrote:A 3D engine that syncs physics with FPS is crap.
It's not that they are synced, but that they are dependent on each, in that rendering is dependent on physics. And having them in synch tends to give higher fidelity with physics simulations such as hit detection.

- Monk

Re: Display drivers programming

Posted: Fri Feb 24, 2012 7:24 am
by Solar
tjmonk15 wrote:I wasn't referring to motion tear, but screen tear. Which happens when a screen is in the middle of being displayed on the screen and a new screen becomes available. It causes a line to appear on the screen where the 2 screens have changed.
How would a higher FPS solve that, other than having two or more "tears" on screen?

You might want to note that many modern 3D engines no longer run "as fast as possible". (The Halo 3 engine, for example, "caps" at 30 FPS.)
And sometimes, it is preferable (in fast paced action games, at the competitive levels) to screen tear, in the hopes that the newer part of the screen will let you react just that much more quickly.
I won't tell you what I think of games or gamers "at the competitive level", because I would most likely be breaking forum etiquette.
Solar wrote:A 3D engine that syncs physics with FPS is crap.
It's not that they are synced, but that they are dependent on each, in that rendering is dependent on physics.
You got it the wrong way around. Of course is rendering dependent on physics. But physics should not be dependent on rendering, is what I say.

Re: Display drivers programming

Posted: Fri Feb 24, 2012 7:33 am
by Combuster
tjmonk15 wrote:EDIT: Changed super bright red for a darker one to help readability. Is it better now?
Still illegible. You only really helped the scarce few that use the pony theme. The rules mentions "no colours" explicitly for a reason.:roll:
You would have to add that code in probably 100+ places
That's the stupid solution, caused by a lack of ability to oversee the engine in its entirety.
The guys at the top don't care about doing it right
They do care about not getting their stuff back for not working.
Labelly Gamers as not very smart can be hazardous to your health
At least less hazardous as telling truths in China.
Brendan, also realize how stressful a game dev's life is. They generally work 80-120 hours a week
I should introduce a friend and lead game developer to you, just to show you how misinformed you are. What are you, a wannabe? :shock:

Re: Display drivers programming

Posted: Fri Feb 24, 2012 7:58 am
by brain
Combuster wrote:
Brendan, also realize how stressful a game dev's life is. They generally work 80-120 hours a week
I should introduce a friend and lead game developer to you, just to show you how misinformed you are. What are you, a wannabe? :shock:
This depends on where in the industry you are and how successful you are as with all industries. If you are near the top with a good library of prebuilt code to build games upon, of course you can churn out games in a regular 40 hour week and still have time to relax even at crunch time.
If on the other hand youre a one-man indie starting out, with no back catalogue of games and no existing code to build on you can find yourself working 80 hours a week to stay afloat, and just get that first game out of the door as you have to develop a working set of libraries, integrate them with an engine/framework etc and you will have no other team-members to split the workload with.
The same goes for just about any competitive industry, e.g. web design or even non-computing trades.

I speak from a little bit of experience in indie game development, which it flit between, in between bouts of operating system development and other application development.

Re: Display drivers programming

Posted: Fri Feb 24, 2012 8:07 am
by John
I recall some "wife" of EA employees complained to EA or to the press how her partner was working over time and suffering without a proper life etc. And I personally know developers who slog it out at over 70-80 hours week for prolonged period of time (close to a year) when they were near to the high time of their production. So, it could really depend on which stage of their production. But in general, I've the impression that it is true that games developers life isnt much of a life really.

Re: Display drivers programming

Posted: Fri Feb 24, 2012 8:08 am
by Solar
brain wrote:If on the other hand youre a one-man indie starting out, with no back catalogue of games and no existing code to build on you can find yourself working 80 hours a week to stay afloat...
That's not "staying afloat", that is having a non-sustainable business plan, and working hours well beyond the point of diminishing returns until you simply burn out.

If you can't do it in 40-50 hours / week, don't bother. (And 50 hours is pushing it.)

Re: Display drivers programming

Posted: Fri Feb 24, 2012 8:15 am
by brain
Solar wrote:
brain wrote:If on the other hand youre a one-man indie starting out, with no back catalogue of games and no existing code to build on you can find yourself working 80 hours a week to stay afloat...
That's not "staying afloat", that is having a non-sustainable business plan, and working hours well beyond the point of diminishing returns until you simply burn out.

If you can't do it in 40-50 hours / week, don't bother. (And 50 hours is pushing it.)
Yeah, you're most likely right and this is why i stopped trying to make money from indie games and just do it as a hobby :) Another issue is once you're done and release it, the market for such games is pretty small, most gamers want amazing technologically impressive multi-million dollar AAA titles, unfortunately.

Re: Display drivers programming

Posted: Sat Feb 25, 2012 12:27 am
by childOfTechno
Some observations:

@Solar:
A 3D engine that syncs physics with FPS is crap. The solution to motion tear is motion blur, not higher FPS, because no amount of FPS will solve the underlying problem.
The best way to handle physics is with a variable time step. You get the most responsive result, and you can calculate the position of the objects at a precise moment in time. You also need this for network prediction.

The solution to motion tear is double buffering and correct frame synchronisation, you render the next frame and swap the buffers at the next vertical retrace so the video card only ever sends whole frames to the display. Unfortunately this means you have to wait until vertical retrace before you can start rendering the next frame (a stall.) The solution to that limitation is triple buffering, which always leaves you with a free buffer to modify. Effective graphics engine design is *all* about eliminating stalls.

@ Brendan
Unfortunately, people who write games aren't smart enough to handle multiple threads (and often aren't even smart enough to add the "if(game_state_changed)" part and will redraw exactly the same graphics repeatedly when nothing has changed at all).
For one, a highly interactive computer game doesn't have to "play nice" with other tasks, the point is to deliver smooth interactive graphics, you may as well draw the frame as not draw it (and hog the CPU.) Secondly, games rarely show the same frame twice, there is always something moving (even if it's just an animated mouse cursor.) And thirdly, remember that 90% of the rendering load falls on the GPU these days so you may as well tell it to draw, it'll just sit idle otherwise.

People who write games are a lot smarter than you realise. What is the GPU if not another thread? The two major factors affecting graphics engine performance are cache stalls and GPU pipeline stalls. Modern games programming is all about careful thread synchronisation (of a considerably more complex type than for applications.)

EDIT: Oh, and as a side note, I've worked in the commercial games business. My advice is, don't, it's awful (60-70 hour weeks are the norm.)