Posts made by IBwWG

@LangLearn-Korean ONESHOT is the default (so you can omit it, and the whole options param). I think they auto-recycle. I've never tried pooling them.

@IBwWG Just a note on stamping, this of course doesn't apply to animated sprites. In that case it's easier to get them before you initialize them, resizing the whole graphic before it gets parsed as frames:

		if (Scale == 1.0) {
			loadGraphic(GraphicAsset, true, OriginalWidth, OriginalHeight);
		} else {
			var originalBitmap:BitmapData = FlxAssets.getBitmapData(GraphicAsset);
			var matrix = new Matrix();
			matrix.scale(Scale, Scale);
			var newWidth = Std.int(OriginalWidth * Scale);
			var newHeight = Std.int(OriginalHeight * Scale);
			var scaledBitmap = new BitmapData(newWidth, newHeight, true, 0); // fill with transparent
			scaledBitmap.draw(originalBitmap, matrix);
			loadGraphic(scaledBitmap, true, newWidth, newHeight);
		}

An update, we went gold this week! Give the completed game a go. We sincerely hope you enjoy it. :)

@Kyatt Yikes, I read that twice as "it" instead of "I". Thanks for clarifying :)

@zkylon I am at least. I have it set to fullscreen, but where it doesn't look so great is if your desktop res is different, or you un-fullscreen it with alt+enter (in Windows.)

I was wondering the same thing. My game looks fairly terrible in anything under the HD I designed it for. I hadn't known about the antialiasing option but I should give that a try....except you say it won't be of much help @Kyatt ? I don't understand...

I can confirm that it's definitely not safe to call dumpCache() on cpp, if you intend to use pixel perfect collision checks! It results in your collisions never colliding because they get checked against an auto-generated transparent image.

I can also confirm it is safe to call dumpCache() on flash, even with collision checks, because, IIRC, it doesn't do anything anyway on that platform.

@Gama11 Personally I use the F-keys for all sorts of my own debugging stuff. But as you say it can be overridden in code, so no biggie either way.

@IBwWG Maybe the whole thing is moot though--can anyone confirm whether the line above is safe and sensible to do also on a non-hardware-accelerated system (cpp in either case)? Like if you run that code in that case, is it merely useless, or is it actually destructive? If it's merely useless then that's fine, I'll just put it in. If it's destructive, I need to find a way to detect hardware acceleration...

I'm using flixel 4.1.1, openfl 3.6.1, lime 2.9.1 and found these lines of the texture atlas demo interesting:

		// Remove atlas bitmaps from memory (useful for targets with hardware acceleration: cpp only atm).
		FlxG.bitmap.dumpCache();

Sounds great! If everything's loaded up into graphics memory, dump it from regular memory.

But what if I've compiled for systems without hardware acceleration, like my 32-bit linux box with openfl build linux --window-hardware=false? (If I didn't compile this way, the game simply wouldn't run.)

I tried at runtime with if (Lib.application.config.windows[0].hardware) but it won't compile because Class<openfl._legacy.Lib> has no field application. How can I detect whether I've passed that window-hardware flag instead then?

I tried searching for "window-hardware" in both the lime and openfl repos, but I see nothing there.

@rknonchalance I think it was something to do with embedded fonts. I had font paths used in Inkscape that came out all garbled. But I think even simpler parts of my SVGs were not always rendering correctly.

@Gama11 Whoa! Sorry, big misinformation there. I was trying to use openfl's svg library, and because of whatever problems that I cannot remember right now, everywhere I was trying to use SVG I have replaced with prerendered PNGs. I'm glad you asked, I had made some poor assumptions there, not seeing the directory I had the PNGs in, only seeing the SVGs. The code and my project.xml revealed otherwise.

My unreleased game Debatcles uses SVGs with HaxeFlixel for precisely that, stick figures. Well, and everything else in the game. :) As of January or February I was getting it to work OK on Windows, Android, and Flash. I couldn't get SVGs to work early this year.

@DleanJeans Well, whether the parent state pauses in the background is a bit up to you. For starters, you may need to set _parentState.persistentUpdate = false, but that won't cover things that update independently of your state, like any tweens, timers, sounds playing, and so on. So you need some kind of function to toggle those when you open the substate and toggle them back when you close it.

@rraallvv pretty much HaxeFlixel just sits atop OpenFL.

Also: http://haxeflixel.com/documentation/game-development-tools/

@galoyo Maybe super-slow autocomplete as was mentioned earlier? How long do you give it?

@sionco Are you on flixel dev, or which version now?

@galoyo I read the first link totally differently. The OP there was assuming there was a link, yes, but Gama11 explained there too that there isn't. If you open up AssetPaths.hx in your project's source folder, you should be able to see which directory it's looking in, because it calls the builder macro with it. Mine looks like this (the default):

package;

@:build(flixel.system.FlxAssets.buildFileReferences("assets", true))
class AssetPaths {}

And it's that "assets" there that determines what you can find in AssetPaths.

As for the files themselves actually being present when you build, though...@Gama11 wouldn't they need to be included properly via project.xml? I.e. if your project.xml doesn't refer to "assets" but AssetPaths does, then I would expect that AssetPaths autocompletion would find your assets, but at run-time, the correct-looking paths it had put in your code would refer to things that, on build, had not been copied into bin/export/$platform/assets. Is that correct?

I found this curious line in FlxMouseEventManager:

if (!reg.object.alive || !reg.object.exists || !reg.object.visible || !reg.mouseEnabled)

...which prompted me to search the rest of the flixel codebase for how alive is actually used, since I've never used it so far. It seems it's just there for convenience for game universes wherein things have health, take damage, die, etc., and isn't more basic than that. There are special helper functions here and there to leverage its use, but FlxMouseEventManager seems to be out of place here in using it.

I'm going to take a wild guess that .active was intended here, which to me makes way more sense. The side effect of the current implementation is that currently my .active = false objects, stuck behind a substate, are still functional with regards to mouseovers and mouse clicks, even with persistentUpdate = false on the parent. I was thinking to myself, what more do I need to do to make these things inactive while the substate is open? Well...I guess I have to kill() them too, the way it currently is...then revive() them when the substate closes.

Am I off base here? Does anyone rely on FlxMouseEventManager using alive instead of active? If so, how come?

@xhunterko See crashdumper for how to get stack traces...