[SOLVED] RenderTexture offset when using RDP / OpenGL 1.1

[dweomer21]

See below for a very simplified mockup of my code.
The issue is when I run the code with a computer that only has OpenGL 1.1.
Running the app via Remote Desktop exhibits this behavior because RDP uses a OpenGL 1.1 lib.

As you can see in the attached screenshot "screenshot-GOOD.png", the blue rect displays correctly in the upper left corner of the window when run on session 0 with OpenGL > 1.1.
The next screenshot ("screenshot-RDP.png") is the result of me running the code in a remote desktop session.  The blue rect is positioned incorrectly, centered vertically in the window.
It's as if the offscreen rect coordinate system is different when opengl 1.1 is used.
Maybe there is an obvious answer to this problem, damned if I can't pin point what the heck is going on.

Anyone have any ideas?
I don't care about RDP really, but the hangup is on my co-developer's laptop, which only has 1.1, and exhibits the same behavior.  The game is just a text game, so we don't need any kind of OpenGL-accelerated graphics.  However, we have several TextArea sub-windows (the blue rect), whose positions are all skewed on his laptop, and messes up the proper display of our text, making development very difficult for him, to say the least :-).

One more detail: I get a bunch of errors/warnings in RDP in the console window when in debug mode.

An internal OpenGL call failed in Texture.cpp (146) : GL_INVALID_ENUM, an unacceptable value has been specified for an e
numerated argument
An internal OpenGL call failed in Texture.cpp (147) : GL_INVALID_ENUM, an unacceptable value has been specified for an e
numerated argument

Another forum posting states this is because GL_CLAMP_TO_EDGE is not supported in OpenGL 1.1.  However, it seems this is simply a warning, and I'm not sure if that is directly related to the offset rect issue I'm experiencing.

Thanks ahead of time for any advice!

#include "SFML/Graphics.hpp"
#include "SFML/Window.hpp"

#include <iostream>



int main(int argc, char** argv)
{

        sf::RenderWindow win;
        win.create(sf::VideoMode(1000, 500), "My Window", sf::Style::Close);
        sf::ContextSettings settings = win.getSettings();
        std::cout << "OpenGL Version: " << settings.majorVersion << "." << settings.minorVersion << std::endl;

        sf::Font m_font;
        if (!m_font.loadFromFile("LiberationMono-Regular.ttf"))
        {
                return 1;
        }

        sf::Text m_text;
        m_text.setString("Some String");
        m_text.setFont(m_font);
        m_text.setCharacterSize(15);
        sf::IntRect m_rect(0, 0, 800, 350);
       

        sf::RenderTexture m_offscreenRect;
        m_offscreenRect.create(m_rect.width, m_rect.height);
        m_offscreenRect.clear(sf::Color::Blue);
        m_offscreenRect.draw(m_text);
        m_offscreenRect.display();
       
        sf::Sprite m_sprite;
        m_sprite.setTexture(m_offscreenRect.getTexture());

        // Main event loop
        while (win.isOpen())
        {
                // Process events
                sf::Event event;
                while (win.pollEvent(event))
                {
                        switch (event.type)
                        {
                        case sf::Event::Closed:
                                // Window was closed, exit game
                                win.close();
                                break;

                        }
                }

                win.clear();
                win.draw(m_sprite);
                win.display();
        }

        return 0;
}
 

[Laurent]

SFML is not supposed to work in version 1.1 of OpenGL, it uses some 1.2 and 1.4 features. If you want to investigate, you'll have to check which functions SFML uses and the corresponding version of OpenGL that supports them, to eventually find what can cause this bug.

But why do you use SFML if all you want is to print text?

[dweomer21]

Yes, I had read about the fact that sfml does not support opengl 1.1, but I didn't actually think that would be an issue when we chose to use SGML.   I mean, 1.1?  That's ancient!  But apparently, still an issue now and then.
  I guess I was hoping that this was something simple that could be easily worked around.  What I'll probably do is check OpenGL version, and if 1.1, manually offset the rects, if I can reliably figure out what the offsets will be.

As to why we are using SFML when we only want to print text, well, we've gone back and forth on this.  First, we were using pdcurses, which worked for most, but not all, of what we wanted.  Honestly, the biggest reason we stuck with SFML is that it is such great API to work with.  It has a c++ interface, unlike pdcurses, and SDL, for that matter.
Another reason is to allow future ability to use sprites for other things, like the player's character portrait, and equip locations. 
Though the interface to our game is pure text, like the MUDs of old, the option to use simple graphics for other future features is appealing.

Thanks for the input.  I'll continue debugging on my end to see what else I can find.  If anyone else has any ideas, let me know.

--scott

[dweomer21]

Ugh, still stumped.  I've compiled SFML 2.1, and have attached it to the code's process, so I'm able to step through all of SFML's code.  Nothing is standing out as an obvious indication of trouble though, and of course, graphics are hard to debug because it's hard to look at the data structures etc, and know whether a specific call has done something screwy.

Debugging into OpenGL is beyond me, so I'm not sure what to do from here.

I realize I'm outside of the "supported" area of SFML, since it's OpenGL 1.1, but if anyone out there has any ideas or pointers, please do let me know!
Even a hack of a workaround would be great at this point.  I dread the thought of rewriting the game with a different MM library :-p

If you're the curious type, it's easily reproducible by simply doing a remote desktop session (MS Windows, in case it's not obvious) while running the code from my original post.
Anyway, fingers crossed, and thanks again!

[dweomer21]

Hot damn, I figured it out!
I actually think this is a bug in the SFML source, but please verify!

SGML source, V. 2.1, Texture.cpp, line 473:

matrix[13] = static_cast<float>(texture->m_size.y / texture->m_actualSize.y);

The above line integerizes the ratio of size to actualSize.  The result is cast as a float, but since both the operands are integers, it is guaranteed never to result in anything but a integer cast as a float.

For some reason, when I use OpenGL 1.1, the actualSize is always a power of two, which usually ends up being larger than the size.  For example, if I use a size of 30 x 30, the actualSize is 32 x 32.  Similarly, 200 x 200 has an actualSize of 256 x 256.  I changed the above line to:

matrix[13] = static_cast<float>(texture->m_size.y) / static_cast<float>(texture->m_actualSize.y);

and everything displays flawlessly!


I'm all set on my end -- I've recompiled the SFML code with the above  change.  If this turns out to be a bug, let me know if you'd like me to officially file one.

Cheers,
Scott

[Laurent]

I think it's already fixed in the current sources

[Nexus]

It's indeed fixed. That's why you should use the latest development version

[dweomer21]

Aha, very good!  I'm glad I was able to get this figured out on my end, but next time, I'll try the latest source before posting the problem.
Thanks again all!