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 :D. 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.
Cas 
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.
all I get is a tiddy little window ???
http://www.pkl.net/~rsc/downloads/tiddybox.png
software works fine though - 19-20fps ish
athlon1.33 256mb ddr, gf2gts 32mb
strange - cos other LWJGL stuff works just fine.
silly question, but…
Was the p4 was connected to the mains when you tested it? (cos they clockdown to conserve battery)
[quote]all I get is a tiddy little window ???
[/quote]
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).
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.
[quote]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.
[/quote]
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.
http://www.tuxracer.com/ has a free demo for win32 too and runs opengl. I don’t know if it can run in a window though.
Environment:
Win2k/256MB
Chip type: Matrox Millennium G400
DAC type: integrated 300Mhz
Memory size: 16MB
Adapter string: Matrox Millennium G400 AGP
Bios Information: v2.1.035
Driver version: 5.82.18.0
Lol, I got 1fps running this program. My comp can’t do OpenGL. This is an integrated G400 with 16MB ram, so it’s not a state of the art.
Your java program most likely works properly, it’s just my machine cannot do anything with it.
It’s capable of running Quake3 so it should be capable of running anything else. Back to the drawing board to select a valid display mode then
Cas 
The “ProjectedTextures.exe” works fine in 16-bit and 32-bit mode, very slow in 24-bit. And I get the same problem as whome with TerrainGL (not running in 16-bit and 32-bit, running a slow as possible on 24-bit)
Intresting? Didn’t think so
/M
[quote]The “ProjectedTextures.exe” works fine in 16-bit and 32-bit mode, very slow in 24-bit. And I get the same problem as whome with TerrainGL (not running in 16-bit and 32-bit, running a slow as possible on 24-bit)
[/quote]
Ah, i guess it’s a problem with 24bit then…good to know…
I run a java and native demo in the following computer, here is the results:
256MB, PentiumIII 860Mhz, NVidia Riva TNT2 Model 64, 16MB
Bios Information: 2.05.1903, Driver date: 30.9.1999
ProjectedTextures.exe
same results for 16bit and 32bit, no 24bit available.
-> 2 FPS
terraingl.jar (without software parameter)
color mode 16bit -> error: requires greater colour depth
color mode 32bit -> 7 FPS
terraingl.jar (with software parameter)
color mode 16bit -> 13 FPS, interestingly it works this time.
color mode 32bit -> 13 FPS
Here is .bat files I use to launch java demo.
[RunDemo.bat]
set cp=terraingl.jar
set lwjgl=…\lwjgl-0.4\lwjgl.jar
set lwjgl_dll=…\lwjgl-0.4
c:\j2sdk1.4.1_01\bin\java -Djava.library.path=%lwjgl_dll% -cp %cp%;%lwjgl% TerrainGL
[RunDemoWithSofware.bat]
set cp=terraingl.jar
set lwjgl=…\lwjgl-0.4\lwjgl.jar
set lwjgl_dll=…\lwjgl-0.4
c:\j2sdk1.4.1_01\bin\java -Djava.library.path=%lwjgl_dll% -cp %cp%;%lwjgl% TerrainGL software
Just post here an updated test programs if you want us to run it.
[quote]Just post here an updated test programs if you want us to run it.
[/quote]
Ok, i made a new jar. Just replace the jar from the old opengltest.zip with this one.
http://www.jpct.net/download/terraingl.jar
The new version start in 640*480 windowed with 16bit for color, zbuffer and textures. To change that, four new parameters exist:
color32 - start in 32bit color mode
texture32 - use 32bit textures
zbuffer32 - use a 32bit depthbuffer
fullscreen - go fullscreen
Maybe this helps to find the problem. Your TNT2-M64 results are strange…that card isn’t that great but not that(!) bad either…
I’ve posted results to my webpage 'cause it’s so long text. One thing to say, things are looking good now
Tomorrow I can run it on Pentium III 800Mhz.
Please, verify my fullscreen problem described in a document. Anything to be done for it?
http://koti.mbnet.fi/akini/java/misc/terraingl.html
http://koti.mbnet.fi/akini/java/misc/terraingl.html
[quote]I’ve posted results to my webpage 'cause it’s so long text. One thing to say, things are looking good now
Tomorrow I can run it on Pentium III 800Mhz.
Please, verify my fullscreen problem described in a document. Anything to be done for it?
http://koti.mbnet.fi/akini/java/misc/terraingl.html
http://koti.mbnet.fi/akini/java/misc/terraingl.html
[/quote]
Thank you very much for your affords. I really appreciate it. The zbuffer32 switch is stupid as i’v e discovered on my own hardware (GF4)…24 would do, but 32 always fails…anyway, the fullscreen thing is something i’m aware of and i should have warned you (sorry). Actually, i was unsure to add it at all…problem is, that i’m closing the app by using a WindowEvent and there is no pure Java-window in fullscreen (at least you can’t see it)…i haven’t implemented a LWJGL conform way of capturing at least a key pressed (like ESC) to close the window…i was too lazy. The whole application is a quick and dirty conversion from a “software rendering only applet” i wrote some time ago. That’s the reason why it lags such stuff. Sorry again and thank you for trying.
Ok, good to know I could help you somehow. Are you planning to publish a sourcecode somewhere later?
I know, that 3d stuff is out of my league atm but I could try learning it a bit by bit.