The Crew
  7 / 10    
[quote="bo3b"] If statements in the CPU are essentially free today, there is no point in optimizing them away. More to the point, you have wildly obfuscated that code, and I'll bet $100 the compiler generates exactly the same code. [/quote] I am afraid you will loose that bet... Edit: Now the below part is without taking into account what the compiler DOES when you specify Optimize the code /02, /03 (as there is magic there only those who wrote the compiler will understand ^_^) So this is the a pure non-optimized asm generated: /End of Edit [code] 1st case ASM: cmp eax, ebx je label1 jne label2 label: bla bla bla ret label2 bla bla bla ret [/code] [code] 2ND case: cmp eax, ebx je label1 label2 bla bla bla label: bla bla bla ret [/code] As you can see there is only one jump and one ret rather than 2 jumps and 2 rets. Don't belive me? Write it compile it and disassemble it;)) Anywho we are loosing track here hahaha this is just for the love of art. Now back to this: [quote="bo3b"] Actually, not to be mean, but your example of the If statement there is nearly a textbook example of what NOT to do. [/quote] I really want to see that book and mostly I want to see the logic behind it. The way I see it (and all the people I know/worked with) is this: Case 1: Imagine first function being 100 lines long and having "return;" all over the place Case 2: Same function as above (100 lines) but has just one return. You can clearly see where it ends and what it returns. You just need to find where the return value is modified, thus making the whole block more readable and making the block flow natural rather than being abruptly stopped in the middle of it... It's funny since in all the companies I worked they all agreed on the same semantic as case2 (always one return rather then returns all over the freaking place)... but then again...maybe all of them were/bad at coding ? and I took something bad from them ? [quote="Helifax"] Also don't go crazy and OVER Optimize stuff as that can lead to other bad things (code base could become less readable, less maintainable). [/quote] That is exactly why I gave that example to show what it WILL LEAD TO. That is why I kept saying all over the initial post "Don't go with over-optimizations..." Anyway, I think I "deviated" this thread too much... and in the end is all about how readable the code is and so on.
bo3b said:

If statements in the CPU are essentially free today, there is no point in optimizing them away.
More to the point, you have wildly obfuscated that code, and I'll bet $100 the compiler generates exactly the same code.


I am afraid you will loose that bet...

Edit: Now the below part is without taking into account what the compiler DOES when you specify Optimize the code /02, /03 (as there is magic there only those who wrote the compiler will understand ^_^)
So this is the a pure non-optimized asm generated:

/End of Edit

1st case ASM:

cmp eax, ebx
je label1
jne label2

label:
bla bla bla
ret

label2
bla bla bla
ret


2ND case:

cmp eax, ebx
je label1
label2
bla bla bla

label:
bla bla bla
ret


As you can see there is only one jump and one ret rather than 2 jumps and 2 rets. Don't belive me? Write it compile it and disassemble it;))
Anywho we are loosing track here hahaha this is just for the love of art.

Now back to this:
bo3b said:
Actually, not to be mean, but your example of the If statement there is nearly a textbook example of what NOT to do.

I really want to see that book and mostly I want to see the logic behind it.

The way I see it (and all the people I know/worked with) is this:

Case 1: Imagine first function being 100 lines long and having "return;" all over the place
Case 2: Same function as above (100 lines) but has just one return. You can clearly see where it ends and what it returns. You just need to find where the return value is modified, thus making the whole block more readable and making the block flow natural rather than being abruptly stopped in the middle of it...

It's funny since in all the companies I worked they all agreed on the same semantic as case2 (always one return rather then returns all over the freaking place)... but then again...maybe all of them were/bad at coding ? and I took something bad from them ?

Helifax said:
Also don't go crazy and OVER Optimize stuff as that can lead to other bad things (code base could become less readable, less maintainable).


That is exactly why I gave that example to show what it WILL LEAD TO. That is why I kept saying all over the initial post "Don't go with over-optimizations..."

Anyway, I think I "deviated" this thread too much... and in the end is all about how readable the code is and so on.

1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc


My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com

(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)

#91
Posted 03/21/2015 12:30 PM   
[quote="helifax"]Instead of: [code] bool FuncA(void) { if (a == b) return true; else return false; } [/code][/quote] Of course you could also do: [code] bool FuncA(void) { return (a == b); } [/code] But again I'd just advise going with whichever is going to be clearest in the context of the function.
helifax said:Instead of:

bool FuncA(void)
{
if (a == b)
return true;
else
return false;
}

Of course you could also do:

bool FuncA(void)
{
return (a == b);
}


But again I'd just advise going with whichever is going to be clearest in the context of the function.

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

#92
Posted 03/21/2015 01:27 PM   
[quote="bo3b"] Maybe we disagree, but I think the second example is nearly unreadable, the first is clean and clear.[/quote]lol, welcome to my world. Almost all code is unreadable to me. It didn't occur to me that my if/then workaround would be at all problematic because any lack of clarity there just seems like another drop in the ocean. But point taken. I've dabbled in programming on and off for 25 years now, but I don't think anything has ever felt clean and clear in that time. I somehow scrape through when I have to, but my brain just never quite feels at home in this world. EDIT: just realised that you were talking to Helifax. I guess plain English is a problem area for me sometimes too,hehe. Actually, I understood Helifax's 2nd example well, because I recognised it from Fusion where I use it all the time. In Fusion (more of a GUI wrapper than a programming language itself) it looks something like this: ALWAYS: inputQuit = true IF [esc] is pressed, inputQuit = false In Fusion, it's actually a time saver, because doing the if statement twice would be more fiddly. I find the logic simple too: it's basically "do this, unless that", though it arguably twists the original meaning of "if/then" to do so. So the problem is probably less with the logic, and more with vocabulary (ie.most programming languages don't have the word "unless"). Anyway, I'm pleased with my progress so far. I've fixed loads of things already: HUD, map, sun glare, smoke, leaves, mud splatters. I've had no luck with the blooms though, apart from disabling them, so I'll probably ask for help with that tomorrow.
bo3b said:
Maybe we disagree, but I think the second example is nearly unreadable, the first is clean and clear.
lol, welcome to my world. Almost all code is unreadable to me. It didn't occur to me that my if/then workaround would be at all problematic because any lack of clarity there just seems like another drop in the ocean. But point taken.

I've dabbled in programming on and off for 25 years now, but I don't think anything has ever felt clean and clear in that time. I somehow scrape through when I have to, but my brain just never quite feels at home in this world.

EDIT: just realised that you were talking to Helifax. I guess plain English is a problem area for me sometimes too,hehe.

Actually, I understood Helifax's 2nd example well, because I recognised it from Fusion where I use it all the time. In Fusion (more of a GUI wrapper than a programming language itself) it looks something like this:

ALWAYS: inputQuit = true
IF [esc] is pressed, inputQuit = false

In Fusion, it's actually a time saver, because doing the if statement twice would be more fiddly.

I find the logic simple too: it's basically "do this, unless that", though it arguably twists the original meaning of "if/then" to do so.

So the problem is probably less with the logic, and more with vocabulary (ie.most programming languages don't have the word "unless").




Anyway, I'm pleased with my progress so far. I've fixed loads of things already: HUD, map, sun glare, smoke, leaves, mud splatters. I've had no luck with the blooms though, apart from disabling them, so I'll probably ask for help with that tomorrow.

ImageVolnaPC.com - Tips, tweaks, performance comparisons (PhysX card, SLI scaling, etc)

#93
Posted 03/21/2015 01:33 PM   
@Helifax: If you are going to compare code the compiler generates, you have to leave on full optimizations. Still, this all misses the point. If you are changing your coding habits based on supposed performance improvements you are definitely doing it wrong. Look, I'm not guessing here- When I worked at Apple, my last cool job was as the Tech Lead for the OS performance profiling team. We had a test suite that would run some 25 apps and games through an automated test suite to look for performance degradations on different OS releases. I worked professionally on performance problems and performance metrics for 5 years. Now during that time, I would speak with various engineers about changes they made that introduced problems. There was not a single instance of a person guessing their problem correctly. I could never do it either. The only way you'll know where performance matters is to profile the code. Now performance problems are *always* bottleneck related. There is never a situation where it's just code that is too lengthy or too verbose or something. Spending any time at all on optimizing IF statements is wasting your personal time on stuff that has no measurable impact. Saving three instructions in a sequence of code that is run once is just a waste of time and energy. People who started with very small computers like Ataris or Apple IIs nearly always have this optimize everything mindset- and the problem is that it wastes time you could spend on something more valuable. Like a measured performance bottleneck. This all really comes down to how you want to spend your time. I strongly recommend people spend their time on results-oriented approaches, keeping in mind that there are higher values like readability that are extremely valuable on big teams. Your example there of dev teams not wanting returns out of the middle of a function is not at all related to performance. That's a code quality issue and if the shop deems it a requirement, that is certainly a proven approach. The reason they want that is for code simplicity and reliability, and that is orthogonal to performance. Edit: Apologies if that comes across as too strong. I tend to get overly excited about these sorts of things because of a lot of bad experiences in the past with my team members concentrating on stuff that was irrelevant, and making us miss schedules or be canceled outright. Edit2: There actually is a textbook of sorts, McConnells "Code Complete". This book made me a 10x better programmer. [url]http://www.amazon.com/Code-Complete-Edition-Developer-Practices-ebook/dp/B00JDMPOSY/ref=dp_kinw_strp_1[/url] Relevant snippet: [url]https://books.google.com/books?id=LpVCAwAAQBAJ&pg=PT1096&lpg=PT1096&dq=mcconnell+code+complete+optimization&source=bl&ots=GGJqpiFkQN&sig=_XAvMAqfn0uck8vRlv0_TjxIWY0&hl=en&sa=X&ei=SzoOVabqA5ekyATZtIH4Bg&ved=0CDYQ6AEwBA#v=onepage&q=mcconnell%20code%20complete%20optimization&f=false[/url]
@Helifax: If you are going to compare code the compiler generates, you have to leave on full optimizations.

Still, this all misses the point. If you are changing your coding habits based on supposed performance improvements you are definitely doing it wrong.

Look, I'm not guessing here- When I worked at Apple, my last cool job was as the Tech Lead for the OS performance profiling team. We had a test suite that would run some 25 apps and games through an automated test suite to look for performance degradations on different OS releases. I worked professionally on performance problems and performance metrics for 5 years.

Now during that time, I would speak with various engineers about changes they made that introduced problems. There was not a single instance of a person guessing their problem correctly. I could never do it either.

The only way you'll know where performance matters is to profile the code.


Now performance problems are *always* bottleneck related. There is never a situation where it's just code that is too lengthy or too verbose or something.

Spending any time at all on optimizing IF statements is wasting your personal time on stuff that has no measurable impact. Saving three instructions in a sequence of code that is run once is just a waste of time and energy.

People who started with very small computers like Ataris or Apple IIs nearly always have this optimize everything mindset- and the problem is that it wastes time you could spend on something more valuable. Like a measured performance bottleneck.

This all really comes down to how you want to spend your time. I strongly recommend people spend their time on results-oriented approaches, keeping in mind that there are higher values like readability that are extremely valuable on big teams.


Your example there of dev teams not wanting returns out of the middle of a function is not at all related to performance. That's a code quality issue and if the shop deems it a requirement, that is certainly a proven approach.

The reason they want that is for code simplicity and reliability, and that is orthogonal to performance.


Edit: Apologies if that comes across as too strong. I tend to get overly excited about these sorts of things because of a lot of bad experiences in the past with my team members concentrating on stuff that was irrelevant, and making us miss schedules or be canceled outright.

Edit2: There actually is a textbook of sorts, McConnells "Code Complete". This book made me a 10x better programmer.

http://www.amazon.com/Code-Complete-Edition-Developer-Practices-ebook/dp/B00JDMPOSY/ref=dp_kinw_strp_1

Relevant snippet:
https://books.google.com/books?id=LpVCAwAAQBAJ&pg=PT1096&lpg=PT1096&dq=mcconnell+code+complete+optimization&source=bl&ots=GGJqpiFkQN&sig=_XAvMAqfn0uck8vRlv0_TjxIWY0&hl=en&sa=X&ei=SzoOVabqA5ekyATZtIH4Bg&ved=0CDYQ6AEwBA#v=onepage&q=mcconnell%20code%20complete%20optimization&f=false

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#94
Posted 03/22/2015 02:40 AM   
OK, when you titans of programming wisdom have finished sparring, could someone please help me with my The Crew fix? :p As I mentioned before, I've managed to fix a whole bunch of stuff, which is great. I'm now tackling the bloom. There are many shaders that affect the headlights, and most of my attempts to fix them (using some of the techniques recommended by DarkStarSword) didn't work. I did however manage to get very promising results with one shader just now. When I applied the prime directive to it, it fixed the positioning perfectly (headlight blooms, both front and back, were positioned correctly, on both your car and others'). The are, however, 3 problems. [IMG]http://i60.tinypic.com/15e7hpe.jpg[/IMG] PROBLEM 1: they don't occlude properly. As you can see in the jeep, the lights shine through the metal. They DO disappear eventually if you keep rotating the camera, but not early enough. PROBLEM 2: They don't display in each eye (you can see this in the pic also). This is actually less of a problem than I would have thought - I honestly didn't even notice it until I saw the above side-by-side. But it's still a problem, obviously. PROBLEM 3: The damn thing just stopped working. Ever since I alt-tabbed out and into the game (and I've since quit and reloaded), these same headlights are WAY off. They are no longer screen-depth like they were in vanilla, but they have a separation of about 20cm now. I didn't change any files - all I did was alt tab out and back in. Here is the VS: [code]//car front and rear lights bloom - sharpish points for front, bluntish for rear VS Texture2D<float4> t0 : register(t0); SamplerState s0_s : register(s0); Texture2D<float4> StereoParams : register(t125); Texture1D<float4> IniParams : register(t120); void main( float4 v0 : position0, float4 v1 : TEXCOORD0, float4 v2 : TEXCOORD1, float4 v3 : TEXCOORD2, out float4 o0 : SV_POSITION0, out float o1 : SV_ClipDistance0, out float4 o2 : TEXCOORD0, out float4 o3 : TEXCOORD1) { float4 r0; uint4 bitmask, uiDest; float4 fDest; o0.xy = v0.zw; o0.zw = float2(0.000000e+000,1.000000e+000); r0.xyzw = t0.SampleLevel(s0_s, v1.xy, 0.000000000e+000).xyzw; o1.x = -v2.w + r0.x; o2.xy = v1.zw; o2.zw = float2(0.000000e+000,0.000000e+000); o3.xyzw = v3.xyzw; //FORCE NVIDIA STEREO ADJUSTMENT (PRIME DIRECTIVE) float4 stereo = StereoParams.Load(0); float separation = stereo.x; float convergence = stereo.y; o0.x += separation * (o0.w - convergence); // o0=0; return; } /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // Generated by Microsoft (R) D3D Shader Disassembler // // // Input signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // position 0 xyzw 0 NONE float zw // TEXCOORD 0 xyzw 1 NONE float xyzw // TEXCOORD 1 xyzw 2 NONE float w // TEXCOORD 2 xyzw 3 NONE float xyzw // // // Output signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_POSITION 0 xyzw 0 POS float xyzw // SV_ClipDistance 0 x 1 CLIPDST float x // TEXCOORD 0 xyzw 2 NONE float xyzw // TEXCOORD 1 xyzw 3 NONE float xyzw // vs_4_0 dcl_sampler s0, mode_default dcl_resource_texture2d (float,float,float,float) t0 dcl_input v0.zw dcl_input v1.xyzw dcl_input v2.w dcl_input v3.xyzw dcl_output_siv o0.xyzw, position dcl_output_siv o1.x, clip_distance dcl_output o2.xyzw dcl_output o3.xyzw dcl_temps 1 mov o0.xy, v0.zwzz mov o0.zw, l(0,0,0,1.000000) sample_l r0.xyzw, v1.xyxx, t0.xyzw, s0, l(0.000000) add o1.x, r0.x, -v2.w mov o2.xy, v1.zwzz mov o2.zw, l(0,0,0,0) mov o3.xyzw, v3.xyzw ret // Approximately 0 instruction slots used ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/ [/code] Here is the relevant PS: [code]//car front and rear lights bloom - sharpish points for front, bluntish for rear Texture2D<float4> t0 : register(t0); SamplerState s0_s : register(s0); Texture2D<float4> StereoParams : register(t125); Texture1D<float4> IniParams : register(t120); void main( float4 v0 : SV_POSITION0, float v1 : SV_ClipDistance0, float4 v2 : TEXCOORD0, float4 v3 : TEXCOORD1, out float4 o0 : SV_Target0) { float4 r0; uint4 bitmask, uiDest; float4 fDest; r0.xyzw = t0.Sample(s0_s, v2.xy).xyzw; o0.xyz = v3.xyz * r0.xyz; o0.w = 0.000000000e+000; //headlight bloom disable // o0=0; return; } /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // Generated by Microsoft (R) D3D Shader Disassembler // // // Input signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_POSITION 0 xyzw 0 POS float // SV_ClipDistance 0 x 1 CLIPDST float // TEXCOORD 0 xyzw 2 NONE float xy // TEXCOORD 1 xyzw 3 NONE float xyz // // // Output signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_Target 0 xyzw 0 TARGET float xyzw // ps_4_0 dcl_sampler s0, mode_default dcl_resource_texture2d (float,float,float,float) t0 dcl_input_ps linear v2.xy dcl_input_ps linear v3.xyz dcl_output o0.xyzw dcl_temps 1 sample r0.xyzw, v2.xyxx, t0.xyzw, s0 mul o0.xyz, r0.xyzx, v3.xyzx mov o0.w, l(0) ret // Approximately 0 instruction slots used ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/ [/code] Any idea how I could address any of these 3 problems? (obviously #3 is the most important)
OK, when you titans of programming wisdom have finished sparring, could someone please help me with my The Crew fix? :p

As I mentioned before, I've managed to fix a whole bunch of stuff, which is great. I'm now tackling the bloom. There are many shaders that affect the headlights, and most of my attempts to fix them (using some of the techniques recommended by DarkStarSword) didn't work.

I did however manage to get very promising results with one shader just now. When I applied the prime directive to it, it fixed the positioning perfectly (headlight blooms, both front and back, were positioned correctly, on both your car and others').

The are, however, 3 problems.

Image

PROBLEM 1: they don't occlude properly. As you can see in the jeep, the lights shine through the metal. They DO disappear eventually if you keep rotating the camera, but not early enough.

PROBLEM 2: They don't display in each eye (you can see this in the pic also). This is actually less of a problem than I would have thought - I honestly didn't even notice it until I saw the above side-by-side. But it's still a problem, obviously.

PROBLEM 3: The damn thing just stopped working. Ever since I alt-tabbed out and into the game (and I've since quit and reloaded), these same headlights are WAY off. They are no longer screen-depth like they were in vanilla, but they have a separation of about 20cm now. I didn't change any files - all I did was alt tab out and back in.

Here is the VS:

//car front and rear lights bloom - sharpish points for front, bluntish for rear VS

Texture2D<float4> t0 : register(t0);

SamplerState s0_s : register(s0);


Texture2D<float4> StereoParams : register(t125);
Texture1D<float4> IniParams : register(t120);

void main(
float4 v0 : position0,
float4 v1 : TEXCOORD0,
float4 v2 : TEXCOORD1,
float4 v3 : TEXCOORD2,
out float4 o0 : SV_POSITION0,
out float o1 : SV_ClipDistance0,
out float4 o2 : TEXCOORD0,
out float4 o3 : TEXCOORD1)
{
float4 r0;
uint4 bitmask, uiDest;
float4 fDest;

o0.xy = v0.zw;
o0.zw = float2(0.000000e+000,1.000000e+000);
r0.xyzw = t0.SampleLevel(s0_s, v1.xy, 0.000000000e+000).xyzw;
o1.x = -v2.w + r0.x;
o2.xy = v1.zw;
o2.zw = float2(0.000000e+000,0.000000e+000);
o3.xyzw = v3.xyzw;



//FORCE NVIDIA STEREO ADJUSTMENT (PRIME DIRECTIVE)

float4 stereo = StereoParams.Load(0);
float separation = stereo.x; float convergence = stereo.y;
o0.x += separation * (o0.w - convergence);
// o0=0;





return;
}

/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// position 0 xyzw 0 NONE float zw
// TEXCOORD 0 xyzw 1 NONE float xyzw
// TEXCOORD 1 xyzw 2 NONE float w
// TEXCOORD 2 xyzw 3 NONE float xyzw
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_POSITION 0 xyzw 0 POS float xyzw
// SV_ClipDistance 0 x 1 CLIPDST float x
// TEXCOORD 0 xyzw 2 NONE float xyzw
// TEXCOORD 1 xyzw 3 NONE float xyzw
//
vs_4_0
dcl_sampler s0, mode_default
dcl_resource_texture2d (float,float,float,float) t0
dcl_input v0.zw
dcl_input v1.xyzw
dcl_input v2.w
dcl_input v3.xyzw
dcl_output_siv o0.xyzw, position
dcl_output_siv o1.x, clip_distance
dcl_output o2.xyzw
dcl_output o3.xyzw
dcl_temps 1
mov o0.xy, v0.zwzz
mov o0.zw, l(0,0,0,1.000000)
sample_l r0.xyzw, v1.xyxx, t0.xyzw, s0, l(0.000000)
add o1.x, r0.x, -v2.w
mov o2.xy, v1.zwzz
mov o2.zw, l(0,0,0,0)
mov o3.xyzw, v3.xyzw
ret
// Approximately 0 instruction slots used

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/



Here is the relevant PS:

//car front and rear lights bloom - sharpish points for front, bluntish for rear

Texture2D<float4> t0 : register(t0);

SamplerState s0_s : register(s0);


Texture2D<float4> StereoParams : register(t125);
Texture1D<float4> IniParams : register(t120);

void main(
float4 v0 : SV_POSITION0,
float v1 : SV_ClipDistance0,
float4 v2 : TEXCOORD0,
float4 v3 : TEXCOORD1,
out float4 o0 : SV_Target0)
{
float4 r0;
uint4 bitmask, uiDest;
float4 fDest;

r0.xyzw = t0.Sample(s0_s, v2.xy).xyzw;
o0.xyz = v3.xyz * r0.xyz;
o0.w = 0.000000000e+000;
//headlight bloom disable
// o0=0;



return;
}

/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_POSITION 0 xyzw 0 POS float
// SV_ClipDistance 0 x 1 CLIPDST float
// TEXCOORD 0 xyzw 2 NONE float xy
// TEXCOORD 1 xyzw 3 NONE float xyz
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target 0 xyzw 0 TARGET float xyzw
//
ps_4_0
dcl_sampler s0, mode_default
dcl_resource_texture2d (float,float,float,float) t0
dcl_input_ps linear v2.xy
dcl_input_ps linear v3.xyz
dcl_output o0.xyzw
dcl_temps 1
sample r0.xyzw, v2.xyxx, t0.xyzw, s0
mul o0.xyz, r0.xyzx, v3.xyzx
mov o0.w, l(0)
ret
// Approximately 0 instruction slots used

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/



Any idea how I could address any of these 3 problems? (obviously #3 is the most important)

ImageVolnaPC.com - Tips, tweaks, performance comparisons (PhysX card, SLI scaling, etc)

#95
Posted 03/22/2015 11:20 AM   
@bo3b Totally agree with you! The IF/ELSE example was given since Volnaiskra asked about the performance of the if/else block and I tried to help. I said the performance impact is negligible at best and he shouldn't care about optimizing that. If he really wants to optimize he could do something like that (that makes it easier to read and so on and so on.) I know no one releases code WITHOUT optimizations and thus I tried to say that there are cases when optimizing a tiny function like that might give optimized code in ASM. (Different story when you build it with optimizations ;)) ) Don't worry, I don't feel offended or anything! I actually enjoyed having this discussion and I really hope others might learn from it as well;)) Big thanks for the "Code Complete" book link (I am already sleeping with it "under the pillow"). Good to see that someone else is also referencing that book ! ;)) I'm done hijacking this thread;)) but I really hope people learnt some lessons from this discussion ^_^
@bo3b

Totally agree with you! The IF/ELSE example was given since Volnaiskra asked about the performance of the if/else block and I tried to help. I said the performance impact is negligible at best and he shouldn't care about optimizing that. If he really wants to optimize he could do something like that (that makes it easier to read and so on and so on.) I know no one releases code WITHOUT optimizations and thus I tried to say that there are cases when optimizing a tiny function like that might give optimized code in ASM. (Different story when you build it with optimizations ;)) )

Don't worry, I don't feel offended or anything! I actually enjoyed having this discussion and I really hope others might learn from it as well;))

Big thanks for the "Code Complete" book link (I am already sleeping with it "under the pillow"). Good to see that someone else is also referencing that book ! ;))

I'm done hijacking this thread;)) but I really hope people learnt some lessons from this discussion ^_^

1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc


My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com

(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)

#96
Posted 03/22/2015 11:37 AM   
[quote]PROBLEM 3: The damn thing just stopped working. Ever since I alt-tabbed out and into the game (and I've since quit and reloaded), these same headlights are WAY off. They are no longer screen-depth like they were in vanilla, but they have a separation of about 20cm now. I didn't change any files - all I did was alt tab out and back in.[/quote]When you alt+tabbed out and in did the convergence change? What happens to the bloom as you adjust the convergence? [quote][code] o0.zw = float2(0.000000e+000,1.000000e+000);[/code][/quote] That looks like it's setting the output depth to a constant (1), suggesting that the depth is not going to be in o0.w, however if you are lucky the depth might be available elsewhere in the shader... [quote]PROBLEM 1: they don't occlude properly. As you can see in the jeep, the lights shine through the metal. They DO disappear eventually if you keep rotating the camera, but not early enough.[/quote]That suggests that the occlusion is probably still being based off the mono coordinates. It might be sampling the depth buffer at the original mono coordinates to determine occlusion, but it needs to sample it at the stereo coordinates. [quote]PROBLEM 2: They don't display in each eye (you can see this in the pic also). This is actually less of a problem than I would have thought - I honestly didn't even notice it until I saw the above side-by-side. But it's still a problem, obviously.[/quote]This is probably due to the same cause as problem 1. Curious: [quote]Here is the VS: [code] ... void main( ... float4 v1 : TEXCOORD0, ... out float o1 : SV_ClipDistance0, ... { ... r0.xyzw = t0.SampleLevel(s0_s, v1.xy, 0.000000000e+000).xyzw; o1.x = -v2.w + r0.x; ... } [/code][/quote] The vertex shader is sampling something (shame this game is missing headers to determine what) at coordinates passed in from the game and using it to set a clip distance with a given offset... Could that be the depth buffer it's sampling? Could this be setting the occlusion? Could v2.w contain the depth? This is a complaete stab in the dark - but what would happen if you modified the stereo correction like this: [code] o0.x += separation * (v2.w - convergence); [/code] And if that does work, what would happen if you then added this line just before the line with t0.SampleLevel (try the above change by itself first, and you will need to move the declarations of "stereo", "separation" and "convergence" up to before this point): [code] v1.x += separation * (v2.w - convergence) / v2.w; [/code]
PROBLEM 3: The damn thing just stopped working. Ever since I alt-tabbed out and into the game (and I've since quit and reloaded), these same headlights are WAY off. They are no longer screen-depth like they were in vanilla, but they have a separation of about 20cm now. I didn't change any files - all I did was alt tab out and back in.
When you alt+tabbed out and in did the convergence change? What happens to the bloom as you adjust the convergence?

o0.zw = float2(0.000000e+000,1.000000e+000);

That looks like it's setting the output depth to a constant (1), suggesting that the depth is not going to be in o0.w, however if you are lucky the depth might be available elsewhere in the shader...

PROBLEM 1: they don't occlude properly. As you can see in the jeep, the lights shine through the metal. They DO disappear eventually if you keep rotating the camera, but not early enough.
That suggests that the occlusion is probably still being based off the mono coordinates. It might be sampling the depth buffer at the original mono coordinates to determine occlusion, but it needs to sample it at the stereo coordinates.

PROBLEM 2: They don't display in each eye (you can see this in the pic also). This is actually less of a problem than I would have thought - I honestly didn't even notice it until I saw the above side-by-side. But it's still a problem, obviously.
This is probably due to the same cause as problem 1.



Curious:
Here is the VS:
...
void main(
...
float4 v1 : TEXCOORD0,
...
out float o1 : SV_ClipDistance0,
...
{
...
r0.xyzw = t0.SampleLevel(s0_s, v1.xy, 0.000000000e+000).xyzw;
o1.x = -v2.w + r0.x;
...
}

The vertex shader is sampling something (shame this game is missing headers to determine what) at coordinates passed in from the game and using it to set a clip distance with a given offset...

Could that be the depth buffer it's sampling? Could this be setting the occlusion? Could v2.w contain the depth?


This is a complaete stab in the dark - but what would happen if you modified the stereo correction like this:
o0.x += separation * (v2.w - convergence);



And if that does work, what would happen if you then added this line just before the line with t0.SampleLevel (try the above change by itself first, and you will need to move the declarations of "stereo", "separation" and "convergence" up to before this point):
v1.x += separation * (v2.w - convergence) / v2.w;

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

#97
Posted 03/22/2015 02:00 PM   
[quote="DarkStarSword"][quote]PROBLEM 3: The damn thing just stopped working. Ever since I alt-tabbed out and into the game (and I've since quit and reloaded), these same headlights are WAY off. They are no longer screen-depth like they were in vanilla, but they have a separation of about 20cm now. I didn't change any files - all I did was alt tab out and back in.[/quote]When you alt+tabbed out and in did the convergence change? What happens to the bloom as you adjust the convergence?[/quote]Yes, it may have changed, but just a little. I think I was using a convergence slightly different from the saved setting, so when I alt-tabbed it probably reverted to the saved setting. When I adjust the convergence all the way in (ie. there's no popout, everything is 'behind' the screen, and the adjustment itself slows down to a near stop even when still holding down the hotkey), then the bloom becomes perfectly aligned with the car. But when I move the convergence out to a moderate (desirable) degree again (little bit of popout on the road etc., but all of the car is still 'behind' the screen'), the bloom gets crazy separation again. [quote] Curious: [quote]Here is the VS: [code] ... void main( ... float4 v1 : TEXCOORD0, ... out float o1 : SV_ClipDistance0, ... { ... r0.xyzw = t0.SampleLevel(s0_s, v1.xy, 0.000000000e+000).xyzw; o1.x = -v2.w + r0.x; ... } [/code][/quote] The vertex shader is sampling something (shame this game is missing headers to determine what) at coordinates passed in from the game and using it to set a clip distance with a given offset... Could that be the depth buffer it's sampling? Could this be setting the occlusion? Could v2.w contain the depth? This is a complaete stab in the dark - but what would happen if you modified the stereo correction like this: [code] o0.x += separation * (v2.w - convergence); [/code][/quote] Then the bloom becomes even more widely separated :(
DarkStarSword said:
PROBLEM 3: The damn thing just stopped working. Ever since I alt-tabbed out and into the game (and I've since quit and reloaded), these same headlights are WAY off. They are no longer screen-depth like they were in vanilla, but they have a separation of about 20cm now. I didn't change any files - all I did was alt tab out and back in.
When you alt+tabbed out and in did the convergence change? What happens to the bloom as you adjust the convergence?
Yes, it may have changed, but just a little. I think I was using a convergence slightly different from the saved setting, so when I alt-tabbed it probably reverted to the saved setting.

When I adjust the convergence all the way in (ie. there's no popout, everything is 'behind' the screen, and the adjustment itself slows down to a near stop even when still holding down the hotkey), then the bloom becomes perfectly aligned with the car.

But when I move the convergence out to a moderate (desirable) degree again (little bit of popout on the road etc., but all of the car is still 'behind' the screen'), the bloom gets crazy separation again.


Curious:
Here is the VS:
...
void main(
...
float4 v1 : TEXCOORD0,
...
out float o1 : SV_ClipDistance0,
...
{
...
r0.xyzw = t0.SampleLevel(s0_s, v1.xy, 0.000000000e+000).xyzw;
o1.x = -v2.w + r0.x;
...
}

The vertex shader is sampling something (shame this game is missing headers to determine what) at coordinates passed in from the game and using it to set a clip distance with a given offset...

Could that be the depth buffer it's sampling? Could this be setting the occlusion? Could v2.w contain the depth?


This is a complaete stab in the dark - but what would happen if you modified the stereo correction like this:
o0.x += separation * (v2.w - convergence);


Then the bloom becomes even more widely separated :(

ImageVolnaPC.com - Tips, tweaks, performance comparisons (PhysX card, SLI scaling, etc)

#98
Posted 03/29/2015 12:21 AM   
@Volnaiskra: For the bloom, that sounds suspiciously like the bloom we see in TheBall. Same symptoms with it varying pretty wildly based on convergence. Take a look at the fix for the bloom in that case. It involved fixing BOTH the vertex location, AND the texture associated. This post shows both the original code, and the fixed code for reference: [url]https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/4048551/#4048551[/url] That is ASM, but I'm sure you can translate the idea to your HLSL shader.
@Volnaiskra: For the bloom, that sounds suspiciously like the bloom we see in TheBall. Same symptoms with it varying pretty wildly based on convergence.

Take a look at the fix for the bloom in that case. It involved fixing BOTH the vertex location, AND the texture associated.

This post shows both the original code, and the fixed code for reference:

https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/4048551/#4048551


That is ASM, but I'm sure you can translate the idea to your HLSL shader.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#99
Posted 03/29/2015 04:43 AM   
[quote="Volnaiskra"]But when I move the convergence out to a moderate (desirable) degree again (little bit of popout on the road etc., but all of the car is still 'behind' the screen'), the bloom gets crazy separation again.[/quote]That confirms that the bloom is being drawn with a very low depth that has nothing at all to do with the depth of the light. [quote][quote="DarkStarSword"]This is a complaete stab in the dark - but what would happen if you modified the stereo correction like this: [code] o0.x += separation * (v2.w - convergence); [/code][/quote] Then the bloom becomes even more widely separated :([/quote] I forgot to compensate for the difference between depth (if that is depth) and W - try this: [code] o0.x += separation * (v2.w - convergence) / v2.w * o0.w; [/code] Another thing you can try is using a ShaderOverride section in the d3dx.ini to draw that shader with a different convergence to the rest of the game - this would move it back to infinity: [code] [ShaderOverrideBloom] Hash = ... Convergence = 0 [/code]
Volnaiskra said:But when I move the convergence out to a moderate (desirable) degree again (little bit of popout on the road etc., but all of the car is still 'behind' the screen'), the bloom gets crazy separation again.
That confirms that the bloom is being drawn with a very low depth that has nothing at all to do with the depth of the light.

DarkStarSword said:This is a complaete stab in the dark - but what would happen if you modified the stereo correction like this:
o0.x += separation * (v2.w - convergence);


Then the bloom becomes even more widely separated :(


I forgot to compensate for the difference between depth (if that is depth) and W - try this:
o0.x += separation * (v2.w - convergence) / v2.w * o0.w;


Another thing you can try is using a ShaderOverride section in the d3dx.ini to draw that shader with a different convergence to the rest of the game - this would move it back to infinity:
[ShaderOverrideBloom]
Hash = ...
Convergence = 0

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

Posted 03/29/2015 05:22 AM   
[quote="DarkStarSword"] I forgot to compensate for the difference between depth (if that is depth) and W - try this: [code] o0.x += separation * (v2.w - convergence) / v2.w * o0.w; [/code][/quote] that made it separate further still. (so far apart that I had to greatly reduce the convergence for the blooms to re-enter the picture. [quote] Another thing you can try is using a ShaderOverride section in the d3dx.ini to draw that shader with a different convergence to the rest of the game - this would move it back to infinity: [code] [ShaderOverrideBloom] Hash = ... Convergence = 0 [/code][/quote] I just did [code]convergence = 0;[/code] in the shaderfile itself. Is that the same thing? It made a difference, but of course the bloom became independent of convergence, so even if I got it to almost work, it broke as soon as I adjusted convergence.
DarkStarSword said:

I forgot to compensate for the difference between depth (if that is depth) and W - try this:
o0.x += separation * (v2.w - convergence) / v2.w * o0.w;


that made it separate further still. (so far apart that I had to greatly reduce the convergence for the blooms to re-enter the picture.


Another thing you can try is using a ShaderOverride section in the d3dx.ini to draw that shader with a different convergence to the rest of the game - this would move it back to infinity:
[ShaderOverrideBloom]
Hash = ...
Convergence = 0


I just did
convergence = 0;
in the shaderfile itself. Is that the same thing?

It made a difference, but of course the bloom became independent of convergence, so even if I got it to almost work, it broke as soon as I adjusted convergence.

ImageVolnaPC.com - Tips, tweaks, performance comparisons (PhysX card, SLI scaling, etc)

Posted 03/29/2015 06:50 AM   
[quote="Volnaiskra"][quote="DarkStarSword"] I forgot to compensate for the difference between depth (if that is depth) and W - try this: [code] o0.x += separation * (v2.w - convergence) / v2.w * o0.w; [/code][/quote] that made it separate further still. (so far apart that I had to greatly reduce the convergence for the blooms to re-enter the picture.[/quote] Ok, sounds like this is a dead end, though it may just be that it is not scaled correctly and/or may require 1/v2.w for the depth, or maybe -v2.w. There's nothing in the shader to suggest how to scale it though, so any experimentation here would just be trial and error :( [quote]I just did [code]convergence = 0;[/code] in the shaderfile itself. Is that the same thing? [/quote] No, this isn't a local variable in the shader, this is the convergence setting that the driver uses when it applies the stereo correction so it has to be in the d3dx.ini. That said... I might have confused the issue here - if the bloom was originally at screen depth regardless of convergence than this won't do anything.
Volnaiskra said:
DarkStarSword said:

I forgot to compensate for the difference between depth (if that is depth) and W - try this:
o0.x += separation * (v2.w - convergence) / v2.w * o0.w;


that made it separate further still. (so far apart that I had to greatly reduce the convergence for the blooms to re-enter the picture.

Ok, sounds like this is a dead end, though it may just be that it is not scaled correctly and/or may require 1/v2.w for the depth, or maybe -v2.w. There's nothing in the shader to suggest how to scale it though, so any experimentation here would just be trial and error :(

I just did
convergence = 0;
in the shaderfile itself. Is that the same thing?

No, this isn't a local variable in the shader, this is the convergence setting that the driver uses when it applies the stereo correction so it has to be in the d3dx.ini. That said... I might have confused the issue here - if the bloom was originally at screen depth regardless of convergence than this won't do anything.

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

Posted 03/29/2015 07:03 AM   
Still seems like the same problem to me that TheBall was showing. Bloom wildly diverging upon changing convergence. I still think it would be interesting to try to stereo fix both the location and the texture, so o0 and o3 in this case.
Still seems like the same problem to me that TheBall was showing. Bloom wildly diverging upon changing convergence.

I still think it would be interesting to try to stereo fix both the location and the texture, so o0 and o3 in this case.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 03/29/2015 09:14 AM   
Hello, I can not understand everything, my English is not good enough. Where is the progress of a patch? have you forsaken? It's impossible, too complicated? I expect a patch to play this game :-p :-)
Hello, I can not understand everything, my English is not good enough.

Where is the progress of a patch? have you forsaken?
It's impossible, too complicated?
I expect a patch to play this game :-p

:-)

Posted 05/24/2015 09:42 AM   
laozi Just one mistake in English: "expect" --> hope for Some people here don't like to see such words as "I want", "I expect because I told you I want a while ago" etc., so avoid even getting close to such words ;) About the fix: I'm also still waiting, still hoping (and still asking kindly ;) ) I won't buy this game until the fix is ready. If it won't be finished - I won't play The Crew. And that would be bad, since it has a good potential to be awesome, but not in "fake" 3D. Real 3D transforms this mediocre game into a really interesting one. The world. I like the world in 3D. So huge, open terrain. :)
laozi

Just one mistake in English:

"expect" --> hope for

Some people here don't like to see such words as "I want", "I expect because I told you I want a while ago" etc., so avoid even getting close to such words ;)




About the fix:
I'm also still waiting, still hoping (and still asking kindly ;) )

I won't buy this game until the fix is ready. If it won't be finished - I won't play The Crew. And that would be bad, since it has a good potential to be awesome, but not in "fake" 3D. Real 3D transforms this mediocre game into a really interesting one. The world. I like the world in 3D. So huge, open terrain. :)

Posted 05/24/2015 10:35 PM   
  7 / 10    
Scroll To Top