Topics

1

SFML projects / [GUI] SFML backend for ImGui

« on: January 05, 2015, 07:51:23 pm »

Hello.

I've written an SFML backend for ImGui: https://github.com/Mischa-Alff/imgui-backends

ImGui is a bloat-free graphical user interface library for C++. It outputs vertex buffers that you can render in your 3D-pipeline enabled application. It is portable, renderer agnostic and carries minimal amount of dependencies. It is based on an "immediate" graphical user interface paradigm which allows you to build user interfaces with ease.

ImGui is designed to enable fast iteration and allow programmers to create "content creation" or "debug" tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal, and thus lacks certain features normally found in more high-level libraries.

ImGui is particularly suited to integration in 3D applications, fullscreen applications, embedded applications, games, or any applications on consoles platforms where operating system features are non-standard.

The backend uses SFML's vertex arrays (and GL_TRIANGLES) for rendering, so this should work on every platform SFML supports.

Usage is explained in the repository's SFML/README.md, or here: https://github.com/Mischa-Alff/imgui-backends/blob/master/SFML/README.md

What isn't implemented:

• Stencils. If the horizontal ImGui window size is too small, you'll still see transparent rectangles, as SFML does not provide support for clipping, and I haven't gotten around to working on a solution.

Cheers

2

General discussions / Clipboard support on Linux: A few hiccups.

« on: October 03, 2014, 06:55:38 pm »

Hello all!

I've been spending the last few hours determined to get clipboard support working on Linux. You can check my progress here: https://github.com/Mischa-Alff/SFML/feature/clipboard
(NOTE: I won't push my current progress with support for X11 until it's finished. There's no point in making tiny little commits for every two lines of code)

I'm not 100% familiar with everything, so this is essentially all to the extend of my understanding. I might be wrong. God, I hope I'm wrong, but using X is a land of sadomasochism, and if I were wrong, it wouldn't be sadomasochism anymore.

The problems

• To receive the clipboard's contents, you must request ownership of the clipboard, request its contents, and then wait for an event containing the property that points to the contents of the clipboard. (This is apparently to prevent uselessly sending data around all the time)
• Once you've obtained ownership of the clipboard, you need to store its contents and send them to the next client who requests the data, until someone else requests ownership. (According to ICCCM sec. 2.6.1.3, you must request ownership to request contents, but not everyone follows ICCCM)

The potential solutions

Obviously, the only solution to the second one is to stick the selection sending code in the sf::WindowImplX11::processEvent function.

The solution to the first one is slightly more complex: Most software waits for a selection_notify_event in the getClipboard function, therefore driving the CPU up to 100% and sending all possible events to the event handler until it reaches a selection_*_event, then processing that event and returning the data sent in the event. The problem with this method is that it will completely block execution until it gets to the event it wants, which might be never.

References:

• ICCCM sec. 2.6.1.3: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.1.3
• How GLFW does it (Look for "selection" and "clipboard"): https://github.com/glfw/glfw/blob/master/src/x11_window.c

I'm looking for recommendations as to how I should proceed on this, what would be best for the API, and what would be best for the codebase.

Please don't reply with your ideal vision of how the clipboard API should be, without any real advice. I'm trying to solve a problem that has been plaguing me for hours, and I would like a constructive discussion on how this could be solved.

Other than that, any help is appreciated and much needed. SFML needs clipboard support.
Thanks!

3

Graphics / Blocky font rendering

« on: September 06, 2014, 03:46:57 pm »

Hi everyone.

I'm using SFML compiled from source from the feature/xcb branch.
When trying to render text in a virtual machine running Ubuntu 14.04 (both x86 and x86_64), my code gives me blocky text:

int main()
{
    // Load a font for text rendering
    sf::Font font;
    if(!font.loadFromFile("resources/sansation.ttf"))
        return EXIT_FAILURE;

    // Create a text object using the font we've just loaded
    sf::Text text;
    text.setFont(font);
    text.setCharacterSize(16);
    text.setColor(sf::Color::White);
    text.setPosition(0.f, 0.f);
    text.setString(
        "SFMLSFMLSFML"
    );

    // Create the main window
    sf::RenderWindow window(sf::VideoMode(640, 64), "SFML");

    // Start the game loop
    while (window.isOpen())
    {

        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window: exit
            if (event.type == sf::Event::Closed)
                window.close();

            // Escape key: exit
            if ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape))
                window.close();
        }

        // Clear the window of previously drawn content
        window.clear();

        // Draw our text
        window.draw(text);

        // Finally, display the rendered frame on screen
        window.display();
    }

    return EXIT_SUCCESS;
}

 

Here's an image:


This is weird because I'm using exactly the same font as the OpenGL example, and the OpenGL example's text renders just fine

The same code works just fine on Windows (8.1 x86_64)

Any ideas/feedback/help is appreciated.

Thanks,
Aster

4

Graphics / [Solved] Error when building sfml-graphics on MinGW-w64 4.9.1 x86_64

« on: August 28, 2014, 10:03:38 pm »

Hi there.

I just reinstalled my compiler, and switched from MinGW 4.8.2 i686 to MinGW 4.9.1 x86_64.
I'm on Windows 8.1. My compiler is MinGW 4.9.1 x86_64 (64-bit). I'm using CMake 3.0.1.
I'm building with

$ git clone https://github.com/SFML/SFML && cd SFML
$ mkdir build && cd build
$ cmake .. -G"MinGW Makefiles"
$ make

All the modules build fine, except for sfml-graphics, which fails with:

Linking CXX shared library ..\..\..\lib\sfml-graphics-2.dll
cd /d C:\Users\Aster\Programming\temp\SFML\build\src\SFML\Graphics && "c:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\sfml-graphics.dir\link.txt --verbose=1
"c:\Program Files (x86)\CMake\bin\cmake.exe" -E remove -f CMakeFiles\sfml-graphics.dir/objects.a
c:\MinGW\x86_64\mingw64\bin\ar.exe cr CMakeFiles\sfml-graphics.dir/objects.a @CMakeFiles\sfml-graphics.dir\objects1.rsp
c:\MinGW\x86_64\mingw64\bin\g++.exe     -shared -o ..\..\..\lib\sfml-graphics-2.dll -Wl,--out-implib,..\..\..\lib\libsfml-graphics.a -Wl,--major-image-version,2,--minor-image-version,1 -Wl,--whole-archive CMakeFiles\sfml-graphics.dir/objects.a -Wl,--no-whole-archive ..\..\..\lib\libsfml-window.a ..\..\..\lib\libsfml-system.a "C:\Program Files (x86)\SFML\lib\glew.lib" -lopengl32 ..\..\..\..\extlibs\libs-mingw\x64\libfreetype.a ..\..\..\..\extlibs\libs-mingw\x64\libjpeg.a -lwinmm -lgdi32 -lopengl32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
CMakeFiles\sfml-graphics.dir/objects.a(GLExtensions.cpp.obj):GLExtensions.cpp:(.text+0x21): undefined reference to `glewInit'
CMakeFiles\sfml-graphics.dir/objects.a(GLExtensions.cpp.obj):GLExtensions.cpp:(.text+0x43): undefined reference to `glewGetErrorString'
c:/MinGW/x86_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles\sfml-graphics.dir/objects.a(GLExtensions.cpp.obj): bad reloc address 0x0 in section `.pdata'

I don't have GLEW installed separately from SFML (I usually do, but I installed SFML before GLEW this time), but this shouldn't be important since SFML ships with the "right" version of GLEW.

Is this issue MinGW x86_64 specific? How can I fix it without installing GLEW manually?

Cheers,
Aster

5

Window / Alt-F4 not sending sf::Event::Closed to sf::Window

« on: July 17, 2014, 09:10:58 pm »

Hi there.

Upon testing my game on Linux, as it has no menu yet, the only way to close it is using Alt-F4.
This method works perfectly fine on Windows with both fullscreen and windowed mode..
.. But on Linux, it only works in windowed mode. With fullscreen mode, Alt-F4 won't send the sf::Event::Closed event, and Alt-Tab won't change the window's focus.

I've tested this on Archlinux with GNOME 3, GNOME Classic, and XFCE.
I'm using SFML from latest git.


Here's some example code:

#include <SFML/OpenGL.hpp>
#include <SFML/Window.hpp>

int main()
{
        sf::Window window{sf::VideoMode::getDesktopMode(), "Whee", sf::Style::Fullscreen};

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

                glClear(GL_COLOR_BUFFER_BIT);
                window.display();
        }

        return 0;
}

 

The OpenGL stuff (include, glClear and window.display()) is optional, but I put it in there so that you can clearly see the fullscreen window.
The only way for me to exit this program or return to my desktop is to switch to a different TTY and pkill it.


Any help is appreciated.
Cheers.

6

Feature requests / Replace Xlib with XCB

« on: April 24, 2014, 12:01:15 am »

So, I've been adding clipboard support to SFML, and Windows was trivial.

Then came Xlib.
Xlib is bad. It hasn't been updated in 12 years.
It's complicated, and slow, and makes you want to throw grapefruit at strangers.

But! XCB exists.
It's more up-to-date, doesn't suck as much.
It's still X, which is a downside.
But let's look at the bright side, it's already implemented, but this PR is a year old, and nothing has been decided.
It's probably out of date, but if the SFML dev team would should a glimmer of interest, I'm sure it would be updated in a single day.

SFML needs to be ported to XCB, it's a question of modern code, and it'll probably even be faster as such.
So yeah, SFML claims to be modern, but it uses a 12-year old, outdated backend.

(Also, newlines, newlines everywhere!)

7

Window / SFML Windowing Does Not Work With Xinerama

« on: November 01, 2013, 04:31:07 pm »

Hello,

I just switched from the open source nouveau drivers to nVidia's official nvidia drivers. I tried launching an SFML app, and I get this:

Failed to use the XRandR extension while trying to get the desktop video modes
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  151 (NV-GLX)
  Minor opcode of failed request:  4 ()
  Resource id in failed request:  0x1c00001
  Serial number of failed request:  48
  Current serial number in output stream:  48

The reason for this is clear; XRandR is failing. It's failing because I use the nvidia driver, which disables XRandR in favor of the more flexible Xinerama, since I have a rather complicated GPU/display setup.

I understand the fix: "Use the open-source drivers!!!" This, I might consider, but not everyone will. I can't just tell all of my Linux users "Oh yeah, if you happen to use the faster, more complete nvidia drivers, you can't run my software!". I don't think anyone wants to do that.

I'd make this a feature request, but for now I want to know if there's a workaround, or if it's something that needs to be fixed.

8

SFML projects / Looking for a Few Bored People

« on: September 04, 2013, 01:27:16 am »

Ladies, Gentlemen, Hello!

I hope I'm not bothering the SFML forum with this post too much, but this is pretty much the only place I wanted to post in.

NOTE: I'm in a weird mood upon posting this, so please read this in an English accent. Thanks.
NOTE 2: I'm seriously not expecting anybody to answer. It's 1 AM or something and I really want to write a Gameboy emulator for some reason.


Let me commence.
I am searching for a few fine fellows to work with me on several splendid projects of various lengths. Most of these projects make use of the wonderful SFML library, and all are written in the magnificent C++. These aforementioned fellows must be serious in their work and motivated to collaborate on a project. Most of these programming journeys shall be made open and free to the public, although not necessary, but encouraged. In order to allow the reader to imagine which magical wonderlands these projects shall board, I will list some of the topics that have entered my mindset;

• Emulators! Splendid, joyous emulators, of various devices. It would be most enjoyable to start with a Gameboy emulator, to get things spiffy!
• Games! Yes. All sorts of games. I have many ideas, most of which are too verbose to list here, I may specify later on.
• Glorious software of all types, I, for one, am interested in all types of development!

If you, the spiffing reader are still interested, let me introduce my very self:

• I have been developing with C++ for 26 Lunar Phase Cycles (2 years).
• I have written and aided in the development of a few games. My GitHub.
• I have been practicing the use of a piano for over 90 Lunar Phase Cycles, and cello for 3 Lunar Phase Cycles. This makes me proficient in the production of music for entertainment purposes.
• I am always highly contactable and I favor communication and planning over the most lousy do-what-you-want attitude that is the bane of software.
• I can communicate in both French and English, making speech easier if you are from the other side of SFML.

I shall thus top this post off with "prerequisites" for the fine fellows who shall perhaps be working with me. It shant get a list because they happen to be simple and not to be taken too seriously. Anyways, it would be preferable if you were serious about the project being worked on, and did not leave a few weeks former to starting. It would also be preferable if you happened to be Human.


And so, that finished off my wonderful request. I wish you all a great day.
Aster

9

Feature requests / Getting bounds for sf::View

« on: September 02, 2013, 09:38:38 am »

Hiya,

In most of my games involving an sf::View, I write a little function that looks somewhat like:

sf::FloatRect getViewBounds(const sf::View &view)
{
        sf::FloatRect rt;
        rt.left = view.getCenter().x - view.getSize().x/2.f;
        rt.top  = view.getCenter().y - view.getSize().y/2.f;
        rt.width  = view.getSize().x;
        rt.height = view.getSize().y;
        return rt;
}
 

As you can guess, it returns an sf::FloatRect containing information on the bounds of a given sf::View. This function has many uses, such as checking if something is on-screen or not using sf::Rect's very useful .contains() and .intersects() functions.

My feature request is to ask if such a thing could be stuck into sf::View by default, as it has many uses and it's pretty essential for game development, in my opinion.

Thanks,
Aster

10

General / Menu Systems in Games

« on: August 08, 2013, 07:55:15 am »

Hi all,

I've been getting more and more interested in doing things The Right Way™, and this time, I want to write a good menu/status system for my game. I want something modular, maintainable, and more importantly, I want to write it myself.

Essentially, what I'd want to write is a system like this:

• Main menu, with: Play, Level editor, Options, Quit.
• Both play and level editor will be making use of the game's engine, and they'll be dynamic.
• In both, I'll need a way to summon the "pause" menu, and in the level editor, I'll probably want some keyboard input in a side-menu.
• Options will do what every functional options menu has always done.
• Quit will obviously quit.

That should give a simple idea as to what I'd like to do.
Since I've never really done such a thing, and a lot of the people here are better at this than I am, I'm asking for a few tips on how to write such a thing in a clean way, and not diving into a doom of inheritance and possibly explosions.

Keep in mind, I'm not being lazy and asking for ready-made implementations. I'm just asking for the best way to go about a clean and modular menu system. (Buttons and things have pretty obvious implementations, but if there's some extra hax involved for some reason, please do mention it. )

Thanks!
Aster

EDIT: Damn, I swear I had posted this in the general discussions thread.. Any chance of it being moved?

11

SFML projects / [SFML Game Jam #1] Lumenumbra

« on: August 06, 2013, 03:22:30 am »

After 72 hours of work, three shirts, one night of oversleeping, many cups of coffee, lots of bug fixing, stress, and "support" from some of y'all..

I present to you... Lumenumbra!

Version:0.2 Beta

Gameplay:
Lumenumbra is a minimalistic lighting-based 2D game.
You play as a source of light. Making use of the shadows you create to get around the world.
Some objects can be seen, and create shadows, but others can only be seen in the shadows.

Features:

• The levels are written in JSON, this makes it very easy for users to add their own levels.
• Awesome lighting effects make the game look 3D!
• Two levels of awesomeness!

Screenshots:



Downloads:

• Windows (Win32)
• Linux x64

Links:

• My Website!
• My GitHub
• Lumenumbra's GitHub repository

Thanks for reading! Hope you have fun!

12

General / SFML not linking properly

« on: August 02, 2013, 10:50:50 pm »

Good day,
I switched to SFML 2.1 today (which was apparently a bugfix). All I did was essentially a drop-in replacement of the SFML files (include folders, .a files and .dll files).

Before describing my error, I'm specify that I'm on Windows 7 x64 with MinGW 4.8.1 DW2 x32.

So, I compiled myself, replaced the files, then went ahead to compile my jam project, only to get

C:\Users\Aster\AppData\Local\Temp\ccXM3Mrx.o:main.cpp:(.text+0x9c): undefined reference to `_imp___ZN2sf6SpriteC1Ev'

For every single SFML thing I use, I get this error. From every module.

I compile with this:

g++ -std=c++11 -Wall -lsfml-graphics -lsfml-window -lsfml-system main.cpp Game/Game.cpp -osfml-jam

I've tried using SFML's precompiled binaries. I upgraded MinGW from 4.8.0 to 4.8.1. I rebooted.

I have no idea why this is happening, any help would be greatly appreciated. Thanks!

13

SFML projects / "Triangle Super" -- A fast-paced minimalist game

« on: May 04, 2013, 11:03:02 pm »

Ladies and Gentlemen; I present to you, Triangle Super!

        Triangle Super was a game I intended to submit for the 26th Ludum Dare, but do to a few issues, I didn't get the chance to submit. However, I'm not going to just drop my first ever piece of standalone software just because some pretty stupid reasons, so I finished and polished the game, and here it is!

        The idea came to me, after I learned that the theme was "Minimalism". After having contributed to Open Hexagon, that game's concept still affects my thinking in the most wild of ways, so I obviously wanted to make a "reverse" clone. Triangles taking their revenge. However, I kind of changed my mind half way, and this came out.

        The gameplay is very simple, you control a hexagon using a mouse, and you're trying to avoid incoming triangle-delta-things, headed towards you in random directions. Use space to take screenshots.

        To aid myself in the fabrication of this marvel, I have used Thor 2.0 and, obviously, SFML. Other than the font, the rest of the game was entirely produced by me (music as well), and Grimshaw/DevilWithin has helped me with learning how to use trigonometry in my code. Thanks to eXpl0it3r as well, for notifying me of Arial.tff's copyright issues, and replacing it for me.

So, let's get on to where you can possibly find my prized work of art..

• The source repository can be found on Github.
• The Windows download can be found here.
• Linux builds: 64bit Linux and 32bit Linux.
• If someone wants to compile an OSX build for me, that'd be great!

That's all I have to say as of now.. I hope you like it!
I do plan on improving the music when I get the time, it's on my itinerary.

14

Feature requests / Native Wayland Support on Linux

« on: March 06, 2013, 02:10:56 pm »

Hello all.

Just recently, Wayland has started being shipped with the mesa drivers on Archlinux. I'm seriously considering the move, since X is older than I am, and hasn't changed (much) since my birth.

For those of you who need some enlightenment on the subject, here's a recent video of Daniel Stone, a developer of Wayland, explaining everything (get some popcorn, it's a long one):
http://youtu.be/RIctzAQOe44 .

Now, I'm not entirely sure whether SFML works on Wayland or not. It should, since Wayland can interface with X programs. But since Wayland is more or less "the future" compared to X, I think SFML should be written to support it as well.

I'm also aware of Ubuntu's (Canonical's) new fabulous idea, Mir. I don't support the project at all, but I don't have much against it. My request is entirely for Wayland, and I'd like to prevent flamewars on the two.

Thanks,
Aster

15

General discussions / Let's Create an sf::Pig!

« on: December 15, 2012, 09:36:15 am »

Hi y'all!
I'm currently doing the Ludum Dare, using C++ and SFML (because SFML is just so cool for this stuff), and I realized that SFML did not have an sf::Pig. As my game is about a pig, this made me sad.  So I suggest the easter-eggy implementation of an sf::Pig! (Complete with texture and everything)

usage:

sf::Pig Johnny( sf::Pig::Personality::Nice, true); // creates a little piggy with attitude "nice" and active = true.
Johnny.runAround();
Johnny.Oink();
Johnny.Fart(sf::Pig::fartType::loud);
if(Johnny.shootGiantLaserBeamOutOfMouth())
{
    Johnny.Slaughter();
}
else
{
    Johnny.Explode();
}
 

I find this a genius idea. Thanks for reading!

(Yes, I AM kidding, although it'd be pretty cool to have an sf::Pig)