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 [4] 5 6 ... 43
releases / Re: v2.50 beta thread!
« on: Mon, Apr 25, 2011 »
ok yea I can verify that post-processing the camera buffer is hard/impossible at the moment.  i am thinking about the best way to make that an option again :)

releases / Re: v2.50 beta thread!
« on: Mon, Apr 25, 2011 »
hey dude great catches!  I've already put in most of the changes.  couple of specific things:

1 - yes, if you want to mimic the old followAdjust() behavior, then you should create your own FlxObject (i usually call mine "focus" or something like that) and assign your own custom behavior there, and have the camera follow that.  default look-ahead behavior ended up being sufficiently complicated that i feel most comfortable taking that approach from now on.

2 - as far as post-processing, you SHOULD be able to just override your game state's draw() functionality, and do it there.  however, I will be re-building FlxBloom to run in v2.50 today I think, and I will see how it goes!  I originally intended to include a "screen" FlxSprite with each camera, and then decided against it, but I can't actually remember why...

releases / Re: v2.50 beta thread!
« on: Sun, Apr 24, 2011 »
Well depends on the tile size right, it calculates the end index based on the world coordinates you passed and the tile size...

releases / Re: v2.50 beta thread!
« on: Sun, Apr 24, 2011 »
yes, findPath() runs on world coordinates.  if it is returning null during the distance calculation it is because it could not find a clear path between the two points you provided.  this may be a bug or it may just be an issue with the tilemap data, i can't tell yet.  we have run quite a few tests here though and it seems to find end points correctly...

releases / Re: v2.50 beta thread!
« on: Sun, Apr 24, 2011 »
yea by default the world bounds are just set to the screen size plus a little bit of padding around the edges.  so you definitely want to make sure that you update those boundaries if you're making a game with scrolling!

also, I believe 2.50 is ready for the big leagues finally :) put up something like 7000 lines of new documentation or updated variable names (no more _a = bla bla!) in the last few days, and the new website is almost ready :)

help / Re: EZPlatformer Tile Trouble?
« on: Sat, Apr 23, 2011 »
if you're using v2.50 you should put the FlxTilemap.AUTO in the loadMap() call as a parameter now

chat / Re: Ludum Dare 20
« on: Sat, Apr 23, 2011 »
i'm gonna try to get a few hours in this year.  if i can't, i'll at least try to be around ont he forums/IRC during the afternoons to help with tech support!

chat / Re: flash game dojo
« on: Sat, Apr 23, 2011 »
we got it back up :) big ups to photonstorm for knowing what to do!

releases / Re: v2.50 beta thread!
« on: Sat, Apr 23, 2011 »
yea findPath runs off worldspace x and y coordinates, and returns a FlxPath.  One reason to run off X and Y coords is so you can easily use it with any game object, not just from tile to tile.  also it is easier to calculate world coords from a tile than vice versa, and you can use the new mmm i think its FlxTilemap.getTileCoords() to automatically grab that info from specific tile types.

FlxObject has a method called followPath() that you can use to automatically follow a path, or just write your own logic in update(), using the FlxObject.path var to store a reference to the path.  paths know how to draw themselves in visual debug mode so you don't have to worry about that part either!

The path following is VERY VERY simple at the moment, just linear, from node to node, no fancy tweening or anything.  However, it does have some useful behavior flags, for looping versus no loop, and only following on X axis (nice for patrolling enemies in platformers)

releases / Re: v2.50 beta thread!
« on: Sat, Apr 23, 2011 »
2.50 supports transparent by colors now, so double-check the alpha on flxg.bgcolor!  Tho I should check that the default bg color is opaque too...

help / Re: Block stacking - similar to tetris
« on: Fri, Apr 22, 2011 »
in older versions of flixel this is just ognna be aproblem :P your best bet is to set blocks that have "landed" already to be "immovable" or i believe "fixed = true" is how it worked?  that should improve collisions and improve the melting thing

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

releases / Re: v2.50 beta thread!
« on: Fri, Apr 22, 2011 »
klembot: well flixel has always done positions as floats, but it would have broken the old "collision hulls" system i was using, which was based on using velocity only.

ALSO, awesomeness, I believe the final-ish beta build of 2.50 is up on github right now, including FULL documention for v2.50.  If any of you have some free time this weekend and want to try some things out, that'd be awesome.  I really appreciate everyone that's been banging on it so far, found and fixed a lot of weirdness already :)

If all goes well the new site and the v2.50 master branch will both go live on sunday or monday night!  just in time for ludum dare 20 next weekend :D

also, updated my 2.50 master to-do list with results:

> seeing if i can simplify sound mgmt with the global sound mixer SKIPPED
> trying to clarify world/physics overlap versus screen/graphic overlap DONE
> timers DONE
> hover bool/callbacks for flxbutton DONE
> comparing the speed of my "fast" angle calcs in FlxU versus just using Math SKIPPED
> maybe improving the "lost focus" arrow screen appearance OK FOR NOW
> double click support DELAYED
> auxiliary global update/draw callbacks lists DONE (PLUGINS)
> exposing _framePixels DONE
> running through the github queue DONE
> fixing up DELAYED

I also put in or fixed a bunch of stuff not listed there but that's ok!

releases / Re: v2.50 beta thread!
« on: Fri, Apr 22, 2011 »
the intent is for MOST uses, in most cases, you'll never actually work with those methods.  In all the games I've ported locally to 2.50, I've only ever worked in update().

The three functions are all called right in a row, on each object.  So there's no like... pre-pass, THEN real update pass, then post-pass.  It's just for each object, we call pre(), then update(), then post().

This allows for a few useful things.  One, preUpdate() can register and track the last X and Y position of the object, which is really important for the new, simpler collision system, and will enable easy movement of the x += 0.5; flavor, which was impossible in old flixel.  Two, postUpdate() can handle animation, clearing the collision flags and integrating the new X and Y position based on velocity and acceleration, if you used those variables.  And three, you no longer have to call super.update if you're extending FlxSprite or FlxBasic or FlxObject, as nothing happens in update() by default.  So you can just override it, and throw ALL your logic in there.

It was a little scary at first for sure, but I think that the tradeoffs in clarity and simplicity are really worth it!

HOWEVER, it's possible if not likely that some crazy game ideas out there might need to override preUpdate or postUpdate for one reason or another.  In this case it's totally not a big deal, you just override it like usual, and as long as you remember to call super.preUpdate() or super.postUpdate() you should be just fine :)

nice!  i already had delete, but i added the rest :)

in old versions of flixel you should use FlxSPrite.velocity.x, not just FLxSprite.x, if you want them to move around.  since old versions of flixel didn't have a fixed framerate, changing x each frame will yield different behavior on different computers, so i didn't support it back then.  rather, it will move around the screen, but the collision system doesn't cope with it very well.

so either do something like:

Code: [Select]
this.velocity.x = 50;
or else do something like:

Code: [Select]
either should get collisions working again, but i'd recommend the former.

releases / Re: v2.50 beta thread!
« on: Mon, Apr 18, 2011 »
I only have 1 question for Adam:
ScrollFactor has been removed from FlxGroup. Does this mean that the only way to set scrollFactors on sprites in a group is now to manually set it for each sprite we add?

I put in a new thing for this that I'm kind of excited about, that is useful for way more than just scrollFactors.  I use it down at the bottom of PlayState.create() in the Mode dev branch:

Code: [Select]
_hud.setAll("scrollFactor",new FlxPoint(0,0));

These two lines of code set everything in my HUD group to not scroll and only run on the main camera.  It may only work for public variables though?  Pretty handy regardless.  I might need to make a sister function like "callAll()" that would do the same for functions, rather than variables?

releases / Re: v2.50 beta thread!
« on: Fri, Apr 15, 2011 »
Ok, another handy suggestion for FlxButton. A get function for _status, to check the status of the button. Code example below:
Code: [Select]
 * returns status of button.
public function get status():uint
return _status;

Np, that's on my list for next week already :)

releases / Re: v2.50 beta thread!
« on: Fri, Apr 15, 2011 »
Elasticity is awesome :) The only issue I have with it is there's no way to set a minimum threshold (that I've found). Setting it to anything other than 1 makes it reduce in value over time, but when it gets down to a really low figure the sprite will sit and jitter insanely on the spot, never quite getting back to zero again.

Yeah - check out FlxParticle to see a simple way to threshold a bouncing sprite

releases / Re: flixel v2.35 + new git branch "beta"
« on: Fri, Apr 15, 2011 »
Hmmm - has something to do with generating the bounding box display version of the tiles, which you can just comment out i think.  V2.50+ doesn't do bounding box display that way anymore though

Pages: 1 2 3 [4] 5 6 ... 43