Farseer Physics Engine 3.0 Update (January)

Coordinator
Jan 10, 2010 at 12:07 AM
Edited Apr 18, 2010 at 7:56 PM

It is time to let you know what is happening to FPE 3.0; what are we doing and what are we going to do. So here is a list of things that we are creating at the moment and how far we are with it.

Fixed and non-fixed joints - Done
Create fixed versions of the non-fixed joints that use world coordinates instead of local coordinates. The non-fixed joints should all use local coordinates for anchors.

Controllers - Done
Implement a controller structure. The decoupled structure makes it easier to extend the functionality.

Convex decomposition - Done
FPE 3.0 only have convex polygons at the moment. It would be great with concave polygons too, so we need a convex decomposition part in the engine to split up concave polygons. Depending on what way we takes, it includes building a constrainer, triangulator and a merger. constrainer makes sure the input is workable and the output lives up to the expectation of the engine. The triangulator split a polygon up into triangles and the merger merges the triangles into larger convex polygons. I'm working on several algorithms at the moment.

Union/Subtract polygons - Done
Boolean polygon operations to add and subtract polygons from each other.

Path factory - In progress
The path factory will be changed and extended to easily create tank tracks, rope and chains.

Texture-to-vertices - Done
We have a great algorithm in FPE 2.x for converting textures to vertices. It support holes and multiple textures in the same bitmap.

Decoupled debug structure - Done
I've already worked on this one and created a separate project that is in charge of the drawing. Matthew is working on some better drawing functionality and a new neat debug panel.

Platform independent
We would like to support all managed platforms, that includes Silverlight, XNA, Windows forms, WPF and others. As something new, we also have Xbox360 as a targeted platform and thus the samples will work on Xbox and the library will be optimized for the Xbox360 platform.

Cancel collision - Done
It is not possible to cancel a collision in Box2D, we would like that functionality to be included in FPE 3.0, but it is not easy due to the internals of Box2D (some assumptions Box2D takes about collisions). It is a small but important feature. I'm also going to implement a broadphase based collision event. If you cancel that event, it will not process the object at all.

New shapes - Done
We would like to extend our shapes to include new types. At the moment we have circles (approximated), circles (real) and rectangles. The new shapes will be:

  • Ellipse
  • Capsule
  • Chamfered rectangle
  • Gears

Others might be included too.

Extended collision filtering - Done
FPE 3.0 will have a flexible collision filtering system that both ease the use of the engine and increase performance (less collision tests). I'm still thinking about this one, but it might be something like 2.x:

  • Group
  • Category

Cutting polygons - Done
Provides a way of cutting polygons along a straight line. Great for lightsabers and laser weapons.

Breakable bodies - Done
Provides an easy way of combining bodies and make them breakable

Extensive samples - In progress
Easy to use samples that shows off all the functionalities of the engine. It also functions as a great foundation for new games by using a high performance and flexible drawing and game structure.

--------------------

Remember, if you want to work on any of those areas or have ideas that fall outside any of those categories, feel free to join us.

Developer
Jan 10, 2010 at 12:53 AM

Also feel free to let us know what you would like to see in the engine. Please keep it physics related. I know there are some features people would love to see that we maybe just haven't thought of.

For all you brave souls that have been downloading the latest source code, please test out the 3.0 Version of the engine. You can find it in

\Samples\FP3.0\Farseer Physics 3.0.sln

Just make sure to have either SimpleSamplesXNA set as the startup project or TestBed.

I've been doing a ton of work on the rendering engine to make the samples clean and user friendly. It's important to note I only have 2 computers. I need people to run these projects on their computers and report back to me. Please don't be vague. I need your CPU speed, graphics card info, and exactly what happened, that includes when it works great. You can reach me at mattbettcher@gmail.com.

Also please let me know what samples you would like to see. Don't say things like "real-time fluid simulation", that's just crazy LOL. Also I won't write a whole game for you, but I can get a good list of stuff to add to the samples we already have.

Jan 10, 2010 at 12:54 PM

Brilliant update guys :)  
Simply Brilliant.

Well matt you wanted to know about any features that we wanted so I thought I would list a few.

"Union/Subtract polygons Boolean polygon operations to add and subtract polygons from each other."
As well as this would it be possible to have a way to cut one polygon with another. So instead of subtracting it cuts along its polygon and splits the others under it. Phun does this in its physics engine and can be quite useful.
Like this... 

Also I was wondering will there be any support for particles that can collide with objects and stuff but cannot collide with each other and stuff. Would there be any optimizations that could be made for them if this was the case or should we just use small cubes??

Also what about breakable objects? Perhaps that can have logical groups of triangles break off them if a collision was heavy enough? So a star would have its tips broken off it there was enough force applied?

I also wanted to ask you guys if real circles were slower than fake ones with 30 or so verts or if they have any other distinct disadvantages over vert based ones??
From what it looks like in the source we are using a DynamicTree for the broadphase, what are the significant differences to the default broad phase in farseer 2? Will this dynamic tree be better for the 360 and its fairly odd performance characteristics?

My internet is down at the moment (I’m on my mobile) so doing stuff is a bit of a pain right now but later I will test all the samples on my pcs and stuff and give you all the details... What samples/areas of your code did you need data from? The new rendering code?
I can run it thou my profiler too on a couple machines and give you the timing outputs etc... if you want.

As for the samples I think that there should be about 7-10 simple ones and 3-7 advanced ones each showing just one feature or item.
Perhaps a couple showing just the real basics then one for the sleep controller then some simple path ones then perhaps a "Bridge demo with some objects littered on it" then maybe one of those crazy walker things then a gravity sensor then a fake soft body would be cool (just using springs probably) then tank treads etc..
I don't know I’m just thinking they should all be moderately simple and each on dedicated to just one thing except perhaps the last one which could show some things working together maybe?

Anyway I would love it if you could both try to answer some of my questions (I know there are a lot) but anyway 3.0 looks very very promising and I look forward to trying to help on it as much as I can in the future.

Developer
Jan 10, 2010 at 5:07 PM

@danthekilla:

1. It would certainly be possible to add a cutting feature to the polygon operations.

2. I did a test in FP2.0 where I added collide-able particles to the simulation. In my test I made rain that would last for 2 - 3 bounces before dieing (You know what I am talking about if you know particle systems). It was quite fast and I will definitely look into adding a particle shape to FP3.0 or some form of particle. I have tons of ideas on how to implement it.

3. Breakable objects are something I tried very hard to add to FP2.1 and failed. With the new power of FP3.0 I think this could become a reality. FP3.0 already has a demo showing how to implement breakable bodies using multiple shapes, but it can definitely use a better approach.

4. Real circles are very fast and they roll correctly, unlike circles in FP2.1. The only disadvantage I can think of would be once we implement breakable objects real circles would have to be replaced with fake ones to be broken apart.

5. The DynamicTree eliminates all world size constraints and seems to be quite fast, even on the 360.

6. All of my mods so far have been to get a new rendering engine working as FP3.0 now uses meters instead of pixels. I really just need to make sure it's working well across a wide number of different hardware. Also I will be adding a SpriteSheet feature soon so objects can be animated. This feature will not control the animation however so if someone wants to write an animation controller feel free.

7. The samples will be organized like the previous FP with Simple and Advanced being separated. I know there will be a few performance examples, but most will be simple examples showing how to use a feature.

I hope this answers most of your questions. I'm sure Ian will post in the near future. Just so everyone knows these features cover one line on the page here, but in the engine they can span thousands, so every bit of help is appreciated.

Thanks

Coordinator
Jan 10, 2010 at 9:06 PM
Edited Jan 10, 2010 at 9:11 PM

1. Yes, and I've been looking into that using some old code I once created for FPE 2.x. I use the raycasting feature and simply use the entry and exit points from the result. I will update the original post with this feature and take another look at it when I'm done with the convex decomposition.

2. I believe that it is Physics2D.net that have particles. A particle shape could be handy, I think it is a bad idea to include particle-system features in a physics engine, but if the particle shape itself is added to the engine, a particle system could be hooked up to the physics engine. I've also been thinking about dynamic lines (I think it is Chipmunk that has them).

The problem with particles is that they should not have a bounding box and you can't calculate proper physics reactions on particles vs. particles. It is possible to do a polygon vs. particle test and apply a proper physics reaction.

3. The way that Box2D does breakable bodies is to calculate the max impulse on collision and if it is over some threshold, it disconnects the bodies. I'm sure we can find a better way of doing this. Maybe with a controller? FPE 2.x has breakable joints instead, but joints are soft constraints compared to two fixtures sharing one body.

I think it would be great to have automatic breakable bodies. If you mark a body as breakable, it triangulates the body and creates several smaller bodies fixed together. Feel free to comment on this.

4. As Matt wrote: Real circles, raycasts and AABB checks are very cheap. Most of our shapes (capsule and the like) will be emulated using polygons, but it is actually possible to create real capsules as long as you have an algorithm to check if a point is inside a capsule. (essentially two (half)circles and a rectangle).

5. Again, as Matt wrote: The dynamic tree has removed some limitations compared to the old broadphase that Box2D used. For now we stick with the dynamic tree broadphase only. In the future we might have a look at implementing more algorithms that are optimized for special cases.

----

FPE 3.0 will still have the same simplistic approach to samples as 2.x had. We must remember that physics engines are not easy to work with and all the features are overwhelming to new users. A simple step by step strategy with the samples will make it easier for our users to learn the physics engine. Users that need more than just the basic collision system will also have that possibility.

I'm thinking something like this:

HelloWorld
Very simple integration of Farseer Physics into a XNA game. This is mainly to those new to both C# and XNA (and physics engines). This sample only shows what is necessary to make two objects collide and be controlled using keyboard or gamepad.

SimpleSamples
Contains the most simple features of FPE 3.0. This includes Force, Torque, body types (static, dynamic), sleeping, collision callbacks and joints. They should be build with reusability, flexibility and readability in mind. Much like the current SimpleSamples, but with a better and more polished structure/looks. (I'm also thinking debug view here Matt ;) )

AdvancedSamples
Contains the more advanced features of FPE 3.0: Boolean polygon operations, joint combinations, path factory, controllers, triangulation and specialized interactions with the engine (One-way collisions, damage calculations and the like)

TestBed
This will be with the same structure as SimpleSamples and AdvancedSamples. It will be our (developers) testbed in the sense that when we create something new, we can create a sample that tests the functionality. It is also a good reference on how to use all the functionalities of the engine.

------

Obviously only the SimpleSamples and AdvancedSamples needs to be released and maintained like a release. The Testbed will stay inside the source control and the HelloWorld project will be uploaded somewhere and updated to the newest version of the library when it is released.

Coordinator
Jan 10, 2010 at 9:17 PM

@Matthew: I was just thinking about the debugview. Now that we have the chance, we might as well take it all the way and make it absolutely perfect. (Or an approximation of perfect. ;) ).

How about we include a way of enabling and disabling drawing of different structures? AABBs, contacts, normals, dynamic/static/sleeping/kinetic states and more. We could toggle the features using F2-F12 (F1 to enable debug view) and give a visual response of the toggle.

 

Jan 11, 2010 at 10:30 AM

Yer matt that is exactly what I was thinking of when I meant a particle shape. Something that just collides with other objects but has no mass etc... Rain is a brilliant example (I was also thinking a flame thrower in a platformer could work well with physics particles) what kind of things could be done to speed up a physics type such as this? As I imagine performance would be its biggest bottle neck.

Also it is great to hear that "real circles" are just as fast as fake (or faster) but while being far more accurate.

I agree that a way of automatically breaking up bodies would be good. Something that can pre sub-divide (in the case of a box) and split up a polygon and then when a impulse over a certain amount hits the object it could just break off one of those pre created objects.

Also I think that having parts of the debug view useable using f2-f12 would be useful too, but things like this should perhaps happen only with a debugger attached or only in debug so that the overhead for timing farseer is not in programs for people that forget to turn them off?? I forgot on my first game and later when I profiled it I found that about 4-7% of farseer's time was on its debug stuff (Not much I know but it’s the little things that can add up)

I think that a sample system like that would work well too.


Anyway it’s looking good and my internet gets put back on in a few days so I will do some testing of the new things in 3.0 (new rendering etc...) then.

Coordinator
Jan 11, 2010 at 11:14 AM

Ok, I will look into the automatic breakup for future versions. It might be included in 3.0 depending on if the elements required to make it work are there.

As for the debugview and overhead. I know matthew is doing his best on optimizing the performance of the debugview. The thing about putting the timings inside a DEBUG compiler condition is that optimizations are not enabled when in debug mode (or debugger attached). This could create a situation where the timings are wrong because some parts of the engine are manually inlined and optimized and others are not.

Perhaps it should be included in the Settings file? since the settings inside the file are constants, the compiler will optimize any "if (false)" away.

Coordinator
Jan 12, 2010 at 8:28 PM
Edited Jan 12, 2010 at 8:29 PM

Update:

I've been working on polygon decomposition using different algorithms. I would like the concave polygons to be automatically decomposed if the user wishes it, the tricky thing about this is that we can't expect anything from the input the algorithm gets. There are a lot of things that the algorithms and Box2D in itself does not like:

  • Concave polygons! - Box2D does not work with those
  • Collinear points - Box2D does not like them because the convexity check in Box2D works from segment to segment. It can't distinguish collinear points from a concave polygon
  • Point count higher than 8 - Box2D default. It works with 8 points at the time for optimal speed. The number is user defined and can be set as high as needed. Still, we have to adapt the algorithms to conform with this number.
  • Holes in polygons - A classic problem in geometry.
  • Complex polygons - Polygons that overlap itself and the like. It does not like point clouds either!

The good news is that I'm checking all those things to make sure the engine behaves great in any situation you give it. We do this my normalizing your data and throw errors if we can't use the data (like complex polygons).

See our old algorithm here and the new one here.

That is not the only news. I've also managed to improve the performance of our tools by optimizing the methods used to calculate the centroid of polygons and the like. Here are the old and new algorithm for calculating the centroid:

old: 12173 ticks {X:9.895511 Y:7.830241}
new: 4083 ticks {X:9.895511 Y:7.830242}

The ticks are the timer ticks needed to calculate the centroid. The X and Y after the ticks are the coordinates of the centroid of the polygon shown in the pictures above.

Coordinator
Jan 13, 2010 at 11:39 PM

Update:

I've finished including the Melkman based convex hull algorithm from FPE 2.x and included a new Gift-Wrap based convex hull algorithm to our arsenal of tools. I have the Earclip algorithm (from FPE 2.x) completely refactored and working along with the Bayazit algorithm. Our list of tools is expanding and next on the list are the boolean polygon tools. This include a tool to reduce the number of polygons by merging duplicate points and edges that are collinear. Very important to have such a tool when working with FPE 3.0 internals (see previous post for details).

We are not going to support non-simple polygons, but I've also included a tool to test for polygon complexity and convert a complex polygon to a simple polygon. Might come in handy at some point.

I'm updating the original post with the new updates.

Jan 15, 2010 at 1:22 AM

I want to translate this Engine to iPhone OS. XNA is not exciting plateform as iPhone.

Is there anyone who also have this thought?

Coordinator
Jan 15, 2010 at 1:04 PM

The closest to iPhone that I know of i Microsoft Surface. One of our users ported FPE 2.x to the Surface platform with multitouch. I don't know of any iPhone ports yet. I remember reading that .net applications somehow could run on iPhone, how is that possible?

Jan 15, 2010 at 1:22 PM

i have made some iphone games and some xna games and the xna one have been about 50 times more sucsesful. Simon i would try xna first so you don't have to deal with the iphone app store which makes programmers sad :(

There is a wrapper for xna so it can run on the iphone but it is quite slow as the iphone isnt ment to be used that way (expesially graphics) but it only gives you access to the zune part of xna so farseer wont run anyway. as it dosnt run on the zune :(

Maybe try the iphone box2d ?? its limited but adding what you need would be easyer than porting farseer i think.

also great work genbox with the polygon decomposition stuff really great work.

Coordinator
Jan 15, 2010 at 6:46 PM

Thanks danthekilla. Are you sniffing around in my code? ;)

To be honest, I don't think that convex decomposition is the right solution to the problem (in most cases). I'm really thinking about finding another narrow phase algorithm and add that to the engine, just like FPE 2.x. The problem with distance grid is that it takes some time to compute it, so it can prove difficult to create objects on the fly, however, the same problem exists with SAT narrow phase with concave polygons. I would think that the time needed to decompose polygon can be larger than calculating a distance grid. + there is a huge overhead of having 100 objects instead of one, and it creates all sorts of funny behaviors.

Anyway, I will get the things on the todo list finished first, then I can take a look at all the other stuff.

Jan 16, 2010 at 4:16 AM

Physics2D.NET, which I use in Boxycraft uses a distance grid, and I find it really troublesome. My editor allows you to create objects of any size/shape, and this makes it difficult to find the right settings. I've found that the time it takes to triangulate a large shape is usually nothing compared to the time it takes to calculate the distance grid.

How well does your decomposing work, in terms of generating as few polygons as possible? And also, How bad can the funny behavior be, I don't have any experience with it?

Coordinator
Jan 16, 2010 at 9:36 AM

As all algorithms have, the distance grid also have up and down sides to it. The goal of a physics engine is really to balance the equation of positive and negative and in order to do that, we could provide several different algorithms. To give an idea on what we are up against, I've made a list of up and down sides relative to our goal:

Goal: Provide support for both concave and convex polygons with focus on performance.

Distance grid: Support for both concave and convex polygons.

Up side:
- Number of points does not matter in terms of performance
- Good performance with both types of polygons

Down side:
- All calculations are done at the creation of the grid. The good thing is that it is only done one, unless you change the shape of the distance grid.
- Grid cell size can sometimes be too large and needs to be changed to something smaller.

SAT: Support for convex polygons only

Up side:
- Fast with concave polygons
- Polygons can change on the fly

Down side:
- Number of polygons matter in terms of performance (fewer is better)
- Needs convex decomposition in order to support concave polygons (and that has a ton of problems in itself)

---

Now, as you see, they are very different algorithms and some would use the first one, and others the second one. Unfortunately there are no perfect algorithm that combines the features that both algorithm have. So I'm thinking about providing both in the engine and then it is up to the user to choose the other if needed.

As for the problems with decomposing concave polygons, there are quite a few:

1. It takes time. The texture that I use to test it on is the same on used in the AdvancedSamples (Texture to vertices sample) and it takes around 8 ms for the bayazit algorithm and 30 ms for the earclip algorithm to decompose it.

2. The seems. The places where the convex polygons join there is a seem. First of all, this seem can create some weird behavior. Imagine a floor with a small hole in it. If you let an object move along the floor, once it hits the hole, the object jumps. That is what happens with seems in this kind of physics engine.

3. Sub-optimal decomposition. If you need an algorithm to be fast, you have to create sub-optimal solutions. You will always end up with a large number of sub-polygons if the polygon you decompose, has a lot of arches. There are also cases where there are no solutions and wrong solutions.

---

I hope that shed some light on the subject. As for 3.0, the only narrow phase algorithm will be the SAT algorithm, then we will see where we go from there.

Coordinator
Jan 16, 2010 at 4:57 PM

Update:

David Lévesque is one of our new developers. He is helping out with the development of the engine and has just started to convert the joints to fixed and non-fixed joints, just like FPE 2.x has it.

I'm updating the original post with this so you can follow his progress.

Coordinator
Jan 16, 2010 at 9:28 PM

Update:

While David is working on the Joints and Matthew is working on the DebugView and samples, I'm going to implement a controller structure and implement some force generators. I would like to thank Matthew and David personally for helping out. You guys are great!

Jan 16, 2010 at 11:27 PM

This seems to be moving steadily forward. Can't wait for it to be finished!

Keep up the awesome work! :)

Jan 17, 2010 at 12:42 AM

Hey genbox how are you going to do the force generators?

The point gravity (a user submission i think) was basicly a for loop around every object in the physics sim and it did a few distance checks and then if within a certain area it applyed the point physics, is this how farseer 3.0's one will work?
In farseer 2.0 i made my own point gravity that was added into the broadphase (not much of an overhead i found) with a sensor and then it did the physics in its oncollision function. I found this to be much faster when having 10+ gravity wells i was just wondering what your plans were for it?

Also i made a motor for farseer 2.0 that didnt need to have 2 objects (working like a pin) or 1 object that stuck the item to the world, it was a motor joint that needed only one object but did not pin it to the world (Good for just applying forces or for making a car out of springs instead of pin motors) could we have something like this in 3.0?

Coordinator
Jan 17, 2010 at 1:07 AM

I'm working on the force generators and I'm still figuring out the best way of doing it. I do have a system in mind tho - it contains per body logic filtering and stuff like that.

I've already added a standard gravity controller as the one in FPE 2.x. It does nothing fancy using sensors or anything like that. The current implementation is O(n^2 * B * P) where n is the number of bodies inside the simulator, B is the number of attractor bodies and P is the number of attractor points. Worst case is O(n^3 * P), but then again, the gravity operations are not too expensive and it can handle a lot of bodies at he same time.

In 3.0 we have two options to lower the big O:

1. Use query

The broadphase has a query function where you supply an AABB and it will find all the Fixtures in that area. I'm not sure about the big O in the dynamic tree, but since it is a tree, it must be around O(log n) and O(n) worst case.

2. Use sensors

Using sensors has more overhead since it actually report the contacts detected. You can have a circular form instead of a rectangle as used in the query.

 

If you want to give it a try, feel free to update the gravity controller to use one of those solutions. It would be great if you could provide before and after benchmarks for me and others to see. There might be a game or two out there that uses the gravity controller for everything and can make use of a high performance gravity controller.

As for the motor, I'm not sure exactly what you mean. Could you explain how it works/what it does?

Jan 17, 2010 at 6:01 AM
Edited Jan 17, 2010 at 6:02 AM

Well you know how there are 2 types of motor in farseer 2.0 at the moment (User submitted i beleve)

The fixed revolute joint motor that requires 1 body and makes the body rotate around it but be fixed to the world.
The revolute joint motor that requires 2 bodys and one rotates on the other.

Well i added a 3rd kind that isnt actually a joint at all, it dosn't fix any object to the world or another object, all it does is apply, regulate and manage rotational force like the other motors do.
This allows you to have a motor on a circle for instance that will just spin but not be attached to anything.

Its kind of like a decoupled motor, that can be attached by itself or with other real joints.

The reason i made it is for the game i have been working on for 5-6 months.

One of the biggest issues we had was that the most recent sat version of farseer (4 months old now) while being very very fast had a bunch of issues with thin triangles or any angle in a polygon under 30`degrees so we created some code that would detect these splinters and fix the polygons to stablize the simulation. We have also created a much better sleep controller that uses rotation as well as movement and takes into account the size of the object instead 1 fixed size for all wakeing and sleeping. We also have the decoupled motors and many other things like gravity controllers etc...

Once the game goes up we are happy to give away any changes that we made to farseer to anyone that wants them.
(Pritty much none of the changes would be usefull in 3.0 but maybe it might help some people that will still be using 2.1 in the future?

 

Here is a video. It is called physics lab and uses farseer 2.1 for the menu systems and a custom version (about 35% rewritten) for the games physics.

http://www.youtube.com/watch?v=YtgyCHp-Gzo 

Also we put a few menchins of farseer in the games credits hope thats ok.
I might make a small post about the game when it goes up (hopefully within 1 week)

Jan 17, 2010 at 6:10 AM

Sorry the video link was bad before.
Also this is a very short non finished trailer.

Physics Lab Trailer

 

Coordinator
Jan 17, 2010 at 1:25 PM

That makes sense. It could also be good for character control. Let's have a look at it when you are have the time for it then. I might try out the gravity controller based on sensors, just for fun.

I'm working on the FluidDragController right now and might implement it there too.

Coordinator
Jan 23, 2010 at 2:45 AM

Update:

Just a quick update on what happens. I've been working on the buoyancy controller and it has been giving me some problems. I finally found the bug that have been bothering me for quite some time (a whole week actually), I will fix it tomorrow together with some updates to the Fixture, Body and Shape class that makes their equality checks faster and more reliable.

If I get the buoyancy controller working, I will start working on the force and game-logic controllers. If I get the time I will work on some performance improvements to the controllers. (The ones that Danthekilla mentions - using the broadphase)

More updates will come soon.

Coordinator
Jan 30, 2010 at 8:36 PM

Update:

Erin from Box2D has overhauled the CCD code of his engine to get a more robust CCD implementation. The guys behind Box2D.XNA are already updating to the latest version of Box2D (rev 40, released today). It contains a lot of bugfixes along with the new CCD code, once they are done with the update, I will port over the changes to FPE 3.0.

I've included a class called CuttingTools that includes a method of cutting shapes. I've also added a small test to show how this works. I will work a little more on the code and test tomorrow.

I think too much time is going to be used on implementing the controllers. I will leave it up to users themselves to implement their own controllers. I'm changing its status to done and strike the items of the list.

Jan 31, 2010 at 7:16 AM

Very nice Genbox, I got excited shivers playing with the testbed! And I lol'd at the Teo Jansen Walker! :D

I can't wait for all those features and I think you're doing an awesome job!

Feb 1, 2010 at 10:22 AM

The testbed and speed improvements are awesome, keep up the good work!

Feb 3, 2010 at 12:54 PM

Genbox, the improvements are looking very nice. I have one question though, right now I'm on a quite advanced stage on my game, but I'm not sure if to freeze it (at least in adding new features) until version 3.0 is out, just for updating the engine then. My question is, v3.0 is going to have the same features (or more) than 2.1? How different you expect that the methods will be?

Thanks! And thanks to everybody who is contributing to the engine (BTW: I'd love to join, but I'm a very bad coder, and my english is quite bad for the documentation, if I find how can I help I'll let you know)

Coordinator
Feb 3, 2010 at 10:45 PM

I would go ahead and use 2.x for the game if I were you. There is no telling on how long it is going to take 3.0 to come out. Feature-wise, the 3.0 version will have the same features as 2.x and more. Some of the tools from 2.x have already been ported to 3.x and some new features are being worked on. If you used the factories API from the 2.x version, the 3.x should not be much different. Some properties have other names and some of them are not in the same place as before. I hope to keep the FPE 3.0 classes close to the Box2D classes, but remove a lot of the complex and rarely used stuff to make the engine simpler to use.