Opengl app for testing

Started by
16 comments, last by Keermalec 19 years, 4 months ago
Dvad, 40 fps is probably nearer the truth, I get 50 fps on a GeForce 256, but 80 fps is not impossible. It also depends if you're looking at the empty sky or at the whole geometry. The sky seams are due to older cards not supporting GL_EXT_CLAMP_TO_EDGE in glParameteri(). Dvad can you try the newer version here and tell me if they disappear (this one uses GL_CLAMP instead of GL_REPEAT).

Terrax, way to go! That is one hell of a computer you got there.

I have a Celeron 2400 with a GeForce FX5600 and I get 236 fps.
Advertisement
I ran the gl_clamp version, the skylines are still there, but not quite as visible. They are less visible than in the GL_Repeat picture that you posted.
Downloaded latest version (world gl_clamp.zip), results:
Time:    3.18s  Frame duration 0.0087s  Framerate: 114.63 fps  Position:  -14.00,    0.90,    4.00Time:   18.98s  Frame duration 0.0075s  Framerate: 132.51 fps  Position:  -21.21,    0.90,    9.44Time:   29.22s  Frame duration 0.0050s  Framerate: 199.64 fps  Position:   -6.23,    0.90,   23.06Time:   71.57s  Frame duration 0.0106s  Framerate:  94.32 fps  Position:    2.92,    1.70,   -0.69


Windows 2000 Professional SP3
Athlon 1600XP
256Mb PC2100
GeForce2 ti200 driver version 56.72
Vsync off

Also, the seams in the skybox were hardly noticable.
--
Cheers,
Darren Clark
Run's fine, CLAMP_TO_EDGE is supported on this GPU, however you say you changed it to GL_CLAMP, still looks good at the corners.

Here's what I got:


Time: 5.83s Frame duration 0.0168s Framerate: 59.38 fps Position: -14.00, 0.90, 4.00
Time: 19.20s Frame duration 0.0167s Framerate: 60.06 fps Position: 9.53, 1.70, 4.18
Time: 27.25s Frame duration 0.0166s Framerate: 60.22 fps Position: 17.43, 0.90, -14.22
Time: 34.23s Frame duration 0.0164s Framerate: 61.05 fps Position: 25.60, 0.90, -23.16
Time: 43.21s Frame duration 0.0166s Framerate: 60.13 fps Position: 29.50, 0.90, -25.12
Time: 65.23s Frame duration 0.0166s Framerate: 60.18 fps Position: 44.01, 0.90, -34.90
Time: 71.88s Frame duration 0.0166s Framerate: 60.21 fps Position: 41.83, 0.90, -20.25
Time: 84.38s Frame duration 0.0170s Framerate: 58.75 fps Position: 25.17, 0.90, 1.08
Time: 94.01s Frame duration 0.0166s Framerate: 60.29 fps Position: 14.51, 1.70, 5.53

O/S: Win2K PRO
CPU: P4 2.4 GHTZ
RAM: 1024M
GPU: GeForce4 Ti-4600.
vsync: on
Comserv, CLAMP_TO_EDGE is used by the programme if it is supported, otherwise it switches to GL_CLAMP, as some older cards have an incorrect implementation of GL_CLAMP which works like CLAMP_TO_EDGE.

The correct implementation of CL_CLAMP, so I hear, is to average the edge pixels with the colour of the background, thereby creating a dark border around each of the skybox's faces, which shows up as dark seams on the skybox. I have no solution for cards like DVAD's which have a correct implementation of GL_CLAMP but no CLAMP_TO_EDGE support.

Too bad your vsync is on, your fps is limited to your screen refresh rate, which is 60 fps.
The view drifts slowly up and to the left.

With VSync on, I can control the view with the mouse. It is hard to explain what happens but it is plain horrible. I have to move the mouse real slowly (even then it is jerky) or else it seems to decide to turn at some predetermined rate and then suddenly stop. This rate seems to depend on how fast I move the mouse.

With VSync off, the mouse hardly has any effect at all - I have to constantly move the mouse down and to the right (over and over continuously) to counter the drift.

The arrow keys work properly.

Framerate: 1139 fps

P4 3.0Ghz
6800GT 256Meg
WinXP SP2
Time: 2.10s Frame duration 0.0050s Framerate: 199.76 fps Position: -12.66, 0.90, 3.03
Time: 2.88s Frame duration 0.0050s Framerate: 199.29 fps Position: -10.34, 0.90, 0.67
Time: 3.65s Frame duration 0.0054s Framerate: 186.32 fps Position: -8.05, 0.90, -1.68
Time: 4.51s Frame duration 0.0056s Framerate: 177.14 fps Position: -5.50, 0.90, -4.31
Time: 5.40s Frame duration 0.0056s Framerate: 178.27 fps Position: -2.89, 0.90, -7.00
Time: 6.18s Frame duration 0.0054s Framerate: 186.69 fps Position: -0.55, 0.90, -7.83
Time: 6.98s Frame duration 0.0050s Framerate: 199.13 fps Position: 1.85, 0.90, -7.89
Time: 7.91s Frame duration 0.0051s Framerate: 194.73 fps Position: 4.62, 0.90, -7.95
Time: 8.86s Frame duration 0.0049s Framerate: 204.81 fps Position: 7.47, 0.90, -8.03
Time: 9.76s Frame duration 0.0047s Framerate: 213.82 fps Position: 10.19, 0.90, -8.12

Windows XP SP 2
Pentium 4 3.0 GHz 800 MHz FSB
1024 Kingston Hyper-X PC3200 RAM
Radeon 9600 XT 128 Meg / 128 Bit

Also, mouse movements don't seem to work very for me. I do have a Microsoft wireless mouse (and keyboard), but signal strength is not the issue. It's at the point where I have to practically move my mouse sideways across my entire desk to get a <10 degree rotation.
Hm, the sucky camera movement at high framerates is because I read in mouse movement with getCursorPos. Therefore when the movement per frame is less than 1 pixel, you get zero angle turn, hence the slowness at high framerates.

Can't think of an easy way around this. Anyone know of a function that reads in mouse movement apart from getCursorPos()?

This topic is closed to new replies.

Advertisement