Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - IQAndreas

Pages: [1] 2
Through the hard work and dedication of Fernando Bevilacqua, Thomas Weston, myself, and a few other helpful chaps along the way, we are now happy to present the community version of Flixel v2.56.
This version fixes many of Flixel's older bugs, while staying reverse compatible with projects that use Flixel v2.55 (the current version in AdamAtomic/flixel). Just pop the v2.56 SWC into your existing projects, and give it a try.

To view all the changes, check out the changelog:

But we are not stopping here, there is more that can be added Flixel! If anyone wants to help contribute to further; suggest a feature, tackle an existing issue, or submit a bug report on GitHub:

chat / Re: loadRotatedGraphic Problem
« on: Sat, Aug 24, 2013 »
Could you provide the code you are using that is causing this problem?

releases / We need your help ironing out Flixel bugs!
« on: Tue, Apr 30, 2013 »
We are working on an unofficial fork of Flixel in which we are fixing all of Flixel's old bugs. (Once all the old bugs are fixed, we will be adding new features.)

We need help with:
 * Fixing old bugs (all listed in GitHub)
 * Verifying the code and checking for errors in pull requests (all listed on GitHub as well)

If you want to help out, please read the contributing instructions, and then send us a pull request. If you are unfamiliar with or new to GIT, you can also post bug fixes in this thread and one of us can create a pull request for you.

More details about the FlixelCommunity fork
Flixel Community was born as a healthy fork of Flixel. It is not supposed to replace Flixel or to compete with it, but to co-exist. Adam encouraged us to grow a community version and maintain it to our heart's content, even offering it as an alternative to Flixel.

help / Re: Overhead to loadGraphic()?
« on: Tue, Apr 30, 2013 »
The first time you call "loadGraphic()" there is some overhead as Flixel creates and instance of the BitmapData and stores it, but after that initial call, any subsequent calls to "loadGraphic" accessing the same class are relatively quick, and won't noticeably affect how much memory is used at all.

I thought there was a fancy way to do it in Flixel.

It involved creating a "dummy object" which you use with "sound.proximity()", making sure that object is entirely to one side or the other. Sadly, at the moment you move the "dummy" far enough away so it's only heard in one speaker, FlxSound also uses "distance fading" (quieter the further away from the target you are), and by then the sound is too far away to be heard at all.

There is no way to say "only pan the sound from left to right, don't reduce the volume if it is far away", but if think think that feature would be good to have, I can try to implement it.

But I'm glad you were able to get a workaround. :)

I don't really see the difference between FlxSound and Sound. They both work.
FlxSound is easier to use than Flash's Sound class. ;)

Maybe someone else can try to make a Flixel version that uses gfx from a swc instead of EMBED?
A SWC is nothing but a collection of classes, no different really than a SWF full of classes. Basically, a SWC serves as an extension to a SWF. You can use EMBED add items to a SWC which will open in Flixel just fine.

Do you mean like creating assets in Flash professional, exporting them to a SWC, and then using them in Flash? Provide more details on what you are looking for, and perhaps I can help add the features.

releases / Re: FlxSound Edit - Seamless Embedded Audio!
« on: Thu, Jan 10, 2013 »
I might be able to take a look at it. (FlxSound has become a bit of a love child of mine as of lately)

Which version of Flixel was the modified version of the code originally written for? (shame on you, Geti, for not using version control! ;)

... actually, FlxSound is more of an adopted child, since Adam was the original father.

help / Re: FlxSubState displays but doesn't update
« on: Fri, Aug 31, 2012 »
I am so very sorry for not answering your questions. I don't often check the Flixel forums and didn't even know this thread existed!

Do any of you still need help with FlxSubState? You guys are very welcome to ask me for help on Skype (username "IQAndreas") or you can send an email by using this contact form:

releases / Re: Funky code in FlxSprite::loadGraphic()
« on: Fri, Jan 20, 2012 »
umm, I think you should a little more on the subject but you are on the right track ;)
I must be really slow this week... but are you sure?

First it draws the "initial frames", then it draws the same frames reflected across the x axis and moved so it's on the right.

Also, if a moderator could move this to the "help" section. This was all an embarrassing error in thinking on my part, not a problem with the released code. ;)

releases / Re: Funky code in FlxSprite::loadGraphic()
« on: Thu, Jan 19, 2012 »
Ah, like this?

Generates to (where "1r" is the flipped version of frame 1 etc)

Thanks guys, I really shouldn't be staring at code on days when I can't think. ;)

releases / Re: Funky code in FlxSprite::loadGraphic()
« on: Wed, Jan 18, 2012 »
Ah, got it! ;D

And just to double check, if the graphic is animated and flipped, is the new sprite sheet generated in such a fashion? (Imagine this is a sprite sheet)

Generates to (where "1r" is the flipped version of frame 1 etc)

(I don't currently have a sprite sheet or project to test this on)

releases / Funky code in FlxSprite::loadGraphic()
« on: Wed, Jan 18, 2012 »
My brain is a tad slow this morning. Could someone help me decode what is going on in "FlxSprite::loadGraphic"?

It's doing something funny in the highlighted areas where it's using "width" and "height" interchangeably:
Code: [Select]
_flipped = _pixels.width>>1;
_flipped = 0;
if(Width == 0)
Width = _pixels.height;    // <------------------
else if(_flipped > 0)
Width = _pixels.width*0.5;
Width = _pixels.width;
width = frameWidth = Width;
if(Height == 0)
Height = width;    // <------------------
Height = _pixels.height;
height = frameHeight = Height;
Plus, what happens if both "Reverse" and "Animated" are set to true?

Are you planning on issuing some pull requests to the main repo or are you going to try and just keep updating your branch(es) along side the master branch as it gets updated?
I have been sending pull requests for the bug fixes, but not any of my other branches. (I figure I bug him enough with my pull requests for bug fixes anyway, :P and none of my changes actually are needed, but are instead nice little additions or handy changes.)

But if AdamAtomic makes any further updates, I will of course pull those changes in to my branches as soon as possible.

I made a list of my branches since the "about" field on GitHub isn't big enough:,5693.0.html
Plus a fancy little chart of the branches courtesy of GitHub:

Are your additions to Github plugins or are they a branch of the main repository?
There was no easy way to add this capability without modifying core classes, so I'm afraid I had to create a new branch.

The branch is updated to the latest release version of Flixel (2.55 is it?).
I have been meaning to add all the latest bug fixes (the unofficial bug fixes), but have not yet.

Ok, got it working. Nice addOn! Thx!
Awesome. :) If you get it working in a game where you will be releasing the source, let me know and I can link to it as an example of how to use the library (in case the EZPlatformer game I modified isn't enough)

If you have any feature requests or bugs let me know either here or on GitHub.

This is a very interesting topic, was any progress made with this in regards to flixel power tools? I was thinking about working on something like this myself and would love to work off anything that is currently existing instead if possible.
If you want, you can help me trying to get MinimalComps to work natively in Flixel. ;)

I'm still in the planing stages trying to figure out what the minimum class I need to extend is, and how to structure everything properly. if you feel like it, I would love a second set of eyes.

I'm probably in over my head, but I figured I'd take it one component at a time and see where I get with it all.

Just a few minor notes on the matter (and I am by no means a professional). None of these are actual "requirements", but personal practices I keep to keep code easier to manage.

Folder organization
This is typically how I organize my projects (and how most "Eclipse-based" workspaces are set up by default):
src - The source code for that specific game.
lib - All external libraries that are not specific to your game (often in SWC format for ease of use and faster compile times)
bin - Where the SWF gets compiled to. Sometimes there is a "bin-release" and "bin-debug" just to keep the debug version separate.
assets - Some people place this folder inside of the "src" folder, I place it in the top level folder, Flixel places it in the "org/flixel/data" folder. I wish there was a proper standard, but this one seems to vary quite a bit.

I'd like to emphasize something about the first two folders, "src" and "lib". The src folder should ONLY be used for code used for that specific game. For instance, I'm assuming you use Flixel for several of your projects, so keep that in a separate "lib" folder. That way, if a new version of Flixel is released, you can remove the old version, put the new version in without needing to meddle with your "src" folder. It will also make it clear to other developers which classes are your own, and which are from outside sources.

I would recommend learning how to use SWCs. That way, you don't need to mess around with folders of files each time, you instead have one bundled up, easy to move or update file. (but SWCs for me are just a personal preference)

Keep folder names all lowercase - (such as "src" instead of "Src") Some Operating Systems are case sensitive on folders, others are not. You can avoid any trouble by playing it safe and always using lowercase (but .as files still need to have the same case as their class names).

Don't use the top level namespace - Just don't do it. You may be forgiven if you have one single "Main" or "MainTimeline" class, but otherwise, don't. ;)

And a final note, worry more about your actual code convention (making sure to leave comments, logically group functions and variables, avoid really big classes) as that's what you will be staring at 98% of the time.

That's all I can think of at the moment that deal specifically with folder structure. :)

EDIT: I am so sorry, I reread your posts (I had just skim read it the first time around). I did not mean to be condescending in any way, I just assumed you were new to programming looking for beginner advice. :-\

So what would be different cases to use each of them? In other words,  why we have both of them to achieve conversion?
If the object you are type casting really is of that class, there is no difference.

But if it does not convert, Auriplane is entirely correct on the results. I quote Krilnon from the Kirupa forums:
The advantage would be that one does what you might want it to do in some situations and the other does what you might want it to do in others. For example, sometimes it's okay that a null value passes unnoticed through a part of your application. Sometimes it's not okay, so you might want an error to be thrown with a syntax that is about as concise as the syntax with the other behavior.

So sometimes you want to throw an error, sometimes you just want to know that it didn't work to convert it.
Code: [Select]
function doSomething(target:DisplayObject)
    // Target NEEDS to be a Sprite. Throw an error if it's not.
    var container:Sprite = Sprite(target);

function doSomethingElse(target:DisplayObject)
    // Target "can" be a Sprite. If not, that's okay too.
    var container:Sprite = target as Sprite;
    if (container == null)
        { container = defaultContainer; }

releases / IQAndreas Flixel branches on GitHub
« on: Sun, Dec 25, 2011 »
Since the "description area" on GitHub is a tad crowded, here is the full description of which branches I have in my fork. (but if you guys would prefer I move this list to a separate site or something, let me know)

Master - master
It should match up with AdamAtomic's Flixel master. I have not made any changes to the master branch yet.

Organizing Flixel better - dev_organizing_flixel
I felt like FlxU and FlxG were a bit too cluttered. The full list of changes can be found here:,5675

FlxSubState System - dev_FlxSubState
Additional classes, perfect for dialogs and pause menus. Details can be found here:,5663.0.html

Additional functions on Input - dev_keyboardAdditions
List of all three additional functions (mainly for detecting if any key was just pressed or released)

Efficient Input - dev_efficient_input
Radically reduces the amount of code run each and every frame inside of "update()". In addition, the new way of handling keyboard events allows you to know when a key was last pressed or released. The code has not yet been benchmarked or even tested if it works properly (but it should work in theory!) :P

To make things easier (albeit, more cluttered), I keep bug fixes in their own individual branches.

The "complete" branch with all current fixes merged into one branch (including the two fixes found in AdamAtomic's dev branch) is named "dev_fix_all":

Here are the list of all "fix" branches and their corresponding issue fixes:

releases / Organizing Flixel a tad better
« on: Fri, Dec 23, 2011 »
I find that "FlxU" and "FlxG" are far to cluttered, so in a new branch, I rearranged things a little better (adding new classes where needed).

FlxM (FlixelMath) - Contains all the math functions from FlxU
FlxColor (I didn't abbreviate it) - Contains the color functions from FlxU, and the static color constants from FlxG. Also added a static "getGrey(brightness, alpha)" function, since it is oh so handy!
FlxG.effects - Now in plugin format! Contains those "FlxG.flash", "FlxG.fade" etc functions. New effects can be added by modifying the org.flixel.plugins.FlxEffects class.
FlxG.vcr - Contains static functions for loading/pausing/playing replays.

So far, I have resisted the urge to move the "format" static functions in FlxU to "FlxS" (FlixelString), but if any "region support" for such formatting appears in Flixel, I definitely think that's where the functions should go.

The full list of changes can be viewed here:

I just organized the code this way because to me it's now more logically arranged and less cluttered. (but of course, it isn't reverse compatible, so any code will need to be updated to use this new version.) I made sure that all changed functions where "infrequently used", so moving them to a separate class wouldn't take a performance hit.

What are your thoughts? Bad idea? Good idea?
Are there any other parts that could be organized better?

Pages: [1] 2