Author Topic: v3.0 planning thread  (Read 35220 times)

increpare

  • Member
  • **
  • Posts: 42
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #20 on: Tue, Apr 12, 2011 »
re: mod support, I'd say don't worry about it, as Flod covers it with incredible accuracy, and is very easy to use. Mind you, if you add those sound hooks I keep asking for in, then it'd make it even better ;)
If there are a couple of external libraries that might be useful with flixel, and are quite stand alone, maybe a 'flixel platform' distribution with all these third party but trustworthy/stable odds and ends tossed in might be cool.

Billy

  • Active Member
  • ***
  • Posts: 159
  • Karma: +0/-0
  • Herper of Derps
    • View Profile
    • billy.wenge-murphy.com
Re: v3.0 planning thread
« Reply #21 on: Tue, Apr 12, 2011 »
If we're moving out underused things like FlxKong, I was thinking a system similar to what Javascript libraries do would be useful. Check some boxes on a webpage for what pieces you want, and it stitches together a distribution for you. People can pick and choose auxiliary libraries without bloating the main codebase for everyone.

You just need data describing the changes required to apply the mod ("FIND <line of text>", "INSERT LINE <whatever>") and a script that does it, then zips up the files.

Quote
re: mod support, I'd say don't worry about it, as Flod covers it with incredible accuracy, and is very easy to use. Mind you, if you add those sound hooks I keep asking for in, then it'd make it even better

It's not going to change licenses though, right? I mean, it couldn't become part of Flixel right now...
« Last Edit: Tue, Apr 12, 2011 by Billy »

klembot

  • Member
  • **
  • Posts: 61
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #22 on: Tue, Apr 12, 2011 »
Seconding the wish to make it easier to extend Flixel and also for a cleaner and more stable API (which ties into wish #1). I don't mean to hate but for every major release, there always seems like there's a gratuitous name change, e.g. render -> draw, that breaks the existing helper classes I've written. It's not that hard to do a search/replace on my code, but it's annoying... and on the flip side, how many Flixel tutorials out there have become totally incorrect as a result?
I will never reveal the twofold secret.

axcho

  • Active Member
  • ***
  • Posts: 174
  • Karma: +0/-0
    • View Profile
    • Evolution Live!
Re: v3.0 planning thread
« Reply #23 on: Tue, Apr 12, 2011 »
I don't mean to hate but for every major release, there always seems like there's a gratuitous name change, e.g. render -> draw, that breaks the existing helper classes I've written. It's not that hard to do a search/replace on my code, but it's annoying... and on the flip side, how many Flixel tutorials out there have become totally incorrect as a result?
This. Seconded.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v3.0 planning thread
« Reply #24 on: Tue, Apr 12, 2011 »
Totally understand, and I know it's not much consolation but things changed a LOT less during this update than I thought they would... the balance I'm trying to strike is keeping things simple and accessible for newcomers, keeping the performance good, and not breaking TOO much of the old code.  In the case of render() vs draw(), it definitely wasn't a necessary change, but I thought it might help beginners understand what happens in that part of the game loop.

Actually, there are two suggestions just from this page of this thread that illustrate my point perfectly I think:

Quote
Umm and finally, the most boring of all - really tidy-up the internals Smiley There is lots of "magic" going on in places, and some really lazy variable names Smiley It could all just be a lot cleaner in places!

Quote
for every major release, there always seems like there's a gratuitous name change, e.g. render -> draw, that breaks the existing helper classes I've written.

That said, I think the API has been stabilizing - this is the first shakeup in 6 months or more, I only change things when they move closer to my (admittedly arbitrary) ideals.

So yeah - you're right, it is annoying, and it's something I definitely keep in mind, but I also try to not be TOO felicitous, and make sure that changes are done for a reason, even if I totally forget to explain why publicly and/or it's not the greatest reason in the first place :P

photonstorm

  • Administrator
  • Key Contributor
  • *****
  • Posts: 1502
  • Karma: +1/-0
    • View Profile
    • Photon Storm
Re: v3.0 planning thread
« Reply #25 on: Thu, Apr 14, 2011 »
It feels like it has been stabilising a lot recently. And creating flixel is always going to be an evolutionary process, driven by personal requirements as well as external ones.

Right now it feels like it's at some kind of tipping point. As easy as it makes game dev, lots of areas are still quite voodoo, which means devs really do still need to be quite skilled in AS3 to take their game anywhere advanced. Yet we are seeing a regular influx of new devs here, all trying to do the same sorts of things.

This can partly be solved through documentation and tutorials, but only partly. Right now flixel IS Adam, and as a self-confessed control freak I can understand why talking about changes before making them can be hard :) But there is also a sort of civic responsibility involved now that it's getting the momentum it deserves.

It's that whole "with great power comes great responsibility" thing :)
http://www.photonstorm.com



"Tell me and I will forget, show me and I might remember, involve me and I will understand" - Confucius

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v3.0 planning thread
« Reply #26 on: Thu, Apr 14, 2011 »
yea, internally some stuff is still a bit of a mess. i think i have touched and improved the variable names and logic of every internal file in the whole library in the last month, but this again comes back to these things that all pull at each other from different directions:

1 - obvious need to simplify and clarify the code base

2 - obvious need for stability for the sake of documentation, community tutorials, and more

3 - obvious need for performance and constant improvement to keep up with changing tech and new insights into game development

Performance and simplicity rarely work together it seems like, and stability versus improvement are constantly at cross-purposes.  So no matter what happens, to fix things and keep flixel awesome(r), it means we have to change things (just not too many).

I will also continue to try and publicly announce months in advance any time there are planned changes.  the camera system for example is a pretty big change, but it was talked about for months beforehand.  some changes that seem pretty arbitrary are definitely for the better as well - for example things like shifting code from FlxU back to FlxG (after shifting it to FlxU months ago) were done to keep FlxU library-agnostic.

part of the goal for this update was to make flixel more modular, and i was not altogether successful at that yet.  FlxU was part of that, and knowing that molehill is coming up and integrating physics being interesting as well, i have been trying to prep for ways to wrap and include those things without causing yet more massive changes later this year.

HOWEVER, in general, for new versions of Flixel, if I HAVE to choose between keeping old code that isn't good, and replacing it with new good code, I'll always choose the latter.  If I have to choose between sticking with old, confusing names for variables and replacing them with useful new ones, I'll definitely opt for the latter.

But I will also make sure (like I did with 2.43b) to archive off and branch any popular, supported versions, so that those can kind of constantly be out there.

finally, if you compare my 2.5 wish list to my 3.0 wish list, the 2.5 wish list had some crazy big things in it, while the 3.0, with the exception of molehill, is basically small additions, rather than wholesale refactors.  Even if i add physics at this point, it will be an addition, not a replacement, since box collisions have stabilized a bit.

so yea, hope that helps these things make sense.  all this input and feedback helps me a ton, and i am looking forward to continuing to try and balance clarity, stability and improvements in the future :)  i'm sure flixel will never be "done" but i'm getting very, very satisfied with the architecture, and trivial name changes are a pain in the butt for me too, since it affects every example project i have (at least 8 now) :P

ONWARD!!

klembot

  • Member
  • **
  • Posts: 61
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #27 on: Fri, Apr 15, 2011 »
First of all Adam, I think what you're saying makes a lot of sense. Stuff's gotta get better and breaking things is inevitable. Design choices have to be made at some point, and I have a tremendous amount of respect for the work you've done.

Maybe I missed a post about this but I was never really clear on the delineation between FlxG and FlxU? (I assumed G = global, U = utility, but it seemed like a subtle distinction, especially when collision-related stuff lived there.) And so seeing stuff jump between the two had been kinda head-scratching, but if the idea is FlxU is platform-agnostic, that starts to put things into perspective.

The Flixel voodoo I've had to figure out, and I think would be worth clarifying in docs and/or code:

  • FlxSprite's render process, specifically how pixels, _framePixels and _ct work. I've also wanted to generate a sprite sheet dynamically but I wasn't clear how to plug that in.
  • FlxAnim internals. e.g. I wanted to alter the framerate of an animation on the fly, so that birds would flap their wings faster based on their speed.
  • What the heck collision hulls were :) This was clear with rectangular sprites but I was trying to hack FlxTilemap and it was scary territory. I know collisions have been overhauled in 2.5 but I haven't had a chance to look at that yet.

I'm just wondering, what would your comfort level be with forming a code cleanup patrol of interested folks?
I will never reveal the twofold secret.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v3.0 planning thread
« Reply #28 on: Fri, Apr 15, 2011 »
Hey klembot!  flxsprite and flxanim definitely both need some cleanup, i'll be working on that next week I think.  collisions were terrifying, and hulls have been removed entirely in favor of just auto-tracking the last X and Y position of the object, os hopefully that will be less nightmarish :)

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v3.0 planning thread
« Reply #29 on: Fri, Apr 22, 2011 »
updated the top post with my current "future builds" list from my local taskpaper, hopefully will give some insight into where things are at, what problems I see in 2.50 :)

abielins

  • Member
  • **
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #30 on: Thu, Apr 28, 2011 »
I made an auto-tiling sprite: https://github.com/windsurfer/ConvenientFlixel/blob/master/org/flixel/FlxTilingSprite.as

Not quite what you're looking for, but I did the modulo math already :P

Deviantgeek

  • Member
  • **
  • Posts: 63
  • Karma: +0/-0
  • Youngest flixel dev ever. Srsly.
    • View Profile
    • Devianix
Re: v3.0 planning thread
« Reply #31 on: Wed, May 4, 2011 »
Just found out about HaXe, and its really similar to AS3. If we made a HaXe port of flixel, we could to compile for practically every major language!

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v3.0 planning thread
« Reply #32 on: Wed, May 4, 2011 »
tru fax!  last i heard their bitmap support was not great, but if flixel ends up working well on molehill then haxe would probably be pretty trivial, which is awesome for sure

auriplane

  • Snails!!
  • Contributor
  • ****
  • Posts: 497
  • Karma: +1/-0
  • Snails!!
    • View Profile
Re: v3.0 planning thread
« Reply #33 on: Wed, May 4, 2011 »
About this:

- tilemap wrapping would still be neat, especially for backgrounds and stuff

You could have wrap behaviors.  Wrapping is one, return zeroes beyond edges is one, truncate to nearest edge is one.

To elaborate on that last one, if you request 20,-5 and the minimum y coord is 0, it returns the tile from 20,0.  The "mario pipe" someone was talking about in another thread?  You'd never be able to jump over it, and you don't have to extend the level just to keep them from doing it.

Well, I don't know if you even like this idea, but here's some cruddy code:

Code: [Select]
// in FlxTilemap

        public var getTile:Function = getTileNoWrap;
        public var setTile:Function = setTileNoWrap;
        private var _tileAccessBehavior:int = TILE_ACCESS_BEHAVIOR_NORMAL;
       
        public static const TILE_ACCESS_BEHAVIOR_NORMAL:int            = 0;
        public static const TILE_ACCESS_BEHAVIOR_WRAP:int              = 1;
        public static const TILE_ACCESS_BEHAVIOR_ZEROES_AFTER_EDGE:int = 2;
        public static const TILE_ACCESS_BEHAVIOR_REPEATING_EDGE:int    = 3;

public var _wrapCenterOffsetX:uint;
        public var _wrapCenterOffsetY:uint;

// In loadMap

            //Pre-calculate center of uint, truncated to nearest multiple of
            //width/heightInTiles, to allow easy modulus for wrapping getTile()
            //Note: this doesn't use FlxPoint, to avoid floating point
            _wrapCenterOffsetX = (uint.MAX_VALUE / 2) - (uint.MAX_VALUE / 2) % widthInTiles;
            _wrapCenterOffsetY = (uint.MAX_VALUE / 2) - (uint.MAX_VALUE / 2) % heightInTiles;

// at top-level, again

        public function get tileAccessBehavior():int
        {
            return _tileAccessBehavior;
        }
       
        public function set tileAccessBehavior(behavior:int):void
        {
            switch (behavior)
            {
                case TILE_ACCESS_BEHAVIOR_NORMAL:
                    getTile = getTileNoWrap;
                    setTile = setTileNoWrap;
                    break;
                   
                case TILE_ACCESS_BEHAVIOR_WRAP:
                    getTile = getTileWrap;
                    setTile = setTileWrap;
                    break;
                   
                case TILE_ACCESS_BEHAVIOR_ZEROES_AFTER_EDGE:
                    getTile = getTileZeroesAfterEdge;
                    setTile = setTileZeroesAfterEdge;
                    break;
                   
                case TILE_ACCESS_BEHAVIOR_REPEATING_EDGE:
                    getTile = getTileRepeatingEdge;
                    setTile = setTileRepeatingEdge;
                    break;
                   
                default:
                    throw new Error("Unknown tile access behavior: " + behavior.toString());
            }
           
            _tileAccessBehavior = behavior;
        }

        public function getTileNoWrap(X:uint,Y:uint):uint
{
    return getTileByIndex(Y * widthInTiles + X);
}
       
        public function getTileWrap(X:uint, Y:uint):uint
        {
            // Avoid problems from size of uint % modulus != 0, by moving each *near* the center of uint.
            // To work _wrapCenterOffsetX % widthInTiles == 0 should be true, and likewise for Y and height.
            // Will fail someday, if you move billions of tiles away, or if I made some basic math error :-)
            X = (X + _wrapCenterOffsetX) % widthInTiles;
            Y = (Y + _wrapCenterOffsetY) % heightInTiles;
            return getTileNoWrap(X, Y);
        }

        public function getTileZeroesAfterEdge(X:uint, Y:uint):uint
        {
            if (X < 0 || Y < 0 || X >= widthInTiles || Y >= heightInTiles)
                return 0;
           
            return getTileNoWrap(X, Y);
        }
       
        public function getTileRepeatingEdge(X:uint, Y:uint):uint
        {
            if (int(X) < 0)
                X = 0;
            else
            if (X > widthInTiles - 1)
                X = widthInTiles - 1;
               
            if (int(Y) < 0)
                Y = 0;
            else
            if (Y > heightInTiles - 1)
                Y = heightInTiles - 1;
           
            return getTileNoWrap(X, Y);
        }

        public function setTileZeroesAfterEdge(X:uint, Y:uint,Tile:uint,UpdateGraphics:Boolean=true):Boolean
        {
            // You can't change the zeroes, so this will always return false.
            if (X < 0 || Y < 0 || X >= widthInTiles || Y >= heightInTiles)
                return false;
           
            return setTileNoWrap(X,Y,Tile,UpdateGraphics);
        }

    public function setTileWrap(X:uint,Y:uint,Tile:uint,UpdateGraphics:Boolean=true):Boolean
{
            X = (X + _wrapCenterOffsetX) % widthInTiles;
            Y = (Y + _wrapCenterOffsetY) % heightInTiles;
           
    return setTileNoWrap(X,Y,Tile,UpdateGraphics);
}

public function setTileRepeatingEdge(X:uint,Y:uint,Tile:uint,UpdateGraphics:Boolean=true):Boolean
{
            if (int(X) < 0)
                X = 0;
            else
            if (X > widthInTiles - 1)
                X = widthInTiles - 1;
               
            if (int(Y) < 0)
                Y = 0;
            else
            if (Y > heightInTiles - 1)
                Y = heightInTiles - 1;
           
    return setTileNoWrap(X,Y,Tile,UpdateGraphics);
}

        public function setTileNoWrap(X:uint,Y:uint,Tile:uint,UpdateGraphics:Boolean=true):Boolean
{
    if((X >= widthInTiles) || (Y >= heightInTiles))
return false;
    return setTileByIndex(Y * widthInTiles + X,Tile,UpdateGraphics);
}


Seems to work okay for me, but I didn't test it much :-)  Defaults to the old behavior.

Adam Atomic

  • Founder
  • Key Contributor
  • *****
  • Posts: 852
  • Karma: +0/-0
  • new dad
    • View Profile
    • Adam Atomic
Re: v3.0 planning thread
« Reply #34 on: Wed, May 4, 2011 »
yea, clamp, wrap and edge-repeat or something would be really nice i think

initials

  • Contributor
  • ****
  • Posts: 378
  • Karma: +0/-0
  • Initials
    • View Profile
    • Initials Blog. Code and other things.
Re: v3.0 planning thread
« Reply #35 on: Wed, May 4, 2011 »
+1 for edge wrapping.

It would make "infinite levels" easier to do.
Initials: Super Lemonade Factory, Super Lemonade Factory Part Two, Above The Clouds, Revvolvver, Four Chambers of the Human Heart

goshki

  • Active Member
  • ***
  • Posts: 172
  • Karma: +0/-0
    • View Profile
    • Vigeo Games
Re: v3.0 planning thread
« Reply #36 on: Sun, May 8, 2011 »
tru fax!  last i heard their bitmap support was not great, but if flixel ends up working well on molehill then haxe would probably be pretty trivial, which is awesome for sure

There already is a Haxe port of Flixel: https://github.com/domrein/Flixel-Haxe but the last time I tried it, it had some functional problems and some features that Flixel is based upon are not easily portable to Haxe (at least if you plan writing a cross-platform Haxe code).

roboprez

  • Member
  • **
  • Posts: 13
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #37 on: Fri, May 13, 2011 »
Can flixel already do animated tiles in tilemaps?

SimonMarynissen

  • Member
  • **
  • Posts: 12
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #38 on: Thu, May 19, 2011 »
That would be very nice!

xraven13

  • Active Member
  • ***
  • Posts: 213
  • Karma: +0/-0
    • View Profile
    • GemaNeko
Re: v3.0 planning thread
« Reply #39 on: Fri, May 20, 2011 »
I think that we need something like FlxGroups, but for FlxSounds... So it would be easy to create different groups of sounds, and then pause them, change volume etc.

edit : I forgat to mention most important reason why this is needed. FlxSound's play is super slow because each time new instance of sound is created...
« Last Edit: Fri, May 20, 2011 by xraven13 »