LWJGL Forum

We've released prerelease 2 of LWJGL 0.7. We're basically done for 0.7, but want to make sure everything is fine for the 0.7 release...

head on over to //www.lwjgl.org to get the goods!

I couldn't get WinCVS to produce a changelog, so this will have to wait.

Please report ANY anomalities!

Converting my stuff now.

Issues/comments:[list=a]

• Do you have a 0.7 Quickstart Guide, just to ease the pain?  Or just a few lines to give us a starting point?
  
• I know we need to flip our buffers now - but when and how do we do that?
  
• Window.create() etc throw Exception!  Yuk! :wink:
  
• Buffer overflow possible in state queries:  glGetFloat(pname, buffer) converts to library call of glGetFloatv(pname, buffer + buffer.position()) - no check whether buffer is large enough to hold queried data.
  [/list:o]
  
  Resolved:[list=a]
• My textures aren't appearing - I suspect an odd effect caused by the new way of handling buffers.  I'll see what I need to change. (Resolution - flip the pixel buffer after reading pixel data from file.)
  
• The mouse appears to be vertically flipped (again)? (Resolution - get over it and stop whinging! :roll:)
  
• glGenTextures - This doesn't take a number of textures to generate any more - how does this get calculated? (Resolution - appears to "just work"?)
  
• glGetFloatv - Now called glGetFloat.  I thought Cas said there'd be a version that returned a single integer, for those times when you really don't want to bother creating a one element buffer just to return a single int? (Resolution - use your own query layer)
  [/list:o]
  
  Edit: Adding and removing issues as I come up with them!

i have all of my stuff working... used the loadTextures() method in the Nehe07 port that you can get off of sourceforge...

but the textures are flickering (or i guess some of the triangles are coming in and out).... this didnt happen with 0.6.  in the new Nehe07 port the loadTexture() returns a int [] instead of an int and the render then uses a filter to pick the value to use as the address of the texture.  i have tried rotating the filter in the array and it is always choppy...  

does anyone have any ideas as to why this might be happening?

thanks

Being A Guide To Porting Code From Pre-0.7 To Pre2-0.7

[list=1]

• The GL class is now abstract and is not instantiated.  Call Window.create(...) instead, with the same arguments you used to call the GL constructor with.
  
  
• Call Window.destroy() instead of GL.destroy().
  
  
• The "maintenance" methods of GL are now part of Window - isMinimised(), isCloseRequested() etc.
  
  
• The gl.tick() method no longer exists.  It has been replaced with Window.update() - call this whenever you would have called tick() before.
  
  
• DisplayMode selection - no change.
  
  
• GLU code - no change; the GLU is still included as of this release.
  
  
• glColor*v - the array versions of many methods no longer exist.  Call the corresponding multiple-argument method.  E.g. glColor3fv(myColor) becomes glColor3f(myColor[0], myColor[1], myColor[2]).
  
  
• glGenTextures - this method no longer takes an argument describing the number of texture names to generate.  If your buffer was created immediately before being used, this method "just works".  If you've been playing with it, or it's larger than the number of texture names to generate, you may need to manually set buffer.position(0).limit(n), where n is the number of names to generate.  An alternative may be buffer.position(n).flip().  (TBC)
  
  
• Mouse/Keyboard input - no change.
  [/list:o]
  
  That's all I've noticed so far.  Please post any additions or corrections.

cfmdobbie, thanks a lot!! - I'll more or less be copying this text to the 0.7 readme!

I was *very* tired last night, which is why I forgot one REALLY important bit!

Methods passed a buffer, now use position and limits to calculate the number argument. so in glGenTextures you just do a buffer.position(0).limit(1); to create 1 texture.

But this comes at a small price, back in ye old days, when the address of the buffer was passed, it was always passed as the base address. Now you HAVE to make sure that the buffer has had it's position set to the begining of the buffer. This usually involves a buffer.flip() or buffer.rewind()

One small fluke I forgot to mention:
EAX has been disabled in this release, I am working on an update which will make it easier to use - stay tuned.

now, responses:
a) working on a quickstart guide, will be ready for full 0.7 - it will be a set of simple lessons for using LWJGL - NOT OpenGL or OpenAL.
b) always when you pass it to a method. I don't think I've seen a case where I haven't done it
c) yeah, we'll fix that to a proper kind of exception - adding to todo
d) yup, we'll look into that... but it's just that this has ALWAYS been possible - the only way to fix it, is to have a huge Look up table, and assert against the sizes in it.

loadTextures from NeHe comes in two variants - one that returns 1 int and one that returns an array - I just ported chman's nehes... I don't know why it's done like that - simplicity I guess.

need to go to work now - will be following this thread, and posting as needed when I get a chance

thanks for the reponses... i will play around with my textures some more tomorrow... i am sure it is just something i am doing wrong in my code... maybe i should move away from bitmaps and use gifs or jpgs that java is more familiar with :)

i'm looking forward to the 0.7 quickstart on lwjgl... should be very interesting.

btw - thanks for the porting guide cfmdobbie

Quote from: "Matzon"loadTextures from NeHe comes in two variants - one that returns 1 int and one that returns an array - I just ported chman's nehes... I don't know why it's done like that - simplicity I guess.

well, i have rewritten my code to load the textures and pass only one int as the address back and i am still getting the choppy triangles... i mean it looks good for the most part, but you can definitely tell that something is going wrong...

if anyone wants to try to find the bug i have been missing, here is the code for the texture loading... i am happy to share the rest of my code as well, but dont want to bog down the message board unless someone wants to see it...



   private final static int loadTexture(String file) throws Exception {
       Image image = null;
       image = BitmapImage.loadImage(new FileInputStream(file), file);

       // Exctract the image
       BufferedImage textureImage = new BufferedImage(image.getWidth(null), image.getHeight(null), BufferedImage.TYPE_3BYTE_BGR);
       Graphics2D textureGraphics = (Graphics2D) textureImage.getGraphics();
       textureGraphics.drawImage(image, null, null);
       textureGraphics.dispose();

       // Put the image in memory
       ByteBuffer scratch = ByteBuffer.allocateDirect(4 * textureImage.getWidth() * textureImage.getHeight());

       byte data[] = (byte[]) textureImage.getRaster().getDataElements(0, 0, textureImage.getWidth(), textureImage.getHeight(), null);
       scratch.clear();
       scratch.put(data);

       // Create an IntBuffer for the image address in memory
       IntBuffer buffer = ByteBuffer.allocateDirect(4).order(ByteOrder.nativeOrder()).asIntBuffer();

       // Create the texture in OpenGL
       GL.glGenTextures(buffer);

       // Typical Texture Generation Using Data From The Image
       GL.glBindTexture(GL.GL_TEXTURE_2D, buffer.get(0));

       // Linear filtering
       GL.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR);

       // Linear filtering
       GL.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR);

       // Generate the texture
       scratch.flip();
       GL.glTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGB, textureImage.getWidth(), textureImage.getHeight(), 0, GL.GL_RGB, GL.GL_UNSIGNED_BYTE, scratch);

       // Return Image Address In Memory
       return buffer.get(0);
   }





btw:  this code will load a milkshape3d ascii model into simple java objects... there is a model that has a simple draw method that renders to lwjgl... i havent been able to find any code that does this, which is why i am writing it... there was a chman port that i found, but it did not support animations, or i coundnt find any support for them... if someone knows about a piece of code that supports milkshape animations in lwjgl i would be happy to use it, otherwise i will keep on working on this and make it available for anyone that wants it...

thanks

(Newbie alert! ;) ) Maybe it's that you're missing a order(ByteOrder.nativeOrder()) on the following line:

ByteBuffer scratch = ByteBuffer.allocateDirect(4 * textureImage.getWidth() * textureImage.getHeight());

Or is that just a requirement for other primitives (int, float etc)?

Hi,

I Updated my RenderTotexture Demo using the newest Release avaible at LWJGL.org

But i got a Exception :

java.lang.UnsatisfiedLinkError: nGetNULLValue

at org.lwjgl.Sys.nGetNULLValue(Native Method)

at org.lwjgl.Sys.<clinit>(Sys.java:105)

at org.lwjgl.Display.<clinit>(Display.java:81)

at rendertotexture.ConfigFrame.createDisplayModes(ConfigFrame.java:276)

at rendertotexture.ConfigFrame.<init>(ConfigFrame.java:64)

at rendertotexture.ConfigFrame.main(ConfigFrame.java:78)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.sun.javaws.Launcher.executeApplication(Unknown Source)

at com.sun.javaws.Launcher.executeMainClass(Unknown Source)

at com.sun.javaws.Launcher.continueLaunch(Unknown Source)

at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)

at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)

at com.sun.javaws.Launcher.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

You can Launch the Example via Wevbstart via :

http://www.mac-systems.de/rendetottexture.html

Just Click the Blue Button. (actual Windows only)

- Jens

java.lang.UnsatisfiedLinkError: nGetNULLValue
some kind of versiuon mixup - make sure you have correct version of everything... nGetNULLValue has been removed - so probably some old class files that need to be recompiled...

Quote from: "AndersD"(Newbie alert! ;) ) Maybe it's that you're missing a order(ByteOrder.nativeOrder()) on the following line:

ByteBuffer scratch = ByteBuffer.allocateDirect(4 * textureImage.getWidth() * textureImage.getHeight());

Or is that just a requirement for other primitives (int, float etc)?

thanks for the catch... still didnt fix my missing triangles :( ... i need to take a closer look to what i ported from 0.6 to 0.7 i guess

Just for everyone's information: Alien Flux is now running perfectly under the current CVS build of LWJGL 0.7pre2 so it's looking like it's perfectly stable, and we can expect a proper release at the weekend.

Cas :)

Quote from: "princec"Just for everyone's information: Alien Flux is now running perfectly under the current CVS build of LWJGL 0.7pre2 so it's looking like it's perfectly stable, and we can expect a proper release at the weekend.

Cas :)

great news! makes me feel that much better that my problems are coming from my code and not from the libraries :D

FYI: i fixed my problem with my flickering triangles.

i was using the example Window.create() method as seen below...

Window.create("window", 50, 50, 640, 480, 16, 0, 8, 0);

but i am using 24bbp bitmaps for textures and the min depth buffer and bpp had to be set to 24 (duh) as follows...

Window.create("window", 50, 50, 640, 480, 24, 0, 24, 0);

i guess for some reason my old code that used lwjgl 0.6 was initializing differently (24 by default)

thanks again for all of you help :D

I advise you to use 16 bit depth buffers for better portability. You will probably get a 24 bit one anyway, but nevertheless...

<edit>Oh, and I also advise asking for 16 BPP as well. Again, it'll give you more if it can.

Cas :)

So what you're saying is hardcode the 16 and if higher resolutions are available, it'll get set to that automagically?  :shock: <-- that sums up my current look

What you're actually doing when you're specifying those parameters is saying the minimum you'll be happy with. Therefore you should aways set them to the minimum you'll be happy with :) It's then up to the drivers to come up with the best possible match.

One thing you can do is try to create an optimised Window with 32 bit this-and-that and catch the Exception when it fails and try to create one with the minimum requirements.

Cas :)

i get choppy triangles with any depth buffer minimum set less than 24... do you think this is because i am using bitmaps rather than something like a gif or a jpeg for my textures?  or could it be a problem with my hardware using 16 bpp depth buffers(i am running an nvidia geforce4 card, but it is in a laptop)?

thanks

Your problem is that you've set your viewing frustum with a far greater range than 16-bit precision can allow accurately enough not to have visual artifacts - this caught me out a few years ago when I did that terrain demo.

Try setting near to 100 and far to 20000 or something like that, and make sure it's fogged out by 20000 or things will just pop into existence.

Cas :)

Quote from: "princec"Try setting near to 100 and far to 20000 or something like that, and make sure it's fogged out by 20000 or things will just pop into existence.
Cas :)

thanks... that worked great!  i need to brush up on my opengl - its been a long time.

i can now set my depth buffer back down to 8bpp and it works perfectly!

thanks again!  :D

After porting ~50.000 lines of code (Yeah! We are progressing really well!  :D) to pre2 0.7, I have some things to note:

A) I really liked the way buffer.position is used now. It saves a lot of slices, although it requires you to be careful with flips and stuff.

B) I really liked the way some functions were modified to accept different types of Buffers, thus not requiring you to specify the type explicitly. Very Java-styled. But I think you missed quite a few others that could be handled that way. A couple examples:

glMultMatrix
glGet (glGetInteger(int param, IntBuffer buffer) => glGet(int param, IntBuffer buffer)

C) glTexImage2D and glTexSubImage2D should also take a FloatBuffer as pixel sources. Has some usages with dynamically generated textures. Also, glMultMatrixd is missing.

D) The VBO case was handled quite elegantly. Liked that too.

(Still getting used to the new buffer position stuff!)

I would guess glGetInteger et al are like that because there are other get methods that accept the same arguments, like glGetPixelMap(int, IntBuffer).  If there were a glGet(int, IntBuffer), you can guarantee people would try to glGet(GL_PIXEL_MAP_R_TO_R, intBuf) with it.  (But hey, maybe they should be able to?)

glMultMatrixd: Most of the double producing and consuming methods have been culled, for performance reasons.  Can you use glMultMatrixf instead?  (Or "glMultMatrix" as it should be called!)

QuoteCan you use glMultMatrixf instead? (Or "glMultMatrix" as it should be called!)

That's what I did. I just converted the buffer from Double to Float. I used it only one time, anyway. But why was it culled? It makes sense to remove the color*v functions, but why this one? Higher precision is sometimes needed in matrix operations (e.g. projection matrices). I'd like it back in LWJGL, since it doesn't have any "hidden" performance implications, like color*v. If you want higher precision, you should be able to have it. What do you guys think?

No current 3d hardware uses double precision internally anyway, so why bother keeping the *d methods? I'm also a little curious as to why glTexImage2D needs to take floatbuffers. What did you mean?

- elias

glTexImage2D (and TexSubImage2D) can be used with GL_FLOAT as pixel data type. That's why they need to take a FloatBuffer. You can still do it with a ByteBuffer (that holds floats), but doing it with a FloatBuffer would be cleaner.

OT: Is it possible to add query methods to Keyboard, that would return the state of Caps and Num Lock? I'm asking because I have troubles with the current Keyboard translation (especially with languages other than English) and I want to implement my own, but not knowing the Caps and Num state is the only thing missing to do it correctly.

also OT
public static final int KEY_CAPITAL = 0x3A;
public static final int KEY_NUMLOCK = 0x45;

should do ?

There, FloatBuffer method versions added.

- elias

Didn't realise you could use floating point textures :)
What kinds of groovy uses might I put them to I wonder...

Cas :)

Quotepublic static final int KEY_CAPITAL = 0x3A;
public static final int KEY_NUMLOCK = 0x45;

should do ?

I know I can track their state AFTER I'm in the game, but what if Caps Lock was ON BEFORE running it? That would mess it up. At least I'd need to know their initial state.

Quote from: "princec"Didn't realise you could use floating point textures :)
What kinds of groovy uses might I put them to I wonder...

:) Helpfull, indeed. I use them to dynamically generate the minimap texture. I do all the lighting calculations (based on sun's position, terrain geometry and texture colors) using floats, and by using a float texture, I don't have to convert float->(unsigned)byte. The card converts for me  8).

Heh. I reckon you'll find it does it on the CPU before it gets to the card :) But still, nice to know it's got a use.

Cas :)

Quote from: "princec"Heh. I reckon you'll find it does it on the CPU before it gets to the card :)

I hope not, but even if it does it on the CPU, it would be much faster than doing it in Java. Anyway, do you know where I can find some info on this? Just to be certain.

ATI_separate_stencil is missing... :lol:

Knowing the Keyboard CAPS LOCK state etc. sounds like you're working around what could be a LWJGL translation bug. Can you give more specific detail as to what is broken in the translation?

- elias

Well, as functionality is concerned, the numeric keypad keys don't translate to any characters, whether num lock is on or off.

As with bugs...I haven't managed to isolate it yet. There's some strange behavior going on, but only some times. I guess it may have something to do with other applications I'm running (I'm on WinXP by the way). I don't know. But here is an example of what happens when I encounter the bug:

Normally if you press and hold Shift, press and release A, then release Shift, you should get the following events:

Shift (pressed)
A (pressed)
A (released)
Shift (released)

Without translation enabled, it always does it right. But sometimes, with translation enabled, I get the following (with the same presses/releases):

Shift (pressed)
A (pressed)
Shift (released) <- Wrong
A (released)
Shift (pressed) <- Wrong
Shift (released)

I hope this helps...

I'm planning support of greek language input in my TextFields, that will require a map of Keyboard.KEYs to characters anyway. That's why I'm asking for that functionality. I'm just wondering, is it difficult to implement? If it isn't, I think it would be a nice addition to the API.

I looked through the code and couldn't find anything suspicious :/ It would really help if you tracked it down to something reproducible... Anyway, why can't win32 do the greece translation for you?

- elias

Quote from: "elias"
Anyway, why can't win32 do the greece translation for you?

It could, but it's ugly and I don't trust it.

Ugly, because it returns some odd char values > 256, which still have to be translated to something 0-256 (or 0-128), to look-up characters in my font textures.

Moreover, I'm not sure if machines with different character sets (or whatever they're called), or lack of the appropriate ones, would return the same values for each key. Can I be sure that win32 returns the same values as linux? Or that the user's machine is properly configured and supports languages other than english? That's why I don't trust it. I've seen a lot of problems concerning greek language support, all these years.

I have to be sure everything works as expected, and that's why I want to do it myself.

Anyway, I'm asking for such a little thing...  :roll:

Also, by doing it myself, a user will be able to see and type greek text, even if there's no support for it by the OS. Don't you think that's a big advantage?

Weird chars? Aren't they just unicode? Anyway, it's not much you ask for for, but it is still a work around of an existing feature, and I don't like to have two different methods of doing the same thing instead of fixing the existing one (or replacing it).

Anyway, X Windows cannot give you the LED status in a portable way.

- elias

My font code works fine with Unicode, and even renders Hebrew. All the support is built in to Java if you want to use it. However it's sad to say that this stuff really isn't meant to be in the LWJGL library. We provide a very raw interface to the hardware and very little else. And on the face of things, it's probably very noble to spend a lot of time writing a game that you can type your name in Greek on the hiscore table but it's also probably a total, utter waste of time from a business perspective in terms of cost-benefit.

Despite using plain ol' English in Alien Flux, which would imply that the UK would be represented a little better, Alien Flux's current purchase statistics show that nearly 90% of the customers are Americans or Canadians, even though only 40% of the site visitors are from there. It follows that this is likely to be the case for other games, give or take. The Greek market is almost certainly going to be <1% of your customer base.

Lowest common denominators. Don't you just love them? That's why we're still stuck with 8.3 names here and there. Criminy.

Cas :)

Yes, but Spasi is Greek (or at the very least works there).  Just because the Internet gives you a global market doesn't stop there being a local market for software.  And if you're in Greece and know Greek people, I expect the market will be much more than 1% Greek. :?

When we started designing the whole thing we agreed to support two languages at least, english of course and greek. And I'm not talking text only, but speech too. I know the greek market will be only a small percent, but given the fact what we are doing has never been done in Greece before, the enthusiasm of a greek game will be enormous.

cfmdobbie is right. We've seen a couple of pathetic games make considerable sales, just because they were done here. We don't want to miss that  :wink:

Anyway, I guess I'll have to improve my font code.

We're also doing this for publicity and recognition. History and language is a sensitive subject in Greece (isn't it everywhere?), so having a greek company ship a game about ancient Greece in English wouldn't look good.

even so I'm not completely sure why you're having problems.
Do Greek chars work in Alien Flux on the hiscore table?

Cas :)

Quote from: "princec"
Do Greek chars work in Alien Flux on the hiscore table?

Yes, they do! How did you do that  :shock: ? Does Alien Flux come with greek characters in its textures? Or do you build them at runtime (from what you've said before, I don't think so)? They look fine, except accented characters don't work. I don't know if "accent" is the right word, you know, I mean the "dots" over vowels we put in words. Just like the one on 'i'. Oh, for some strange reason it only works for 'e', that is, an 'e' with a "dot" on it.

Quote from: "princec"
even so I'm not completely sure why you're having problems.

Well, I haven't had any problems yet, only thought about the problem, I was going to implement it later. From my first thoughts, I found that it would be easier to map a Keyboard.KEY to an offset in my textures, but it all came down to the Caps lock problem. It's still doable, except for that. Anyway, I'll have to do it another way now. That is, a map of char values to offsets. This is what you're doing in Flux, right?

By the way, from my tests, the lwjgl translation works right for greek accented characters. It returns the correct unicode, so no worries there.

I mentioned in this topic that the ATI_separate_stencil extension is missing from lwjgl and I didn't get any responce and I haven't seen it in sourceforge yet. Is it getting in?

I suppose it will be! We'd better add it. And yes, we support all the Unicode characters in the Impact fonts. We don't support right-to-left typing or ligaturization though, as that requires AWT code. I'd quite like to get my hands on some pure Java ligaturization/text formatting code to handle this.

Cas :)

I'm on the motherf*cker...

- elias

LOL! Ok, Elias had better add it, poor overworked student that he is!  :twisted:

Cas :)

I'm not quite sure just how I should feel mocked.


Anyway, the extension is added.

- elias

Thank you guys. Keep it up elias!  :lol: