I may have discovered a memory leak...
Turns out, whenever I do animations on an icon bigger than 32x32, it seems to just build up the ram massively. Byond craps out once it hits 2gigs. I'll have tot est on my home computer as well to make sure it's not something on this machine that's causing it. Edit: Actually seems to happen even with tiny icons. Everything getting created by my effects system seems to be sitting around in ram. Looks like I'll have to implement an effects pool like I did with the tank game. Still, this concerns me, it means nothing's getting deleted, even though I've set all the relevant variables to null, and even called del() anyway. | |
http://www.byond.com/forum/?post=1995892
Can I get a hell yeah? Whilst it's true that you should be taking care of this yourself, inevitably you end up missing something. | |
Yut Put wrote:
no, saving every room removes penalty for dying. one of the best parts of metroid games is the feeling of "i better find another save room or i'll lose my stuff" Think of the casuals not the hard core. | |
Well, I did as you suggested.
My effects are deleting properly, but the ram's still there. Something tells me all these animations are getting cached and not properly being removed fro memory... or something Like I said, it may be my system. I'm running Win 10 and using a gtx 550Ti I'll have to test my system at home to see if the ram builds up the same way, if it does I'll know it's just not the machine. | |
Sorry for the double post, but I figure on a better solution: You all can test it for me, yaaaaay!
https://dl.dropboxusercontent.com/u/25108410/LuxTEST.zip Here's the link to the current build, the charge animation seems to build up ram the fastest. if you experience the same issue with ram PLEASE let me know. Also some warning: This build is not meant to be played so expect strange behavior from unfinished enemies or terrible looking rooms. | |
What's the name of your game btw @bravo
| |
Does it stand for anything :D?
| |
:c okay. | |
The only thing that can cause the ram to go up is assigning variables, since they're memory. Actual operations take very little ram, rather CPU (makes sense).
So check to see if you're adding to a list perhaps, because if they're getting GC'd properly then it should stop using that RAM later. Maybe you're adding a reference to a list, then setting the list index to null instead of removing it properly? That's a common one I make, since lists CAN contain null elements. Before I fixed it (earlier today actually) my update loop list could reach well over 5k indexes in a matter of minutes, because it was just full of null elements (Which still use up a small bit of RAM). | |
Nope, no lists. I just create an object, modify it's variables, position it on the map, flick or animate() it, then delete it.
I wonder if it has anything to do with how the proc is set up though... It has 9 arguments, not sure if that does anything. | |
Found it
When you use icon+=[rgb] it creates and caches an icon with that exact rgb addition done to it. If you randomize the colors going in, a new one is created if one isn't found with the same exact color applied to it. No problem there. The issue is that after these are set to null or the object with that icon is deleted, the icon is never erased. It just chills out in your ram. I did multiple tests and the more variation you have the faster and more ram it builds up. Making a bug report now. | |
Wait are you using icon operations instead of using the color var?
You deserve everything you get. | |
Because color works differently than adding rgb values to an icon.
 First example is +rgb(25,0,0), Looks brighter and has an upper limit of everything becoming white. Second is color=rgb(255,0,0), looks darker and has an upper limit of everything becoming black. Not only that but color applies to anything attached to the mob as well, so all images will get that color applied unless you've set RESET_COLOR in the appearance flags. With color, as far as I've tried, there's no way to get an icon where you can change the color, and it will result in a fade from that color to white within the icon. Conversely, you can't fade to black within an icon using +rgb, you have to use color for that. | |
You can accomplish that effect using the full version of color instead of using rgb(). For example.
animate(src, transform = matrix()*2, color = list(0.6,0,0,0,0.2,0,0,0,0.2,0.5,0,0), time = 1)//color = rgb(150,50,50), time = 1)This is my take damage proc's animation. It sets the color to a list with the values rr,rg,rb,gr,gg,gb,br,bg,bb. It's very vibrant looking, and looks identical to your second example. Literally anything (aside from a few very niche things) that can be accomplished by icon operations can be done better with animate(). | |
color = list(0.6,0,0,0,0.2,0,0,0,0.2,0.5,0,0) I honestly don't understand what's going on here. Like... I need an explanation of the whole rr,rg,rb,gr,gg,gb,br,bg,bb thing. | |
It's impossible to cancel it once it's begun, and the player is locked until the light show finishes
It's basically to allow player to pass by and touch the save platform without being prompted or forced to save immediately when they touch it.