Timers produce wired errors and also some FUZE crashes
-
Hi i am havin a bad time with timers, i think it's a code interpreter related issue.
if you want my full code pm me and i'll add you as a friend, it's too long to re-type in here
here is an over simplyfied version of my code:
//some constants array map[512 * 256] //this array is the map which is an array of integers each one representing a tile id array tiles[256] //array containing the tiles data, the position in the array is the id of the tile //some tiles constants declared /*array of integers containiing the controls actions triggered when it was last updated, used to allow for easy tracking of actin with the use of multiple controllers at the same time, like using both the analog stick or the arrows to moove a character, it's also used to allow for easy read of input by different parts of the code and not having too mutch input dedicated variables, but rather a standard way of accessing it, but i was thinking about replacing it with a struct instead, because this still requires some constants, while a struct does not*/ array controls[20] //for loop to fill the first 128 tiles with the ascii characters in order to allow for text on the map which is not a tile //some other variables and constants declared here //game execution starts here, some times also this guy here caused the game to crash or fuze to crash timer = setTimer(1 / 30, 1, scheduled()) setupMap() gameLoop() function gameLoop() loop checkDocked() //checks if the switch in docked mode and adjust the screen resolution accordingly setBG() //clears the video buffer and then draws a square on it as large as the screen to fill it with the appropriate bg color uIRender() //draws a text line using a bunch of printat calls, plus it prints out some debug info /*makes a bunch of printat and ink calls to display the praphics for my text game including different colors for the character which are on screen*/ displayRender() //here goes some code to calculate the screen renders/second (which are not frames, because the update function adds some time if the framerate is higher than 60 like what happens with this game update() repeat return void //this function is used to handle user input indipendently from the screen drawing using what should be an infinite repetitions timer, so with this we can have consistent playability while the game runs at various framerates, and so not being slown down by laggs or going too fast with high frame rates, only downside is that with high framerates i get some teering, i need to figure out a way to have vertical sync function scheduled() getInput() //fills the inputs array with input data basically checkAndMoove() //calculates the camera position and moove the player accordingly to the inputs stopTimer(timer) /*this guy right here makes fuze to produce errors or crashes, no matter where i moove it or the arguments i use, but i need an infinite repetition timer and is the only way i know of doing it in fuze. it causes errors like fuze giving messanges about invalid types followed by random integrer numbers at random lines in code, fuze crashing and incorrect ammount of arguments for functions*/ timer = setTimer(1 / 30, 1, scheduled()) return void //here implementation of the function i mentioned and of some other handy functionsa setup which i think is enought to replicae it (not tested)
//variables and large arrays declarations (maybe not necessary) timer = setTimer(1 / 30, 1, scheduled()) //large array filling (maye not necessary) //some other stuff being executed //some functions decalaration (maye not necessary) function scheduled() //some funcions calls (maybe not needed to trigger the bug) stopTimer(timer) timer = setTimer(1 / 30, 1, scheduled()) return voidAn easy fix to my issue is to introduce timers with unlimited schedules until they are stopped, so i have to set the timer just once and forget about it until i need to close the game
Additional info: the bug happens no matter of the arguments i use for the settimer function, but i know for sure it's caused by it, commenting it out makes the whole thing work fine, so i think that there are some serious timer-related issues
-
@ITzTravelInTime
Hi I have just tried your code from Twitter and confirm that it crashesHowever if you add a main program loop it doesn't:
timer = settimer(1 / 30, 1, sched()) loop update() repeat function sched() clear() update() print("test") update() stoptimer(timer) timer = settimer(1 / 30, 1, sched()) return voidIs there a reason that you are redefining the timer in the callback function?
-
@pianofire i use my main loop in a function called after initializing the timer and it still crashes or throws some wired errors
-
@pianofire the reason for the redefinins is that fuze don't allows for timers with unlimited repetitions
-
-
to avoid the bug all together i just use an insanely high number of repetitions for the timer call, so it should last long enought even for the longest game sessions, and so i avoid resetting the timer all together and so i can just perform a normal timer call at the start of the game's execution, that's the best way of workaround the issue for now, until we don't have an official way of resetting the timer after it runs out of repetitions or they add an endless repetitions timer
-
@ITzTravelInTime Why not just use -1 for unlimited repetitions?
-
@_JKDOS Is that a thing? the documentation doesn't mention it
-
I'm also getting alot of errors while timers are running. Shorter the interval the more likely I am to get an error. The -1 is a neat trick though. Wish I knew that yesterday
-
I've come across some odd behavior with the timer as well. I was attempting to utilize the timer for MML playback for purposes of higher-precision playback rather than once every frame (though I have it set to 1/60 just to keep it in time with the typical approach). I would store the handle for the set timer in my MML structure, but when doing this in certain spots within my initialization function or some other functions relevant to loading/playing provided MML data, I get an error regarding the function used for the timer callback about an "incorrect number of parameters for function", even though the callback function has no parameters. Other functions seem to have no issue, including when done globally (even when still assigning it to this structure). Here's the thing. The line number in the error message is ludicrous. Just now, it says the error lies on line 1848996251. Yep, almost line 2 billion. My code is barely 1,000 lines long. Sometimes, depending on where I place it, the line number will be just as bad in the opposite direction, with it being negative. It'll even crash the program when the line is move close to either the beginning or end of a function.
-
@Discostew I sometimes get the parameter error also with timers and the error report just seems to be random line number and error
-
@sys64738 said in Timers produce wired errors and also some FUZE crashes:
@Discostew I sometimes get the parameter error also with timers and the error report just seems to be random line number and error
The same thing happened to me, but this -1 solution has actually saved me
-
Hang tight, we're aware of some issues involving timers and we're working to address them in a coming patch.
In the meantime, you can work around the FUZE language timers by writing your own timers manually:
some_timer = 0 // initial timer value some_timer_max = 2 // the interval in seconds you want your timer to run at // your game loop loop some_timer += deltaTime() // keep track of passing time for your timer if some_timer >= some_timer_max then some_timer -= some_timer_max someFunction() // run whatever function you like! endif repeat -
@Willpowered Thank you, but for what reguards the programs i am working on i need timers because with those i can have consistent controls reguardless of the framerate and the use of the -1 for the repetition times fixed this to me, you should really put more info in the documentation
-
@ITzTravelInTime Same here with consistency. For my MML player, I want to give users of it 2 options. One without timers, and one with. With timers, they not only benefit from higher resolution timing for more accurate playback, but by having it on a timer, it won't stop or glitch if they have to process a lot of stuff in the main loop in one go because, unless I'm mistaken, it would/should interrupt what's being processed to process that stuff from that timer. Of course without timers, they wouldn't need to use a timer at all, allowing them to use it for other purposes.
