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.


Topics - dabbertorres

Pages: [1]
1
DotNet / SFML.NET 2.4 Update
« on: October 03, 2016, 10:58:56 pm »
Branch: https://github.com/dabbertorres/SFML.NET/tree/2.4

I made a few architecture/style changes that I wanted to make sure were discussed and accepted/not-accepted before submitting a PR.

The major things:
  • When updating and debugging to make sure all is well, I realized that only the release CSFML dlls were being used, making debugging a little more annoying. I fixed this by adding a (internal) CSFML class to each module (ie: SFML.Graphics.CSFML, etc) that contains an internal const string with the name of the CSFML dll to be used. It's value is determined by an #if !DEBUG switch. This allows the CSFML debug dlls to be loaded in debug mode, and vice versa in release mode.
  • I moved the Context class to the Window module, to match up with SFML and CSFML (it was in Graphics). Side-Effects: had to be made public, which I felt was okay, due to Context being publically available in both SFML and CSFML. More uniform APIs, essentially.
  • Null-Conditional operator usage. This feature is tied to the C# 6.0 compiler, not to a .NET version. So it works when compiling SFML.NET for .NET 3.5 (with VS 2015, at least). I wasn't sure if the targeted support version was for Visual Studio (C# compiler) or .NET, hence my question on this.
  • Style-wise, SFML.NET used two different namespace styles:
namespace SFML
{
    namespace Graphics
    {
        ....
vs
namespace SFML.Graphics
{
    ....
    I normalized it all to the second, as I find it to be a nice feature (I'd like C++17 to get it).

Comments, questions, concerns?

2
SFML website / Small Typo
« on: September 29, 2015, 02:51:50 am »
Just an FYI:

"Activate of deactivate..."

Appears to go back to at least the 2.0 documentation!

3
Graphics / sf::Texture::update memory leak.
« on: June 29, 2015, 07:55:07 pm »
Spoke with eXpl0it3r on irc a bit about this.

Anyway, so I have a multithreaded application. Seems that calling sf::Texture::update repeatedly, leaks. Tracking it revealed that it's specifically sf::priv::WglContext::createContext which leaks, and it leaks a lot, very quickly (~42 MiB in 3 sec).
sf::priv::WglContext::makeCurrent also causes a leak, but no where near as much (~72 KiB in 3 sec).

Essentially, my application has a thread controlled by an SDK I'm using, of which I have no control over. It calls a function that I write, and waits until it returns. I have this function launch a thread to do some processing on what the SDK passed to me, and detach from it, so I can let the SDK's thread continue.

I'm taking the image it gives, me converting it to an sf::Texture, and then in another thread, drawing said sf::Texture with an sf::Sprite on a sf::RenderWindow.
I have mutexes around any access to the texture.

Minimal example:
#include <SFML/Graphics.hpp>

#include <mutex>
#include <thread>

int main()
{
        using byte = unsigned char;

        sf::Texture texture;

        std::mutex textureMutex;

        std::thread([&]()
        {
                while (true)
                {
                        sf::sleep(sf::milliseconds(32));
                        std::thread([&]()
                        {
                                std::lock_guard<std::mutex> textureLock(textureMutex);

                                std::vector<byte> bytes(640 * 480 * 4);

                                if (texture.getSize() == sf::Vector2u{0, 0})
                                {
                                        texture.create(640, 480);
                                }

                                texture.update(bytes.data());
                        }).detach();
                }
        }).join();
       
        return 0;
}
 

The sf::sleep is there to simulate time waiting for the call from the SDK.
Also, without it, SFML outputs this:
Code: [Select]
An internal OpenGL call failed in TextureSaver.cpp (38) : GL_INVALID_OPERATION,
the specified operation is not allowed in the current state
An internal OpenGL call failed in Texture.cpp (390) : GL_INVALID_OPERATION, the
specified operation is not allowed in the current state
An internal OpenGL call failed in Texture.cpp (391) : GL_INVALID_OPERATION, the
specified operation is not allowed in the current state
An internal OpenGL call failed in TextureSaver.cpp (45) : GL_INVALID_OPERATION,
the specified operation is not allowed in the current state
Failed to create an OpenGL context for this window:
and an abort() gets called from crtmbox.c for every set of the above messages. Though, that seems less relevant.

Also, here is the VS *.diagsession file from running VS' Memory Analysis tool (had to put it on my Dropbox, as it's too big).

Oops, forgot versions and hardware and stuff:

OS: Windows 8.1 Enterprise
CPU: i7-4790
GPU: Intel HD Graphics 4600 (tried default driver and latest driver)
SFML: 2.3 from Github, compiled myself

Given that it's an Intel GPU, I'm assuming this is probably a driver issue... I'd try another graphics card, but I don't think we have any here at work.

4
SFML projects / OO Sprite Batch
« on: January 20, 2015, 06:27:18 pm »
So, yesterday I thought to myself, ooh, having a sprite batch of sorts in SFML would be very nice, so I started on one, and in my ignorance failed to check the wiki/forum for results. Which... resulted in this:

https://github.com/dabbertorres/SwiftSpriteBatch

For those who don't know what a SpriteBatch is or does, it is essentially a container of vertices that all use one texture. So, rather than having 1 draw call per sf::Sprite, it allows you to have only 1 draw call for (almost) any number of vertices, or swift::Sprites, which turns out to be much faster.

It works very much like the sprite batch on the wiki, but rather than working based off indices, it uses classes.

It consists of 2 classes, a SpriteBatch class, and a Sprite Class.

Here's the example from the Github page:
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

#include "SpriteBatch.hpp"
#include "Sprite.hpp"

int main(int argc, char **argv)
{
    sf::RenderWindow window;

    window.create({800, 600, 32}, "SFML");

    sf::Texture texture;
    if(!texture.loadFromFile("ftlGrizzly.png"))
    {
        std::cerr << "error loading texture\n";
    }

    swift::SpriteBatch batch(texture, 2);

    swift::Sprite spriteOne(batch);
    spriteOne.setOrigin({spriteOne.getLocalBounds().width / 2, spriteOne.getLocalBounds().height / 2});
    spriteOne.setScale({2, 2});
    spriteOne.setPosition({400, 400});
    spriteOne.scale({0.5, 0.5});
    swift::Sprite spriteTwo(batch);
    spriteTwo.setPosition({400, 200});

    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            switch(event.type)
            {
                case sf::Event::Closed:
                    window.close();
                    break;
                default:
                    break;
            }
        }

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

    return 0;
}
 

The constructor of the SpriteBatch takes a sf::Texture, and the number of Sprites you would like to have. I went with locking the size because Sprites work with pointers, and if the memory needs to be relocated due to resizing, that invalidates pointers, which causes a whole bunch of issues.

There are 2 constructors for Sprite, both take the batch you want to add the Sprite to, and 1 takes a sf::IntRect to set as the texture rectangle.
Upon destruction of a Sprite, the vertices the Sprite used are kept, but all with position (0, 0) and color (0, 0, 0, 0). This effectively makes it non-visible, without invalidating pointers.
I tried to keep similar (if not the exact same) behavior as an sf::Sprite in regards to functions to call on swift::Sprite. In my testing, it seems to act the same, so here's to hoping it is truly that way. Hehe.

I'd love any feedback anyone has and am happy to answer any questions anyone may have!

EDIT: Should add that it uses C++11.

5
Window / XCB version does not create MouseButtonReleased events
« on: January 10, 2015, 10:29:39 pm »
OS: Arch Linux x86_64
g++: 4.9.2-20141224
SFML: master branch today

Example Code:
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>

#include <iostream>

int main()
{
        sf::Window window;

        window.create({800, 600, 32}, "SFML");

        while(window.isOpen())
        {
                sf::Event event;

                while(window.pollEvent(event))
                {
                        switch(event.type)
                        {
                                case sf::Event::MouseButtonPressed:
                                        std::cerr << "Mouse Button Pressed\n";
                                        break;
                                case sf::Event::MouseButtonReleased:
                                        std::cerr << "Mouse Button Released\n";
                                        break;
                                default:
                                        break;
                        }
                }
        }

        return 0;
}
 

Output:
Code: [Select]
[alec@alec-desktop-archlinux:~]$ ./a.out
Unable to get joystick attribute. Could not find USB device for joystick at index 0.
Unable to get joystick attribute. Could not find USB device for joystick at index 0.
Unable to get joystick attribute. Could not find USB device for joystick at index 1.
Unable to get joystick attribute. Could not find USB device for joystick at index 1.
Mouse Button Pressed
Mouse Button Pressed
Mouse Button Pressed
Mouse Button Pressed
^C

(Joystick output can be ignored for this post I believe)
So, it's creating two Button Press events per mouse click, rather than one ButtonPress and one ButtonRelease.

6
Window / Joystick Identification
« on: June 29, 2014, 11:02:47 pm »
I'm sorry if I'm missing something obvious, but, with this code:
#include <SFML/Window.hpp>
#include <iostream>
#include <string>

int main()
{
        std::cout       << "Joystick #" << 0 << " connected:\n"
                                << "Name:\t" << static_cast<std::string>(sf::Joystick::getIdentification(0).name) << '\n'
                                << "Vendor:\t" << sf::Joystick::getIdentification(0).vendorId << '\n'
                                << "Product:\t" << sf::Joystick::getIdentification(0).productId << '\n';
       
        return 0;
}
 

Command to compile: g++ main.cpp -lsfml-system -lsfml-window

I am getting an undefined reference to sf::Joystick::getIdentification(unsigned int).
The rest of the Joystick functions seem alright.

OS: Arch Linux x86_64
Kernel: 3.15.1
g++: 4.9.0-20140604
SFML: latest from github (d73418261b)

7
General discussions / Valgrind Conditional Jumps
« on: May 25, 2014, 08:18:19 am »
While debugging an application of mine, Valgrind threw several errors, some of which might be coming from SFML (Joystick stuff): "dependencies on uninitialized value(s)".

These may be false positives, but I was hoping someone else more familiar with this kind of stuff could have a look, just in case.

non-SFML programs do not have these errors, so it's not likely anything else.

System:
Arch Linux x86_64
Latest SFML sources

Minimal Reproduction:
Code: [Select]
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>

int main()
{
sf::RenderWindow window;
window.create(sf::VideoMode(800, 600), "SFML");

return 0;
}


Valgrind Output:
(click to show/hide)

Looking at SFML's code, I think the errors are here and here;

8
SFML projects / Embedded Console
« on: March 30, 2014, 01:57:42 am »
https://github.com/dabbertorres/EmbeddedConsole

This is a relatively simple embedded console in a RenderWindow. It takes advantage of C++11, especially in the use of std::function.

Current Features:
  • Arguments
  • returns
  • If you can write a function to do it, it can run it

It only supports showing one prompt, input, and output right now, but plans are in place to remedy this limitation.
Here's a screenshot:


And an example of usage:
#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>

#include "Console.hpp"

int main(int argc, char **argv)
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Console");

    sf::Font font;
    if(!font.loadFromFile("./data/DejaVuSansMono.ttf"))
        return 1;

    swift::Console console(500, 200, font);

    console.addCommand("mouse", [&window](std::vector<std::string> args)
    {
        if(args.size() == 2)
        {
            if(args[1] == "x")
                return "x: " + std::to_string(sf::Mouse::getPosition(window).x) + '\n';
            else if(args[1] == "y")
                return "y: " + std::to_string(sf::Mouse::getPosition(window).y) + '\n';
        }
        return "x: " + std::to_string(sf::Mouse::getPosition(window).x) + '\n'
        + "y: " + std::to_string(sf::Mouse::getPosition(window).y) + '\n';
    });

    console.addCommand("hello", [](std::vector<std::string> args)
    {
        return "Hello to you too!";
    });

    console.addCommand("exit", [&console](std::vector<std::string> args)
    {
        console.activate(false);
        return "";
    });

    while(window.isOpen())
    {
        sf::Event event;

        while(window.pollEvent(event))
        {
            switch(event.type)
            {
                case sf::Event::Closed:
                    window.close();
                    break;
                case sf::Event::TextEntered:
                    console.update(static_cast<char>(event.text.unicode));
                    break;
                case sf::Event::KeyPressed:
                    switch(event.key.code)
                    {
                        case sf::Keyboard::Up:
                            console.activate(false);
                            break;
                        case sf::Keyboard::Down:
                            console.activate(true);
                            break;
                        default:
                            break;
                    }
                    break;
                default:
                    break;
            }
        }

        window.clear(sf::Color::White);

        window.draw(console);

        window.display();
    }

    return 0;
}

9
SFML projects / SFML Input Manager
« on: March 28, 2014, 05:10:05 am »
Hi, I thought it'd be good to share something I made recently.

https://github.com/dabbertorres/SwiftInputManager

Here's the example of use on github:
#include <SFML/System.hpp>
#include <SFML/Window.hpp>

#include "KeyboardManager.hpp"
#include "MouseManager.hpp"

int main(int argc, char** argv)
{
    sf::Window window(sf::VideoMode(800, 600, 32), "SFML");

    swift::KeyboardManager keyboard;
    swift::MouseManager mouse;

    keyboard.newBinding("exit", sf::Keyboard::Escape, [&window]()
    {
        window.close();
    });

    mouse.newBinding("exit", sf::Mouse::Right, [&window]()
    {
        window.close();
    });

    while(window.isOpen())
    {
        sf::Event event;

        while(window.pollEvent(event))
        {
            keyboard(event);
            mouse(event);

            switch(event.type)
            {
                case sf::Event::Closed:
                    window.close();
                    break;
                default:
                    break;
            }
        }

        window.clear();

        window.display();
    }

    return 0;
}
 

Multiple uses of the same button are possible too.

An improvement that I'd like to make in the future though are for multiple keypresses, (Ctrl+A, etc).

Nothing too exciting, but in my own bigger projects I figured this would be a nice way of keeping all of the input handling of keypresses and such wrapped up. It works great for me, so I figured I'd share it, and if anyone is willing, share what they think of it. Thoughts on the quality of the code (I'd love feedback, I haven't shared much of my own, and as I'm pretty much self-taught...), etc, would be great!

Pages: [1]
anything