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.

AppGameKit Classic Chat / Need help slowing down an operation via the Screen Refresh Rate ...

Author
Message
ProfVersaggi
12
Years of Service
User Offline
Joined: 6th Apr 2012
Location: Maastricht Netherlands / Chicago, USA
Posted: 6th Mar 2013 14:09
I have a series of physics enabled sprites, each of which gets gets positioned by SetSpritePositionByOffset in the main loop. The problem is that the sprites get repositioned too fast. I need to slow the process down some how but I'm not sure how.

I've used a counter 'scheme' that incorporates GetSeconds() and checks to see if a 1/2 second or second has gone by but in practice that results in only the first of all the sprites actually being updated, the others *never* get the update command.

Is there a better way to 'slow down' an arbitrary operation relative to the screen refresh rate of the main loop?

----
From the Desk of Prof Versaggi ...
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 6th Mar 2013 14:21
hmmm,
SetSpritePositionByOffset skip the physic system.
regular you have forces for movement and friction as brake.
maybe is CreatePhysicsForce interesting for you too.

here is a example with SetSpritePositionByOffset
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 6th Mar 2013 16:15
You could reduce how far the objects move each time to make them appear slower moving. So if you are moving at 1 pixel, try 0.5, until it moves as desired. You may be better using physics commands to move your objects when using physics though.

ProfVersaggi
12
Years of Service
User Offline
Joined: 6th Apr 2012
Location: Maastricht Netherlands / Chicago, USA
Posted: 6th Mar 2013 16:59
I think I need something more along the lines of updating every 10th screen refresh or something ....

----
From the Desk of Prof Versaggi ...
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 6th Mar 2013 18:36
Depends on how physics enabled the sprites are

One option is to use Time Based movement - where everything is set up in relation to a second of time. Any movements on a frame basis are done by multiplying the value per second by getFrameTime().

For example, if your object moves 200 pixels per second and you are getting 60fps, getFrameTime() will return 1/60 or 0.16667.

So the 200 pps object will move 200 * 0.16667 pixels this frame. If the frame rate drops, the movement per frame increases.

With TBM, you get the value from getFrameTime() and multiply it by some factor before applying to achieve the speed change.

I typically use two globals, on to hold the raw value - called something like AppFrameTime, and another which is used for game objects - called something like GameFrameTime

This is so that the game objects can be slowed down and speeded up, while game independent stuff - such as menus - keep the original speed.

Which is where the "how physics enabled" question comes in, if you are moving some objects with physics, then you will need to adjust the physics playback speed in the same way to keep them in sync with TBM times.
ProfVersaggi
12
Years of Service
User Offline
Joined: 6th Apr 2012
Location: Maastricht Netherlands / Chicago, USA
Posted: 6th Mar 2013 20:28
<' then you will need to adjust the physics playback speed in the same way to keep them in sync with TBM times.'>

I followed you up until this point ... how is that actually done?

----
From the Desk of Prof Versaggi ...
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 6th Mar 2013 23:17
I think you can probably surmise from the way I skipped over that part, that I actually have no idea.

I could guess, but having not tried messing with the physics beyond the usual "set something moving .. watch it move", it would be just that.

I'd look at how changing gravity and at the same time changing the velocity works, but maths is not a strong subject for me and physics - for get it.

...or you could not use physics - I can do that.
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 6th Mar 2013 23:24
I've not actually tried it, but I think StepPhysics() allows you to control physics timings...
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 6th Mar 2013 23:33 Edited at: 6th Mar 2013 23:34
Erm, yeah, that's what I meant to say

But seriously, before posting, I went to the help to see if I could see a command for it, but my Physics page is blank.

No really it is, but I don't know if it's an issue with the beta or something at my end. Don't know if I've looked at it since the last update.

Attachments

Login to view attachments
lilpissywilly
AGK Developer
14
Years of Service
User Offline
Joined: 10th Sep 2010
Location: Office Chair
Posted: 9th Mar 2013 21:35 Edited at: 9th Mar 2013 21:37
I've actually tried mixing timer-based-movement with physics and you can just try setting the FPS to say 30 to see that box2d handles this just fine.

I tried a system where you can set the stepPhysics() based on fps but box2d handles it better left alone IMHO.

If you want to check something less often than every frame I would do something like: (depending on if you want to use timer-based or not)

None timer-based:



timer-based: (one way of doing it)



now the second way of doing it makes it so that if you have for instance 60 FPS as your target, the + 1 would be times 1 (0,0166666666666667 * 60 = 1), so it would stay at + 1. If your game would slip to let's say 30 FPS at one point the increment would be + 2 (0,0333333333333333 * 60 = 2) and thus would reach the number 10 at the same time regardless of current FPS.

So that's one way of doing it timer-based, another way is just to increase myTimer# with getFrameTime() and decide the amount of time you would like to pass. Either way

*Edited twice because of spelling - slightly pissed lilwilly

My hovercraft is full of eels
ProfVersaggi
12
Years of Service
User Offline
Joined: 6th Apr 2012
Location: Maastricht Netherlands / Chicago, USA
Posted: 11th Mar 2013 12:37
lilpissywilly - (that name *is* awesome) .... the timer piece worked like a charm. The big question is: "Does it have to be called from the main do-loop or can will it be just as effective embedded somewhere else in a function that gets called? Like say in a finite state machine somewhere?

Big thanks again for the helpful tip!

----
From the Desk of Prof Versaggi ...
lilpissywilly
AGK Developer
14
Years of Service
User Offline
Joined: 10th Sep 2010
Location: Office Chair
Posted: 11th Mar 2013 13:30
The key is, in this case, that myTimer# is updated every frame and checked in every frame if it has reached its goal (10 in the example). So yes it's suited to be in the main-loop or in a function called every loop in the main-loop.

Glad it worked

My hovercraft is full of eels

Login to post a reply

Server time is: 2024-11-24 09:33:57
Your offset time is: 2024-11-24 09:33:57