not accurate setTimeout and it works only on mousedown - facebook

I have problem with setTimeout.
In all major browsers it works fine but not in IE...
I'm creating a facebook app- puzzle. When player press Start button, the timer starts count his time of playing one game.
At the beginning I used setInterval to increase timer but with cooperate of facebook scripts it delayed about 2 seconds at the end of game. Then I found on stackoverflow trick to increase accuracy of timer: setInterval timing slowly drifts away from staying accurate
And again- without facebook it worked fine, no delays were shown. With facebook it still has delays.
Now to condensate info that might interest You:
When user clicks Start then I create new Date as startTime.
When user ends game script creates finalTime new Date, then substract finalTime - startTime.
In code there is setTimeout:
(...)
f : function() {
var sec_time = Math.floor((puzzle.nextAt - puzzle.startTime)/1000);
$('.timer').html(sec_time);
if (!puzzle.startTime) {
puzzle.startTime = new Date().getTime();
puzzle.nextAt = puzzle.startTime;
$('.timer').html('0');
}
puzzle.nextAt += 100;
puzzle.to = setTimeout(puzzle.f, puzzle.nextAt - new Date().getTime());
}
(...)
when user place on correct place last puzzle piece then I call clearTimeout(puzzle.to);
I have now 2 issues:
not accurate time, in IE it can be even 7 second difference!
in IE during game it works only when user have mousedown... :/
To drag puzzles I use jQuery drag & drop plugin.
At least very helpful info will be how to achieve accurate timer.

You should put your scripts in jQuery's ready function and not at the bottom of the page, as the Facebook SDK is loaded asynchronously and may impact timed executions if they're initiated at the bottom of the page.
As for timing, you're gonna see inaccuracy of between 15ms and 45ms in IE7 depending on other JS executions on the page. Your 100ms timeout will drift badly because of this. Better to record a start time and build a timer with a higher polling frequency than needed and do a comparison between start time and 'now' in each cycle to determine what to do next.

Related

Pause then resuming simulation in Anylogic

I would like to give the user a button that allows them to skip ahead 1 hour in the simulation and then continue running the model if play is clicked. The code below allows the user to skip ahead an hour, however they are unable to resume the simulation when play is clicked.
double nextHour = time() + 60;
pauseSimulation();
getEngine().runFast(nextHour); //Runs the model to the next hour when button is clicked
Any help much appreciated.
Try adding runSimulation() after the last line. But probably, that does not work. In that case:
Create a dynamic event (not the normal event) with the line runSimulation() in its action code.
In the button code, before the runFast... line, write create_MyDynamicEvent(1, HOUR). This will trigger the even 1 hour later and unpause the model.
AnyLogic Support suggested the following solution, which I have used:
Unfortunately, Ben's suggestion didn't didn't work; it seems to cause an issue when pauseSimulation() is used.

Roblox regen script

Im trying to make it so after a player touches a certain brick it falls,that part works.But what I want it to do is to respawn after a set amount of time and the old one be destroyed.Im trying to make an obby with falling bricks.I have no clue what to do
That's pretty easy, all you need to do is add a wait() and then once it's waited said amount of time make it change the position of the block back to what it was. Here:
function onTouched(humanoid)
wait(3)
script.Parent.Position = Vector3.new(0.57, 1.2, 1.23)
end
script.Parent.Touched:connect(onTouched)
Put this script in the brick you want 'regenerated' and change the wait and position to what you want.

How to properly measure elapsed time in background in Swift

I have this two functions that measure the elapsed time when the phone is locked or the app is in background:
func saveTimeInBackground(){
startMeasureTime = Int(Date.timeIntervalSinceReferenceDate)
}
func timeOnAppActivated(){
stopMeasureTime = Int(Date.timeIntervalSinceReferenceDate)
elapsedTime = stopMeasureTime - startMeasureTime
seconds = seconds - elapsedTime + 2
if seconds > 0 {
timerLbl.text = "time: \(seconds)"
} else {
seconds = 0
timerLbl.text = "time: \(seconds)"
}
}
and then in the viewDidLoad() i have observers that are trigger the functions when the app becomes active/inactive:
NotificationCenter.default.addObserver(self, selector: #selector(saveTimeInBackground), name: Notification.Name.UIApplicationWillResignActive, object: nil)
NotificationCenter.default.addObserver(self, selector: #selector(timeOnAppActivated), name: Notification.Name.UIApplicationDidBecomeActive, object: nil)
The problem is that when the app becomes active there are 2 seconds (approximately) of difference so i've added 2 seconds and it seems to work fine, but only if the elapsed time is > 15 seconds.
If i lock the phone and immediately unlock it the there are like 5 or more seconds that are missing. For example, if there are 50 seconds left, when i lock and immediately unlock it there are like 42 seconds left.
Can anyone please explain, what i am doing wrong?
Edit: The logic of the app is this:
It starts a match between 2 players with 60 seconds for a game. The problem is that when one of the players locks the phone the app stop to measure the time. This way if the player1 has 10 seconds left to make a move, the player2 still has 50 seconds left. I'm looking for a reliable way to calculate the time even if the player locks the phone or put the app in background.
Edit 2: I think i figured out what the problem is: I think the issue has to do with the fact that the “seconds” are Int, and the Date not and when it gets converted it’s rounded up. I didn't tested it, but when i ahve the solution i'll post the answer. Thanks all for your time!
You're relying on exact timing of notifications that aren't guaranteed to have any exact timing. There's no guarantee about when, exactly, either of those notifications will arrive, and there's nothing you can do about that. Even your two-second fix is, as you say, approximate. It'll probably be different on different models of iPhone or even at different times on the same iPhone, depending how busy iOS is when you check.
What's more, when you go into the background, you can't be certain that you'll stay there. Once in the background, iOS might decide to terminate your app at any time.
I'm not sure what the goal is here but I think you'll need to reconsider what you want to do and see if there's some other approach. Your current two-second hack will, at best, spawn a bunch of other hacks (like the 15 second threshold you mention) without ever being especially accurate. And then it'll probably all break in the next iOS update when some iOS change causes the timing to change.
I would use Date object to track game time.
func gameStart() {
gameStartDate = Date()
}
func timeOnAppActivated() {
let secondsLeft = 60 - abs(gameStartDate?.timeIntervalSinceNow ?? 0)
if secondsLeft > 0 {
timerLbl.text = "time: \(secondsLeft)"
} else {
timerLbl.text = "time: 0"
}
}
Ok, like I mention in the edit 2 of the question:
The first issue was because "seconds" is a Int and then it almost always gains or lose when converting it from Double.
But the main problem was that i had to invalidate the timer when the app enter in background and i didn't.
So now with invalidating the timer when the app gets the notification that will enter background and then starting it when it enter foreground everything works fine.
To test this properly call those methods on button click. It may be coz of delay in releasing some resources in background.

Resume game from time at which it was paused

I am writing a game using CreateJS and using CocoonJS to distribute. Within CocoonJS API are a couple of listener functions that allow callbacks when pausing and resuming of the game. The game's timer and (time-based) animations are driven by the Ticker event's "delta" property. The issue that I am having at the moment is, on resuming the game following on from pausing it, the timer will pick up from the time at which it paused plus the time spent whilst paused. For example, I pause the game after 20 seconds for exactly 4 seconds, on resuming the game the timer will carry on from 24 seconds (not 20 seconds, which is intended). I've tried storing the ticker event's "runTime" property before pausing and attempting to then set the ticker event's "runTime" to this stored value on resume, but this doesn't work.
A snippet of my original code (before tinkering) is like the following:
createjs.Ticker.setFPS(60);
createjs.Ticker.on("tick", onTick, this);
Cocoon.App.on("activated", function() {
console.log("---[[[[[ APP RESUMING ]]]]]---");
createjs.Ticker.paused = false;
});
Cocoon.App.on("suspending", function() {
console.log("---[[[[[ APP PAUSING ]]]]]---");
createjs.Ticker.paused = true;
});
onTick = function (e) {
if (!e.paused) {
animateUsingTicker(e.deltaTime);
countDownTimerUsingTicker(e.deltaTime);
//etc...
stage.update();
}
};
Can someone please assist me on this?
Many thanks
One really easy way to deal with this is to use Timer.maxDelta. For example, if you are targeting 60fps, you could set this to something like 32ms (double the expected delta), to prevent getting huge values back when resuming an app/game.

libspotify C sending zeros at the end of track

I'm using libspotify SDK, C library for win32.
I think to have a right setup, every session callback is registered. I don't understand why i can't receive the call for end_of_track, while music_delivery continues to be called with zero padding 22050 long frames.
I attempt to start playing first loading the track with sp_session_load; till it returns SP_ERROR_IS_LOADING I post a message on my message queue (synchronization method I've used, PostMessage win32 API) in order to reload again with same API sp_session_load. As soon as it returns SP_ERROR_OK I use the sp_session_play and the music_delivery starts immediately, with correct frames.
I don't know why at the end of track the libspotify runtime then start sending zero padded frames, instead of calling end_of_track callback.
In other conditions it works perfectly: I've used the sp_track obtained from a album browse, so the track is fully loaded at the moment I load to the current session for playing: with this track, it works fine with end_of_track called correctly. In the case with padding error, I search the track using its Spotify URI and got the results; in this case the track metadata are not still ready (at the play attempt) so I used that kind of "polling" on sp_session_load with PostMessage.
Can anybody help me?
I ran into the same problem and I think the issue was that I was consuming the data too fast without giving other threads time to do any work since I was spending all of my time in the music_delivery callback. I found that if I add some throttling and notify the main thread that it can wake up to do some processing, the extra zeros at the end of track is reduced to one delivery of 22,050 frames (or 500ms at 44.1kHz).
Here is an example of what I added to my callback, heavily borrowed from the jukebox.c example provided with the SDK:
/* Buffer 1 second of data, then notify the main thread to do some processing */
if (g_throttle > format->sample_rate) {
pthread_mutex_lock(&g_notify_mutex);
g_notify_do = 1;
pthread_cond_signal(&g_notify_cond);
pthread_mutex_unlock(&g_notify_mutex);
// Reset the throttle counter
g_throttle = 0;
return 0;
}
As I said, there was still 22,050 frames of zeros delivered before the track stopped, but I believe libspotify may purposely do this to ensure that the duration calculated by the number of frames received (song_duration_ms = total_frames_delivered / sample_rate * 1000) is greater than or equal to the duration reported by sp_track_duration. In my case, the track I was trying to stream was 172,000ms in duration, without the extra padding the duration calculated is 171,796ms, but with the padding it was 172,296ms.
Hope this helps.