Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
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  Java Game APIs & Engines / JOGL Development / Re: JSR-231 1.1.0 Release Candidate 2 Released on: 2007-02-06 11:54:48
Thanx Ken.

This is the part which I have missed: the FloatBuffer.put(FloatBuffer) method.

With that knowledge, the project I'm currently working on, to send OpenGL rendering over input/output streams, is almost finished. As a proof of concept, I redirected the OpenGL rendering from my sample Java application to native Max OSX application through UNIX pipes.

The result was awesome! The overhead of pushing the data through the stream was insignificant, and the animation seemed to run as smooth as in Java. As a point of reference I'd like to mention, that in Java I used GLCanvas, and in Cocoa I used NSOpenGLView.

One of the most noticable side-effects was, that in case of the Java application I used for testing (simple ZX Spectrum emulator), it ran much smoother when the rendering was sent over the stream. This may be due to the fact, that the actual rendering was delegated to the separate UNIX process, and was not performed within the same process in separate Java thread.

Thanks for your help Ken, and I'm waiting impatiently for final 1.1.0 Release.

2  Java Game APIs & Engines / JOGL Development / Re: JSR-231 1.1.0 Release Candidate 2 Released on: 2007-02-05 14:38:29
Hi, Ken.

I just wanted to apologize for my last post, because it was a complete junk.
I've just missed few things while reading the Javadoc fpr Java NIO, and that's why I was convinced,
that it was not possible to write data from, let's say, FloatBuffer to WritableByteBuffer.

I'm still not sure how to write the content of FloatBuffer in case it's not backed by a float[] array,
but I'll try to investigate it on my own, rather than taking your valuable time.


3  Java Game APIs & Engines / JOGL Development / Re: JSR-231 1.1.0 Release Candidate 2 Released on: 2007-02-05 10:47:56
Hi Ken, and thanx for your fast answer.

First of all, I'd like us to take a little bit deeper look at the Java NIO API.

The first observation is, that the Java NIO API not provide any method to copy the content of buffer of "different" type to a ByteBuffer. In other words, having an instance of, let's say, FloatBuffer it's not possible to create a ByteBuffer out of it, using Java NIO API. In that light, it's not possible to write generic method in Java, which would write the content of, let's say, FloatBuffer (or any other kind of buffer different than ByteBuffer) to a Channel.

The second observation is, that the only way to create an instance of buffer of "different" type is to create a wrapper on an instance of ByteBuffer. In example, to create an instance of FloatBuffer, you MUST first create an instance of ByteBuffer, and then wrap it with FloatBuffer using ByteBuffer.asFloatBuffer() method.

That's why I think, that using ByteBuffer, instead of Buffer, as an argument in the mentioned methods in GL interface would be a sligtly better solution. I believe that it would simplify the native code a little bit (no need to downcasting), and increase the flexibility of GL interface, because it would make it possible to implement it purely in Java, in a complete way.

I love the idea of having a GL interface, because it provides an abstraction of GL to the Java developer. Having that, it's possible to implement the GL interface in any, custom way. Unfortunalety, because the java.nio.Buffer was used in a couple of methods, it's not possible to implement those methods purely in Java.

Final thought. Isn't it some kind of a hint, that there's no generic WritableChannel class with write(Buffer) method to write content of any buffer? What we have, is only WritableByteChannel with write(ByteBuffer) method. Maybe the GL interface should go in the same direction? Or maybe the Java NIO API should be redesigned/extended to have a generic WritableChannel class with write(Buffer) method?

Best regards,
4  Java Game APIs & Engines / JOGL Development / Re: JSR-231 1.1.0 Release Candidate 2 Released on: 2007-02-05 08:45:12
I don't know if it's the right place to put this message, but I could not find a better one.

I'm concerned about the decision to map (void*) type from C to java.nio.Buffer in Java. One of the methods using that mapping is glTexImage2D(). I'll try to describe the problem I have with it.

I'm working on a concrete implementation of GL interface, which instead of calling OpenGL library functions directly, would send the data to output stream, redirecting the actual rendering to the process (or any kind of input stream reader) sitting at the other end of the output stream.

The story behind this idea is very short. What I wanted to achieve is to perform rendering in Java, using an abstraction of OpenGL provided by GL interface. But the goal was to redirect actual rendering to different process (in my case it's a Cocoa application on Max OS X).

The problem I have is simple: there are a couple of methods having java.nioBuffer argument. What I need to do, is send the content of the buffer to the WritableByteChannel. The problem is, that it can not be done in general, because the write() method on the WritableByteChannel takes ByteBuffer as a parameter. There's no way in Java to wrap a Buffer into ByteBuffer, or to read the content of the buffer in general. The only thing which I can do, is try to downcast an instance of Buffer to ByteBuffer, and pray that it really is an instance of ByteBuffer.

I'm aware of the fact, that from the JOGL's point of view, it does not matter which kind of buffer is passed to the gl method, because it's possible to get access to the buffer content using JNI. But using pure Java it's not possible. That's why it makes the GL interface flawed in that are, because it's not possible to implement it without using JNI.

What is your view on that issue? Has it already been discussed somewhere else? I'm waiting for your response.

Best regards,
Michal Pociecha-Los
Pages: [1]
ivj94 (579 views)
2018-03-24 14:47:39

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

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

Solater (59 views)
2018-03-17 05:04:08

nelsongames (104 views)
2018-03-05 17:56:34

Gornova (122 views)
2018-03-02 22:15:33

buddyBro (665 views)
2018-02-28 16:59:18

buddyBro (89 views)
2018-02-28 16:45:17

xxMrPHDxx (491 views)
2017-12-31 17:17:51

xxMrPHDxx (727 views)
2017-12-31 17:15:51
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!