I was trying to add a little icon for one of the objects in my project, and when I added the code I expected to make it show up, my game started crashing upon loading.
After some frustrating debugging, I found out that although I was setting the ID of the object when I constructed it, the ID was leaving the constructor function as -1. It turns out, FlxBasic, which the object is a subclass of, sets the ID to -1 when it is constructed, and I had put super() in AFTER setting the object ID. As soon as I moved super() to the front of the constructor, everything worked again.
Sometimes the most aggravating errors are the smallest, simplest ones.
Sunday, November 20, 2011
Sunday, November 6, 2011
Programming Challenges: Garbage Collection
Flash (and many other programming languages) have a wonderful feature that makes program development easier to get into. Flash has a Garbage Collector that runs automatically when the program's memory reaches its limit. Basically, the Garbage Collector (GC) checks all the objects to see if they're connected to anything. Anything with 0 connections gets deleted and the memory it took becomes available for use again. Next, the GC checks every connection from the root of the program and marks everything that's still connected to root. Anything not connected back along some line can't be accessed ever again by the program, and is also deleted, even if it has links to other objects.
In order for the garbage collector to be effective, any objects your program isn't going to need ever again need to be disconnected from everything. Objects with 0 links are much faster for the GC to find and remove than groups of interconnected objects that are inaccessible to the program.
A good way to imagine this is a cork-board with a bunch of pins, and strings linking one pin to another. Each pin is an object. Each string connecting one pin to another is a link. The Garbage Collector comes along when your board is too full of pins to put any new ones in.
As you do things on your cork-board, you want to cut all the strings connected to a pin you're done with, because that's the easiest and fastest way for the GC to know it needs to be pulled out.
Another way to manage memory (and it's more memory-efficient than good garbage collection practices) is to recycle objects when you're done with them. That is, change the values of an object you're done with to match the new object of the same type you want to create.
You could have an array of objects you re-use often, and whenever you would want to make a new one, it first sees if there's anything in your recycle array. If there is, it assigns the new values to the existing object and assigns that object to the needed reference. If there is nothing in the recycle array, then it creates a new object. Whenever you're done with an object, you add it to the recycle array and then cut all other references to it.
If you do this, you'll want a function in each recycled object's class that resets its variables, with the same inputs as the constructor. In fact, it will usually mirror your constructor.
In order for the garbage collector to be effective, any objects your program isn't going to need ever again need to be disconnected from everything. Objects with 0 links are much faster for the GC to find and remove than groups of interconnected objects that are inaccessible to the program.
A good way to imagine this is a cork-board with a bunch of pins, and strings linking one pin to another. Each pin is an object. Each string connecting one pin to another is a link. The Garbage Collector comes along when your board is too full of pins to put any new ones in.
As you do things on your cork-board, you want to cut all the strings connected to a pin you're done with, because that's the easiest and fastest way for the GC to know it needs to be pulled out.
Another way to manage memory (and it's more memory-efficient than good garbage collection practices) is to recycle objects when you're done with them. That is, change the values of an object you're done with to match the new object of the same type you want to create.
You could have an array of objects you re-use often, and whenever you would want to make a new one, it first sees if there's anything in your recycle array. If there is, it assigns the new values to the existing object and assigns that object to the needed reference. If there is nothing in the recycle array, then it creates a new object. Whenever you're done with an object, you add it to the recycle array and then cut all other references to it.
If you do this, you'll want a function in each recycled object's class that resets its variables, with the same inputs as the constructor. In fact, it will usually mirror your constructor.
Tuesday, November 1, 2011
Programming Challenges: API Documentation
I'm working on a flash-based game using the Flixel library, and a regular part of my process is running into things that aren't working or I don't fully understand. I am going to try to post a problem I ran into and the solution I found for it as I work on this game. I'm working in a Windows program called FlashDevelop (version 3.3).
Basically, I had an older version of the Flixel library that I had been using until recently. When I started this project, I downloaded the latest version of Flixel. As I worked on my program, I kept getting suggestions for variables and functions that didn't exist any more, or had been renamed. Every time this happened I had to dig through the library files for half an hour just to find the right variable or function for the job.
Today I tried to use the FlxSprite.createGraphic() function, which had been renamed in the latest version. When my game wouldn't compile, I went through several files in the Flixel library trying to find which class had the renamed function in it. After I found it, when I tried typing in createGraphic(), it didn't show up in the suggestion list. Instead, makeGraphic() - the new, correct name for the function - was now showing up in the suggestion list.
What?
Turns out FlashDevelop caches a library's contents when you first use it, but doesn't update that cache unless you open the file(s) that have changed.
Today's challenge: Updating Flixel's API Documentation
Somehow FlashDevelop had the wrong documentation for the version of the Flixel library I am using.Basically, I had an older version of the Flixel library that I had been using until recently. When I started this project, I downloaded the latest version of Flixel. As I worked on my program, I kept getting suggestions for variables and functions that didn't exist any more, or had been renamed. Every time this happened I had to dig through the library files for half an hour just to find the right variable or function for the job.
Today I tried to use the FlxSprite.createGraphic() function, which had been renamed in the latest version. When my game wouldn't compile, I went through several files in the Flixel library trying to find which class had the renamed function in it. After I found it, when I tried typing in createGraphic(), it didn't show up in the suggestion list. Instead, makeGraphic() - the new, correct name for the function - was now showing up in the suggestion list.
What?
Turns out FlashDevelop caches a library's contents when you first use it, but doesn't update that cache unless you open the file(s) that have changed.
Solution: Open the library files.
Subscribe to:
Posts (Atom)