Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / How to sync jump/fall with fps#?

Author
Message
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 7th Sep 2003 05:27
Link
Here is basic idea behind my jump/fall routine...

fps# = screen fps()
yspd# = y# - oldy#
oldy# = y#
gravity# = -10/fps#

yspd# = yspd# + gravity#
y# = y# + yspd#


Im having trouble keeping the jump/fall speeds consistant across varrying fps. Right now, you fall much faster with a high fps. Ive identified and isolated the problem (half the battle), but I cant think of a solution. The problem is, when the program is looping more often (higher fps), the yspd# variable 'stacks' more often. Here is an example.

Lets say the above code was running on two machines, one at 1fps and another at 2fps. The machine at 1fps would loop once, gravity# would equal -10, yspd# would equal -10, and y# would be pulled down to -10. However at 2fps, on the first loop gravity# would equal -5, yspd# would equal -5 and y# would be pulled down to -5. On the second loop, yspd# would remain at -5, then jump to -10 from gravity, pulling y# to a final destination of -15. Thus the faster the program loops, the more time yspd# has to stack, and the faster youll fall...

Im sure there is a simple solution to this, I just havent been able to see it for some reason.

Thanks in advance for any info

All you need is zeal
Back to top
Profile PM Email
TRS80Model1
23
Years of Service
User Offline
Joined: 2nd Feb 2003
Location: - Please Select -
Posted: 7th Sep 2003 06:04
Link
What you need to do is limit the game main loop to the fps, not the jump, try timer funtion or use directx fps limiter.(exclusive mode only)
Back to top
Profile PM Email Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 7th Sep 2003 06:24
Link
Hmm so youre saying before I run the main loop, check fps, run the program x loops, then wait for a full second to pass before repeating? So the main loop should be inside a 'second timer()' loop? Is this how all the big boys do it? Never knew

All you need is zeal
Back to top
Profile PM Email
CattleRustler
Retired Moderator
22
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 7th Sep 2003 06:43
Link
sync rate?
to be consistent

just guessing as I an n00b dbp

-RUST-
Back to top
Profile PM
the_winch
23
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 7th Sep 2003 07:06
Link
You can base the speed off the fps if you want, no need to use the timer().
You just need to get the maths right.
Back to top
Profile PM Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 7th Sep 2003 07:47
Link
Heh and what are the maths? I can get a steady fall, regardless of fps, if I just subtract gravity# from y every loop, because gravity is fps based (-10.0/fps#). However its when I start using momentum (yspd#) that things get tricky. Like I said, because higher fps loops more often, yspd# stacks more rapidly.

So how do you do a realistic looking fall (or any momentum based movement) that stays constant regardless of fps?

All you need is zeal
Back to top
Profile PM Email
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 7th Sep 2003 10:16
Link
Most people use sync rate caps, and other half assed methods to control speed. I think the majority of the db community is a little foggy on this whole issue (I know I am). We need somebody to step in and tell us how it SHOULD be done. How do the big boys do it?

All you need is zeal
Back to top
Profile PM Email
Jon Huhn
22
Years of Service
User Offline
Joined: 7th Sep 2003
Location:
Posted: 7th Sep 2003 19:07 Edited at: 7th Sep 2003 19:08
Link
Zeal,

I have no experience with DBP, but I've done quite a bit of work with Macromedia Director (which has a decent all-purpose 3D engine), and this is what I do to keep all values in my applications changing at the same rate, regardless of the end user's framerate:

Try dividing ALL your deltas by fps#, not just your gravity value. By ensuring that every time you change a value, you divide the change in value by the framerate, you should keep the playback mostly the same at all framerates.

The only drawback to this approach is that framerates under 30 frames/sec will experience somewhat inaccurate acceleration of values. But if you keep your framerate above 30, the inaccuracies are so small as to be negligable.

I would rewrite your code this way (pardon if I mess up the sytax - I'm unfamiliar with it):


fps# = screen fps()
yspd# = y# - (oldy#/fps#)
oldy# = y#
gravity# = -10

yspd# = yspd# + (gravity#/fps#)
y# = y# + (yspd#/fps#)


Does this work?
Back to top
Profile PM
Andy Igoe
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United Kingdom
Posted: 7th Sep 2003 21:35
Link
Bah, dont cap your fps. What a waste on powerful PC's! And still lags on PC's that are just under specification! It's a terrible solution, but there is a very easy answer.



Pneumatic Dryll
Back to top
Profile PM Email Website
Kensupen
23
Years of Service
User Offline
Joined: 19th Sep 2002
Location: United States
Posted: 7th Sep 2003 22:40
Link
I hate to burst everyone's bubble, but you can't use timer() correctly under WinXP. There are too many processes running in the background to be accurate. DBPro doesn't get 100% of the CPU because of how NT works. There was a thread on this and it's a fault of DX and Windows.

You'd have to base all timings off the FPS under NT/XP

-Kensupen

Nerdsoft Creations - Lead Programmer
System Specs: AMD XP 1700+, WinXP Home, 1GB PC133 ram and Radeon 9500 using DX9
Back to top
Profile PM Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Sep 2003 23:30
Link
The bubble hasn't been burst I'm afraid. We had that argument with Heartbone here too. Despite the fact that we explained and removed the problem, he wouldn't be convinced

Just one question ... if timer is not accurate, there does the SCREEN FPS() function get elapsed time from?
Back to top
Profile PM Email Website
Rye
23
Years of Service
User Offline
Joined: 30th May 2003
Location: United Kingdom, Blackrod
Posted: 7th Sep 2003 23:46
Link
i created this and it uses timer() to limit the number of screen refreshes per second. I have XP pro and the program seems to work.

It allows your main loop to do loops as fast as your computer will do them but the framerate will be constant. there are a few flaws. If you run the program through midnight, then the timer
resets back to 0 and the screen will no longer refresh.
I get an average of 300 on my computer which is an athlon xp 2500, 512 DDR, gf4 ti4800. I use this in all my projects and i use the average to limit speeds. so for gravity :-

grav#=-9.81/average#(1)
yspeed#=yspeed#+grav#

its seems to work well.



The only thing im curious about is if i move the print command from the main loop into the function then i get an average of 48000. not sure why.
Back to top
Profile PM Email
Kensupen
23
Years of Service
User Offline
Joined: 19th Sep 2002
Location: United States
Posted: 8th Sep 2003 05:03
Link
I get 473 using that snippet. I don't really have any clue what you're trying to do with it, but it doesn't seem like my PC is running at 60 FPS.

-Kensupen

Nerdsoft Creations - Lead Programmer
System Specs: AMD XP 1700+, WinXP Home, 1GB PC133 ram and Radeon 9500 using DX9
Back to top
Profile PM Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 8th Sep 2003 07:14
Link
Thanks for the effort guys but still dont see how its done...

Jon Huhn I got funky results from your code, dont think thats how to do it.

PneumaticDryll your timer() code does the exact same thing as my /fps# code. They both work fine for moving objects, but dont work when dealing with momentum (falling, ect).

Ryan your code is just a tad confusing, I cant tell how many fps im getting. When I use the screen fps() comman I get some insane high numbers (like in the thousands). Are you sure you got a real momentum based fall to work with that code?

All you need is zeal
Back to top
Profile PM Email
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 8th Sep 2003 10:12
Link
Argggggggggggg this is really driven me nuts. You wouldnt think it would be so hard for me to figure out. How in the hell... There has to be a way to do a fall with just /fps#, but why oh why cant I see it.

All you need is zeal
Back to top
Profile PM Email
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 8th Sep 2003 20:45
Link
Whoever gives me da codes that shows how to do a realistic fall thats time or fps based gets a cookie. Sorry I have been forced to resort to bribes, but this has really been driven me crazy. When I get hung up on little crap like this I cant work on anything else.

All you need is zeal
Back to top
Profile PM Email
CattleRustler
Retired Moderator
22
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 8th Sep 2003 20:49
Link
I know what you mean Zeal. Sorry I cannot as of yet be any help in this matter, but I did enjoy your Gimmee da codez reference.


-RUST-
Back to top
Profile PM
Andy Igoe
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United Kingdom
Posted: 8th Sep 2003 22:23
Link
Quote: "but dont work when dealing with momentum (falling, ect). "


Dang I did this recently in one of my projects, I don't remember which though, to reduce by percentage. I think it was something along the lines of calculating the potential v's the gamespeed too, but i'll have to run some tests and figure it out when I get the chance.

Pneumatic Dryll
Back to top
Profile PM Email Website
TRS80Model1
23
Years of Service
User Offline
Joined: 2nd Feb 2003
Location: - Please Select -
Posted: 9th Sep 2003 08:45
Link
Why would you want to refresh the screen faster than the eye can process information anyways? that is wasting time that could be running AI or other cool stuff. DVD movies refresh at 29.6 fps and movie film at theaters is 30 fps. What is the point in using the
Quote: "What a waste on powerful PC's!"
processing power when it has to sit idle whiles the video completes the refresh.

Maxing the fps just leaves imperfections in the animations cause of OS lag.

Don't know, and don't understand what is the point of 200 fps, makes no sense to anyone with logic that I have spoken to.
Back to top
Profile PM Email Website
Andy Igoe
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United Kingdom
Posted: 9th Sep 2003 11:02
Link
Quote: "that is wasting time that could be running AI or other cool stuff

Don't know, and don't understand what is the point of 200 fps, makes no sense to anyone with logic that I have spoken to. "


The human eye can detect changes in refresh rate at up to about 50-60 fps. If you can get a game to run consistently above this speed then your players are in for a smooth end result.

More often than not when i'm working in DBPro in 3D I aim the game to run at about 25fps on my system which is what I consider the minimum for useability.

If I was to sync the game to that speed and do the mathematics accordingly not only do I make the game unplayable for those with lower PC's, but I waste a potential 25-35fps on faster machines which could dramatically improve the playing experience.

Maximising a game for 200fps on a fast PC as you mention TSR well, we all know is a bit of a pipe dream for most BASIC programmers, personally in my latest project (Transfusion) I am running around 100fps with more to add, but on a very slow PC getting 20fps will run the game at the same speed and still be playable.

As for doing other cool stuff in the redundant time between 60-200fps - well that's a matter of future proofing really isn't it - and not something most of us worry about in games as 200fps is not really that common, be honest.

With OS related lag issues there are many cures for badly installed systems and those running too much background software - the OS itself doesn't cause any jittery lag. That's a whole other subject really but there are a fair few solutions to it: fastsync; framerate dampening; checking to see if MSN Messenger is running and close it...! etc.

Pneumatic Dryll
Back to top
Profile PM Email Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th Sep 2003 15:47
Link
I remember in the 'old days' that when programming for the C64 coders were always fighting to get that elusive 50fps.

The one I remember most was Braybrooks diaries when he was coding Uridium and Paradroid ... I think ...
Back to top
Profile PM Email Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 9th Sep 2003 16:00
Link
Warrrggg I still need da codes!

All you need is zeal
Back to top
Profile PM Email
Yuri
23
Years of Service
User Offline
Joined: 12th Jun 2003
Location: Italy
Posted: 9th Sep 2003 16:05 Edited at: 9th Sep 2003 16:05
Link
there are probably an easy solution.. i programmed a sort of "fps relative" code on Amos 3D... i need to know a thing however:

are all object drawed on screen when the command SYNC (or fastsync) is used?

i'm explain better

is the first example much faster than the second?

first:


second:


CBMZone main administrator
http://www.cbmzone.com
Back to top
Profile PM Email Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 9th Sep 2003 16:19
Link
Im using a for next loop for my main game loop. Its my understanding they run faster than do loops because they dont auto sync, and a few other things. So in my for next loop, I call sync every time. ex

for a = 0 to 1

`game code

sync
a = 0
next a

All you need is zeal
Back to top
Profile PM Email
Yuri
23
Years of Service
User Offline
Joined: 12th Jun 2003
Location: Italy
Posted: 9th Sep 2003 17:35
Link
ahhh it brings up memories to me.......
i remember the "infinite" or "tricked do-loop" for - next on the commodore computers...

for x=1 to 0
next x

naturally this doesn't work on DBP..

CBMZone main administrator
http://www.cbmzone.com
Back to top
Profile PM Email Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 9th Sep 2003 18:00
Link
Did you say you did a solution in Amos 3d? Are you sure it would work with stacking/momentum based movements?

All you need is zeal
Back to top
Profile PM Email
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 9th Sep 2003 23:05
Link
Come on where are all the uber coders? This has to have a simple solution, but ive been hung up on it for so long I know ill never figure it out on my own. Heeeeelllllppppp!

My offer still stands. Show me da codes that does a fall based on time/fps and youll win a cookie.

All you need is zeal
Back to top
Profile PM Email
Rye
23
Years of Service
User Offline
Joined: 30th May 2003
Location: United Kingdom, Blackrod
Posted: 10th Sep 2003 00:06
Link
Thinking about it, it isnt just your falling that will be affected by different computer speeds. it will be the movement of every object. I guess that is why the TGC made sync rate like they have, limiting the num of loops per sec as well as the fps. If your good enough you can probably find a way around it.
Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th Sep 2003 00:53
Link
Here are the basic equations. Just plug your values in at each loop to find your new speed and the distance travelled.

Back to top
Profile PM Email Website
Zeal
23
Years of Service
User Offline
Joined: 10th Oct 2002
Location: Colorado Springs, CO
Posted: 10th Sep 2003 03:05
Link
I think a cookie is in order. I just did a fall at 20 and 200fps, both were within a few thousands of a second apart. The whole "Distance" variable confused me at first. I think you meant coord right? Otherwise what is Speed? Anyway here is how I wrote my code...

y# = y# + yspd# + (-0.0025*(looptime#^2))

Looptime to the power of two seemed to be the missing link in this puzzle. And it might be just a mixup in my code, but I seemed to get slightly more accurate results using y#/yspd# rather than oldy#/oldyspd#.

Thanks again everyone! Exspescialy you IanM! Give me your postal address and ill ship this cookie out asap

All you need is zeal
Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th Sep 2003 10:35
Link
The problem you were having with 'looptime#' may be because you hadn't converted the 1000's of a second to seconds by dividing by 1000?

The speed is the number of units you move per second (or whatever time unit you decide to use). You can match this to 1 unit = 1 pixel if you are doing 2D work (which you have done), or 1 unit = 1 world unit if using 3D.

In fact it doesn't even have to be a straight 1 to 1 conversion if you don't want it to be. The equations don't care if you measure time in seconds or distance in metres or whatever, as long as you are consistent in using them
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-25 09:39:04
Your offset time is: 2026-07-25 09:39:04