If this mode could be added woud it be useful or is the difference between 24hz and 30hz not big enough? Most console games aim for 30fps except a few that runs at 60hz. 30fps is actually fairly smooth.
Best wishes
Ulf
If this mode could be added woud it be useful or is the difference between 24hz and 30hz not big enough? Most console games aim for 30fps except a few that runs at 60hz. 30fps is actually fairly smooth.
Best wishes
Ulf
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
It's not bad but I find 3D really benefits from higher frame rates. I don't know why but I can play a console game at 30fps and not have too many issues, but a 3D game at 30fps feels much slower and akward.
It's not bad but I find 3D really benefits from higher frame rates. I don't know why but I can play a console game at 30fps and not have too many issues, but a 3D game at 30fps feels much slower and akward.
It's not bad but I find 3D really benefits from higher frame rates. I don't know why but I can play a console game at 30fps and not have too many issues, but a 3D game at 30fps feels much slower and akward.
It's not bad but I find 3D really benefits from higher frame rates. I don't know why but I can play a console game at 30fps and not have too many issues, but a 3D game at 30fps feels much slower and akward.
Everyone's sensititvity tends to differ a little, but I certainly noticed smoother motion when migrating from 1080p24 to 1080p30 3D (using TriDef's Ignition, 60 Hz Desktop setting - for reduced control lag), but smaller improvement above 30 fps. Before the great 4K EDID mod existed, I primarily used Ignition, 1080p24 full-frame 3D, and AMD GPUs (for many years). Note that very few HDTVs can display 1080p30, however...
Everyone's sensititvity tends to differ a little, but I certainly noticed smoother motion when migrating from 1080p24 to 1080p30 3D (using TriDef's Ignition, 60 Hz Desktop setting - for reduced control lag), but smaller improvement above 30 fps. Before the great 4K EDID mod existed, I primarily used Ignition, 1080p24 full-frame 3D, and AMD GPUs (for many years). Note that very few HDTVs can display 1080p30, however...
I actually can't stand gaming at 30fps, I suspect it actually gives me headaches the animation is just so choppy to my eyes. Yes some people are more sensitive to it than others but I suspect this changes for the most part once you are used to a higher framerate. Personally 30fps is the bare minimum for me 24hz would be unacceptable.
I actually found Dark souls was actually less difficult in 3dvision at 60fps too.
I actually can't stand gaming at 30fps, I suspect it actually gives me headaches the animation is just so choppy to my eyes. Yes some people are more sensitive to it than others but I suspect this changes for the most part once you are used to a higher framerate. Personally 30fps is the bare minimum for me 24hz would be unacceptable.
I actually found Dark souls was actually less difficult in 3dvision at 60fps too.
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
EVGA 1080TI SLI
Samsung SSD 840Pro
ASUS Z97-WS
3D Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
Problem is I can't get 60hz on ultra in Witcher 3. My computer needs an upgrade and I'm not planning SLI this time so it's waiting for pascal to arrive. Don't have the money at the moment either.
Problem is I can't get 60hz on ultra in Witcher 3. My computer needs an upgrade and I'm not planning SLI this time so it's waiting for pascal to arrive. Don't have the money at the moment either.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
I think the topic of 30hz gaming on TVs is officially closed. Let's focus on getting DX11 and DX9 titles to work in SBS and top-bottom.
DarkStarSword has done great work already.
I'm not sure his code is stable enough to be in the main branch of 3DMigoto. If it is I will attempt to plug it into DX9.
I can't change the thread title but let's discuss DX9 SBS in this thread.
Otherwise someone could be kind enough to create a new thread for that topic.
This is different from our current DX11 solution and will require some work.
More SBS for the win :)
The 4K edid hack is good for those that can use it.
I'm doing this for you as I don't have a TV and don't need it personally.
SBS and top-bottom Would be lovely now with 4k 3D Tvs and HMD like OSVR. It would solve the problem with streaming to Living room 3D tvs from your pc. It would be nice if nvidia just added this to the out put options in there driver.
But, in the end I trust the work in our community members more then the company that makes the hardware. I thank them for all there hard work.
I also notice something interesting with the OPENGL3DVISION WRAPPER made by Helifax if you turn off 3D useing Ctrl T it turns in to Side By Side and it work well. That's How I play Open GL games with his wrapper on my 4k TV.
SBS and top-bottom Would be lovely now with 4k 3D Tvs and HMD like OSVR. It would solve the problem with streaming to Living room 3D tvs from your pc. It would be nice if nvidia just added this to the out put options in there driver.
But, in the end I trust the work in our community members more then the company that makes the hardware. I thank them for all there hard work.
I also notice something interesting with the OPENGL3DVISION WRAPPER made by Helifax if you turn off 3D useing Ctrl T it turns in to Side By Side and it work well. That's How I play Open GL games with his wrapper on my 4k TV.
Flugan - if you wanted to get started trying to port my SBS / TAB solution to your DX9 wrapper go for it. I can try to give you a hand but I am really flat out with other things right now and I still have to sort out some remaining issues with certain games in the DX11 version. It would be really good if we can post them both to the blog in a couple of weeks so that we solve it for just about every situation, and I'm sure it would increase the exposure of your DX9 wrapper and get you a little more visibility in the community as well :)
Flugan - if you wanted to get started trying to port my SBS / TAB solution to your DX9 wrapper go for it. I can try to give you a hand but I am really flat out with other things right now and I still have to sort out some remaining issues with certain games in the DX11 version. It would be really good if we can post them both to the blog in a couple of weeks so that we solve it for just about every situation, and I'm sure it would increase the exposure of your DX9 wrapper and get you a little more visibility in the community as well :)
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
I'm not sure how many fixes work with my wrapper as HeliX wrapper is way more advanced.
Let me know when you feel ready with your code and point me in the right direction and I will probably figure it out. If I'm able to.
I'm not sure how many fixes work with my wrapper as HeliX wrapper is way more advanced.
Let me know when you feel ready with your code and point me in the right direction and I will probably figure it out. If I'm able to.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
I think we should be aiming for something that can be chain loaded from Helix Mod so they can both work together rather than attempting to replace Helix Mod. As for the code - there will be some reuse but I suspect the majority of it will be written from scratch following the same high level procedure since a lot of the details will be different:
[.] vertex shader needs to use a vertex buffer instead of SV_VertexID[/.]
[.] pixel shader needs to use a sampler instead of .Load()[/.]
[.] reverse stereo blit may have some shared code, but the DX calls are slightly different (see below).[/.]
[.] hook on the present call will use an explicit procedure that follows the same rough process as the CustomShader section in the DX11 version, which boils down to:[list]
[.] perform reverse stereo blit on back buffer[/.]
[.] save any state that will be altered/cleared[/.]
[.] clear any state that may interfere[/.]
[.] set any state the custom shaders need (including assigning the stereo back buffer to a sampler)[/.]
[.] run the shaders[/.]
[.] restore the original state[/.]
[.] call the original present call[/.]
[/list][/.]
Because of this, I don't think there is any reason to wait for the DX11 version to be polished since it's mostly going to be just about fixing up issues with the state, or problems that occur during game init. The DX9 version may well run into similar issues, but it's not clear that they will be the same issues.
The reverse stereo blit is probably the hardest part to get right since there are a few gotches. The public documentation on the call is here:
[url]http://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__stereoapi.html#gabf25d1ff8c91bc13fe42f097e0e5ae05[/url]
To make it work, you need to get the back buffer with ID3D9Device::GetBackBuffer() and perform a reverse stereo blit from it to a STEREO double width texture using StretchRect (force it to stereo when creating the texture), then copy that to a MONO double width texture (force it to mono when creating the texture). The first is necessary for the reverse stereo blit to work at all (doesn't make much sense, but trust me on that), and the second is necessary so that the shader will be able to read the same info from both eyes.
There are other gotchas with the reverse stereo blit as well (doesn't work on depth buffers or MSAA resources, which require additional steps to convert to something that it can work on), but since you only need to apply it to the back buffer you should not need to worry (also, these may not even apply to DX9 at all).
The code to do this in 3DMigoto is all in CommandList.cpp - search for "stere2mono", "reverse" and "RecreateCompatibleResource". This is all generic code though to support arbitrary resource copying - you don't need 99% of it since you are only doing one relatively straight forward thing and don't need to worry about all the permutations that code is designed to handle and all the edge cases that come about with it.
There is also an additional implementation of the reverse stereo blit in FrameAnalysis.cpp - search for "DumpStereoResource" and "CreateStagingResource". This is a bit simpler since it is not as generic, and it does handle some of the edge cases that CommandList does not without additional steps (MSAA and depth buffer cases), but does not perform the final copy back to a mono resource since it maps them to the CPU instead.
I think we should be aiming for something that can be chain loaded from Helix Mod so they can both work together rather than attempting to replace Helix Mod. As for the code - there will be some reuse but I suspect the majority of it will be written from scratch following the same high level procedure since a lot of the details will be different:
vertex shader needs to use a vertex buffer instead of SV_VertexID
pixel shader needs to use a sampler instead of .Load()
reverse stereo blit may have some shared code, but the DX calls are slightly different (see below).
hook on the present call will use an explicit procedure that follows the same rough process as the CustomShader section in the DX11 version, which boils down to:
perform reverse stereo blit on back buffer
save any state that will be altered/cleared
clear any state that may interfere
set any state the custom shaders need (including assigning the stereo back buffer to a sampler)
run the shaders
restore the original state
call the original present call
Because of this, I don't think there is any reason to wait for the DX11 version to be polished since it's mostly going to be just about fixing up issues with the state, or problems that occur during game init. The DX9 version may well run into similar issues, but it's not clear that they will be the same issues.
The reverse stereo blit is probably the hardest part to get right since there are a few gotches. The public documentation on the call is here: http://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__stereoapi.html#gabf25d1ff8c91bc13fe42f097e0e5ae05
To make it work, you need to get the back buffer with ID3D9Device::GetBackBuffer() and perform a reverse stereo blit from it to a STEREO double width texture using StretchRect (force it to stereo when creating the texture), then copy that to a MONO double width texture (force it to mono when creating the texture). The first is necessary for the reverse stereo blit to work at all (doesn't make much sense, but trust me on that), and the second is necessary so that the shader will be able to read the same info from both eyes.
There are other gotchas with the reverse stereo blit as well (doesn't work on depth buffers or MSAA resources, which require additional steps to convert to something that it can work on), but since you only need to apply it to the back buffer you should not need to worry (also, these may not even apply to DX9 at all).
The code to do this in 3DMigoto is all in CommandList.cpp - search for "stere2mono", "reverse" and "RecreateCompatibleResource". This is all generic code though to support arbitrary resource copying - you don't need 99% of it since you are only doing one relatively straight forward thing and don't need to worry about all the permutations that code is designed to handle and all the edge cases that come about with it.
There is also an additional implementation of the reverse stereo blit in FrameAnalysis.cpp - search for "DumpStereoResource" and "CreateStagingResource". This is a bit simpler since it is not as generic, and it does handle some of the edge cases that CommandList does not without additional steps (MSAA and depth buffer cases), but does not perform the final copy back to a mono resource since it maps them to the CPU instead.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Flugan if you are going to work on this, you will probably want to look into adding force fullscreen, resolution and refresh rates also. That's if you haven't already done so in your dx9 wrapper or perhaps this is already available in helixmod.
In fact, if you already have it as a feature you could host it as a solution for 2D gamers and solicit donations from a larger demographic since prior options like Refresh Lock, stopped development years ago
http://www.softpedia.com/get/Tweak/Video-Tweak/RefreshLock.shtml
Chiri has a version, but it is undocumented and never works.
http://helixmod.blogspot.com/2013/02/chiris-force-certain-resolutionhertz.html
Just an idea....
This post made me think of it
[quote="dr_invisibrow"]OK I poked around a bit tonight and I feel like I made some amount of progress. I stumbled on a d3d9.dll someone prepared for a different game in order to force fullscreen, and it works in this case, too.
In case anyone else wants to have a look, I tossed it here:
https://drive.google.com/folderview?id=0B4a3obHgl0Med19pcWNuYmJZdmM&usp=sharing
There are just two problems:
1) I'm not sure why, but it appears the DRM in this game prevents this dll from hooking in. So it unfortunately only works alongside a pirated copy of the game with DRM stripped out.
2) This dll has the same name as the one the helix mod uses. I'm not sure how to load both of them.[/quote]
[url]https://forums.geforce.com/default/topic/901810/3d-vision/lightning-returns-final-fantasy-xiii/post/4828764/#4828764[/url]
Flugan if you are going to work on this, you will probably want to look into adding force fullscreen, resolution and refresh rates also. That's if you haven't already done so in your dx9 wrapper or perhaps this is already available in helixmod.
In fact, if you already have it as a feature you could host it as a solution for 2D gamers and solicit donations from a larger demographic since prior options like Refresh Lock, stopped development years ago
http://www.softpedia.com/get/Tweak/Video-Tweak/RefreshLock.shtml
dr_invisibrow said:OK I poked around a bit tonight and I feel like I made some amount of progress. I stumbled on a d3d9.dll someone prepared for a different game in order to force fullscreen, and it works in this case, too.
There are just two problems:
1) I'm not sure why, but it appears the DRM in this game prevents this dll from hooking in. So it unfortunately only works alongside a pirated copy of the game with DRM stripped out.
2) This dll has the same name as the one the helix mod uses. I'm not sure how to load both of them.
Best wishes
Ulf
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
I actually found Dark souls was actually less difficult in 3dvision at 60fps too.
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
EVGA 1080TI SLI
Samsung SSD 840Pro
ASUS Z97-WS
3D Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
DarkStarSword has done great work already.
I'm not sure his code is stable enough to be in the main branch of 3DMigoto. If it is I will attempt to plug it into DX9.
I can't change the thread title but let's discuss DX9 SBS in this thread.
Otherwise someone could be kind enough to create a new thread for that topic.
This is different from our current DX11 solution and will require some work.
More SBS for the win :)
The 4K edid hack is good for those that can use it.
I'm doing this for you as I don't have a TV and don't need it personally.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
But, in the end I trust the work in our community members more then the company that makes the hardware. I thank them for all there hard work.
I also notice something interesting with the OPENGL3DVISION WRAPPER made by Helifax if you turn off 3D useing Ctrl T it turns in to Side By Side and it work well. That's How I play Open GL games with his wrapper on my 4k TV.
This is depending on how hard it is to port DarkStarSwords solution.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
Let me know when you feel ready with your code and point me in the right direction and I will probably figure it out. If I'm able to.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
Because of this, I don't think there is any reason to wait for the DX11 version to be polished since it's mostly going to be just about fixing up issues with the state, or problems that occur during game init. The DX9 version may well run into similar issues, but it's not clear that they will be the same issues.
The reverse stereo blit is probably the hardest part to get right since there are a few gotches. The public documentation on the call is here:
http://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__stereoapi.html#gabf25d1ff8c91bc13fe42f097e0e5ae05
To make it work, you need to get the back buffer with ID3D9Device::GetBackBuffer() and perform a reverse stereo blit from it to a STEREO double width texture using StretchRect (force it to stereo when creating the texture), then copy that to a MONO double width texture (force it to mono when creating the texture). The first is necessary for the reverse stereo blit to work at all (doesn't make much sense, but trust me on that), and the second is necessary so that the shader will be able to read the same info from both eyes.
There are other gotchas with the reverse stereo blit as well (doesn't work on depth buffers or MSAA resources, which require additional steps to convert to something that it can work on), but since you only need to apply it to the back buffer you should not need to worry (also, these may not even apply to DX9 at all).
The code to do this in 3DMigoto is all in CommandList.cpp - search for "stere2mono", "reverse" and "RecreateCompatibleResource". This is all generic code though to support arbitrary resource copying - you don't need 99% of it since you are only doing one relatively straight forward thing and don't need to worry about all the permutations that code is designed to handle and all the edge cases that come about with it.
There is also an additional implementation of the reverse stereo blit in FrameAnalysis.cpp - search for "DumpStereoResource" and "CreateStagingResource". This is a bit simpler since it is not as generic, and it does handle some of the edge cases that CommandList does not without additional steps (MSAA and depth buffer cases), but does not perform the final copy back to a mono resource since it maps them to the CPU instead.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
In fact, if you already have it as a feature you could host it as a solution for 2D gamers and solicit donations from a larger demographic since prior options like Refresh Lock, stopped development years ago
http://www.softpedia.com/get/Tweak/Video-Tweak/RefreshLock.shtml
Chiri has a version, but it is undocumented and never works.
http://helixmod.blogspot.com/2013/02/chiris-force-certain-resolutionhertz.html
Just an idea....
This post made me think of it
https://forums.geforce.com/default/topic/901810/3d-vision/lightning-returns-final-fantasy-xiii/post/4828764/#4828764