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 / Are the DBPro fps numbers real!

Author
Message
Trisect Development
21
Years of Service
User Offline
Joined: 8th Sep 2002
Location: Denmark
Posted: 20th Sep 2002 22:28
Link
Ex.
When i run a the light example it says DBPro fps 36, but it runs very slow, around 10 fps i would think.

I don't think it shows the real Frame Pr. Seconds!

My spec:
IntelIII 866, 256 MB, Geforce256DDR
Back to top
Profile PM Website
haggisman
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 20th Sep 2002 23:21
Link
lol i would say a computer has a better chance of calculating the number of frames per seconed better than any human, maybe you are blinking too much or someth'n

Specs:- 1GHZ athlon, Radeon8500, 192mb ram
Back to top
Profile PM Email Website
Trisect Development
21
Years of Service
User Offline
Joined: 8th Sep 2002
Location: Denmark
Posted: 21st Sep 2002 00:35
Link
No no no

I can see if something runs very slow!

I have seen games run fine at 25 fps, and this runs slower at 36.

All i'm saying is, i don't think they a real!

Back to top
Profile PM Website
haggisman
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 21st Sep 2002 01:07
Link
how do you know the games that you thought were running at 25 weren't reporting the FPS wrong?

Specs:- 1GHZ athlon, Radeon8500, 192mb ram
Back to top
Profile PM Email Website
Trisect Development
21
Years of Service
User Offline
Joined: 8th Sep 2002
Location: Denmark
Posted: 21st Sep 2002 01:17
Link
I dont!

Just think that 36 fsp should run faster!

Back to top
Profile PM Website
las6
21
Years of Service
User Offline
Joined: 2nd Sep 2002
Location: Finland
Posted: 21st Sep 2002 02:06
Link
game/application speed is not always linked to the fps you know.

I can make a game with jerky movement and controls... that still would run at ~90fps... or something.

Specs :: [1333Mhz : 256DDR : Geforce 2 Mx 64MB]
Back to top
Profile PM Email Website
xtom
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Ireland
Posted: 21st Sep 2002 02:26
Link
The frame rate command seems accurate enough to me. ie 0-15 is very jumpy, 15-30 is a bit jumpy but acceptible-ish, 30-45 is smooth and 60+ is ultra smooth.
Back to top
Profile PM Website
Mentor
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 21st Sep 2002 16:16
Link
fps speed has no relation to the speed of the objects in a program, if you write a high speed game then you make the object move faster by increaseing the steps between positions, so if, for example, the x position is updated by 5 units per frame, that makes the object move quickly, on the other hand if you want something in the same game to move 5 times slower then you would update by 1 unit per frame, so for every 5 units the first object appears to move the second one only moves one unit, in the demos the rotation/movement is set to run smooth by updateing the positions by small amounts at a time, if it takes the object 1 second to rotate right round then at 36fps it must be rotateing in 10 degree steps, if you want smoother movement (say 5 degree steps) then you need to take 2 seconds and a total of 72 frames to turn right round in 5 degree steps, or if you want to turn in 1 degree steps then it is going to take 360 frames, at 36fps that would take ten seconds to rotate the model (realy smoothly) right round, there is another reason why the fps counter is accurate, thats called the trade descriptions act, you can get prosecuted for lying about things like that, so they will have made sure it is accurate (besides, its easy to code and check, just zero the timer at the start of the loop and print the millisecs at the end of the loop, that will tell you how long the code took to hit the sync command)

Mentor.

Back to top
Profile PM
Zero
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: Finland
Posted: 21st Sep 2002 20:02
Link
I agree with Timelord. I think there are some bugs when outprinting the FPS. And I have a proof of it. I made a system that grabs the FPS value and sets the object movement speed according to that value. The object should move at the same speed in spite of what value the FPS is! I mean if the fps was 40, it would move 1 step per frame. If the fps was 80 then it would move 1/2 steps per frame. This works fine in DB#1. In DBPro I get 266 fps and the object moves way too slow! So where is the bug??

The evil plan is now even closer!
- - - - - - - - - - - - - - - - - - - -
Specs:- P3 550 Nvidia TNT2M64, 192Mb RAM
Back to top
Profile PM Email
haggisman
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 21st Sep 2002 22:07
Link
code?

Specs:- 1GHZ athlon, Radeon8500, 192mb ram
Back to top
Profile PM Email Website
WarWolf
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 22nd Sep 2002 02:19
Link
If you don't think that the built-in FPS-counter is real, then write your own and compare!

I didn't steal it!
Back to top
Profile PM
Zero
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: Finland
Posted: 22nd Sep 2002 12:44
Link
speed#=40/screen fps() because it would move 1.0 when 40 fps.

Simple math:

x/40=1/screen fps()

equation gives the fixed speed as X

The evil plan is now even closer!
- - - - - - - - - - - - - - - - - - - -
Specs:- P3 550 Nvidia TNT2M64, 192Mb RAM
Back to top
Profile PM Email
haggisman
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 22nd Sep 2002 13:49
Link
what are you showing?
x/40= the inverse of screen fps() ??
x=40/screen fps() ???
so what if it gives x a fixed speed, i do that all the time, where is your code to show the bug?

Specs:- 1GHZ athlon, Radeon8500, 192mb ram
Back to top
Profile PM Email Website
Zero
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: Finland
Posted: 23rd Sep 2002 10:00
Link
It's a simple equation where we have to solve x (new speed movement). It can be written into speed#=40/screen fps(), because multiplying cross: 40*1=x*screen fps(). Divide both sides by screen fps() and you'll get speed#=40/screen fps(). What's so weird about that?

The evil plan is now even closer!
- - - - - - - - - - - - - - - - - - - -
Specs:- P3 550 Nvidia TNT2M64, 192Mb RAM
Back to top
Profile PM Email
Zero
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: Finland
Posted: 23rd Sep 2002 10:03
Link
The actual bug is, as I have said before, that the object moving with the fixed speed, moves way too slow. DB#1 works fine. SO.. DBPro lies us about the screen FPS, BUT this happens only in one of my projects. Usually it tells 'the right fps'.

The evil plan is now even closer!
- - - - - - - - - - - - - - - - - - - -
Specs:- P3 550 Nvidia TNT2M64, 192Mb RAM
Back to top
Profile PM Email
haggisman
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 23rd Sep 2002 13:15
Link
DBpro lies about the FPS??? Only in one of your projects, well umm that sounds like its your fault. Perhaps if you would post your code we could help you!!!!!!!

Specs:- 1GHZ athlon, Radeon8500, 192mb ram
Back to top
Profile PM Email Website
Zero
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: Finland
Posted: 23rd Sep 2002 17:48
Link
No way, this is my secret project, believe me.. there's nothing funny about the thing I keep telling you.
The reason why this is bugging is that the speed is created from screen fps(). If it returns a bigger value than the 'real fps', the ratios goes all wrong and so the fixed speed is too low. I've told you everyting you should know about the code. Maybe I will write timer()-based fps calculation to fix things up.

DBP still have lots of bugs to fix for example VAL() does not work with real numbers, with decimal separator in string.

There's few funny things also.. I have loaded only one plane into the scene and pitched it down 90 degrees. It is equipped with 256*512 texture (8-bit bmp) and sync rate is set to 0. And what I get.. FPS 50-60. My other project (secret as said before) runs about 266 fps in spite of there are lots of more polygons in that scene.

The evil plan is now even closer!
- - - - - - - - - - - - - - - - - - - -
Specs:- P3 550 Nvidia TNT2M64, 192Mb RAM
Back to top
Profile PM Email
Mentor
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 23rd Sep 2002 22:04
Link
if you want to compare the "real" fps with the one displayed by DB then just this block of code at the START of your programs main loop, in all the examples that run on my system the DB fps is slightly LOWER than the one returned by the millisec timer, you MUST put this block in at the start of the program loop since when an fps is locked the actual loop may only take 1ms but then DB has to wait until the card has refreshed and then wait again for the set time to elapse before doing the refresh, so the block has to calculate the refresh time just after it occurs, since trying to calculate the time before the refresh will give you a stupidly short time, enough explaining, the block........

countscreen=1000/(timer()-timecheck)
text 0,20,str$(countscreen)
timecheck=timer()

the display leaves room at the top for you to put in a text 0,0..etc to display the claimed time from DB, in all the cases I ran DB is actualy faster than it thinks it is.

Mentor.

Back to top
Profile PM
Mike
21
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 23rd Sep 2002 23:48
Link
Hi Zero

Erm I can see from your function that the reason your 40/screen fps thing aint working is due to the fact that you are dividing two normal numbers and storing them as an floating integar. As DBPro is much like a normal language then its worth adjusting it similar to

speed# = 40.0/....

etc

Mike

VapourNET.com
Web Technology Experts
Back to top
Profile PM Website
Guillermo
21
Years of Service
User Offline
Joined: 15th Sep 2002
Location: United States
Posted: 24th Sep 2002 07:35
Link
If you are concerned with the fps, you are really concerned with the refreshing rate. The flickering may be caused by many different things. Remember. Your monitor has 3 main beams of light that have to refresh every frame. There is interlazing, and there is the regular flickering of your monitor.
The human eye supposedly can not see more than 1/24 of a second. This is, 12 frames per second and 12 intervals between the frames. However, with training, people can see a white flash of 1/24 sec duration between dark frames. So, I doubt that you could see flickering at 60 or more FPS.
Any way, if you want to find out what the problem is, have an x=x+1 print statement placed in your animation loop. Also, add a timer between the begining and the end of the animation in the loop. Then, divide x by the total time. This will tell you how many times your animation was refreshed per millisec.
Well, this is just an idea. I do this type of thing in my programs all the time, just out of curiosity.


Guillermo

Back to top
Profile PM Email
Guillermo
21
Years of Service
User Offline
Joined: 15th Sep 2002
Location: United States
Posted: 24th Sep 2002 07:37
Link
I meant to say at 30 fps or more, not 60 fps in the above post

Back to top
Profile PM Email
waffle
21
Years of Service
User Offline
Joined: 9th Sep 2002
Location: Western USA
Posted: 24th Sep 2002 07:55
Link
also, try measuring the update time...

global MasterTimer as integer
global MasterDelay as integer
MasterTimer=timer()
MasterDelay=50

`then in your main loop
do
`do all your normal stuff

`then display the delay time
Text 0,0,"Update time = "+Str$(MasterDelay)
`then if you want this in frames per second
Text 0,20,"My Frames per sec = "+str$(int(1000/MasterDelay))

sync
`now the measure the time
MasterDelay=Timer()-MasterTimer
MasterTimer=Timer()
loop
Back to top
Profile PM Email Website
Zero
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: Finland
Posted: 24th Sep 2002 09:58
Link
Sorry MIke, but I do have 40.0 included in the code, but when I wrote it here, i forgot to put the decimal separator..

Guillermo:
You'll notice if the game runs at 30fps or 60 fps in spite of eye can only 'see' 24 images per second..

The evil plan is now even closer!
- - - - - - - - - - - - - - - - - - - -
Specs:- P3 550 Nvidia TNT2M64, 192Mb RAM
Back to top
Profile PM Email
Richard Davey
Retired Moderator
21
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 24th Sep 2002 13:02
Link
It's true most eyes can only notice around 24 refreshes a second, however this isn't much use unless your eyes are perfectly in sync with your monitor refreshes Obviously this is never going to happen, therefore you'll notice a visible difference between 30fps and 60fps every single time.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Lazzarus
21
Years of Service
User Offline
Joined: 19th Sep 2002
Location:
Posted: 24th Sep 2002 22:06
Link
I've been attemting the same thing using the fps() command and experinced the same sort of problems with slow down of movement. I just tried mentors couple of line of code using the timer and my movement seems alot smoother now.

I compared the result and although close there does appear to be a little difference between the two.

Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-27 01:01:12
Your offset time is: 2024-04-27 01:01:12