Jump to content

  • Log In with Google      Sign In   
  • Create Account

how to avoid macro loops


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
33 replies to this topic

#21 proanim   Members   -  Reputation: 446

Like
0Likes
Like

Posted 27 December 2012 - 11:10 AM

It works with s.append("\n"); no problem.

 

Also when I try to read the file as santa01 suggested there is something wierd happening. When function gets vertex shader it reads through it and exits just before

 

    theColor = inColor;
}

 

and when it reads through fragment shader it read the file entirely and adds some garbage characters at the end (when debugging).

 

I never used this approach so I might be missing something.



Sponsor:

#22 L. Spiro   Crossbones+   -  Reputation: 14447

Like
0Likes
Like

Posted 27 December 2012 - 11:41 AM

Are you phil67rpg?

If you made changes to your code and you have new errors, post the new code.  It helps us not to take shots in the dark when trying to guess what your problem could be.

 

Anyway it sounds as though you either forgot to add the 0 or you added the 0 but at a fixed position.

I surely hope you did not forget the 0 because I mentioned it twice and it was included in the santa01’s code.

 

If you are inserting it at a fixed or miscalculated position it would explain why one shader is too short and the other is too long.

 

 

Again, nothing but conjecture until we see some code.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#23 proanim   Members   -  Reputation: 446

Like
0Likes
Like

Posted 27 December 2012 - 12:20 PM

This is the code I used 

 

ifstream file(sFile.c_str(), ios::binary);

	file.seekg(0, ios::end);
    int sourceLength = file.tellg(); // warning C4244: 'initializing' : conversion from 'std::streamoff' to 'int', possible loss of data
    GLchar* shaderSource = new GLchar[sourceLength + 1];
 
    file.seekg(0, ios::beg);
    file.read(shaderSource, sourceLength);
    shaderSource[sourceLength] = 0;
 
	file.close();

    uiShader = glCreateShader(a_iType);
    glShaderSource(uiShader, 1, (const GLchar**)&shaderSource, NULL);
    glCompileShader(uiShader);
 
    delete[] shaderSource;

    GLint compileStatus;
    glGetShaderiv(uiShader, GL_COMPILE_STATUS, &compileStatus);

    if (compileStatus == GL_FALSE)
	{
        GLint infoLogLength;
        glGetShaderiv(uiShader, GL_INFO_LOG_LENGTH, &infoLogLength);
        
        GLchar* infoLog = new GLchar[infoLogLength + 1];
        glGetShaderInfoLog(uiShader, infoLogLength, NULL, infoLog);
        
		ofstream outfile;
		outfile.open ("log.txt");
		outfile << infoLog << endl;
		outfile.close();

        delete[] infoLog;
    }

 

it is almost exactly the same as santa01's.

 

You say that santa01's code did include 0 (where is it?)



#24 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 27 December 2012 - 02:30 PM

it is almost exactly the same as santa01's.

 

You say that santa01's code did include 0 (where is it?)

 

Its on line:

shaderSource[sourceLength] = 0;

which does present in your sources...

 

you can always print shaderSource to stdout to see if there is any extra crap in the buffer. its also useful to look through the shaderSource contents in your IDE under debug, IDEs do usually print special character with their symbolic representation like \r\n etc. for instance if you develop under MacOS X you gonna have \r whereas shader compiler could expect \n instead, hence compilation errors.

 

and it definitely won't harm to examine shader source file in hex editor to check its real contents :)



#25 proanim   Members   -  Reputation: 446

Like
0Likes
Like

Posted 28 December 2012 - 09:29 AM

When i print the content of shaderSource to file with

 

ofstream outfile;
outfile.open ("log.txt", fstream::out | fstream::app);
outfile << shaderSource << endl;
outfile << endl;
outfile.close();

 

I get normal contents of vertex and fragment shader - no extra symbols or anything.

 

But when I use debugger I see this

 

 

63944468.jpg
 
and this
 

36815480.jpg
 
any ideas?

 



#26 Paradigm Shifter   Crossbones+   -  Reputation: 5442

Like
0Likes
Like

Posted 28 December 2012 - 09:36 AM

You haven't executed the line that null terminates the string yet. Step over it and look again.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#27 proanim   Members   -  Reputation: 446

Like
0Likes
Like

Posted 28 December 2012 - 09:58 AM

When I get to delete[] shaderSource; line
vertex shader is the same as i posted and fragment shader doesn't have extra symbols at the end huh.png

Edited by proanim, 28 December 2012 - 09:58 AM.


#28 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 28 December 2012 - 10:53 AM

Can you confirm that when source is explicitly defined in code lie this:

    const GLchar* shaderSource = "#version 330\n"
        "layout (location = 0) in vec3 inPosition;\n"
        "layout (location = 1) in vec3 inColor;\n"
        "smooth out vec3 theColor;\n"
        "void main()\n"
        "{\n"
            "gl_Position = vec4(inPosition, 1.0);\n"
            "theColor = inColor;\n"
        "}\n"

    glShaderSource(uiShader, 1, &shaderSource, NULL);
    glCompileShader(uiShader);

    // dont call delete[] on const arrays, you will get SIGSEGV

    GLint compileStatus;
    glGetShaderiv(uiShader, GL_COMPILE_STATUS, &compileStatus);

    if (compileStatus == GL_FALSE) {
        GLint infoLogLength;
        glGetShaderiv(uiShader, GL_INFO_LOG_LENGTH, &infoLogLength);
        
        GLchar* infoLog = new GLchar[infoLogLength + 1];
        glGetShaderInfoLog(uiShader, infoLogLength, NULL, infoLog);
        
		ofstream outfile;
		outfile.open ("log.txt");
		outfile << infoLog << endl;
		outfile.close();

        delete[] infoLog;
    }

it compiles without errors?


Edited by santa01, 28 December 2012 - 10:55 AM.


#29 proanim   Members   -  Reputation: 446

Like
0Likes
Like

Posted 28 December 2012 - 11:15 AM

It compiles without errors but it doesn't have any effect. I tried your way, there was no effect from the shader but the debugger did show correct output from shaderSource. I also tried to use it this way

 

bool CShader::loadVertexShader(int a_iType)
{
	const GLchar* shaderSource = "#version 330\n"
        "layout (location = 0) in vec3 inPosition;\n"
        "layout (location = 1) in vec3 inColor;\n"
        "smooth out vec3 theColor;\n"
        "void main()\n"
        "{\n"
            "gl_Position = vec4(inPosition, 1.0);\n"
            "theColor = inColor;\n"
        "}\n";

	uiShader = glCreateShader(a_iType);
    glShaderSource(uiShader, 1, &shaderSource, NULL);
    glCompileShader(uiShader);

	ofstream outfile;
	outfile.open ("log.txt", fstream::out | fstream::app);
	outfile << shaderSource << endl;
	outfile << endl;
	outfile.close();

	GLint compileStatus;
    glGetShaderiv(uiShader, GL_COMPILE_STATUS, &compileStatus);
 
    if (compileStatus == GL_FALSE)
	{
        GLint infoLogLength;
        glGetShaderiv(uiShader, GL_INFO_LOG_LENGTH, &infoLogLength);
        
        GLchar* infoLog = new GLchar[infoLogLength + 1];
        glGetShaderInfoLog(uiShader, infoLogLength, NULL, infoLog);
        
		ofstream outfile;
		outfile.open ("log.txt");
		outfile << infoLog << endl;
		outfile.close();
 
        delete[] infoLog;
    }

	return 1;
}

 

also no effect. I did this just in case I don't miss anything when doing this part

 

// Load shaders and create shader program
//shVertex.loadShader("data/shaders/color.vert", GL_VERTEX_SHADER);
shVertex.loadVertexShader(GL_VERTEX_SHADER);
shFragment.loadShader("data/shaders/color.frag", GL_FRAGMENT_SHADER);


#30 Cornstalks   Crossbones+   -  Reputation: 6991

Like
0Likes
Like

Posted 28 December 2012 - 12:21 PM

What do you mean by "no effect?" If things aren't drawing/showing, it possible your draw calls and/or vertex data are incorrect.


[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#31 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 28 December 2012 - 12:58 PM

also no effect.

We are currently talking about these compilation errors:

Fragment shader failed to compile with the following errors:
ERROR: 2:1: error(#307) Profile "smooth" is not supported
ERROR: 2:1: error(#76) Syntax error: unexpected tokens following #version
ERROR: error(#273) 2 compilation errors.  No code generated

right?

 

If yes, then glsl compiler definitely considers shader source as a one line like:

 

#version 330layout (location = 0) in vec3 inPosition;layout (location = 1) in vec3 inColor;smooth out vec3 theColor;

 

which isn't legal and the only stuff I can suggest here is to try out windows EOL sequence of \r\n instead of pure \n in a shaderSource above

 

If no, than please provide something more valuable rather than `also no effect', glsl compilation log at least (if nothing is printed and nothing is rendered than its worth printing shader compilation status log with out the check `if (compileStatus == GL_FALSE)')



#32 proanim   Members   -  Reputation: 446

Like
0Likes
Like

Posted 28 December 2012 - 01:02 PM

Well this is only simple trinagle on the screen that should make use of color shader. The works by default, and somewhere on the half of this topic there was a solution that improved my original shader loading function (and it works no problem). But then since it was suggested not to read the file line by line and do extra work after, I would like to try and make that work.

And this approach gives white triangle instead of rainbow color effect that you see in usual tutorials that use color shader. That is what i mean by having 'no effect'. As far as I can tell there is no errors in the function or in shaders, this problem is very wierd to me since even if I supply vertex shader which I am having problems (like const GLchar* from above) with for whatever reason, it doesn't work.



#33 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 28 December 2012 - 01:40 PM

And this approach gives white triangle instead of rainbow color effect that you see in usual tutorials that use color shader.

How do you render your polygon?



#34 rip-off   Moderators   -  Reputation: 8764

Like
0Likes
Like

Posted 28 December 2012 - 02:16 PM

As the others have mentioned, you really have (at least) two distinct problems here. The first is loading the file contents into memory, and the second relates to loading and applying shaders. You should approach these as different problems, and solve and test them in isolation.

As others have demonstrated, use a hard coded string literal to test your shader code.

Likewise, write a small program to demonstrate and test file loading. For example, you can load a file into a string fairly simply using streambuf iterators:
#include <string>
#include <iterator>
#include <fstream>
#include <iostream>

std::string read(std::istream &stream) {
    std::istreambuf_iterator<char> begin(stream);
    std::istreambuf_iterator<char> end;
    return std::string(begin, end);
}

int main() {
    std::ifstream in("ReadMe.txt");
    if(in) {
         std::string data = read(in);
         std::cout << "The file contents are:\n";
         std::cout << data;
    } else {
        std::cerr << "Failed to open the file" << std::endl;
        return 1;

    }
}
It is also possible to make read() a one liner, but it falls afoul of the most vexing parse.

Once you've verified that you can load strings correctly, and that you can create and use shaders correctly, then is the time to create a program that does both. Breaking a complex task into simpler sub-tasks is called "divide and conquer" and is absolutely necessary for writing functioning and maintainable software.

Edited by rip-off, 28 December 2012 - 02:17 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS