Flixel Forums

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

Title: v3.0 planning thread
Post by: Adam Atomic on Fri, Apr 8, 2011
flixel v3.0: THE FUTURE IS OURS

Here is some stuff I have on my list of things that aren't making the cut for this beta:

- what about making camera rotation/scaling NOT be horrible?
   > involves nesting in a display object or whatever
   > if you DO fix this, update the documentation in FlxCamera
- RaySimplify is pretty horribly broken
   > probably because raycast just does point checks, and it should be doing line-vs-line checks
   > otherwise it can VERY easily hop over corners, even with a lot of points on the line
   > assuming that part of it is even working right
   > would be easy to test like from middle of screen to mouse, using a path?
- FlxTilemap doesn't support screenspace overlaps
- easing/tweening
   > steal from Chevy?
   > run as a plugin, like timers and path debug display?
- utility functions for exploring 2D arrays?
   > what about 1D arrays?  could be its own weird "iterator" type of class?¡
   > instantiated with an array, width, and height, and has neighbor getters, etc?
- vector math helpers to FlxU (see github)
- would be nice if watch() could parse the string better to allow stuff like "velocity.y"
- doubleclick support
   > tried this, but had annoying side effects on determinism/replays
   > can't remember why though, seems easy...
- improve flx.py (check email)
- mod/musagi/sfxr support?
   > this may have more cons than pros really
- tilemap wrapping would still be neat, especially for backgrounds and stuff
   > its not really THAT crazy either, just a lot of modulo stuff
- API for drawing primitives onto sprite surfaces
   > started (FlxSprite.drawLine) but very incomplete
- bitmap font support
   > ship flixel with custom fixed-width font
- molehill (whenever it gets good install base)
- physics?
Title: Re: v3.0 planning thread
Post by: Adam Atomic on Fri, Apr 8, 2011
we've also been fiddling with a kind of C/OpenGL/Python sort of setup for flixel, but probably there won't be a nice 1:1-ish relationship between OpenGL ports and flixel until I roll the graphics pipeline over to molehill later this year
Title: Re: v3.0 planning thread
Post by: Bennett on Fri, Apr 8, 2011
FWIW, I think it's very easy to make Box2DFlash work with Flixel as is, so I don't think you need to prioritize that one.
Title: Re: v3.0 planning thread
Post by: Adam Atomic on Fri, Apr 8, 2011
yea - oh that reminds me, I wanted to paste in my notes about Nape (a cool flash physics engine that Photonstorm introduced me to)

Quote
   - test tracing and re-tracing of tilemaps (for editing)
         > very easy to build a custom map by painting at 1x1 then zooming it up 8x or 16x
      - add a "Step" key to step-by-step check for cases where the physics are allowing the objects to intersect
      - try re-jiggering the demo to run at half res but scaled up (possibly by scaling the stage?)

      - be able to tell when you're on the floor
         > the platformer way to do this is to have two ground sensors, one on each side of the sprite
         > what about checking if you're on a wall, or if you just hit a wall?  that's useful callbacks...
         > averaging normals or checking for the occasional valid normal is NOT sufficient/safe/robust
         > what if instead of callbacks there were just readonly variables?
            > onWall, wasOnWall, onLeft, wasOnLeft, onFloor, wasOnFloor, etc?

      casting H rays from each side and V rays from top and bottom would yield easy normals
      and give some wiggle room on the floor and wall checks.  could even have a "bias" setting that controls how far beyond the bounding box the rays go... also would not require ANY callbacks, which is sort of crazy nice, since i have to use callbacks for the actual override stuff anyways.
      1 ray would just come out of the center, but 2+ would be spread across the side from edge to edge.
      if 2 or more, also set flags for whether each corner is "off" (no idea how to organize all that data yet)?
      
      ray casting notes ->
      results:rayResult = space.rayCast(new geom.Ray(Vec2,Vec2));
      results has a point and a normal, as well as a pointer to the PhysObj
      
      == NAPE INTEGRATION NOTES ==
   
      Ooooh man, I think I pretty much know how to pull this off now!!
   
      // HELPER FUNCTIONS: setupOverlap() and setupCollision()
      // setupOverlap would register senseBegin callbacks
      // binary ANDs IDs to each other so they will make it through the initial collision check
      // and use the bitmask/group filters as CbTypes for registering callbacks
      FlxU.setupOverlap(player,enemies,bumpedEnemy);
      FlxU.setupOverlap(player,bullets,gotShot);
      FlxU.setupOverlap(player,pickups,gotPickup);
   
      // so my objects would probably all default to collision group 1 if not solid, and sensor group 0
      // so probably groups should create their own collision ID, and pass it on to all their children
      // when objects are added, they take the group's ID, and when the group ID changes, update all children
   
      // bullets hitting walls would just disappear by using their internal onCollide(Normal) callback
      // players and enemies would collide with stuff flagged as solid automatically
      // could add additional collisions pretty easily, maybe like this ->
      FlxU.setupCollision(player,crates,callbackOptional);
   
      // This would mean that by default enemy bullets WOULD check against each other
      // So a "don't collide with self" flag probably makes a lot of sense
      // Stuffs everything in this Flixel group into a Nape group
      bullets.noInternalCollisions(); // or something like that
      // Might have to be done before objects are added, but that's ok I think
      // That would mainly be used for particles and stuff anyways I suppose?
   
      //Probably players or any sprites should be able to request a non-1 bitmask as well
      //so probably there will still be a FlxU function for that (that the group constructor utilizes too)
   
      solidFilter = 0xffffffffff; //collides with everything
   
      > probably want to capture Begin callbacks for everything against everything
      > only capture PostSolve for player and enemy types i think
      > this means sprites will have probably mmm 4 pre-sets?
         > actors like players, enemies, bosses, etc (always awake, check for onFloor, etc)
         > objects like crates
         > static/kinematic objects like platforms or elevators (can move)
         > particles
      > tileblocks, tilemaps etc will be static types

      NOTES ON ASTEROIDS TYPE MOVEMENT
      > have to manually rotate the force on the object
      > can require a LOT of force to move an object around
      > obviously want to set gravity to zero and set the linear damping properties of objects (air resistance)

      NOTES ON ELEVATORS
      > elevators are easiest as "kinematic" objects (NOT static objects)
      > you have to update their position manually, and reverse-calculate their velocity
      > you have to at LEAST call stopMovement() if not stopAll() AFTER adding it to the space
      > should be able to move nicely along paths I think
      > when exposing to user, should be treated as if "static", and obfuscate the new movement rules I think

      NOTES ON CONVEYOR BELTS
      > very similar to elevators, except you don't update their position
      > just set their velocity to the velocity you want the belt to have

      SLOPE NOTES
      > it's not TOO hard to just sum up all the floor-like touches into a safe-ish guess at the surface angle
      > THEN it's very easy to change the player's speed based on that, to get nice, slope-actuated motion
      > ideally we'll expose that angle through the API, but also enable some simple "auto" behavior
         that scales motion similar to how its being done in napetest

      > snapping generated geometry to integer doesn't seem to help with collision bugs much
      > does keep things a litlte cleaner in some ways though

At this point I am not really prioritizing it as much as I was, especially since my retro collisions got marginally less sucky, and its easier to write your own handlers now, AND flixel is on a fixed timestep now.
Title: Re: v3.0 planning thread
Post by: PaulGene on Fri, Apr 8, 2011
Id move Molehill to the top of the list, you will end up having to redo a load of the things you are currently adding if you do it last. And I recommend NAPE for physics.

haha we must have pressed save post at exactly the same time there! NAPE is fantastic...
Title: Re: v3.0 planning thread
Post by: axcho on Fri, Apr 8, 2011
I've been working on a seamless Box2D integration with Flixel, but after finding out about Nape a few months ago, I've also decided to try for Nape integration as well.

Adam, if you want to postpone your own Nape integration, I'd be happy to step up for that.
Title: Re: v3.0 planning thread
Post by: xraven13 on Fri, Apr 8, 2011
Eh, if Flixel would be component based it would be so easy to change stuff... It would be great if you would think about it...  ;D

Otherwise really nice work, I didn't actually expect anymore updates, so this is quite surprise that you maintain this project so long.

Because of Flixel, I learned OOP, and made few games, who knows would it be the same that there wasn't Flixel, so thanks a lot..:)
Title: Re: v3.0 planning thread
Post by: Ace20 on Fri, Apr 8, 2011
There's one feature I'd love to see more than any other: Slopes.

I really like the simplicity of Flixel's "physics" engine (I'm not a big fan of the realistic simulations like Box2D), but I think if it supported slope/shape collisions it'd open up possibilities for so many more kinds of games. There's only so much you can do with rectangles alone...
Title: Re: v3.0 planning thread
Post by: krix on Fri, Apr 8, 2011
+1 for slopes
Title: Re: v3.0 planning thread
Post by: superdeformed on Sat, Apr 9, 2011
another +1 for slopes. 
Title: Re: v3.0 planning thread
Post by: Deviantgeek on Sat, Apr 9, 2011
+1 for slopes, and circles!
Title: Re: v3.0 planning thread
Post by: initials on Sat, Apr 9, 2011
+1 for slopes.
I know there's a tutorial out there already for how to do it, but native Flixel slopes seems to be popular, and it's definitely a cool thing to have.
Also sfxr support would be fantastic.
Title: Re: v3.0 planning thread
Post by: roboprez on Sun, Apr 10, 2011
+1 for slopes again  ;)

I thought that Molehill was 3d acceleration. Will it really improve performance of  the 2d stuff?

Also an inbuilt tweening function like TweenLite would be nice
Title: Re: v3.0 planning thread
Post by: Geti on Sun, Apr 10, 2011
Slopes would be great, but if you do that you may as well just be using NAPE or something similar anyway.

I've been pondering some ways of linking the retro collisions and slopes in some way because hitboxes are sufficient for almost everything, but there's the odd issues like "where should a hitbox collide with the slope? at the corner? because that means you need to do odd proxy corners where slopes meet squares again"... I suppose that's why it's so far back on the list.

NAPE integration would be pretty sweet, but I'm concerned about the overhead of such a library for smaller less physics-heavy more graphics-heavy games where all you need/want is hitboxes so you can spend more CPU juice on rendering.

I'd love something that simply extended the current flixel solution but had the ability to compare slopes with quads in some reasonable way, especially if that solution applied the rotation code to rotated flxobjects.


Flashpunk's tweens etc are pretty sweet as far as tweens go btw, and easy as all hell to implement.
Title: Re: v3.0 planning thread
Post by: Adam Atomic on Sun, Apr 10, 2011
Geti hit pretty much all of that right on the nose.  Slopes will probably not be officially supported in flixel UNLESS it's via NAPE or something similar.  Since I was able to somewhat stabilize my box collisions, I'm now confronted with the possibility or need to try and keep that system AND somehow add physics support, which is sort of intimidating.

HOWEVER, if you want to do slopes, there are a FEW things you can do to implement them yourself (and then maybe share with the community):

1 - modify or make your own separation/processing function, and run your own calls to FlxState.overlap() instead of FlxState.collide.  Could possibly extend the FlxTile object to include slope information as well.

2 - tilemaps support callbacks again, so you might be able to do some cool slope behavior in there too, but making a new function to run FlxState.overlap() on is a lot more promising I think.

Hopefully by the end of the year we won't really have to spend CPU on rendering, that will all be on the GPU?  We'll see I guess.

Easing/tweens would be really nice, especially with the new path stuff, and I agree, they should be easy to implement.
Title: Re: v3.0 planning thread
Post by: Adam Atomic on Sun, Apr 10, 2011
I definitely want to emphasize that really for ANY custom collisions, you can just do your own overlap() callbacks.  If you look in FlxState at how overlap() and collide() work, its just instantiating a quad tree, and then passing it a couple callbacks.  The callbacks that FlxState.collide() uses are FlxObject.separate(), FlxObject.SeparateX(), and FlxObject.SeparateY().  You can steal that stuff and just extend it or rewrite it to have the behavior that you really want it to have pretty easily.

For example, if you were writing a game that didn't use any boxes at all, and only used circles (like Osmos or something) then it would be a pretty simple thing to write your own circle-based separator, and run FlxState.overlap() with THAT callback, instead of FlxObject.separate.

So none of that stuff is built in, BUT hopefully this way of organizing will mean that the community can write their own custom separators, and share them, and people can include them in their projects more easily!
Title: Re: v3.0 planning thread
Post by: Geti on Sun, Apr 10, 2011
Oh wow, I haven't looked into the new code yet so that's excellent to hear.
Fingers crossed that I can find more time for coding this week and maybe mock up some different collision functions.
Title: Re: v3.0 planning thread
Post by: increpare on Tue, Apr 12, 2011
- mod/musagi/sfxr support?
I'm not really convinced as to the worth of explicitly supporting this sort of stuff.  Here's my deliberation process in bullet-point form:

1: it takes about as long to download sounds as to generate them
2: requires special treatment of sounds
3: the Sfxr API is pretty monolithic as is, and doesn't need any work to tack on (okay it needs a little to pull out the relevant code, but I made a stand-alone packaging of the bfxr api, though that's not as feature-full as tom vian's).  
4: Playing, even precached, sounds with Sfxr is going to be way more intensive than letting the sound API do its thing by itself (I think.  I haven't benchmarked, though).
5: I imagine doing whole music tracks would be more intensive still.
6: really really really really slow in debug mode. (Not as much of a problem if generating async, admittedly)

On the plus side

1: keeps size down (not that it's going to be much of an issue for sound effects, but for music tracks it would surely be).
2: ability to easily generate lots of mutations, alter sounds on the fly, would save a lot of games from audio-drabness.
3: ability to paste sounds directly into source code, saves faffing about with filesystems.
4: it wouldn't be at all hard to just toss it in and include it, and new people who mightn't otherwise be able to figure out how to use it might appreciate that.
Title: Re: v3.0 planning thread
Post by: photonstorm 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 ;)
Title: Re: v3.0 planning thread
Post by: photonstorm on Tue, Apr 12, 2011
I think one of the biggest benefits flixel could have (beyond Molehill, which is a pretty vital move come 2012) would be to create a standard plugin system for it. So it can be easily extended by 3rd parties, and provide plenty of hooks deep into it, so they can really prod about and make it do things even you never thought of!

Oh and sort out the sound handler. You should be able to create new sound groups (ambient, ui, fx, music) and assign sounds to them and control their group properties individually.

Umm and finally, the most boring of all - really tidy-up the internals :) There is lots of "magic" going on in places, and some really lazy variable names :) It could all just be a lot cleaner in places! This isn't fun though, and I appreciate the need to do fun tasks on personal projects like this!
Title: Re: v3.0 planning thread
Post by: increpare 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.
Title: Re: v3.0 planning thread
Post by: Billy 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...
Title: Re: v3.0 planning thread
Post by: klembot 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?
Title: Re: v3.0 planning thread
Post by: axcho 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.
Title: Re: v3.0 planning thread
Post by: Adam Atomic 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
Title: Re: v3.0 planning thread
Post by: photonstorm 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 :)
Title: Re: v3.0 planning thread
Post by: Adam Atomic 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!!
Title: Re: v3.0 planning thread
Post by: klembot 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:


I'm just wondering, what would your comfort level be with forming a code cleanup patrol of interested folks?
Title: Re: v3.0 planning thread
Post by: Adam Atomic 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 :)
Title: Re: v3.0 planning thread
Post by: Adam Atomic 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 :)
Title: Re: v3.0 planning thread
Post by: abielins 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
Title: Re: v3.0 planning thread
Post by: Deviantgeek 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!
Title: Re: v3.0 planning thread
Post by: Adam Atomic 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
Title: Re: v3.0 planning thread
Post by: auriplane 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.
Title: Re: v3.0 planning thread
Post by: Adam Atomic on Wed, May 4, 2011
yea, clamp, wrap and edge-repeat or something would be really nice i think
Title: Re: v3.0 planning thread
Post by: initials on Wed, May 4, 2011
+1 for edge wrapping.

It would make "infinite levels" easier to do.
Title: Re: v3.0 planning thread
Post by: goshki 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).
Title: Re: v3.0 planning thread
Post by: roboprez on Fri, May 13, 2011
Can flixel already do animated tiles in tilemaps?
Title: Re: v3.0 planning thread
Post by: SimonMarynissen on Thu, May 19, 2011
That would be very nice!
Title: Re: v3.0 planning thread
Post by: xraven13 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...
Title: Re: v3.0 planning thread
Post by: danmilward on Mon, Jul 4, 2011
What about the GPU acceleration stuff here: http://www.willemrenevanvliet.nl/?page_id=198
Title: Re: v3.0 planning thread
Post by: alejoamiras on Tue, Jul 12, 2011
Hey Adam, what have you thought about adding the method to change the point of rotation to the FlxObjects--->FlxSprites in v3.0?

I really need that to my new Flixel Game lol (anyway I solved it resizing the image but it really sucks ! haha) !!!

And I Think it can be really usefull ! :D:D

So, let us know what else is the very best API of all internet its gonna have :D !!!

Congratz on ur work done .

EDIT: And what about creating ComboBoxes and Radiobuttons ? - I think we can not do that yet -
Title: Re: v3.0 planning thread
Post by: zuperxtreme on Fri, Aug 12, 2011
Isn't the offset the "point of rotation"?

Title: Re: v3.0 planning thread
Post by: John Hutchinson (Johntron247) on Fri, Aug 12, 2011
What about the GPU acceleration stuff here: http://www.willemrenevanvliet.nl/?page_id=198

Seconded!  Those of use trying to use flixel to do anything worthwhile on mobile devices are seriously working against the grain.   I'm still loving it... just saying that flixel + mobile, as it is now, leaves a lot to be desired.
Title: Re: v3.0 planning thread
Post by: Bennett on Mon, Aug 15, 2011
I'm using NAPE with Flixel on my new project, and I just want to say it's really really good, however:

1. The NAPE codebase won't be finished or stable for a while given that it's undergoing a major rewrite.
2. Since NAPE is written in HaXE and imported into the flex project as a compiled swc, I think proper integration would be really messy.
3. It is so easy to use with Flixel that it's hardly worth integrating it into the flixel codebase.

I think the same thing goes for tweening: TweenLite works just fine with Flixel.

The changes I'd like to see in 3.0 relate to Flixel being a better Flixel, rather than adding big new features.
- Molehill, so we can make games with significant amounts of rotation
- More algorithmic design tools: a revamped FlxTileBlock that handles edges and corners, for example.
- Support for bitmap fonts
- Per-frame hitboxes
- Complete switch to handling sprites with their anchor at the center would make physics-integration much easier.

And one gripe: I always wind up having to change _curFrame and _curAnim to public vars. Giving the user some way to read the current animation & frame is nice if you want to chain animations together from outside the class.

Oh and make it so you can set visibility of sprites per-camera.
Title: Re: v3.0 planning thread
Post by: photonstorm on Mon, Aug 15, 2011
I love Nape and its speed, but I'm not convinced it's a good match for Flixel core - mostly for the reasons listed above. I also think that for a lot of flixel games they just don't need advanced physics, and those that do can integrate it. My concern would be getting it to work seamlessly with FlxTilemap for example.

I would much rather see Flixel 3 support a significantly more advanced Tilemap system. I want curves, slopes, ramps, etc. Also things that are important to lots of games like CCD for high speed bullets, per-frame pixel perfect collision (including separation) and definitely different target renderers (molehill, air3).

None of them small or simple :)
Title: Re: v3.0 planning thread
Post by: Wiering on Thu, Aug 25, 2011
Code: [Select]
// in FlxTilemap
...
        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;

It's far more flexible if you allow separate behavior for X and Y.

Another one that I often use would be TILE_ACCESS_BEHAVIOR_MIRROR, where every other copy of the map is mirrored.
This should have the option to also mirror the tiles or not.
Title: Re: v3.0 planning thread
Post by: c023-DeV on Thu, Sep 1, 2011
... things that are important to lots of games like CCD for high speed bullets...

Aaah, so the "tunneling" I am experiencing wit the Weapons would be reduced?! Yeah, Im currently working around that by offseting the game and flash framerates, hrhrh, works somehow and gives me some fast bullets but no ultra speed =D

Oh, yeah I'm in for the Molehill GPU accellerations and stuff but want to also clearly say no to 3D or fancy stuff... Flixel is Flixel and shall stay Flixel, you know what I mean, luvin the Fixels =D
Title: Re: v3.0 planning thread
Post by: John Hutchinson (Johntron247) on Wed, Sep 7, 2011
The ability to load an external image file into a Class object would be REALLY handy!  That way we can dynamically load sprites and tilesets without too much trouble.

I'm doing that now and it's a real pain the way it's currently set up because both the sprites and function to load maps only accept a Class.
Title: Re: v3.0 planning thread
Post by: KWarp on Wed, Sep 21, 2011
Looks like molehill is coming around next month:
http://www.macrumors.com/2011/09/21/adobe-targets-3d-gaming-with-flash-player-11-and-air-3/ (http://www.macrumors.com/2011/09/21/adobe-targets-3d-gaming-with-flash-player-11-and-air-3/)
Title: Re: v3.0 planning thread
Post by: Cadwallader on Wed, Oct 5, 2011
FlxTilemap's ray() really need some fixing! It's jumping through a lot of corners!
Title: Re: v3.0 planning thread
Post by: producerism on Fri, Oct 7, 2011
a lot of flixel games they just don't need advanced physics, and those that do can integrate it....

... I want curves, slopes, ramps, etc. Also things that are important to lots of games like CCD for high speed bullets...

Unless I'm misunderstanding, it seems that the integration of a physics engine like NAPE would directly address the requests for curves/slopes/ramps/etc.  I realize the context was regarding tilemaps, but couldn't each tile have an optional { shape: [#,#,#,#] } property to be used for physics?

I know, I know, easier said than done!  However, as others have mentioned about MoleHill integration, the sooner the better, because adding all the features that come along with it will make some of the previously added features redundant or obsolete.  It seems this is the same case with NAPE.  If lots of time is put into improving the existing "physics" engine, isn't a good portion of that time wasted when a proper physics engine is implemented?
Title: Re: v3.0 planning thread
Post by: Vania on Thu, Dec 1, 2011
I dont think it's a good idea to keep adding stuff to the core indefinitely, it's going to become a monster.

The priority now should be to add ways of extending the core dynamically.
Plugins are very simple yet some people like Photonstorm are already doing great things with it, imagine what this awesome community would do if given more power!
Something like components for adding functionality to game objects and making it easier to share and reuse our code...
Title: Re: v3.0 planning thread
Post by: initials on Wed, Dec 7, 2011
I'm using NAPE with Flixel on my new project, and I just want to say it's really really good, however:

Do you have a sample project of this? I can't get NAPE to run with Flixel.
Title: Re: v3.0 planning thread
Post by: Vania on Fri, Dec 16, 2011
Another cool thing would be parenting.
Being able to add children to objects like in Unity3D,
that would mean using transform matrices instead of x, y, angle.
Title: Re: v3.0 planning thread
Post by: foosety on Mon, Dec 19, 2011
I would much rather see Flixel 3 support a significantly more advanced Tilemap system. I want curves, slopes, ramps, etc. Also things that are important to lots of games like CCD for high speed bullets, per-frame pixel perfect collision (including separation) and definitely different target renderers (molehill, air3).


 + 1 for this
Title: Re: v3.0 planning thread
Post by: test84 on Mon, Dec 19, 2011
1- I think iOS development should be more possible, I have no idea how but people at Stencyl are doing it somehow.
2- I had a lot of problems making a shotgun for flixel, apparently the quad tree has problems with collision detection of small objects that are next to each other.
Title: Re: v3.0 planning thread
Post by: pixelomatic on Mon, Dec 19, 2011
1- I think iOS development should be more possible, I have no idea how but people at Stencyl are doing it somehow.
2- I had a lot of problems making a shotgun for flixel, apparently the quad tree has problems with collision detection of small objects that are next to each other.

That:
Quote
The reason for the simultaneous timing is that, under the hood, we’re working on a brand-new engine that will let all Stencyl games share a common codebase, work consistently on each platform, and be exported in the platform’s “native” code, whether it be Objective-C, Java or JavaScript.
Taken from: http://blog.stencyl.com/?p=448

I believe, conversion between as3 and Objective-C is needed for that purpose.
Title: Re: v3.0 planning thread
Post by: test84 on Mon, Dec 19, 2011
That:Taken from: http://blog.stencyl.com/?p=448

I believe, conversion between as3 and Objective-C is needed for that purpose.

I don't know if you are aware or not but there is a iOS port of flixel that Adam used/wrote for Canabalt and some other unannounced game but the development is not maintained much, our very own initials can talk to you days about how hard it is to work on it when there is no one there beside you.

I think it should get a kick and people will follow afterwards.
Title: Re: v3.0 planning thread
Post by: initials on Mon, Dec 19, 2011
I don't know if you are aware or not but there is a iOS port of flixel that Adam used/wrote for Canabalt and some other unannounced game but the development is not maintained much, our very own initials can talk to you days about how hard it is to work on it when there is no one there beside you.

I think it should get a kick and people will follow afterwards.

I think there is a pretty high barrier to iOS development which is keeping people out.
I'd love it if more people joined in on the iOS side but the equipment is expensive.
Title: Re: v3.0 planning thread
Post by: test84 on Mon, Dec 19, 2011
I think there is a pretty high barrier to iOS development which is keeping people out.
I'd love it if more people joined in on the iOS side but the equipment is expensive.

I can manage to borrow devices if it was for a limited time but I don't think that would suffice.

I'm really thinking about iOS/Android after my current game and really would love to do it with flixel by coming to that lonely little place of this forum that apparently there is only you! Because I will probably make another platformer and don't want to see all these experience with flixel waste away but it seems flixel and iOS are not taht good together, as you know way better than me.

I'm getting off-topic here but I'm wondering how Adam manages to use flixel for iOS when it's hard for like everyone else.
Title: Re: v3.0 planning thread
Post by: zaphod on Mon, Dec 19, 2011
I'm really thinking about iOS/Android after my current game and really would love to do it with flixel by coming to that lonely little place of this forum that apparently there is only you! Because I will probably make another platformer and don't want to see all these experience with flixel waste away but it seems flixel and iOS are not taht good together, as you know way better than me.

I'm sorry for intruding this thread but I want to present my port of flixel v2.55 to haxe which works on flash, iOS and Android (and native Windows, Mac and Linux app). I think that it might interest you because haxe's syntax is very similar to actionscript and thus it's easy to develop crossplatform 2d games with it.
Project repository can be found here: https://github.com/Beeblerox/HaxeFlixel
Compiled version of Mode demo (windows only) can be downloaded here: https://github.com/downloads/Beeblerox/HaxeFlixel/ModeDemo20122011.zip
Title: Re: v3.0 planning thread
Post by: John Hutchinson (Johntron247) on Tue, Dec 20, 2011
I'm sorry for intruding this thread but I want to present my port of flixel v2.55 to haxe which works on flash, iOS and Android (and native Windows, Mac and Linux app). I think that it might interest you because haxe's syntax is very similar to actionscript and thus it's easy to develop crossplatform 2d games with it.
Project repository can be found here: https://github.com/Beeblerox/HaxeFlixel
Compiled version of Mode demo (windows only) can be downloaded here: https://github.com/downloads/Beeblerox/HaxeFlixel/ModeDemo20122011.zip

I've been hoping someone would do this!  I don't have time to check it out just now but you totally made my night.
Title: Re: v3.0 planning thread
Post by: axcho on Fri, Dec 23, 2011
I've been hoping someone would do this!  I don't have time to check it out just now but you totally made my night.

My thoughts exactly. :)

Thanks for the haXe port! That's a big deal - have you tried compiling to iOS yet?
Title: Re: v3.0 planning thread
Post by: John Hutchinson (Johntron247) on Fri, Dec 23, 2011
That's what I'm wondering as well.  I haven't had time to do this myself, and probably won't for a while.  I'm still very curious though
Title: Re: v3.0 planning thread
Post by: zaphod on Fri, Dec 23, 2011
Thanks for the haXe port! That's a big deal - have you tried compiling to iOS yet?

Unfortunately I haven't Mac or iPhone. But I will ask somebody to compile it and report here when it will be done.
Title: Re: v3.0 planning thread
Post by: xhunterko on Mon, Jan 30, 2012
Handling Z order and Z rotation. Along with rotateXY support for FlxSprite.
(I think I'm using those terms correctly.)
Title: Re: v3.0 planning thread
Post by: test84 on Thu, Feb 23, 2012
Is there going to be a v3?
Title: Re: v3.0 planning thread
Post by: Reptangle on Mon, Feb 27, 2012
zaphod, thanks for the port! :)

However, in Mode Demo.exe, all I see for graphics is white squares, except the enemies, bullets and some background tiles. Any idea why?
Title: Re: v3.0 planning thread
Post by: test84 on Mon, Feb 27, 2012
zaphod, thanks for the port! :)

However, in Mode Demo.exe, all I see for graphics is white squares, except the enemies, bullets and some background tiles. Any idea why?

It's not hard or strange, in the constructor you set the bounding box how you like it to be. Default is to bound the smallest box it can around the image by the size you apply in constructor but later on you use height and width to adjust it and you even have offset.x and .y for fine tuning it.

Unfortunately I haven't Mac or iPhone. But I will ask somebody to compile it and report here when it will be done.

Looking forward to hear and see about it!
Title: Re: v3.0 planning thread
Post by: goshki on Sun, Mar 18, 2012
Unfortunately I haven't Mac or iPhone. But I will ask somebody to compile it and report here when it will be done.

I've managed to run the Haxe port (Mode demo) on Android on Nokia N900 (NITDroid).

(http://i.imgur.com/O2QFo.jpg)

Unfortunately it runs very slowly and sound is not working. But I haven't looked much into it so I don't know what potential improvements can be made (debris emitters are one sure source of slowdowns).
Title: Re: v3.0 planning thread
Post by: twothreetwo on Tue, May 15, 2012
Off the top of my head there are two things that I'd love to see:

1/ Updatable boundary boxes (used for rotating sprite collision detection).
2/ It's minor but the sprite "angle" shouldn't be tied to it's rotation. I.e. setting angle shouldn't rotate the sprite, a new var called "rotation" should do that. Makes life a little more confusing when adding physics as angle can refer to a whole host of things.
Title: Re: v3.0 planning thread
Post by: Greed on Thu, Jan 24, 2013
There's any news regarding flixel v3 ?
Title: Re: v3.0 planning thread
Post by: Gama11 on Wed, Jan 30, 2013
There's any news regarding flixel v3 ?

I don't think so. :(

There's the flixel-community repo (https://github.com/FlixelCommunity) on GitHub though, which seems promising. Here's a forum thread (http://forums.flixel.org/index.php/topic,6673.0.html) about it.
Title: Re: v3.0 planning thread
Post by: Greed on Wed, Jan 30, 2013
Oh! Thank you @gama11 !

I don't know how i havent seen this before xD

But, yeah, i has hoing for stage 3D ;-;

Anyway thank s for the light, and i 'll continue to check these updates!
Title: Re: v3.0 planning thread
Post by: CrazySam on Tue, Mar 12, 2013
Quote
I'm getting off-topic here but I'm wondering how Adam manages to use flixel for iOS when it's hard for like everyone else.

Adam did a port of Flixel to ObjectiveC, from scratch. My guess is that he ported only the critical code he needed to get Canabalt and subsequent games working on iOS, so he doesn't want to release the code because it doesn't have feature parity with flash Flixel. Or maybe he doesn't want Flixel users to flood the iOS market with low quality ports, cause he knows the iOS market has a big problem with discoverability and flooding the market with Flash game ports would only make it worst.

I've been using HaxeFlixel (http://haxeflixel.com/) for a while now though, and I can't recommend it enough for mobile and desktop 2D game development. It's true that Haxe isn't as user friendly as Actionscript, and that NME has some issues (notably, horrible sound support on Android), but I've been blown away by Zaphod's efforts to optimize HaxeFlixel, as well as the contributions that key members have been making to the engine. We have all of photonstoms plugins as well as new classes and features added by the community.

Because HaxeFlixel (http://haxeflixel.com/) has distanced itself from Adam's "official" Flixel codebase, we are free to grow and evolve, and make important changes to the engine in order to boost performance and make it friendlier for mobile development.

I'm not one of those people that say "Flash is dead", but there's no arguing that the market for Flash games is no longer growing, and most Flash game companies are jumping ship to mobile or HTML5. My advice is to ride that wave and move on to another framework. But if you really love Flixel like I do, and want to continue using it, join the HaxeFlixel (http://haxeflixel.com/) community, and come discover what Haxe is all about.

Just make sure  read the HaxeFlixel docs (http://haxeflixel.com/docs) and spend some time familiarizing yourself with the Haxe + NME (http://www.nme.io/developer/documentation/getting-started/) workflow, before going to the HaxeFlixel forums (http://haxeflixel.com/forum/) for help.
Title: Re: v3.0 planning thread
Post by: paala on Wed, Mar 13, 2013
Hey, Canabalt is open source in I OS.
And your post is kind of advertising of Haxe...
Personally I saw a flixel game made with adobe air that runs super smooth on my 75$ tablet.
So why use Haxe when Adobe air does a pretty good job?
Title: Re: v3.0 planning thread
Post by: Charlie Riot on Thu, Mar 14, 2013
Quote
So why use Haxe when Adobe air does a pretty good job?

You just answered your own question. "Pretty good" is not necessarily something developers strive for.

–That being said, I'm personally sticking with Flash Flixel for a while. The support is brilliant, and my only issues with it are performance-related, though even those could be inefficient code on my part. The way I see it, both Haxe Flixel and Flash Flixel are downright amazing, but one feels like an evolution of the other.