OpenGL pixel format / context errors under windows x64

[jimmy]

Hi,

maybe someone has an idea whether this can be ignored, or if I am doing something wrong...

Following minimal program (standard green shape example):

#include <iostream>
#include <vector>

// OpenGL headers
#define GLEW_STATIC
#include <GL/glew.h>
#include <GL/wglew.h>

// SFML
#include <SFML/Graphics.hpp>
#include <SFML/OpenGL.hpp>



int main()
{

    sf::ContextSettings settings;
    settings.depthBits = 24;
    settings.stencilBits = 8;
    settings.antialiasingLevel = 0;
    //settings.majorVersion = 4;
    //settings.minorVersion = 5;

        std::cout << "Desktop Mode: " << sf::VideoMode::getDesktopMode().width <<"x"<< sf::VideoMode::getDesktopMode().height <<"x"<< sf::VideoMode::getDesktopMode().bitsPerPixel << std::endl;

    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "SFML works!", sf::Style::Default, settings);

    settings = window.getSettings();
    std::cout << "depth bits:" << settings.depthBits << std::endl;
    std::cout << "stencil bits:" << settings.stencilBits << std::endl;
    std::cout << "antialiasing level:" << settings.antialiasingLevel << std::endl;
    std::cout << "version:" << settings.majorVersion << "." << settings.minorVersion << std::endl;


        // OpenGL: check renderer
        std::cout << "OpenGL renderer:" << glGetString(GL_RENDERER) << ", vesion: " << glGetString(GL_VERSION) << std::endl;

        // Check available texture units:
        GLint texMaxCoords, texMaxComb;
        glGetIntegerv(GL_MAX_TEXTURE_COORDS, &texMaxCoords);
        glGetIntegerv(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, &texMaxComb);
        std::cout <<  "Max Textures/Combined Texture Units: " << texMaxCoords <<"/"<< texMaxComb << std::endl;




    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}
 

yields the following expected console output when compiled for Windows x86 (32 bit):
Desktop Mode: 1920x1080x32
depth bits: 24
stencil bits: 8
antialiasing level: 0
version: 3.1
OpenGL renderer: Intel HD Graphics 3000, version 3.1 - Build 9.17.10.4101
and the window with the circle is shown, of course.


When compiling for Windows x64 (64 bit), I also get the window with the (correctly drawn) circle.
In the console log, however, I see some additional (repeated) errors (output by SFML, I presume):
Desktop Mode: 1920x1080x32
Failed to set pixel format for device context: The pixel format is invalid.
Cannot create OpenGL context.
depth bits: 24
stencil bits: 8
antialiasing level: 0
version: 3.1
OpenGL renderer: Intel HD Graphics 3000, version 3.1 - Build 9.17.10.4101
Failed to set pixel format for device context: The pixel format is invalid.
Cannot create OpenGL context.

But everything seems to work fine, so I am confused...

Clearly this has something to do with 64 bits.

My environment is:
- SFML 2.3.1 (compiled from source by myself for x86 and x64, with Visual Studio 2010)
- Visual Studio 2010
- Windows 7 x64

Anyone any idea?

[binary1248]

What happens if you don't specify any context settings or try to change some of the values in your example?

[jimmy]

Good idea.

I commented out the context settings, and created the Window with only:

sf::RenderWindow window(sf::VideoMode(200,200), "SFML works!", sf::Style::Default);

Doesnt change anything in the outpu log, still showing "invalid pixel format".

I'll debug it into the exact place in sfml when the message is created, but currently I attribute this behaviour to either a Windows x64 or grpahics driver "peculiarity"...

[jimmy]

Ha, I guess I found it...

Somehow it seems I have managed to mess up my build environment:
using dependency walker on my generated exe, I get a warning about "modules with different cpu types".

All loaded DLLs show as 64-bit, except "comctl32.dll", which is loaded as a 32-bit version.

So, as usual: the problem is in front of the computer, and not inside...