Jump to content

  • Log In with Google      Sign In   
  • Create Account


Erik Rufelt

Member Since 17 Apr 2002
Offline Last Active Today, 04:24 AM
*****

#5141543 Compiling opengl code using gcc through the command line

Posted by Erik Rufelt on 23 March 2014 - 03:43 PM

so dont put it at the top, put under the others




#5141498 Compiling opengl code using gcc through the command line

Posted by Erik Rufelt on 23 March 2014 - 01:15 PM

Add one piece of the code at a time.

 

Don't start from the old code, start from the working code and add stuff in.

 

Don't remove the #includes at the top, but add the extra includes under them.




#5141494 Compiling opengl code using gcc through the command line

Posted by Erik Rufelt on 23 March 2014 - 12:54 PM

Great, congratulations :)

 

I think the -L with capital L actually adds a folder to search for libraries in so you can probably shorten it a bit by removing those if you don't have folders with those names that need added to the searchpaths.

 

The massive amounts of error messages from --verbose is that the linker tries to be smart when it doesn't find a library and searches all paths it knows and tries to add ".dll.a" and similar to the filenames to see if it can fix an error in the command line.




#5141477 Compiling opengl code using gcc through the command line

Posted by Erik Rufelt on 23 March 2014 - 11:37 AM

Seems it doesn't find the library paths. Maybe add -L"path to your directory"..

 

Googling tells me you can add "-Wl,--verbose" to add warnings to the linker..

 

Or try removing -lglew32 and -lfreeglut and just enter libglew32.a on the command line instead. Not sure if that works though..

 

Also, with that code you don't need GLEW so try without that first, then add it after freeglut works, so if something else goes wrong you can be sure which part gives the error.




#5141407 Compiling opengl code using gcc through the command line

Posted by Erik Rufelt on 23 March 2014 - 05:28 AM

You're getting compile errors. These have nothing to do with libs but with source code, as libs are only ever linked to once compiling succeeds without errors.

Your error "'GLAPI' does not name a type" comes from the fact that the file freeglut_std.h has source-code including 'GLAPI' and the compiler doesn't know what that means.

I would guess that is because you include freeglut_std.h without including gl.h or something like that.

 

The following means that on line 11 in Triangle.cpp you include GL/glut.h, and on line 17 in GL/glut.h that file includes freeglut_std.h, and in that file on line 121 is the error encountered. It's often so that if the first error in a long list like yours is fixed then all others are automatically fixed too.

/freeglut_std.h:121:0,
from /GL/glut.h:17,
from Triangle.cpp:11:

It seems very strange that these headers wouldn't guarantee to have GLAPI already defined.

 

Start by changing your file to include <GL/gl.h> at the top. That is just a guess though but if you're lucky it might change something.

 

If it doesn't work, try to compile this program first (as your current program is already dependent on a lot of different libraries, and it's better to add one at a time):

// Triangle.cpp
// Our first OpenGL program that will just draw a triangle on the screen.

#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h> // Windows FreeGlut equivalent

///////////////////////////////////////////////////////////////////////////////
// Window has changed size, or has just been created. In either case, we need
// to use the window dimensions to set the viewport and the projection matrix.
void ChangeSize(int w, int h)
{
    glViewport(0, 0, w, h);
}


///////////////////////////////////////////////////////////////////////////////
// Called to draw scene
void RenderScene(void)
{
    // Clear the window with current blue color
    glClearColor(0.0f, 0.0f, 1.0f, 1.0f );
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    // Perform the buffer swap to display back buffer
    glutSwapBuffers();
}


///////////////////////////////////////////////////////////////////////////////
// Main entry point for GLUT based programs
int main(int argc, char* argv[])
{
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
    glutInitWindowSize(800, 600);
    glutCreateWindow("Triangle");
    glutReshapeFunc(ChangeSize);
    glutDisplayFunc(RenderScene);

    glutMainLoop();

    return 0;
}



#5141326 Compiling opengl code using gcc through the command line

Posted by Erik Rufelt on 22 March 2014 - 06:26 PM

Maybe try http://codelite.org/ , I've used it to build OpenGL apps on Linux.

You get errors in included headers, so I would start by building a simpler app in whatever compiler you attempt to use, as in printf("Hello World"); return 0;

Then when that works add one line or function at a time until it doesn't work, and you at least know where it goes wrong.




#5133820 Confused by the VTune profiling results

Posted by Erik Rufelt on 23 February 2014 - 05:38 AM

The optimizer inlines, reorders and rewrites the code, so a line of C++ doesn't really have meaning anymore as the machine-code looks entirely different. The profiler tries to go backwards to find the C++ code that is responsible for execution time. It is probable that the generated code has everything reordered and the highlighted line is what causes any work to actually be done, so you can't really get anything more exact than adding 186 + 28 + 28 + 19 for the total loop cost.

You could go to ASM view to see what the assembly code looks like and get more exact readings.




#5133709 OpenGL text rendering anti-aliasing anomality

Posted by Erik Rufelt on 22 February 2014 - 08:38 PM

Your white-on-white text indicates that the the string texture has premultiplied alpha (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) and you draw it with (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) instead.




#5130863 Calling a virtual function, illegal call of non-static member function?

Posted by Erik Rufelt on 12 February 2014 - 12:53 PM

Should I instead pass an object which has its own work function (derived from a base class)?

Yes.

 

 

But then I would have to pass some interface to the object.

No.

DerivedWorkerThread *object = new DerivedWorkerThread("some interface");

CreateThread(...., WorkerThread::ThreadRoutine, (LPVOID)object);



#5130610 Win32 API and Petzold - still relevant?

Posted by Erik Rufelt on 11 February 2014 - 02:32 PM

To clarify, I don't think there's anything wrong with Win32, and I write almost everything I do on Windows with it (just because it's the one I learned once and haven't needed anything else). I just think that choosing it for needing to write "high-performance Windows programs" would be a bad reason.




#5130218 Direct2D DrawText low performace

Posted by Erik Rufelt on 10 February 2014 - 01:06 AM

Cache the strings or character-glyphs to a texture and draw your text with textured quad(s).

 

However, it shouldn't be that slow with D2D.. though it depends on how much text you draw and possibly other things. Approximately how many characters do you draw each frame, and how many ms does it add to your frame-time?

Does it make a difference if you draw 1 character or 1000?

Just to determine if the problem is in using D2D at all or in the work it does when drawing glyphs.




#5130108 atomic float add ?

Posted by Erik Rufelt on 09 February 2014 - 11:08 AM

You have to do a loop in some way, either a spin-lock mutex that waits to perform the add until no other thread is currently doing it, or do the add first and store the result with atomic compare and swap and retry on failure.

 

First way:

while( forever ) {
  if(atomicCompareAndSetFlag())
    break;
}

memory[...] += float;

clearTheAtomicFlag();

Second:

bool done = false;
while( !done ) {
  float old = memory[...];
  float new = old + float;
  
  // This will only return true if the old value hasn't been changed since it was read
  done = atomicCompareAndStore(old, new);
}

Both these reduce to the same problem, atomically changing a value in memory only if it is of a known value. This is called compare and exchange (or swap).

Such a method returns true if the value was equal to the expected value, and in that case the value has atomically been swapped to the new value.

Processors implement these atomically, and if two threads tries to do it at exactly the same time, one of them will always go first and succeed, while the other thread will return false and not change the value as it has already been changed.

 

std::atomic has compare and exchange, which you can use for that part.




#5130022 Aspect ratio vs. display ratio

Posted by Erik Rufelt on 09 February 2014 - 12:37 AM

I'd say that's the only way. Alternatively changing the amount of the world seen at a time if the game has scrolling, and fill the borders with the extra content instead, or something else that fits the game rather than a black border. For example if you use a vertical 3D FOV and the standard ratio is 4:3 then all wider displays will only show more content on the sides.




#5128236 Post processing

Posted by Erik Rufelt on 02 February 2014 - 02:15 PM

You probably need some restrictions, like are the colors always only those 3 colors?

Is it a magnification of a smaller image, like an image where each pixel is 16x16 instead of 1x1 or similar?

 

If it can be any image at all and you want to smooth hard corners, then it's pretty difficult and you need a very smart algorithm that searches the images.

If the original image is a small image that you want to magnify without making it look pixelated, then it's much easier.




#5128234 Converting triangle strip to triangle list

Posted by Erik Rufelt on 02 February 2014 - 02:07 PM

for(i = 2; i < indexCount; ++i) {

   bool odd = ((i % 2) != 0);

   listIndices.append(stripIndices[odd ? i : i - 2]);

   listIndices.append(stripIndices[i - 1]);

   listIndices.append(stripIndices[odd ? i - 2 : i]);

}






PARTNERS