Community fork of Adam “Atomic” Saltsman's popular game engine Flixel. Distilled from a variety of Flash games he worked on over the last couple years, including Gravity Hook, Fathom and Canabalt, its primary function is to provide some useful base classes that you can extend to make your own game objects.
This is what I refer to as the @moly fixes, the changes requested more than a year ago in #107 and first attempted to patch in #169.
The major difference between now and back at #169 is... Well, moly's ObjectPool is a generic implementation of the design pattern, and a fairly elegant one at that. However, because this is Flixel, it's been renamed FlxObjectPool; and because of the organizational changes, I made it a public class and stuck in the util package.
Mostly, I referred to the original commit's changes. There are some small differences - spacing, I guess I was OCD about curly braces at that time, etcetera - but otherwise the code is the same.
I have given this a once over test. Collisions still work and it compiles. That's all I can guarantee. I'm still dealing with my own problems with the current codebase that impede more exhaustive tests. I would recommend some testing, mostly to make sure that memory doesn't leak. It should actually rein in past memory problems, as well as give some speedup to physics calculations, but no promises.
For what it's worth, the first time this set of changes was attempted, it did result in significant speedups to the code's execution and was fine. It is only caution requesting testing.
I'm available for questioning and for changes needed in the pull.
Erps. Didn't realize it'd show up in the pull XD The commentary covers the only part I had to trace code to understand, on the assumption that others may find it unclear or unintuitive.
This is what I refer to as the @moly fixes, the changes requested more than a year ago in #107 and first attempted to patch in #169.
The major difference between now and back at #169 is... Well, moly's ObjectPool is a generic implementation of the design pattern, and a fairly elegant one at that. However, because this is Flixel, it's been renamed FlxObjectPool; and because of the organizational changes, I made it a public class and stuck in the
util
package.Mostly, I referred to the original commit's changes. There are some small differences - spacing, I guess I was OCD about curly braces at that time, etcetera - but otherwise the code is the same.
I have given this a once over test. Collisions still work and it compiles. That's all I can guarantee. I'm still dealing with my own problems with the current codebase that impede more exhaustive tests. I would recommend some testing, mostly to make sure that memory doesn't leak. It should actually rein in past memory problems, as well as give some speedup to physics calculations, but no promises.
For what it's worth, the first time this set of changes was attempted, it did result in significant speedups to the code's execution and was fine. It is only caution requesting testing.
I'm available for questioning and for changes needed in the pull.