Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dramcryx

Pages: [1]
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)

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)
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
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
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?

Quote
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 :-X

Quote
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? ;D

7
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? :)

Pages: [1]