Actual code size in editor is affecting available memory program has to start with until fuze restart
-
@Spacemario no your not seeing ghosts i have seen the exact same issue with my game as well. smooth fps at fuze restart. After a couple runs of my game fps is less smooth and cpu time has gone a bit up (which is the cause of the fps drop). I can not explain it either (except perhaps memory fragmentation or so) but don't think thats related to this issue (although it could if you run really low on memory then fps drops quite a bit from what @Gothon said on discord) . I think its a seperate issue but you are not alone in noticing it
-
@joyrider3774 Thanks for that info-- it's not my game! (probably :D ) And I'm not going crazy (unlikely :D)
Funny anecdote, I actually have my chip music play every so slightly faster in three and four player split screen, in case players run into the framerate issue.
Since all of my timers are dependent on the main game loop and hence the framerate, slow-motion music is the dead giveaway in my game.
-
@Spacemario while its hard to reproduce, you need a game or app where you are nearly hitting the maximum cpu time before fps drops (so barely hitting 60 fps) then its easier noticeable when it happens. I was able to workaround the issue a bit by searching for optimazations and applying them. Then i had some more spare cpu time and when those small slowdowns would start happening again it would not occur or occur less drastic. Maybe you can still find some optimazations and to have more broader cpu time left to spare it would not be noticable if it would happen as i did. But that's easier said than done :)
-
@joyrider3774 Oh, I most certainly can! I'm straddling a line right now between readable, well-factored code on one extreme, and bare-to-the-metal brutally efficient code on the other extreme.
If I absolutely need to, I can "de-factor" some more code to make it faster (fewer loops, fewer abstraction functions).
Right now the game is very playable in four-player-- locked 60 fps on a fresh Fuze run, in fact-- with only one sacrifice (I'm not drawing one of the map layers, and have a cheaper compromise visual effect instead), and I'm just about done adding engine mechanics, so my "engine" shouldn't get any slower.
Now it's on to level design... I always have a tough time switching gears, I want to just keep adding features and stay in the code :D
In any event, thanks for letting me bounce some stuff off you (figuratively :D ).
-
@Spacemario Sounds like it would be a good idea to decouple the music timers from the update frequency?
-
@Spacemario can you make it happen on purpose ? if so can you record the debug info part of the screen. Like what does the lower right nr do ? does it go quickly from a high(er) nr to 0 and and the back to the high(er) nr and back to 0 really quick in a repeating manner or does it stay steady around the same nr?
-
@vinicity Agreed! Actually, is there a way in Fuze to decouple all timers from the main game loop? The way my game works now reminds me of certain CGA/EGA-era DOS titles in the 80s, where jump height and stuff was inadvertently tied to the framerate :D
It's like the timers should be based on real-world time increments or some equivalent, not just an integer getting incremented/decremented each frame.
-
@joyrider3774 I absolutely can reproduce it! All I need to do is run the game like four or five times in a row from the editor-- I'll record a video later today and post it.
-
@Spacemario check the code for my music example. The second song has a detached timer. I’m thinking the same principle could be used for all timers.
As for making movement that isn’t tied to the update frequency, one easy way is to multiply the movement with deltaTime().
-
@vinicity Thanks, I'll take a look! And yeeessss... deltaTime... that sounds exactly along the lines of what I was thinking...
In the interest of time, I'm tempted to just forge ahead with my game as-is, then make a "2.0 engine revision" with improvements like this, and which I (and others if they want) could also use for future projects...
