Flesh out QuickStart wiki

[GoogleCodeExporter]

We need to better document the steps to get started using JBox2D in its current 
form - it's not entirely clear how to get the testbed running if you just check 
out the project with no other knowledge.  If you just try to import the project 
into Eclipse, for example, it's not obvious whether or not to use the updating 
directory or the jbox2d directory, and it's a bit tricky to set up the project 
by hand to get it to compile the testbed.

Currently the lowest friction approach seems to be to use Maven (the log4j 
dependency is handled easiest through Maven), so we should explain how to get 
the testbed running using Maven from:

1) Eclipse (I added this to the wiki already, though it needs to be checked)
2) Netbeans
3) IntelliJ IDEA (this one is almost trivial, it Just Worked for me when I 
tried to open the project directory and let it do its Maven thing, and I had to 
do zero configuration)
4) Command line (? - maybe this is not something we should support...)

We should ideally test all of these on from-scratch new installations, and keep 
them up to date with each release.

We may also want to include info or an example explaining how to use JBox2D 
within an external project, though for the most part people shouldn't have 
trouble with this (just drop in the .jar).

Original issue reported on code.google.com by ewjor...@gmail.com on 9 Jul 2011 at 10:38

[GoogleCodeExporter]

Original comment by ewjor...@gmail.com on 9 Jul 2011 at 10:46

• Added labels: Usability

[GoogleCodeExporter]

good ideas, I think we should include stress tests for the command line, where 
one can specify the test (probably have a couple types for different needs, one 
with tons of objects, the other with lots of joints, etc) and pooling methods 
(something i'm gonna work on tonight) so someone can just throw the jar in a 
system and see how it performs

Original comment by toucansa...@gmail.com on 11 Jul 2011 at 11:51

[GoogleCodeExporter]

Good call on the stress test, it's always good to have, esp. because it really 
helps optimization - it's one thing to optimize based on frame rates, but it's 
something else altogether to have a solid set of tests that stress all the 
different parts of the engine and give you some numbers to check against.

I'd also love to put together a few tests that could be run on the AS3 and C++ 
ports, too, just to see how things compare - a physics engine is a pretty great 
complicated real world piece of software, so it makes for a pretty fair 
comparison of the speeds of different languages and runtimes.

Original comment by ewjor...@gmail.com on 12 Jul 2011 at 6:10

[GoogleCodeExporter]

I added some more info to the wiki page.

Original comment by toucansa...@gmail.com on 2 Aug 2011 at 6:03