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

Adam Atomic

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

Bennett

  • Member
  • **
  • Posts: 29
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #2 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.

Adam Atomic

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

PaulGene

  • Member
  • **
  • Posts: 83
  • Karma: +0/-0
    • View Profile
    • PaulGenehompson
Re: v3.0 planning thread
« Reply #4 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...

axcho

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

xraven13

  • Active Member
  • ***
  • Posts: 213
  • Karma: +0/-0
    • View Profile
    • GemaNeko
Re: v3.0 planning thread
« Reply #6 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..:)

Ace20

  • Member
  • **
  • Posts: 22
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #7 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...
FOR ZE GERMANZ

krix

  • Member
  • **
  • Posts: 61
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #8 on: Fri, Apr 8, 2011 »
+1 for slopes

superdeformed

  • New Member
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #9 on: Sat, Apr 9, 2011 »
another +1 for slopes. 

Deviantgeek

  • Member
  • **
  • Posts: 63
  • Karma: +0/-0
  • Youngest flixel dev ever. Srsly.
    • View Profile
    • Devianix
Re: v3.0 planning thread
« Reply #10 on: Sat, Apr 9, 2011 »
+1 for slopes, and circles!

initials

  • Contributor
  • ****
  • Posts: 378
  • Karma: +0/-0
  • Initials
    • View Profile
    • Initials Blog. Code and other things.
Re: v3.0 planning thread
« Reply #11 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.
Initials: Super Lemonade Factory, Super Lemonade Factory Part Two, Above The Clouds, Revvolvver, Four Chambers of the Human Heart

roboprez

  • Member
  • **
  • Posts: 13
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #12 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

Geti

  • Active Member
  • ***
  • Posts: 143
  • Karma: +0/-0
    • View Profile
    • 1 Bar Design
Re: v3.0 planning thread
« Reply #13 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.

Adam Atomic

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

Adam Atomic

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

Geti

  • Active Member
  • ***
  • Posts: 143
  • Karma: +0/-0
    • View Profile
    • 1 Bar Design
Re: v3.0 planning thread
« Reply #16 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.

increpare

  • Member
  • **
  • Posts: 42
  • Karma: +0/-0
    • View Profile
Re: v3.0 planning thread
« Reply #17 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.
« Last Edit: Tue, Apr 12, 2011 by increpare »

photonstorm

  • Administrator
  • Key Contributor
  • *****
  • Posts: 1502
  • Karma: +1/-0
    • View Profile
    • Photon Storm
Re: v3.0 planning thread
« Reply #18 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 ;)
http://www.photonstorm.com



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

photonstorm

  • Administrator
  • Key Contributor
  • *****
  • Posts: 1502
  • Karma: +1/-0
    • View Profile
    • Photon Storm
Re: v3.0 planning thread
« Reply #19 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!
http://www.photonstorm.com



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