FPS Issue with Gideros 2018.6.1

kussakov · June 2018

Hi Guys,

I just upgraded my Gideros from 2017.X to 2018.6.1.
All of my projects/apps started going really fast on the emulator. Actual FPS shown is like 90FPS.
All projects are set to 60FPS.
application:getFPS() returns 60, the emulators displays 90.
Tried to set the FPS specifically to 60, but no luck.
Tried an option that was not on my previous version: VSync - no luck - same FPS.

Any advice?

Cheers

SinisterSoft · June 2018

The VSYNC option may require a close and re-open of the emulator.

Also, try restarting your computer.

oleg · June 2018

Use the "deltaTime"
http://docs.giderosmobile.com/reference/gideros/Sprite/Event.ENTER_FRAME

totebo · June 2018

@kussakov I noticed this only when I'm running a HTML5 game on my external monitor on Mac. What system are you on?

Although deltaTime is great it would be good to have a guaranteed FPS around the setFps() value.

kussakov · June 2018

Thanks for the replies!

I agree with @totebo. We must have guaranteed FPS. I have been using Gideros since 2013. This is the first time I experience this issue and it affects all of my projects.
What changed?
I can't just redo all of by apps. It is too much work and I have one particular project that heavily depends on FPS which will need a big redesign.
I restarted the player, the computer, installed the latest drivers, etc. No change.
BTW: I have DELL XPS with Windows 10 and Nvidia graphic card.
I am going to downgrade Gideros, version by version and report in which version this was first introduced. I am going to use the version prior to that...

SinisterSoft · June 2018

It's only on the player - I think export should work ok.

kussakov · June 2018

I see. So setFps/getFps no longer work on the player :-(
I tried with setFps(30). It got even worst since the real FPS is still 90.
Since I use a big touch screen computer I heavily depend on the player for testing and rapid development. Until recently the player and the device work exactly the same and I could count on the fact that if the simulation and timings work on the player - all would work exactly the same on the device.
Anyway... I have a temporary workaround - I will downgrade and not use the new features and fixes for now.

BTW: Do you know if I can have two versions of Gideros on the same computer?

Thanks!

kussakov · June 2018

I just tried to redesign one of my projects to not be dependent on FPS.
It uses Gideros Particles class a lot.
It requires number of frames:
"ttl: time to leave, number of frames this particle will stay on screen"
How do I address this?
Thanks!

oleg · June 2018

fps=60

k=fpsreal/fps

ttlreal= ttl /k

kussakov · June 2018

Hi @oleg,

How do I get fpsreal? getFps returns 60.
If I knew how to get the real FPS I would not ask all these questions and fixing all projects will be really easy.

Thanks!

oleg · June 2018

deltaTime*fps=1sec

1sec/deltaTime=fps

oleg · June 2018

local frame = 0
local timer = os.timer()
local function displayFps()
        frame = frame + 1
        if frame == 60 then
                local currentTimer = os.timer()
                print(60 / (currentTimer - timer))
                frame = 0
                timer = currentTimer    
        end
end
 
stage:addEventListener(Event.ENTER_FRAME, displayFps)

kussakov · June 2018

I see. You mean to calculate it dynamically. This may work for some parts of the code - like the particles.

Thanks!

SinisterSoft · June 2018

The delta is given to you each frame, use that in addition to the set frame rate to find the multiplier for movement. The built-in particle sprites already do something similar to this.

local frameRate=application:getFps()
local fineSkip=0
 
function gameLoop(e)
  fineSkip=e.deltaTime*frameRate
 
  x+=5*fineSkip  -- move 5 pixels if frame rate accurate, else more if slower rate or less if faster rate
 
end
stage:addEventListener(Event.ENTER_FRAME,gameLoop)

totebo · June 2018

Most of my games rely on Box2D. What's the best way to use deltaTime to account for varying frame rates in Box2D? Continuously changing the stepping value? Use deltaTime as a multiplier for all applyForce and other movements? Or both?

SinisterSoft · June 2018

Box2D is built to use the delta, just let it know what it is...

world:step(e.deltaTime,1,5)

totebo · June 2018

Perfect, thanks!

oleg · July 2018

SinisterSoft said:
The delta is given to you each frame, use that in addition to the set frame rate to find the multiplier for movement. The built-in particle sprites already do something similar to this.
local frameRate=application:getFps()
local fineSkip=0
 
function gameLoop(e)
  fineSkip=e.deltaTime*frameRate
 
  x+=5*fineSkip  -- move 5 pixels if frame rate accurate, else more if slower rate or less if faster rate
 
end
stage:addEventListener(Event.ENTER_FRAME,gameLoop)

for windows e.deltaTime does not work properly
need to calculate fps through os.timer

**
the ball is fineSkip windows
milk fineSkip android

hgy29 · July 2018

You may want to use http://docs.giderosmobile.com/reference/gideros/Core/frameStatistics#Core.frameStatistics to get current fps

oleg · July 2018

hm...

kussakov · July 2018

Guys,

We are missing the point:

Why should we do ANY of that?
These are all workarounds. They do not fix setFps and getFps APIs.

It was working just fine for many years.

What changed? Why breaking something that worked? This is not progress.
Can that (regression?; attempt at improvement?) bug just be fixed in the next version of Gideros, so that getFps and setFps work again and we have stable FPS for all devices?
That is my real question.

Cheers

Vlad

hgy29 · July 2018

Vlad, I think the vsync thing would have broke it up on some configuration. This is a complex topic since frame rate isn’t just 60Hz, it ought to be what your monitor actually support. Can you check what is the refresh frequency of your monitor ?

I am working on gideros those days so I’ll take a look at what was done in the code and how that could possibly have affected non vsynced rendering.

edit: if I am correct, the issue was introduced in 2018.3, it would be great if you could do a before/after test to confirm

kussakov · July 2018

Thanks hgy29! I understand.
I will try that in an hour or two and let you know.

kussakov · July 2018

@hgy29, you are right.
The issue first appears in version 2018.3
2018.2.1 does not have this issue.

hgy29 · July 2018

Thanks, now we know where to look. Gideros Player outputs some debug about VSYNC capabilities of the computer, could you post them here ? You can grab them with DebugView (https://docs.microsoft.com/en-us/sysinternals/downloads/debugview), they should be something like GLFMT: xxx lines

hgy29 · July 2018

I made a patch to gideros to ensure we use the original timed refresh if vsync option is not enabled, no matter what the OS reports: https://github.com/gideros/gideros/commit/88feef07e8472eb2da26b6301ec88a7edd3181cf
This should fix your issue.

kussakov · July 2018

Thank you very much @hgy29!

hgy29 · July 2018

I am still interested in those GLFMT debug lines if you don't mind, to better understand what is going on.

antix · July 2018

When is 60fps not 60fps?

It is quite interesting that I have 2 android devices running my game. Both are reporting 60fps. Rotating a sprite at a fixed rate of rotation causes them to rotate at different speeds. Running the game on the windows player causes the sprite to rotate even faster.. but it is still reporting that it is running at 60fps.

Confusing to say the least.

totebo · July 2018

By "reporting" do you mean getFps()? Or a calculated FPS?

antix · July 2018

using getFps()

Howdy, Stranger!

Categories

In this Discussion

Top Posters

FPS Issue with Gideros 2018.6.1

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

FPS Issue with Gideros 2018.6.1

Comments