Experimental Scala port

Discuss issues specific the Scala port of Box2D
Villane
Posts: 101
Joined: Mon Sep 01, 2008 6:32 am

Re: Experimental Scala port

Postby Villane » Mon Sep 07, 2009 3:51 am

brainclog wrote:So I think that part is resolved, although Netbeans seems to completely ignore the source for fenggui... There is no refresh like in Eclipse (or it's hidden), and sometimes it will do it on its own and sometimes...nothing. Anyhow I have a bigger problem, I create a new project and it has a Main already, and I can't figure out what your main class is for the testbed, assuming there is one. I thought it was TestbedMain, but it's just a trait... I am kindof a scala newb, but have read most of the book. I tried to call one of the scene singeltons like PlanetGravity.createScene and passed in my own world object. It compiled, but didn't do anything. I selected Run Main Project.


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

brainclog wrote:I have to say, the special characters (e, pi) are annoying. Netbeans likes to put squiggly red lines starting at a special character until the end of the source file, but it doesn't flag an error, just makes it impossible to read the source, even though it apparently supports unicode (and the character shows up correctly). Plus it would be difficult to edit source, although most people won't need to.


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.

brainclog
Posts: 185
Joined: Mon Dec 17, 2007 10:11 pm
Contact:

Re: Experimental Scala port

Postby brainclog » Mon Sep 07, 2009 12:26 pm

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!

Zzzzrrr
Posts: 103
Joined: Sat Mar 15, 2008 5:49 am
Location: Washington, DC
Contact:

Re: Experimental Scala port

Postby Zzzzrrr » Sat Sep 19, 2009 6:45 am

brainclog wrote: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.

Villane
Posts: 101
Joined: Mon Sep 01, 2008 6:32 am

Re: Experimental Scala port

Postby Villane » Sat Sep 19, 2009 2:41 pm

Zzzzrrr wrote: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.

Villane
Posts: 101
Joined: Mon Sep 01, 2008 6:32 am

Re: Experimental Scala port

Postby Villane » Mon Sep 21, 2009 5:55 pm

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?

BorisTheBrave
Posts: 1911
Joined: Mon Jan 07, 2008 10:51 am
Contact:

Re: Experimental Scala port

Postby BorisTheBrave » Tue Sep 22, 2009 12:29 pm

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

ewjordan
Posts: 803
Joined: Sun Sep 23, 2007 2:35 pm

Re: Experimental Scala port

Postby ewjordan » Wed Sep 23, 2009 11:23 am

Villane wrote: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?


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).

Villane
Posts: 101
Joined: Mon Sep 01, 2008 6:32 am

Re: Experimental Scala port

Postby Villane » Wed Sep 23, 2009 2:26 pm

BorisTheBrave wrote:Has the dynamic trees broadphase been ported?

Not yet.

ewjordan wrote: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 have a similar impression. Haven't actually used OpenCL yet.

ewjordan wrote: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).

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.


Return to “Scala”



Who is online

Users browsing this forum: No registered users and 2 guests