VSync not working
(10-19-2014, 10:07 AM)zico link Wrote:However the GF8800 which OP mentioned will do the job fine if proper drivers are used (I think NVidia still supports the card in their mainstream drivers).

That depends on how you define "mainstream drivers". Nvidia declared anything pre-fermi as "legacy GPUs" just a few months ago. So the latest driver series supporting these chips will bei 340.xx, The new driver lines 343/344 (which also support the new GM204 maxwell chips of the GTX9xx series) require a GTX400 as a minimium.

However, situation is not really bad, the 340.xx series still will get bugfixes and support, iirc NVIDIA promised to do so until 2019. It is just that those drivers won't see any new features. However, those GPUs are pretty maxed out at D3D10/OpenGL 3.3 anyway, so there is not much of a change at all, in practice.

The situation is much worse on older ATI/AMD and intel chips, except on linux with the open source driver stack from the mesa 3d project. But those also suck.
"Perfection is attained not when there is nothing more to add, but when there is nothing more to remove." -- Antoine de Saint Exupéry
Vsync is working fine for me, no tearing at all. The problem is the jerky motion when Vsync is enabled.

Playing with Vsync off
-The motion is buttery smooth at a solid 200 fps (=5 ms frametime.)
-The visuals are torn to shreads!

Playing with Vsync on @ 60fps (=16 2/3 ms frametime)
-The visuals are solid, no tears whatsoever!
-The motion is stutter-ama galore!

What is causing the stuttering?
I've shown that it takes no more than 5ms (200 fps) for my computer to calculate a frame.
With vsync on it's got a over 3 times that amount of time to calculate a frame (16 2/3 ms.)
So why is there any stutter at all? The stutters do not show up on the fps counter for some reason.

A few other notes:

Turn speed is FPS dependent (probably translation speed as well.)
@ 200 fps you turn a bit faster than at 060 fps.

Also I've tested -maxfps 60 and I don't sense any affect with Vsync off.
Correction: It doesn't work as a command line parameter in the shortcut, but it does work editing the d1x.ini file.
(10-19-2014, 08:29 PM)Hypersonic link Wrote:Vsync is working fine for me, no tearing at all. The problem is the jerky motion when Vsync is enabled.

You might be a victim of the issue described in this thread: http://www.dxx-rebirth.com/frm/index.php...821.0.html.

You can try with the versions I made in this post: http://www.dxx-rebirth.com/frm/index.php...l#msg20745. It will add a new command line option to the game: -syncgl. The usage of this is explained in another post: http://www.dxx-rebirth.com/frm/index.php...l#msg20740.
"Perfection is attained not when there is nothing more to add, but when there is nothing more to remove." -- Antoine de Saint Exupéry
VSync implemented in the driver/hardware will buffer rendered frames and display them in sync with the monitor refresh. The application will not 'see' that not all the frames it produces are actually shown, so it will happily produce 200 fps, while the driver only displays 60 of them each second. You should be able to set VSync (preferably with triple buffering) in the driver and use a max-frame setting in the application.

Edit: It appears rebirth is checking back from the opengl driver what the setting is, but setting maxfps to 90 and enabling opengl triple buffering in the driver seems to produce a nice smooth result without tearing
Computers are just going to get faster and faster. If/when DXX migrates to SDL 2.0 I think this fact should be kept in mind. I noticed Full 3D hardware acceleration listed here https://wiki.libsdl.org/MigrationGuide I wonder if this includes hardware transform?

I think there should be some decoupling.

Should be able to run independently from rendering. One should be able to set physics frametime to a constant, from say 1ms to 20ms. So you can move around silky smooth, while the display shows as many points as it can per second. The constant physics frametime will mean you turn at the same speed regardless of display rate.

pre GPU handoff rendering:
It would be a colossal waste of computing power spitting out rendering frames as fast as the physics frames. While there should be a buffer here, there's no point in making it more than double, as it can be filled almost instantaneously (in relation to display rendering.) The game engine would monitor the frametime the GPU reads from the buffer. The game engine would scale how fast it writes to the buffer relative to this (say the GPU reads from it every 16ms, then the game engine writes to it no more often than half of this = 8ms.)

This is an update to a possible buffering process on this msg

About states on this msg (same topic)
sorry, slightly OT, but since this is the latest vsync problem thread i figured i may as well post it here.

about 59.9 vsync problem...

no program will be able to overcome the 59.9 vsync bug. all (my) games suffer from this.

the only way to fix it is to create a custom resolution using GTF timings insted of AUTOMATIC. that is the only way to get a true 60hz. ive proven this in multiple games already and is easily repeatable time and again.

at 59.9hz the game becomes unsynced (from audio) in less than 1 minute. at (a true) 60hz it can go on for hours and never become unsynced. so there is definately a real bug here and its not DXXR's fault.

[Image: 59bug.png]

dont go chasing this down thru DXXR, itll be a waste of time. framecapping and stuff helps but it still is unsynced.

The thread title I believe is a bit of a misnomer. Vsync works just fine. The problem is the associated stuttering that occurs when it is enabled, something that sub-system decoupling should fix.
the stuttering yes, thats part of the 59.9 bug too. a verticle stuttering to be precise. the stuttering becomes a mouse problem for me, and i can see it stutter during the credits roll once every second.

a simple way to test for this is to play in a lower resolution then native.

i just trying to mention that this problem may actually be bigger then just DXXR.

Well with other games I get smooth motion with vsync on without changing any timings, so I should get a similar experience with this game as well. I just tried darkplaces-sdl.exe and plays smooth with vsync on. As both games use SDL I wouldn't say it's SDL causing it, but I'm not sure which SDL version it is using.

Forum Jump:

Users browsing this thread: 1 Guest(s)