Box2D Forums

How is this project progressing? I've recently taken an interest in Scala and would like to see the code.

Other than potential for concurrency and multithreading, what are the advantages of functional programming in Box2D? How will an optimized Scala port compare to jBox2D, considering both run on the JVM?

The code is now available: http://github.com/Villane/scalabox2d/tree/master

However, please consider:
* it's for "early looks" only for now. The code needs clean-up and optimizing.
* no test-bed, that will come soon.
* it's currently slower than JBox2D (even 2 times slower, for example in the pyramid test while it hasn't settled)
* I'm investigating the performance issues, but it'll take time

Some notes about changes compared to JBox2D/Box2D

Packages:
vecmath
* put the vector/matrix math in a different package outside of "box2d", that should be also usable without the physics engine. Also renamed the classes, and everything in the "vecmath" package is immutable.
* separated box2d.collision into "collision" and "shapes" (seemed to many classes for one package). Not sure if I got everything right about that.
* moved DebugDraw to "draw" package
* "common" package has some currently unused classes
* a couple of other classes were renamed or moved to different packages as well, but the majority of the classes are named as before. If it helps, I could make a detailed list of all renames/moves.

Naming & code changes:
* removed lots of m_ prefixes from members. This caused some local variables to have the same name as members -- in those cases I shortened the local names.
* removed "get" from many method names.
* replaced some constants and variables with actual unicode greek letters, such as π, ε, α, ω. Not sure if it's a good idea, as these aren't exactly on most people's keyboard, but I left the spelled-out alternatives for any special characters in public methods or constants.
* named Mat22.mulT to ** . Not sure why I chose that, there is probably a better symbol for the operator, I just didn't come up with one when working on that so it kind of got left like that.
* Removed most of the semicolons, maybe that wasn't very smart as it's just more changes between the two versions. Looks more Scala-ish, though

Warning on operator precedence: special characters have the highest precedence in Scala (higher than * / ), letters have the lowest, so these are different:
a + b × c == a + (b × c)
a + b cross c == (a + b) cross c

Excellent work!

I'm definitely willing to give you a hand if you would like. Having ported Box2D to the D programming language, I'm very familiar with the engine. It will also be a good opportunity to dive into Scala.

My primary question in regard to performance: Considering Scala is a functional language, and every operator is a function itself, how much overhead is involved in all those extra method calls? The great thing about D (and C++ with the inline keyword) is that most of the math functions are automatically inlined and optimized by the compiler. I'm not sure if the Java compiler automatically does this, although I know other ports such as AS3 hand-inline in computationally intensive places like the ContactSolver.

For example, in Scala:
1 + 2
is actually interpreted as (1).+(2)

Alas, am I barking up the wrong tree or should we trust the Scala compiler to do it's job?

I'm not sure if Villane comes by here much these days, but I can (partially) answer this - yes, there's a good deal of overhead, and the Scala port is quite a bit slower than the Java one. But...from what I know, cases like (1).+(2) are automatically inlined to 1+2, and they're only wrapped with the Int wrapper if you're doing other stuff (like in a for loop, you might write " i <- 1 until 10," and that (1).until(10) call is not perfectly optimized by scalac, as it requires actually creating an object, then calling the until method, and returning an iterator, etc., and it brings a lot more overhead along for the ride than a normal for loop in Java would).

I still have yet to track down exactly which parts actually contribute the most to the time the engine takes in Scala, though. I suspect it's mainly that the looping constructs are not as fast as they could be in general, but I'm not sure where else slowdowns might be coming from. The Java compiler tends to do very well at inlining and optimizing in general (it's tricky to do your own optimizations in Java because most of the things you'd think of, the compiler's already doing), but the Scala compiler could be doing a lot of things that block optimizations when it turns Scala source into bytecode.

Yes, I think one of the main problems is the for loops I used. I am currently switching most code to while loops and I've already gained some speed (but still behind JBox2D). Should have thought about this earlier. Also doing more manual inlining in performance hotspot methods (mostly in ContactSolver).
I suspect the fact that I used immutable vectors and matrices also has some effect on the performance especially when there are a lot of contacts.

I have to say I'm a bit disappointed with the Scala compiler regarding optimizations. So far I haven't noticed *any* effect from turning on inline and optimise switches, even when adding @inline annotations to methods.

BTW. Scala 2.8.0 is going to potentially lessen the amount of boxing of "primitives" (Int, Float, etc.) by generating specialized versions of generic classes for primitives (when there's a @specialize annotation on the class). So using for (i <- 1 to 20) {} loops is going to get less problematic.

For those who are interested, I'd thought I'd explain where I want to go with ScalaBox2D. It's a rather long post

Going back to the original goal
I may have forgotten some of my initial goals at some point. The original reason that I started the port instead of just using JBox2D is that I wanted the classes that show up in actual GAME code (Bodies, shapes, vectors etc.) to be as "good API" as possible, and following Scala conventions rather than Java ones:
v.x instead of v.getX(), case classes, immutable Vectors and so on.
I didn't think I could just replace those parts of JBox2D so I ported the whole thing. I must admit I'm not sure I've made as good a job with the API as I hoped, so some more changes may come.

I'm not actually 100% sure about the immutability of vectors any more. I think it's one of the problems with the performance, but I don't know how to measure it without yet again rewriting a whole lot of code. And from some viewpoint it might actually be better API to be able to say body.pos.x += 1 instead of body.pos += (1, 0). At the moment I'm still leaning more towards immutable though.

Performance
I don't want to keep improving performance while making the code harder to read. I'll keep doing some more optimisations for now, but eventually what I want to achieve is to keep all the math-heavy methods as concise and understandable as possible and let the compiler optimise things. Unfortunately I haven't found the time to learn how to write Scala compiler plug-ins, and I don't think the scala compiler itself can optimise away the creation of temporary vectors without a special plugin.

Current optimisations are going quite slowly. By now I've spent numerous hours with YourKit, but the effort that I have to put in to gain 10% is too much at this point and I'm making the code uglier, which is going against my original goal.

And it may be actually fast enough for many games. I know it is fast enough for the games I'm working on (they are on hold right now, though)

Unicode
Many tools still have problems with UTF-8, but I think they can be mostly configured to work with it. Even the Scala standard library has some methods with unicode characters so any tool for writing Scala should be able to work with unicode. So α, λ, π, ε, × and friends are going to stay for now and the more the code looks like actual mathematics, the better IMHO.

Anyway, user code does not have to use those special symbols, everything has a spelled-out alternative.

I know they are harder to type, but there are solutions: for example in Windows you can add the greek keyboard and switch to that with Alt+Shift. Most of the letters are where you'd expect (a = α, b = β etc.). I don't know what the solutions are on Linux or Mac, but they can't be much worse? I admit I don't know how to type ×, I've used autocomplete and copy&paste.

Maybe this is not reasonable, but I just like seeing that in code and maybe I'm not a completely reasonable person If more people start using this port and this is actually somehow hindering adoption/development, then I may reconsider

Do you know how to set up Netbeans or Eclipse to support this? When I was looking through the code a while back I had trouble getting either one to recognize the special characters.

I'm keenly interested in this project, by the way, I grow warmer and warmer towards Scala the more I use it; in fact, I'm trying to do as much JBox2d coding using Scala these days as possible (using the library, not developing it), it just makes so many things easier (I've been working up a wrapper to do JBox2d + Pulpcore using Scala; when it's in a public-ready state, I'll release that). Quite often in that process I've had an itch to throw a Scala class or two into JBox2d to clean up some API annoyances, but I think that would be somewhat unacceptable to those using pure Java.

Also, I apologize for never pulling in ScalaBox2D as part of JBox2d as we'd discussed a while back, it turned out to be a bit more than I had time to do; I'm really glad to see you've continued to think about it and work on it.

I wouldn't concern yourself overly much with speed at this point; if people are desperate for speed, they can always back off and use JBox2d, or go all the way and use C++ instead - my opinion even on JBox2d is that anyone doing something that the engine is too slow for is probably trying to do a project that's inappropriate for Java, and should be writing C++ anyways. I'd guess the Scala port is at least achieving AS3 performance, and that's clearly good enough for probably 95% of the games that use Box2d.

In Eclipse, all I had to do was set the workspace default encoding to UTF-8 (under Window -> Preferences -> General -> Workspace). But this can also be done per-project. I will investigate NetBeans soon, I haven't used it in a while.
EGit (Eclipse Git plugin) still gives me some trouble though.



No worries, I totally understand. I don't have time for half the things I would like to be doing

I agree that you should stick to your original goals and keep the API as clean as possible. Performance issues will be worked out in due time as the Scala compiler is optimized and you continue to work out bugs. In any case, the engine is "fast enough" for most practical purposes.

Scala is a great language and has been growing on me every day. I appreciate the functional style, power of the JVM, and all the Java libraries available. Hopefully the Scala game community will continue to grow.

The only thing I disagree on are the greek symbols. Most people don't have them on their keyboard and won't bother with setting up and remembering keyboard shortcuts. I personally don't mind the symbols, although NetBeans syntax hi-lighting is not working correctly. The Greek symbols are readable with UTF-8 turned on, although all the code gets underlined in red (like a spellchecker) which is quite hard on the eyes and annoying to read.

I can help with the demo framework if you like; it may be a good idea to add a nice GUI. There are a few libraries that are compatible with Slick.... At first glace FengGUI and Nifty GUI look promising.

In any case keep up the great work!

Does NetBeans allow you to see the sources of Scala's standard library classes? Even though the source attachment is specified for the library, it doesn't seem to open them in my case. I wanted to try if this problem also existed with the Scala library.

Anyway, this seems to be a bug in the NetBeans Scala plug-in, because I can use the greek letters (but not the cross/dot product symbols) in Java code with no problem. It seems to be already reported as well: http://www.netbeans.org/issues/show_bug.cgi?id=165659