A link for the file, since it’s to big for a post.
http://www.infoway-pi.com.br/LWJGLTextureState.java
Using your file multitexture still works for me. So either there's still some GL13 reference around somewhere, or Apple's driver doesn't correctly implement the ARB extention either.
Or something else, but I wouldn't know anything about it.
If it's a reference for GL13, it has to be outside that class, since I removed all of them from there. I'm still trying, but it seems to me apple's implementation of ARBMultitexture is not correct.
But I agree with Rensanse and think it's really dumb to have this kind of support for this hardware, witch has a OpenGL 1.4 driver comming from the manufaturer itself, Intel.
Well I'm sure multitexturing can work (OSX itself probably uses that).
If you're still willing to sink time into this, I'd try to see if you can get the Nehe tutorial to work on your machine, http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=22
There should be an LWJGL example there, as well as an OSX one. By the looks of it, it uses ARB too.
I'll put my hands on this, I'm really interested into digging everything up.
Llama,
It uses ARB too, yes. But I didn't manage to make it work here yet, because of some issue with lwjgl. It was made to compile over lwjgl 0.94, witch I downloaded and the project still doesn't work. I'll keep on trying.
But I already noticed two things:
1 - They use EXTTextureEnvCombine, instead of ARBTextureEnvCombine, for combine constants. I changed my code to this and yet it didn't work.
2 - I saw a reference to some ARBMultitexture.glMultiTexCoord##ARB(…) methods, witch I didn't see in LWJGLTextureState of jME. Where's the coordinates setting code for glueing the textures to polygons in jME?
Best Regards
Ah yes
GL13 is used for setting the texture coordinates, which explains why this doesn't work for you!
jME doesn't use the exact function you mention, but it points to a buffer. Search for
GL13.glClientActiveTexture(GL13.GL_TEXTURE0 + i);
in LWJGLRenderer.java
My code here (at work) is a bit old, so maybe just search for GL13.GL_TEXTURE0.
It's kinda weird in the version I have actually, we check for the ARB extention, and then we use the GL13 method :P
Thanks a lot Llama, now it works perfectly.
Any chance that you/we can put this changes in the CVS, as a alternative path, for dummy drivers witch do not implement GL13?
Well, apperently for cards that don't have the ARB extention, it didn't work anyway… (because of this check in LWJGLRenderer). So that indicates that practically all cards support the ARB extention too…
Since we don't really have something for alternative rendering paths right now… maybe we should just switch to ARB. Maybe the other devs have a stronger opinion on this…
I guess there's some things to consider… Is it possible that some driver would not support ARB (or support it differently?) Also, is there differences between ARB and 1.3 implementations? Personally, I'd rather look at supporting multiple paths because I doubt this will be the last place this will come up.
Well, since I'm using this macbook as my mobile coding machine for the project I'm developping at the moment, I think I'll probably come up with other issues of a driver that supports only GL12.
I'll let you all know about them and, for the moment, stick to the hacked code.
The solution for the passer by:
Hack the code in LWJGLTextureState.java and LWJGLRenderer.java replacing all references to the GL13 lwjgl class for those found in ARBMultiTexture, ARBTextureEnvCombine etc. Remember to replace ALL the references, of methods and constants. A safe way of doing this is removing the import line of the GL13 class from the import list, making all the references visible as compile errors in Eclipse.
Thanks for all the support guys.
renanse said:
I guess there's some things to consider...
Quick update… I've just locally moved our GL13 usage all back to ARB (one exception is GL_SUBTRACT for combine mode because it doesn't appear to be in lwjgl's ARBTextureEnvCombine, asking them about it.) I've also provided more support for managing supported texturestate features yourself. Among other things, this allows you to turn off multitexturing or other features explicitly to see what this does to your game.
After more testing here, it will go into CVS and hopefully open a new world of multitexturing to those with poor driver support. (Potentially this will also give more people access to your games.)
I'm very thankful for your support guys (everybody, since I've been requesting help in others threads as well).
I'll using my hacked ARG version here, witch is quite stable at the moment. Looking forward to getting your refactoring from CVS when available.
My game project (for programmers), called Tank Battles, has just been aproved for hosting on sourceforge.net. This is a very brief description of it:
Tank Battles is a 3D simulator for teaching robot artificial inteligence. It's
heavilly influenced by Robocode, but differs from the former in that it adds the complexity of a full 3D scene, realistic physics simulation, among other features.
I'll be posting an anouncement on the proper location after finishing the first alpha release, probably next weekend or so.
My best regards.
perick said:
I'm very thankful for your support guys (everybody, since I've been requesting help in others threads as well).
Thank you for helping us tackle this issue, and reporting it in the first place! (and being very persistent in trying to get it fixed)