Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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  Games Center / Archived Projects / Re: HDR / Bloom tech demo on: 2007-10-13 21:08:50
Doesn't work for me cause I use a fixed dual screen setup in linux. Can it be started in windowed mode?
2  Game Development / Game Mechanics / Re: water on: 2007-06-01 16:32:54
The question is impossible to answer for you without any additional information. Surely you can have something that resembles water in most physics engines, but if that's good enough depends entirely on the application. For example in a racing game you usually want very realistic (or at least specialized) physics which most physics engines  know of don't have. If you wer working on a strategy game, I'd be wondering why you'd even bother with an advanced physics engine like ODE.
3  Game Development / Game Mechanics / Re: [PhysX4J] Alpha version released on: 2007-06-01 16:28:22
I thought it was supposed to be hardware accellerated with their special pci  physics card. If it is, it should be faster than any of the pure software based solutions.
4  Game Development / Shared Code / Re: new phys2d joint on: 2007-03-27 20:55:15
In my opinion your demo also shows some of the limitations of this approach:
- configuring the behaviour of the 'blob' is difficult, i.e. not intuitive
- a large number of joints is required, which is very expensive to calculate and with the current method gets more inaccurate if there are more connected joints
- what about non-convex or even non-star-shaped bodies, where should the joints be placed? An arbitrary triangulation with joints might do it, but it wouldn't be nice to have
different behaviour for different triangualtions.

I guess what I'm trying to say is that, altough the SpringJoint can be used as you do for deforming objects for specific cases. But using it to implement general deforming colliders would not be a good idea in my opinion.

By the way you seem to have misinterpreted the control parameters of the spring joint which, I must admit, are not very well chosen (it's what I needed to model a rope). The stetched and compressed spring constants are the only 'real' spring constants. If the spring is stretched or compressed beyond the limits ste by min- and maxSpringSize, the involved body's impulses travel over the spring directly, as if the bodies are directly connected at the joint axes. Since the simulation is done in discrete steps, the spring can be stretched or compressed beyond its limits too far, the brokenStringConst determines how much force is used to correct this.
5  Game Development / Game Mechanics / Re: Opinions please? on: 2007-03-27 20:27:19
A very amitious project! Are you working on it alone? I love space shooters as well, although I'm generally too lazy to actually get my joystick to play...

Writing your own physics simulation seems overly complicated, why did you choose to write your own rather than to use for example JOODE?
6  Java Game APIs & Engines / Java 3D / Re: Bouncing Ball - Physics and Collision Detection on: 2007-03-27 20:12:20
The 'animation' of a moving ball is usually (if not always) done by calcuting the ball's new position every frame and drawing it at the appropriate position. I don't know anything about Java3D, but I'm pretty sure you wouldn't need anything special like a PositionInterpolator that you mentioned.

Judging from your questions, you seem quite new to game programming in general (please forgive me if I'm wrong). Might I suggest to start with simple 2D games first? Implementing a small packman game would teach you most of the basics you'd also need for 3D and can be done in less than a week's time. Any 3d shooter would certainly cost you months or more likely years to finish, depending on how much you start with.

You'd be suprised how incredibly complicated physics-systems can be, something like ODE (or the java port/rewrite JOODE) cost a number of people a few years to write. I'm not trying to discourage you though, but in this case it might be more educational and rewarding to start small.
7  Game Development / Shared Code / Re: new phys2d joint on: 2007-03-25 17:51:07
The best way to get some experience is to fiddle with the examples. Demo21 shows the SpringJoint. Using the SpringJoint to simulate non-rigid body simulation might work, but I suspect it will not give very nice results. For example the SpringJoint tends to be quite bouncy as it has no built-in friction. I'm quite sure the SpringJoint is too simple to be used for general non-rigid body simulation, but maybe it could be used in some cases.

Did you have a specific application in mind?
8  Game Development / Performance Tuning / particle system maximum number of sprites on: 2007-03-24 20:51:22
I was experimenting with some fancy particle effects using Jos Stam's fluid solver which looks really nice. There is a possibility that I could use this stuff in my little towship game and possibly other future projects. The main problem is that it uses quite a lot of sprites. In the range of 1000-10000 sprites. The sprites' dimentions go up to 64x64. There are many tricks to limit this number somewhat but ultimately more sprites will look nicer. So I was wondering how much would be the maximum for 'normal' computers.

How many sprites do you use for your particle effects? What should be my aim if I'm targeting 'my mom's computer' (with hardware acceleration though)? Does the size of the textures matter much (both their onscreen size and in memory size)? Is the video card's fill-rate really the only bottleneck or should I also avoid things like scaling or rotating? Is an alpha channel also expensive for hardware accelerated graphics?

ps. Yes I could go and do experiments myself somewhere, but hey, I'm lazy.

9  Game Development / Game Mechanics / Re: polygon support in phys2d on: 2007-03-14 23:43:32
The gears demo is quite simple actually, to me it seems to behave quite accurately. The only thing to which a force is applied is the smallest gear.  I was inspired by monowheels, a motercycle where one sits inside the wheel. Although it doesn't really resemble one I must admit Wink.

-- edit: fixed the closing url tag
10  Game Development / Game Mechanics / polygon support in phys2d on: 2007-03-14 17:21:19
I finally decided to post a patch of my work on polygon support for phys2d. Hopefully it will be integrated into phys2d soon. It seems to be working quite well, but further testing has to prove that. Note that I did not finish line collision support as I was planning to, it took me too long to get that done as well. This means that line-line collisions are not supported at all and collisions with the endpoints a line gives somewhat strange results. Some other features added by the patch:
- bitmasks for collision groups
- very basic ambient damping
- collider factory (should still be converted to a table-based method
- .. maybe more small things that I forgot..

The patch also ads two demo's, the first one is showing off colliding objects of all shapes and the second one some gear construction that I made for fun.

Click to Play
Click to Play

For now I'm totally fed up with this stuff so don't expect updates very soon. The code is quite thoroughly documented (well, my code is  Tongue) and I'd be happy to answer any questions. If I ever have another go at this, I'd limit myself to convex polygons and use a well documented algorithm like lin-canny or v-clip to implement this. Getting a proper penetration depth and collision normal really is a major problem and I think there will still be issues with strange shapes. I have a very strong feeling that my solution is unnecessarily complicated  Undecided.

The code also contains some commented out pieces of code that could be useful in the future. For example line-line collisions is actually implemented, but disabled because a small piece of functionality is missing. There's also some commented out code in the Arbiter class of which I wrote a different version which reuses vector objects and some other things, it's ugly but made the thing run significantly faster.

Finally the patch. I hope you make good use of it Cheesy
11  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-03-07 22:22:11
(Of course correctness should be of higher priority than performance.)

Why should it? As long as everything looks 'natural' I'm ok with it. In any case, I haven't had any need for doubles yet; the problems that I encounter are usually more related to picking the right collision normal and penetration depth.

There might be some trouble up ahead though. I haven't properly tested the accuracy yet, for example placing object very far from the origin and using very small objects. Most certainly things will go wrong somewhere, if it turns out we need more 'space' (determined by the minimum objects size and maximum distance from the origin) switching to floats isn't really big a deal.

Maybe fixed point math could be useful. Does anyone know whether fixed point math actually is faster than floating point math? On modern processors like my dual core amd64 it's probably completely irrelevant, but what about mobile processors?
12  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-03-07 09:45:49
Using doubles only makes the problem more rare: very small penetrations will simply always be there, I have to deal with them some way or another.
13  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-03-06 22:43:17
A small update: I am still working on the collision detection, it's mostly a long and painfull process of debugging. There are quite a lot of problems with floating point rounding errors which are not easy to solve. While many examples work perfectly, like the gear system I showed before, however some simple examples exhibit very strange (jumpy) behaviour.

Movable line support is coming along nicely, although I will have to seriously alter the collision detector's structure to properly implement line-line collisions and allowing one way pass-though lines. For both problems, I need to know on what side (of a line) the other body was in the last frame. Just making the collision detector statefull isn't enough; it will have to be updated each frame as well. But I'm talking to myself.

Currently I'm planning to
- get the most apparant bugs fixed or work around them
- get movable line support working except for line-line collisions and pass-through lines
.. and release a patch. After that I'll continue with optimizations and getting the line-stuff working, but that will be another patch.

I still update my project's svn fairly regularly:, in case you can't wait any longer.
14  Discussions / Miscellaneous Topics / Re: If you could change Java, the language, what would you change? on: 2007-03-05 09:33:53
And there goes strong type checking out the window.

While this is true for java's type system as it is, it is not necessarily true in general. There are strong type systems where you don't have to decide whether you're using floats or ints in an expression, this is inferred by the compiler automatically. Some functional languages like Haskell have this feature and it works great (in most situations). This feature is called type classes which has nothing to do with OO-classes.

For example 34 + 4 * 2 would have a type (Num a) => a, which tells us that it gives us a polymorphic type a (any type a), wich is in the 'Num' class. Had I used a 'floating point' somewhere, e.g. 34 + 4 * 2.2, the type would've been (Num a, Fractional a) => a. Note that Fractional also implies Num, so one can leave out the 'Num' class.

You might be right for #2 ("Methods that take any input, currently have to have a version for Object plus all the primitive types. e.g JUnits assertEquals, could be condensed from 20 to 2 methods"). I don't understand what exactly he wants to have here, so it would be hard to judge wether it would be possible with a strong type system.

15  Game Development / Performance Tuning / profiling rules! on: 2007-03-01 22:21:11
I'd like you to hear a small success story on profiling. I am currently working on phys2d, see this topic, because I need it for a small project of mine called towship. From the very start I did think about efficiency in a bigger picture, for example testing all edges of both polygons would be very expensive (n*m) so I first select collision candidates (still quite some room for improvement there). But I didn't care much about smaller efficiencies like avoiding square roots wherever possible and those kind of things.

I decided to use a profiler to find the pieces of code where optimizations were really needed although I thought I knew more or less which parts would be problematic. Well, I couldn't have been more wrong. The first bit of very expensive code was the line-line intersection code, which I implemented with 4 crossproducts (where I only calculated the Z axis!). Rewriting those 10 lines of code immediately doubled the frame rate (from 1 to 2 fps in the profiler  Tongue).

The next bit of code was even more unexpected. I used a HashSet of integer which also was quite expensive, apparently it has a lot of overhead. I tried several alternatives, first I found a specialized IntegerSet library which was much faster but has some licensing issues (I wanted to include the source code itself). So I moved on and tried the java BitSet (although I was worried about the memory overhead in that case) which was faster than the HashSet but a little slower than the IntegerSet. Finally I tried a very simple handcoded singly linked list. It worked like a charm and was the fastest solution thusfar!

So, in roughly two hours work and only about 200 lines of code rewritten/changed, I increased performance by 400%!  Shocked

Next time I won't hesitate a second to use a profiler and if any of you have doubts .. well .. just change your mind!
16  Game Development / Game Mechanics / Polygon collision picture! on: 2007-02-28 16:52:38
I've got the polygon support more or less ready. There are still many bugs to find/fix, optimizations to be made and code to be cleaned up and better documented (although it is quite alright). Bottom line, no patch yet but you can get the current stuff from my project's svn server (which I mentioned in some earlier post in this thread).

To tease you, here's a picture of a nice demo (yes, it really runs perfecty):
Click to Play

Is there really no good BSD licenced util package out there? Because I've had to use some more standard java stuff.
Huh Why do you need to not depend on the standard Java libraries?
Well it wasn't really my choice, but Kevin put some effort into making it independent so I suppose I should keep it that way. There are some very clear advantages to having less dependencies though:
- no problems when the java api changes and the library will work with any java api
- it should be fairly easy to make a stand alone package which is light weight
- you don't have to deal with someone else's bugs (which is a minor issue with the standard libraries)
- .. probably more..
17  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-27 12:02:00
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.

Seems like a good idea. I'll have to keep that in mind, since I have the more or less natural tendency to keep adding features/complexity it will be difficult Smiley for me.

Again a small update, I have colliding polygons now, but I discovered some bugs in the process. Some of which are very nasty, especially finding the collision 'features' proves to be a royal pain. These features are the entry and exit point of one polygon into the other. These can be simple, i.e. where the first polygon just penetrates the other's hull or complex when the first polygon goes all the way through the other polygon.

Not only does the contact point stabilization depend on these collision pairs but also the penetration depth calculation.

Hmm, who exactly am I explaining this to? Grin .. Well at least you know I'm still working on it.

The line shape was a dirty hack in place of proper polygon support. Might be best to just rip it out altogether and only replace it if it's actually required for your project. Most things I want to do with the library won't need lines if polygon support is in see this running.

I'll see what I'll do with the lines, my first thought is to leave them in because they can be a lot more efficient in some cases, for example when polygons have very different sizes like walls colliding with objects. Also because the current implementation of polygons doesn't allow non-closed polygons, I'd leave them in. Maybe it's an idea to simplify them a little (the Line class I mean).

Then finally I have one question. I really need some containers here an there, sorted and otherwise. So far I've managed to restrict myself to a HashSet from the standard library. In the end however, these dependencies need to be cut. Does anyone have some good util classes under a BSD compatible licence?

18  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-24 18:36:22
I think it's a great idea to have proper support for 2d in JOODE. All my work on phys2d is under the phys2d license as well so you can copy whatever you need. However, isn't there something to be said for a small 2d collision detection library as well? I mean, suppose JOODE has all the functionality for 2d that phys2d has at some point, would there still be a reason to maintain phys2d?

I was also wondering whether there is/will be a lot of shared code in the 2d and 3d stuff of JOODE, other than general math (vectors/matrices) and containers (hashmaps/lists). If there is not that much overlap, wouldn't it be good to have two separate libraries?

Then a small update on my progress. I've made significant progress for the convex polygon collisions. It seems to be working completely (also with lines, circles and boxes), but I have not thoroughly tested it yet and some optimizations remain. As I said before the methods I employ should work for non-convex polygons just as well (a little less efficiently though). I'll give that a try tomorrow or tonight.

I'm also in the process of allowing lines to be moving colliders, but haven't quite finished that. Unfortunately it means I will have to dive into the old code which is, imho, ugly and unreadable (not just because it's not my code).
19  Java Game APIs & Engines / Tools Discussion / Re: 2D Particle Effect Editor on: 2007-02-23 19:07:12
ATI card by any chance? Seems to be issues with LWJGL AWTCanvas and ATI cards (at least thats whats been reported so far)

nope, nvidia
20  Java Game APIs & Engines / Tools Discussion / Re: 2D Particle Effect Editor on: 2007-02-23 12:55:35
Hmm pedigree doesn't work very well on my computer (ubuntu linux). It crashes and the UI is borked at times. If I ever find the time, I'll look into it myself, but that's not very likely. Particle reality doesn't seem to have been updated either, is there anything else available?
21  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-23 12:26:17
Well, I personally think that in this case the, apparently not so expensive, use of typeof won't give any measurable performance hit because it will happen only a very limited number of times per frame. Let's see, the number of narrow phase collision checks times two to be exact. So that's peanuts compared the actual collision check. Not that the discussion isn't interesting.

I really mis on the fly construction of (anonymous) functions, like lambda's in functional languages. Of course you can make an anonymous class in java, but I'd like to have access to variables in the scope without making things final. C# allows those kind of functions to be created. But I suppose this concept is only very distandly related to function pointers Wink so I'll stop ranting.
22  Discussions / Jobs and Resumes / Re: how much it cost to make an RTS similar to RedAlert? on: 2007-02-21 09:59:04
Assuming that RTS games are indeed the most complex kind of games, why would that be? So compared to a realtime 2d game (think of shmups and/or rpg's) let's see how complex an RTS might be.

- The graphics don't seem to differ that much in complexity from any realtime 2d game, for example a tileset and unit sprites plus some particle effects for explosions would do it (which sounds easy here and now, but I know it's hard/expensive for any game).  So no difference here...
- An  AI (high level, not indiviual units) would be very complex indeed, but we could skip that by making the game multiplayer only. Okay, no real difference yet...
- Speaking of which, for a multiplayer game, setting up the networking would be a necessity, which I imagine isn't easy either (never done it myself). Most other 2d games don't have networking, but if they does, I'd say it's just as hard as for an RTS.
- Most RTS's that I know of, don't have any real physics system, I'd say just about the same thing as what any realtime 2d game would have.
- Sound.. I can't see the difference either

Well for the plumbing, so far so good (I'm probably forgetting/ignoring some issues). So if I'm right, which admittedly is a big if, where does all the complexity come in? I can see that balancing units in such a way that the game is interesting strategically would be very difficult. It would require an immense amount of testing/tweaking. But is it really all the difference?

All my argueing aside, I do agree with eliwood's guestimate of 2 years and $500,000. However my word is worth very little as it is based on a flimsy amount of real world experience. So, expect at least to double the cost and time required.
23  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-21 09:30:56
I might give that a try, but I'll have to find an approximation method as well for non-convex polygons.
24  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-20 17:12:20
I have made quite a lot of progress. Convex colliders are implemented and I expect to have support for non-convex object very soon as well. If anyone would like to have a look at the code, check out the svn repository of towship:

I will send you a patch as soon as things have advanced some more, but if you can spare the time to have a look at what I've done.. I would appreciate any comments.

There is one problem for which a solution is not entirely trivial though: I have to find an accurate penetration depth for collisions. The current algorithm only finds the intersecting faces from which I can get the intersection point and normal, but penetration is not as simple. Does anyone have any ideas how to solve this?
25  Discussions / Jobs and Resumes / Re: how much it cost to make an RTS similar to RedAlert? on: 2007-02-20 16:45:12
I don't know what kind of project you had in mind, but there are many open source projects for RTSs. Have a look around, it will definately be easier to alter one instead of recreating one.  Spring is a particularly mature one, with many different versions already available, but it's not java. I don't know any java ones from the top of my head, but I wouldn't be suprised if there are a few!
26  Game Development / Shared Code / the separating axes algorithm on: 2007-02-20 16:38:41
Because I spend some time writing this stupid code and, in the end, don't need it at all, I'll just post it here hoping that someone can use it sometime Smiley. The separating axes theorem is used to determine whether two convex polygons are colliding. Absolutely nothing amazing and well documented on the net, but here it is.

By the way, it would be nice if we had a 'real' repository for these code snippets. Or we could just use some existing ones...
27  Game Development / Artificial Intelligence / Re: artificial potential fields on: 2007-02-19 09:02:14
Thanks for the suggestions, I'll definately try dropping repulsive fields on the way. My first exploration of the subject actually was quite promising. Even the most basic versions seem to do well enough for this game, this is mostly because I'm not desparately trying to avoid collisions, as long as it looks remotely 'realistic' (not totally brainless) it's okay.

Another advantage of these artificial potential fields is that I get some tweaking parameters for free. For example, it's fairly easy to make an AI behave more reckless or very afraid. An AI can also evade specific objects in different ways, for example, a seeking missile shouldn't be evaded in the same ways we would evade a rock. There are some more things I plan to experiment with like flying preplanned paths, dynamic path flying (eg. circle around the player), flocking like behaviour and formation flying.

I'm going to combine the potential fields with path finding for the static environment. Hopefully this will also resolve some of the local minima. I was hoping I could use the potential fields to evade moving objects.

Keep the suggestions going and I will keep you posted!  Wink

28  Game Development / Game Mechanics / Re: exact ray box intersection on: 2007-02-16 19:13:49
I don't know if you're still reading this but I might have some more to add. The separating axes theorem (which holds for any convex poly) in principle only gives you the distance between two convex polygons but it's not that hard to extend the algorithm. I'm currently working on that myself for convex polygons, so if you want a full algorithm, just ask.

For box line collisions you could have a look at the phys2d library (, specifically the LineBoxCollider (
29  Game Development / Game Mechanics / Re: Which physics engine? on: 2007-02-15 12:45:44
If the physics are 2d, you could give phys2d ( a try, its quite basic. However there is no other documentation than the comments that go with the code and consequently javadoc documentation. No tutorials whatsoever. There are a lot of demos that should get you started though.
30  Game Development / Game Mechanics / Re: New Version of Phys2D on: 2007-02-15 09:14:11
Well, I'm not quite sure about wether or not users would add new colliders, but it would be nice I suppose. You really dislike reflection that much? Maybe there's some caveats I'm unaware of? In these cases I usually just choose the simplest solution. What I dislike most about most uses of instanceof, is the fact that, in most situations, you still need to cast the object. I suppose I prefer C++'s way of dealing with it. But well, in my eyes both java's and c++'s typing systems are quite primitive anyway.

Anyways, from the top of my head I don't really see a solution without reflexion. Any ideas?
Pages: [1] 2
EgonOlsen (42 views)
2018-06-10 19:43:48

EgonOlsen (22 views)
2018-06-10 19:43:44

EgonOlsen (43 views)
2018-06-10 19:43:20

DesertCoockie (197 views)
2018-05-13 18:23:11

nelsongames (124 views)
2018-04-24 18:15:36

nelsongames (123 views)
2018-04-24 18:14:32

ivj94 (864 views)
2018-03-24 14:47:39

ivj94 (125 views)
2018-03-24 14:46:31

ivj94 (768 views)
2018-03-24 14:43:53

Solater (140 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!