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.

Topics - Adam Atomic

Pages: [1] 2 3 ... 5
releases / v2.50 released!
« on: Wed, Apr 27, 2011 »
A few minutes ago (much to the chagrin of everyone on earth following the flixel twitter account) I pushed all the development changes from the last month or so over to the master branch on github.  We've been testing this release for almost two weeks now, and we've gotten a LOT of the kinks out, and I'm really happy with it.  If you want to find out more about the release, you should totally check out the brand new web page:

Isn't it pretty??  There are a few sections that still need some work but I think this will be a much better resource than the old one.  One of the coolest things we have now is a vastly improved method for submitting your games to a central archive:

So, first off, my apologies to everyone who sent a thumbnail to my email over the course of the last year or so and then never got to see their game added to the old archive.  Second, I humbly and earnestly hope that you will take the time to submit (or re-submit) your games to the new archive, where we can have full-size screenshots and captions, which are all automatically syndicated to the flixel homepage.

Our web admins are in charge of screening the games that go up there, but pretty much anything is fair game, we'll just only post 3 games a day from the queue.  So yea.  2.50 is go, new website is go, new game archive is go, and Ludum Dare 20 kicks off this Friday night :D


releases / v2.50 demo activity
« on: Tue, Apr 26, 2011 »
Hey flixelers!  I am wrapping up the new website, and one of the things it will have (among many others!) is a FEATURES page.  It will look something like this hasty mockup, sort of:

The idea is to create some nice little interactive demos, kind of like this one on the tweenlite homepage (scroll down to the Interactive Demo section).  While I can create all these demos myself, I thought this would be a cool opportunity for some community involvement.  I can and probably will create at least a few of these just to serve as examples for the other examples, if that makes sense...

HOWEVER, because these are forward-facing, public, sanctioned demos, there are some fairly strict requirements:
  • Demos must run in 400x300 resolution (pref. w/ 1x zoom)
  • Source code must be open (pref. on github or other browsable site), and the actual demo logic contained in a single FlxState.
  • Code should be clearly and heavily commented and well-organized.
  • Keeping the demo up-to-date will be YOUR responsibility
  • Use as few embedded resources as possible to keep load times down
  • Since there will be multiple SWF files on one page, demos should should have a simple "title screen" state that clears on mouse click (like FlxTeroids), that runs at a lower game and flash player framerate than the actual demo

UPDATE: there is now a simple template project that you can download that has most of these specs set up already.

That's about all I can think of at the moment.  Like the TweenLite demo, I think these demos will be best served with mouse-driven, checkbox-y style behaviors.  Just simple, focused mini-apps that show off a specific feature and thus provide good source code or samples for other developers, especially beginners.

Have I scared you off yet??  If not, here are the general feature areas that I think would benefit from having demos:

I am totally open to more ideas, though these kinds of specialized or focused topics are the ones that will benefit most from these micro-demos and their accompanying explanations.  As always I'd be happy to answer any questions about the guidelines or look over submissions, and I'm looking forward to seeing this stuff come together!  Hope you guys had a good holiday weekend and I'm looking forward to Ludum Dare 20 this weekend!

releases / MOVED: iOS Canabalt Problems/Solutions
« on: Tue, Apr 12, 2011 »
This topic has been moved to iOS.

chat / Looking for another community moderator
« on: Sun, Apr 10, 2011 »
hello chaps (and chapettes, i hope)!  I am looking for someone to step up and help mr. photonstorm with administration and moderation duties here on the forum, as well as with the soon-to-be-established tumblr account.  The formal description is as follows:

You have just a few responsibilities: find spam posts and delete them, ban spam accounts (never by IP, but always by hostname, email and username), keep the forums updated and with good security, and approve submissions to the flixel tumblr.

"Low commitment" may be a relative term, as keeping the forums updated with good security is sometimes a pain in the butt!  However, on the whole, I would expect these duties to take up maybe half an hour each week.  It would be a big help for me, and I'm sure photonstorm wouldn't mind either :)  Thanks!

releases / 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 (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?

releases / v2.50 beta thread!
« on: Fri, Apr 8, 2011 »

Oh man, exciting times you guys!!  First, there is a whole new branch on github dedicated to the old beta 2.43, since I know it's pretty popular and I don't want to ruin everybody's christmas:

This is just a copy of the old beta branch, that I will no longer maintain, but is there in easy reach just in case you need it.  Once that was archived, I merged the v2.50 dev branch down into beta:

And here is the github commit manifest, sadly soiled by documentation noise:

I'm going to quickly attempt to detail the major changes real quick:

1 - Collision system has changed a lot.  While it's still the same basic idea, the "collision hulls" are gone in favor of just storing the last position of each object.  Also, all the hitLeft(), hitRight() callbacks are gone, and replaced by a simpler system.  During update(), you can just check isTouching(FLOOR) or wasTouching(LEFT) or whatever, and keep all your logic in one function.  Also it is easy to run your own collision handlers and stuff.

2 - Don't really need to call super.update in most classes anymore.  You DO need to call it in your game states though!

3 - The debugger overlay is beastly powerful now!  You can also extend the drawDebug() function in your sprite classes to make the visual debugger more powerful.

4 - Added rudimentary path following and path-finding with debug visuals.

5 - Added new camera system, so you can do split-screen, or picture-in-picture with just a few lines of code.  However, EVERYTHING is cameras now.  Most of the time this isn't a big deal, because there is a default camera that is easy to work with.

6 - I removed FlxKong, FlxPanel, the game-level offsets and frames (though that can be emulated with cameras now), and will probably be removing FlxMonitor.  Thrust was removed from FlxObject, and some things were moved around.

7 - States extend groups now, and groups just extend flxbasic, not flxobject.  Groups also have a nice new "recycle" function, that can be used to intelligently re-use game objects like bullets or enemies.

8 - Camera follow behavior is less swoopy and spazzy, and easier to extend/override.

That's the big stuff I think.  I know that is only a cursory overview, but part of what I'm doing next week while we beta test this stuff is working on finishing the documentation and helping build a new more informative website, with a tour and stuff.


However, in the meantime, it would be a really big deal to me if whoever is able can try porting one of their existing prototypes over to the new code base, even though it will change a little bit in the coming week or two, and let me know what bugs they find, or where they get stuck, or what seems crappier.  In general, my goal with this update was to make things more simple, more clear, and give people more control.  This did sometimes require making some big changes, but in my test projects locally I've not had to change any of the core behavior, and the actual game code in my projects has dropped by 10-20%, which is cool.

So yeah, if you have time this week to try out the new code and let me know what you think and what bugs you find, that would be awesome.  There are a few different ways to report bugs:

1 - You can simply reply to this thread :)

2 - You can submit them to

3 - You can message me on!/flixation

I will be watching and interacting on all these channels next week to try and get v2.50 ready for the master branch.  Thanks ahead of time for your time and effort in helping with this, and I'm looking forward to getting this new code base out to the world :)


There are a few rough spots in the beta still I think that probably won't get magically better next week, but I'm looking forward to improving over the course of the year:

1 - Collisions are still not an amazing system.  While it is much more stable than before, it still has limitations and weirdness sometimes.  I've tried to segregate the collision behavior as much as possible, to both make it easier for ME to understand and to make it easier for YOU to help me improve.  Whether it is optimizations for the quad tree or better approaches to collision resolution, I hope we can work together to improve that system over the next few months.

2 - I just put in path-finding yesterday afternoon, and I'm quite certain it is a mess.  Now that there is a kind of quasi-official FlxPath object, I'm hoping that it will be trivial to improve the guts of FlxTilemap.findPath() without blowing people's minds, and I think the community can help with that a lot.

3 - Path-following is also newly added, and probably pretty rough around the edges as well.

Finally, I have a few things that I'm definitely going to be looking at during the beta testing next week:
> 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'll be making a new v3.0 thread to talk about wacky future features.  In the meantime, this is the short-term plan of action, and I'm really looking forward to your feedback and help in the next week or two to roll over to the new hotness!  Thanks :)

iOS / welcome!
« on: Tue, Apr 5, 2011 »
So at the moment this is just a kind of general place to post questions, fixes, and just generally share help and ideas about the admittedly rough iOS port of the framework.  So have fun I guess!

That's what twitter said anyways.  Which is insane.  Anyhow, what happened??

1 - I got pretty busy with work stuff.  I help run an iPhone games company with my friend Eric, and we've put out 2 games and a multitude of updates this year, with more updates on the way as we crunch up against the holidays.

2 - My lady and I are pregnant (yes on purpose) and are going to have a boy in January or February.  This is alternately terrifying, exciting, overwhelming, mundane and awesome.  Is also cutting into free-time projects a bit.

3 - Flixel is pretty OK.  I've been doing a lot of little prototypes and projects here and there, and it's basically working ok and not causing too many problems for me.  I've said a lot before that flixel is my most greedy project, and it's really true; if it does what I need, I get pretty unmotivated about updating it.

THAT SAID, it's been 6 months.  And each little prototype I've built in that time has resulted in some tweaks to flixel here and there, and they're starting to pile up.  None of this stuff is mindblowing, I promise, but I think sometime soon I'll be able to put out a nice update which just simplifies things a little more, and adds some nice functionality here and there.  Stuff that will be in it probably:

1 - FlxGroup will have some recycling abilities/options.  I am realizing, after typing a lot of the same code in a lot of different projects, that moving and extending some of the FlxEmitter behavior into FlxGroup would be really handy.  FlxEmitter will still exist, it'll just be much simpler, and only really handle the timed emission of sprites and the auto-generation of particle sprites.  This means FlxGroup can be used for all sorts of things, like managing the global sound pile, etc.  It should be super useful!

2 - FlxGroup will not have position or speed information anymore.  It will not extend FlxObject anymore.  This was handy for the collision functions, but I'll work out what to do with that - seems like most collisions are between groups anyways?  Anyways, putting stuff in groups that could move around was just kind of insane, since flixel doesn't really do nested rendering, it was wreaking havoc on collisions, and it wasn't that useful anyways.

3 - FlxSound is a lot more useful now I think, can check playback volume, waveform amplitude on each channel, and even do some simple beat detection stuff.

4 - The usual attempts to clarify collide vs overlap, and to get overlap to play nice with scrollFactor and sprites vs objects.  Not sure its fixed still, as the distinction is just confusing.  You want to use the sprite edge for onScreen() checks, but for object overlap you probably want to use bounding box... might need to rename some fucntions or something.

5 - I think it'd be handy to include a bitmap font class, I'm gonna think on how to do that in the simplest way.  Hopefully it'll just be another version of FlxText, that works more like tilemap (splitting up into tiles, caching to a single sprite).  Between that and removing the umm deprecated flixel.mp3 file this should get flixel down to just maybe 40 kb compiled, which I like.

6 - The beginnings of some more complex shape-drawing stuff that plays nicely with flixel sprites

7 - Will definitely try to incorporate some things like path-finding and path-following and some other goodies too

Ok I think that's about it!  Thoughts?

chat / Flash Game Dojo
« on: Tue, Jun 15, 2010 »
Hey guys, I just wanted to let you know about a project I've been working on with nubile genius Chevy Ray Johnston since March.  The blurb from the site is:

"Flash Game Dojo was started in March 2010 by Chevy Ray Johnston and Adam 'Atomic' Saltsman as a way to pool their collective knowledge of ActionScript programming, provide a trusted and benevolent host for SWF files, and to help ease new coders into the murky, shark-infested waters of creating their own Flash games. Flash Game Dojo is an ad-free, not-for-profit enterprise for game design education. "

This is the page itself:

We are super, super excited about this - we built a free game uploading service:

We built a solid-but-still-growing online knowledgebase of Flash game programming stuff:

AND we built a walkthrough for beginners who have never actually made any game before, much less a Flash game:

To be clear, we are not under the impression that this will change the world overnight, but it's definitely something we both wanted badly to exist, and now it does.

releases / v2.41 up on dev + beta branches
« on: Wed, Jun 2, 2010 »
Read Release Notes on github

Download dev branch source here

Code: [Select]

> dev console doesn't display, just traces frame timing when is set


> stupid tilemap stuff
> stupid preloader stuff

V2.38 STUFF:

> Don't have to "Force" an animation to play() if it is both not looped AND finished
> Optimized rotatePoint() and getAngle() with non-trig shortcut maths
> NEW FUNCTION - FlxObject.hitSide()
- called by BOTH hitLeft() and hitRight()
- shortcut since horizontal collisions usually share logic
- can still override hitLeft() or hitRight() independently
> Don't forget to call super.hitSide() and not super.hitLeft()
> FlxEmitter.createSprites() has new parameter "Bounce"
- automatically assign a bouncing behavior to particles
- uses new class
> Various general optimizations (should help with mobile versions)
> FlxTileblock extends FlxSprite now
- has new function loadTiles()
- can still call loadGraphic() but has less options
- render times drastically improved (Mode dropped from 3ms to 0ms)
- supports rotation, scaling, tinting, etc
- implicit support for non-square tiles too
> - flag this to disable non-mobile features
- currently only disables some stage events and the sound tray
> FlxButtons can no longer be pressed while game is paused
- set FlxButton.pauseProof to true to work while paused
> Fixed annoying problems with bounding boxes
- sprites with offsets appear properly now
> FlxKeyboard has NUMPAD keys now
> FlxTilemap only renders when necessary
- tiles are cached to a screen-sized buffer
- only redrawn when the buffer can't cover the screen
> FlxU got some new color utilities!
- FlxU.getColor() - generate a uint color from RGBA components
- FlxU.getColorHSB() - generate a uint color from HSB components (thanks, trashpaint!)
- FlxU.getRGBA() - return an array of RGBA values from a uint color
- FlxU.getHSB() - returns an array of HSB values from a uint color
> hopefully made FlxU.random() a little safer
- deprecated mutate() in favor of fixSeed()
- BUT you can still mutate seeds like this: fixSeed(seed+mutator);

mostly bug fixes and optimizations, a couple small API changes, and a few new utilities.  trying to get flixel to be a little more Android friendly...

chat / updating the forums!
« on: Sat, May 8, 2010 »
forum user cai got this nice skin started for me and I finally got around to installing it.  It's about 95% F'ing Awesome, but it's possible that while finishing the last 5% this weekend things might look INSANE from time to time.  I'll try and have it all straightened out by Monday though!  Thanks :)

releases / flixel v2.35 + new git branch "beta"
« on: Mon, Apr 19, 2010 »
Hey dudes!  Update time.  Fixed some annoying things, added a beta test of bounding box displays, and I created a new code branch.  There are now THREE code branches on github:

1 - MASTER branch - this is the equivalent of any "stable" release of an API or codebase

2 - BETA branch - this is a relatively stable but not fully tested version with few/no API changes.  This is essentially where stuff that is being considered for the MASTER branch will live.

3 - DEV branch - this is the public mirror of my own personal development version of flixel.  Currently it is in sync with beta but this will likely NOT be the case starting sometime soon.  Maybe once or twice a year possible game-breaking changes could move from dev into beta, to be tested and refined and eventually make it into the master release!

I will present these different options nice and clear on the flixel homepage soemtime soon, but the easiest way to think of them is master is pretty safe, beta is more advanced but less safe, dev is probably not very safe at all but will have weird new things in it!

v2.35 Change List:

Code: [Select]
> FlxEmitter: smarter default delay value
- 3 seconds for explosions
- 0.1 seconds for streams
> FlxG.showBounds
- set to 'true' to show bounding boxes
- still misses some objects, re-toggling usually fixes
- NO automatic hotkey for this option/behavior, but code is easy
> if(FlxG.keys.justPressed("B")) FlxG.showBounds = !FlxG.showBounds;
> FlxU: changed default quad tree world size + position
- now set to FlxG.width by FlxG.height at 0,0
> FlxSprite: optimized loadRotatedGraphic()
> FlxText: now supports non-embedded fonts

You can check out the new bounding box stuff by pressing the 'B' button on any of these demos:

All these v2.35 changes were submitted to the dev and beta branches ONLY, and will only be available on master once they've been vetted and tested a bit more.

releases / Quake 2 in HTML5
« on: Fri, Apr 2, 2010 »

If anybody has any insight to how they got OpenAL working in HTML5 I would be super interested to know more!  There would still be the whole render-to-texture problem I'm sure, but flixel running in javascript would divorce us completely from Adobe software, which I would find relatively pleasant :)  ALSO if that is indeed an April Fools joke then NEVERMIND i'm an idiot :P

releases / v2.32 (master) and v2.33 (dev) are up!
« on: Thu, Apr 1, 2010 »
Ok, there is a verified stable patch for v2.31 up on the master branch!  Download it and enjoy :)

There is also a new development build up (v2.33) that has some kinda cool stuff.  If you pull down the dev console in 2.33 you will notice there is a bunch of new frame timing data - it's not SUPER granular but hopefully it will help with understanding how flixel works and even with debugging occasionally!

v2.33 change list:

Code: [Select]
> New class!
- Stores and averages a window of values
> FlxConsole updates
- Developer console now shows millisecond timing
  for a variety of processes
- Game updates, game rendering, flash idle time, etc
> FlxG.framerate is a getter/setter now
- Change SWF framerate at any time

releases / v2.31 is up!
« on: Mon, Mar 29, 2010 »
Change list:

Code: [Select]
> Flex SDK 4 text compatibility resolved
> FlxG: new variables "framerate" and "frameratePaused"
> FlxGame: simplified render loop, framerates improved
> FlxGame: switched game loop to use a timer
- browser plugin efficiency improved
- AIR and Flash Player framerates improved
> FlxPanel: fixed bug where buttons weren't working right
> FlxPreloader: new variable "minDisplayTime"
- optional, display preloader even if game is loaded/loads quickly
> FlxText: fixed "flat white rectangle" initialization problem
> FlxText: fixed documentation problem with ShadowColor variable
> FlxTilemap: fixed and optimized preCollide()
- Not much of a framerate difference as far as I can tell
- Corrected "walk off left side but hit right side" behavior
> FlxTilemap: added warning message to log if setCallback() is called
> FlxU: new functions startProfile() + endProfile()
- Prints execution time to debug console with given label
- Suggested Usage:
var pf:uint = FlxU.startProfile();
FlxU.endProfile(pf,"Expensive Function");
> FlxU: new variable quadTreeDivisions
- controls granularity of quad tree

releases / performance notes from today's bugfixin'...
« on: Mon, Mar 29, 2010 »
So today is a bugfix day for flixel, I should have a nice new dev and master release up in a few hours with lots of fixes and a few new things (but ZERO api changes or deletions).  EN ROUTE, however, I started doing a little profiling (using a new thing in FlxU), and discovered some interesting stuff.  I am using FlxCollisions as my testbed since it's pretty CPU heavy.  Discovered some interesting things about how the CPU/timing was working.  Here are the average times for various operations in FlxCollisions first example (robot and gib spewer) in milliseconds:

1 - Updating all object positions: 3ms
2 - Colliding all objects: 10ms (1ms to build tree, 9ms to walk it)
3 - Rendering all objects: 1ms
4 - Misc Flixel overhead: 1ms
5 - Browser overhead: 25ms!!

I couldn't believe this at first, so I made a new app that had no flixel files, not even a text field or a graphic, all it had was a timer and a trace statement.  Sure enough, the shortest interval you can get out of a timer in the browser is about 24ms or so (on OSX at least).  I made some changes to the flixel game loop which will be detailed later, and ran it locally in the flash player (same FlxCollisions app), and got 150 FPS!!

Ridiculous.  ANYWAYS, this has funny implications for the future of flixel optimization.  On the one hand, it makes flixel's execution speed even more important, but on the other hand, even in the absolute best case scenario I can't even crack 45fps on OSX because of browser BS.

SO...I guess all I'm saying is that I definitely take flixel's performance seriously, and especially in the department of walking the quad tree there is some ground to be made up I think.  But a lot of the other optimizations (vectors instead of arrays, lack of inline functions, method call overhead) seem to be more or less inconsequential.

FINALLY, I have a theory about how to sneak an extra 10fps or so out of the browser performance but I haven't gotten it to work in flixel yet.  I *THINK* there should be a way to basically start the 24ms browser BS timer before stepping through the 15fps or so update, so that the game update loop basically happens during the browser's...whatever time.  However, all my attempts at getting this working are wildly unstable and I'm tired of force-quitting my browser!  If anyone wants to try and get a hack loop like this working I would be very interested in the results :)  I will try again, but probably not anytime soon.

Anyways, hope that helps with understanding flixel performance, and keep an eye out for an update later today!

releases / IMPORTANT-ISH: flixel branching + stability
« on: Mon, Mar 22, 2010 »
In preparation for the private beta of the translator app, I've added a second branch to the flixel codebase called "dev".  The main branch, "master" will not be changing much for the next few months.  Most changes or updates that I do will go into the "dev" branch, except for bug fixes or other things that won't mess up the "master" API.  This should be good for everyone I think!

If you want to be on the cutting edge of flixel, make sure you pull from the "dev" branch, not "master"!

I don't know yet what kind of effect this might have on the issues queue, but I think it should be OK.  I will try and get some bug fixes out on the master branch this week!  If you have any questions lay em out here and I will try to answer them as best I can, thanks!

help / forum moderator assistance requested!
« on: Mon, Mar 15, 2010 »
Please email if you are interested in helping to moderate the forums.  Currently this will consist solely of deleting and banning the occasional spammer; it's pretty easy!  Thanks guys

UPDATE - found a mod, I'll let you guys know if/when I need more help, thanks to everybody who offered their assistance!

releases / v2.23 is up!
« on: Wed, Mar 3, 2010 »
Hey dudes, since I'm heading off to GDC in a few days I tried to cobble together a kind of basic maintenance release.  This shouldn't break anything or even change the behavior, this is more just fixing some annoying bugs and adding a few extra parameters here and there:

Code: [Select]
> FlxSound changes/additions:
- new variable 'playing'
- new variable 'name'
- new variable 'artist'
> NOTE: these currently only work with streamed sounds!
> better volume hotkeys support on numpad keyboards
> better support for wrapped text
> FlxTilemap changes/additions
- setTile and setTileByIndex perform simple bounds checking now
- follow() has new parameter Border
> specify more or fewer tiles to be visible around edge of map
> handy for blocking things off or adding visual padding
> included some light game loop optimization
> fixed site locking code

I'm working on updating and getting code highlighting going in the forums too (though a forum reskin will have to wait)

chat / best flixel games
« on: Fri, Feb 12, 2010 »
Hey guys, i'm in the process of completely revamping the flixel website, and am putting together a list of the awesomest flixel games, this is what I have so far:

please contribute suggestions!  if i like em i'll add em to the list!

Pages: [1] 2 3 ... 5