Messages

1

General / Re: Entire game in single cpp file?

« on: April 21, 2021, 05:17:19 pm »

https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list
Youtube tutorials are often low-quality and gloss over lots of important topics. C++ is probably the most complex language (at least of those actually used in the industry), it's entirely impossible to learn it in a few days.

That being said, if you want to learn a new language in 2021, I'm not sure if C++ is still the best choice. I would rather recommend Rust (if you want to have the same level of control), which is significantly more modern and easier to use than C++, and does a lot of things better.

2

General / Re: About game states

« on: April 16, 2021, 08:15:53 am »

@AdrianHey: please follow the advice I gave you in my last answer.

It's not nice to ask a low-effort question without research, let people spend a big amount of time answering and then not even get back to them.

The only question that you replied to was this one, and interestingly it's exactly the one where you spent more time asking the question.
All the others are two-sentence questions and remain unanswered:

• https://en.sfml-dev.org/forums/index.php?topic=27969
• https://en.sfml-dev.org/forums/index.php?topic=27970
• https://en.sfml-dev.org/forums/index.php?topic=27973
• https://en.sfml-dev.org/forums/index.php?topic=27989
• https://en.sfml-dev.org/forums/index.php?topic=27998

If you continue like this, soon people will stop helping you altogether.

3

General / Re: Problem using delta time

« on: April 15, 2021, 12:30:27 pm »

I am trying to make an int function withc return delta tiomme and It doesent work. Any ideawhat can I do?

Please read this thread first.
This concerns a lot of your posts here.

And please spend at least 10 seconds formulating a clear question without typos, if you expect people to spend several minutes answering.

4

General / Re: Change color when hovering over text

« on: April 15, 2021, 10:13:34 am »

By the way, this should just be a warning (maybe an error if you treat warnings as errors), you can still use setColor().

5

Network / Re: My Issue with TcpListener listen() method

« on: April 11, 2021, 04:56:53 pm »

A bit late, but the reason is not zero initialization -- both times, the same constructor is called, default-constructing the sf::TcpListener member variable.

As expl0it3r mentioned, initialization at startup (i.e. from global variables) is a big mess in C++, as there's no deterministic order. So better avoid global variables in general, good design almost always makes them obsolete.

6

General / Re: understand sf::Time

« on: April 11, 2021, 04:29:36 pm »

sf::Time is simply a value. It doesn't change on its own.

7

General / Re: Entire game in single cpp file?

« on: April 11, 2021, 04:27:25 pm »

Multiple files only decrease compile if you carefully check dependencies, and possibly use the PImpl idiom. If you have a #include <SFML/Graphics.hpp> + several standard includes in every header file, your code is almost guaranteed to compile slower than doing the same thing in a single header file. After all, the compiler needs to re-compile the same code over and over (unless you use precompiled headers).

You can definitely start with one file, C++ leaves it up to you how you organize your code. But once your code grows beyond a few hundred lines, it really gets harder to navigate. At some point, compile times do come into play, because that one file (and thus your entire code) needs to be recompiled on every change, no matter where.

Consider this: you have files Zombie.hpp and Zombie.cpp which implement a class. The header is simply the public interface + some member variables. The logic how the zombie moves is written in the .cpp file. Now if you want to modify something, e.g. make it faster to move or change how it interacts with certain objects, the compiler only has to recompile Zombie.cpp + all the headers it includes. But it does not have to recompile Player.cpp, Item.cpp and Orc.cpp. They are independent translation units.

8

General / Re: ld.exe cannot find -lsfml-graphics-d

« on: April 11, 2021, 03:34:34 pm »

All the search directories are added correctly still its giving this error.

Are you sure you added the library directory with sfml-graphics-d? Double-check, the error indicates that it is wrong.

How does the filesystem of that lib directory look?

9

General / Re: If an object is not drawn does it exist?

« on: April 09, 2021, 01:10:48 pm »

If an object is not drawn does it exist?

Quite a philosophical question!

See my answer in the other thread for an explanation. Collision with other objects will happen exactly when you program it, otherwise not. There is no "implicit" collision in SFML or anything like that.

Maybe also consider reading a good C++ book that explains the concept of objects and their lifetimes

10

General / Re: Any way I can destroy objects?

« on: April 09, 2021, 10:40:04 am »

Even if you would call the destructor, the object would still be there, just in a destroyed state. But you'd still have a variable referring to it. Also it would be undefined behavior for stack/automatic objects, their destructor is called at the end of their scope, so don't invoke it manually.

What you typically want to do for things like bullets is a STL container, almost always std::vector (see cppreference.com). You can dynamically add and remove objects, and iterate over all existing objects. So whenever someone shoots a bullet, you add it, and when it hits something, you remove it from the vector.

11

General / Re: How can i make a static array of shapes and then draw it?

« on: March 30, 2021, 08:54:49 am »

"Static array" can also be understood as the counterpart to "dynamic array", i.e. an array with fixed size at compile time, or simply an array -- not a pointer allocated with new[]. I would try this.

Using the keyword static just so it's used really makes no sense. Maybe we're missing some context.

12

General discussions / Re: Best Practice? Lots of Icons/Symbols/Bars for players and npcs

« on: March 23, 2021, 11:44:20 am »

A few hundred draw calls should be OK, did you encounter any problems? I wouldn't make code more complicated than necessary.

Otherwise, can you tell us a bit more about how the effects/icons are drawn? Are they static? Are they part of a shared texture? Animated?

13

SFML wiki / Re: Rectangular Boundary Collision

« on: March 19, 2021, 11:12:34 am »

Nice, thanks a lot for yet another contribution! Very nicely documented too

14

General discussions / Re: Is it just me, or SFML is very well written

« on: March 18, 2021, 11:45:53 am »

Is there a way I can get some information on how Laurent planned the whole thing

Let's see if he stumbles across this thread

But a lot of good API design comes down to experience in software engineering. You work with a lot of APIs and begin to see what works and what doesn't. Always try to see it from a user perspective -- a good process to ensure that is dogfooding.

@Nexus do you think SFML is here to stay and will be maintained/upgraded over the years? Some people I talk to believe it's "old" or  "dated" while I can't stop praising it.

It should stay, even if development has slowed down a bit. On one hand the library is in a state where a lot of things work and are stable, but there are still some larger things we'd like to do, see solution designs. I personally try to push the C++17 topic a bit, which should help modernize the library from a language perspective.

Still, we should acknowledge that it's not the 2000s anymore, where C and C++ were the only languages for game development, and writing your own engine was a must. For people who just want to create a small game, an engine (like Godot or Unity) and simpler language (like GDScript or C#) can be more productive. You're trading off control over the code base and need to adhere to the way how the engine does things, however. SFML is still very lightweight and highly optimized for 2D rendering, and you're free to use whatever architecture on top. Be it a classical OOP scene-graph, an ECS or something entirely different, SFML provides the building blocks and doesn't dictate how to use them. So it ultimately depends also on personal preference.

15

General discussions / Re: Is it just me, or SFML is very well written

« on: March 17, 2021, 07:18:03 pm »

A lot of the clean code can be attributed to Laurent, the original author of SFML, who kept the philosophy of "simple" true over the years
When I joined the community over a decade ago, the C++ quality was definitely a factor for me, compared to more low-level C alternative libraries.

From all the programming languages I know, C++ has the widest variance of code quality in my opinion. Even PHP and JS have no chance here. A big part of the reason is the number of paradigms that C++ has enabled, and the big changes in usage over its lifetime.

It's not just that there is a lot of bad C++ code, but there is an almost creative variety of different ways how code can be bad.
We really have everything:

• C with classes, manual memory management and a big pointer mess (LZMA, most gamedev-related libraries)
• over-engineered template hell (several Boost libraries)
• Java in C++ (Ultimate++, many UI frameworks)
• macro hell (wxWidgets)
• antiquated design (standard iostreams)
• over-fashionable design (using template parameter packs and trailing return types just for the sake of modernity)
• wheel reinventors (almost every gamedev library w.r.t. standard containers, linear algebra libraries)

For a long time, truly well written libraries almost seemed like a niche, a gem, to find in C++. There are so many different styles to write C++, it's hard to objectively classify which code is clean. Obviously, the above list is my personal view, and other people might see this differently.

If I needed to summarize what makes libraries good, I would probably mention something along the lines of:

• It has a clear scope, keeps its promises but does not try to solve problems it is not made for.
• There's typically one way to solve a problem, and it's clear which one.
• There's an intuitive relation between types, functions and other symbols in the library, and the number of symbols in total is manageable.
• Abstraction level is high, I don't need to know anything the implementation in order to work with the library.
• Things are named appropriately. For many parts of the library, I don't even need to consult documentation. But if I do, documentation is always helpful.