Messages

1

General / Re: Static linking problem with VS2019

« on: August 29, 2019, 05:25:34 pm »

I agree that there's no prebuilt binaries for VS2019 but it doesn't really matter for dynamic linking then?

2

General / Static linking problem with VS2019

« on: August 29, 2019, 05:14:36 pm »

Hi. I'm trying to static link prebuilt binaries using Visual Studio 2019 and it fails with undefined references type of LNK2019. It works with dynamic link (no "s" suffix) and the app runs okay with dlls provided.
The command I'm trying to build with is:

cl -EHsc main.cpp sfml-graphics-s.lib sfml-window-s.lib sfml-system-s.lib opengl32.lib freetype.lib winmm.lib gdi32.lib

This command is for building your example green circle.
Am I wrong in linkage order? It fails on linking the graphics package. Same command previously worked with MinGW's g++, of course with proper substitutions.

(click to show/hide)

.....
main.obj : error LNK2019: ссылка на неразрешенный внешний символ "__declspec(dllimport) public: __cdecl sf::String::String(char const *,class std::locale const &)" (__imp_??0String@sf@@QEAA@PEBDAEBVlocale@std@@@Z) в функции main
main.obj : error LNK2019: ссылка на неразрешенный внешний символ "__declspec(dllimport) public: __cdecl sf::String::~String(void)" (__imp_??1String@sf@@QEAA@XZ) в функции main
main.obj : error LNK2019: ссылка на неразрешенный внешний символ "__declspec(dllimport) public: __cdecl sf::VideoMode::VideoMode(unsigned int,unsigned int,unsigned int)" (__imp_??0VideoMode@sf@@QEAA@III@Z) в функции main
main.obj : error LNK2019: ссылка на неразрешенный внешний символ "__declspec(dllimport) public: void __cdecl sf::Window::close(void)" (__imp_?close@Window@sf@@QEAAXXZ) в функции main
.......

UPD: -DSFML_STATIC makes no effect (even longer list of link fails)

3

General / Re: Threaading a sprite

« on: February 12, 2019, 10:50:02 am »

I thought I deleted this post because I fugired out the problem quickly.
The problem was using join() instead of detach().
Second one worked out well.

4

General / Threaading a sprite

« on: February 04, 2019, 06:01:04 pm »

Hi. I've got a sf::Sprite inheritor and I want to make it perform attack animation. The problem is that the duration of that animation must be much longer than a quick button click.
I made "attack" method as a thread that locks other methods from changing sprite's position and texture.
But that texture doesn't seem to change. When R key is pressed, strikev2() is called.

(click to show/hide)

void Leoric::strikev2()
{
    std::thread execute(&Leoric::performAttack, this);
    execute.join();
}

void Leoric::performAttack()
{
    locked = true;
    sf::Clock clock;
    auto start = clock.restart().asMilliseconds();
    while (clock.getElapsedTime().asMilliseconds() - start < 1000)
    {
        setTexture(strikeAssets[look][static_cast<int>(clock.getElapsedTime().asMilliseconds() / 250)], true);
        std::cout << clock.getElapsedTime().asMilliseconds() / 250 << std::endl;
    }
    locked = false;
}

So in performAttack I exactly want my texture to change 4 times and it doesn't happen but locked makes the effect and std::cout also prints integers. I think the problem is syncing texture in main. Could you, please, suggest how should I fix that?

5

Feature requests / Re: sf::Texture and sf::Image constructors with filename parameter

« on: January 06, 2019, 12:48:48 pm »

And... really, doing all this stuff at global initialization (before entering main), is not only UB (because some global SFML objects may not be created yet), but also not really a great idea for handling errors, logging, etc.

Tbh I don't use global values. I use class with const private fields.
I have a capsule class that contains std::list<sf::Sprite > (actually extended sf::Sprite) and they share the same texture and field scheme (18x18 array of FloatRect). That's why I want as much static constants as I can do.
I think I'll go for what you offered to me with these initializing functions. Hope inlining them will also not include themselves as subprograms.

P.S. Do you personally think that library will lost some Simplicity if you go try-catch way instad of bool functions?

6

Feature requests / Re: sf::Texture and sf::Image constructors with filename parameter

« on: January 06, 2019, 12:06:55 am »

This leads to discussions about error handling, exceptions, etc. but this is a complex topic

That's good but let me ask then - why it cannot be smth like

sf::Texture(const std::string &filename) throw(sf::exception::loadingError) //or std::runtime_error for example

that one?

Thread-safety is never achieved with const. You need synchronization primitives in any case.

I didn't really mean this. I mean that I would like to copy static const texture to each sf::Sprite in my std::list<>, for example. This can be done parallel, right? But I'm not sure it will happen if it stays mutable. Nevermind

sf::Texture makeTexture(const std::string& filename)
{
    sf::Texture t;
    t.loadFromFile(filename); // put some log on failure at least, but beware of global objects initialization order
    return t;
}

const sf::Texture MyClass::texture = makeTexture("...");

I actually did think about several of these initializing functions that would provide me all constants I need. Even if I can make them inline, don't you think it looks sort of workaround?

7

Feature requests / sf::Texture and sf::Image constructors with filename parameter

« on: January 03, 2019, 10:49:57 pm »

Hi, community.
I love this library for almost everyting excpet one thing - there are only default (excluding copy) constructors for texture and image class.
It puts me in some trouble because I would like some static const textures and images (then they are read-only, it's safer for multi-threading). I actually think this will add some efficiency, please, tell me if I'm wrong.
So I can't make textures const as I have to use loadFrom...() method instead of direct initialization in class constructor.
I think there are reasons for those not to exist yet. Could you, please, tell me them?