Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Games Center / Archived Projects / Re: Alien Flux Alpha Test 9 on: 2003-04-11 10:48:33
There is a problem with redefining the controls: When I try to hit one of the buttons to redefine a key or hit the ok button to finish, instead it binds the previously selected one to the left mouse button.
2  Java Game APIs & Engines / OpenGL Development / Re: Scene Graph on: 2003-04-10 22:03:28

I cannot agree with that. A point stands for a certain location in space whereas a vector is a direction that has no certain origin and can be located anywhere. That's also how mathematics and physics handle these items.
A thing like a position is very different from a thing like speed. A think like a vertex coordinate is very different from a thing like a normal.

And for they transform differently (applying a translation to a vector absolutely make no sense), they have to be treated differently.

Libs that ignore the difference have sometimes very ugly code when it comes to transform normals.....

When you use different classes for them you have additional code to maintain...

Making a difference between points and vectors by using different classes is actually new to me. I know two solutions, both make no difference at all, both call the thing (which is essentially a 3-tuple) a vector, and none of them produces any 'dirty' code if you know what you are doing.

Solution no. 1 (which I'm using in my engine): There is very very very seldom a case where you do not know if a vector means a position or a direction. Actually I have not yet seen any such case. There are simply two transformation functions, one for points and one for methods.

Solution no. 2 (which OpenGL uses): Very nice, but requires additional CPU time. All vectors are stored as 4-tuples, where the fourth value is 1 for positions and 0 for directions. A transformation is stored as a 4x4 matrix where the rightmost column contains the translation part of the transform. Advantage: You can store the translation in the matrix as well. Also, computing the signed distance of a point to a plane means simply computing the dot product of two 4-tuples.

BTW the ugly code when transforming normals may have another reason: You cannot transform normals the same way as you transform vertices. This only works for either orthogonal or orthonormal transformations (not sure). Otherwise the normals are tilted towards the surface during transformation.
3  Java Game APIs & Engines / OpenGL Development / Re: Threads and LWJGL on: 2003-04-10 07:51:42
I think Cas is right that LWJGL should not be thread-safe, because I actually don't see a reason to have several threads feed OpenGL at the same time. But if you want to move other stuff like the game logic to threads, why not? Unless you are already in the optimizing stage, your main criterion should be whether your program works in a pro-thread way. That is, it has to do several unrelated jobs which need to synchronize seldom or never.
4  Java Game APIs & Engines / OpenGL Development / Re: LWJGL jni similiar to SWT jni? on: 2003-04-09 23:32:40
I can provide a set of math classes that I have more or less copied from Crystal Space. Euler angles and quaternions are still missing, but that should be simple. Apart from that, it got 2d and 3d vectors, matrices, planes, 3d transforms, axis-aligned boxes and an interface to parametric lines and surfaces.

The real point however is that all classes are *IMMUTABLE* like String. I know that this will hit you because it means lots of allocations all the time. On the other hand it makes coding very clean and makes optimizations possible which are not possible with mutable classes. (For example, you never need to copy a 3d vector).

My intention was to use these immutable classes until they prove to be a bottleneck, and then introduce mutable variants (like StringBuffer) for the inner calculations but still use the immutable variants where possible. Has anyone made real experience with the performance of such an approach?
5  Java Game APIs & Engines / Java 3D / free stuff on: 2003-04-07 14:21:09
Just got a mail with this link:

Looks like tons of free stuff, but I haven't look at it myself yet.
6  Java Game APIs & Engines / OpenGL Development / Re: lwjgl runtime difficulty on: 2003-04-06 22:44:56
What about alpha? I had problems with the 0.5 because it couldn't get alpha for the frame buffer. In the latest CVS version this works though.
7  Java Game APIs & Engines / OpenGL Development / Re: Multiple GL Windows on: 2003-04-03 19:54:00
Wouldn't it be possible to run swing inside the OpenGL window? AFAIK the swing components are designed to render themselves to an awt.Graphics object, whatever that does internally. It should be possible to write such an object that actually maps everything to OpenGL. Sounds nice to me because suddenly you get everything in your GUI that swing has, including user-made extensions from the 'net.
8  Java Game APIs & Engines / Java 3D / Re: 3d engine using openGL directly on: 2003-04-03 10:37:16
And about structs: I'm not sure if that really speeds things up. Because, before you can access the members of a struct you have to set up the struct itself (as a window to the buffer). Either this takes more time than you gain, or you cache the struct itself and that takes a lot of memory when you do it everywhere.

You DO gain some cleaner code, but you could get that otherwise, like:

// normalize vector at position 20
buf.readVector3f (vec, 20);
vec.normalize ();
buf.writeVector3f (vec, 20);

This is nearly as clean. To solve the speed problem, I think another trick than structs is needed. Speed is only a problem anyway when you want to perform some operation on all elements of a big buffer - The term "batch processing" comes to my mind again.
9  Java Game APIs & Engines / Java 3D / Re: 3d engine using openGL directly on: 2003-04-03 09:58:33
Just found out that LWJGL already supports what I need! In fact, your library looks very similar to what I had in mind. Looks like the right choice to me Smiley

@kevglass: I wanted to provide a higher-level API than OpenGL to the Java side, but still based on JNI. Like, transfer an array of vertex data to the native side at startup and then, at runtime, do something like "batch processing": one JNI call to a native function which sends all data to OpenGL in a tight loop. In other words, exactly what I found buffers in LWJGL to be Smiley
10  Java Game APIs & Engines / Java 3D / Re: 3d engine using openGL directly on: 2003-04-02 19:12:59
Actually, I wanted to write a "lowest layer" (the only part of the program that contains native code), set it on top of OpenGL and provide a _different_ interface to the Java part. However, I have noticed that I don't get around providing some functions that are actually the same as OpenGL functions. So I could as well try an OpenGL binding Smiley

One thing would be important to me though: In case I find a part of your mapping that becomes a bottleneck because it works through JNI, is it then possible to replace only that part with a self-made native library?This native library would do nothing than to run some OpenGL functions in a kind of "batch mode" to avoid JNI. I think it should work, because OpenGL is designed to work that way, but I want to be sure.

Not that I expect such problems, but I don't want to change the binding again, should they appear.
11  Java Game APIs & Engines / Java 3D / 3d engine using openGL directly on: 2003-04-02 09:03:16
Hi you all! I'm currently unsure what to do. My goal: I want to write a 3d engine. However, I am not sure which low-level API to base it on. AFAIK I have three options:

1. Base it on Java3D. This sounded very good to me at the beginning because it is portable and the API allows a lot of optimization in the background. However, I did not read any "performance success stories" yet (only about success in development time), and the API is not exactly what I need (maybe it works with some tricks though).

2. Base it on an OpenGL-for-Java binding (LWJGL, GL4Java, etc.). This leads to problems as well: When it comes to transferring all the data of a really complex 3d object down to OpenGL, the repeated JNI calls *seem* to be a performance problem (can anyone clear this issue?) But an OpenGL binding seems to be "almost good"

3. Write an own Java/native binding which uses OpenGL at the native side but offers a higher-level interface to the Java code. This would allow to create an API which is designed specially for Java (unlike OpenGL) and also does a lot of caching on the native side.

As you probably see, I favor the third option. Note that I understand the difference in Java3D vs. OpenGL as "scene graph vs. immediate-mode access". I would write the scene graph / management part completely in Java then (the native part would work at a lower level then scene graphs).

It also seemed to me that OpenMind is similar to what I want to do, but like Java3D its API is not what I had in mind.

My question is, does this sound like a reasonable approach?

Thanks in advance.
Pages: [1]
EgonOlsen (1572 views)
2018-06-10 19:43:48

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

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

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

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

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

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

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

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

Solater (882 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 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!