Box2D Forums

I guess the Testbed main class is a bit hidden (and TestbedMain is a badly named trait). It's because all slick-dependent code is in a separate package. The wiki page I linked to did list it though:
org.villane.box2d.testbed.slick.TestbedRunner



I'm aware of that, but it's a bug in the Netbeans Scala plug-in and hopefully will be resolved soon. I will probably reduce the usage of unicode chars in the near future though.

Ok so I haven't tried ScalaBox2D again yet, but I got an OpenGL demo working with Scala and LWJGL using Eclipse. The process for adding libraries is similar in both programs, and I found guides telling exactly how to set each program up to use LWJGL, Netbeans just doesn't work though. Buggy POS! My advice to anyone looking at Scala is to use Eclipse (even though Netbeans supposedly has better Scala support, except the erm...not working part). Thanks for your help!

I would have to respectfully disagree with that statement. I've spent a lot of time with both Eclipse and Netbeans, and they each have their strengths and weaknesses. However, my Netbeans setup is working quite well at the moment. I recently switched from Eclipse (again) because the bugs in Galileo were driving me nuts.

Both IDEs are fully capable, and subject to personal preference. I think it's disingenuous to single one out as a POS; remember that both are FREE and open source. If you want commercial quality, you can always shell out for IntelliJ.

Well, Eclipse at least is supposed to be commercial quality. The vendors who work on it do it because it's the platform for their commercial products. If they fix bugs in Eclipse, they fix it in Eclipse, not in their own product. I just think that as features and the complexity of it increases, the number of bugs do as well. And sadly the Eclipse developer community (with some exceptions) doesn't care that much about usability, or even end users. I'd love to see a platform like that built with as much focus on usability as Apple's products for example.

PS. I've used IDEA in the past and have tried out each new release, but actually I prefer Eclipse even to IDEA. Yes, it's just personal preference, mostly because I just like the UI better.

There is a work in progress library ScalaCL http://ochafik.free.fr/blog/?p=207 which lets you write Scala code (an internal DSL) that gets compiled to OpenCL programs at runtime, which then get executed on the GPU. This is useful for small chunks of code that can run in parallel. I think it's pretty awesome to be able to write OpenCL code in Scala.

It would be interesting to use this in ScalaBox2D, except I think it's hard to find code to parallelize in a fine-grained way in Box2D. What do you think?

Has the dynamic trees broadphase been ported? Some of that stuff can benefit from concurrency, while not being a large chunk of code.

1) This Scala wrapper is freaking awesome. I've avoided OpenCL up until now because it was going to cost me more in development time than it would save me in compute time, but the wrapper is unbelievably straightforward.

2) We discussed parallelizing Box2d computations a while back, and I believe the way it worked out was as follows:

- Each island can be stepped independently without much trouble, so that's easy
- Each island can be solved independently, so that's also easy
- Even within an island, we may be able to get away with solving each (possibly conflicting) contact independently and just ignoring the fact that it's happening concurrently, because the solver is pretty much agnostic to the order of contact evaluation and using a slightly stale value as an input is not going to make a major difference. This was never tested (or at least it was never shown to lead to a speedup, I think I tested the behavior and it seemed okay, but I couldn't get any speed bump without some massive restructuring of the Java code because of thread creation overhead).
- The old broadphase was pretty much impossible to parallelize

This is probably my OpenCL ignorance shining through, but my main question is: how tiny does each computation have to be in order to get a benefit from pushing (many copies of) it through that pipeline? I've always been under the impression that graphics card processing is only useful for situations where you have a simple set of vector operations that needs to be applied thousands of times, without much actual logic going on, in which case we're not likely to see very much improvement.

I wouldn't be too eager to introduce this dependency in the Scala Box2d, even if it did help - it ultimately relies on native code that can't run on a lot of machines, which means a whole lot of headaches (no unsigned applets, for one, also a messier build, probably getting into even weirder stuff if you want to support machines without OpenCL abilities).

Not yet.


I have a similar impression. Haven't actually used OpenCL yet.


Yes, it would definitely have to be optional, maybe an experimental branch if it can't be just an implementation selection at runtime. Not that I'd like maintaining two branches. In any case, I'll finish other things first, before messing with this.