Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
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] 2 3 4
1  Game Development / Game Mechanics / Re: JOODE Development Status on: 2006-07-03 19:00:01
Sorry, I did not use ant for building and did not realize this bogus. I checked in a new version of the ant build file, which is working.
2  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-06-02 17:35:20
The refactoring of the project structure is almost done. I just have some problems with deleting some folders, that are not used anymore. But you can start working on the new structure anyway.
3  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 19:25:08
Wow, the migration has been completed. That was fast. Sourceforge writes it takes up to 24 hours, it took about 24 seconds  Wink

JOODE is on Subversion  Grin

The homepage is updated to reflect the latest changes: http://joode.sourceforge.net
4  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 19:22:50
I will start now an import of a dump into a SVN repository. Please do not check any code into CVS anymore. As soon as I got any results I will anounce them here.

You can check the current status of the import using this link as well: http://sourceforge.net/project/admin/svn_migration.php?group_id=151965
5  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 17:48:04
I can press the key, but I do not know if I have enough permissions to really do the migration. But I will try it  Wink
6  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 17:27:04
 Wink The shell server is currently down. I could not put the file there as well.
7  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 17:21:30
OK. Have not moved to Subversion yet. Yeah this is the problem. I can't get any of the instructions to work for migrating the CVS repository in the proper fasion.  Have not tried a SVN dump yet. Can you send me one (I think you have my email)
Well, the compressed file still has a size of over 6MB. I will put the file on the shell server, where it has to be for the import anyway.
8  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 11:53:10
By the way. Do we really need the ODE code in our porject? It seems to be quite old. I would prefer to put a pointer to the ODE repository containing the latest code in the project.
9  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-31 11:49:57
STOP!!! Please try to keep the history, it could be useful if we looking for bugs. If you just delete the history we could have made all changes to CVS as well.

If you have any problems wioth importing the history please tell me and I will try to help you. I can provide an archive containing an SVN dump of JOODE. This should be the prefered way of setting up an Subversion repository.
10  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-30 19:02:16
Hmmmm, its kind of difficult to get working. I have tried. Get your code up in CVS.

OK, I won't do any changes until we are on Subversion ;-)

At the very least I can just put in the existing code as is. We lose our change history, but I do not think that is very important anyway.
What is the problem with the migration? Are you using this page https://sourceforge.net/project/admin/svn_migration.php?group_id=151965?
11  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-29 20:19:13
Most important thing would be, that you migrate the project to Subversion. We need this for repackaging. Otherwise we will not be able to change the visibility of fields. Would be nice if you get this done  Wink
12  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-29 19:47:43
I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.
That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list.
Sorry if you find this junk but I agree with t_larkworthy. The Wine project (http://www.winehq.org) do has a lot of feature and yet they began their X.Y numbering with 0.9. They're actually at 0.9.14 (which I'm actually upgrading to). A 1.0 release is not a small thing, see ODE which is still at 0.5 !
If you read the whole mail you will see that I suggest to start with 0.5 before heading towards a 1.0 release.
13  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-29 10:41:20
I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release.
That's right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list.

Make sure all the users methods have javadoc's.
Make sure there is methods for everything that is expected to be interacted with, (so no direct interaction with the force accumulator, for instance).
Intergrate the properties system with the code flow. i.e. which step method that should be used should be chosen via the properties file etc.
All that is not that important for a release. The only really relevant thing for a first release (let's call it 0.5 before doing a 1.0 release) is that the code is stable und working. The API should not change dramatically anymore and of course everything must be working. And that's where I see the problems for a release right now. The API is not stable and I still have problems getting everything running. As soon as I start implementing more complex applications the physic system is exploding.

Write a logging system. I don't like extra dependancies like log4J. I am thinking something very simple. Maybe 3 levels, which all require the C style IO. (to avoid string concatinations)
Why not use the JAVA logging API? I would really discourage from an own logging API.

Bigger things that need a bit more discussion are general architecture improvements. I was mentioning this at chrismas. I think it would be good if we could have an interceptor pattern for step events on Bodies and contruction of bodies and geometries etc. This will allow extra simulation behaviours to be snapped in easily. We could even refactor some of our existing ones out like gravity.
Yeah, I've got lots of ideas as well. But let's get the current code clean and running and it should be no problem to make improvements in the future.
14  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-28 11:03:11
Could you please make an announcement before you migrate to Subversion. I think it will take some time until the code is moved to Subversion. I do not want to have code changes I have to merge afterwards.

Another thing I'd like to know is what is your idea of how JOODE will go on. You are the project leader and administrator, but I see no directions from your side how JOODE will go on. Since I have joinde JOODE only arne and me are really working on the project. I am afraid JOODE will get stuck, as long as no one will have the ambition and vision in getting JOODE on. We need directions in this project.
15  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-22 17:37:33
As soon as I find some time I will move the tasks from the homepage to the Sourceforge tasks and put a link to the page on Sourceforge.
The tasks are now moved from the webpage to Sourceforge.
16  Game Development / Game Mechanics / Re: I have a game written in java and I need some physics on: 2006-05-22 11:59:15
At the moment I cannot encourage you to use JOODE. The trimesh implementation is not known to be finished in the near future.
17  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-22 11:52:05
No, i disagree. A library might contain listener for other implementation to get notified of changes, but it will not provide hooks for direct data manipulation. Especially for a physics library this would almost always result in unpredictable results. If there are improvements they have to be made in the physcis library.
err, either I misunderstood you, or you didn't understand what I meant... what do you mean with "hooks for direct data manipulation"? What I meant: many libraries do something like this:
1  
2  
private Vector position;
public Vector getPosition() { return position; }

This is problematic if Vector is not immutable for the public. You can do somePhysicsObject.getPosition().setX( 5 )! And you could even do this while physics is in the middle of some computation etc.
That's why my suggestion would be to hand out values only not a reference to a mutable object (or hand out immutable objects).
OK, now I understand what you mean Wink Well, making values immutable requires an interface again. But handing out only values would be fine. Values have to be copied again, if they should be immutable, but if you want to manipulate the returned data again, there is no way around copying values. You also have to be aware that you will be able to manipulate data, if we decide to put there an interface for float arrays. If the reference to the array are kept and data is manipulated outside the physices engine then the physics engine gets corrupted again. But I prefer to put there some best practice adviced over making everything bullet proof.
18  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-19 18:33:03
[...] Keeping references means that only the objects that have moved will suffer the virtual call overhead, which is neglectiable these days...

Or is there something im missing ?
Yes, I think so: libraries might not want to give away references - to detect changes to their vectors and avoid recalculation of derived values for each step.
No, i disagree. A library might contain listener for other implementation to get notified of changes, but it will not provide hooks for direct data manipulation. Especially for a physics library this would almost always result in unpredictable results. If there are improvements they have to be made in the physcis library.

(vectors=float[] and matrices=float[][])
not necessarily! javax.vecmath -> Vector3f -> no float[]
This is exactly the problem: the math library would have to use the same interface / data class which is not the case, usually.
That's really bad. So sorry for javax.vecmath Wink Then I see no way for integrating data from javax.vecmath - unless we do not decide to use kavax.vecmath as underlying math library for JOODE.

And regarding the interface proposal with functions: you can't unify the different math libraries this way as they may have similar signatures but methods behave differently (e.g. javax.vecmath.Vector3f.add(Vector3f) vs. jme.math.Vector3f.add(Vector3f)). So, yes, hdietrich this would be no benefit.

But I don't see how this 'common interface' should work Undecided
You must provide implementations for every math library supported, that hide the math libarary's signature. A factory could hide the concrete instantiation. But without gaining any benefit from this we do not have to think about this anymore.

What are the most common math libraries we should support?

Java3D = javax.vecmath
Xith3D = javax.vecmath
jME = own math library (does this one use arrays as underlying datastructure?)
19  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-18 19:15:59
But having an interface with a concrete implementation for each library results in exactly the same as using a specific library in JOODE.

We only have to share the data (vectors=float[] and matrices=float[][]).
20  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-18 17:52:09
For the internal calculations - especially the lcp solvers - we will need own math implementations.

The frontend requires us to have:

[ul]
[li]position vectors[/li]
[li]rotation matrices and/or quaternions[/li]
[li]force vectors[/li]
[li]torque vectors[/li]
[li]maybe the moment of inertia matrix[/li]
[li]vectors for the definition of geometries[/li]
[/ul]

I think that's all. If we have interfaces working with arrays we won't have to show anything at the front - the math library will be hidden from the user.
21  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-18 17:45:34
The box is "jumping" out of sight within two or three iteration steps.
22  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-18 14:59:20
t_larkworthy, could you clean up the feature requests on the Sourceforge page. I think that except of the trimesh request the requests are not appropriate anymore.
23  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-18 14:56:38
Ok - I fixed that JointSlider stuff, the testcase now works, there wasn't a bug in the Joint, but in the testcase (sign error)
mmh ... sourceforge seems to down again...or do we already have subversion?

I have a very simple test for the JointSlider involving a Box and nothing else. This is nearly the same as SingleBodySliderTest, but it fails. Am I doing something wrong?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
package net.java.dev.joode.test.joint;

import javax.vecmath.Vector3f;

import net.java.dev.joode.body.Body;
import net.java.dev.joode.geom.Box;
import net.java.dev.joode.joint.JointSlider;
import net.java.dev.joode.test.SimpleWorld;

public class SliderTest extends SimpleWorld {

   public SliderTest() {
      super(true);

      Box box1 = new Box(this.space, 2, 2, 2);
      Body body1 = new Body(this.world);
      body1.pos.setY(4);
      body1.pos.setX(-4);
      body1.mass.setBox(1, box1.getSide().getX(), box1.getSide().getY(), box1.getSide().getZ());
      box1.setBody(body1);
      this.gfxManager.addBinding(box1, this.view.getScene());

        JointSlider slider = new JointSlider(this.world);
        slider.attach(body1, null);
        slider.setAxis(1, -1, 0);
       
      view.getView().getTransform().lookAt(new Vector3f(0, 0, 10),
            new Vector3f(0, 0, 0), new Vector3f(0, 1, 0));
   }

   public static void main(String[] args) throws InterruptedException {
      SliderTest test = new SliderTest();
      while(test.fps.runs()) {
         test.step();
      }
   }

}


Slowly I hazard a guess that there is something wrong with the moment of inertia created for a box...
24  Game Development / Game Mechanics / Re: JOODE Development Status on: 2006-05-18 14:52:17
Uh, you are right. The BoxBoxCollisionTest and BoxCollisionTest show ugly results. The rest of the tests are OK, at least the one's that were working before. I have the suspicion that the BoxBoxCollider still has errors.

The Stepper were not influenced by the last changes, so I think it's not realted to the API changes I just commited. I will do some debugging of the BoxBoxCollider again  Sad
25  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-18 14:47:40
Great, I hope your exams were successful  Wink

As soon as I find some time I will move the tasks from the homepage to the Sourceforge tasks and put a link to the page on Sourceforge.
26  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-18 14:36:09
Let's assume we will have very low impact on performance by putting there an wrapper around the concrete math implementation. What are the concern regarding memory?

As far as I see we only need plain vector and matrix operations for JOODE (add, multiply, dot-, and scalar-product). The vector and matrix data will always be a plain array of float or double values. The rest of the code will be methods to manipulate the data. What will a wrapper look like?

1  
2  
3  
4  
5  
6  
7  
public interface Vector {
  void add(Vector vector);  
  void add(Vector vector, Vector result);
  void multiply(float a);
  void multiply(float a, Vector result);
  ...
}


Isn't this the code implemented by nearly every math library? What are the benefits of putting there a wrapper instead of a concreate math library? If we manage to share the underlying data structures (arrays) from my point of view we will have no benefit.

So my suggestion is to put there interfaces, which allows us to share the data structures (arrays), and use whatever math library fits best to the needs of JOODE.
27  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-18 10:59:11
For deciding wether to use interfaces or dublicated position/rotation/scale etc. we really should do some performance tests. (my guess is that copying data could be faster than having interfaces)

We have to obey the tradeoff of performance and memory consumption. But some tests would be nice Smiley

But I think what really should not be doubled is the memory needed for trimesh geometry as that is a lot of memory. Wouldn't it be most appropriate to use java.io float buffers there? Does JOODE use them?

Right now JOODE does not support trimesh geometry. But I agree that the trimesh definition should be an array of float of a float buffer. It will be interesting how to handle Vertices, Edges, and Faces, because this are informations that might be needed by Renderer and Physics Engine.
28  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-16 18:39:28
I just added a Todo list to the webpage. This is no tracker, but it should give a overview of the status of JOODE.
29  Game Development / Game Mechanics / Re: JOODE Project Structure on: 2006-05-16 14:29:06
OK, great. I am heavily waiting on this, so we can get something on again.

Could you please assign the right to create tasks to me on Sourceforge, so we can track the todos in sourceforge?
30  Game Development / Game Mechanics / Re: jME Physics 2 - collaboration between projects on: 2006-05-16 13:48:41
So I am interested in what are goals of jME Physics 2 if it wants to everything agnostic?
It does not. As stated above it does not make sense to me to be scenegraph agnostic. jME Physics is a physics abstraction/API layer for the jME scenegraph.
My fault, I mixed up the response from MagicSpark with the jME Physics goals. Sorry.

Quote
As stated above I think JOODE can contibute only very few things to this dicussion.
I think the developers on this forum can contribute a lot to this discussion Smiley (and that's not only JOODE developers)

That's why I said JOODE Wink

Your suggestion to have wrappers for the math package or to abstract from the actual data holding classes seems problematic to me: first performance would be degraded (polymorphism costs a magnitude in access time).  Second it would be very hard to define the semantics of operations on the math data without actually specifying the whole math package.

I think about wrappers, which implement an common interface. By doing this we could have implementations for different libraries. I do not think that the performance impact would be that much. Moreover it is questionable if the impact on memory consumption is nearly the same just as having math structs twice.

Thus either using the same math package or converting values on demand seem to be the only choices to me. Why do you use a custom math package in JOODE and which package should be used in favor and why?

The custom math package is a relict from the ODE port. ODE has its own math library and this was ported as well. But this library is very unhandy, since it makes use of pointers a lot. As I already mentioned it will be replaced sooner or later. For me (personal opinion) vecmath from Java3D would be the preferred library. I think it is the most popular library used for game development.
Pages: [1] 2 3 4
 

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

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (11 views)
2014-04-15 18:08:23

BurntPizza (10 views)
2014-04-15 03:46:01

UprightPath (23 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (107 views)
2014-04-08 23:06:04

tom_mai78101 (207 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!