Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
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  
  Arrays  (Read 1997 times)
0 Members and 1 Guest are viewing this topic.
Offline killingtime

Senior Newbie




Humm


« Posted 2003-04-06 10:20:45 »

I can see why this isn't going to go down hugely well, but do you think the addition of direct array support in LWJGL would be a wise move? I know that they are slower, generally, than their native mapped buffer counterparts, but overloading things like color3fv with an array version gives people a choice (though of course it might lead to people using these exclusively).

I don't know, passing array references just seems more natural that's all.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-04-06 12:39:54 »

It certainly is natural, unfortunately it's naturally really slow too, so we won't be adding it. Besides - you are certainly better off in Java doing
1  
gl.color3f(color[0], color[1], color[2]);

than
1  
gl.color3fv(color);


The syntax you see is a bit of a C anachronism.

I'm still not even sure we should be using pointers myself but there's still a huge overhead getting an address out of a direct bytebuffer using JNI methods. More experimentation needed.

Cas Smiley

Offline killingtime

Senior Newbie




Humm


« Reply #2 - Posted 2003-04-22 15:56:29 »

I understand why you don't want to add them. I wrote this when I was originally thinking of moving from GL4Java to LWJGL. Now that I decided to go with it anyway I'm kinda getting used to it, or just sticking with using Xf rather than Xfv for funtion calls in some areas of code.

On a different note though since I've noticed that they are in the examples and I've stuck them in the code that I'm using should LWJGL have a utility library for generating float buffers (or any other type of buffer) we could use an OpenGL like syntax and have something like:

public static FloatBuffer floatBuffer3f(float, float float)
{
 //generate and return the float buffer with the values      given
}

and give "overloaded" forms for arrays and other common sizes (well four points I guess).

Let me know what you think, I'd be happy to write them, though it is hardly much work and it could be stuck in a package like org.lwjgl.util or something.



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

Senior Member


Medals: 1


Who, me?


« Reply #3 - Posted 2003-04-22 19:54:51 »

We had a little discussion a while ago about abstracting the "int pointers" away with a safe data-type wrapper.  I think the general consensus was that it would add a load of classes to LWJGL, add a load more method signatures and add a lot more maintenance issues, and not help out all that much.  If you're careful you should have no problems with ByteBuffers, they just take a bit of getting used to.

They're a bit of a waste for storing small amounts of data like single vertices anyway.  At least with the current JVMs they appear to be page-aligned, so each vertex will take up 4K of RAM...  Shocked


However, a few functions to automate the creation of ByteBuffers might be useful.  It would certainly stop people forgetting to multiply their calculated size by four for 32-bit data types, or forgetting to set native ordering etc.  Sys looks a good place for them - any thoughts?

public FloatBuffer createFloatBuffer(int size)
public FloatBuffer createFloatBuffer(float[] data)
etc

Hellomynameis Charlie Dobbie.
Offline Captain-Goatse

Junior Member




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


« Reply #4 - Posted 2003-04-23 10:31:25 »

This is for the devs of lwjgl, mainly cas:

What do you guys plan on doing with the buffers? I mean I know only one use for the buffers, but wouldn't it be a bit nicer for even the syntax of the code to hide the Sys.getDirectBufferAddress(buffer), since it does not serve any real purpose, at least not to my knowledge.

It is just a minor thing and not really that important, but I just need to ask does it serve any other purpose?

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #5 - Posted 2003-04-23 11:07:22 »

(I'm not an LWJGL dev, but I'd like to chime in here)

The reason for using buffers is to pass chunks of data to OpenGL via the LWJGL JNI layer.  The various methods that access or fill buffers with data could take a ByteBuffer object directly, but getting the data out in JNI-land would then be quite expensive.

It's a lot cheaper to just generate the address Java-side and cache it somewhere.  Sys.getDirectBufferAddress does that generation.

Hellomynameis Charlie Dobbie.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #6 - Posted 2003-04-23 11:17:29 »

For the record, we have been talking about doing a MemoryBuffer object instead, which is just a ByteBuffer with its chached address. That way:
a) it's "easier"
b) (most importantly) more safe.

Some have been arguing against lwjgl, exactly because you could wreak havoc with those pointers. By making lwjgl safe (and NOT making it abysmal to work with) we will make the library available to a whole other group of people.

This hasn't been thought 100% through yet, so no promises here...

Offline Captain-Goatse

Junior Member




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


« Reply #7 - Posted 2003-04-23 12:34:22 »

I know what it is for, perhaps I wasn't clear enough. Can't the sys.getdirectbufferaddress be hidden somewhere into the code? Since it doesn't seem to have any other purpose than passin in the buffer address, why can't it be hidden somewhere into the code?

I thought that was included into the principles of clear syntax.     If it is trivial and does not have any other purpose, then why is it there? It just makes things one step more complicated. I mean if there as a good reason, for the user to use it in that form, then it should be in that form. If there isn't, couldn't it be included somewhere else?

Sys.getDirectBufferAddress is out of place and looks nasty in the code.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #8 - Posted 2003-04-23 12:55:20 »

I think I understand what you mean.

If MemoryBuffers are implemented, then it will disappear from your code.  You instantiate a memory buffer, the constructor gets the address and stores it, and when you pass the MemoryBuffer to a method it either calls the "pointer" version of the method with the address of the buffer wrapped in the MemoryBuffer, or it passes the whole lot to JNI which then extracts the address and uses it.  It's a bit more overhead for the library, but it removes that from the developer.

Currently you can't do without getDirectBufferAddress, as you need to do the caching.  Passing a ByteBuffer to a method and making it get the buffer's address each time is too costly.  However, until MemoryBuffer appears (if it ever does) for now you can just implement your own wrapper for ByteBuffer, as I'm sure many of us have done so.  Used like:

gl.getIntegerv(GL.WHATEVER, myBuf.getAddress()) ;

Call getDirectBufferAddress in the constructor, cache it as an instance variable and implement a getAddress method to pull it out.  The address is then held with the data, you're less likely to get things mixed up, and the "ugly" method call disappears from all your code except the wrapper.  Tada! Grin

Hellomynameis Charlie Dobbie.
Offline killingtime

Senior Newbie




Humm


« Reply #9 - Posted 2003-04-23 13:20:52 »

Would the replacement buffers subclass the current nio classes, or would you create another native allocation system. If the 4k minimum allocation is true (and I have no reason to accuse cfmdobbie of being a lier) then ByteBuffer is really quite expensive.

As for the buffer creation utility class I was thinking of the package being org.lwjgl.util and the class Buffer with static functions for creating a three and four value buffer for the most regular types taking both seperate values as an argument and arrays as an argument. There would also be a function to create an arbatary length buffer and one to create an arbatary length buffer based on an array handed in. An example of the basic format would be:

createFloatBuffer3f(float, float, float)

Basically the same format as that used in OpenGL.




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

Senior Member


Medals: 1


Who, me?


« Reply #10 - Posted 2003-04-23 15:17:37 »

Quote
If the 4k minimum allocation is true (and I have no reason to accuse cfmdobbie of being a lier) then ByteBuffer is really quite expensive.

I can't take credit for that piece of info.  There was a thread a while back which discussed ByteBuffer overheads, and it was Cas who put two and two together:

http://www.java-gaming.org/cgi-bin/JGOForums/YaBB.cgi?board=LWJGL;action=display;num=1045573177;start=0#3

Naturally, this behaviour may change in a future Java release.

Hellomynameis Charlie Dobbie.
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.

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

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

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

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

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

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

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

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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!