Re: Display drivers programming
Posted: Fri Feb 24, 2012 6:09 am
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 Place to Start for Operating System Developers
http://f.osdev.org/
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.
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.
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.
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.
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
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
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...
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.)
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.
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).