Messages

1

Graphics / Re: Simple OpenGL question - texture loses its transparency after copying

« on: Today at 05:59:33 pm »

I haven't read your OpenGL code, but if you use the default AlphaBlend blend mode, this is expect behavior.

You're rendering the same transparent item over the other, adds the alpha values, so over multiple iterations the alpha value simple gets to the max value and this becomes fully visible and not transparent anymore.

2

General / Re: Unable to find .dll files, cannot find -lsfml-graphics-d | previously all worked

« on: Today at 05:56:51 pm »

Make sure your E:\SFML-2.6.1\lib directory contains the needed files (e.g. libsfml-graphics-d.a).

Make sure the compiler is actually configured to the expected version.

I use the following download for SFML 2.6.1: "GCC 13.1.0 MinGW (DW2) - 32-bit".

I use the newest release of CB (installed from codeblocks-20.03mingw-32bit-setup.exe).

Those don't match, see the links in the red box on the SFML Download page, that links you to the exactly matching compiler.

3

General / Re: Font Loading.

« on: Today at 05:26:13 pm »

I didn't pay much attention to the specific code, but the culprit might be this: *font

You're dereferencing your pointer, but since you've never initialized it, you'll run into undefined behavior and it can crash.

Check your warning levels of the compiler, there might be a warning shown for this.

4

General / Re: Font Loading.

« on: Today at 03:10:38 pm »

I can't reproduce it.

I've used VS2022 as well and the following CMake script and C++ code.

cmake_minimum_required(VERSION 3.22)
project(SFMLTest CXX)

include(FetchContent)
FetchContent_Declare(SFML
    GIT_REPOSITORY https://github.com/SFML/SFML.git
    GIT_TAG master)
FetchContent_MakeAvailable(SFML)

add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest PRIVATE SFML::Graphics)

#include <SFML/Graphics.hpp>

#include <iostream>

int main()
{
    auto window = sf::RenderWindow{sf::VideoMode{sf::Vector2u{500, 500}}, "SFML Test"};
    window.setVerticalSyncEnabled(true);

    auto font = sf::Font::loadFromFile(R"(C:\Windows\Fonts\Arial.ttf)");
    if (!font.has_value())
    {
        std::cerr << "Can&#39;t load font" << std::endl;
        return -1;
    }

    auto text = sf::Text{ *font, "Hello World" };

    while (window.isOpen())
    {
        while (auto event = window.pollEvent())
        {
            if (event.is<sf::Event::Closed>())
            {
                window.close();
            }
        }

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

If you run it through a debugger do you see where it crashes?
If you check the Windows Event Log under Application, do you see more information there?
Is you application logic just so that the application closes?

5

Graphics / Re: How expensive are sprites?

« on: Today at 02:51:33 pm »

Sprite itself is a lightweight class and doesn't directly have an impact on performance.

The texture it uses and the draw calls made by the sprite is what needs to be considered.

If you use multiple textures, then you'll be paying the price of a texture context switch, which can be okay, but can also quickly add up. As such the general recommendation is to use texture atlases (e.g. tile maps), which then lets you reuse the same texture, but with a different texture rect.

Draw calls are slow and one of the most common causes for rendering performance issues (with SFML).
This should usually be fine for a few hundred sprites, if you get into the thousands, you should really reconsider your options. The general recommendation here is to switch to vertex array or vertex buffer, which allows you to render a whole "mesh" of vertices in a single draw call.

The best source (pun intended) for these questions is the source code: https://github.com/SFML/SFML/blob/2.6.x/src/SFML/Graphics/Sprite.cpp

Are sprites stored on the GPU (ie all he details about the graphical icon)?

No, sprites reside entirely on the CPU/RAM side. Textures however are stored in VRAM (which is why copying textures is expensive, as you first have to move it from VRAM to RAM and then back to VRAM).

How do you judge whether you have too many sprites?

There isn't a specific rule. Usually things become noticeable if your game (not some artificial "benchmark") doesn't manage to get a reasonable framerate (60-200fps).

Is there context switching that takes place with spite data stored on the GPU?  Is it switching in and out from the CPU if there isn’t enough capacity?

[/quote]
Sprites are lightweight objects. You can use them even as temporaries and recreate them every frame, but just because you can, doesn't mean it's really recommended.

6

General / Re: Font Loading.

« on: Today at 12:33:59 pm »

How are you using the font?

.\Ironforge.exe
The requested video mode is not available, switching to a valid mode
  VideoMode: { size: { 2560, 1440 }, bitsPerPixel: 32 }
Failed to change display mode for fullscreen
 

But the font problem, I never got it. I also tried to catch std::runtime_error, but it did nothing.

Is 2560, 1440 a valid resolution for your monitor?

Maybe you're mixing debug and release libraries, which could cause odd side effects due to undefined behavior.

7

General / Re: Keyboard Press Once [SOLVED]

« on: Today at 08:35:31 am »

While sf::Keyboard::isKeyPressed may "work", it's not the intended usage to mix it with events.

Unfortunately, I don't know what's causing the events to not have the right value.

8

General / Re: Font Loading.

« on: Today at 08:33:06 am »

Have you tried a different font?
Does it crash with an exception, because of the .value() call on the optional?

9

General discussions / Re: Virus alert during download

« on: May 30, 2024, 11:05:15 pm »

It's a so called false-positive. Would be great if you could report it as such, hopefully someone at McAfee would then clear it.

If you don't want to disable your AV, you're best served by building SFML from source, e.g. by using the SFML CMake template.

10

SFML projects / Re: Tail Smash! - Arcade driving game

« on: May 29, 2024, 11:32:24 pm »

That's a pretty cool write up! I especially liked the diagrams

11

General / Re: Can't compile when trying to render text

« on: May 29, 2024, 11:31:08 pm »

That's a known issue when using UCRT-based MinGW versions, as the pre-compiled freetype library were compiled with MSVCRT. You can either switch to a MSVCRT-based MinGW version or build SFML's dependencies with your own compiler.

12

General / Re: Keyboard big issue

« on: May 29, 2024, 01:01:52 pm »

What window manager are you using? Is this running wayland or xlib?

13

General / Re: Keyboard big issue

« on: May 29, 2024, 02:09:49 am »

What version of SFML are you using?

14

General / Re: Keyboard big issue

« on: May 28, 2024, 04:55:17 pm »

Set a break point inside the key pressed event body, run the application through a debugger and check what the value of the key code is.

I have a feeling that you either have a different layout configured that you're expecting, so hitting the specific key doesn't actually trigger something. Or you have something installed on Debian that remaps keyboard values.

It's unlikely an SFML issue, since we've been using basically the same code for a long time now.

15

General / Re: Keyboard big issue

« on: May 28, 2024, 04:29:00 pm »

Are you using a special keyboard layout?

So the following example application doesn't work?

#include <SFML/Graphics.hpp>

int main()
{
    auto window = sf::RenderWindow{ { 1920u, 1080u }, "Color Switcher" };
    window.setFramerateLimit(144);

    auto backgroundColor = sf::Color::Black;

    while (window.isOpen())
    {
        for (auto event = sf::Event{}; window.pollEvent(event);)
        {
            if (event.type == sf::Event::Closed)
            {
                window.close();
            }
            else if (event.type == sf::Event::KeyPressed && event.code == sf::Keyboard::R)
            {
                backgroundColor = sf::Color::Red;
            }
            else if (event.type == sf::Event::KeyRelease && event.code == sf::Keyboard::G)
            {
                backgroundColor = sf::Color::Green;
            }
        }

        window.clear(backgroundColor);
        window.display();
    }
}

If you use SFML 2.6, can you try scancodes instead?