Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
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  
  Suggestions (to LWJGL team)  (Read 3047 times)
0 Members and 1 Guest are viewing this topic.
Offline Orion

Senior Newbie




Java games rock!


« Posted 2004-07-30 06:08:05 »

Hi! I have examined your binding and I have some suggestions on how to make it better. There are some things that I consider very weird.

1. There are no functions like
1  
glVertex3fv(float[])
or like
1  
glMaterialfv(...)
. I would rather prefer to use arrays than a "float, float, float" chain or Buffers in this case.
2. Why do use subclasses of Buffer rather than the Buffer itself? It is very strange.
3. Why don't you make a private constructor in GL11-15 classes and all other utility classes. They shouldn't have a public constructor and shouldn't be instatiated as all methods and fields are static!
4. Why do use only the ByteBuffer in gluBuild2DMipmaps function?
5. Why did you change GL names? I find it very inconvenient
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2004-07-30 07:31:14 »

Quote
Hi! I have examined your binding and I have some suggestions on how to make it better. There are some things that I consider very weird.
Hi, and thanks for  your comments. LWJGL has evolved a long way since its first inception. The way it is today is basically because it *feels* right, for the majority of the developers. That said, there will be some that want it to behave differently - we can't please everybody Wink

Quote
1. There are no functions like
1  
glVertex3fv(float[])
or like
1  
glMaterialfv(...)
. I would rather prefer to use arrays than a "float, float, float" chain or Buffers in this case.

Yes, it is more convenient - unfortunately this is exactly how you kill performance. When OpenGL renders, it wants its data fast. By using arrays you are forced to move data from within the VM which is considerably slower than using a direct ByteBuffer or variants thereof. See 5 too.

Quote
2. Why do use subclasses of Buffer rather than the Buffer itself? It is very strange.
We use subclasses of bytebuffers so that we know the datatype, and thus the offset into the buffer for elements.

Quote
3. Why don't you make a private constructor in GL11-15 classes and all other utility classes. They shouldn't have a public constructor and shouldn't be instatiated as all methods and fields are static!
Sure we could do that... but I actually don't see any user *benefit* from doing it... you can't use a GL11 instance for anything and it's a final class anyway - it would simply be for the sake of being more OOish

Quote
4. Why do use only the ByteBuffer in gluBuild2DMipmaps function?

See 1. Why not? - an image is just bytes - why wrap it in something else?

Quote
5. Why did you change GL names? I find it very inconvenient
The names that were changed was because  they didn't make sense in Java (they were removed entirely) or because the actual purpose of the method [gl*f, i, b] was implied by the type of Buffer supplied (FloatBuffer (f), IntBuffer(i), ByteBuffer(b)).

Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2004-07-30 08:11:41 »

Actually the constructors should indeed be private to avoid any confusion.

Cas Smiley

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

Junior Member




Java rocks!


« Reply #3 - Posted 2004-07-30 10:44:55 »

Orion,

Some people here, myself included, have developed simple wrapper classes that restore the functionality as you described, I found this very useful when porting code from the many C++ OpenGL examples on the web.

There are a few tricky ones though that you need to watch out for.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
public static void glVertexPointer( int size, int type, int stride, float[] buffer ) {
  glVertexPointer( size, stride, toBuffer( buffer ) );
}

public static void glColorPointer( int size, int type, int stride, float[] buffer ) {
  glColorPointer( size, stride, toBuffer( buffer ) );
}

public static void glTexCoordPointer( int size, int type, int stride, float[] buffer ) {
  glColorPointer( size, stride, toBuffer( buffer ) );
}


These methods don't execute immediately, the information is only used when a glDrawArrays call is made, so if you use both color and texture, you need 2 buffers to hold the data, rather than just reusing 1.

This was covered in a previous topic, here:-

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1077796504;

Andy.

Offline Orion

Senior Newbie




Java games rock!


« Reply #4 - Posted 2004-07-30 11:36:20 »

Thanks for answering so soon! I understand now what makes you use such methods.
Offline elias

Senior Member





« Reply #5 - Posted 2004-07-31 07:34:08 »

I've now added private constructors to all OpenAL and OpenGL static classes in CVS.

- elias

Offline Zeph

Junior Newbie




typical code monkey


« Reply #6 - Posted 2004-08-01 02:52:37 »

Quote
I've now added private constructors to all OpenAL and OpenGL static classes in CVS.

- elias


This makes sense, but unfortunately it seems to break spgl's AL class, which subclasses the org.lwjgl.openal.AL class.

Although it is otherwise a static class, it seems Java still wants the spgl class to inherit the constructor from its superclass.

I'd suggest it would be better to either make the org.lwjgl.openal.AL constructor protected, so subclasses can still implicitly inherit it, or remove it completely, since it will never be called anyway.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #7 - Posted 2004-08-01 06:54:28 »

Go for protected for all of them.  There's no way of getting confused and instantiating them without some odd-looking syntax (which will tip most people off), but it still allows for subclassing.

Hellomynameis Charlie Dobbie.
Offline elias

Senior Member





« Reply #8 - Posted 2004-08-01 11:37:53 »

Hm. Why does spgl's AL have to extend AL?

- elias

Offline Zeph

Junior Newbie




typical code monkey


« Reply #9 - Posted 2004-08-01 13:44:19 »

seems to be adding some convenience methods which may have been useful at some stage, but I can't see that they're adding much to the spgl API...

still, the fact is that it's more correct to have a protected than a private constructor unless the class is declared final.

IF AL, GL1x, etc *really* shouldn't be subclassed, they should probably be declared final for the sake of consistency. But then I've always been a pedantic sod  Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2004-08-01 16:10:16 »

SPGL's AL shouldn't really be subclassed, it's just an anachronism...

Cas Smiley

Offline Orion

Senior Newbie




Java games rock!


« Reply #11 - Posted 2004-08-01 17:57:35 »

Besides, about the buffers. I have a class for textures that (apart from all else) is capable of loading an image from a file. I have a field in this class that is aimed for storing the image information. And it's type is Buffer (superclass for ALL Buffers). It's very convenient to represent data this way, because this Buffer object can be an istance of either ByteBuffer, DoubleBuffer, FloatBuffer, or any other subclass. (as image data tends to be stored in various Java types). In C/C++ you can just have a void* field and it will be capable to store data of any type. But since we use Java, you can't store data in void array. So, what am I talking about? Well, it would be a LOT more convenient to use the Buffer superclass in all methods of LWJGL. Because if I had to use a subclass, I would do the following, which is a very nerve-racking task:

1  
2  
3  
4  
5  
6  
7  
if(someBuffer instanceof ByteBuffer)
   //pass it as a ByteBuffer argument

if(someBuffer instanceof DoubleBuffer)
   //pass it as a DoubleBuffer argument

etc.


But if LWJGL would have support for methods with Buffer only arguments, my code would be a lot shorter. And besides, this is how it's done in JOGL.
So, why don't you check for the buffer type internally? I really hope you consider my advice!
Offline Orion

Senior Newbie




Java games rock!


« Reply #12 - Posted 2004-08-01 17:59:10 »

P.S: if you have problems with private constructors, check Joshua Bloch's "Effective Java" book.
Offline elias

Senior Member





« Reply #13 - Posted 2004-08-01 19:22:18 »

Zeph: The GL* and AL* classes _are_ final! That's what they're meant to be anyway, so tell me if I forgot some (a few are not, like the ARBProgram class which is extended by ARBVertexProgram and ARBFragmentProgram. This is intended, and ARBProgran does indeed have a protected constructor (it has to)).

Orion: We've chosen not to use the instanceof "switch" in handling buffers. And LWJGL needs the specific type, because LWJGL, unlike JOGL, honors remaining() and position() (for which we need the element size of the buffer).

- elias

Offline elias

Senior Member





« Reply #14 - Posted 2004-08-01 19:26:32 »

Oh well, AL isn't final (why could SPGL extend it if it was not). It's fixed now.

- elias

Offline Zeph

Junior Newbie




typical code monkey


« Reply #15 - Posted 2004-08-01 22:12:36 »

well. crisis averted... we now return to our regularly scheduled programming!  Wink
Offline Orion

Senior Newbie




Java games rock!


« Reply #16 - Posted 2004-08-02 05:21:50 »

2 Elias: but what's so wrong with the instanceof operator???
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #17 - Posted 2004-08-02 05:37:49 »

it's farking slow!
besides, it would bloat LWJGL and make it slower for everybody - if you *need* this feature you can easily wrap it yourself.

Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2004-08-02 07:41:25 »

It's a really weird feature to ask for... I can't think of any task that could possibly require it that could not be designed better so that it wasn't needed.

Cas Smiley

Offline Orion

Senior Newbie




Java games rock!


« Reply #19 - Posted 2004-08-02 08:56:19 »

Look. I don't know which data will be stored in my buffer (bytes, floats, doubles). So I'll have to call glTexImage2D for every different Buffer type (6 or more times), which would look like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
// if type == ByteBuffer 
GL11.glTexImage2D(GL11.GL_TEXTURE_2D, 0, txt.getComponentCount(),
txt.getWidth(), txt.getHeight(), 0, fmt, typ, (ByteBuffer)txt.getData());

//if type == FloatBuffer

 GL11.glTexImage2D(GL11.GL_TEXTURE_2D, 0, txt.getComponentCount(),
        txt.getWidth(), txt.getHeight(), 0, fmt,
        typ, (FloatBuffer)txt.getData());

//if type == DoubleBuffer

 GL11.glTexImage2D(GL11.GL_TEXTURE_2D, 0, txt.getComponentCount(),
        txt.getWidth(), txt.getHeight(), 0, fmt,
        typ, (DoubleBuffer)txt.getData());


This is VERY ugly. How can I possibly avoid this?
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2004-08-02 09:47:30 »

By requiring the client to provide a buffer of a known type. It is generally not advisable to provide methods that take a Buffer as a parameter because it could some crazy subclass of Buffer which you haven't anticipated such as CharBuffer or LongBuffer.

At the very least, require a ByteBuffer as your parameters, and then you can turn it directly into a FloatBuffer or IntBuffer or whatever as required. But Buffer as an argument is a very poor choice.

Cas Smiley

Offline Orion

Senior Newbie




Java games rock!


« Reply #21 - Posted 2004-08-02 13:08:12 »

Thanks for the advice! I really appreciate it.
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2004-08-02 14:03:50 »

No worries. Sometimes OOP makes us gnash our teeth for hours or days trying to do something "just because" when the answer is staring us in the face.

Cas Smiley

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.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (103 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
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!