As I described in my previous post, I’ve started working from the latest HaxeFlixel dev code to take advantage of the latest and greatest tools. This includes a newly revamped command-line interface to use flixel-tools to create a new project from a template. Unfortunately, I had the hardest time ever trying to get my quick demo program to work that was running just fine on the 2.0.0-alpha3 (or whatever it was).
The issue turned out to be that the new template’s project .xml file does something… helpful, I guess? with your assets directories. You see, the project will get created with an assets directory containing a variety of subdirectories for storing images, music, etc. If you wanted to load a graphic to a FlxSprite, you might think you’d use:
loadGraphic("assets/images/filename.png", true, true, 32, 32);
But you’d be wrong! That’s the relative path to the file, but your .xml file renames each individual subdirectory to remove the assets bit:
<assets path="assets/images" rename ="images" />
Thus, instead I should have been loading like so:
loadGraphic("images/filename.png", true, true, 32, 32);
I don’t know why this decision was made to obscure the file path as a default assumption for every project, but it cost me a couple hours’ frustration to save a few characters every time I load an asset. I’ll most likely be removing these aliases in my personal projects, and since I’ve sourced my Haxe flixel / flixel-tools libraries from personal repos, I can always patch my template tool to work that way from the command-line.
On a side note, if anyone knows a way to get real-time feedback on why a Haxe program crashes out, I’d love to know about it. If I could’ve seen a simple “file not found” error message on exit, I could’ve focused my efforts on that loadGraphic() command exclusively. That probably could’ve shaved half my debugging time.