FOXY

👍

I will try the new version this evening.

@Z22

Don't bother with the in and out qualifiers for things declared at the start of fragment shaders. Fragment shaders can only have one output and this is the predefined variable gl_FragColor which, being predefined, does not need to be declared by you at all. Even if they could have other outputs there is absolutely nothing that could ever use these other outputs. Using "in" is redundant because it is the default and the only thing that can be a valid "out" is gl_FragColor. Things are different in vertex shaders, but we are only talking about fragment shaders here.

Everything else declared in a fragment shader but outside of its functions can only be either

1) inputs. which must be declared as either uniform or varying. Any input should have a value assigned to it by something that runs before the fragment shader otherwise it will just be zero.

2) Shader local variables which must not be declared as either uniform or varying. These will default to zero unless you assign them an initial value.

Note, every time that a fragment shader runs it gets a new set of these variables - if you give one a value it will NOT have that value in the next frame but will have been reinitialised.

If you try to import code from other sources please be aware that different systems will provide different sets of system specific uniform and varying global variables. You can rely on those begining with gl_ as those are specified by the GLSL language and must always be provided, everything else is system specific (such as the vUv variables that you have previously used). Within the iStripper system there are some of variables, such as u_Elapsed and u_WindowSize which are provided by Totem's code but if you are getting code from elsewhere that uses any uniform or varying variables other than the gl_ ones you will need to find out if iStripper provides any equivalents and if so what they are called.

@TheEmu

@Z22 seems to have solved it. Version 5 of Acid Rain does not appear to be producing any errors in the vghd.log and therefore I would have thought it should now run on your INTEL GPU.

My Windows 10 allows me to select a default GPU to use when starting any executable or to start a program using a particular GPU. These choices are offered as a pop up menu when you right click on an executable as shown in the attached image. To run iStripper with specific GPU I therefore

1) Stop it if it is already running - using the Quit menu option from the iStripper Systray icon because closing the GUI window does not stop the program, only its user interface. Very occassionaly it has not stopped properly and I have had to ***** it using the Task Manager, but that hasn't happened to me for a long time.

2) Find the iStripper executable and right click on it to bring up the context menu, then navigate through the menu until you find and use the particular items show in the attached image. Confusingly, if you don't know the history, the executable is called vghd.exe and is found on my system in the following folder

C:\Users\X-Format\AppData\Local\vghd\bin

and should be in a similar location on yours.

I do not have time to look any further into Z22's shader problem at the moment. Maybe I can do so this evening, but I can not promise anything.

@Z22

It also works with swings but initially it might be easier to do it as a separate scene.

Under the "Clip" declaration remove "top" from the "deny" line

Add new line

allow: top

In the framebuffer id: fb2, under "clipsprite" change the position to 0, -2160.

I can't see any errors in the vghd.log so it looks like this is OK.

PS
You could also combine the swing scene with the origiinal to give you both a swing and standing/pole in one scene. You will need to move the clip positions to the left and/or right to stop them clashing. Apologies if I'm teaching my grandma to suck eggs.

Yes, models like Tessa Fowler, Alice Brookes, Louisa Lockheart, Busty Alli, Beth Lily, Joey Fisher or Sensual Jane would be great. And I am totally in love with Estelle Taylor.

Cool, hopefully The Emu can run it too.

Looks Good @Z22

Runs fine on my AMD/ATI and no errors reported in the vghd.log

Right.. Fingers crossed..

https://drive.google.com/open?id=0B52wt5m78EmUSGtmRmgxcXg3Qms


Edit:- left one of the files out.. Corrected

nm.. fixed.

Question: How does anyone temporarily disable the NVidia GPU so that their rig resorts to intel GPU only as per @TheEmu's situation.? It stands to reason, if members cannot temporarily do that, surely they will never know whether anything is working to GLSL rules or not. Problems shouldn't be fractal but they seem to beget each other lol.

It depends on your set up. Many PCs now have the grahpics card built in and not necessarily INTEL. If you do not have a separate graphics card then you can only work with the onboard one. Usually you woulld have to go into the BIOS to enable/disable the onboard graphics if you have a separate graphics card. Many people would not have this option if they only have the one GPU. Mine is permanently disabled as my lowly AMD/ATI is far better then the the onboard graphics.

I suspect that @ThEmu has a laptop similar to my work laptop. It has dual graphics cards (mine is INTEL or AMD). It auto switches between the two dependent on the application. For high graphics usage e.g. AutoCAD in my case, it automatically uses the AMD.

I haven't looked at mine too closely (It is only used at work) but I am guessing there is a way to ***** it to use only one of the graphics processors. I have a feeling that @TheEmu did this a while back when there were some problems with some of the stuff he had done. Apparently it worked OK on one of his GPU's but other people were having problems. When he tried it on his other GPU it also exhibited problems. Now I think he tries everything on both GPU's just to be certain.

Yeh , have gotten rid of the problems TheEmu told me about(i think) but now i have another problem,

I can't find the correct way of modifying a textures colour so i get a bias to the right on the red channel/texture because its using the colour cycle as x position as well as for red. Why it can do that in the first place is odd, If i can sort out that problem i should be able to get it working as intended again.

c0 = vec4(-((fm0)*ColSize), rbgT, rbgT, 0.1);
//fm's come from a modulated sine function. rgbT and ColSize are ease of use constants

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// offset texture buffers(not currently offsetting)

blur0 = c0 + texture2D(texture0, vec2(vTexCoord.x, vTexCoord.y));
the line above is the problem. its inputing fm0 into vtexcord.x and using it as a colour...( .y too but to a much lesser extent.)

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// combine buffers
gl_FragColor = mix (blur0, blur1, blur2); // addition layers removed for ease of reading.

So i can see what it's doing wrong now i just don't know how to fix it. doh!

Hi @Number6 great..as you can imagine my tongue is hanging out a lot ;-)>

greetz @z22
I haven't a clue what I'm doing however...
I have been eliminating the 'varying' function
by applying the 'in' 'out' syntax elaborated in
https://gamedev.stackexchange.com/questions/29672/in-out-keywords-in-glsl
to RadialBlur2B.fsh
eg:
///////////////////////
//Original taked from "halloween" scene by totem(istripper)
//Adapted by z22
//tweeked to RadialBlur2Bxxx.fsh

uniform sampler2D texture0;
uniform sampler2D texture1;
uniform sampler2D texture2;

//varying vec4 gl_TexCoord[];
//varying vec4 gl_Color;
in vec4 TexCoord;
out vec4 vTexCoord;
in vec4 FragColor;
out vec4 Colsize;

//////////////////////etc.

I've done the eliminating of 'varying' also for a Combine3xxx.fsh and
ChromativAberation2xxx.fsh and it appears to work much the same as before.

This doesn't take into account all the issues @TheEmu cited about non compliance with
his intel GPU and not assigning a value to anything declared as a uniform.

Question: How does anyone temporarily disable the NVidia GPU so that their rig resorts to intel GPU only as per @TheEmu's situation.? It stands to reason, if members cannot temporarily do that, surely they will never know whether anything is working to GLSL rules or not. Problems shouldn't be fractal but they seem to beget each other lol.

@Z22

Have you looked in your vghd.log?

The scene appears to work for me as per your screencaps and it is a nice effect but it is throwing up dozens of lines of errors in the vghd.log. It even lists lines of shader code in the log and I've never seen it do that (although Totem may have added this feature).

Some of the errors are the ones that @TheEmu has pointed out. Some of the others may be a subset of this.

Unfortunately it is some time since I did any scenes and although many of them used tweaked shaders I really don't know enough about Open GSL to comment. In those days with the old VG interface it actually had a debugger that threw up the errors on the fullscreen interface (even for those that appeared to work). This no longer happens however the vghd.log does list Fullscreen (and skin) errors.

The problem is that unless you follow the actual standards of Open GSL there are always going to be graphics cards it will work with and those it won't. This is down to the graphics cards manufacturers and their interpretation of the standards - some will ignore the error and others won't.

If you look way back in this thread (or maybe the shared screens thread) there was one particular shader that worked fine on my AMD/ATI card but @EverthangForever couldn't get it working on his NVIDIA. I think @Wyldanimal solved that one at the time. It was just a single line that the AMD/ATI would accept but the NVIDIA wouldn't.

I'd listen to what @TheEmu is saying - he has a lot of experience working with shaders. Between you I am sure you can solve the problem. It would be greaT if you can get it working without the errors as it would look really nice with some of my old psychedelic scenes. Who knows I may even be inspired to get up off my fat arse and do some more.

PS - Hi @EverthangForever - how's it going?

Right, i think i know whats spazzing it out now.

I have a texture and i want to alter its colour but i have been adding the colour array to the coords array.

blur0 = c0 + texture2D(texture0, vec2(vTexCoord.x - (1*blurSize), vTexCoord.y - (-0.1*blurSize)))

Whats the correct syntax to do so?

Well, i have cleared out a lot of the crap and now all it does is posterize it... dafuk? It may just be an amplitude problem and a bit of tuning will fix it.

I there anyway we can open the scn.cache and make it readable so i can see what it did when it came across the problems?



The fm1,fm3,fm5 numbers were because i pulled it out of an old folder and i had forgot i had been using a input from a texture loacation(was messing with plazmas).

AcidRain4, like the previous AcidRains does not work on my Intel GPU, for exactly the same reasons as before.

Please note in a fragment shader you MUST not assign a value to anything declared as a uniform or a varying. On some systems it may work but it is still invalid to do so EVEN ON THOSE SYSTEMS and may stop working at any time, typically after a graphics driver update.

It is as if you had an algorithm that navigated the streets from point A to point B but its included a step that drove the wrong way down a one way street - it may work but it is not valid.

That said, even after I correct the declarations of the fm variables to be simple floats I still just get a blank background and I have no idea why.

I have found what the vUv variables do - they do absolutely nothing. The only place that they are used is to assign initial values to c0, c1 and c2, but these are then overwriiten by new values a few lines further on. Delete the delcarations of these variables, delete the lines that use them and add vec4 to the start of the lines that assign values to c0, c1 and c2. (The vUv vaiables appear to be left over from some old code that has been copied from somewhere that used a system that automatically provided these variables, the iStripper system does not, but as you are effectively not using them that is not a problem)

As I had rather too much wine at lunch I am not going to try to do any more study of why the scenes do not work on my system because I am likely to do more ***** than good)

Sure, & AcidRain4 and all your previous trials work fine on my NVidia 660ti ;-)
Only thing I changed was the allow
because Natalia ~the Punisher was made for this .scn lol ;)
@Number6 has a different GPU to NVidia I believe,
so it would be good to hear from that side as well.

I see. So i should post work in progress versions here and save the other thread for when they work as intended(that could take a while...lol).

Does the latest one AcidRain4 work on your system?

Yes.........appropriate lyrics Chicsans, but not Chilliwack methinks, ...........More Led Zep........but not to worry........:)

@z22 tks for your comments in the shader mods. Really helps lots 😊👍

You asked elsewhere why there are 3 threads for fullscreen stuff:
I'm not saying it is gospel or anything, however this is how i understand it:

Share thread was created before discussion began pushing too deep into the thread newly shared work links. It works best for more final bug-free or complete versions* of things that show something new or some new approach about scene presentation.

Fullscreen Discussion thread was created to take the discussion padding out of the shared thread so people can easier find newly posted or older shared download links in the afore mentioned* place.

The 'New Fullscreens available!' thread is part of Totem Team's own announcements of new features section. Like a news thread group. Its really intended for feedback on what changes they've recently done, rather than for posting members' own creations. Its easy to ***** this, because @TotemTeam rarely post as a newsworthy header there something special or new about fullscreen. I think the last mention was within the beta announcement that included new FS right arrow key use :)

@Mustang013

If you consider the girls pleasuring themselves either with their own fingers or with toys, XXX is hotter than full nudity. You will get bonus credits when you have 40 cards in your collection. You're almost there.

is XXX hotter than full nudity? When do I get bonus credits?

@FX000

"Four men in a rock 'n roll band
Fly at night in the morning we land
Fly at night 'till we're satisfied
See the morning from the other side..."

Ooops, probably the wrong band.😐

Mr Bohnam was known for the good stuff! I'm sure it's a rhythmic leaf!!

@FX000 cool, wonder what he's smoking...

Thanks .

Ilove that pic! @Z22 hope ya don't mind,. I put some additions to that kewl piccy!

It made me think of four rock n roll fellows!

PieAce

Dang it. why are there 3 threads for scenes...

repost from the other 2...

https://drive.google.com/open?id=0B52wt5m78EmUdDd3aDBLZ0puTVE

Thanks, it can be downloaded now.

Goldfrapp;

https://www.youtube.com/watch?v=uco-2V4ytYQ

My own addition..

https://drive.google.com/open?id=0B52wt5m78EmUdDd3aDBLZ0puTVE

I have been informed that this doesn't work on at least one system, it works fine on mine though...hmm.

We are working on fixing it and i will post an updated link if/when we get it fixed.

FOXY

IMHO the best there is on the pole in the 3K cards.

When you have enough cards to be able to access the older 720p cards there is also Suzie Q and Shabba.

Forgot to add the link for the shader thats is creating those images

https://drive.google.com/open?id=0B52wt5m78EmUdDd3aDBLZ0puTVE

As far as i can remember the uVu thing is a left over/repurpose form

https://github.com/spite/Wagner/tree/master/fragment-shaders
I may have been thinking of adding the brightness/constast one then got distracted by boobs. ;?

I did try and add in his CA shader but while it gives a nice colourfull effect it zooms the image and i couldn't figure out a way of not doing so. It also causes stuttering randomly.

Are their any cards that have some really solid pole dancing?

This is the effect i am getting.

Look at my headache.

It seems that I still start from the GLSL entry😋

What your compiler is probably doing is treating fm0 etc. as if they were shader local variables rather than inputs.

Looking at your code again it seems that fm0, fm2 and fm4 all have their values calculated within the shader with the only inputs to these calculations being fm1, fm3, fm5 and u_Elapsed, but fm1, fm3 and fm5 are never assigned a value. It is possible that on your system you are getting some radndom non-zero value but I am always getting 0.0.

I would simply remove the varying or uniform keywords from the declaration of these variables and and an explicit initial value for them - something like the folowing (I have not tested these, so choose whatever values you feel appropriate)

float fm0 = 0.0;
float fm1 = 0.1;
float fm2 = 0.0;
float fm3 = 0.2;
float fm4 = 0.0;
float fm5 = 0.3;

I do not know what to do aboyt the vUv variables because I don't know what you were intending that they represent. The way they are currently declared means they will default to vec2(0.0,0.0) so when use them to access a texture you always get the colour of one of its corners, which is probably not what you want.

I am about to go out for lunch, if you have not solved the problem when I return I will experiment a bit with your code to see if I can get anywhere.

I am using a gtx 1080

The question is what is windows doing with these errors. Because the .scn work fine on my rig(by the looks of it on others too).

if i change
varying highp vec2 vUv0;
varying highp vec2 vUv1;
varying highp vec2 vUv2;
varying float fm0;
varying float fm1;
varying float fm2;
varying float fm3;
varying float fm4;
varying float fm5;

to
uniform highp vec2 vUv0;
uniform highp vec2 vUv1;
uniform highp vec2 vUv2;
uniform float fm0;
uniform float fm1;
uniform float fm2;
uniform float fm3;
uniform float fm4;
uniform float fm5;

it breaks(lessens) the effect.

So as you say it doesn't like the varing but at the same time uniform breaks it. So what is the compiler putting in its place that is giving me the effect i am getting? Don't forget i am a novice and have no clue what half of the commands mean or do.

I am just going by other shaders and experimenting to see what works ect.

fm's come from the 3 modulated sine functions.

/Modulated sine A

float amplitude0 = 1.0;
float frequency0 = 2.0;
fm0 = sin(fm1 * frequency0);
float t0 = 0.01*(-u_Elapsed*130);

fm0 += sin(fm1*frequency0*4.1 + t0*1.1);
fm0 += sin(fm1*frequency0*4.2 + t0*1.2);

fm0 *= amplitude0*0.04;

these give me a nice sine which i use cycle r.g.b.

AcidRain3 results in the following error messages (and more for other fm varaibles)

ERROR: 1:36: 'assign' : l-value required "fm0" (can't modify a uniform)
ERROR: 1:39: 'assign' : l-value required "fm0" (can't modify a uniform)
ERROR: 1:40: 'assign' : l-value required "fm0" (can't modify a uniform)
ERROR: 1:42: 'assign' : l-value required "fm0" (can't modify a uniform)
ERROR: 1:48: 'assign' : l-value required "fm2" (can't modify a uniform)

As I said before, uniform variables, like varying ones, are inputs into a fragment shader and can not be legally modified by one. Some compilers do not detect that the source program is invalid so you can get away with it when using those compilers - but the result is undefined and it may not work with the next release of the compiler.

Which compiler you use depends on which GPU you are using. I mainly use the one built into the Intel i7 CPU in my laptop but if I ***** it to use its "real" NVIDIA GPU then the NVIDIA compiler will be used - the compiler being part of the GPU driver. This probably explains why we see different results even though we are both using Windows machines.

Also, because the fm variables are inputs to the shader something elsewhere has to assign them values, but nothing in the AcidRain example does that.

This is me all over...


Hmm... odd, works on this end without throwing up any errors, although i found and quashed another bug.

The fm's are meant to add a colour cycle to r,g, and b of each texture(works on windows)(there was bug which made the fm's also move the texture xy)

See if this works on your system now, it works fine in windows.

https://drive.google.com/open?id=0B52wt5m78EmURTFyUF8xemx5T2c
Bugfixes and added fake chromatic aberation

At long last, thanks Totem - they look great! Time to play around with them myself and make some Background 2D images. Just one thing I've noticed the istripper logo gets some funny white lines top and bottom. When I crop them they are fine?

I would like to see Lucie T take 2.

Not going to happen but I would like to see her all grown up 😉

And Lola Reve, but I think she may have retired that sexy butt, who knows.

Karissa, Kalisy, Jillian Jansen, and Erica Fontes.

The new fullscreens look good, though I still can't use the bikini scene.

 You just need to buy bikini scenes or edit the category to all in the Bikinis.scn file.

Kate Shoo

@L3088
I want to add regular expressions to the search option, so you will be able to do searches like "a0893|a1340|a1473", but it will be added in the future - don't know when exactly.

Hovewever I have a request. To make this thread clear please leave any suggestions about Showrom in the proper thread, I mean here:
http://www.istripper.com/forum/thread/36785/1?post=540847
Thank you 😉

@lukaszr Thanks this is a great addition to your page, it makes a great extension to the istripper software.

In regards to the ability to search special offer cards would it be possible for you to add the ability to generate a list that can then be used to search in the software. I know if you use the "|" symbol in the search box you can enter a bunch of card numbers eg. "a0893|a1340|a1473" and it will only display those cards.

@lukaszr : you're the one my friend, your showroom becomes better and better with the time. bravo 👍

When I try your latest AcidRain my GLSL compiler (Intel's) rejects it with the following error messages.

ERROR: 1:33: 'assign' : l-value required "fm0" (can't modify a varying)
ERROR: 1:36: 'assign' : l-value required "fm0" (can't modify a varying)
ERROR: 1:37: 'assign' : l-value required "fm0" (can't modify a varying)
ERROR: 1:39: 'assign' : l-value required "fm0" (can't modify a varying)
[/code]

with more for the other fm variables. This is because you declare fm0 etc. as "varying". In GLSL the keyword "varying" does not declare a variable as distint to a constant, it declares a variable that has different values in different simultaneously active invokations of a fragment shader - basicly something that varies from pixel to pixel as opposed to a uniform variable that is the same for each pixel. The GLSL language says that fragment shaders may not modify anything declared as "varying" which are inputs to fragment shaders. Vertex shaders can modify things declared as "varying" and these act as inputs to the fragment shaders (actualy the inputs to the fragment shaders are interpolated from the values calculated for each of the neighbouring vertices). It is unfortunate that some GLSL compiler implementations do not enforce the limitation and allow things that are violations of the official language specification.

This can be fixed by just removing "varying" from the declarations - if you leave them outside the function they will be initialised to 0.0 or you can delete them and declare them inside the function when you first use them.

However, when I do this I then the scene reduces to a blank background behind the performer. This may be due to the cact that you have declared the "varying" vectors vUv0, vUv1 and vUv2 but nothing every provides them with values so they default to (0.0,0.0). When I run the scene I get a warning message

2017-10-22T08:47:05[] WARNING[QOpenGLShader::link: "Fragment shader contains a user varying, but is linked without a vertex shader.

What were you trying to do with vUv0 etc.?