i'm adding support for OpenGL via LWJGL to http://www.jpct.net right now. If you have LWJGL 0.4 installed, i would be very happy if you would download http://www.jpct.net/download/opengltest.zip and tell me if it runs at all and if it looks somehow like http://www.jpct.net/pics/opengltest.jpg. My problem is, that i do own three machines but all of them have Geforce cards in them...so i'm not sure if it runs on other hardware.BTW: the test application opens a 640*480*32 window on the desktop to do the rendering. So your desktop has to be set to 32bit for it to work.

Edit: I does require a card that supports 32bit textures...at least i think it does...i can't test it....

Edit 2: I've uploaded a new version that can be run in software mode too (for comparision or just for fun). Use the batchfile "*_software.bat" for windows or add the parameter "software" to your call to start in software mode.

Hmmm...i just copied all lwjgl-stuff into the lib/ext directory in my Java-dir and it works this way on every system i tried.Try to "unjar" terraingl.jar and start TerrainGL.class directly. Maybe that helps.

I read that using the -jar switch make java ignore the CLASSPATH env and -cp/-classpath switches. I think you need to add Class-Path attribute to the jar's MANEFST file for the jar to pick up other jars in the same directory.

Linux 1.3GHz Athlon, GeForce2, 177-188fps.Great job! jPCT was the best software only 3D API I could find for Java. I like the fact that it comes with MD2 and 3DS model loaders. Now with hardware accel I think it's the easiest way for someone to make a fast 3D game.

I doubt that your Cel. ist the problem. The problem is most likely your G400. Try something different or at least to update the drivers for it. A Cel. 500 has to be much faster than that. Look at the post above where Matzon got 43fps on a Cel. 550 with GF2MX.

If that's possible without too much effort, i would really appreciate it. The more the better

Passed. hardware: 110-119 FPSsoftware: 13-17 FPSThat was on a PIII 1.1GHZ, with a radeon 7500 (mobility M6) on a compaq presario 2700.

Two things to say:- Nice results for the hardware modes..- PIV sucks. My other laptop has twice (!!!) the frequency, next (de)generation processor, faster memory, better graphic board, better chipset, and it is not able to at least make 100% better than PIII. lame. Moreover it heats like an oven. i hate my PIV..

Then i suggest to try another OpenGL application that runs in a window and see how it runs. Either your graphics card/driver has a problem with doing OpenGL in a window (or doing OpenGL at all) or something with your setup is wrong. Your performance in OpenGL mode is much too low. The 6-7 fps in software mode sound realistic though.

Or it might be a problem with lwjgl - on windows, lwjgl apps should be able to swiych color depths on the fly, afaik. So why does it matter that the desktop is in 16 bit mode? And what is the difference between 24 and 32 bit desktop depth?

EDIT: I have seen that selecting a weird mode drops the app back to standard software opengl. We really should implement real queries of available pixel formats. Like on linux . Cas is on it, but I think he is way too busy atm.

It's a "feature" not a "bug"... under Windows you can do OpenGL in nearly any mode because it gives you a software driver if you ask for something the hardware doesn't understand - which is perfectly legal - but feckin useless because their driver is so awfully slow. (How fast is Mesa5.0? Anyone tried it?)

There is an obscure ARB extension for getting available hardware pixel formats but it's not widely supported.

The only thing you can do is check for the telltale Windows software driver name with glGetString(GL_VENDOR) (I think) and exit if you get Micro$oft in there somewhere.

It shows you just how slow M$'s default OpenGL implementation is as well doesn't it?

BTW, it's usually best to ask for 16-bit colour to ensure the app runs on a wider variety of hardware.

All this trouble getting a valid mode makes me think lwjgl should include a more robust way of selecting a display mode. If we can't always be sure of the available modes, why not do like spgl does per default? That is, instead of querying modes with Display.getAvailableModes(), use a Display.switchToBestMode(...), that select the best matching mode from the application specified min/max limits on depths, window size etc.?

That way, lwjgl more closely matches the behaviour of ChoosePixelFormat/glXChoosePixelFormat (and probably also that of the mac equivalent).

EDIT: ... and I don't think game developers are overly concerned about the _exact_ properties of the mode they get, as long as it meets certain requirements. Or more specificly, the exact pixelformat might not matter - window sizes should match the required size, IMHO.

- PIV sucks. My other laptop has twice (!!!) the frequency, next (de)generation processor, faster memory, better graphic board, better chipset, and it is not able to at least make 100% better than PIII. lame. Moreover it heats like an oven. i hate my PIV..

silly question, but...Was the p4 was connected to the mains when you tested it? (cos they clockdown to conserve battery)

That's the fps-display-window. The LWJGL windows is shown in your taskbar but obviously not visible. I have this problem on one of my machines too, if i focus anything before the LWJGL windows comes up...it's there in the taskbar and the application seems to run, but nothing is visible...don't knwo how to get rid of this but to use fullscreen instead (my test application won't let you do so though).

silly question, but...Was the p4 was connected to the mains when you tested it? (cos they clockdown to conserve battery)

Yes, certainly. Both laptops were running at full frequency.Nevertheless, while the difference in frequency and new stuff did not change speed as expected, some of my tests (including inlining) showed that things changed for bandwidth and that some optimisations on my side for reducing its use were not useful anymore. Good point there.

Yep, win32 lwjgl windows are not state-of-the-art yet, unfortunately. One of the reasons is that not all of us wants windowed mode to be implemented as anything else than debug windows. I hope we can iron out the remaining bugs in the boring stuff like focus, alt+tab'ing etc in time for 1.0.

Then i suggest to try another OpenGL application that runs in a window and see how it runs. Either your graphics card/driver has a problem with doing OpenGL in a window (or doing OpenGL at all) or something with your setup is wrong. Your performance in OpenGL mode is much too low. The 6-7 fps in software mode sound realistic though.

Ok, I will do this test only if I had a such OpenGLled test program. I don't have any games in this machine and does not know any freely avail games with OpenGL support. If any1 could link here a native OpenGL test program, I could benchmark fps.

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