Flixel Forums

development => releases => Topic started by: Adam Atomic on Fri, Apr 8, 2011

Title: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 8, 2011
THE NEW HOTNESS

Oh man, exciting times you guys!!  First, there is a whole new branch on github dedicated to the old beta 2.43, since I know it's pretty popular and I don't want to ruin everybody's christmas:

https://github.com/AdamAtomic/flixel/tree/v2.43b

This is just a copy of the old beta branch, that I will no longer maintain, but is there in easy reach just in case you need it.  Once that was archived, I merged the v2.50 dev branch down into beta:

https://github.com/AdamAtomic/flixel/tree/beta

And here is the github commit manifest, sadly soiled by documentation noise:

https://github.com/AdamAtomic/flixel/commit/35948b2049d7bed6bb40726d411b5d11ad1d781e

I'm going to quickly attempt to detail the major changes real quick:

1 - Collision system has changed a lot.  While it's still the same basic idea, the "collision hulls" are gone in favor of just storing the last position of each object.  Also, all the hitLeft(), hitRight() callbacks are gone, and replaced by a simpler system.  During update(), you can just check isTouching(FLOOR) or wasTouching(LEFT) or whatever, and keep all your logic in one function.  Also it is easy to run your own collision handlers and stuff.

2 - Don't really need to call super.update in most classes anymore.  You DO need to call it in your game states though!

3 - The debugger overlay is beastly powerful now!  You can also extend the drawDebug() function in your sprite classes to make the visual debugger more powerful.

4 - Added rudimentary path following and path-finding with debug visuals.

5 - Added new camera system, so you can do split-screen, or picture-in-picture with just a few lines of code.  However, EVERYTHING is cameras now.  Most of the time this isn't a big deal, because there is a default camera that is easy to work with.

6 - I removed FlxKong, FlxPanel, the game-level offsets and frames (though that can be emulated with cameras now), and will probably be removing FlxMonitor.  Thrust was removed from FlxObject, and some things were moved around.

7 - States extend groups now, and groups just extend flxbasic, not flxobject.  Groups also have a nice new "recycle" function, that can be used to intelligently re-use game objects like bullets or enemies.

8 - Camera follow behavior is less swoopy and spazzy, and easier to extend/override.

That's the big stuff I think.  I know that is only a cursory overview, but part of what I'm doing next week while we beta test this stuff is working on finishing the documentation and helping build a new more informative website, with a tour and stuff.


FROM BETA TO MASTER

However, in the meantime, it would be a really big deal to me if whoever is able can try porting one of their existing prototypes over to the new code base, even though it will change a little bit in the coming week or two, and let me know what bugs they find, or where they get stuck, or what seems crappier.  In general, my goal with this update was to make things more simple, more clear, and give people more control.  This did sometimes require making some big changes, but in my test projects locally I've not had to change any of the core behavior, and the actual game code in my projects has dropped by 10-20%, which is cool.

So yeah, if you have time this week to try out the new code and let me know what you think and what bugs you find, that would be awesome.  There are a few different ways to report bugs:

1 - You can simply reply to this thread :)

2 - You can submit them to https://github.com/AdamAtomic/flixel/issues

3 - You can message me on https://twitter.com/#!/flixation

I will be watching and interacting on all these channels next week to try and get v2.50 ready for the master branch.  Thanks ahead of time for your time and effort in helping with this, and I'm looking forward to getting this new code base out to the world :)


GOING FORWARD


There are a few rough spots in the beta still I think that probably won't get magically better next week, but I'm looking forward to improving over the course of the year:

1 - Collisions are still not an amazing system.  While it is much more stable than before, it still has limitations and weirdness sometimes.  I've tried to segregate the collision behavior as much as possible, to both make it easier for ME to understand and to make it easier for YOU to help me improve.  Whether it is optimizations for the quad tree or better approaches to collision resolution, I hope we can work together to improve that system over the next few months.

2 - I just put in path-finding yesterday afternoon, and I'm quite certain it is a mess.  Now that there is a kind of quasi-official FlxPath object, I'm hoping that it will be trivial to improve the guts of FlxTilemap.findPath() without blowing people's minds, and I think the community can help with that a lot.

3 - Path-following is also newly added, and probably pretty rough around the edges as well.

Finally, I have a few things that I'm definitely going to be looking at during the beta testing next week:
> seeing if i can simplify sound mgmt with the global sound mixer SKIPPED
> trying to clarify world/physics overlap versus screen/graphic overlap DONE
> timers DONE
> hover bool/callbacks for flxbutton DONE
> comparing the speed of my "fast" angle calcs in FlxU versus just using Math SKIPPED
> maybe improving the "lost focus" arrow screen appearance OK FOR NOW
> double click support DELAYED
> auxiliary global update/draw callbacks lists DONE (PLUGINS)
> exposing _framePixels DONE
> running through the github queue DONE
> fixing up flx.py DELAYED

I'll be making a new v3.0 thread to talk about wacky future features.  In the meantime, this is the short-term plan of action, and I'm really looking forward to your feedback and help in the next week or two to roll over to the new hotness!  Thanks :)
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 8, 2011
probably I will make FlxTilemap.drawIndex and FlxTilemap.collideIndex obsolete and leave those up to the new FlxTilemap._tileObjects and setTileProperties() system, since that's a lot more powerful
Title: Re: v2.50 beta thread!
Post by: axcho on Fri, Apr 8, 2011
Thanks very much, I'm looking forward to trying it out with one of my new prototypes and finding some bugs! ;)

Any suggestions for those of us cleaning up the Flixel iOS framework? Would you recommend keeping it to v2.43b for the near future, or would it be a good idea to switch over to v2.50 as soon as it goes to master?

In the meantime, we'll keep going with v2.43b, but it would be nice to switch to v2.50 for the iOS port too once it stabilizes. Are you planning on doing your own iOS port of v2.50?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 8, 2011
i would NOT recommend developing in 2.50 if you are using the current release of flixel iOS.  as of right now we do not expect to release an ObjC version of 2.50+
Title: Re: v2.50 beta thread!
Post by: axcho on Fri, Apr 8, 2011
Ah, good to know, thanks.

I guess this could provide an incentive to continue developing in v2.43b for those of us who'd like to port our games to iPhone eventually...
Title: Re: v2.50 beta thread!
Post by: krix on Fri, Apr 8, 2011
That is so freaking amazing!
I'm definitely going to work on a new game just to use this cool framework.
Thank you Adam for all your effort, you brought me the fun in game development!

Keep up the great work.
Cheers
Title: Re: v2.50 beta thread!
Post by: Cadwallader on Fri, Apr 8, 2011
So FlxKong won't be back any time soon? Just curious.
Awesome release! I will prob gonna test it in a project of mine...
Keep it up.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 8, 2011
Felt weird continuing to include it, but it can still be downloaded from the v2.43b branch
Title: Re: v2.50 beta thread!
Post by: xyroclast on Sat, Apr 9, 2011
How come FlxKong is gone?
I'm planning to release on Kongregate, so info about the situation would be much appreciated :)
Title: Re: v2.50 beta thread!
Post by: feiss on Sat, Apr 9, 2011
Hi ya, good work Adam :)

I guess I have to update my flex 3.5, it gives me an error compiling VCR.as (FileReference.save() and FileReference.data not available)

Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Sat, Apr 9, 2011
What about createGraphic? That was very useful for simple bullets.
Title: Re: v2.50 beta thread!
Post by: ntdb on Sat, Apr 9, 2011
What about createGraphic? That was very useful for simple bullets.

Try FlxSprite.makeGraphic(width, height, color, unique, key)
Title: Re: v2.50 beta thread!
Post by: roboprez on Sun, Apr 10, 2011
Was updating one of my little experiments to the new version and I noticed one thing. In FlxGame at line 128 there is
Code: [Select]
_requestedState null; This just keeps giving me a syntax error unless I change it to
Code: [Select]
_requestedState = null;
I also made a log of things I had to do to convert my code from the current master of Flixel to this version. Would people find that useful to see?


EDIT: I just added a bit to the bottom of the FlashGameDojo article on Dynamic Lighting (http://flashgamedojo.com/wiki/index.php?title=Dynamic_Lighting_(Flixel)) about how to get it working in the latest version.
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Sun, Apr 10, 2011
I also made a log of things I had to do to convert my code from the current master of Flixel to this version. Would people find that useful to see?

That would be awesome!
Title: Re: v2.50 beta thread!
Post by: Cadwallader on Sun, Apr 10, 2011
Felt weird continuing to include it, but it can still be downloaded from the v2.43b branch

I don't think it's working anymore and by asking that I actually meant if it will ever be fixed or something.
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Sun, Apr 10, 2011
Also, what about FlxPause? A big triangle is no replacement!
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 10, 2011
Hi ya, good work Adam :)

I guess I have to update my flex 3.5, it gives me an error compiling VCR.as (FileReference.save() and FileReference.data not available)

Yea the debugger requires Flex 4.0
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 10, 2011
Felt weird continuing to include it, but it can still be downloaded from the v2.43b branch

I don't think it's working anymore and by asking that I actually meant if it will ever be fixed or something.

mmmm i won't fix it any time soon, but maybe it can be part of the plugins thing i'm thinking about though?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 10, 2011
Was updating one of my little experiments to the new version and I noticed one thing. In FlxGame at line 128 there is
Code: [Select]
_requestedState null; This just keeps giving me a syntax error unless I change it to
Code: [Select]
_requestedState = null;
I also made a log of things I had to do to convert my code from the current master of Flixel to this version. Would people find that useful to see?


EDIT: I just added a bit to the bottom of the FlashGameDojo article on Dynamic Lighting (http://flashgamedojo.com/wiki/index.php?title=Dynamic_Lighting_(Flixel)) about how to get it working in the latest version.


A - actually it would even be useful for ME to see that change log!

B - I am checking for that bug there, probably a silly typo that Eclipse didn't catch for some reason

C - awesome, yay dynamic lighting and fgd!
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 10, 2011
Also, what about FlxPause? A big triangle is no replacement!

So pausing was a real mess in old flixel.  There were a lot of overlapped/confused things:

1 - focus gained/focus lost (also could be called alt-tab pause)

2 - the new debugger overlay pause and step ability

3 - pressing an in-game pause button

I wanted to separate and clarify these actions.  The big triangle thing will be updated/improved a little next week, if only for aesthetic purposes.  It also still intelligently auto-pauses the music for you then, etc.

Debugger pause and stepping is a debug behavior only, and will NOT pause music or sound playback.

In-game pausing should be handled on a project-by-project basis, and FlxG.paused is a built-in boolean that can help you figure out what behavior to use.  FlxCamera might be really useful for doing custom pause screens, as could FlxG.playSounds() and FlxG.pauseSounds().  This isn't necessarily the way it has to be forever, but so many games have different pause game behaviors - inventory screens, stuff with different music, mouse menus, etc, that the hardcore pause behavior I felt was too confusing and restrictive.

I am definitely open to feedback on this stuff, but I wanted to describe the ideas behind the change :)
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Sun, Apr 10, 2011
MMkay, that sounds resonable. Anyways, I had an awesome feature suggestion, that wouldn't be TOO hard to implement. A setTile As FlxSprite function in FlxTilemap. This would allow us complete control over individual tiles, and making dynamic lighting way easier to implement.
Title: Re: v2.50 beta thread!
Post by: foosety on Sun, Apr 10, 2011
EDIT***:

Actually after some reflection I think it would be better to just have a good tile animation system instead. You could do this with SetTile, but surely there has to be a better method?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 10, 2011
hmmm i will give it some thought!  would this sort of make a new sprite for each tile in the map then, or?  not really clear on how this would work...
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Sun, Apr 10, 2011
hmmm i will give it some thought!  would this sort of make a new sprite for each tile in the map then, or?  not really clear on how this would work...

You make a new FlxSprite(like how you would make a player), pass it to the function, with either the individual tile you want to be placed, or what tile index you want it to be placed at. For example:
Code: [Select]
var t:FlxTilemap = new FlxTilemap();
t.loadMap(Map, ImgTiles, 16, 16);
t.follow();
t.setTileAsFlxSpriteIndex(Lava, 3);
add(t);

Tile index syntax is setTileAsFlxSpriteIndex(FlxSprite:FlxSprite, TileIndex:uint)

Individual is setTileAsFlxSprite(FlxSprite:FlxSprite, X:uint, Y:uint)

Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 10, 2011
would it make more sense to have a function that retrieves the world coordinates of a given tile?  that could be pretty flexible, and even return an array with all the world coordinates of a given tile index?
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Sun, Apr 10, 2011
would it make more sense to have a function that retrieves the world coordinates of a given tile?  that could be pretty flexible, and even return an array with all the world coordinates of a given tile index?

That could also be useful, but after digging through the source code, flixel already uses flxobjects for individual tiles. if you could set FlxTile.as to extend FlxSprite, and allow us to set individual FlxTiles for each tile in the tilemap, it would work perfectly. Maybe even a seperate FlxTilemap for this, like FlxSpritemap?

EDIT: also, just to clarify, this so that the FlxSprite, and tilemap are treated as one object.
Title: Re: v2.50 beta thread!
Post by: ChainedLupine on Sun, Apr 10, 2011
would it make more sense to have a function that retrieves the world coordinates of a given tile?  that could be pretty flexible, and even return an array with all the world coordinates of a given tile index?

Some ideas I've had (and use):

A) A version of overlaps duplicated the existing FlxTilemap::overlap logic, but that passes back a FlxObject representing the overlapping tile instead of just a true/false flag.  I stuff the tileid into the FlxObject::data structure for further referencing, plus the tileX/Y.

B) A method that deals with all onscreen tiles.  (To be used for visual effects.)  You pass it a function and gets passed the tile rect and tileid for each time that is onscreen.

You could combine method A/B by making a generic set of tile queries that are more expansive than just FlxTilemap::getTile.  For example, one that takes a FlxRect (in world coords) and returns a list of tiles that overlap that boundary.

In fact, I'd love to see more generic queries of structural data in Flixel.  Like, for example, give me a list of all sprites or tiles that are within a line, or within a bounding shape (rect, sphere).  Functions like FlxTilemap::ray are nice, but I tend to want to do per-item comparisons instead of just a global pass/fail.  For example, what if I have tiles that I want a collision flag on but would like for them to be transparent for LOS checks, like a glass wall?
Title: Re: v2.50 beta thread!
Post by: roboprez on Mon, Apr 11, 2011
Okay here's my log for updating from master to 2.5

instead of overriding render() need to override draw()
bgColour moved from FlxState to FlxG
FlxG.follow() now FlxG.camera.follow()
adjustBounds() died
createGraphic() is now makeGraphic()
FlxG.collide() is now just collide() (In FlxState)
draw() is now stamp()
Have to turn FlxG.debug on to use sexy command window
FlxG.flashFramerate controls frame rate.

Also about the last thing. What's the difference between FlxG.flashFramerate and FlxG.framerate?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 11, 2011
cool - flashFramerate is the actual flash player framerate, while framerate is the actual game loop framerate.  for example you can have your game running at 60 fps even if flash player is only running at 30 fps.  it will look kind of choppy but you can guarantee the simulation is very tight/smooth in the background.
Title: Re: v2.50 beta thread!
Post by: Rybar on Mon, Apr 11, 2011
Just curious, why did you move overlap() and collide() into FlxState?  That and their scope being changed from public static to public has created some headaches for me in one project I'm converting, as I have some custom line collision stuff that calls overlap from inside a public static function.

I have a lot of trouble with function scope anyways...scope isn't confusing as a concept, but the compiler errors it causes are cryptic, i.e. 1180:Call to a possibly undefined method... etc.
Title: Re: v2.50 beta thread!
Post by: increpare on Mon, Apr 11, 2011
So I've been playing with this on-and-off.  Converted an old project, made a new one, and did some camera prototypes.  Everything's worked pretty admirably.

Take what follows with a pinch of salt:

Following notes I jotted to myself while thinking about things, not all about 2.5-specific things, though.

I didnít try out the debugger too much.  Was making a game with more involved data-structures, so it didnít really seem worthwhile.  Also haven't looked at the pathfinding stuff yet.

I wanted to show the system cursor at one point, so ended up commenting out all occurrences of flash.ui.mouse.hide() - is there another way to do it?  (not 2.5 specific I think ).

Iím very happy to be rid of the flxpause auto-menu.  Of all the places to put an instructions menu, the 'lost focus' screen is not it ;)

I did try out camera stuff.  Works fine.

Having to rename all my FlxSprite.UPs to reference FlxObject, no big deal.

Itís my feeling that assigning FlxCamera.target should be the same as calling FlxCamera.follow  (not beta-specific, admittedly - )

Still canít figure out how to do the path-finding stuff you were talking about in mode

kept on forgetting what createBitmap was called.

> hover bool/callbacks for flxbutton
You know that flxbutton behaves badly, yep? (standard behaviour: button clicks if mouse pressed and released on button, no matter where itís been in between, flxbutton behaviour: have to mouse down and up and not leave the button area) (not 2.5 specific admittedly).  

FlxPreloader.minDisplayTime should probably have a note that you should call it after super() (unlike className).   [ Though, I'm having a bad preloader day today, and it's generally confusing me. ]
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Mon, Apr 11, 2011
Flx.py is borked. Either that, or you accidentially moved back to
Code: [Select]
FlxG.switchState(new PlayState()); which is more annoying to type. FlxG.state = new playstate(); was better imo.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 11, 2011
oh hmm - i was only calling it from FlxState here, but it could probably be changed back to being a static function in FlxState and be just as usable that way... if a lot of people are using it from OUTSIDE FlxState though maybe it would make sense to move it back into FlxG
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Mon, Apr 11, 2011
Ok, another thing. Shouldn't the framerate be declared in a FlxGame's super function? Makes more sense for me, at least. Its mainly just because i cant get the normal way to work though. Btw, its where you do this:

Code: [Select]
super(320,240,MenuState,2);
Title: Re: v2.50 beta thread!
Post by: photonstorm on Mon, Apr 11, 2011
I guess I have to update my flex 3.5, it gives me an error compiling VCR.as (FileReference.save() and FileReference.data not available)

Hmm, check you are compiling for Flash Player 10 first. That function isn't available in FP9, but is there in FP10 (and AIR 1.5+). Pretty sure flex 3.5 supports it, providing player is set correctly.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 11, 2011
Ok, another thing. Shouldn't the framerate be declared in a FlxGame's super function? Makes more sense for me, at least. Its mainly just because i cant get the normal way to work though. Btw, its where you do this:

Code: [Select]
super(320,240,MenuState,2);

Yeah if folks want to see framerate parameters there that would be easy to add!
Title: Re: v2.50 beta thread!
Post by: superdeformed on Tue, Apr 12, 2011
off topic: congrats on the baby-making!
Title: Re: v2.50 beta thread!
Post by: photonstorm on Tue, Apr 12, 2011
I have to admit I don't really like having the frame rate fixed at 30 fps for me. So a constructor parameter would be good - or just read it from the stage.frameRate and set it to that?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Tue, Apr 12, 2011
you can also change either the game loop framerate or the flash player framerate from FlxG.framerate and FlxG.flashFramerate respectively at any time
Title: Re: v2.50 beta thread!
Post by: Kronoshifter on Tue, Apr 12, 2011
Would be great if an official FlxTimer could be added
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Tue, Apr 12, 2011
yea some kind of timer option is on my internal list for the beta, though it may end up being a plugin or something, we'll see :)
Title: Re: v2.50 beta thread!
Post by: roboprez on Wed, Apr 13, 2011
Hmm. in the latest version you just pushed; FlxTilemap's flip out when the map has a negative integer. Specifically the first line of updateTile().
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Wed, Apr 13, 2011
Ah - yea, i can fix that, one sec :)
Title: Re: v2.50 beta thread!
Post by: Rybar on Wed, Apr 13, 2011
Found something tonight:

https://github.com/AdamAtomic/flixel/blob/dev/org/flixel/FlxGroup.as#L167

If you don't set maxSize, functions that iterate through your flxgroup in typical fashion:

Code: [Select]
for(m:int = 0, m < group.members.length; m++)
will throw null object errors, due to FlxGroup.length being some power of 2 above the actual number of objects added to the array. In my case I had filled the group with 40 objects and the length was set to 64 due to the code above. Is there a performance gain from expanding the array for new members like this?
I just set maxSize and fixed my problem, but I can imagine situations where the length is dynamic and you wouldn't want empty array entries.
Title: Autotiles seems to be not working correctly
Post by: 3WG on Thu, Apr 14, 2011
? Any idea i just tried with FlxCollision
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Thu, Apr 14, 2011
yea if you are manually iterating through group members, you have a couple options now.  The easier option i think is instead of iterating through FlxGroup.members.length, just iterate through FlxGroup.length.  Otherwise you do need to check for null entries.
Title: Re: v2.50 beta thread!
Post by: krix on Thu, Apr 14, 2011
I found a bug in FlxObject and FlxSprite
--> getScreenXY() returns a wrong variable.

Original code from latest dev branch:

Code: [Select]
override public function getScreenXY(Point:FlxPoint=null,Camera:FlxCamera=null):FlxPoint
{
if(Point == null)
Point = new FlxPoint();
if(Camera == null)
Camera = FlxG.camera;
_point.x = x - int(Camera.scroll.x*scrollFactor.x) - offset.x; //copied from getScreenXY()
_point.y = y - int(Camera.scroll.y*scrollFactor.y) - offset.y;
_point.x += (_point.x > 0)?0.0000001:-0.0000001;
_point.y += (_point.y > 0)?0.0000001:-0.0000001;
return Point;
}

_point should be returned instead of Point because the local variable Point is created but never used. So the function always returns a new FlxPoint or the FlxPoint from the parameters.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Thu, Apr 14, 2011
oh balls you are 100% correct, stupid copy paste error on my part!  i'm on it
Title: Re: v2.50 beta thread!
Post by: Rybar on Thu, Apr 14, 2011
Anyone drawing effects to the screen with the flash API, gotta subtract scroll.x and .y instead of adding them now under the new camera system.

Thanks Adam for moving overlap and collide back to FlxG btw.   :D
Title: Re: v2.50 beta thread!
Post by: Rybar on Thu, Apr 14, 2011
I'm a bit confused on how to duplicate some behavior I had with the new collision system. I had something like:

Code: [Select]
override public function hitleft()
{
velocity.y = -velocity.y *.8
}

It was for bouncing off the floor and ceiling. Am I to use if(isTouching(LEFT)) or (touching & LEFT) or something else entirely? I haven't had any luck so far.. help please!
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 15, 2011
in update(), doing this:

Code: [Select]
if(isTouching(LEFT) velocity.y *= -0.8;
should totally work.  Currently the only thing that is tough to do is to manually adjust the X velocity on X touches (like LEFT, RIGHT, WALL, etc), or manually adjust the Y velocity on Y touches (like UP, DOWN, FLOOR, etc).  However, you can use FlxObject.elasticity to do some nice automatic bounce behaviors.

In this specific case though, for an X touch with a Y velocity change, I'm not sure why isTouching(LEFT) wouldn't work, without knowing what was going on with the X velocity and the actual collision situation there
Title: Re: v2.50 beta thread!
Post by: Rybar on Fri, Apr 15, 2011
lol, thats exactly what I'm doing though, I mis-typed my example. It's just bouncing off the walls and floors by overriding hitleft, hitright, hitceiling, hitfloor.

Code: [Select]

override public function hitleft()
{
velocity.x *= -0.8
}

override public function hitfloor()
{
velocity.y *= -0.8
}

etc.
is what worked before, now I'm trying with the new checks & bitfields with

Code: [Select]
if(isTouching(LEFT) velocity.x += -0.8;
//etc....
and it's not working.

Why is it that adjusting X velocity on X touches and Y velocity on Y touches is difficult now?  Could you elaborate a bit on how to make use of the elasticity parameter? I'm sure that would work if I was doing it properly but I tried giving my player object some elasticity (elasticity = .5) and it didn't seem to have the desired effect.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 15, 2011
yea what i would try is just remove the isTouching stuff entirely, and just set elasticity to 0.8, and you should be good to go.

whats happening, if you're using collide() (and thus separate()), is when stuff collides its setting the velocity of that axis to zero.  so when you collide with the left wall, it sets your velocity to 0 (if elasticity is zero).  so multiplying the velocity when the next frame rolls around doesn't really have any impact.

however, setting elasticity to 0.8 should work great, and then you don't have to do any isTouching at all.  if you really want to manually adjust on touches, then you need to declare your own FlxPoint to store the last frame's velocities in, or write your own separate() functions.

this is not something i'm super-satisfied with, but elasticity seems to work pretty great for a lot of stuff so far!
Title: Re: v2.50 beta thread!
Post by: photonstorm on Fri, Apr 15, 2011
Elasticity is awesome :) The only issue I have with it is there's no way to set a minimum threshold (that I've found). Setting it to anything other than 1 makes it reduce in value over time, but when it gets down to a really low figure the sprite will sit and jitter insanely on the spot, never quite getting back to zero again.
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Fri, Apr 15, 2011
Ok, another handy suggestion for FlxButton. A get function for _status, to check the status of the button. Code example below:
Code: [Select]
/**
 * returns status of button.
 */
public function get status():uint
{
return _status;
}
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 15, 2011
Elasticity is awesome :) The only issue I have with it is there's no way to set a minimum threshold (that I've found). Setting it to anything other than 1 makes it reduce in value over time, but when it gets down to a really low figure the sprite will sit and jitter insanely on the spot, never quite getting back to zero again.

Yeah - check out FlxParticle to see a simple way to threshold a bouncing sprite
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 15, 2011
Ok, another handy suggestion for FlxButton. A get function for _status, to check the status of the button. Code example below:
Code: [Select]
/**
 * returns status of button.
 */
public function get status():uint
{
return _status;
}

Np, that's on my list for next week already :)
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Fri, Apr 15, 2011
yay! Makes stuff much easier.
Title: Re: v2.50 beta thread!
Post by: XanderXevious on Sat, Apr 16, 2011
Really great job on the Flixel 2.5, Adam!

Didn't take too long to convert everything over and works much smoother.

The coolest feature has to be the new FlxCamera - just 2 new lines of code and I have split screen, another 2 lines and I can zoom or rotate the screen to my heart's content!

For my 2 cents, here are the things that I had to do to convert everything over, a la the 'quick and dirty' approach:

Convert over the cameras:
Code: [Select]
camera = new FlxCamera(0, 0, FlxG.width, FlxG.height);
FlxG.resetCameras(camera);
camera.follow(player, FlxCamera.STYLE_PLATFORMER);
Set the world bounds for collisions/overlaps to work correctly:
Code: [Select]
FlxG.worldBounds = new FlxRect(0, 0, tilemap.width, tilemap.height);Use the new collision functions
Code: [Select]
FlxG.collide(level.mainLayer, player);
FlxG.overlap(coinsGroup, player, CoinCollected);
Ensure collide and draw indices are specified in loadmap now:
Code: [Select]
layerbg.loadMap( new CSV_bg, Img_bg, 25,25, FlxTilemap.OFF,0,1,1 );

I'll update both DAME flixel exporters and sample games to support 2.5 later today.

I only have 1 question for Adam:
ScrollFactor has been removed from FlxGroup. Does this mean that the only way to set scrollFactors on sprites in a group is now to manually set it for each sprite we add?
Title: Re: v2.50 beta thread!
Post by: photonstorm on Sat, Apr 16, 2011
I do think that FlxTilemap ought to have its own FlxRect which relates to its position / size, that was public. So you could do:

Code: [Select]
FlxG.worldBounds = map.getRect
Title: Re: v2.50 beta thread!
Post by: XanderXevious on Sat, Apr 16, 2011
I do think that FlxTilemap ought to have its own FlxRect which relates to its position / size, that was public. So you could do:
Code: [Select]
FlxG.worldBounds = map.getRect
I second that. It would be very useful.
Title: Re: v2.50 beta thread!
Post by: XanderXevious on Sat, Apr 16, 2011
I think I've found a bug with the path following code in FlxObject.

Around line 480 there is this test

Code: [Select]
if( ((_pathCheck.x <= 0) && (dx >= 0)) || ((_pathCheck.x >= 0) && (dx <= 0)) ||
((_pathCheck.y <= 0) && (dy >= 0)) || ((_pathCheck.y >= 0) && (dy <= 0)) )
advancePath();

I have a mostly vertical path of 2 nodes set to YOYO. The problem is that the x test is passing when it shouldn't. Sometimes in the middle of the path, and eventually when it reaches the top node it will get stuck, calling advancePath over and over again.

Changing the code to the following seems to fix it:

Code: [Select]
var xGreater:Boolean = Math.abs(_pathCheck.x) > Math.abs(_pathCheck.y);
var yGreater:Boolean = Math.abs(_pathCheck.y) > Math.abs(_pathCheck.x);
var xPass:Boolean = xGreater && ( ((_pathCheck.x <= 0) && (dx >= 0)) || ((_pathCheck.x >= 0) && (dx <= 0)) );
var yPass:Boolean = yGreater && ( ((_pathCheck.y <= 0) && (dy >= 0)) || ((_pathCheck.y >= 0) && (dy <= 0)) );

if( xPass || yPass )
advancePath();
Title: Re: v2.50 beta thread!
Post by: XanderXevious on Sat, Apr 16, 2011
For anyone that's interested (and doesn't want to download DAME ;) ), here is a link to some sample as3 projects, with versions for both flixel 2.43 and 2.5 included. The end results for each are (mostly) identical.

http://dambots.com/games/dame/samples.zip (http://dambots.com/games/dame/samples.zip)
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 18, 2011
I only have 1 question for Adam:
ScrollFactor has been removed from FlxGroup. Does this mean that the only way to set scrollFactors on sprites in a group is now to manually set it for each sprite we add?

I put in a new thing for this that I'm kind of excited about, that is useful for way more than just scrollFactors.  I use it down at the bottom of PlayState.create() in the Mode dev branch:

Code: [Select]
_hud.setAll("scrollFactor",new FlxPoint(0,0));
_hud.setAll("cameras",[FlxG.camera]);

These two lines of code set everything in my HUD group to not scroll and only run on the main camera.  It may only work for public variables though?  Pretty handy regardless.  I might need to make a sister function like "callAll()" that would do the same for functions, rather than variables?
Title: Re: v2.50 beta thread!
Post by: klembot on Fri, Apr 22, 2011
I see preUpdate and postUpdate methods in FlxBasic and the potential added complexity is a bit scary. Could you talk a little bit about what the idea behind them (and the _ACTIVECOUNT and _VISIBLECOUNT variables) is, i.e. how they're intended to be used?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 22, 2011
the intent is for MOST uses, in most cases, you'll never actually work with those methods.  In all the games I've ported locally to 2.50, I've only ever worked in update().

The three functions are all called right in a row, on each object.  So there's no like... pre-pass, THEN real update pass, then post-pass.  It's just for each object, we call pre(), then update(), then post().

This allows for a few useful things.  One, preUpdate() can register and track the last X and Y position of the object, which is really important for the new, simpler collision system, and will enable easy movement of the x += 0.5; flavor, which was impossible in old flixel.  Two, postUpdate() can handle animation, clearing the collision flags and integrating the new X and Y position based on velocity and acceleration, if you used those variables.  And three, you no longer have to call super.update if you're extending FlxSprite or FlxBasic or FlxObject, as nothing happens in update() by default.  So you can just override it, and throw ALL your logic in there.

It was a little scary at first for sure, but I think that the tradeoffs in clarity and simplicity are really worth it!

HOWEVER, it's possible if not likely that some crazy game ideas out there might need to override preUpdate or postUpdate for one reason or another.  In this case it's totally not a big deal, you just override it like usual, and as long as you remember to call super.preUpdate() or super.postUpdate() you should be just fine :)
Title: Re: v2.50 beta thread!
Post by: klembot on Fri, Apr 22, 2011
Oh cool. I like the idea of tracking previous x/y position that way. x += 0.5 failed because Flixel rounds off coordinates to the nearest pixel for rendering, right?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 22, 2011
klembot: well flixel has always done positions as floats, but it would have broken the old "collision hulls" system i was using, which was based on using velocity only.

ALSO, awesomeness, I believe the final-ish beta build of 2.50 is up on github right now, including FULL documention for v2.50.  If any of you have some free time this weekend and want to try some things out, that'd be awesome.  I really appreciate everyone that's been banging on it so far, found and fixed a lot of weirdness already :)

If all goes well the new site and the v2.50 master branch will both go live on sunday or monday night!  just in time for ludum dare 20 next weekend :D



also, updated my 2.50 master to-do list with results:

> seeing if i can simplify sound mgmt with the global sound mixer SKIPPED
> trying to clarify world/physics overlap versus screen/graphic overlap DONE
> timers DONE
> hover bool/callbacks for flxbutton DONE
> comparing the speed of my "fast" angle calcs in FlxU versus just using Math SKIPPED
> maybe improving the "lost focus" arrow screen appearance OK FOR NOW
> double click support DELAYED
> auxiliary global update/draw callbacks lists DONE (PLUGINS)
> exposing _framePixels DONE
> running through the github queue DONE
> fixing up flx.py DELAYED

I also put in or fixed a bunch of stuff not listed there but that's ok!
Title: Re: v2.50 beta thread!
Post by: axcho on Fri, Apr 22, 2011
ALSO, awesomeness, I believe the final-ish beta build of 2.50 is up on github right now, including FULL documention for v2.50.  If any of you have some free time this weekend and want to try some things out, that'd be awesome.

Will do. :)
Title: Re: v2.50 beta thread!
Post by: aukyr on Sat, Apr 23, 2011
I just started to port, something like this happened
http://cl.ly/0c2N0f3w1G3n1h1j1z0c
I guess draws the screen but does not clear the old one maybe?

it should look like this:
http://aukyr.com/nemmies/nemmies_v02.html

Any guesses? No runtime or compile errors.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sat, Apr 23, 2011
2.50 supports transparent by colors now, so double-check the alpha on flxg.bgcolor!  Tho I should check that the default bg color is opaque too...
Title: Re: v2.50 beta thread!
Post by: Dids on Sat, Apr 23, 2011
So, uh, any news on FlxPath/followPath?
I was just about to implement FlxPathfollowing using Flixel 2.5 dev/beta but noticed that FlxPath was there, now I'm just not 100% sure how to use it.
I know that I can pass findPath to the tilemap, but not sure how that ties in with FlxPath.
Also, does findPath really use pixels' x & y as points and not tile locations as points?

Thanks in advance. :-)
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sat, Apr 23, 2011
yea findPath runs off worldspace x and y coordinates, and returns a FlxPath.  One reason to run off X and Y coords is so you can easily use it with any game object, not just from tile to tile.  also it is easier to calculate world coords from a tile than vice versa, and you can use the new mmm i think its FlxTilemap.getTileCoords() to automatically grab that info from specific tile types.

FlxObject has a method called followPath() that you can use to automatically follow a path, or just write your own logic in update(), using the FlxObject.path var to store a reference to the path.  paths know how to draw themselves in visual debug mode so you don't have to worry about that part either!

The path following is VERY VERY simple at the moment, just linear, from node to node, no fancy tweening or anything.  However, it does have some useful behavior flags, for looping versus no loop, and only following on X axis (nice for patrolling enemies in platformers)
Title: Re: v2.50 beta thread!
Post by: Dids on Sat, Apr 23, 2011
Ah, makes sense and suits me perfectly.
Thanks for the quick reply! :-)
Title: Re: v2.50 beta thread!
Post by: aukyr on Sat, Apr 23, 2011
2.50 supports transparent by colors now, so double-check the alpha on flxg.bgcolor!  Tho I should check that the default bg color is opaque too...

so I changed;
bgColor = 0x626c46; ---to--> FlxG.bgColor = 0xFF626c46;
and it got back on.

I also found out that if you are using autotilemap and camera follow, you should pass UpdateWorld=true which is false by default when defining "FlxG.camera.setBounds()"

When it was false, I got my walking guy falling in the tilemap and ignoring collisions, starting at 8 or 6 tiles inside the tilemap from the right.. not sure how they are related but, I managed to get this happening a little bit closer to the edge of the tilemap by increasing the game w/h. But anyway updateworld=true, solved this completely.

I loved the new flixel, and can confirm that this prototype has been ported just fine, and got much better. Thanks for everyones efforts.

http://aukyr.com/nemmies/nemmies_v03.html

if you want to compare with 2.35 just change 3 to 2 in the url ;)

Title: Re: v2.50 beta thread!
Post by: Dids on Sun, Apr 24, 2011
Did some testing with FlxPath/findPath and this is what I noticed:

Doing tilemap.findPath(new FlxPoint(0, 0), new FlxPoint(100, 100), false, false) should (to my understanding) get the path from 0,0 to 100,100, but instead it becomes null, since in my case it runs out of bounds (over the max tile index).

My tilemap is 320x240 with 16x16 per tile, so with that in mind, in the above example findPath uses startIndex 0 and endIndex 100 and after that it gets to "figure out how far each of the tiles is from the starting tile" and stops there/returns null.

I tried changing the coords from 0,0 to 10,10 which in turn give me startIndex 0 and endIndex 0, but it does add a new point to the FlxPath's node (at 10, 10).

I'm just tracing findPath's function directly to see what it's doiong

I must be misunderstanding something or just confusing world and tile locations, but I thought that findPath does the tile calculation for you based on the X and Y coords you give it?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 24, 2011
yea by default the world bounds are just set to the screen size plus a little bit of padding around the edges.  so you definitely want to make sure that you update those boundaries if you're making a game with scrolling!

also, I believe 2.50 is ready for the big leagues finally :) put up something like 7000 lines of new documentation or updated variable names (no more _a = bla bla!) in the last few days, and the new website is almost ready :)
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 24, 2011
yes, findPath() runs on world coordinates.  if it is returning null during the distance calculation it is because it could not find a clear path between the two points you provided.  this may be a bug or it may just be an issue with the tilemap data, i can't tell yet.  we have run quite a few tests here though and it seems to find end points correctly...
Title: Re: v2.50 beta thread!
Post by: Dids on Sun, Apr 24, 2011
Alright, I'll keep testing, bound to get it right at some point. ;)
It might even be the tilemap data, as I'm using an Ogmo-based tilemap.
Flixel 2.5 is looking really, really good to be honest. :)

EDIT: Is endIndex the last tile location? As in my example above, I'm telling it to find a path to X100/Y100 and it's telling me that the endIndex for that is 100 and that's when it becomes null. The total width of the tiles on screen is 20 (height is 15).
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sun, Apr 24, 2011
Well depends on the tile size right, it calculates the end index based on the world coordinates you passed and the tile size...
Title: Re: v2.50 beta thread!
Post by: axcho on Sun, Apr 24, 2011
Mistake in the documentation for FlxText:
Quote
shadow : uint
The alignment of the font ("left", "right", or "center").

Looks like the description for shadow was copied and pasted from alignment and never changed...

Also the comment for FlxSprite.stamp() still refers to render()
Quote
This function is NOT intended to replace render()!

Probably want to change that to draw().

***

There seems to be a bug in FlxButton.draw(), which assumes that there is a label, even though it is possible to create a button with a null label:
Code: [Select]
/**
 * Just draws the button graphic and text label to the screen.
 */
override public function draw():void
{
    super.draw();
    label.draw();
}

Probably should check if label is null first so it doesn't crash:
Code: [Select]
override public function draw():void
{
    super.draw();
    if(label != null)
        label.draw();
}

***

Another bug, in FlxObject.justTouched() which does the opposite of what it is apparently supposed to do:
Code: [Select]
/**
 * Handy function for checking if this object is just landed on a particular surface.
 *
 * @param Direction Any of the collision flags (e.g. LEFT, FLOOR, etc).
 *
 * @return Whether the object just landed on (any of) the specified surface(s) this frame.
 */
public function justTouched(Direction:uint):Boolean
{
    return ((touching & Direction) && (wasTouching & Direction)) > NONE;
}

Instead, you probably want it to check if it is touching now and not touching last time:
Code: [Select]
public function justTouched(Direction:uint):Boolean
{
    return ((touching & Direction) > NONE) && ((wasTouching & Direction) == NONE);
}

***

FlxGroup has a method called getFirstAvail() - have you considered renaming this to getFirstAvailable()? This is one of the only places in Flixel where a name is abbreviated, and so it is inconsistent and easy to forget. I hear tell that the only appropriate names to abbreviate in code are "min" and "max", and other similarly common words. "Avail" is not one of them.

Maybe you could call it getFirstAbsent() to more clearly show the opposing relationship with the getFirstExtant() function. Still a short name, but no abbreviation.

***

Also, would it be possible to make the default version of the API documentation omit or hide the "internal" public variables and functions? I think they'd tend to clutter up the interface info that I'd actually be looking for, and make things more intimidating and confusing for newcomers...

Comments in the code itself should probably be fine for those who want to actually hack that stuff (like myself, perhaps).

***

I do not see a built-in way to reproduce the functionality of the old FlxG.followAdjust(). How would I do this? Do I have to manually create a separate cameraTarget object that I move every frame based on my actual target's velocity?

***

Trying to port one of my recent prototypes to Flixel v2.50 beta, I'm wondering how to port the graphical effects code that I've put in FlxState.postProcess(), since this method seems to be missing, along with FlxState.screen, the FlxSprite buffer I was using.

Any suggestions? It seems that the cameras all have their own buffers, but these are BitmapData objects. Would it be too much to ask to give each camera a "screen" FlxSprite that countains its "buffer" BitmapData? This would make it easier to do effects like your FlxBloom without having to dig into Flash bitmap rendering functions.

Currently my solution is to create my own "screen" FlxSprite and set screen.pixels to FlxG.camera.buffer. I would like to request that you give each camera its own public "screen" FlxSprite with this already set up.

I am also having some difficulty with postProcess() effects because the camera buffers are all locked during the FlxState.draw() call, where I've tried to move my old postProcess() code. Basically, it lags a frame behind, because it uses the old version.

Is the best practice in this situation simply to call FlxG.unlockCameras() and then FlxG.lockCameras() again? It looks like those are internal functions. And FlxG.camera.buffer.unlock() could work but it seems very unsafe and encapsulation-breaking. More importantly, I can't get it to work correctly. I wonder if there might be a better way to handle this.

Or maybe I should be moving this code into a custom FlxCamera subclass?

***

So other than that post-processing issue my port to v2.50 is complete. (I'm looking forward to seeing your FlxBloom example for v2.50!) I love the new features like the replays and plugin system, and I appreciate all the improved refactoring and such that has gone into this update. I know it will take a lot of tutorial writing from the Flixel community to make this update fully accessible to new developers, but I think it will be very worthwhile and helpful in the long run.

Thank you, Adam.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 25, 2011
hey dude great catches!  I've already put in most of the changes.  couple of specific things:

1 - yes, if you want to mimic the old followAdjust() behavior, then you should create your own FlxObject (i usually call mine "focus" or something like that) and assign your own custom behavior there, and have the camera follow that.  default look-ahead behavior ended up being sufficiently complicated that i feel most comfortable taking that approach from now on.

2 - as far as post-processing, you SHOULD be able to just override your game state's draw() functionality, and do it there.  however, I will be re-building FlxBloom to run in v2.50 today I think, and I will see how it goes!  I originally intended to include a "screen" FlxSprite with each camera, and then decided against it, but I can't actually remember why...
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 25, 2011
ok yea I can verify that post-processing the camera buffer is hard/impossible at the moment.  i am thinking about the best way to make that an option again :)
Title: Re: v2.50 beta thread!
Post by: Dids on Mon, Apr 25, 2011
Still not quite getting good results with the pathfinding. :-/

I even tried dividing the world coordinates with the tileSize, as that atleast got me a point or two to play with, though every single time I get a path, enemies seem to be moving to the top left corner, so instead of increasing the X and Y it's decreasing them.

I'm just feeding it the coords like this: findPath(new FlxPoint(enemy.x, enemy.y), new FlxPoint(player.x, player.y))

As soon as the coords are bigger than the total tile width or height of the tilemap, it returns null.

I have to be doing something horribly wrong, as I can't seem to wrap my head around this. Am I perhaps supposed to get the tile myself, then pass the tiles point coordinates to findPath?

Are there any working examples of pathfinding in action, so I could crosscheck with existing code?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 25, 2011
that's super weird - cuz i mean the first 2 lines of findPath() are:

Code: [Select]
var startIndex:uint = uint((Start.y-y)/_tileHeight) * widthInTiles + uint((Start.x-x)/_tileWidth);
var endIndex:uint = uint((End.y-y)/_tileHeight) * widthInTiles + uint((End.x-x)/_tileWidth);

Like the very first thing it does is convert the world coordinates you give it into tile indices.  So the way you are using it in your example should be totally fine.  so i mean the world coordinates themselves need to be within the map dimensions, but you really shouldn't have to bother with tile indices or anything :(  that's weirdness.

I believe the dev branch of FlxCollisions has some simple pathfinding code running in it at the moment, if you uncomment the two blocks labeled "silly pathfinding whatever"
Title: Re: v2.50 beta thread!
Post by: axcho on Mon, Apr 25, 2011
ok yea I can verify that post-processing the camera buffer is hard/impossible at the moment.  i am thinking about the best way to make that an option again :)

Thank you. Looking forward to seeing what you come up with. :)
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 25, 2011
I fixed the thing where tilemap collisions were losing track of what was A list and what was B list.  I had to rework the mass/elasticity-based collisions some to get FlxTeroids to work right, but I'm really happy with the results so far.  FlxText and FlxSprite documentation fixed.  FlxButton null thing fixed.  justTouched() logic gate fixed.  renamed getFirstAvail() to getFirstAvailable().

ok post-processing is the last thing I have left I think.  FlxBlur, FlxTeroids, FlxInvaders, FlxCollisions, Mode and HelloWorld have all been updated to v2.50 locally!  Once I figure out post-processing and FlxBloom I think I will push all this stuff out to the master branch, and tomorrow we should have the new website working!

Thanks again for all the testing and early upgrades and stuff you guys, it's been a huge help!
Title: Re: v2.50 beta thread!
Post by: Deviantgeek on Mon, Apr 25, 2011
I fixed the thing where tilemap collisions were losing track of what was A list and what was B list.  I had to rework the mass/elasticity-based collisions some to get FlxTeroids to work right, but I'm really happy with the results so far.  FlxText and FlxSprite documentation fixed.  FlxButton null thing fixed.  justTouched() logic gate fixed.  renamed getFirstAvail() to getFirstAvailable().

ok post-processing is the last thing I have left I think.  FlxBlur, FlxTeroids, FlxInvaders, FlxCollisions, Mode and HelloWorld have all been updated to v2.50 locally!  Once I figure out post-processing and FlxBloom I think I will push all this stuff out to the master branch, and tomorrow we should have the new website working!

Thanks again for all the testing and early upgrades and stuff you guys, it's been a huge help!

...
...
YAYAYAYAYAYAY! New stuff! and the code branch will finally be stable for w bit.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, Apr 25, 2011
phew, I think that was the last big push.  post-processing is back in, and tweaked a few other things here and there.  If you have time tonight or tomorrow I would LOVE for someone to go through and bang on it just a little more before I go over to master branch tomorrow evening.  I was able to update all my old demo projects to the new codebase, and I haven't spotted any exceptionally lame things lately... so here's hoping we made it :)

tomorrow i'll be working on the website with jasmhz and waiting for any last bug reports to come in, but otherwise I think 2.50 might be ready for the big time!
Title: Re: v2.50 beta thread!
Post by: axcho on Mon, Apr 25, 2011
Great, I'll try the new post-processing system later tonight. Looking forward to it! ;)
Title: Re: v2.50 beta thread!
Post by: Dids on Mon, Apr 25, 2011
Got a bit further using a really simple Mappy-generated tilemap.

It seems my problem is with collisions, as it's returning null when checking for allowCollisions, even though I'm only using two tiles and setting their properties so that one's collidable (walls) and one's not (floors).

EDIT: Gotten as far as getting calculating the distance, so getting there, but the following if sentence seems to be null:
Code: [Select]
if((_tileObjects[_data[i]] as FlxTile).allowCollisions)Guess I could try yet another tile editor. :-P

EDIT2: Err what the heck, it's working now, apparently had a problem with tile collisions.
Title: Re: v2.50 beta thread!
Post by: axcho on Tue, Apr 26, 2011
Yay, my post-processing effects don't lag behind anymore! ;D

However, with the latest version of v2.50, my FlxTimer objects have stopped working - the callbacks never get called! Any idea why that is?

Code: [Select]
    // ...

    // start timer
    var timer:FlxTimer = new FlxTimer();
    timer.start(1, 1, onWaitTimer);
}

private function onWaitTimer(Timer:FlxTimer):void
{
    // remove timer
    Timer.stop();

    // ...

In this example, onWaitTimer() never gets called...
Am I using FlxTimer correctly here?

***

Also, looking at the change you've made to make post-processing possible, I'm wondering whether it might be a good idea to set useBufferLocking per camera, not just globally. Could there be situations where you'd have some cameras with effects and some without?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Tue, Apr 26, 2011
I should have explained that it works by overriding draw(), and you can work directly with the bitmapdata flxcamera.buffer or the new flxsprite flxcamera.screen. For some operations the frame pixels may be out of date on the screen object, but you can force it to be ok by calling drawFrame if you need to
Title: Re: v2.50 beta thread!
Post by: Geti on Tue, Apr 26, 2011
Adam it could be better if instead of calling pre- and postUpdate all in FlxGroup's main update and all in a row for every object, you made FlxGroup's preUpdate() call all it's members preUpdate functions, postUpdate call all it's members postUpdate() functions, and then in FlxState's update override called preUpdate(); updateMembers(); postUpdate(); so that the functions were actually all called in unison - allowing preUpdate to do communication, update to process that communication, and postUpdate to apply all changes, for example, which is much better than just splitting one object's update function into three possible parts.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Tue, Apr 26, 2011
yea definitely possible!  i am marginally worried about the performance of doing 3 loops instead of 1 loop in each object, but it's definitely worth considering, making a note to keep an eye on it!
Title: Re: v2.50 beta thread!
Post by: Geti on Wed, Apr 27, 2011
as you'd only be doing the loops at each FlxGroup for each member, it shouldn't be too performance heavy, and if it is you could just not call the preUpdate and postUpdate functions in your flxState override. (adding a "fastUpdate()" function that just calls super.update() in flxState would do the trick).

I might set it up and send you the git link on twitter at some point over the next few days, it just seems pointless the way it's currently set up is all.
Title: Re: v2.50 beta thread!
Post by: Dids on Thu, Apr 28, 2011
Not really sure if this belong in this thread anymore, but it's worth a short. ;-)

Does anyone have any tips on updating the path while moving at a relatively high velocity? So far all my efforts have ended up in laggy movement, no matter how often/rarely I update an object with a new path.

Should I just calculate the path, then iterate through the nodes one by one, instead of using followPath altogether?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Thu, Apr 28, 2011
i'm not sure i follow (no pun intended) - you have a fast-moving object and you are giving it a new path to follow each frame, or?
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Thu, Apr 28, 2011
I just pushed v2.51 to the dev branch, the main changes are to overlaps(), and a new function overlapsAt().

overlaps() is now smart enough to call tilemap collision if necessary, and recursively loop through groups.  FlxG.overlaps() is still going to be better performance, probably, but sometimes overlaps() is handier, especially for prototyping.

overlapsAt() is a new function that takes and X and Y value, it's a sort of "what if" function that some people have requested.  you would use it something like this:

Code: [Select]
if(overlapsAt(x+10,y,walls)) { trace("within 10 pixels of right wall"); }
overlapsAt() has the same upgrades overlaps() got, meaning it handles groups and tilemaps pretty well.  i did some cursory testing and everything seemed ok, but if you guys can help me check it tonight and tomorrow then folks should be able to use it for Ludum Dare... thanks!
Title: Re: v2.50 beta thread!
Post by: UberGeorge on Fri, Apr 29, 2011
Hi Adam, You're making a lot of great changes to Flixel but they're all major changes. I feel you're overlooking some of the more mundane features that Flixel could use.

1) You currently have a useDefaultHotKeys switch. I'd also like to see a useFlixelCursor switch. If it's set to false Flixel switches to the Flash system cursor instead of it's own.

2) Give FlxSprite the ability to draw just a portion of the image.

3) MouseOver and buttonClick sound effects options added to FlxButton

4) Independant Music and SoundFX mutes.

Looking through Flixel's code I think the first two could be added rather easily without running the risk of breaking existing code. The other two might be more complicated though.

Thanks for listening! Bye.
Title: Re: v2.50 beta thread!
Post by: 3WG on Fri, Apr 29, 2011
Hi Flixelers,

I'm trying the new 2.5 flixel and something miss for me with the new isTouching()

The old way to check hitTop(Contact:FlxObject,Velocity:Number) as the ability to retrieve to objects type we are touching ...

What the best way to do this with 2.5.


P.S. : Maybe one day i will master English and another Flixel (only the second is a dream ;)

Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Fri, Apr 29, 2011
aweosme suggestions ubergeorge!  would you be inclined to punch them into the github issues queue?  i will be more likely to keep track of them there, i like how most of that sounds though

3WG - the way to check that stuff in v2.50 is to do it similar to how FlxU.overlaps() used to work.  you just write a custom callback or handler and pass that in to FlxG.collides()
Title: Re: v2.50 beta thread!
Post by: UberGeorge on Fri, Apr 29, 2011
Great, I added them as four individual requests. Thanks.
Title: Re: v2.50 beta thread!
Post by: auriplane on Fri, Apr 29, 2011
I have a bunch of little things I can contribute, if anyone wants them, that I hacked into 2.43 for my current project as I went.  But I really want to try updating to 2.51, because this fixed timestep stuff seems like it would help with a lot of little physics bugs in my game!  (Like, a current bug: not being able to jump into one-tall corridors, because you pass over it in the space of one frame!  Happens at 20fps or lower.)

A couple tiny things I did: changed FlxText shadow to have a _shadowDistance var, added a FlxText outline (behaves like shadow, but draws on all four sides instead of +1+1), added a separate music volume, added a ringbuffer to keyboard to give me the last N keys pressed, added some missing keys, separate console enable/disable flag in FlxG...  So mostly small things.  Should I post any of my horrid hackery?

I had this idea that I should try to serialize the tilemaps to AMF via ByteArray, then embed those to reduce the startup time for a map, but I never got that working :-(

Looking forward to trying 2.51 tonight :-D

P.S. My CAPTCHA to sign up for the forum had a Greek letter in it, which I dutifully entered, and it said I was correct!
Title: Re: v2.50 beta thread!
Post by: auriplane on Fri, Apr 29, 2011
Yikes!  Changing the collision stuff from 2.43 to 2.51 is pretty daunting.  

The bounces for hitleft etc., I take out entirely replace with elasticity?

useDefaultHotKeys -> useSoundHotKeys?
showBounds -> FlxG.visualDebug?
FlxState.bgColor -> FlxG.bgColor (including alpha?)
Okay, _pause has been broken into a bunch of things.  That makes sense.  Why is _focus just a Sprite?  My old FlxPause was used only for lost focus, and looks like this:

Code: [Select]
package
{
    import org.flixel.*;

    public class PauseLayer extends FlxGroup
    {
        public var pauseText:FlxText;
        public var bg1:FlxSprite;
        public var bg2:FlxSprite;

        public function PauseLayer():void
        {
            // snip a bunch of code to set up a little pause box
            // ...
        }

        override public function update():void
        {
            if (FlxG.mouse.justPressed() ||
                FlxG.keys.justPressed("Z") ||
                FlxG.keys.justPressed("X") ||
                FlxG.keys.justPressed("J") ||
                FlxG.keys.justPressed("K") ||
                FlxG.keys.justPressed("P") ||
                FlxG.keys.justPressed("ESCAPE") ||
                FlxG.keys.justPressed("SPACE") ||
                FlxG.keys.justPressed("ENTER"))
                FlxG.paused = false;
        }

I went ahead and took a screen shot of my old pause screen, though I'm not sure what to do from there--I've got no update()!

Some actors bounce off walls, but not floors.  They need separate X and Y elasticity!  Can you make it a vector instead of a scalar, by any chance?  (EDIT: Well, it only took a minute to add it to my own copy, so it's no big deal :-)

Moving platforms are the only place where I actually used the flxobject passed in by hitleft/hittop etc.  Most of the time, it looks like I want justTouched(), rather than isTouching().  Looks good!

My project is an exciting 31000 lines of cruddy code, so it'll be a little while before I get it working, I think, so I don't actually know how well it works yet :-)
Title: Re: v2.50 beta thread!
Post by: axcho on Fri, Apr 29, 2011
Some actors bounce off walls, but not floors.  They need separate X and Y elasticity!  Can you make it a vector instead of a scalar, by any chance?
This would be a nice change for v2.52... ;)
Title: Re: v2.50 beta thread!
Post by: misko28 on Sat, Apr 30, 2011
My tilemap doesn't work for tiles above index of 15 :(
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sat, Apr 30, 2011
My tilemap doesn't work for tiles above index of 15 :(

is it on auto-tile?  i'm pretty sure the tile types are enumerated by total number of tiles...
Title: Re: v2.50 beta thread!
Post by: misko28 on Sat, Apr 30, 2011
I've changed

Code: [Select]
map.startingIndex = 1;
map.loadMap(new levels[FlxG.level-1], tileImg, 16, 16);

to

Code: [Select]
map.loadMap(new levels[FlxG.level-1], tileImg, 16, 16, 0, 1, 0, 0);
And now I can't see tiles with index 15
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sat, Apr 30, 2011
can you post your level data and tiles?  if you want to keep them secret just email them to me and i'll figure out whats up :)
Title: Re: v2.50 beta thread!
Post by: misko28 on Sat, Apr 30, 2011
http://dl.dropbox.com/u/17207099/tile.bmp

http://pastebin.com/RZybz8Wb
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Sat, Apr 30, 2011
I have a bunch of little things I can contribute, if anyone wants them, that I hacked into 2.43 for my current project as I went.  But I really want to try updating to 2.51, because this fixed timestep stuff seems like it would help with a lot of little physics bugs in my game!  (Like, a current bug: not being able to jump into one-tall corridors, because you pass over it in the space of one frame!  Happens at 20fps or lower.)

A couple tiny things I did: changed FlxText shadow to have a _shadowDistance var, added a FlxText outline (behaves like shadow, but draws on all four sides instead of +1+1), added a separate music volume, added a ringbuffer to keyboard to give me the last N keys pressed, added some missing keys, separate console enable/disable flag in FlxG...  So mostly small things.  Should I post any of my horrid hackery?

I had this idea that I should try to serialize the tilemaps to AMF via ByteArray, then embed those to reduce the startup time for a map, but I never got that working :-(

Looking forward to trying 2.51 tonight :-D

P.S. My CAPTCHA to sign up for the forum had a Greek letter in it, which I dutifully entered, and it said I was correct!

these are super good ideas, do you want to punch them into the github issues queue?
Title: Re: v2.50 beta thread!
Post by: misko28 on Sat, Apr 30, 2011
http://dl.dropbox.com/u/17207099/tile.bmp

http://pastebin.com/RZybz8Wb

And when I try to use getTileByIndex on my map, it returns 0  :-\
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, May 2, 2011
ok pushed up a bunch of stuff to beta branch as v2.52, mostly some timer fixes and a new function FlxSprite.replaceColor()
Title: Re: v2.50 beta thread!
Post by: photonstorm on Mon, May 2, 2011
Just grabbed 2.52 and added it to 2 of my games, both work perfectly with it. In fact one I was having performance issues with is now running a lot smoother. Will try it on my work machine tomorrow (where the issues were more evident).
Title: Re: v2.50 beta thread!
Post by: Bennett on Mon, May 2, 2011
I can't get the console to appear by pressing ~... am I missing something really obvious, or is it not working right now?
Title: Re: v2.50 beta thread!
Post by: photonstorm on Mon, May 2, 2011
On my keyboard (UK English) it's the ' key (same as the @ key, not ~) but works fine.

I have to add forceDebugger = true to my FlxGame class though, without it it doesn't work because I don't use the FlxPreloader.
Title: Re: v2.50 beta thread!
Post by: Bennett on Mon, May 2, 2011
thanks, that did it.
Title: Re: v2.50 beta thread!
Post by: Adam Atomic on Mon, May 2, 2011
Just grabbed 2.52 and added it to 2 of my games, both work perfectly with it. In fact one I was having performance issues with is now running a lot smoother. Will try it on my work machine tomorrow (where the issues were more evident).

I found a bug where I had put in unnecessary floating point correctiosn that were occasionally causing tilemaps to basically redraw the buffer every single frame.  pretty ****ty for performance it turns out!!
Title: Re: v2.50 beta thread!
Post by: Geti on Mon, May 2, 2011
FlxSprite.replaceColor()
Freaking awesome.
Title: Re: v2.50 beta thread!
Post by: Dynamite_Studios on Tue, May 3, 2011
(Reposted from my accidental post on the other thread...)

I seem to have a problem...

I am porting my (unfinished) game from flixel 2.35 to flixel 2.50, and I'm getting an error in FlxG.collide();. I call it in two places:
FlxG.collide((level as FlxObject),player);/////Collisions
FlxG.collide((level as FlxObject),_bullets);/////////End of Collisions


I'm getting a few errors referring to lines 906-918 of FlxG (v2.50). They are:
line 912: error 1119
lines 914, 915, 916: error 1061

It mentions that there are possibly undefined methods in FlxQuadTree  :o

I don't know how to solve it, and I know it might sound newbish, but I have no idea what is going on... i'm not shure if this is me or the original code, since it was released just hours ago, but I'm a bit worried  :-\ .

Thanks in advance!
Title: Re: v2.50 beta thread!
Post by: axcho on Thu, May 5, 2011
Reported a bug with the latest Flixel here:
https://github.com/AdamAtomic/flixel/issues/144

It's a quick fix, but significant because without it FlxTimer doesn't do anything...
Title: Re: v2.50 beta thread!
Post by: hanuman on Thu, May 12, 2011
Hey guys,

Sorry to ask such a dumb question but where is in 2.5 Sprite instance I can addChild vector stuff. Being stuck on this - only option I found FlxG.flashGfxSprite - but when I added to it, stuff didn't apeear on screen...
Title: Re: v2.50 beta thread!
Post by: photonstorm on Thu, May 12, 2011
You can't (*), flixel is designed for bitmap games.

* without a lot of messing around, and then the vector objects won't work as normal sprites etc
Title: Re: v2.50 beta thread!
Post by: hanuman on Thu, May 12, 2011
You can't (*), flixel is designed for bitmap games.

* without a lot of messing around, and then the vector objects won't work as normal sprites etc

Hey photonstorm,

Thanx for reply. I don't want to use vector in game just UI made within Flash IDE. On 2.43 FlxState was built on top of flash Sprite class so I could just addChild from it but now Adam(thank You for such an awesome framewok) refactored it and I don't know what to do...:)
Title: Re: v2.50 beta thread!
Post by: goshki on Thu, May 12, 2011
I don't want to use vector in game just UI made within Flash IDE. On 2.43 FlxState was built on top of flash Sprite class so I could just addChild from it but now Adam(thank You for such an awesome framewok) refactored it and I don't know what to do...:)

You can access stage by FlxG.stage and add DisplayObject children to it (mind the child ordering).
Title: Re: v2.50 beta thread!
Post by: photonstorm on Thu, May 12, 2011
In 2.5 it still works in the same way, except every camera is a Sprite on the display list. I'd really like for all cameras (and the mouse) to be contained in one single display list object, as it would make several things easier re: sponsor APIs. But until then you'll have to hack around it. You could expose the camera parent Sprite by modifying the codebase a little, just be aware of index order.
Title: Re: v2.50 beta thread!
Post by: hanuman on Sun, May 15, 2011
photonstorm, goshki

Thanx a lot for help guys... :D
Title: Re: v2.50 beta thread!
Post by: werem on Thu, May 26, 2011
Is hard to use the FlxGroup.sort method in a group with groups. Even if you overload the sortHandler method so the group does not generates an error because does not have the "y" property, you can't be sure that the sprites sort correctly, because they are sorted inside the groups.
Title: Re: v2.50 beta thread!
Post by: mightiest_hero on Thu, Jun 2, 2011
Is hard to use the FlxGroup.sort method in a group with groups. Even if you overload the sortHandler method so the group does not generates an error because does not have the "y" property, you can't be sure that the sprites sort correctly, because they are sorted inside the groups.

You can trick that. When add a group to a group don't use add(group) but looping add(group.member)
Title: Re: v2.50 beta thread!
Post by: Alex on Wed, Sep 28, 2011
(Reposted from my accidental post on the other thread...)

I seem to have a problem...

I am porting my (unfinished) game from flixel 2.35 to flixel 2.50, and I'm getting an error in FlxG.collide();. I call it in two places:
FlxG.collide((level as FlxObject),player);/////Collisions
FlxG.collide((level as FlxObject),_bullets);/////////End of Collisions


I'm getting a few errors referring to lines 906-918 of FlxG (v2.50). They are:
line 912: error 1119
lines 914, 915, 916: error 1061

It mentions that there are possibly undefined methods in FlxQuadTree  :o

I don't know how to solve it, and I know it might sound newbish, but I have no idea what is going on... i'm not shure if this is me or the original code, since it was released just hours ago, but I'm a bit worried  :-\ .

Thanks in advance!

I had this problem and then realized I had flixel defined in a global and a local classpath. There were conflicts causing the missing method issue.