Topics

1

Graphics / Crash on glDeleteFramebuffersEXT

« on: September 29, 2010, 04:29:17 pm »

Hey guys,
I know, this is my 3rd thread within a week or so, but as soon as I registered here, problems that I'm not able to solve myself magically started coming up...

Given the following code:

Code: [Select]

#include <SFML/Graphics>

int main()
{
if (!sf::RenderImage::IsAvailable()) return -1;
sf::RenderImage img;
        if (!img.Create(800, 600)) return -1;
} // Crash

As the comment already implies, my program crashes when calling sf::RenderImage::~RenderImage(). Mory exactly, the unhandled exception appears to come from the following piece of code in RenderImageImplFBO.cpp:

Code: [Select]

RenderImageImplFBO::~RenderImageImplFBO()
{
    // Destroy the depth buffer
    if (myDepthBuffer)
    {
        GLuint depthBuffer = static_cast<GLuint>(myDepthBuffer);
        GLCheck(glDeleteFramebuffersEXT(1, &depthBuffer));
    }

    // Destroy the frame buffer
    if (myFrameBuffer)
    {
        GLuint frameBuffer = static_cast<GLuint>(myFrameBuffer);
        GLCheck(glDeleteFramebuffersEXT(1, &frameBuffer)); // Crash
    }
}

Yet again, the comment indicates where the crash occurs.
Operating system is Windows 7 64 bit, SFML version is the latest SVN snapshot of 2.0, custom built binaries for 64 bit (the crash occurred under 32 bit, too, anyway). My graphics "card", if this is somehow relevant, is an Intel HD Graphics onboard chip.

I don't know if I made a mistake using sf::RenderImage or if I discovered an SFML bug. Maybe you can help me out

regards,
Debilo

2

General / MSVC++ 2010 64 bit libraries

« on: September 26, 2010, 02:27:38 pm »

Hey everybody,
I'm trying to build the latest SFML2.0 snapshot from source, using MSVC++ 2010 Express. All packages were flawlessly compiled, except for the graphics package. Well, it works out great when building static libraries, but as soon as I try to build a DLL, my linker complains about 15 unresolved externals in the Freetype library.
I've built all the extlibs for x64 by hand, including Freetype. But even when I use the extlibs shipping with the snapshot my linker still isn't content with it.

If anyone is wondering why I would do all this: The reason is a crash occuring when sf::RenderImage::~RenderImage() is called after invoking sf::RenderImage::Create().
I was able to trace it back to ig4icd32.dll, which is my graphics driver, so I assume that there might be some trouble with the 32 bit binaries, especially when OpenGL is concerned.
Maybe this is the wrong approach for fixing the problem. If so, I'd of course appreciate any help fixing this problem and thus making a x64-build unnecessary.

However, my competitive spirit was aroused by these nasty linker errors, and I guess it's not exactly a bad idea having native 64 bit binaries instead of the 32 bit ones (although this should not pose a problem, usually).

It'd be great if you can help me out once again,
regards,
Debilo


Edit: Update: I don't know how, but somehow the sfml2-graphics.dll was finally built with no problem. Unfortunately, I don't remember having made a change in the configuration, so it's still nebulous what caused this problem. Building sfml2-graphics-d.dll still produces the errors, though.

Edit2: Well, well, well...just made a 3rd complete new attempt, and it worked. Yet again I have no idea what I might have done to finally convince my linker to swallow it...
And since I'm just in the act of asking:
I wonder how to build sfml2-module.lib. I have *-s.lib, *-s-d.lib, *.dll and *-d.dll, but no *.lib, if you know what I mean. I built SFML for targets "Release Static", "Debug Static", "Release DLL" and "Debug DLL", which
are 4 in number (and I have 4 output binaries). Where is the rest? (I guess I'm just not seeing it at the moment)

Edit3: Yay, everything works fine, 64bit libs built successfully...

3

Graphics / Weird results with blur shader

« on: September 22, 2010, 06:28:15 pm »

Hey guys,
I'm currently trying to get into shader programming a bit. However, I encounter a problem which doesn't appear to make any sense to me.
The shader I'm using is the following:

Code: [Select]

uniform sampler2D tex;

void main()
{
    vec4 sum = vec4(0.0);
    vec2 offx = vec2(1.0, 0.0);
    vec2 offy = vec2(0.0, 1.0);
    sum += texture2D(tex, gl_TexCoord[0].xy - offx - offy);
    sum += texture2D(tex, gl_TexCoord[0].xy - offy);
    sum += texture2D(tex, gl_TexCoord[0].xy + offx - offy);
    sum += texture2D(tex, gl_TexCoord[0].xy - offx);
    sum += texture2D(tex, gl_TexCoord[0].xy);
    sum += texture2D(tex, gl_TexCoord[0].xy + offx);
    sum += texture2D(tex, gl_TexCoord[0].xy + offx + offy);
    sum += texture2D(tex, gl_TexCoord[0].xy + offy);
    sum += texture2D(tex, gl_TexCoord[0].xy - offx + offy);
    gl_FragColor = (sum / 9.0);
}It's a plain, simple box filter. I can't spot any mistakes in it, which might be owed to the fact that I'm lacking any experience with shader programming.

A minimal example for the C++-code is:

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow win(sf::VideoMode(800, 600), "Shader");
    sf::Image image;
    image.LoadFromFile("tulips.jpg");
    sf::Shader postEffect;
    postEffect.LoadFromFile("blur.sfx");
    sf::RenderImage renderImage;
    renderImage.Create(win.GetWidth(), win.GetHeight());
    renderImage.Clear();
    renderImage.Draw(sf::Sprite(image));
    renderImage.Display();

    sf::Sprite screen(renderImage.GetImage());

    while (win.IsOpened()) {
        sf::Event e;
        if (win.GetEvent(e)) {
            if (e.Type == sf::Event::KeyPressed && e.Key.Code == sf::Key::Escape) {
                win.Close();
            }
        }
        win.Clear();
        win.Draw(screen, postEffect);
        win.Display();
    }
}
Yet again, I can't see a problem with it. I tried to stick as close to the examples given here (http://www.sfml-dev.org/forum/viewtopic.php?p=11699) as I could. Nevertheless other approaches elicit just the same problem, namely:




I'm using the SFML2.0 binaries for Visual Studio 2010, someone uploaded them here in the forum a while ago. Operating system is Windows 7.
While writing this, it occurs to me that the graphics chip of my notebook is merely an Intel HD Graphics onboard-chip, but that should not pose a problem, I expect.

I hope some of you are able to spot the certainly quite obvious error. I can't, however, so thanks in advance.

Regards,
Debilo