Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  LWJGL jni similiar to SWT jni?  (Read 2702 times)
0 Members and 1 Guest are viewing this topic.
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Posted 2003-04-08 07:56:50 »

http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

Now, let me ask a question, since LWJGL is calls OpenGL through C, is it possible to do JNI calls directly to the OpenGL as discussed in this article?

As far as I understand it requires major hacking to get this work, but is it actually possible or even worth it if a person has incredible amount of time to waste away?
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2003-04-08 09:49:21 »

Uhm... I am not entirely certain of what you're getting at...

but all of the gl/al code is simple passthru of arguments from Java.

Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-04-08 09:56:46 »

Well, that's not exactly what we're doing but we're very similar. Our OpenGL calls are passed straight on down to their C calls. That's why we haven't got array versions of the methods etc.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #3 - Posted 2003-04-08 11:50:15 »

Hmm.. I was just wondering is it possible to call a function directly with JNI from the openGL library. Although the C overhead is tiny, it would be possible wouldn't it? Let's say if someone were smart enough to hack OpenGL the way they did with windows code at SWT. Basically it would be a lot easier, but more time consuming as you'd have to write JNI function for every single openGL call.

As the article discusses, the operating system is very primitive, and that is how OpenGL is, except that the functions are the same on each of the platforms. However, the problem I see now is that how OpenGL was coded initially. By doing this, we could get rid of the Sys.getDirectBufferAddress and the idea of buffers and reduce one level of overhead as well as call directly from JNI.

So instead of calling C you'd call directly from opengl32.lib and glu32.lib and let the JNI do its work. Would this be possible? As far as I understood the article it is.

I'm interpreting this through that article and I could be talking out of my ass.


Edit: This way we could also take advatange of JNI type handling functions...
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-04-08 12:01:45 »

Indeed you are Smiley
We're doing it the bestest, fastest, easiest way possible. In theory we could go the whole hog like with SWT and push our OS idiosyncracies up into Java as well but I have a general aversion to OS-specific classfiles. But that can be solved using interfaces and private implementors anyway. It's an idea that's probably worth considering because it would likely make our code maintenance that much simpler.

What do you think Elias?

Basically we'd need an "OS" interface with all the OS calls we do, and then we'd just simply move all our native code into private Win32/Linux/MacOS classes. And then we'd need a bridge interface between our public APIs and private APIs - so the Window class's create() method, for example, called WindowWin32.create(), which in turn called all sorts of Win32 functions directly.

It'd certainly have the advantages outlined in the article.

Just a thought.

Cas Smiley

Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #5 - Posted 2003-04-08 12:48:01 »

I know you are doing the [insert positive adjective here] graphics library around, but it was just a thought. To tell the truth every time I call Sys.getDirectBufferAddress, I'm first of all ashame of doing it and besides it hurts my brain so hard, due the fact that it is not the most elegant way of getting around.

Secondly, someone(I?) could probably write a *proper* vector maths library, since to tell the truth I'm not very keen on the current one. For example, it is missing conversion to euler angles, quaternions and rotations. I hate to have my own classes around for most trivial tasks that the library could do. Also I know quite a few optimizations so there might be a speed increase(although I can't quarantee that).

I'm pretty sure a lot of people like it how it is, but.... anyway.
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2003-04-08 16:34:29 »

If you'd like to contribute some more vecmath classes to the package we're especially happy to have them Smiley

Cas Smiley

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #7 - Posted 2003-04-08 17:21:00 »

Hey Cas, just out of curiousity, what's all the fixed point math in SPGL for? Floating point is natural to GL, plus floating-point processors make fixed point almost unnecessary. (Well, in 3D anyway.  Smiley) Is there some specific optimization you're trying to achieve? BTW, neat idea on the 16 bit rotation system. It reminds me of the days when I was using a 256 degree rotation system so I wouldn't have to bounds check an unsigned byte. Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Offline elias

Senior Duke





« Reply #8 - Posted 2003-04-08 18:05:45 »

Quote
Indeed you are Smiley
What do you think Elias?

Basically we'd need an "OS" interface with all the OS calls we do, and then we'd just simply move all our native code into private Win32/Linux/MacOS classes. And then we'd need a bridge interface between our public APIs and private APIs - so the Window class's create() method, for example, called WindowWin32.create(), which in turn called all sorts of Win32 functions directly.

It'd certainly have the advantages outlined in the article.

Just a thought.

Cas Smiley


I'm not perfectly with you here - you want to create a jni functions for every native function we call, and kill the functions, like Window.nCreate, that does a lot of work on the C side? In a way, do the work on the java side, and make _every_ jni function a callthrough, like the gl calls. If so, I'm still not convinced that this would be a win in the long run - we have very few non-trivial jni functions anyway, but those we have call a lot of native window system functions once or maybe twice. So what's the win?

- elias

Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #9 - Posted 2003-04-09 15:59:15 »

I'll work with over the week end. However, my style is totally different from the current vecmath style, but I can leave mine as 100% compatible alternative.

Another thing I have different is that is store matrices and vertices as an arrays so Matrix4f is basically OpenGL matrix, this is to minimize the overhead, but I can put there access to all the cells if someone wants that, the only problem though is that if they are non static methods and thus they increase the memory cost of the object.

Basically I have one class Math3d, which has all the static functions such as multiplication and because java allows ambigious functions. the classes itself have their own funtions such as Matrix4f.buildEuler(vector3f v) and so on.

Also I'd like to know what the users want. I mean if people  like the current ones then there is no point changing them, Just those who want can take the new one.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Morin

Senior Newbie




Java games rock!


« Reply #10 - Posted 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?
Pages: [1]
  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 (52 views)
2014-10-17 03:59:02

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

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

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

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

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

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

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

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

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