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.


Topics - IQAndreas

Pages: [1]
1
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: https://github.com/FlixelCommunity/flixel/blob/v2.56/CHANGELOG.md

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:

2
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.

3
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]
if(Reverse)
_flipped = _pixels.width>>1;
else
_flipped = 0;
if(Width == 0)
{
if(Animated)
Width = _pixels.height;    // <------------------
else if(_flipped > 0)
Width = _pixels.width*0.5;
else
Width = _pixels.width;
}
width = frameWidth = Width;
if(Height == 0)
{
if(Animated)
Height = width;    // <------------------
else
Height = _pixels.height;
}
height = frameHeight = Height;
Plus, what happens if both "Reverse" and "Animated" are set to true?

4
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:
http://forums.flixel.org/index.php/topic,5675

FlxSubState System - dev_FlxSubState
Additional classes, perfect for dialogs and pause menus. Details can be found here:
http://forums.flixel.org/index.php/topic,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)
https://github.com/AdamAtomic/flixel/pull/215

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

Fixes
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":
https://github.com/IQAndreas-testprojects/IQAndreas-flixel/tree/dev_fix_all

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

5
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).
https://github.com/IQAndreas/flixel/tree/dev_organizing_flixel

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:
https://github.com/IQAndreas/flixel/commits/dev_organizing_flixel


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?

6
These changes to Flixel allow for "SubStates", where another state is displayed on top of the current one, and has the capability of having a different background color, as well as preventing the "parent state" from updating or receiving keyboard and mouse input.

I still haven't merged the changes to "my" master flixel branch, but instead still have everything stored in a separate branch:
https://github.com/IQAndreas/flixel/tree/dev_FlxSubState

The example game (a branch of AdamAtomic's EZPlatformer) can be found here (with the sample SWF in the "bin" folder):
https://github.com/IQAndreas/EZPlatformer


DETAILS
You can set the sub state from any FlxState as follows:
Code: [Select]
this.setSubState(new PauseMenu(), <optional callback when the menu closes>);
The current "FlxState" (likely named "GameState") is still running in the background and still in memory. The new FlxSubState (named "PauseMenu" in the example) does not replace "FlxG.currentState", but is in a sense a "child" of the current GameState instance. (but it won't show up in the list of the GameState members and interfere with other children)

You can extend "FlxSubState" which works just like a "FlxState" but adds a "isBlocking" option which if set to true prevents the parent FlxState from running it's "update" method. (Note that the parent state's "draw" method is always run, even if the subState is blocking the update command)

So for instance, the "Pause Menu" in MineCraft would have "isBlocking" set to true, so the "game state" stops.
The "Opening Chest" menu in MineCraft would not be blocking, since the world keeps playing in the background.

 - FlxSubState can have a different background color (even transparent or partially transparent, so the "parent state" still shows up behind it.)
 - The SubState will ALWAYS be rendered on top of the parent state.
 - When opening a FlxSubState, you can add a callback for when the state closes.
 - When the FlxSubState closes, you can pass a string to the parent state with information (for instance, why the state closed).

Nitty gritty:
 - The SubState does not have a public reference to it's parent. This is to adhere to proper encapsulation so the SubState doesn't need to know anything about it's parent state. You can however pass parameters to the constructor of the SubState if needed.
 - You can use the FlxSubState as a regular FlxState without any problems. Just make sure you override the "close()" function to handle the behavior properly. You can use "isSubState" to see if the current instance is the main state, or a sub state.
 - There are two additional parameters added to the standard "FlxState" class, "bgColor" and "useMouse". Instead of using the "FlxG" commands for setting those two properties, this will ensure that FlxSubStates also have those properly set.
 - If a parent state has "useMouse" set to false, but the sub state has it to true (such as if there are buttons on the screen), when the sub state closes, it will go back to the parent's mouse settings, hiding the mouse (and vice versa)

7
help / Why is a Class (not instance) passed to FlxGame?
« on: Wed, Dec 21, 2011 »
Is there a reason that in the initial constructor of "FlxGame" you pass a "Class", but in "FlxG.switchState()" you pass an instance? Is this an oversight, or is there a good reason for that?

Personally, I would prefer if an instance is passed as you can pass starting values along to the constructor of the FlxState.

And if someone really stubbornly wants to pass a class, perhaps that parameter could be untyped allowing either a class or instance?


I wasn't sure if this was a question for the GitHub issue tracker, or if that's reserved for bugs. In fact, is there any place where the contributors have written out the logic behind various decisions of how they structured Flixel (more than what can be found scattered about in the code comments)?

8
help / Detect if any key is "just pressed"
« on: Wed, Dec 21, 2011 »
I don't want to detect if any key is down (done with [ic]FlxG.key.any()[/ic] ) but instead if any key was just pressed.

Does this already exist, or should I add such a function?

9
help / "Graphics.clear" for FlxSprites
« on: Tue, Dec 20, 2011 »
What is the FlxSprite equivalent for Graphics.clear? For instance if you have drawn a square using "makeGraphics", how would I reset that line?

I read in another post someone using "flxSprite.fill(0x00000000)", but will that even reset the size of the sprite to the way it was before?


What about for loaded graphics, how are they best cleared without resetting the position, visibility, and existence of a FlxSprite?

10
help / "Sub-FlxState"
« on: Sun, Dec 18, 2011 »
Noo! I was on autopilot, and while thinking I hit the "Reply to Topic", it turns out that button said "Remove Topic" ???

Anyway, this is just reposting that old topic. There were two replies already as well, so I'll just copy and paste them in (luckily the topic was cached, so the back button brought it up again)



Take for instance MineCraft, you are still in the "Play state", but when you open a chest, a GUI appears on top of the current state, and all user input (keyboard, mouse, the works) go to this new state.

However, the background play state still keeps all variables and is essentially "paused" in the background until you exit the current "sub-state".


Is there already a built in way of creating these "sub states" in Flixel, or should I "take matters into my own hands"?

Quote from: test84
I think you can have a boolean for being in a menu and in your update, check and if you are in menu, skip everything and draw and handle menu. But I'm sure there are better ways to do it.

Quote from: auriplane
I didn't use Flixel's state system at all, and implemented maybe 3 global state machines for my game.  Of course, my code is hardly a shining example ;-)  But implementing state machines is easy, so I recommend not getting too hung up on specifics, and just pick a solution and keep your forward momentum.  If it's ever a problem down the road, it shouldn't be a big deal to refactor.

11
releases / What is the current state of Flixel?
« on: Sun, Dec 18, 2011 »
Checking GitHub, the last release was in August, and the last modifications in the "dev" build were in October. Two months really isn't that long, but I'm still curious why there is a standstill while there are a handful of open issues as well as changes in the other branch.

I don't mean to pester the maintainers at all (it's really no hurry, the current build of Flixel works like gold), I'm just curious of how things are coming along. :)

Second, which changes are in the dev build that are planned to be released in the very near future? (I could look at the actual code, but I'm looking for the ideas and thoughts behind the changes) EDIT: Turns out the dev builds only contained two small bug fixes, so no major changes there. What is in the master build is essentially the "latest".

12
help / Detecting clicks on a FlxSprite or FlxGroup
« on: Thu, Dec 15, 2011 »
Is there any "Flixely" way to handle clicks and hovers on Flixel display objects, or do I just add a "plain old" Flash event listener?

Since I'm assuming all FlxSprites are bittled onto one single screen, I'm assuming there is some sort of process.

Pages: [1]