Display drivers programming
Re: Display drivers programming
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.
-
- Member
- Posts: 283
- Joined: Mon Jan 03, 2011 6:58 pm
Re: Display drivers programming
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.Solar wrote:The solution to motion tear is motion blur, not higher FPS, because no amount of FPS will solve the underlying problem.
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.
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.Solar wrote:A 3D engine that syncs physics with FPS is crap.
- Monk
Re: Display drivers programming
How would a higher FPS solve that, other than having two or more "tears" on screen?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.
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.)
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.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.
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.It's not that they are synced, but that they are dependent on each, in that rendering is dependent on physics.Solar wrote:A 3D engine that syncs physics with FPS is crap.
Every good solution is obvious once you've found it.
- Combuster
- 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
Still illegible. You only really helped the scarce few that use the pony theme. The rules mentions "no colours" explicitly for a reason.tjmonk15 wrote:EDIT: Changed super bright red for a darker one to help readability. Is it better now?
That's the stupid solution, caused by a lack of ability to oversee the engine in its entirety.You would have to add that code in probably 100+ places
They do care about not getting their stuff back for not working.The guys at the top don't care about doing it right
At least less hazardous as telling truths in China.Labelly Gamers as not very smart can be hazardous to your health
I should introduce a friend and lead game developer to you, just to show you how misinformed you are. What are you, a wannabe?Brendan, also realize how stressful a game dev's life is. They generally work 80-120 hours a week
Re: Display drivers programming
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.Combuster wrote:I should introduce a friend and lead game developer to you, just to show you how misinformed you are. What are you, a wannabe?Brendan, also realize how stressful a game dev's life is. They generally work 80-120 hours a week
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
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
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.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...
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.
Re: Display drivers programming
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.Solar wrote: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.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...
If you can't do it in 40-50 hours / week, don't bother. (And 50 hours is pushing it.)
-
- Member
- Posts: 28
- Joined: Fri Feb 24, 2012 5:10 pm
Re: Display drivers programming
Some observations:
@Solar:
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
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.)
@Solar:
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.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 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
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.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).
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 ~-