Author Topic: v2.50 beta thread!  (Read 30853 times)

axcho

  • Active Member
  • ***
  • Posts: 174
  • Karma: +0/-0
    • View Profile
    • Evolution Live!
Re: v2.50 beta thread!
« Reply #80 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.
« Last Edit: Mon, Apr 25, 2011 by axcho »

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #81 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...

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #82 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 :)

Dids

  • Member
  • **
  • Posts: 25
  • Karma: +0/-0
    • View Profile
Re: v2.50 beta thread!
« Reply #83 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?

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #84 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"

axcho

  • Active Member
  • ***
  • Posts: 174
  • Karma: +0/-0
    • View Profile
    • Evolution Live!
Re: v2.50 beta thread!
« Reply #85 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. :)

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #86 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!

Deviantgeek

  • Member
  • **
  • Posts: 63
  • Karma: +0/-0
  • Youngest flixel dev ever. Srsly.
    • View Profile
    • Devianix
Re: v2.50 beta thread!
« Reply #87 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.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #88 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!

axcho

  • Active Member
  • ***
  • Posts: 174
  • Karma: +0/-0
    • View Profile
    • Evolution Live!
Re: v2.50 beta thread!
« Reply #89 on: Mon, Apr 25, 2011 »
Great, I'll try the new post-processing system later tonight. Looking forward to it! ;)

Dids

  • Member
  • **
  • Posts: 25
  • Karma: +0/-0
    • View Profile
Re: v2.50 beta thread!
« Reply #90 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.
« Last Edit: Thu, Apr 28, 2011 by Dids »

axcho

  • Active Member
  • ***
  • Posts: 174
  • Karma: +0/-0
    • View Profile
    • Evolution Live!
Re: v2.50 beta thread!
« Reply #91 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?
« Last Edit: Tue, Apr 26, 2011 by axcho »

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #92 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

Geti

  • Active Member
  • ***
  • Posts: 143
  • Karma: +0/-0
    • View Profile
    • 1 Bar Design
Re: v2.50 beta thread!
« Reply #93 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.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #94 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!

Geti

  • Active Member
  • ***
  • Posts: 143
  • Karma: +0/-0
    • View Profile
    • 1 Bar Design
Re: v2.50 beta thread!
« Reply #95 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.

Dids

  • Member
  • **
  • Posts: 25
  • Karma: +0/-0
    • View Profile
Re: v2.50 beta thread!
« Reply #96 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?

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #97 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?

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #98 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!

UberGeorge

  • Member
  • **
  • Posts: 99
  • Karma: +0/-0
    • View Profile
Re: v2.50 beta thread!
« Reply #99 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.