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 ... 3 4 [5] 6 7 ... 43
81
haha, that's almost exactly what it looks like in 2.5 now!  that's a good sign i think

82
releases / Re: v2.50 beta thread!
« on: Fri, Apr 15, 2011 »
yea what i would try is just remove the isTouching stuff entirely, and just set elasticity to 0.8, and you should be good to go.

whats happening, if you're using collide() (and thus separate()), is when stuff collides its setting the velocity of that axis to zero.  so when you collide with the left wall, it sets your velocity to 0 (if elasticity is zero).  so multiplying the velocity when the next frame rolls around doesn't really have any impact.

however, setting elasticity to 0.8 should work great, and then you don't have to do any isTouching at all.  if you really want to manually adjust on touches, then you need to declare your own FlxPoint to store the last frame's velocities in, or write your own separate() functions.

this is not something i'm super-satisfied with, but elasticity seems to work pretty great for a lot of stuff so far!

83
help / Re: Two animation questions
« on: Fri, Apr 15, 2011 »
FlxSprite.finished is pretty useful

84
releases / Re: v3.0 planning thread
« on: Fri, Apr 15, 2011 »
Hey klembot!  flxsprite and flxanim definitely both need some cleanup, i'll be working on that next week I think.  collisions were terrifying, and hulls have been removed entirely in favor of just auto-tracking the last X and Y position of the object, os hopefully that will be less nightmarish :)

85
help / Re: Two animation questions
« on: Fri, Apr 15, 2011 »
for the second case, FlxSprite.finished is pretty useful, and you can also assign a callback to any specific frame of animation if you prefer that method

86
help / Re: 2D sprite sheet
« on: Fri, Apr 15, 2011 »
yea back in the day it only supported one row, but it should be pretty tolerant now :)

87
releases / Re: v2.50 beta thread!
« on: Fri, Apr 15, 2011 »
in update(), doing this:

Code: [Select]
if(isTouching(LEFT) velocity.y *= -0.8;
should totally work.  Currently the only thing that is tough to do is to manually adjust the X velocity on X touches (like LEFT, RIGHT, WALL, etc), or manually adjust the Y velocity on Y touches (like UP, DOWN, FLOOR, etc).  However, you can use FlxObject.elasticity to do some nice automatic bounce behaviors.

In this specific case though, for an X touch with a Y velocity change, I'm not sure why isTouching(LEFT) wouldn't work, without knowing what was going on with the X velocity and the actual collision situation there

88
help / Re: collide not working on right side
« on: Thu, Apr 14, 2011 »
yes, that was necessary with the old collision system.  in 2.50, as long as preUpdate() is called (which it usually automatically is), the collisions will work fine even if you're just directly setting the x and y values during update

89
help / Re: Collision in an "infinite" world?
« on: Thu, Apr 14, 2011 »
you can also move around the "collision window" on a frame to frame basis.  so for example, if i was building canabalt in a quad-tree based system, I could create the world bounds rectangle to be say the size of the screen plus some padding around the edges, and then just shift that over to match the amount of camera scroll that's occured so far.

however, if you do need to do collisions forever everywhere, the other advice you've gotten makes more sense :)

90
releases / Re: v2.50 beta thread!
« on: Thu, Apr 14, 2011 »
oh balls you are 100% correct, stupid copy paste error on my part!  i'm on it

91
releases / Re: v3.0 planning thread
« on: Thu, Apr 14, 2011 »
yea, internally some stuff is still a bit of a mess. i think i have touched and improved the variable names and logic of every internal file in the whole library in the last month, but this again comes back to these things that all pull at each other from different directions:

1 - obvious need to simplify and clarify the code base

2 - obvious need for stability for the sake of documentation, community tutorials, and more

3 - obvious need for performance and constant improvement to keep up with changing tech and new insights into game development

Performance and simplicity rarely work together it seems like, and stability versus improvement are constantly at cross-purposes.  So no matter what happens, to fix things and keep flixel awesome(r), it means we have to change things (just not too many).

I will also continue to try and publicly announce months in advance any time there are planned changes.  the camera system for example is a pretty big change, but it was talked about for months beforehand.  some changes that seem pretty arbitrary are definitely for the better as well - for example things like shifting code from FlxU back to FlxG (after shifting it to FlxU months ago) were done to keep FlxU library-agnostic.

part of the goal for this update was to make flixel more modular, and i was not altogether successful at that yet.  FlxU was part of that, and knowing that molehill is coming up and integrating physics being interesting as well, i have been trying to prep for ways to wrap and include those things without causing yet more massive changes later this year.

HOWEVER, in general, for new versions of Flixel, if I HAVE to choose between keeping old code that isn't good, and replacing it with new good code, I'll always choose the latter.  If I have to choose between sticking with old, confusing names for variables and replacing them with useful new ones, I'll definitely opt for the latter.

But I will also make sure (like I did with 2.43b) to archive off and branch any popular, supported versions, so that those can kind of constantly be out there.

finally, if you compare my 2.5 wish list to my 3.0 wish list, the 2.5 wish list had some crazy big things in it, while the 3.0, with the exception of molehill, is basically small additions, rather than wholesale refactors.  Even if i add physics at this point, it will be an addition, not a replacement, since box collisions have stabilized a bit.

so yea, hope that helps these things make sense.  all this input and feedback helps me a ton, and i am looking forward to continuing to try and balance clarity, stability and improvements in the future :)  i'm sure flixel will never be "done" but i'm getting very, very satisfied with the architecture, and trivial name changes are a pain in the butt for me too, since it affects every example project i have (at least 8 now) :P

ONWARD!!

92
releases / Re: v2.50 beta thread!
« on: Thu, Apr 14, 2011 »
yea if you are manually iterating through group members, you have a couple options now.  The easier option i think is instead of iterating through FlxGroup.members.length, just iterate through FlxGroup.length.  Otherwise you do need to check for null entries.

93
help / Re: Attaching text to a sprite
« on: Wed, Apr 13, 2011 »
If you are just using the text for display, make it a member of the object, override draw() or render(), and set the text object's x and y just before you draw it

94
releases / Re: v2.50 beta thread!
« on: Wed, Apr 13, 2011 »
Ah - yea, i can fix that, one sec :)

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

http://flixel.org/forums/index.php?topic=2904.0

96
releases / Re: v3.0 planning thread
« on: Tue, Apr 12, 2011 »
Totally understand, and I know it's not much consolation but things changed a LOT less during this update than I thought they would... the balance I'm trying to strike is keeping things simple and accessible for newcomers, keeping the performance good, and not breaking TOO much of the old code.  In the case of render() vs draw(), it definitely wasn't a necessary change, but I thought it might help beginners understand what happens in that part of the game loop.

Actually, there are two suggestions just from this page of this thread that illustrate my point perfectly I think:

Quote
Umm and finally, the most boring of all - really tidy-up the internals Smiley There is lots of "magic" going on in places, and some really lazy variable names Smiley It could all just be a lot cleaner in places!

Quote
for every major release, there always seems like there's a gratuitous name change, e.g. render -> draw, that breaks the existing helper classes I've written.

That said, I think the API has been stabilizing - this is the first shakeup in 6 months or more, I only change things when they move closer to my (admittedly arbitrary) ideals.

So yeah - you're right, it is annoying, and it's something I definitely keep in mind, but I also try to not be TOO felicitous, and make sure that changes are done for a reason, even if I totally forget to explain why publicly and/or it's not the greatest reason in the first place :P

97
releases / Re: v2.50 beta thread!
« on: Tue, Apr 12, 2011 »
yea some kind of timer option is on my internal list for the beta, though it may end up being a plugin or something, we'll see :)

98
releases / Re: v2.50 beta thread!
« on: Tue, Apr 12, 2011 »
you can also change either the game loop framerate or the flash player framerate from FlxG.framerate and FlxG.flashFramerate respectively at any time

99
releases / Re: v2.50 beta thread!
« on: Mon, Apr 11, 2011 »
Ok, another thing. Shouldn't the framerate be declared in a FlxGame's super function? Makes more sense for me, at least. Its mainly just because i cant get the normal way to work though. Btw, its where you do this:

Code: [Select]
super(320,240,MenuState,2);

Yeah if folks want to see framerate parameters there that would be easy to add!

100
releases / Re: v2.50 beta thread!
« on: Mon, Apr 11, 2011 »
oh hmm - i was only calling it from FlxState here, but it could probably be changed back to being a static function in FlxState and be just as usable that way... if a lot of people are using it from OUTSIDE FlxState though maybe it would make sense to move it back into FlxG

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