Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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
1  Game Development / Game Mechanics / Re: polygon support in phys2d on: 2007-03-15 03:51:06
You are a freaking genius. I could go back to writing 2D stuff based solely on how cool the demo was.
2  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-26 02:38:25
I like the idea of sharing code between the projects for the time being. I hope sincerely that Phys2D keeps simplicity and speed, while I'd like to see JOODE become highly configurable and full-featured, with several choose-able integrators and a priori detection. Both projects can benefit from going down slightly different paths.
3  Game Development / Game Mechanics / Re: JOODE tests conversion to current Xith3D on: 2007-02-19 21:59:15
look under branches/ , instead of trunk.
4  Game Development / Game Mechanics / Re: Trouble building JOODE on: 2007-02-16 04:21:53
Indeed there seems to be some unfinished work in the build.xml file. Since I can't get a fix on Tom's mind to read it properly, I simply cleaned it up a bit. Should work now.
5  Game Development / Game Mechanics / Re: JOODE developer mailing list on: 2007-02-13 02:47:42
I'd say two mailing lists- one for SVN commits (I like to read them as they come), and dev: joode-dev joode-commit
6  Game Development / Game Mechanics / Re: JOODE tests conversion to current Xith3D on: 2007-02-12 18:36:35
Sure, but there are some MathUtils methods giving me trouble, plus I still don't see the point of the RealPointer class. Those are the only reason the vecmath patch is not complete.

After that, I assume it's easy to switch to openmali.
7  Game Development / Game Mechanics / Re: Which physics engine? on: 2007-02-11 06:54:34
Tell you what, try out ODEJava and JOODE; they both use very similar APIs. For JOODE, check the examples. ODEJava is more mature, but JOODE is a pure-Java implementation.
8  Game Development / Game Mechanics / Re: Iterator and LinkedList on: 2007-02-05 18:59:29
For which Vectors are best. Come on everyone! Let's join the cascade! Tongue
9  Game Development / Game Mechanics / Re: Iterator and LinkedList on: 2007-02-04 03:59:37
I also noticed this when refactoring for static variable use, but mostly left it alone. I think though, that we should discuss it on the joode-dev mailing list:

http://sourceforge.net/mailarchive/forum.php?forum_id=51541
10  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-02-02 17:39:17
Why not let the user configure that ?
Just a "Math Optimizations" Enable/Disable options.
That's what I was getting at.

OK, no problem.
Anyway, change from sun vecmath to our modified vecmath is pretty straight-forward.

cool. I plan to commit the branch (mostly complete) this evening.
11  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-02-01 16:49:36
Don't take me as any indication of the larger project community. It is still a very young project, and has no general "spirit" yet. Tom has already stated he's happy with the contrib, and the thread is becoming an off-topic about Java portability when using "magic" algorithms that rely on specific standards and/or architectures.

I don't like to simply say "Thanks for the contribution, move along." I prefer a public discussion of the patch, what the submitter has done and why, as per the spirit and guidelines of the project. It leads to a better quality of patches. I'm not saying it has to be a hearing before a committee either, but it does not justice to the patch writer to simply take their patch and trash it.

I hope that you will contribute in the future, and I hope you will at least consider JOODE for volatile.
12  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-02-01 15:57:41
non-x86 platform? So that implies PPC right? Which means older macs and PS3.

Try SPARC, anything MIPS, or Cell.

If you read above, the Accuracy VS Speed is configurable depending on the number of loops on the last line. As for the accuracy of JOODE, your depending on LCP in the first place, which isn't highly accurate, but achieves visually convincing results and is stable. If you want accuracy, im afraid your going to have to change all of JOODE.

*Is JOODE accuracy v. speed configurable

If you want to re-prove what Quake3 and I (and countless others) already have proved that it is a worthwhile optimisation, then by all means go ahead Smiley

Did they prove it in Java?

If you look at the change log, you will notice that this code is already in place (with a different initial value). I put it there myself (well, with Amos' help). However, I left it commented out, since there is currently no way to choose, nor was there a concensus on its use.
13  Game Development / Game Mechanics / Re: JOODE developer mailing list on: 2007-02-01 14:22:40
I'm on
14  Game Development / Game Mechanics / Re: [ODEJAVA] Problems limiting angles on: 2007-02-01 11:42:24
How much force does the AMotor have?
15  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-02-01 09:57:03
o noes! Well, it's biggeruniverse. I know, I ought to be more creative...
16  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-01-30 19:14:54
It is accurate to 4 decimal places. Iterations over the last line in the algorithm produces more accurate results. If you look at the optimisation, one line has been commented out as I have replaced the initial guess with one that yields more accurate results.

Well, what accuracy is JOODE guaranteeing to the user? Is accuracy v. speed configurable? At what point of accuracy is this slower than Math.sqrt?

You do realise this is java right?

JOODE is Java, that code is converted C code. It was written to be close to the hardware, which of course makes me suspicious of it. Has this Java code been shown to work on any non-x86 environment? (It should of course, but better to test these things before they are relied upon to be always correct)

This is a contribution, take it or leave it, its up to you.

I hope we take it, as it is faster, but first it has to be proven out.

I agree both with Marvin and darkprophet.

I'd find cool if you, biggeruniverse, would use the same version of vecmath (Kenji Hiranabe modified) as us (in Xith3D) so that we can add these optimisations (if you don't want to change regular sin()/cos()/sqrt() methods we could have fastXXX() ones).

Well, first thing first, let me finish the conversion to pure vecmath. I'll branch it for easy testing, and then it can be decided what to do about optimizations.
17  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-01-30 17:50:38
Ok, it checks out for pure speed. But two hurdles remain:

1. Correctness of computed values
2. Portability to other platforms (and correctness there too)

Also, if it is decided that JOODE should use javax.vecmath throughout, we would rely on the vecmath implementation for vector length (Math.sqrt()):

https://vecmath.dev.java.net/source/browse/vecmath/src/javax/vecmath/Vector3f.java?rev=1.3&view=auto&content-type=text/vnd.viewcvs-markup

Because, as referenced here: http://www.java-gaming.org/forums/index.php?topic=15677.msg125477#msg125477 the biggest slow-down that JOODE currently experiences is in the implementation of the Real class, and its derivatives.
18  Game Development / Game Mechanics / Re: [JOODE] Contribution on: 2007-01-30 15:47:57
This code is in Real, but I left it commented out because it's no longer as fast to do it in integer as in floating point instructions. Esp. for Java, it's probably slower.

@t_larkworthy: I sent you a PM a while back! Check you PMs! Wink
19  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-23 08:29:43
Actually, you are on the right track. I'm working on an entire fix for this but, as I'm sure you have seen, it will take time. There will also be time to test, and verify that the conversion has happened correctly. It is being worked on.
20  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-22 18:53:42
I'm not seeing any compile errors. Can you post some compiler output, or line numbers or something?

EDIT: looks like Art already uploaded it.
21  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-22 01:43:29
Actually, what I had planned (not sure if this is concensus) is to replace the internal geometry classes with javax.vecmath classes. This will take a little time to get changed and tested.
22  Game Development / Artificial Intelligence / Re: AI detail level and scripting on: 2007-01-19 13:26:48
Actually, in testing most of the options, my personal favorite has been Groovy. pnuts has some odd little quirks.

What do you mean by "AI"? That's anywhere from path-finding to Neural Nets. What you use will really depend on what kind of gameplay you are going for, and will probably be a combination of several things.
23  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-19 03:09:59
Go ahead get rid of mine- it's a stub. I like that you used javax.vecmath, I've been planning to convert all of JOODE to using it. I found from traces that the slowest part of the collider was lookups of indices in the Matrix3/4 classes.

Anyway, I'm excited to see some trimesh collisions!
24  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-18 18:48:39
No, it can detect the collisions, but it won't know how to "fix" them correctly. If it sees that a sphere is inside a box, all it knows is exactly that. It doesn't know where the sphere or box came from, or where they are going, hence how can it know which side of the box the sphere entered from?

EDIT: I wish JOODE devs were around to talk to about this. Sad
25  Game Development / Newbie & Debugging Questions / Re: Boolean flags vs. multi-threading? on: 2007-01-18 12:29:53
This entire forum thread is multiple sub-threads within the main thread, which I think is undue given the definition of the problem.

Anyway, never use a simple dictionary, always get the etymology of a word: http://www.etymonline.com/index.php?term=complex

I like the 1715 version.
26  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-18 06:02:09
Probably the quickest thing to do is make your step size half as big, and step the simulation twice per frame. That should help a lot of cases, though of course it will not help when the sphere still ends up within the box on the far side from where it entered. The problem is that the collider has no idea about the velocity of the body, and therefore cannot do tests a priori.
27  Game Development / Game Mechanics / Re: Detecting the time of collision between a rotating line and a moving sphere? on: 2007-01-17 13:14:40
If you weren't at work I would kiss you.

EDIT:
@Markus_Persson: I know the ball flies through. That's why you use the lines and not the ball itself. Given oNyx' wikipedia reference, I've been describing an a priori method whereby you see if a collision will occur in the time step, and where it will occur. Then you place the ball at the position of line intersection (not quite of course, since the intersection is the on the edge of the ball) and give it a new velocity which is the mirror of the current velocity around the perpendicular to the paddle line.

steps:

1. (time step begins) calculate line that represents paddle, given current paddle orientation
2. fire ball velocity ray, get list of collisions, take the first one
3. if it intersects the paddle line (or any line technically, but the paddle line is special)
    place the ball at the intersection point, set new velocity, add paddle angular velocity to ball linear velocity
4. else update ball position by ball velocity
5. (time step ends)

And what do you mean pretending won't work? The entire thing is about pretending! Tongue
28  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-16 17:53:44
I'll work on it.
29  Game Development / Game Mechanics / Re: JOODE love on: 2007-01-16 16:28:59
the fact that static-static collisions are ignored is most annoying for me... first I thought it was a bug, then I found out why in the code and I saw your post.

The issue is, I'm using JOODE Geoms without Bodies but I *want* collision detection because they are dynamic in my world (say, I use JOODE collision detection but not physic simulation here).

So this should be adjustable somewhere.

Hmm. Ok. Would adding something like World.ignoreStaticContacts (default value true) suffice?
30  Game Development / Game Mechanics / Re: Detecting the time of collision between a rotating line and a moving sphere? on: 2007-01-16 16:26:21
Wow. You're right, that's phenomenally complex. But, I don't see where the *exact* time matters, only that the simulation is believable (i.e., if a collision occurs within the time step, which is usually pretty small, react). So let's cut out the idea of sub-steps. Let's look at each of the first row of cells as if each is a full time step. Assuming a time step <1/30 sec, I think that would be sufficiently close to "exact". Now it's simply as I said, the intersection of two lines. This method also ignores "contacts" where the paddle is technically within the sphere, but the sphere is moving away from the paddle (assuming you move the sphere line segment to the edge of the sphere. This is similar to what bleb was saying, with some simplification
Pages: [1] 2
 

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

The first screenshot will be displayed as a thumbnail.

TehJavaDev (16 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (35 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (31 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (44 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!