Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4 ... 8
  ignore  |  Print  
  Pure Java Port of ODE - planning/feasibility  (Read 42411 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #30 - Posted 2005-10-01 18:56:39 »

The key problem is all those "dReal *" fields.   they point to matrices some times, vectors other times. arrays of vectors some times, arrays of matrices other times, etc.  Some times perhaps they can be null?

It's getting that high level understanding of exactly what they are that needs to be sorted out.  I think that will take some time to dive into the depths of the C/C++ source to figure out what those pointers really mean.

Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #31 - Posted 2005-10-02 18:47:03 »

Yeah. Those dReals are annoying. Most are fairly obvious what they should mean.
My webspace is not available yet so I cannot put up my UML diagram yet. However I have used BOUML to generate java.  It has messed up a few attributes and missed a few things, but generally it is pretty good:-
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
struct dxBody : public dObject {
  dxJointNode *firstjoint;   // list of attached joints
  int flags;         // some dxBodyFlagXXX flags
  dGeomID geom;         // first collision geom associated with body
  dMass mass;         // mass parameters about POR
  dMatrix3 invI;      // inverse of mass.I
  dReal invMass;      // 1 / mass.mass
  dVector3 pos;         // position of POR (point of reference)
  dQuaternion q;      // orientation quaternion
  dMatrix3 R;         // rotation matrix, always corresponds to q
  dVector3 lvel,avel;      // linear and angular velocity of POR
  dVector3 facc,tacc;      // force and torque accumulators
  dVector3 finite_rot_axis;   // finite rotation axis, unit length or 0=none

  // auto-disable information
  dxAutoDisable adis;      // auto-disable parameters
  dReal adis_timeleft;      // time left to be idle
  int adis_stepsleft;      // steps left to be idle
};

gets turned into
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  
39  
40  
41  
42  
43  
package JDE.generated;

class dxBody extends dObject {
  //  list of attached joints
  public dxJointNode firstjoint;

  //  some dxBodyFlagXXX flags
  public int flags;

  //  first collision geom associated with body
  public dGeomID geom;

  //  mass parameters about POR
  public dMass mass;

  //  inverse of mass.I
  public dMatrix3 invI;

  //  1 / mass.mass
  public dReal invMass;

  //  position of POR (point of reference)
  public dVector3 pos;

  //  orientation quaternion
  public dQuaternion q;

  //  rotation matrix, always corresponds to q
  public dMatrix3 R;

  //  finite rotation axis, unit length or 0=none
  public dVector3 finite_rot_axis;

  //  auto-disable parameters
  public dxAutoDisable adis;

  //  time left to be idle
  public dReal adis_timeleft;

  //  steps left to be idle
  public int adis_stepsleft;

}


This reverse engineering and generating system can only go so far though. Everything still needs to be checked by eye.  It seems feilds generated like int x,y; seems to get missed, and it only really can reverse enginner the model. Porting the implementation is the real work and I don't know of any tools to help with that.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #32 - Posted 2005-10-02 22:37:01 »

There's probably no way around of understanding how the ODE code works, without risking lots of errors and bugs.

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jfelrod1960

Junior Duke




Use the source Luke, use the source!!!


« Reply #33 - Posted 2005-10-02 23:57:42 »

There's probably no way around of understanding how the ODE code works, without risking lots of errors and bugs.

I agree.  IMHO I think the best attempt is to develop a pure Java physics engine from the ground up.  There are plenty of game physics and generat physics book available.

Jeffrey F. Elrod
Complexsive Systems
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #34 - Posted 2005-10-03 02:37:39 »

When I looked at the code I found that some ODE classes would not need to be ported verbatim.  For example dObject is not needed at all, I think.  Nor, is the ODE array class.  Java already has things to handle that.  The array class of ODE seems to be either a direct Java array, or an ArrayList - depending on how it gets used.. as in if it really needs to have a dynamic size.

Another question would be, should generics (and therfore a Java 5+ requirement) be used?  I'm inclined to say yes, use generics.  Around the time you are done, Java 6 will probably be released so you would still be supporting one major version back and you would get the advantages that Generics (and Enums, and for-each, etc...) will offer.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #35 - Posted 2005-10-03 05:19:06 »

There's probably no way around of understanding how the ODE code works, without risking lots of errors and bugs.

I agree.  IMHO I think the best attempt is to develop a pure Java physics engine from the ground up.  There are plenty of game physics and generat physics book available.

Nice idea in theory.  For that we would need a dedicated team and a physics export.

To port ODE, we at least are starting with a mature physics engine and while Odejava still supports the native JNI ODE (which will be until this pure java port is ready) the quality of the port can easily be validated against ODE itself (using Odejava).

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #36 - Posted 2005-10-03 05:21:47 »

When I looked at the code I found that some ODE classes would not need to be ported verbatim.  For example dObject is not needed at all, I think.  Nor, is the ODE array class.  Java already has things to handle that.  The array class of ODE seems to be either a direct Java array, or an ArrayList - depending on how it gets used.. as in if it really needs to have a dynamic size.

This is good Smiley

Quote
Another question would be, should generics (and therfore a Java 5+ requirement) be used?  I'm inclined to say yes, use generics.  Around the time you are done, Java 6 will probably be released so you would still be supporting one major version back and you would get the advantages that Generics (and Enums, and for-each, etc...) will offer.

How would using generics help in this situation?  I have not yet used them (still on 1.4.2 here) so I don't know myself.

As for Enums, for-each, etc.  Alone I don't think they are compelling reasons to use 1.5 but I agree if we go 1.5 we may as well use them.

Will.


Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #37 - Posted 2005-10-03 05:25:13 »

My webspace is not available yet so I cannot put up my UML diagram yet.

If you (or anyone else working on xith3d/odejava related projects) need webspace, send me an email, I have some space I can share (in the form http://users.xith.com/username).

Will.

Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #38 - Posted 2005-10-03 08:01:58 »

I would go for generics and other features. I find they help in my productivity becuase intelligent editors like IntelliJ and Eclipse can auto generate more code when you use them. I think they can simplify code very well. I am not sure exactly where they could be used in the port becuase using them implies reorganizing the ODE design which is not what I think we should be doing.

Quote
When I looked at the code I found that some ODE classes would not need to be ported verbatim.
Yeah I am not sure about this. I think maybe that array class in ODe should probably go becuase it does not seem to be doing anything clever. Things like the dMatrix though I think should be included as a seperate class, whose implementation should delagate to the Matrix3f (or 4f or whatever) in Vecmath. I think its important though that we still make a wrapper that looks exactly like the ODE equivelant (actually that is impossible becuase in ODE they use operators on the class) .

Quote
IMHO I think the best attempt is to develop a pure Java physics engine from the ground up
No. I will not be part of such an effort becuase I do not think it would ever get finished. I am hioping that the ODE port might be a possible base for others to build from.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #39 - Posted 2005-10-03 10:08:38 »

How do we go about getting the project allocated?

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #40 - Posted 2005-10-03 14:20:29 »

I would go for generics and other features. I find they help in my productivity becuase intelligent editors like IntelliJ and Eclipse can auto generate more code when you use them. I think they can simplify code very well. I am not sure exactly where they could be used in the port becuase using them implies reorganizing the ODE design which is not what I think we should be doing.

Fair points however I would prefer to see an exact ode related reason to abandon 1.4 being that JOGL, LWJGL, Odejava and Xith3D are still all 1.4 compatable.  Ultimately it's up to the primary coder I guess, that is just my opinion Smiley

Quote
Quote
IMHO I think the best attempt is to develop a pure Java physics engine from the ground up
No. I will not be part of such an effort becuase I do not think it would ever get finished. I am hioping that the ODE port might be a possible base for others to build from.

I completally agree.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #41 - Posted 2005-10-03 14:28:41 »

How do we go about getting the project allocated?

One can create the project in java.net, but then the JGO board has to approve it.  Perhaps we can petition for a speedy approval given we are not just a bunch of unknowns.

We need to decide on the name and who the owners are.

My votes are for "pureode" for the former and the main developers (defined as those who are committed to working several hours a week on the project) for the latter.  What do you think?

How related will this project be to Odejava?  Ultimatlly most people will be wanting an O-O layer anyway so I am guessing it will be quite related.  Perhaps we should make it a sub-project of Odejava (which basically just affects the navigation from the java.net directory and nothing else I think).

t_larkworthy, you are sounding very enthusiastic - are you prepared to take the role of team leader?  I am certainly prepared to commit a substantial effort to the project but I don't feel that I am the most qualified to lead it.

Cheers,

Will.

Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #42 - Posted 2005-10-03 15:37:12 »

I think it's the simplest to request a new project at java.net and then we'll all simply have to give our +1. I believe we're enough for that, so it should go fast.

pureode, ... bluesky had also the idea to call it JDE for JavaDynamicsEngine.

I actually like very much JDE, because it's so close to ODE. From that name typos, we could also call it JODE (Java Open Dynamics Engine), like jogl.

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #43 - Posted 2005-10-03 18:00:25 »

I got my webspace allocated at last. Here is what BOUML draws when it reverse engineers the ODE source:-

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #44 - Posted 2005-10-03 18:21:05 »

I have to say my favourite name so far is JDE.

As for project leader, yes I would be prepared to take that role if everyone is ok with that.
I shall list a few things that I think make me suitable for the role for anyone who needs convincing.
I have played around with the code of ODE.
I have made a pretty comprehensive robot simulator based around javaode, I was thinking of open sourcing that but I would rather get the underlying technology more stable (which is what this should achieve).
My math is fairly strong. (Java like most people here is 2nd nature and not really worth mentioning)
I have been a designer for two fairly substantial (albeit J2EE) commercial software projects.
c and c++ is good, though not up to my Java

My drawbacks are:
I have just started a MSc in Neuroscience after completing an MEng in Software Engineering. As all you techies will realise its pretty difficult learning lots of biology from nothing. The overall plan is to do a PhD in neuroinformatics after that. Anyway the workload is pretty punishing, so although most weeks I would like to put in more than 5 hours, some weeks I will have to be strict about how many hours I do. I imagine I will do most work on this project on Sundays.   

I have never been a team leader before.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline jfelrod1960

Junior Duke




Use the source Luke, use the source!!!


« Reply #45 - Posted 2005-10-03 18:55:06 »

I have just started a MSc in Neuroscience after completing an MEng in Software Engineering. As all you techies will realise its pretty difficult learning lots of biology from nothing. The overall plan is to do a PhD in neuroinformatics after that.

Very interesting research ...  I had done some graduate research in ALife which I think is partially related.  Just wasn't as serious as you. Smiley  Good luck with your research!

Jeffrey F. Elrod
Complexsive Systems
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #46 - Posted 2005-10-03 21:36:07 »

When reading all these plans for a physics-engine, I can't help but mention that PPU (Physics Processing Unit) that is about to be released on the market. Hardware acceleration will completely blow away any code that runs on the CPU/GPU doing the physics. So what's the point of truely reinventing the wheel, when such a superb piece of hardware is about to shift our way of thinking abuot physics? Bindings to that engine will also support systems without a PPU because it can also run on the CPU.

Just a thought, worth exactly $0.02 Wink


http://www.ageia.com/novodex.html

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline darkprophet

Senior Duke




Go Go Gadget Arms


« Reply #47 - Posted 2005-10-03 22:21:20 »

like I said...wait 3 - 4 months.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #48 - Posted 2005-10-03 23:49:30 »

PPU accelerated - good and fine, but how do you want to get it to Java? Wait until ODE manages the acess or write a on the PPU's physics-API dependent Java-Interface? Especially the Java-Interface for the PPU is not an option, because who says, that that PhysX API will get the standard? And another Point: It looks, as if it only works for Windows, so we could through Java's platform independency into the garbage bin!!

Ok back to topic...
I think it is a very good idea, that t_larkworthy becomes the project leader. Smiley

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #49 - Posted 2005-10-04 00:26:52 »

PPU accelerated - good and fine, but how do you want to get it to Java? Wait until ODE manages the acess or write a on the PPU's physics-API dependent Java-Interface? Especially the Java-Interface for the PPU is not an option, because who says, that that PhysX API will get the standard? And another Point: It looks, as if it only works for Windows, so we could through Java's platform independency into the garbage bin!!

I agree.  In IT it is always wise to keep abrest of new developments but rarely wise to put on hold current work waiting for them.  Wait till it is standardised and supported, then we can worry about it.  Who knows what areas will be optimised anyway, CPU intensive operations might be easilly passed off to the PPU when the appropriate bindings exist.  Furthermore who is actually going to have a PPU?  Until they build them onto the GPU almost nobody and even then it will take years to become mainstream.  My game is designed to run on a GeForce MX 400!!

Quote
Ok back to topic...
I think it is a very good idea, that t_larkworthy becomes the project leader. Smiley

here here.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #50 - Posted 2005-10-04 00:37:05 »

I have to say my favourite name so far is JDE.

I don't really mind, but when I hear JDE I think "Java Development Environment" i.e. a variation of IDE.  Google seems to agree

JODE was my first choice as a name for Odejava but there is another project with that name already.

Any other ideas?

Quote
As for project leader, yes I would be prepared to take that role if everyone is ok with that.
I shall list a few things that I think make me suitable for the role for anyone who needs convincing.
I have played around with the code of ODE.
I have made a pretty comprehensive robot simulator based around javaode, I was thinking of open sourcing that but I would rather get the underlying technology more stable (which is what this should achieve).
My math is fairly strong. (Java like most people here is 2nd nature and not really worth mentioning)
I have been a designer for two fairly substantial (albeit J2EE) commercial software projects.
c and c++ is good, though not up to my Java

My drawbacks are:
I have just started a MSc in Neuroscience after completing an MEng in Software Engineering. As all you techies will realise its pretty difficult learning lots of biology from nothing. The overall plan is to do a PhD in neuroinformatics after that. Anyway the workload is pretty punishing, so although most weeks I would like to put in more than 5 hours, some weeks I will have to be strict about how many hours I do. I imagine I will do most work on this project on Sundays.   

I have never been a team leader before.

I think with your ODE and C/C++ knowledge you are very suitable.  Thank you Smiley

Will.

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #51 - Posted 2005-10-04 02:01:29 »

As for other name ideas: ODE4J ?

I suggested Generics because I see that the structure of the objects indicates things like arrays of Joints and such.  If they are to use the resizeable ArrayList class then I think the benefits of the added type safety would be significant..  I.e. for much of the same reasons that "dReal *" sucks in C/C++, ArrayList<Object> is undesireable in Java.  It's just an idea.  It's up to you guys to decide.

I also would vote to drop the "dx" prefix on the class names when porting to Java.  It just isn't the Java way to have such a prefix.  I'm not sure if writing a new Matrix clas and delegating to Matrix3f/4f is the way to go, or if Matrix3f/4f should be used directly along side a helper class with static methods much like Math.  Or maybe Matrix3f/3d would be the base class of an ODE Matrix class?  Without the operator overloading the code referencing such classes will look significantly different from the C++ code anyway.

That brings another question: Would you use Matrix3f or Matrix3d, ODE appears to have a compile-time switch to choose single or double precision.  How much will this matter?  Will using doubles make it any more stable?  Will it affect the speed significantly?

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #52 - Posted 2005-10-04 05:19:36 »

ODE4J doesn't give me the impression of a pure ODE impl, more I get the impression it is a binding like Ogre4j.

Is 1.5 even standard on the Mac yet?  http://192.18.37.44/forums/index.php?topic=10648.15;topicseen
I believe there was some codeweaver tool that could transform Generics into 1.4 bytecode, so this could be an option I guess.

I agree there's no need for prefixes on the class names in java.

Regarding floats vs doubles, I'd suggest floats for now since it is faster (and that's what Odejava used).  There's nothing to stop us in the future overloading the methods with support for doubles though (in much the same way as Java3D did it).

Will.

Offline Bombadil

Senior Duke





« Reply #53 - Posted 2005-10-04 08:45:12 »

A spectator's small comment:
JDE sounds too similar to JRE, JDK, IDE, and so on.
JODE I'd like best. Will says it's already in use.
JODEL is too close to JODE I guess (but sounds funny in case you know what Jodeln ist)
JOODE to emphasize the OO aspect? Again to close to JODE I guess.
JODOE (short for John Doe? :-)
<no further ideas>
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #54 - Posted 2005-10-04 09:30:01 »

Yeah, I think we should keep to floats.

I personally thought that we should keep the Java class names exactly the same as the ODE ones. I know thats gonna totally break with java convention but I think it has several advantegous:
ODE documentation will be more relavant
Porting code by copy and paste will be easier as class names will not have to be adjusted.

Another thing that is against Java convention that I think would be a good idea is to port structs as classes with lots of public attributes. That will mean java code will be able to access data just like it does in the C++ code.

Both these things will make is much easier to compare the C++ code and Java code for initial coding and maintanence. I think it will have productivity benifits.

PPU discussions are important as a 'political' context to this project but I do not think that the technology should really intefere with our decision making process. There are far too many unknowns with the technology. Untill there are 3 different manufacturers and 50% of games PCs contain one and all the best games all use them I don't think we java people should be pining after the technology.

Quote
Matrix3f/4f should be used directly along side a helper class with static methods much like Math
Yeah I think your right actually. I ahve been thinking about this. My initial view was that a custom wrapper would allow us to put in all the extra multiplication functions used to optimize ODE. However there is nothing more annoying than using a API that does not use standard classes, especially as our project will probably have a dependancy on the standard library anyway. I thought that the vecmath API made lots of classes final but it doesn't so subclassing is an option, however I do not like that idea becuase developers will still need a translation step somewhere to get their own constructed matricies into the system (unless we code a mechanism for them, which is more work for us  Angry ).So yeah, static helper methods I think is the way to go using the standard vecmath classes.   

As for generics. Although I really really like java 1.5, the features should only be used if the existing ODE design which we are copying uses them. There exists two places where tempaltes are used. The first is the dArray class, the 2nd is an obscure part of the trimesh code. If the dArray use of generics was wide spread then I would maybe say that we need to use them, but the dArray class is actually used very little:-
1  
2  
3  
4  
5  
6  
7  
collision_quadtreespace.cpp:324:        dArray<dxGeom*> DirtyList;
collision_trimesh.cpp:308:                      /* dxTriMesh::ClearTCCache uses dArray's setSize(0) to clear the caches -
collision_trimesh_internal.h:94:            dArray<SphereTC> SphereTCCache;
collision_trimesh_internal.h:100:         dArray<BoxTC> BoxTCCache;
collision_trimesh_internal.h:106:         dArray<CCylinderTC> CCylinderTCCache;
lcp.cpp:381:  dArray<int> C,N;              // index sets
testing.h:37:  dArray<dMatInfo*> mat;


The QuadTree space and the trimesh stuff are both areas I did not want to port. The only real place is the LCP solver, and there is is used to store a list of integers ... big deal. (Damn! we *need* autoboxing  Wink)

So yeah. I think generics are not needed. Thus we might as well stick to 1.4.

Some of you might be wondering how ODE does store lists of things. Bodies and things are joined up in a link list fasion. Its a bit urgh for us Java people seeing the body code containing the implementation used to store it as a list, but I believe we should still replicate this.

Quote
I don't really mind, but when I hear JDE I think "Java Development Environment" i.e. a variation of IDE.  Google seems to agree

JODE was my first choice as a name for Odejava but there is another project with that name already.
Bah!


 

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #55 - Posted 2005-10-04 09:32:24 »

Quote
JOODE
I like that one. Perhaps pronounced judy? Java Object Orientated Dynamics Engine

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline arne

Senior Duke




money is the worst drug- we should not let it rule


« Reply #56 - Posted 2005-10-04 10:24:07 »

+1 for JOODE Smiley

I think we should use javax.vecmath, becuase then we're reducing the amount of errors - we would probably get  errors even by simply porting the ode math stuff. We'll probably also work with vecmath on the outside (because OdeJava does), so it would only increase the overhead if we add another layer.

If generics is really so rarely used, we really could stick to 1.4.

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #57 - Posted 2005-10-04 12:45:28 »

Well some of the matrix functions need to be ported. There are lots of optimizations like: if you know the 3rd column and 4th row are all zero ....
Its all very specialized in the LCP. But yeah. We can add peripheral methods to a static class and just use the standard matrix classes as they are.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Offline Amos Wenger

Senior Duke




Everything's possible, but not everything's fun...


« Reply #58 - Posted 2005-10-04 14:50:28 »

+1 for JOODE
@t_larkworthy : May you create the java.net project now ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline t_larkworthy

Senior Duke


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #59 - Posted 2005-10-04 17:32:58 »

OK great! Yeah I will submit a project form now.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
Pages: 1 [2] 3 4 ... 8
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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 (36 views)
2014-10-17 03:59:02

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

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

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

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

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

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

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

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

BurntPizza (77 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!