Display drivers programming

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Display drivers programming

Post 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.
Every good solution is obvious once you've found it.
FallenAvatar
Member
Member
Posts: 283
Joined: Mon Jan 03, 2011 6:58 pm

Re: Display drivers programming

Post 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
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Display drivers programming

Post 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.
Every good solution is obvious once you've found it.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Display drivers programming

Post 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:
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
brain
Member
Member
Posts: 234
Joined: Thu Nov 05, 2009 5:04 pm
Location: UK
Contact:

Re: Display drivers programming

Post 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.
John
Posts: 8
Joined: Wed Feb 22, 2012 11:47 pm

Re: Display drivers programming

Post 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.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Display drivers programming

Post 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.)
Every good solution is obvious once you've found it.
User avatar
brain
Member
Member
Posts: 234
Joined: Thu Nov 05, 2009 5:04 pm
Location: UK
Contact:

Re: Display drivers programming

Post 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.
childOfTechno
Member
Member
Posts: 28
Joined: Fri Feb 24, 2012 5:10 pm

Re: Display drivers programming

Post 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.)
-~ Beware the turing tarpit, in which everything is possible but nothing of interest is easy ~-
Post Reply