Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Game Mechanics / Re: Java port of Bullet Physics Library on: 2009-07-13 08:56:01
Well, jezek, it's excellent work, thank you for it! I was thinking about creation some kind of simulation library for my project by myself, but port of Bullet most likely is preferable.

I make small demo, with box, bordered by 4 static planes, and several (7-10 is enough) bolls moving in it (billiard, you know). No friction, no gravity, DiscreteDynamicWorld, AxisSweep3 broadphase, SequentialImpulseConstraintSolver, and so on -- mostly copied from your demos. And it shows quite strange behavior.

 1. Energy ( =sum(m*v^2/2) ) does not conserve. Even not close to it. Every collision change total energy of system. For my expirements it's constantly increase, so, after 5000 iterations or above energy increases about 30 times! Even if I decrease simulation step to 0.0001 and use rather small initial velocities (about 5-7m/s). I've noticed, what 1 ball, even with step 0.01 is rather stable in it, so errors seems to rooted in sphere-sphere collisions.

 2. Although sphere-sphere and sphere-plane collisions are totally symmetric (forces are applied to mass center), and they was not given initial rotation (angular velocity), after collisions angular velocity tends to grow up. It means, angular momentum is also not conserve. I do not know, may be it's known limitation of used algorithms, but it also may indicate some errors in it. Again, 1 ball is rather stable in it, so it seems to be a feature of sphere-sphere collisions.


2  Game Development / Shared Code / Re: JStackAlloc - stack allocation of "value" objects in Java on: 2009-07-08 14:31:43
In full fairness to the engineers that made these recommendations (I seem to recall a flurry of them in about 2005), they were only about 10 years early with them - I fully expect that by the time Java 8 rolls around, escape analysis/stack allocation/scalarization will be performing on par with manual object pooling.
Well, it seems, (http://www.ibm.com/developerworks/java/library/j-jtp09275.html) that java 1.6 already has such feature like escape-analyze based stack or even registry allocation.

jezek2, is there any way to use this library in a form where it can degrade gracefully (i.e. turning all pool pulls into plain old allocations) in the absence of instrumentation, or is that just not a realistic possibility given the way it's set up?
I'm sure, it's the question every developer thinking about integrate the library ask first Smiley
3  Game Development / Shared Code / Re: JStackAlloc - stack allocation of "value" objects in Java on: 2009-07-08 12:31:48
Well, I'm not sure if I really want this library to be widely used. I've made it for extreme case of allocation of many tiny objects and published here so someone other who will fall into the same situation can use it. Otherwise HotSpot is very good at allocations, so I don't recommend to use this library in normal situations. I've also used it in some other libraries, but I'm considering to remove it from there as the amount of allocation is not that much.
Well, yes, JIT and GC becames more and more powerfull each day rise. Years Sun engineers adviced not to use object pools just to improve memory allocation, 'cos it does not give the bonus, but only confuses new GC algorithm (it was time generation GC was introduced). So, after years, I was surprised you was able to gain perfomance bonus from such a method, but it is -- and why do not expose it to community? May be it will speed up Sun's JIT enchancements at least Smiley

But if do this, it should be done in the way, which can be easily rolled back if JIT at last become smart enough to do the job by itself. I'm near to sure, what code like this
1  
final Vector3f v = Stack.alloc(Vector3f.class);

will greatly complicate escape analyze job for such "smart" future JIT. So in current version, gaining perfomance bonus for now you'll likely close the way for you code to gain perfomance boost from future compiler allocation optimization.

By the way, can you summarize the perfomance boost you gaining now? Just to be oriented in then and there to use you library
4  Game Development / Shared Code / Re: JStackAlloc - stack allocation of "value" objects in Java on: 2009-07-08 08:58:43
This syntax is not possible, the closest one is:
1  
@StackAllocation Vector3f v = new Vector3f(...);

Yes, sorry, I've forgot about exact syntax for statement annotations -- they are rarely used, as for me.

Interesting idea, though I don't like the annotations syntax for this. I consider the stack allocation as a core feature that shoudn't be optional as it changes the memory behaviour a lot. This is reason why it throws Error instead of some sort of fallback, users would then accidentally run slower/worse path. Also I like it in this explicit way because it tells something special is occuring and not ordinary allocation, such as the case with constructor with argument (or without), the programmer can be misleaded to think that the constructor is actually run or assume that the values are zeroed whereas it's not true.

Well, I agree, your point of view is completely legitime. I just think it's more about your specific use case. As far, as I understand, stack allocations was a critical feature, letting you to port C code to java without great rewritting it to refactor memory usage strategy. So it's really "something special" and "core feature" in your case. But if you want your library to be public used (as for me, it worth it -- it's small, easy, and do the work well -- that's more?), just try to look at it from point of view of developer, thinking about incorporate stack allocations in existing code. In current form, it can't be called non-obtrusive. One should make rather big changes in code, and live with fact, that code won't be ran without instrumentation.  It's makes a high barrier for such decision. From other side -- add annotations to some of statement is not a big deal. Anyone can just do it and be sure, what without special processing such annotations do change nothing in current behavior (and, most probably, even completely removed by obfuscator, if used). As for me, it makes decision "to use or not to use" much easier.

For example. Ive' just downloaded JBullet and exploring sources. I can't run it from my IDE without instrumentation -- although I just want to debug it to clearify code paths, and it's ok for me to have code run slow...

As for "changes the memory behaviour a lot" -- well, think of it from that point of view: memory behavior may be changed a lot by jvm GC options given at startup. It's gives you, in some cases, really big changes in memory behavior, and you really do not see nothing about it in code. It can be chaned by JIT -- and, again, you'll se nothing about it in code. It's java -- memory behavior is much less predictable at all, and I think, most java developers already learn to live with it. You even can't be sure, that new Vector3f() do not actually do the stack allocation by itself -- being optimized by JIT (well, may be for now you can -- such optimizations usually described in Sun's jdk's preview -- but for future... we all waiting for it). If jdk1.7 (8,9..) will include such optimization, one can just remove instrumentation step from it's build process, and letting jit do it's best. While currently one's left with some "strange" legacy code in allocations, which can confuse JIT in it's optimization, and confuse junior developers in understanding "wtf is happens here and why?"

To summarize -- I suppose, annotations-based instrumentation can be added as an option. If someone want stack allocation to be explicit -- it'll have such option. If for someone it'll be easier to add it in non-obtrusive way -- the option will also be here. Nobody can escape. Your library will conquer the world! At least, java part of it Smiley
5  Game Development / Shared Code / Re: JStackAlloc - stack allocation of "value" objects in Java on: 2009-07-07 19:42:03
Excellent work, jezek! JBullet at all, and JStackAlloc particular is very interesting. But I have a thought and idea -- why it's so explicit in code level? If you already use so powerfull method as bytecode instrumentation, why not use it like this:

1  
final Vector3f v = @StackAllocation new Vector3f(...);

and translate in into the same magic on instrumentation phase? From my current point of view, annotations gives you the same possibilities, as your explicit Stack.alloc, but they
  • have no influence on perfomance in case code not instrumented. They just slightly increase class-file size
  • do not require instrumentation. If code not instrumented, it just execute as written.
  • one can use instrumentation in realtime -- on classloader level, and even switch between optimized/not optimized version in realtime!
  • it's subject for more compile-time checking. For example, code like Vector3f = @StackAlloc new Vector3f(v1) simply won't compile, if Vector3f does not have copy constructor. (Unfortunately, it does not save us from missing or misimplementing .set(Vector3f) method...)
  • it's declarative, for me it looks much more elegant

That do you think?

Ruslan
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (59 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (86 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!