|
DeaDb0Lt
Squire
USA
20 Posts |
 Posted - Apr 05 2005 : 1:03:49 PM
|
I think you may have forgotten to uncheck the FRAME LIMITER in the Options Menu. :D
Same System Specs as be, except I have a better(read: AMD) Processor. ;)
(Workin on the DirectX version as I type this)
|
Edited by - DeaDb0Lt on Apr 05 2005 1:05:36 PM |
 |
|
|
Lachlan87
Moderator
USA
160 Posts |
Posted - Apr 05 2005 : 1:40:29 PM
|
| Yup. You're right. I forgot about that. I get 900+ now. |
|
|
|
DeaDb0Lt
Squire
USA
20 Posts |
Posted - Apr 28 2005 : 10:47:40 PM
|
BIG UPDATE!
See First Post |
|
|
|
2dcoder
Knave
83 Posts |
Posted - Apr 29 2005 : 01:20:36 AM
|
"- Time Based Modeling (for Animation) - The Frame Limiter only works properly if you get above 63 FPS. If you see FPS goes below 63, UNCHECK THE FRAME LIMITER."
If you're having to worry about the above situation then you are not truly coding in time based movement.
|
|
|
|
DeaDb0Lt
Squire
USA
20 Posts |
Posted - Apr 29 2005 : 06:34:32 AM
|
First off, I'm not "worried" about anything. Some people get less than 63FPS with it on, because they have slower machines. The game is fully playable with less, but instead of playing it with 30FPS, I'd just suggest unchecking the Frame Limiter.
When I figure out why it doesnt really just CAP it at 60, I dunno...yet.
Anyway, if you played it, you could set the Thread priority to BELOW, start up a few instances of the game, and watch the Time Based Modeling work, you would see that all movement calculations are calculated against the ELAPSED time between frames, or...the Delta, which I believe to be what Time Based Modeling is, no?
Adios
|
|
|
|
2dcoder
Knave
83 Posts |
Posted - Apr 29 2005 : 4:12:25 PM
|
Take out any code for capping, and simply code the movement via the time elapsed delta. Then you're fully 100% time based. ;)
|
|
|
|
DeaDb0Lt
Squire
USA
20 Posts |
Posted - Apr 30 2005 : 10:38:11 AM
|
No, because the point of having a DELTA for the calculations is to allow older hardware/slower machines to run the game, keep the animations moving smoothly.
Assume I keep a constant "delta", and apply it to all animations... That means that EVERY FRAME will move a specific distance. Play my game on older hardware/an older machine, and maybe it can only render 10 frames a second. What you will see is a game in slow-motion.
Have you ever programmed time-based rendering in the past? It doesnt seem like you even understand the concept enough to discuss it. Maybe you have, but it doesnt seem like it. |
|
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - Apr 30 2005 : 1:42:56 PM
|
2dcoder didn't say anything about a "constant" delta, so I think you're both on the same page. If you do remove the frame cap then your time based modeling will still work. On faster hardware or faster monitors the delta is simply smaller, so per frame sprites move a smaller distance but per time unit it's the same.
Of course, having a frame cap is still a good idea. Assuming hardware in the future is going to be faster, which is a safe assumption, then the game's time delta between frames would get closer and closer to zero. Assuming you're using a 32bit floating point value for your time, which is the SINGLE data type in VB, then it's accuracy and precision can be reached very easily for very fast frame rates.
One problem of having a game moving too fast is that your delta time is so small that it is effectively zero. This could cause all sorts of problems such as division by zero errors or a game that's frozen because zero time passes from frame to frame.
So, frame caps are good when using time based movement. However, I have a few ideas on how to make them better.
If you're flipping or refreshing the screen timed in synchronization with the monitor's refresh rate, then that can be an effective frame cap. However, some people can override your application settings by changing their video card's driver settings. So, a software frame cap is still usefull.
To make software frame capping better for everyone's computer, I think it might be a good idea to try to detect the monitor's refresh rate and use either that or a harmonic of the refresh rate. If you use a constant "60" then people with higher refresh rates may detect a slight flicker. I know I can't stand using my CRT monitor on a 60hz frequency. I have it set to 80 otherwise I get disoriented.
As for suggesting a harmonic, a game's FPS can jump from large values to much smaller values depending on the scene displayed. For simple 2D games this isn't such a problem, but for games that have lots of special effects it can be a problem. What happens, assuming the game is refreshing the screen in sync with the monitor's refresh rate is that a slight increase in the time it takes to generate one frame can make the entire game jump to a 1/2 harmonic of the refresh rate. I noticed this problem on some 3D stuff I've done, I could linearly increase the complexity of the graphics but the FPS was not linear. It would jump from 60 FPS to 30 to 20 to 15. Effectively 1/2, 1/3, and 1/4 of 60. The problem was that directx waited for frame synchronization. 1/60th of a second is 0.017 seconds. If it took just bit longer to generate the frame, say 0.018 seconds, then directx had to wait 2 frames before a flip could occur, which was 0.033 seconds long. Increase the complexity of the scene would slow the time to draw the graphics from 0.018 to 0.019 to 0.020 etc..., but that increase in time got clamped to the monitor's refresh rate, so the frame rate was 30 FPS instead of 60.
Large jumps in the frame rate are very noticable and annoying. Clamping the game to 30 FPS would keep movement constant and fluid. Any slowdowns in the frame rate wouldn't be as noticable. A jump from 30 to 20, although very bad, isn't as noticable as a jump from 60 to 30 or even from 60 to 20.
So, frame caps are good, and they're better if they can addapt for hardware where the frame rate jumps around too much. |
|
|
|
2dcoder
Knave
83 Posts |
Posted - Apr 30 2005 : 4:52:17 PM
|
"Have you ever programmed time-based rendering in the past? It doesnt seem like you even understand the concept enough to discuss it. Maybe you have, but it doesnt seem like it."
"Play my game on older hardware/an older machine, and maybe it can only render 10 frames a second..."
Trust me on this one, your game should be able to run at refresh rate on just about any computer the past 10 years. You're not coding a very graphic intensive application. ;)
Yah, I've done a little time based coding in the past. ;) Never needed to cap anything. Just move the sprites smaller or larger distances depending on the time delta.
By the way, CAPPING means it won't run any faster than a capped rate. LIMITING means you limit the fps to a certain value, say 20 0r 30 frames per second.
Eric,
"One problem of having a game moving too fast is that your delta time is so small that it is effectively zero. This could cause all sorts of problems such as division by zero errors or a game that's frozen because zero time passes from frame to frame."
Most computers the past few years have built in high performance counters which pretty much solve this potential problem. Almost all modern games use high performance timers to measure the delta between each frame. Anytime you limit your game to 30 or 60 fps you're limiting the performance of your game. And yes you are correct that running your game with Vsync enabled is a good way to at least achieve some delta value that would not result in any divide by zero errors. But again, using high performance timers will solve this as well.
"What happens, assuming the game is refreshing the screen in sync with the monitor's refresh rate is that a slight increase in the time it takes to generate one frame can make the entire game jump to a 1/2 harmonic of the refresh rate. I noticed this problem on some 3D stuff I've done.."
This isn't a problem, it's just the way refresh rate works. Remember the old Snes, Genesis games where if too many sprites were on screen the game would "slow down"? That was the game missing a vsync, so the game would jump from 60 to 30 or 20 fps. If they would have coded the sprites to move using time based movement, the slow down would never have been noticeable. You would just see slightly coarse movement for a period.
If you're coding games for older computers then there are several things you can do, like delta averaging, delta limiting to 20,30,60 fps, etc. But for modern games/computers, the last thing you want to do is cap any delta values. Faster more powerful computers should be rewarded by running the game smoother. |
|
|
|
VBBR
Moderator
Brazil
617 Posts |
Posted - Apr 30 2005 : 6:49:11 PM
|
Rendering more FPS than the monitor's refresh rate is just a waste because only X frames will be shown being X the refresh rate. Maybe the video card updates at 500 Hz but the monitor (which's the thing you're looking at) will refresh at something between 60 and 100 Hz, hence only 60-100 frames/sec will be shown.
BTW a normal person shouldn't notice a differente between 60 FPS and 600 FPS. |
Whatever. Who knows... |
|
|
|
2dcoder
Knave
83 Posts |
Posted - Apr 30 2005 : 9:45:51 PM
|
"BTW a normal person shouldn't notice a differente between 60 FPS and 600 FPS..."
I can't recall the exact number, but I've read where the human eye can only detect movement up to around 80-90 times per second. ? ?
Well actually, "smooth as butter" animation is usually tied to the vsync of the monitor, regardless of the hz. This is because all graphics are draw offscreen and then the video memory pointer is "flipped" to the new screen during the vertical blank. The only way to understand what I'm saying is if you could run your monitor at 30hz and then update every vsync, this would appear smoother to the eye than running your game at 30fps on a 60hz monitor.
"Rendering more FPS than the monitor's refresh rate is just a waste because only X frames will be shown being X the refresh rate."
100% Correct.
|
|
|
|
DeaDb0Lt
Squire
USA
20 Posts |
Posted - Apr 30 2005 : 11:55:25 PM
|
<b>"2dcoder didn't say anything about a "constant" delta, so I think you're both on the same page. If you do remove the frame cap then your time based modeling will still work. On faster hardware or faster monitors the delta is simply smaller, so per frame sprites move a smaller distance but per time unit it's the same." </b>
Yah, I read his post wrong. My bad.
Capping and Limiting? Same result in the end really.
What I have it do now is wait until the time elapsed reaches a certain value before it draws a frame. Any machine's Ive tested on definitely run above 60FPS(err, 63 even, which is what my LIMITER limits at), so I cant see why with the LIMITER on, they sometimes runs BELOW 60(63). Uncheck the Limiter, and all is good.
Any suggestions? |
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 01 2005 : 01:53:20 AM
|
"Capping and Limiting? Same result in the end really."
Not really. Some programmers CAP the frame rate so it never runs faster than a target delta. This is usually a fail safe incase the game loop can render faster than the developer has coded support for.
Some programmers limit their game fps to a targer rate because of several reasons. One ofcourse would be because the game was not coded in time based movement so they need the game to run at a constant fps. The other reason is and this goes back to dos games, is early on the speed of graphics cards varied so much it was just safer to assume "every computer" could handle 20 fps so let's just limit the game to 20 fps.
Capping means it will never go faster than...
Limiting means it will never go faster OR slower than.... ;)
|
|
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - May 01 2005 : 09:16:43 AM
|
2dcoder,
The high performance counter is good for increased accuracy, but bad for precision. I don't want to go into a discussion about the different timing systems on a windows computer, but the QPC still suffers from the possible problem of generating time deltas that are so close to zero that they effectively are. As I write this, games are currently using 32bit floats for most things, so a cast from a 64bit number to a 32bit number will loose some accuracy. However, the number can still be very close to zero, and that's what can cause problems. The "near to zero" issue doesn't have anything to do with the accuracy of a timer, all them can have this problem.
As for frame harmonics, I respectfully disagree with you. I do think it's a problem. If you're using time based movement without vsync and your FPS drops from 60 to 58 for a second then it's not a problem. If vsync is enabled the game would drop from 60 to 30, and my opinion is that such a drop in FPS is a problem. It isn't a big problem, but it's something that can be avoided. Also, this has nothing to do with time based modeling. Using time based modeling means you can ignore the problem because your internal game time isn't based on the frame rate. However, it's problem in terms of a user's perception of movement.
In terms of the illusion of movement for computer games, the human eye needs at least 30 FPS. I do agree that more is better. And the whole minimum number of frames value is debatable and depends on the medium, such as film, tv, computer, etc. However, a sudden large change in the frame rate, for any medium, is noticable. I think it's best if these changes can be minimized. Maybe it's just me, but I find it difficult to play games where the frame rate jumps around sporadically. If such jumps can be detected and fixed, then why not do it?
On modern hardware, the original game that started this thread won't suffer from any of these problems. I was simply providing situations where a frame cap can be usefull. I tried, although I guess not successfully, to say that a frame cap isn't something that should be applied to everything in the same way. It should be flexible in that it stablizes the frame rate only for systems that need it. Please keep in mind my whole discussion of frame capping was for stablizing the frame rate of the game, not stablizing the game's internal movement because that's the job of time based movement code. I was trying to show how the two ideas can exist together (when needed of course) to keep a game's movment fluid instead of jerky. |
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 01 2005 : 4:23:18 PM
|
I'd say just about every modern game uses time based movement now. All consoles (Xbox, etc) have Vsync enabled. Those games run at 60,30,20, etc. Some developers opt to cap the frame rate at 30 to avoid the scenario you describe where the frame rate drops from 60 to 30 too often. In a 3D game you can get away with fluctuating frame rates much more than you can in a 2D game. In a 3D game the entire world is moving and your eye doesn't focus on a particular sprite as much as it does in a 2D game.
"I think it's best if these changes can be minimized."
I 100% agree.
"If vsync is enabled the game would drop from 60 to 30, and my opinion is that such a drop in FPS is a problem. It isn't a big problem, but it's something that can be avoided. Also, this has nothing to do with time based modeling."
And if you code your game with time based movement from the start, you could always add options to run the game at 20,30,60 or with no limiting at all. This would stablize the frame rate at a constant rate and still provide time based movement. |
|
|
|
|
Come ride the Bullet Dodger Hijack Experience
Topic Locked
