So if my game REQUIRES either PBuffers or FBOs and a system that claims it supports OpenGL 2.1 fails to run it, my game will be disqualified?
hmm, just curious why limit the contest to OpenGL 2.1?, since we’re a niche group and not representative of the general masses, why not just allow up to OpenGL 3.2 and so whoever wants to have some fun with some advanced features can do so.
Just pick a judge with a decent (say 2 to 3 years old) graphics card. I’ve got a 4 year old card and it supports OpenGL 3.3 (as should most DirectX 9 cards).
Besides, stuff like FBO’s and Shaders will allow for much nicer looking games. 
I just want offscreen drawing. It’s probably not a good idea to use pure OpenGL 3+ as you’ll have to write much more code just to get a triangle on the screen.
I’m using immediate mode. I’m just not pushing enough triangles for performance to matter. :persecutioncomplex:
If you’re drawing advanced 3D models, it’s obviously better to use glDraw* methods, but when you have to handle VBOs, VAOs and shader programs and objects just to draw a fullscreen quad, things are getting ridiculous.
Just be aware that the more clever stuff you do like this the less room you’ll have for “game”… I only suggested OpenGL2.1 because the majority of Macs can cope with it. Most of them don’t have OpenGL 3 or better. There are extensions to do a lot of the OpenGL 3 stuff in 2.1 but… you’re probably wasting valuable space thinking of special effects before you’ve even thought of a game.
Cas
ah right, the mac limitation, guess best to stick with opengl 2.x than.
3 days left to submit something!
Another question: lzma.jar is included as part of LWJGL - I think it should probably be on the classpath. Agreed? Some of you clever souls will manage to cram more data in that way.
Hm yes, a huge increase in compression in fact. Putting my current jar through it - 9kb - gets it down to 7kb.
Cas
I’m not sure including lzma.jar on its own will really be of much benefit for the kind of sizes we are talking about, I say this mainly because of the following:
-
You will need extra code to handle the decoding of the lzma compression which would probably negate most of the savings you get.
-
If you are thinking of lzma’ing the whole jar, you’ll probably need a bootstrap jar to extract the thing and then either dynamically add it to the classpath or launch a new jvm, again eating away the savings.
-
The java runtime already has gzip support built in which is equally or almost as good as lzma and the difference is probably insignificant for the sizes we’re talking about.
One option that does come to mind though is if you also allow lwjgl_util_applet.jar (which is why lzma.jar is there in the first place), then you could make a decent saving as it provides all the methods and code needed to extract and load code from lzma files.
Aha! I actually completely forgot that lwjgl_util_applet.jar even existed. I’ll look into it. We might end up having to use it anyway to get around the deployment issues once the first few rounds are over to show the games to a wider audience.
Cas
Quick clarification:
Pack200 will be supported. There will ultimately be some neato way of demoing the games to everyone that probably involves a little downloadable app or applets or whatever but not for a little while - we’ll just keep it simple.
I currently mull over banning the use of AWT classes completely to avoid the temptation to just make a 16K game without using LWJGL at all
Cas