Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

Derniers messages - Page 492

  Forum

stefnev1
MODÉRATEUR
Inscrit en Jul 2008
17207 message(s)
TheEmu
Inscrit en Jul 2012
7424 message(s)

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Tout sur iStripper
18 July 2021, 5063 réponses
Could lack of a "Swizzle" feature explain why some other members' rigs are not compiling some shaders
where the code "boxes" (so to speak) don't balance

No. The "swizzle" operation is a very basic feature of the GLSL shader language and will be supported in hardware by all GPUs (there may be some that did not, but if so the compiler has to generate extra code making them very slow, just as it has to if everything is done in software). The incusion of swizzle as a texture feature indicates that the hardware also has a feature that enables swizzling to be done directly when acessing texture memory but that is not relevant to the simple case under discussion.

The problem is that the compliers in some GPU drivers accept as valid statements that the published GLSL standard says are invalid and, instead of issuing an error message and rejecting the program, they try to be helpful by doing something that may or may not be what the programmer intended.

For example, if v2 and v3 are of type vec2 and vec3 respectively the statement

v2 = v3;

which being short for

v2.xy = v3.xyz;

should be rejected because you can't put three values into something that can only hold two. But some of the compliers treat the above as if it was

v2.xy = v3.xy;

similarly they accept v3 = v2, i.e.

v3.xyz = v2.xy;

as valid and just partially update the value of v3 leaving v3.z unchanged even though the language standard says otherwise.

This behaviour is never useful in new code as it hides bugs. All it ever does is save a few characters in a statement at the expense of making its meaning obscure. The only excuse for it is that the earliest compilers did it so the behaviour is kept so that old programs keep on working - but in that case it would be far better to at least issue a warning rather than silently accept what the language standard defines to be invalid code.
EverthangForever
Inscrit en Oct 2009
4474 message(s)

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Tout sur iStripper
18 July 2021, 5063 réponses
Some GPU's will ignore this error and just swizzle the vectors to match
@WA thank you so much for this explanation (above)

I noticed that if I delete my vghd.log , then quit iStripper and re-open it
to play one scene file, the newly generated vghd.log provides
a summary of fullscreen OpenGL dumps showing data specific to my graphics card.
including:

OPENGL GL_VENDOR: NVIDIA Corporation]
OPENGL GL_RENDERER: GeForce GT 730/PCIe/SSE2]
OPENGL GL_VERSION: 4.6.0 NVIDIA 462.30]
OPENGL GL_SHADING_LANGUAGE_VERSION: 4.60 NVIDIA]
OPENGL version: "4.6"]

OPENGL features: ("Multitexture", "Shaders", "Buffers", "Framebuffers", "BlendColor", "BlendEquation", "BlendEquationSeparate", "BlendFuncSeparate", "BlendSubtract", "CompressedTextures", "Multisample", "StencilSeparate", "NPOTTextures", "NPOTTextureRepeat", "FixedFunctionPipeline")]

OPENGL texture features: ("ImmutableStorage", "ImmutableMultisampleStorage", "TextureRectangle", "TextureArrays", "Texture3D", "TextureMultisample", "TextureBuffer", "TextureCubeMapArrays", "Swizzle", "StencilTexturing", "AnisotropicFiltering", "NPOTTextures", "NPOTTextureRepeat", "Texture1D")]

OPENGL texture units: 32]
OPENGL texture max size: 16384]

I noticed that within the 'texture features' includes "Swizzle"

Could lack of a "Swizzle" feature explain why some other members' rigs are not compiling some shaders
where the code "boxes" (so to speak) don't balance.. yet the shader on my graphics card still compiles ok
without reporting an 'ERROR' ?
Wyldanimal
MODÉRATEUR
Inscrit en Mar 2008
17204 message(s)

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Tout sur iStripper
17 July 2021, 5063 réponses
if you think of the Vec2 as TWO boxes
then p has TWO boxes that you must always put something in.

Also the results of a formula, must have a Box for each of it's results.

lets look at this example

vec2 p = -1.0 + 2.0 * q;
p.x *= iResolution.xy/iResolution.y;

the 1st line vec2 p =
this assigns TWO boxes to p

so p by itself needs to have TWO boxes filled.

in the second line p.x =
here we are using a swizzle to put something in JUST ONE of the BOXES, the BOX called x
But on the other side of the = the formula produces TWO results, So we need to have TWO boxes to hold the results.

this
iResolution.xy/iResolution.y

it is Taking the TWO boxes of iResolution.xy or BOX iResolution.x and BOX iResolution.y
and dividing them by the same box iResolution.y

is a shorter way of
doing this
(iResolution.x/iResolution.y , iResolution.y/iResolution.y)

the results is TWO boxes
but on the front side of the =
there was only ONE BOX to hold the results.

that is what is Meant by you can't convert from a Vec2 float ( 2 Boxes ) to a float (a single BOX)

the Number of BOXES on both sides of the = must be the same.



Now there are several ways to fix the error, and you have to try them to see if it gives the desired results.

you could change line 115 to

p *= iResolution.xy/iResolution.y;
the p alone has 2 BOXES and the formula produces a TWO BOX result.
or
p *= iResolution.xy/iResolution.yx;
again, both side have 2 BOXES
or
p.xy *= iResolution.xy/iResolution.y;
and Again, Both Sides have two BOXES
or
p.x *= iResolution.x/iResolution.y;
this one is different
both sides have only ONE BOX, but Both sides still have the same number of BOXES

a vec3 has 3 BOXES so both sides of the = must have 3 BOXES

a vec4 has 4 BOXES so both sides of the = must have 4 BOXES

The first, second, third, and fourth BOXES can be referred to by using the Swizzle letters
xyzw where x = BOX1, y=BOX2, z=BOX3, w=BOX4
rgba where r = BOX1, g=BOX2, b=BOX3, a=BOX4
stpq where s = BOX1, t=BOX2, p=BOX3, q=BOX4

you can jumble the order of the letter, but the letters are fixed to which BOX they represent.
x is always BOX 1
g is always BOX 2
z is always BOX 3








Wyldanimal
MODÉRATEUR
Inscrit en Mar 2008
17204 message(s)

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Tout sur iStripper
17 July 2021, 5063 réponses
How do you find the error?
in your VGHD.log file it will list the error and what line of code the error took place.

this is what was reported in the vghd.log
2021-07-17T03:35:54[] WARNING[QOpenGLShader::compile(Fragment): ERROR: 4:115: 'assign' : cannot convert from '2-component vector of highp float' to 'highp float']

lets break the error into smaller pieces.

2021-07-17T03:35:54[] WARNING
[QOpenGLShader::compile(Fragment):
ERROR: 4:115:
'assign' : cannot convert from '2-component vector of highp float' to 'highp float']

the error is a 4, and it happened on line 115

the error description is
assign : cannot convert from '2-component vector of highp float' to 'highp float'

Note: Some GPU's will ignore this error and just swizzle the vectors to match

Here is the snippet of code around line 115
notice that p is assigned as a vec2 float on line 114
then on line 115 it is attempting to be converted to a vec1 float.
( we don't use vec1 as part of the language.
but I wrote that so you can see, converting from a 2 vector float to a single vector float )



vec2 p = -1.0 + 2.0 * q;
p.x *= iResolution.xy/iResolution.y;

Now there are several ways to fix the error, and you have to try them to see if it gives the desired results.

you could change line 115 to

p *= iResolution.xy/iResolution.y;
or
p *= iResolution.xy/iResolution.yx;
or
p.xy *= iResolution.xy/iResolution.y;
or
p.x *= iResolution.x/iResolution.y;

all of those will correct the vector conversion error
but not all of them will give the same results

in this case, all of the results are acceptable.