Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dweomer21

Pages: [1]
1
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!

2
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

3
Graphics / Re: RenderTexture offset when using RDP / OpenGL 1.1
« on: March 30, 2014, 03:22:04 am »
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!

4
Graphics / Re: RenderTexture offset when using RDP / OpenGL 1.1
« on: March 29, 2014, 10:53:01 pm »
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

5
Graphics / [SOLVED] RenderTexture offset when using RDP / OpenGL 1.1
« on: March 29, 2014, 09:33:32 pm »
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;
}
 

6
Aha!  I got it to work as fallahn suggested!  I needed text scrolling as well, and I was a little discouraged by what I thought would be a huge sloppy hack, but it turned out to not be that bad.  I alter the View to scroll, and I think this makes it workable. Yay, now I can continue using SFML.

Thanks again for you time.

7
Thanks to both of you. 
I'm implementing a MUD-like console game, which is, unfortunately, looking more and more like it is not a good match for SGML, since it mostly deals with text.  It's kind of a hard match for any graphics lib, however.  I've been using pdcurses, but the problem there is that the event system is blocking, so I can't poll for keyboard events (not to mention that we'd like to use sprites for inventory items).
Anyway, that's just a little background on where I'm coming from. 
I've tried out Allegro, SGML, and SDL, and I like SGML the best so far... but I may have to just wait to use it for my next project, which will hopefully get into the graphics realm.

Thanks again, and keep up the excellent work!

8
I'm new to SFML, and am hoping that I'm just missing something obvious.
I'm trying to render text to a rect on the screen, and I want the rect to act like a clipping mask.  So, if I have a 30-line paragraph in my sf::Text object, for example, I'd like to be able to render it to the rect so that it does not overflow the bounds of the rect. I don't care if it still renders offscreen (in other words, I don't need the rect to wrap text or anything) -- I just don't want to see any of the text that would show up outside the rect.
Is this possible?  I've been fighting this for two days now, and it's GOT to be because I don't know what I'm doing!  Maybe rendering the text as a texture or sprite or something?
Thanks for any pointers.  And sorry for my ignorance :-)
--scott


Pages: [1]
anything