Messages

31

Audio / Re: Access violation executing location 0x0000000000000000.

« on: September 10, 2018, 02:02:41 pm »

Having a minimal compilable example can help you reduce the scope where the problem is and find the root cause. It's not only helping us, but also helping you. With that code, there is nothing we can say. If you cannot abide by this simple rule, I do not think we can help you. Help us help you.

32

SFML development / Re: C++ standards

« on: September 05, 2018, 02:19:23 pm »

About the recent compiler thing, according to this page which is quite up to date, C++17 is pretty much supported by every major compiler that most people uses (MSVC, GCC, Clang). So going the C++17 way for a version that will probably be out in two or three years at least seems like a normal choice. Even if SFML 3 would come out today it would makes sense.

There was a time where it was somewhat recurent(at least in IRC) for people to ask why doesn't SFML support filesystems. That kind of question can easily be solved with C++17 by using std::filesystem. There was a time where SFML was considered more modern than SDL for using hardware acceleration. If we don't go with a recent well supported standard, well SFML is not exactly modern anymore. Just my 2cents for supporting C++17.

33

Audio / Re: Access violation executing location 0x0000000000000000.

« on: August 31, 2018, 02:43:56 pm »

That's not a minimal example. I can't take that code and compile it.

34

SFML development / Re: SFML Roadmap

« on: August 22, 2018, 05:12:39 pm »

Good idea this thread, thanks eXpl0it3r.

My first question is why C++14 for SFML 3.0? C++17 is already standard and is relatively well supported at this moment by every major compiler (according to this page). By the time SFML 3.0 will come out, it will definitely be supported.

Considering how many people seems to ask for filesystem support(and possibily other features), supporting C++17 directly solves that kind of problem, instead of having SFML implementing, only to deprecate it not long after (std::thread vs sf::thread comes to my mind about this). I would expect sf::Thread to be altogether removed anyway from SFML 3.0.

As for the setup for backends, I think it could be very interesting to discuss the possibility of doing such thing. Could also help to port it to more esoteric platform (Xone, PS4, Switch, etc.). I'm all for that, although I understand the work to do something like this can be quite huge.

Finally, while it's nice to add all the things mentions in the list to SFML 2.6, why not start focusing on SFML 3.0 directly for some of those? Scan codes are well advanced that it makes sense, but the rest could probably be more part of SFML 3.0 development directly, making the release of that version earlier than expected, which can only be appreciated.

35

SFML development / Re: SFML Test Strategy

« on: August 20, 2018, 02:30:55 pm »

It's also worth to remember writing tests about edge cases which dictate how SFML deals with some things. For example, a test which tells if rects (0, 0, 10, 10) and (10, 0, 10, 10) intersect or not. It also serves a nice purpose of tests showing a behavior that the user should expect. Unit tests which show you what to expect when you do X and Y are very satisfying.

In my experience, this kind of test also can help a lot of people that wonder how to use different part of the code. It's a direct code example, that shows some of the stuff. A lot of people uses test as an example and a helper to learn how to use libraries.

As for the BDD, I would also agree that a too verbose thing is often annoying and makes it harder to read in a lot of cases. And if we continue with the premise that some users will use the test to learn the library, it makes it harder for them too.

36

General / Re: _Pnode read access violation error in Text.setFont()

« on: August 15, 2018, 02:21:52 pm »

Don't use globals. SFML doesn't support having it's resources (ContextSettings, Font and Text in your case) as globals. It's also a bad design.

37

Graphics / Re: Problems with Struct pointers that contain textures

« on: August 06, 2018, 02:28:25 pm »

And I do really think that I know what a class is and what a struct is, specially, I don't think that not using the new operator gives you the right to say that I don't know how to program, as I said, I'm used to use malloc, and I learn by doing projects anyway.

It somewhat does because it shows you lack some fundamentals of C++. You don't use malloc in C++ (except in rare case which your situation is not a valid case). If you want to use malloc, program in C, not in C++. If you want help, don't reject it when it does not satisfy you. When we tell you to go read a good C++ book, it's not to insult you on your lack of knowledge, but it's to help you and save us both time. All the points eXpl0it3r said are valid.

The fact you go around the errors with possible hack(not sure what you did with a function instead of the constructor) will just bring you maintenance problem in the future.

38

General / Re: Image wont load

« on: July 03, 2018, 03:45:13 pm »

The issue is with your createSprite function. You copy the texture. If you pass it as a const reference (const sf::Texture&) it will be good. However, I don't see the usefulness of your loadImage and createSprite. Like Stauricus said, you copy the texture, which is kinda heavy.

Overall, your code could use some const correctness. You should read up on it Google has ton of info about it!

39

General / Re: Values are still zero after "changing".

« on: June 22, 2018, 02:15:08 pm »

Well where do you call setValues? There's nothing here showing us that.

You should use a debugger to see what is going.

40

Graphics / Re: Question about textures and resources in general

« on: June 14, 2018, 02:25:30 pm »

You have to manage the texture lifetime yourself. The sprites has a non-owner pointer to the texture. So whenever the texture is deleted, those sprites will have a dangling pointer to the texture.

In your situation, you have to make sure your caching system remain alive as long as some sprite used the textures stored within. The lifetime of your sprites won't affect the lifetime of your textures.

41

Window / Re: Cannot get window from its handle

« on: June 08, 2018, 03:42:19 pm »

You should learn more about C++ (and not C) with a good book before going into SFML. The tutorials also explain(briefly how to have everything in a single loop and not blocking everything through a game loop. You don't want to do multithreading for this. Even less when you clearly lack some knowledge of the language.

42

SFML projects / Re: This Grand Life

« on: October 18, 2017, 02:59:30 pm »

Love the artstyle and music. Looks great! Good job! You should contact SFML Projects to have more visibility!

43

General / Re: No PDB Symbols Loaded for SFML Graphics

« on: October 03, 2017, 02:36:25 pm »

Actually, this is an IDE configuration. Visual Studio can't know how to read a sf::Text, or the underlying sf::String(remember that sf::Text is not the text itself, but a graphic representation of a sf::String).

So you need to tell Visual Studio(you can most definitely find some resources by Googling) how it is suppose to read sf::Text for the debugger, and to point it to the sf::String(and of course tell him how to read a sf::String).

44

Window / Re: Maximize Window

« on: August 31, 2017, 02:25:03 pm »

To quote Laurent:

SFML is not a dedicated windowing library...

Further more, nothing prevents you from doing it and making a pull request. You have to remember that the people that works on the library are doing in their own free time. Any help from the community is welcomed.

45

General / Re: hiding console - command and subsystem

« on: July 28, 2017, 03:06:11 pm »

My bad, I misread the CMake in your post.