|
Lachlan87
Moderator
USA
160 Posts |
 Posted - May 01 2005 : 8:22:58 PM
|
VBBR, just as a side note, many people say you shouldn't notice a difference between 60Hz/FPS or 100Hz/FPS, but from personal experience I have found this to be baloney. Everyone in my family can easily tell the difference, and sometimes I detect a slight flicker even though my monitor refreshes at 85Hz. I have never found anyone who couldn't tell the difference. I think the common assumption that people can't tell the difference is based on supposed scientific fact rather than what actually occurs.
A lot of people say humans can't really hear sounds that many of us can, as well. It's just a pet peeve of mine. 
|
 |
|
|
VBBR
Moderator
Brazil
617 Posts |
Posted - May 01 2005 : 9:01:03 PM
|
I like to 'hear' the TV turning on. 
Like, I know when there's a TV on even with sound muted... it's fun 
(I hear the sound the CRT makes) |
Whatever. Who knows... |
|
|
|
Scorpion_Blood
Warrior
Portugal
118 Posts |
Posted - May 02 2005 : 06:11:02 AM
|
| well i have been abducted... mens with big heads implanted me something in my head :S and im able to see pink elephants... lol kidding :p anyway that is true, anyone can see the differences on a 60Hz and 100Hz... it changes on human to human :\ |
Edited by - Scorpion_Blood on May 02 2005 06:11:59 AM |
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 03 2005 : 02:35:13 AM
|
"many people say you shouldn't notice a difference between 60Hz/FPS or 100Hz/FPS.."
Your eyes adjust. If you work with a 85khz monitor for a few hours or days and then work on a 60hz monitor, your eyes will be tricked into thinking it's flickering. When your eyes adjust the percieved flickering will go away. Granted on certain monitor/graphics card combos it will indeed flicker. But usually it just seems to be flickering until your eyes adjust. After all when you focus on little pixels in words for hours on a day and then do the same at a lower refresh it's a major strain on the eye for a spell. |
|
|
|
hotrodx
Squire
43 Posts |
Posted - May 03 2005 : 12:06:10 PM
|
On usual *procedural* loops involving rendering, 100+ FPS also means 100+ cycles per second. This is really a sloppy way of using system resources. Imagine if you had a Network routine nested inside the loop. Programmers should at least sync the framerate with the monitor's refresh rate. Leave the 200 FPS to benchmarking.
Another issue i'd like to point out is some of the inherent problems with time-based loops. Imagine a game, and let's assume it has a "perfect" time delta of 1. On a sheet of graphing paper, plot a game object's movement path, taking into consideration the object's heading rotations.
Now, let's say this same program is run on a slower machine, thus averaging with a time delta of, say, .83. Again recreate the object's movement by plotting it over the first plot (the one with the time delta of 1).
By now you've seen the problem: not only does the x,y need to be time factored, but even the heading rotations as well. You will even see that, if you really calculated the movements, plot 1 isn't exactly the same with plot .83. And while I agree that it may be possible to *approximate* plot 1, the extra calculations already added some overhead on the already slower machine.
We've only talked about one sprite (or mesh, if it's 3D). Imagine adding more just as in any other game.
Now consider the fact that VB6's math isn't all that fast(Umm, C/C++ DLLs, anybody? Or the DotNet route, perhaps?)
With regards to differences in Hz, it could also be a monitor thing. This old monitor I'm using at home is supposedly capable of displaying 72Hz. It does, but with flickering. On some other monitors running at 72Hz, it's pretty smooth in the eyes.
Oh, and before we all forget, nice little game! How about a dodgeball version? ;-)
|
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 03 2005 : 11:33:29 PM
|
"Now, let's say this same program is run on a slower machine, thus averaging with a time delta of, say, .83. Again recreate the object's movement by plotting it over the first plot (the one with the time delta of 1)"
No offense, but it doesn't sound like you quite grasp the coding of time based applications. The fact that the delta is "fluctuating" is ofcourse expected, that's why this just represents a "scaled" value in time which you multiply your movement by. In and that respect how long it takes to get from point a to point b would be the same regardless of the frame rate.
|
|
|
|
hotrodx
Squire
43 Posts |
Posted - May 04 2005 : 01:51:28 AM
|
Some corrections:
A lower time delta means it's actually faster, my bad.
With regards to time delta used in procedural loops -- that's how it's computed, right? Unless you use threads or event-based (on paint) rendering "loops", time based requires and extra dimension to factor.
Time based computations *may* affect the total number of actual cycles (not just the frames rendered), for example-- you are trying to sync the framerate with the monitor refresh rate. The opposite is also possible, i.e. the number of cycles can affect the time delta (because of slowdown in the loop). So if in a time delta of 1 you had 60 cycles, in .83 you have around 72. Now in time delta of 1 you had 60 rotational turns, in .83 you have 72 rotational turns. So the rotational turns itself must be adjusted. And it's not that easy to re-plot the same exact path on 60 cycles with 72 cycles. If you are only incrementing X and Y with a delta-factored speed variable, that's easy. But not with sin/cos rotations factored in.
|
Edited by - hotrodx on May 04 2005 01:58:29 AM |
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 04 2005 : 08:17:46 AM
|
Hey HotRod,
Just my opinion, but you should probably stop thinking about refresh rates,hz,cycles,etc and start thinking more along the lines of "how far is my object going to move in 1 second?". The time delta is the length of time it takes to draw the frame in milliseconds so smaller deltas generate smoother movement, larger deltas generate coarse movement.
Here's a very crude example of time based movement:
'
speed = .05
'
do
start_time = GetTick
' move objects
x = x + (speed * time_delta)
y = y + (speed * time_delta)
' draw objects
time_delta = GetTick-start_time
loop
But the end result is, this object would take the same length of time to travel from point to point b regardless of how fast or slow the frames were being drawn. |
|
|
|
hotrodx
Squire
43 Posts |
Posted - May 04 2005 : 1:03:59 PM
|
Hey 2dcoder,
And how about you think in the lines of "how much angle should I turn in one second if the number of cycles is not constant".
You are just thinking about simple movement schemes like:
if keypressed(up) then y=y-(speed*delta)
if keypressed(down) then y=y+(speed*delta)
if keypressed(left) then x=x-(speed*delta)
if keypressed(right) then x=x+(speed*delta)
But think something like asteroids:
if keypressed(left) then angle=angle-turn
if keypressed(right) then angle=angle+turn
if keypressed(up) then speed=speed+.1
x=x+sin(angle)*speed
y=y+cos(angle) *speed
Then try plotting it on a graph paper. Assume one graph to be a perfect delta of 1, the other, say, 1.34.
|
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 04 2005 : 6:42:14 PM
|
Hey HotRodx,
You're SO CLOSE it hurts! :)
Forget the graph paper, code something up using this and you'll see it works regardless of the frame rate:
Dim angle As Single
Dim speed As Single
Dim turnspeed As Single
Dim thrustspeed As Single
'
turnspeed = 0.002 ' or whatever
thrustspeed = 0.0001 ' or whatever
'
' top of loop
'
If keyup = True Then
speed = speed - (thrustspeed * delta)
'
' could use some trapping...
'
End If
'
If keydown = True Then
speed = speed + (thrustspeed * delta)
'
' could use some trapping...
'
End If
'
If keyleft = True Then
angle = angle - (turnspeed * delta)
End If
'
If keyright = True Then
angle = angle + (turnspeed * delta)
End If
'
x = x + Sin(angle) * (speed * delta)
y = y + Cos(angle) * (speed * delta)
'
' Bottom of loop
' |
|
|
|
hotrodx
Squire
43 Posts |
Posted - May 05 2005 : 01:26:08 AM
|
2dcoder,
But you just approximated the distances -- but they are not the same. The delta, being based with the time between the start and the end of the loop, has a correlation with the total number of loops made over a period of time. Therefore, the delta has a relationship with the cycles per second. In cases where delta becomes bigger, you are having fewer cycles per second. If you have fewer cycles, you have fewer points in your graph. Imagine the points as a polyline. If you got fewer vertices, how could it be the same with the original one? It would be crooked.
So the point is you can only approximate. I'm not even sure that simply factoring the delta with the turnspeed is accurate: delta sampling occurs every cycle, and the delta is fluctuating on slower systems, especially when the OS is accessing the swap file. Also the pseudocode you provided didn't take into account the total amount of rotation made over a period of time, only factoring the turnspeed with the delta sampled from the *previous* loop/cycle. You could end up overshooting, overrotating or even underrotating your, umm, ship, if you're not careful.
Take note that if you have fewer loops, you have fewer opportunities to check user input. Exactly WHEN the key trapping occurs will vary between one with a perfect Delta of 1 with one with a fluctuating one. So the actual time when you turn (by pressing a key) could be different from another. It could be earlier, it could be late.
So the point that time based movement on procedural loops will make an object move from point A to point B in the same period of time ISN'T accurate, because it may never reach the EXACT point B with those with different deltas.
To illustrate my point, I've made a program that simulates the paths. You will see that the paths are not the same. Sometimes, even end points are not the same. Take note of the huge difference between the the very slow deltas with the very fast ones.
Download Attachment:  test.zip
2.75 KB
Also, this might not be a fair representation of an actual game, as it assumes the object is constantly turning right. This actually favors you. If I've simulated actual keytrapping events, the end points would be truly out of place.
Do the math.
DeaDbOLt,
Sorry to hijack your thread, but a point must be raised. Thanks! |
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 05 2005 : 02:08:17 AM
|
All I know is if you take my code and place it in a demo you will find the ship rotates at the same speed regardless of frame rate, and the ship will travel from point a to point b in the same amount of time regardless of frame rate. And THAT my friend IS time based coding. Sure we could get even more accurate with tables defining rotation angles and thrust, and pull values out of the tables based on time deltas. I mean ofcourse there is SO many more ways to achieve "perfection" if that is your goal.
"So the point that time based movement on procedural loops will make an object move from point A to point B in the same period of time ISN'T accurate, because it may never reach the EXACT point B with those with different deltas."
Wait a sec....your original suggestion was to refer to an asteroids type movement in free space where there IS no destination x,y. And the code I supplied WILL do exactly what you challenged. It will rotate direction, thrust, move the sprite, etc, ALL at the same speed REGARDLESS of frame rate. My example proves that I am right in that line of thinking. ;)
Look, as a programmer you know there are many ways we cheat to achieve a level of acceptable simulation in a game. If I needed to code a sprite that would move EXACTLY from pixel(x,y) to another pixel(x,y) using time based coding, there are several ways to do this:
1) Get the starting direction and then multiply this by the time delta each loop. In the event the sprite goes PAST the destination LOCK the sprite onto the destination x,y and stop moving. This is cheating but it works, lots of programs do it. No biggie....
2) Code a table of values representing the path for the sprite to move. Using a counter manipulated via time delta you simply go through this table of values until you reach your destination x,y. The larger the delta the faster you move through the table, choppy movement. The smaller the delta values the slower you go through the table representing smoother movement. This is a more precise method but the drawback is you have to create tables of x,y values representing the path the sprite will move.
The level of accuracy can be adjusted by the programmer as needed for the app. There are just too many ways to do this for anyone to say "it's wrong this way or impossible that way". Time based movement, procedual or thread driven is how it works now days, 2d or 3d.
Still counting those cycles? ;)
|
|
|
|
hotrodx
Squire
43 Posts |
Posted - May 05 2005 : 02:39:37 AM
|
My original movement pseudocode is indeed much appropriate to other ship games than Asteroids (where there is thrust and counter thrust). So maybe think something like Jungle Strike. But that's not the point I'm raising. The point is that the paths are different were rotations are involved.
I've merely refactored the code to simulate time-based movements in the program I uploaded (you DID try it, didn't you?). But it does factor in the (simulated) delta with the x,y movements and rotations.
So here is what I'm saying in plain words: THE PATHS ARE DIFFERENT. |
|
|
|
2dcoder
Knave
83 Posts |
Posted - May 05 2005 : 04:50:19 AM
|
Sure I looked at it, but (no offense) the only thing it proves is you havn't found a solution for your style of thinking.
"So here is what I'm saying in plain words: THE PATHS ARE DIFFERENT."
No one can argue that what YOU have coded is not the solution that would be used by someone coding a time based project where paths need to be anchored by a rotation. hmm.. "anchored". Ever think about a center anchor x,y position and then use that to calculate your rotated anchors via a flucuating delta? :) Ok, I've accepted your challenge, coded something that gives you rotated direction, thrust, in any frame rate. You counter with a slice of code that OFCOURSE would not be EXACT with a fluctuating delta. So instead of assuming your way is the ONLY or RIGHT way, try thinking of delta in combination with tables, anchored positions to calulate your rotated directions, etc,etc,etc. We could have a few beers and probably think of a dozen different ways to make it work. It's been a good debate, perhaps some others will get some ideas from the point and counterpoints. I'm outta this one. ;) (Played your Space Harrier to death last year btw. Frickin AWESOME!) |
|
|
|
hotrodx
Squire
43 Posts |
Posted - May 05 2005 : 05:41:19 AM
|
As addition, projected path tables isn't practical in action games like asteroid. If the moving object has already decided it's course/path in next 5 seconds, what's the point of getting the user input in every cycle (where the user can change directions). Because you are getting input every cycle, it is impossible to determine the final destination. It's also impractical for a lot of objects to do that, just to be accurate. It'd be slow. We're actually looking for solutions in events where there is high delta/low framerate situations.
By cycle, I mean 1 "loop" if that's hard to understand. Cycles are usually the same with Frames (rendered) with loop-based time movement calculations, but Cycles aren't necessary Frames (in frameskipping methods, for example, frames are skipped but cycles aren't). Hence, I've always tried to make that distinction.
As i've pointed out, cycles are correlative with the delta. If in every cycle there is a chance for a user to change directions, then fewer cycles(low framerates/high deltas) would mean fewer or late rotations. The "very slow" graph in my program shows an example of this.
Of course, the differences can be acceptable at times, but there are times when you have to be guarded at sudden drop of framerate. It could make a big "jump" in movement. If you're doing ray hit collisions, then even the delta has to factored with it else you end up going over a wall, say.
And all these extra computations are an overhead for a program-- and an extra problem for the programmer. This isn't a problem for fast computers, as 200fps games are a different set of issues. But it is when you subject your program to stress tests or a slow program.
|
|
|
|
|
Come ride the Bullet Dodger Hijack Experience
Topic Locked
