Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Adam Atomic

Pages: [1] 2 3 ... 43
1
releases / Re: Current state of particles and emitters
« on: Wed, May 11, 2011 »
hey tackle!  you've got the right idea.  I would say you have two options, both of which are fairly easy, but the main differentiator is PERFORMANCE.  If you need like... more than 500 particles, collision is not important, and you are doing a lot of visual processing (rotation, alpha, etc) then I think making your own emitter is probablyt he right idea.  I suspect you could extend FlxEmitter and just ignore the fact that its a group, and repurpose the start/stop functionality, and do your own rendering.

If performance isn't a big deal, and you just want more interesting particle behavior (like wiggling around, changing direction, scaling, etc) then just extend FlxParticle.  You can even set the default particle class of the emitter before calling makeParticles() in order to easily substitute in your custom class.

hope that helps!

2
releases / Re: FlxShaderCamera
« on: Fri, May 6, 2011 »
for performance you might want to do FlxG.resetCameras() instead of addCamera(), otherwise you might be drawing everything twice - looks rad though!

3
releases / Re: v3.0 planning thread
« on: Wed, May 4, 2011 »
yea, clamp, wrap and edge-repeat or something would be really nice i think

4
releases / Re: v3.0 planning thread
« 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

5
releases / Re: Fix for reversed images in the cache
« on: Wed, May 4, 2011 »
yea i added a reverse flag for the key that should have helped with that...

6
help / Re: Hit test for close but non-touching objects
« on: Tue, May 3, 2011 »
there's also a new fucntion int he latest beta called overlapAt() that might be helpful!

7
help / Re: Flixel 2.50 & Pausing
« on: Tue, May 3, 2011 »
yea pausing is up to you now - the trick with pausing is that unless you are doing a very very specific pause behavior, like you just want a custom "lost focus" screen, anything i built in as automatic behavior is going to be too limited.  If music automatically stops, what about games that want music to keep going?  what if you want to pause but to pull up an inventory screen instead?

my best recommendation is to make your own pause screen by extending flxgroup to make the kind of pause screen that YOU want to use in most of your projects.  then you can just include it or copy-paste it in, and have behavior that you have a lot of control over

8
releases / Re: v2.50 demo activity
« on: Tue, May 3, 2011 »
cool, good catch - i missed a closing quote in the html :)

9
releases / Re: v2.50 demo activity
« on: Tue, May 3, 2011 »
This is so rad you guys!!  I went through and rewrote a lot of the features page text to include links to documentation, and updated the checklist:


10
k should be good to go

11
help / Re: Camera/Tilemap Rotation
« on: Mon, May 2, 2011 »
ok, the beta branch has WAY better rotation and scaling options for cameras, have fun!!

12
releases / Re: v2.50 demo activity
« on: Mon, May 2, 2011 »
coming along really nicely!  i replied to your thread in help, i hope it... helps :)

13
help / Re: Camera/Tilemap Rotation
« on: Mon, May 2, 2011 »
without too much pain/suffering i think you could extend flxtilemap to be able to do rotation in a cool way.  the thing about the tilemaps is they render themselves to a buffer, so they're not doing a bunch of unnecessary drawing, etc.  but you could extend flxtilemap to have different behavior and still have decent performance i think.

if i was going to do this, my approach would go something like:

  • extend flxtilemap and have it create a buffer that is twice the size of the screen, instead of same size
  • update the "dirty" check in .draw() to make sense with the rotation stuff
  • rig up some new follow behavior to make sure the origin of theflxtilemap buffer is always at the player center

HOWEVER this would mean that any items in the world that weren't part of the tilemap would have to be rotated around separately, whcih could be quite CPU intensive, depending.

what i suspect you want is essentially to not really move ANYthing around, nor rotate the tilemap, but simply rotate the display of the world so that the player is always facing up, or something like that.  eventually this will be pretty easy to do with the camera system, you'll just have to create a pretty large camera buffer so it can rotate safely, and the player sprite might alias or blur a little unless you specifically render the player in his own special camera or something.

however, currently the camera system rotation and scaling just uses the native flash style, which means that for the camera to rotate and scale properly it needs to be couched in an extra display object so that flash can handle that offset.  this is actually pretty easy, and it's at the very top of my to-do list, but it just hasn't happened yet.  since it won't affect the external API, and i can easily test it in mode, i might actually try putting that in tomorrow, its so silly that you can't scale or rotate cameras intuitively!

14
if the replay is being played through FlxG's interface, then the mouse stuff should be a non-issue - see FlxG.recordReplay() and FlxG.reloadReplay()

15
releases / Re: v2.50 beta thread!
« on: Mon, May 2, 2011 »
Just grabbed 2.52 and added it to 2 of my games, both work perfectly with it. In fact one I was having performance issues with is now running a lot smoother. Will try it on my work machine tomorrow (where the issues were more evident).

I found a bug where I had put in unnecessary floating point correctiosn that were occasionally causing tilemaps to basically redraw the buffer every single frame.  pretty ****ty for performance it turns out!!

16
releases / Re: v2.50 beta thread!
« on: Mon, May 2, 2011 »
ok pushed up a bunch of stuff to beta branch as v2.52, mostly some timer fixes and a new function FlxSprite.replaceColor()

17
releases / Re: v2.50 demo activity
« on: Mon, May 2, 2011 »
Awesome progress so far you guys!  Remember, to make these demos as awesome as possible, I want to encourage community feedback regarding both the demo and the demo's source code!  These things are turning out pretty great, but I know Flixel wouldn't be as good without other sets of eyes looking it over :)

18
help / Re: 2.5 framerate troubles
« on: Mon, May 2, 2011 »
the debugger overlay might be too CPU intensive - compiling in release mode with forceDebugger = false should prevent it from even being instantiated, which might bewhats going on...

19
releases / Re: v2.50 demo activity
« on: Sun, May 1, 2011 »
i'm posting this to the page now - what I'll do (like I did witht he other ones) is I will host the SWF, and provide links to the source code, but it will be up to you to just email or twitter me a new SWF should the demo change so much form community feedback that the SWF doesn't really loook like the source code anymore.  otherwise it's fine for the SWF and the repo to be slightly out of sync :)

20
releases / Re: v2.50 demo activity
« on: Sat, Apr 30, 2011 »
i'll post split-screen tomorrow!  for now passing out, LD48 burnout oooofff

Pages: [1] 2 3 ... 43