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

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
v2.50 beta thread!
« 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 :)
« Last Edit: Fri, Apr 22, 2011 by Adam Atomic »

Adam Atomic

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

axcho

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

Adam Atomic

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

axcho

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

krix

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

Cadwallader

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

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v2.50 beta thread!
« Reply #7 on: Fri, Apr 8, 2011 »
Felt weird continuing to include it, but it can still be downloaded from the v2.43b branch

xyroclast

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

feiss

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


Deviantgeek

  • Member
  • **
  • Posts: 63
  • Karma: +0/-0
  • Youngest flixel dev ever. Srsly.
    • View Profile
    • Devianix
Re: v2.50 beta thread!
« Reply #10 on: Sat, Apr 9, 2011 »
What about createGraphic? That was very useful for simple bullets.

ntdb

  • Member
  • **
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: v2.50 beta thread!
« Reply #11 on: Sat, Apr 9, 2011 »
What about createGraphic? That was very useful for simple bullets.

Try FlxSprite.makeGraphic(width, height, color, unique, key)

roboprez

  • Member
  • **
  • Posts: 13
  • Karma: +0/-0
    • View Profile
Re: v2.50 beta thread!
« Reply #12 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 about how to get it working in the latest version.
« Last Edit: Sun, Apr 10, 2011 by roboprez »

Deviantgeek

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

Cadwallader

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

Deviantgeek

  • Member
  • **
  • Posts: 63
  • Karma: +0/-0
  • Youngest flixel dev ever. Srsly.
    • View Profile
    • Devianix
Re: v2.50 beta thread!
« Reply #15 on: Sun, Apr 10, 2011 »
Also, what about FlxPause? A big triangle is no replacement!

Adam Atomic

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

Adam Atomic

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

Adam Atomic

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

Adam Atomic

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