Topics

1

Feature requests / (CMake) Make BUILD_SHARED_LIBS=OFF by default

« on: April 14, 2021, 12:16:18 am »

I propose to not set  BUILD_SHARED_LIBS to "OFF" by default (except for platforms where static linking is not supported).

Some projects using CMake are building shared libraries which can be convenient for some people, but doesn't really follow what "BUILD_SHARED_LIBS" is meant to do.

See the docs: https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html

If present and true, this will cause all libraries to be built shared unless the library was explicitly added as a static library.

This makes "BUILD_SHARED_LIBS" opt-in flag. But currently I need to "opt-out" from building shared libraries, which is not convenient, as I expect that static libs are built by default, which is the convention that a lot of CMake projects follow.

2

Feature requests / XInput support

« on: October 10, 2019, 02:45:15 pm »

Supporting XInput on Windows will allow use to have the following:
* Have triggers be independent axes instead of one
* Support vibration (not sure if SFML needs to have API for that or it users would be able to get some state out of SFML to handle that using XInput directly)

Xbox 360 and Xbox One amount to ~64% of gamepads used on Steam, so I think that this feature is necessary to have to be able to handle Xbox 360/Xbox One gamepads correctly.

Also, some gamepads (e.g. Logitech ones) also have a switch from DInput to XInput, so Xbox gamepads are not the ones who rely on XInput to work.

3

SFML projects / Tomb Painter - Game Boy inspired game about painting tombs

« on: June 09, 2019, 11:12:04 am »

Site: https://eliasdaler.github.io/
Developer: Elias Daler - everything
Dev logs: https://eliasdaler.github.io/tags/#Tomb+Painter
Twitter: @eliasdaler
Platforms: PC, Mac, Linux
Start of development: August 2017
Release date: 202X (let's hope it's not 203X)

Hello, everyone! My name is Elias Daler and I'm making a game called Tomb Painter.
You may know me from Re:creation (which is now in hiatus), and here I am with another game.

In the game, a painter arrives on mysterious island, which has strange things going on with it. Blob-shaped monsters made of paint start to appear from an ancient tomb. The only way to stop this is to paint beautiful patterns which were washed away by a flood that happened some time ago.

The main mechanic is that you can draw on floors and paint stuff by hitting it with your brush. By painting on the floor, you solve different puzzles.







The game is done in 4 colors (technically it's sometimes 8, because it has two palettes from time to time) and in 160x144 resolution, just like Game Boy!

4

Graphics / [Solved] How do I combine two view transforms into one view?

« on: May 10, 2019, 12:01:11 pm »

In my game, I render what game camera sees onto render texture and then I scale this render texture and finally draw it into window (for letterboxing).
So, I have two views for this: one for game camera and one for properly scaling and drawing the texture.

Now, I want to draw something on top of the texture by combining both camera and texture transforms. How can I do this?

5

Window / Creating a global sf::Cursor on Linux crashes the program on startup

« on: August 05, 2018, 05:09:10 pm »

Repo:

#include <SFML/Window/Cursor.hpp>

sf::Cursor cursor;

int main()
{ }

Stack trace:

#0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:65
#1  0x00000000004ff415 in sf::priv::MutexImpl::lock (this=0x0) at /home/eliasdaler/SFML-release/SFML/src/SFML/System/Unix/MutexImpl.cpp:57
#2  0x00000000004f9ec8 in sf::Mutex::lock (this=0x75a958 <_ZN12_GLOBAL__N_15mutexE>) at /home/eliasdaler/SFML-release/SFML/src/SFML/System/Mutex.cpp:56
#3  0x00000000004f9d43 in sf::Lock::Lock (this=0x7fffffffd4f8, mutex=...) at /home/eliasdaler/SFML-release/SFML/src/SFML/System/Lock.cpp:38
#4  0x00000000004e2b5b in sf::priv::OpenDisplay () at /home/eliasdaler/SFML-release/SFML/src/SFML/Window/Unix/Display.cpp:56
#5  0x00000000004dd655 in sf::priv::CursorImpl::CursorImpl (this=0x76d940) at /home/eliasdaler/SFML-release/SFML/src/SFML/Window/Unix/CursorImpl.cpp:43
#6  0x00000000004d2106 in sf::Cursor::Cursor (this=0x753ab0 <cursor>) at /home/eliasdaler/SFML-release/SFML/src/SFML/Window/Cursor.cpp:36
#7  0x0000000000407ef7 in __cxx_global_var_init ()
#8  0x0000000000407f39 in _GLOBAL__sub_I_main.cpp ()
#9  0x00000000004ff5ed in __libc_csu_init ()
#10 0x00007ffff5dcfb28 in __libc_start_main (main=0x4093f0 <main>, argc=1, argv=0x7fffffffd6e8, init=0x4ff5a0 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd6d8)
    at ../csu/libc-start.c:266
#11 0x000000000040932a in _start ()
 

This crash is caused by OpenDisplay() in sf::Cursor's constructor (here).

Is this expected? What if the display was opened on cursor load only? The fix should be simple in this case and I'm ready to provide a PR for it.

6

Window / NumLock behavior on Linux

« on: April 22, 2018, 11:08:36 pm »

On most keyboards, if NumLock is off, pressing "7" on numpad produces "Home", and when NumLock is on, the "7" is produced.

Right now SFML doesn't reflect that, at least on Linux (didn't test on Windows yet). sf::KeyPressed reports  "sf::Keyboard::Numpad7" being pressed in both cases. Is this intended behavior?

If not, should we fix it? (I already figured out how to do it).

7

Feature requests / Better gamepad support

« on: April 20, 2018, 02:41:20 pm »

Hello, everyone!

Everyone who ever dealt with gamepad input, probably knows how hard it is. Gamepads are extremely inconsistent - even the same device can work inconsistenly on different systems.

Currently, we have sf::Joystick, which is not easy to deal with, when you try to support different gamepads. Not only axes and buttons get identified differently - even the direction of axes is hard to predict.

For example, we have this issue which is causes by gamepad drivers. But what if we could hide all that inconsistency behind a pretty interface?

Here's what SDL does. It has a Gamepad interface built on top of Joystick interface. It allows users to get a wide range of gamepads working without hardcoding everything manually. It allows them to get "Left stick" state, instead of "X" axis state. It allows them to get "A" button, instead of "button 0". ("A" button is "Cross" on Playstation-style gamepads, usually). Another solution would be to call "ABXY" buttons as "North, West, South, East" buttons, to support gamepads which have "A" and "B" (also "X" and "Y") switched.

This works by storing a community-driven database of gamepads and how they work on different systems. We can do the same too!

The interface can look like this, for example:

bool isPressed = sf::Gamepad::isButtonPressed(gamepadId, sf::Gamepad::Button::A);
float pos = sf::Gamepad::getAxisPosition(gamepadId, sf::Gamepad::Axis::LeftStick);

Won't it be wonderful to have?

So, here's what I'm proposing. Let's build a Gamepad interface on top of Joystick interface. We won't deprecate any current behaviour by this. We'll just add a nice interface for developers to use. I think we can agree, that most people want "Joystick" mostly for gamepads, not for steering wheels or, well, joysticks.


I think that I'll be able to provide Windows and Linux implementation if everything is agreed upon. There'll be need for Mac OS X and Android/iOS implementations, as they treat gamepads differently too.

Some things to consider as well:

* XInput. SDL supports XInput, and we can have it too. There are currently a bunch of gamepads supporting it, not just an Xbox 360 one. We need it for letting the developers properly use it with gamepad triggers (right now they are one axis in SFML). This was a huge deal-breaker for some professional developers that I know. They went to SDL, because SFML couldn't handle this properly. We don't want to lose developers like this.
XInput will also allow us to make gamepad vibration (force feedback) available.
* D-pad should be interpreted as 4 buttons, even though drivers usually have them as axes.
* SDL Gamepad DB. It's huge. We need to ask SDL devs if it's okay to reuse it for SFML and see if it can be used at all. Yes, we may create our own database from scratch. But Valve has a lot more resources to get all the info about gamepads, and this is shown by the huge db that was partly made using help of Steam users.

8

Pull Requests & Testing / Scancodes (Windows, Linux, Mac testing needed)

« on: April 09, 2018, 09:04:11 am »

Hello, everyone!

The scancode feature is implemented on Windows, Mac and Linux and needs a lot of testing.

Links:
#1325 by Hiura - created API for scancodes and Mac implementation
#1294 by JohnyPtr - Windows implementation
#1400 by Elias Daler - Linux implementation

Purpose
Scancodes are a very important feature that's been asked to be implemented in SFML for a long time. It gives developers a layout independent way of reading keyboard input. Suppose you're using standard "WASD" walking input scheme in your game. If you just say "if pressed sf::Keyboard::Key::A then go left", it'll work as expected only on a QWERTY and a bunch of layouts where "WASD" is in the place gamers usually expect it to be. But, it'll work wrong on AZERTY layout, which has "A" where "Q" on QWERTY is.

Scancodes prevent this problem. If we say "if pressed sf::Keyboard::ScanA then go left", we're telling something like "if pressed the key which is in the place where A on QWERTY keyboards is then go left".

Testing
Testing can be easily done with this repo. Don't forget to switch to branch "scancode".

Testing is especially important if you have non-QWERTY layout. The more non-traditional it is, the better. Another good thing to test for is weird keyboards with non-grid layouts.

Things to test:

• Alphanumeric buttons. See that scancode corresponds to QWERTY layout. Key description should depend on your layout and produce the same thing that you see when you type into a text editor
• Toogle NumLock on and off and see if numpad keys are correct. In a lot of keyboards if NumLock is turned off then "2" on Numpad acts as "Down"
• Try pressing F1-F12, Space, Tab, Enter, Backspace, Delete, etc. and confirm that they are correctly displayed
• Try pressing Ctrl and Alt keys. They have "Left" and "Right" variants and this should be shown in the test program
• Try changing your keyboard layout in system settings. For example, switch to DVORAK and test that the keys are still identified correctly

There are a bunch of keys which will cause the window to lose focus: System/Win key, VolumeUp/Down keys, etc. These keys need to be tested separately in your code. For example, something like this:

if (sf::Keyboard::isKeyPressed(sf::Keyboard::ScanVolumeUp))
    std::cout << "VolumeUp pressed!\n";

After you've done testing, please post about how it worked for you in this thread. If you have some problems, feel free to ask any questions.

New stuff added to SFML's API

• Keyboard::Scancode enum
• Keyboard::isKeyPressed(Keyboard::Scancode)
• Keyboard::Key Keyboard::localize(Keyboard::Scancode)
• Keyboard::Scancode Keyboard::localize(Keyboard::Key)
• String Keyboard::getDescription(Keyboard::Scancode)

You also now will have "scancode" field filled alongside with "key" in KeyPressed and KeyReleased events.

Examples of usage:

sf::Keyboard::Key key = sf::Keyboard::unlocalize(sf::Keyboard::ScanQ); // Q on QWERTY, A on AZERTY
sf::Keyboard::Scancode scancode = sf::Keyboard::localize(sf::Keyboard::A); // ScanA on QWERTY, ScanQ on AZERTY
sf::String str1 = sf::Keyboard::getDescription(sf::Keyboard::ScanQ); // "Q" on QWERTY, "A" on AZERTY
sf::String str2 = sf::Keyboard::getDescription(sf::Keyboard::ScanSpace); // "Space" on all layouts

It'll be very nice to test this feature not only using Hiura's test program, but in your code as well. Thanks to everyone who'll take the time to test this!

9

General / Is there an easy way to deal with diagonal staircase movement?

« on: February 03, 2018, 10:56:49 am »

Here's a short picture I drew to explain the problem


Previously I used std::round to round real coordinates to render coordinates. It worked pretty great, until I noticed that if something moves with 0.5 increments, the movement becomes quite jerky. The only solution I've found so far is to take velocity into account and do std::floor(pos.x) if v.x > 0 and std::ceil(pos.y) if v.x < 0 (same for v.y and y-coordinate)

Note that I only have to do it if coordinate is exactly between two pixels (e.g. 0.5, 1.5, 2.5, etc.). For other coordinates it works perfectly well with std::round.

Any easier solution to this? (Note that my game is very low-res, so I can't use bilinear filtering or something like this).

10

Graphics / [SOLVED]Efficient ways to draw large grids?

« on: May 25, 2017, 03:37:38 pm »

I have a level editor in my game and potentially maps may be pretty large. I want to draw grid overlay which shows borders for each tile. I realize that I must use VertexArray for grids, but as the map size gets large (e.g. more than 200x200 tiles), the size of VertexArray grows fast. And it doesn't make much sense to draw the entire grid when I only see some region of the map, so I would like to draw only the grid for tiles currently on the screen.

Any tips?

11

General / Using SFML with math libraries? (GLM, Eigen...)

« on: March 10, 2017, 08:55:56 am »

I was wondering if someone here uses math lib along with SFML. I just find sf::Vector2f functionality lacking a lot of time when I need to compute something hard. I ended up writing a bunch of mathematical functions for them myself, but the number of them is increasing and I'm considering to use GLM for all the math stuff.

So, my question is: have anyone used it succesfully SFML and what were the steps with SFML's integration? Maybe I should add some implicit conversions from sf::Vector2f to glm::vec2 and vice versa? Or maybe I should always use doSomething(float x, float y) when calling SFML's API when possible?

What other things may I want to do?

12

General / [SOLVED]Float precision and pixel accuracy

« on: March 05, 2017, 01:15:32 pm »

So, this isn't a novel problem, but so far I haven't seen perfect solution to it.
My game runs at 60 FPS and I use fixed delta time for FPS. Delta is sf::seconds(1/60), so something like 0.016666007.

I tried using rounding and std::floor for positions, but float inaccuracies ruined everything, especially if there were objects which moved with the same speed (hero on platform, for example). Moving them by the same offset caused sprites to be rendered with different offset. (platform or hero would have a bit different offset to each other during some frames).

I guess the best solution is to store position in integers with some subpixel variable indicating 1/4th (1/8, 1/16?) of a pixel. Another way is to use fixed point arithmetic. (Pixel games don't need much sub-pixel precision because to achieve smooth movement I have to make speeds some factors of 60)

Thanks to sf::Vector<T> being customizable, that shouldn't be hard to implement. Does anyone know how to implement this efficiently?

13

General discussions / Resources and discussion about good game engine design and clean code

« on: February 20, 2017, 10:46:57 pm »

I'm a big fan of good, readable and maintainable code.

I believe that writing high quality code is important: it saves your sanity, allows you to iterate quickly and do whatever you want with your game without having to deal with coupling issues and random bugs.

So, I hope this thread starts some productive discussion about things that can make your code and engine architecture better. I'll start with some resources, feel free to add everything you liked.

I'll also occasionally write here about some things that made my code much better and I'd like to hear some similar stories from you!

Books:

• Code Complete by Steve McConnell [Amazon]
• Game Engine Architecture by Jason Gregory [Amazon]
• Game Programming Patterns by Bob Nystrom [Amazon] (also available for free online here)
• SFML Game Programming by Jan Haller, Henrik Vogelius Hansson, Artur Moreira [Packtpub]

Articles:

• Fix Your Timestep!
• The guide to implementing 2D platformers

Talks: // todo
Open source games with good code: // todo

14

Window / Wrong sf::Event::JoystickMoved events sent when pressing any axis or button

« on: November 04, 2016, 02:23:22 pm »

When I press any button or stick on the gamepad, I get several sf::Event::JoystickMoved events.
I think it's axis calibration issue...

Check out what you get with this program (don't press any axes. Just press any button).

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(640, 480), "");
    window.setVerticalSyncEnabled(true);
   
    sf::Joystick::update();

    std::vector<std::string> names = {
        "X",    ///< The X axis
        "Y",    ///< The Y axis
        "Z",    ///< The Z axis
        "R",    ///< The R axis
        "U",    ///< The U axis
        "V",    ///< The V axis
        "PovX", ///< The X axis of the point-of-view hat
        "PovY"  ///< The Y axis of the point-of-view hat
    };

    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            switch (event.type) {
                case sf::Event::Closed:
                    window.close();
                    break;
                case sf::Event::JoystickMoved:
                    std::cout << names[event.joystickMove.axis] << " " << event.joystickMove.position << std::endl;
                    break;
                default:
                    break;
            }
        }

        window.clear(); // fill background with color
        window.display();
    }
}

I consistently get this:

X 0.389105
Y -1.17952
R -395209
U 4.31067

What can I do about it?

15

Graphics / [SOLVED] Failed to compile geometry shader? (SFML 2.4)

« on: September 26, 2016, 09:50:49 am »

SOLVED: turns out that I didn't recompile the file which loaded shader, so sf::Shader::Fragment was still equal to 1 in this source file... I'm not smart at times. 

I've just update to SFML 2.4 from SFML 2.3.2 and now none of my shaders work.
I used pixelate.frag shader from examples and I load it like this:

shader.loadFromFile("res/shaders/pixelate.frag", sf::Shader::Fragment);

For some reason, however, SFML displays the following errors:

Failed to compile geometry shader:
Geometry shader failed to compile with the following errors:
ERROR: 0:8: error(#143) Undeclared identified gl_FragColor
ERROR: 0:8: error(#143) Undeclared identified gl_FragColor
WARNING: 0:8: warning(#402) Implicit truncation of vector from size 4 to size 1.

ERROR: error(#273) 2 compilation errors. No code generated

How can I fix it?