Actual code size in editor is affecting available memory program has to start with until fuze restart
-
@Willpowered @Dave we actually found out the memory leak has got nothing todo with loadimage as i initially thought. if you do a for loop with 1000 iterations all doing the same loadimage call it does not (seem to ) happen. But if you place 1000 loadimage calls on a seperate line it does happen.
So we tested some more ... And it seems it's nothing related to functions at all but actually the size of your source code in the editor itself. If you do 5000 times (on a seperate line)
x = 5memory goes down as well.Or 10000 lines with
test = "this is a test this is a test this is a test this is a test"you'll notice it even quicker as memory goes down with al most 5 mb after each restart.So it seems the source code itself being loaded into the interpreter or the code being (re)loaded in the editor makes this leak happen. And the bigger your code is the more MB you will lose between multiple restarts of your program / game
-
I can confirm this as well. You don't even need to actually type code into the editor. If you were to put 1,000,000 of the character
4into the editor which is equivalent to 1MB. Each time you run the program and exit and run it again. You're losing memory 1-2 MB per every run of the program. So in effect, the interpreter is not freeing old source code. -
Thanks for the report, and for confirming that it's related to program size! We're aware of the issue and have plans to address it.
-
Might be totally unrelated, but I've noticed both memory usage and lower framerates in my current project, the longer I leave Fuze running: silky smooth sixty frames per second when I run the game after a fresh Fuze restart, fifty to fifty five frames after I've restarted the game several times.
May also be user error: I could just be missing a sprite removal somewhere. But figured I'd at least mention that I'm seeing it.
-
@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...
