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 ... 43
41
It's just not in the root package anymore, so you have to add import org.flixel.system.preloader; or whatever to the top of the file to make sure it can find the class

42
releases / Re: v2.50 released!
« on: Wed, Apr 27, 2011 »
Only problem with the layout is that the forums link is now buried in the contribute page, everything else is sweeeeet :D

It also has it's own giant button on the help page!

And no, no one has volunteered to theme the forums yet, I was hoping you would cai :D

43
help / Re: hello world probelm
« on: Wed, Apr 27, 2011 »
how come the window is white?  by default the text is white, so the text might actually be drawn...

44
very close!  just use FlxObject.FLOOR, like it says on the wiki and in the source code on github :)

45
releases / Re: v2.50 demo activity
« on: Wed, Apr 27, 2011 »
yea actually making a demo template project is a really good idea, i will do that right now!

ok here you go: https://github.com/AdamAtomic/FeaturesTemplate

updated the top post to link it as well, thanks for the idea :)

46
help / Re: hello world probelm
« on: Wed, Apr 27, 2011 »
huh, that should work fine O_O  have you tried doing a trace() from inside PlayState.create()?

47
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:

http://flixel.org/

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:

http://games.flixel.org/

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

ONWARD!!

48
help / Re: Problems with Tilemap.following()
« on: Wed, Apr 27, 2011 »
you only need to set the camera bounds and follow behavior once, up in create()

49
releases / Re: v2.50 demo activity
« on: Wed, Apr 27, 2011 »
that sounds awesome but that might be better suited to the flash game dojo wiki?

50
The only way to do this currently is to make one rotated sprite for each frame, and handle toggling between them yourself, perhaps stuffing them both into a flxobject for the sake of simplicity and collisions, and just override draw/render to display the sprites accordingly

51
help / Re: Transparency collision TileMap
« on: Tue, Apr 26, 2011 »
Correct, flixel does not ignore alpha pixels in anything really, all collisions are box v box.  Check out the power tools and if that's not what you wanted either then it's not TOO bad to customize or rewrite collision processors in v2.50

52
help / Re: scrolling maps
« on: Tue, Apr 26, 2011 »
You will want to check out FlxG.follow (v2.35) or FlxG.camera.follow (v2.50) I think!

53
help / Re: Problems with Tilemap.following()
« on: Tue, Apr 26, 2011 »
V2.50 got rid of the weird lerpy camera in favor of using simpler dead zones.  You can still get whatever behavior you want from the camera, but if you want look-ahead or some other behavior then you should create a new object for the camera to follow, and embed the logic you want in that object.

The reasoning is that deadzones are simple and clear and easy to customize, while a smoothly interpolated camera that actually does what you want is pretty weird/difficult in comparison.

The current, v2.50 build of Mode uses FlxCamera.STYLE_PLATFORMER to constrain the camera motion, which means the dead zone is not very wide but is quite tall.  This prevents jumps from messing with the camera too much.  There are a bunch of "style presets" like that, and you can specify your own deadzone too.

You can also do the "fake" follow object trick as well!  If you do that, probably you will want to use STYLE_LOCKON (but not necessarily).  You can use the visual debugging overlay to track your invisible focus object while you are debugging it's behavior too!

54
Floating point errors suck :( v2.50 has a lot of +0.0000001s added to things all over th place in an attempt to curtail those effects withoutnhaving to call round() everywhere... In the meantime, you could try teed ing to 240.0000001 or something... It's gross, but it should prevent those awful annoying floating point errors.  You can also directly manipulate and adjust FlxG.scroll in all versions of flixel, so you could just manually round that value when the tween finishes maybe?

55
releases / Re: v2.50 beta thread!
« on: Tue, Apr 26, 2011 »
yea definitely possible!  i am marginally worried about the performance of doing 3 loops instead of 1 loop in each object, but it's definitely worth considering, making a note to keep an eye on it!

56
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!

57
releases / Re: v2.50 beta thread!
« on: Tue, Apr 26, 2011 »
I should have explained that it works by overriding draw(), and you can work directly with the bitmapdata flxcamera.buffer or the new flxsprite flxcamera.screen. For some operations the frame pixels may be out of date on the screen object, but you can force it to be ok by calling drawFrame if you need to

58
releases / Re: v2.50 beta thread!
« on: Mon, Apr 25, 2011 »
phew, I think that was the last big push.  post-processing is back in, and tweaked a few other things here and there.  If you have time tonight or tomorrow I would LOVE for someone to go through and bang on it just a little more before I go over to master branch tomorrow evening.  I was able to update all my old demo projects to the new codebase, and I haven't spotted any exceptionally lame things lately... so here's hoping we made it :)

tomorrow i'll be working on the website with jasmhz and waiting for any last bug reports to come in, but otherwise I think 2.50 might be ready for the big time!

59
releases / Re: v2.50 beta thread!
« on: Mon, Apr 25, 2011 »
I fixed the thing where tilemap collisions were losing track of what was A list and what was B list.  I had to rework the mass/elasticity-based collisions some to get FlxTeroids to work right, but I'm really happy with the results so far.  FlxText and FlxSprite documentation fixed.  FlxButton null thing fixed.  justTouched() logic gate fixed.  renamed getFirstAvail() to getFirstAvailable().

ok post-processing is the last thing I have left I think.  FlxBlur, FlxTeroids, FlxInvaders, FlxCollisions, Mode and HelloWorld have all been updated to v2.50 locally!  Once I figure out post-processing and FlxBloom I think I will push all this stuff out to the master branch, and tomorrow we should have the new website working!

Thanks again for all the testing and early upgrades and stuff you guys, it's been a huge help!

60
releases / Re: v2.50 beta thread!
« on: Mon, Apr 25, 2011 »
that's super weird - cuz i mean the first 2 lines of findPath() are:

Code: [Select]
var startIndex:uint = uint((Start.y-y)/_tileHeight) * widthInTiles + uint((Start.x-x)/_tileWidth);
var endIndex:uint = uint((End.y-y)/_tileHeight) * widthInTiles + uint((End.x-x)/_tileWidth);

Like the very first thing it does is convert the world coordinates you give it into tile indices.  So the way you are using it in your example should be totally fine.  so i mean the world coordinates themselves need to be within the map dimensions, but you really shouldn't have to bother with tile indices or anything :(  that's weirdness.

I believe the dev branch of FlxCollisions has some simple pathfinding code running in it at the moment, if you uncomment the two blocks labeled "silly pathfinding whatever"

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