Messages

1

General / sf::Text Won't Render After glBindVertexArray()

« on: November 22, 2015, 10:26:08 pm »

Hi there!

This is a question that probably has a really simple answer, as to what I've been reading it has to do with SFML having it's own VBO, VAO, or whatever it is, and I need to use the corresponding glDelete function with it, but I've tried a few different ways with no success.

The way my code is now, the text renders for a second and then goes blank the second that glBindVertexArray(VertexArrayID); is called.

Here is the relevant code:

void AMEngine::Render()
{
        MainWindow->pushGLStates();
        MainWindow->draw(sText);
        MainWindow->popGLStates();

       
        Shader::setShader(&shader, &transform);
       
        GLuint VertexArrayID;
        glGenVertexArrays(1, &VertexArrayID);
        glBindVertexArray(VertexArrayID);
        static const GLfloat g_vertex_buffer_data[] = {
                  - 1.0f, -1.0f, 0.0f,
                    1.0f, -1.0f, 0.0f,
                    0.0f, 1.0f, 0.0f,
                };
       
        // This will identify our vertex buffer
        GLuint vertexbuffer;
        // Generate 1 buffer, put the resulting identifier in vertexbuffer
        glGenBuffers(1, &vertexbuffer);
        // The following commands will talk about our 'vertexbuffer' buffer
        glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
        // Give our vertices to OpenGL.
        glBufferData(GL_ARRAY_BUFFER, sizeof(g_vertex_buffer_data), g_vertex_buffer_data, GL_STATIC_DRAW);
        glEnableVertexAttribArray(0);
        glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
        glVertexAttribPointer(
                0,
                3,
                GL_FLOAT,
                GL_FALSE,
                0,
                (void*)0
                );
       
        glDrawArrays(GL_TRIANGLES, 0, 3);
        glDisableVertexAttribArray(0);
        glDeleteVertexArrays(1, &VertexArrayID);
       
}

Again I'm probably missing something simple as understanding what's going on is very difficult for me, so I apologize if it's simple.

2

Network / How Mature is the Network Module?

« on: November 02, 2015, 01:38:26 am »

This is really a general question. But basically I'm working on learning the fundamentals of a game engine implemented with SFML (purely to learn) and I wanted to know SFML's versatility with networking. Do you recommend using SFML's network module exclusively, or is there another more mature networking library that's lightweight and verbose?

I've only really experimented with networking a few times with a couple of different libraries, and it's not something I know a lot about, but I'm much more confident with it after working on a multiplayer game for some time now. Basically I'm looking for something that's both simple to work with yet expandable. SFML has exceeded my expectations with that, but I wanted to get some input from somebody who's worked with it.

3

General / Re: Threads To Take Screenshots Seamlessly?

« on: October 31, 2015, 05:23:44 pm »

It worked fine for me in debug but maybe your compiler adds a lot of debug stuff to threads so make sure to test it in release mode.

Ah, that's a good idea. Got to setup my release libraries and I'll try that. I also wonder if it has any impact that I'm using the 64 bit version at the moment.

Edit: Tried release, didn't seem to do much. I'm using VS2013. Dunno :/

4

General / Re: Threads To Take Screenshots Seamlessly?

« on: October 31, 2015, 07:17:56 am »

Also you need to make sure that the texture size is at least as big as the window size, otherwise you'll get a crash.

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

int main()
{
    sf::RenderWindow window({1920, 1080}, "Screenshot!");
    sf::Texture tex;
    tex.create(1920, 1080);
    sf::Clock cl;

    while(window.isOpen())
    {
        sf::Time dt = cl.restart();
        window.setTitle(std::to_string(1.f/dt.asSeconds()));

        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
            else if(event.type == sf::Event::KeyPressed)
            {
                tex.update(window);
                sf::Image img = tex.copyToImage();
                std::thread t([img]() {
                                 img.saveToFile("test.png");
                             });
                t.detach();
            }
        }

        window.clear(sf::Color(0xFF0000FF));
        window.display();
    }
}

Yeah, heh, I noticed that when I tried this after it was mentioned, but it's still not seamless. It's better, but not seamless. There is a very noticeable half a second pause when it's done. What the crap do you have, a dual Xeon with a GTX Titan, and an enterprise grade SSD? O.o

5

General / Re: Threads To Take Screenshots Seamlessly?

« on: October 31, 2015, 01:24:06 am »

Oh I love the enthusiasm. A native SFML feature would be great since it is a function so many people look for.

Anyway, I appreciate the help! If only I knew how to perform a GPU copy of the framebuffer. I searched for it, a lot. Got lot's of lovely information about VBOs using GLEW for extensions and so on. Oh well, not my specialty. I love how I can work with an engine and not even have the slightest clue of what I'm actually doing and make something work. Heh.

It's funny, I'd been using Quaternions and whatnot and didn't know how they worked at all until like, yesterday. Can't wait to keep messing with this stuff and figure out how things like Matrices work how they interact with other things. Really wish they taught stuff like that in my high school.

Ah... Well sorry for the off-topic tangent, this has just been a cool learning experience.

6

General / Re: Threads To Take Screenshots Seamlessly?

« on: October 30, 2015, 06:19:07 pm »

Transferring data from VRAM to RAM shouldn't take very long and it's suggested to not do that in a separate thread since OpenGL itself isn't multi-threaded. Instead once you get your sf::Image, you could spin up a thread to save it to disk, which is usually the slow processes. But using a thread is only useful if you actually don't call join() in the main thread, otherwise your main thread will just wait and you don't get anything, but in fact lose time, since thread creation and spin-up has its overhead as well.

Ah thanks for that, I've never really used threads, but now I know what .detach() is for. But there is no doubt that the RenderWindow's capture() slows it down. Saving the file might, but if I just don't save it, there's still a pause or a point where the screen kind of locks about a second regardless of if I use a thread or not.

And I'm not running on ancient hardware either. Actually most of my hardware is completely brand new with Intel's new Skylake CPU, with an SSD and the whole works. The only "old" thing I have is a 660 Ti for a graphics card.

Anyway I sidetracked there, basically RenderWindow's capture is just plain slow. Is there any other way to do it? What about rendering using sf::Texture and copying it to an image or does that not work right with OpenGL or would it be just as slow?

7

General / Threads To Take Screenshots Seamlessly?

« on: October 30, 2015, 11:00:06 am »

Hi there! I'd been looking at a tutorial to make a simple screenshot function, and it had suggested to use threads so game performance wasn't impacted. Currently I'm using the C++11 threads. I was having a terrible time trying to get this to work, but found that you have to disable the OpenGL context when dealing with a window in another thread with the RenderWindow's setActive().

The problem with this, at least as I understand it, I have to wait for the function\thread to be done so I can set the window active again and therefore I suffer from the 1-2 second pause of taking a screenshot that I was trying to avoid because the capture() is slow (according to the SFML wiki)

Is there any way around this?

To give you an idea of what I have:

void AMEngine::ScreenCapture()
{
        sf::Image screenshot = MainWindow->capture();

        time_t epoch_time;
        struct tm tm_p;
        errno_t err;
        epoch_time = time(NULL);
        err = localtime_s(&tm_p, &epoch_time);

        //ToDo: Improve screenshot name formatting
        std::string screenshotName = std::to_string(
                tm_p.tm_mday) +
                "-" +
                std::to_string(tm_p.tm_mon) +
                "-" +
                std::to_string(tm_p.tm_year) +
                " " +
                std::to_string(tm_p.tm_hour) +
                std::to_string(tm_p.tm_min) +
                std::to_string(tm_p.tm_sec);

        screenshot.saveToFile("screenshots/" + screenshotName + ".png");

        MainWindow->display();
}

void AMEngine::Update()
{
        sf::Event event;
        while (MainWindow->pollEvent(event))
        {
                if (event.type == sf::Event::Closed)
                        m_bIsRunning = false;
                if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
                        m_bIsRunning = false;

                if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::F5)
                {
                        MainWindow->setActive(false);
                        std::thread tSC(&AMEngine::ScreenCapture, this);
                        tSC.join();
                        MainWindow->setActive(true);
                }

        }
}

Or is this a pipe dream?

I tried searching about screenshots with threads, but ironically, there's a thread on this forum called the Screenshot Thread. XD

8

General / Re: Crash on Exit Passing RenderWindow to Class

« on: October 26, 2015, 06:15:35 pm »

Wow, I never expected to come back here and see a full blown debate about the use of global variables. I apologize for kind of deferring from the original topic.

Tell that to the makers of Valve's Source Engine. Tons of globals there, that's kind of where I was getting some inspiration from. I've been programming under the Source Engine for quite a while now. But there's tons of global variables, externs all over the place, and whatnot.

The programmers at Valve know what they are doing so I'd say its safe to give them a bit of an exception here 

Typical fallacy: argument from authority

The fact that one big company does something may be the result of various reasons, including historical or political ones -- in short, you don't know the backgrounds. Assuming that it's purely because of better design is risky, and applying the same reasoning to your own code, which has completely different preconditions, is a mistake.

This from a purely logical standpoint. There are objective arguments why global variables are problematic if used too often, see for example here. Please inform yourself carefully and be skeptic what you hear, instead of just thinking "ah, the big guys do it, so it must be right". Most progress in C++ during the decade of C++98 has been made by guys who questioned the common old ways of doing things -- and that was a huge step forward, considering that the language hasn't changed at all until 2011.

Tip: in C++, it's usually better to look at how people don't do things

It may be related with topic starter issue and may not be related.

Because of that it would have been nice to open a different thread and post a link here, so the original discussion can go on uninterrupted. Don't open a thread now -- but thanks for reproducing the issue

Oh I was never defending what they do, by God I hate the Source engine, yet I now program with it almost every day. I hate it, I hate it, I hate it. Also the Source engine was built off of old Quake engines and whatnot. I just find it interesting that programming under this for so long has influenced my coding style. I don't think I ever made a single global variable when coding under Unity, but that's C# not C++.

Agh, I'm doing it again. Sorry for the off topic rant, feel free to lock the topic, I just really get into these types of discussion, even if it is off topic.

9

General / Re: Crash on Exit Passing RenderWindow to Class

« on: October 26, 2015, 12:59:03 am »

I'll go further. Don't ever make ANY global object. There is rarely a situation where it's valid.

Tell that to the makers of Valve's Source Engine. Tons of globals there, that's kind of where I was getting some inspiration from. I've been programming under the Source Engine for quite a while now. But there's tons of global variables, externs all over the place, and whatnot.

Though it does kind of reek of C in terms of methodology. Anyway, I think globals are okay, but you have to base your program around what you have to work with I guess. Haven't messed with SDL in a while, but I could do the whole global variable thing there. Although I really like SFML with its more C++ feel.

10

General / Re: Crash on Exit Passing RenderWindow to Class

« on: October 25, 2015, 05:53:38 pm »

I figured it out.

Ugh... Well to anybody else, basically I had an sf::Font declared globally, which I knew is a big "no-no" for creating Windows, but didn't realize that it also applied to other objects.

Moral of the story, don't make any SFML related classes global, ever, period.

11

General / Crash on Exit Passing RenderWindow to Class

« on: October 25, 2015, 05:49:54 am »

Hi there!

I've researched this issue and tried various things learning that the RenderWindow is non-copyable and all that fun stuff. But, I swear I see other programs doing this that don't have an issue, which I'm guessing I'm simply missing a step.

At the moment, I'm running under Debug mode with the debug libraries linked statically. Basically I have a Camera class with a function DrawHUD that works like so:

void Camera::DrawHUD(sf::RenderWindow &window)
{
        testText.setString("Hi! I'm a HUD!");
        window.pushGLStates();
        window.draw(testText);
        window.popGLStates();
}

Basically it all comes down to window.draw() is where it ultimately crashes. Well, that's sort of true, because it only crashes when the program exits, but only if that draw() is called from inside my class.

When it crashes it goes to the file crtexe.c and points to the lines here:

            if (has_cctor == 0)
                _cexit();

and then proceeds to give me the Unhandled Exception error with ntdll.dll.

It doesn't matter if I pass it as a pointer, and I can't pass it directly because RenderWindow is noncopyable to avoid duplicate windows. So am I just stupid, or?

For more code context, this is basically how it works:

Camera mainCamera;
//...
//WHILE LOOP HERE
mainCamera.DrawHUD(window);

Any ideas? By the way, that testText thing has all the other stuff setup in the class' constructor, but where I put that seemed to not make any difference anyway.