Messages

1

Feature requests / Re: DRM/KMS support

« on: June 11, 2021, 08:33:00 pm »

This is a follow up to a discussion from Discord.

Many users would be really happy to see DRM window management from SFML-PI to be integrated into the baseline. As I mentioned before, I tried to keep SFML-PI up to date with selective patches from 2.5.1, but WindowBase isn't there. Preparing a PR for the current master is a bit over my head to be honest, so I'm asking for help.

SFML-PI has been running well on Linux and Raspbian. All the code under SFML_RPI flag is obsolete because it was only Raspberry PI 3 specific. SFML_DRM flag covers all x86 linux machines and Raspbian on PI3 and PI4 with KMS driver.

https://github.com/mickelson/sfml-pi/

2

Graphics / setUniform("texture2", tex) on RenderTexture flipped

« on: January 05, 2021, 03:33:18 pm »

I'm not sure whether I do something wrong, or it's some undiscover SFML bug, but when I attach an additional texture to a shader bound to an image sprite it gets rendered normally, but when I do the same on a sprite with RenderTexture the additional texture bound to it appears flipped. Here is the link to the GitHub issue and the sourcecode I used.

https://github.com/SFML/SFML/issues/1733

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow window;
window.create( sf::VideoMode::getDesktopMode(), "Flip bug", sf::Style::Fullscreen );
window.setVerticalSyncEnabled( true );
window.setMouseCursorVisible( false );

sf::Vector2u size = window.getSize();

sf::Texture texture;
texture.loadFromFile( "a.png" );
texture.setSmooth( true );

sf::Sprite texture_sprite;
texture_sprite.setTexture( texture );
texture_sprite.setScale( (float)size.x / texture.getSize().x, (float)size.y / texture.getSize().y / 2.0 );

sf::RenderTexture render;
render.create( size.x, size.y / 2 );

sf::Sprite render_sprite;
render_sprite.setTexture( render.getTexture() );
render_sprite.setPosition( 0, size.y / 2 );

sf::Shader shader;
shader.loadFromFile( "shader.frag", sf::Shader::Fragment );
shader.setUniform( "texture2", texture );

while (window.isOpen())
{
sf::Event event;
while ( window.pollEvent( event ))
{
if (( event.type == sf::Event::Closed )
|| ( event.key.code == sf::Keyboard::Escape ))
{
window.close();
}
}

render.clear();
render.draw( texture_sprite );
render.display();

window.clear();
window.draw( texture_sprite, &shader ); // this renders normally
window.draw( render_sprite, &shader ); // this renders flipped
window.display();
}

return 0;
}

shader.frag

Code: [Select]

// This shader draws texture on the left using RB channels and
// texture2 on the right using G channel
uniform sampler2D texture;
uniform sampler2D texture2;

void main()
{
vec4 color1 = texture2D( texture, gl_TexCoord[0].xy * vec2( 2.0, 1.0 ) + vec2( 0.0, 0.0 ));
vec4 color2 = texture2D( texture2, gl_TexCoord[0].xy * vec2( 2.0, 1.0 ) + vec2( -1.0, 0.0 ));
gl_FragColor = gl_Color * ( vec4(color2.x, color1.y, color2.z, 1.0 ));
}


3

Graphics / Re: RGB texture

« on: October 20, 2020, 02:45:28 am »

I'm also currently trying to find a way to display yuv video frames in SFML. Being able to create grayscale textures woud help a lot.

4

Feature requests / Re: DRM/KMS support

« on: September 12, 2020, 12:03:19 am »

Sorry, I forgot to follow up on this topic. The SFML-PI is working ok now, all issues have been squashed. I've updated it with baseline commits up to 2.5.1, but It would be really nice to be able to merge it with the baseline. I'm just wondering if all things we've added conform with your structure.

EDIT: My 2.5.1 PR for SFML-PI is still waiting to be merged. Mickelson has sometimes long gaps in activity. I think it's what is happening now. Another reason to go SFML baseline.

5

Feature requests / Re: DRM/KMS support

« on: June 05, 2020, 04:19:23 pm »

A little heads up.

The DRM backend is almost finished. But we stumbled across an issue that we can't find an elegant way aroud. There was a problem with rendering locking up after pressing the Enter key. We discovered that it was due to the keyboard input being passed to the terminal underneath. We solved that by grabbing an exclusive rights to all keyboard events in /dev/input by calling `ioctl(*itr, EVIOCGRAB, 1);` unfortunately this left us unavle to generate a TextEvent. Can you think of any way of converting a keycode to utf32 without relying on tables for each codepage like in SDL?

6

Feature requests / Re: DRM/KMS support

« on: June 01, 2020, 09:06:41 pm »

Mickelson added DRM/KMS support for Linux and Raspbian(RPI4) to his fork sfml-pi yesterday. Would you be interested merging it now with the master? sfml-pi is still 2.4.2

https://github.com/mickelson/sfml-pi/commit/4b7d415e1464fa98689130b4f7531d9b986c1430

7

Feature requests / Re: DRM/KMS support

« on: April 10, 2020, 08:43:45 pm »

DRM serves the same function a X11 to open a window and reserve a surface, but with better latency and performance as it's closer to the metal.

8

Feature requests / DRM/KMS support

« on: April 10, 2020, 02:55:35 am »

I'm curious what is your stance on adding an implementation of DRM/KMS subsystem on Linux.

9

General discussions / cmake errors in WSL Ubuntu

« on: December 22, 2019, 06:02:20 am »

I'm trying to build the latest SFML for use in MXE environment in WSL Ubuntu, but I'm getting cmake errors. Do you have any clue what is causing it?

oomek@radek-pc:/mnt/d/Documents/GitKraken/sfml/build$ x86_64-w64-mingw32.static-cmake -G "Unix Makefiles" -DBUILD_STATIC=1 -DBUILD_STATIC_LIBS=1 ..
== Using MXE wrapper: /home/oomek/mxe/usr/bin/x86_64-w64-mingw32.static-cmake
     - cmake version 3.15.4
     - warnings for unused CMAKE_POLICY_DEFAULT variables can be ignored
== Using MXE toolchain: /home/oomek/mxe/usr/x86_64-w64-mingw32.static/share/cmake/mxe-conf.cmake
== Using MXE runresult: /home/oomek/mxe/usr/share/cmake/modules/TryRunResults.cmake
== Adding "-DCMAKE_BUILD_TYPE=Release"
loading initial cache file /home/oomek/mxe/usr/share/cmake/modules/TryRunResults.cmake
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeDetermineSystem.cmake:185 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)


-- The C compiler identification is GNU 5.5.0
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeDetermineCCompiler.cmake:212 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)


-- The CXX compiler identification is GNU 5.5.0
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeDetermineCXXCompiler.cmake:210 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)


CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeDetermineRCCompiler.cmake:55 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/Platform/Windows-GNU.cmake:138 (enable_language)
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/Platform/Windows-GNU-C.cmake:2 (__windows_compiler_gnu)
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeCInformation.cmake:48 (include)
  CMakeLists.txt:45 (project)


-- Check for working C compiler: /home/oomek/mxe/usr/x86_64-pc-linux-gnu/bin/x86_64-w64-mingw32.static-gcc
-- Check for working C compiler: /home/oomek/mxe/usr/x86_64-pc-linux-gnu/bin/x86_64-w64-mingw32.static-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:80 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)


-- Check for working CXX compiler: /home/oomek/mxe/usr/x86_64-pc-linux-gnu/bin/x86_64-w64-mingw32.static-g++
-- Check for working CXX compiler: /home/oomek/mxe/usr/x86_64-pc-linux-gnu/bin/x86_64-w64-mingw32.static-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CMakeTestCXXCompiler.cmake:73 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)


CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckIncludeFile.cmake:55 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckTypeSize.cmake:230 (check_include_file)
  cmake/Config.cmake:10 (check_type_size)
  CMakeLists.txt:48 (include)


-- Looking for sys/types.h
-- Looking for sys/types.h - found
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckIncludeFile.cmake:55 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckTypeSize.cmake:231 (check_include_file)
  cmake/Config.cmake:10 (check_type_size)
  CMakeLists.txt:48 (include)


-- Looking for stdint.h
-- Looking for stdint.h - found
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckIncludeFile.cmake:55 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckTypeSize.cmake:232 (check_include_file)
  cmake/Config.cmake:10 (check_type_size)
  CMakeLists.txt:48 (include)


-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of void*
CMake Error at /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckTypeSize.cmake:119 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  /home/oomek/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.15/Modules/CheckTypeSize.cmake:246 (__check_type_size_impl)
  cmake/Config.cmake:10 (check_type_size)
  CMakeLists.txt:48 (include)


CMake Error at cmake/Config.cmake:11 (if):
  if given arguments:

    "STREQUAL" "4"

  Unknown arguments specified
Call Stack (most recent call first):
  CMakeLists.txt:48 (include)


-- Configuring incomplete, errors occurred!
See also "/mnt/d/Documents/GitKraken/sfml/build/CMakeFiles/CMakeOutput.log".
See also "/mnt/d/Documents/GitKraken/sfml/build/CMakeFiles/CMakeError.log".
 

10

Graphics / Re: SFML and OpenGL ES 2.0 context

« on: December 18, 2019, 03:31:22 pm »

How does it relate to SFML? You just opened a window with SFML and created a context with imgui.
The flag SFML_OPENGL_ES2 you have defined does not even exist elsewhere.

11

Feature requests / Signed Distance Field Fonts

« on: November 20, 2019, 08:59:06 pm »

Have you ever considered a possibility to add Single Distance Field Font rendering or it's more accurate cousin Multi Channel SDF Fonts to SFML?
Since it requires shaders to blend with a render target I wonder what's your opinion about that.

12

Graphics / Re: SFML and OpenGL ES 2.0 context

« on: January 11, 2019, 04:44:42 am »

I'm sorry for digging out an old topic, but I need to ask if there are any news regarding the support for GLES 2.0?

13

General / Re: [unsolved] gameSWF started corrupting the rendering since SFML 2.5.0

« on: November 23, 2018, 01:46:34 am »

Now when you showed it it seems logical. I was trying this approach before, but probably after "new" and create()

Thank you again. The leak is gone.

14

General / Re: [unsolved] gameSWF started corrupting the rendering since SFML 2.5.0

« on: November 22, 2018, 02:27:19 pm »

I could define the RenderTexture as a static class member, but unfortunately I have no control over how many instances of FeSWF the script generates.

15

General / Re: [unsolved] gameSWF started corrupting the rendering since SFML 2.5.0

« on: November 22, 2018, 12:42:51 pm »

I've written a small example that is showing the vram leak if I use the binary1248's suggestion. Even without drawing with OpenGL the leak is present and it's caused just by activating the context.

Please take a look, maybe I'm still doing something wrong.

#include <SFML/Graphics.hpp>

void main()
{
        // true - vram leak
        // false - ram leak, fps degradation over time, delay on exit ( comment setFrameLimit() )
        bool leak = true;

        sf::RenderWindow window(sf::VideoMode(800, 600), "");
        window.setFramerateLimit(30);
        sf::Context context;
        sf::RenderTexture *rtexture;

        if (!leak) rtexture = new sf::RenderTexture();

        sf::Event event;
        while (window.isOpen())
        {
                if (leak) rtexture = new sf::RenderTexture();

                rtexture->create(rand() % 100 + 400, rand() % 100 + 400);
                rtexture->clear(sf::Color::Cyan);

                context.setActive(true);
                rtexture->setActive(true);
                //drawing OpenGL stuff here
                rtexture->setActive(false);
                context.setActive(false);

                rtexture->display();
                window.clear();
                sf::Sprite sprite(rtexture->getTexture());
                window.draw(sprite);
                window.display();

                if (leak)
                {
                        delete rtexture;
                        rtexture = NULL;
                }

                window.pollEvent(event);
                if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
                {
                        if (!leak)
                        {
                                delete rtexture;
                                rtexture = NULL;
                        }
                        window.close();
                }
        }
}
 

In case you are wondering why I call new before create(), rtexture is a member of a class that gets destroyed every time AttractMode reloads SWF. And that's because the artwork type can be one the following ( an image, a video, or swf )