31
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 
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.
32
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 thingLet'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.
33
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:
If I needed to summarize what makes libraries good, I would probably mention something along the lines of:
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)
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.
34
SFML development / Re: I created fast sin() / cos() which could replace slower std::sin()/cos()
« on: March 16, 2021, 09:11:38 am »
@jp check the C++ documentation: https://en.cppreference.com/w/cpp/numeric/math/sin
As mentioned by eXpl0it3r, there are overloads for float and double. So the float one doesn't use an unnecessary number of digits.
I agree that it's a nice way to experiment with sin/cos optimizations, but you're also not the first one doing it:
Ultimately, the fastest possible implementation is likely a LUT (look-up table), not a Taylor series. Again a trade-off between code size/memory and speed.
As mentioned by eXpl0it3r, there are overloads for float and double. So the float one doesn't use an unnecessary number of digits.
I agree that it's a nice way to experiment with sin/cos optimizations, but you're also not the first one doing it:
- https://stackoverflow.com/q/18662261
- https://www.gamedev.net/forums/topic/621589-extremely-fast-sin-approximation/
- https://redd.it/g75r2j
- https://github.com/divideconcept/FastTrigo
- ...
Ultimately, the fastest possible implementation is likely a LUT (look-up table), not a Taylor series. Again a trade-off between code size/memory and speed.
35
General / Re: Setting SFML on CLion
« on: March 05, 2021, 03:49:15 pm »
Hello
There's no official tutorial for CLion, but since it is CMake-based, you should be able to use SFML using the normal CMake tutorial. As a generator, you need to use the one set in the CLion toolchain (MinGW g++ or MSVC compiler).
There's no official tutorial for CLion, but since it is CMake-based, you should be able to use SFML using the normal CMake tutorial. As a generator, you need to use the one set in the CLion toolchain (MinGW g++ or MSVC compiler).
36
SFML development / Re: C++ standards
« on: March 04, 2021, 09:21:54 am »
Thanks for the feedback!
enum struct vs. enum class: I don't have a very strong opinion here. Both are terrible cases of keyword recycling, and I guess the entire reasoning to even allow two variants is the old "I want to use struct whenever I can use class (except in template parameter lists)". I thought being public and data-only might be closer to struct, but let's see what others think here
final: what I definitely want to avoid is annotating classes final for no reason. It's one of the "wrong default" issues C++ has (like explicit, const, noexcept...), and the lack of it doesn't imply "this class is designed for inheritance". Regarding final for methods, it probably only makes sense when it's actively harmful to further override a method.
override: yes, I agree it should be used everywhere.
using: good point about the clarity.
I honestly think sf::UintN/IntN types should go too, there's no reason to maintain them with <cstdint>.
Attributes: absolutely agree, especially [[deprecated]] is great. Was thinking about them yesterday, but didn't know where to put it.
enum struct vs. enum class: I don't have a very strong opinion here. Both are terrible cases of keyword recycling, and I guess the entire reasoning to even allow two variants is the old "I want to use struct whenever I can use class (except in template parameter lists)". I thought being public and data-only might be closer to struct, but let's see what others think here
final: what I definitely want to avoid is annotating classes final for no reason. It's one of the "wrong default" issues C++ has (like explicit, const, noexcept...), and the lack of it doesn't imply "this class is designed for inheritance". Regarding final for methods, it probably only makes sense when it's actively harmful to further override a method.
override: yes, I agree it should be used everywhere.
using: good point about the clarity.
I honestly think sf::UintN/IntN types should go too, there's no reason to maintain them with <cstdint>.
Attributes: absolutely agree, especially [[deprecated]] is great. Was thinking about them yesterday, but didn't know where to put it.
37
SFML development / Re: C++ standards
« on: March 03, 2021, 07:30:35 pm »
I elaborated the existing points in the C++17 solution design and added a few new ones. After discussing with eXpl0it3r, the plan is that we have a basic design on each feature before jumping into implementation. This will communicate clearly how we want to change things, and avoid that e.g. move semantics is implemented by 5 people in 6 different ways.
What I wrote down is a suggestion from my point of view, with the main criteria for inclusion being a) ease of use and b) pragmatism (don't change what helps no one). Things are not set in stone.
There are also quite a few open points, feel free to leave feedback!
Regarding move semantics, please use the dedicated thread.
What I wrote down is a suggestion from my point of view, with the main criteria for inclusion being a) ease of use and b) pragmatism (don't change what helps no one). Things are not set in stone.
There are also quite a few open points, feel free to leave feedback!
Regarding move semantics, please use the dedicated thread.
38
General discussions / Re: How up to date are the books in the Learn section?
« on: February 15, 2021, 09:40:55 pm »
Thank you
39
General discussions / Re: How up to date are the books in the Learn section?
« on: February 15, 2021, 12:55:30 pm »
For the book SFML Game Development, in case you look for the source code, it's available on GitHub:
https://github.com/SFML/SFML-Game-Development-Book
It's a bit unfortunate that Packt still doesn't provide an easily visible link to that repo.
Since SFML 2 has been written with backwards compatibility in mind, anything that you could do in SFML 2.0 (at the time of the book's release) is still possible with SFML 2.5. There may be some minor improvements like setFillColor(), but code shouldn't break.
(Disclaimer: I'm one of the authors of that book, so I won't recommend this one over the others)
https://github.com/SFML/SFML-Game-Development-Book
It's a bit unfortunate that Packt still doesn't provide an easily visible link to that repo.
Since SFML 2 has been written with backwards compatibility in mind, anything that you could do in SFML 2.0 (at the time of the book's release) is still possible with SFML 2.5. There may be some minor improvements like setFillColor(), but code shouldn't break.
(Disclaimer: I'm one of the authors of that book, so I won't recommend this one over the others)
40
SFML projects / Re: Dispersio 2
« on: January 21, 2021, 09:09:15 am »
Very nice, congratulations on the release!
The game looks cool, the style reminds me a lot of the original Mario/Donkey Kong game, with the wooden pillars and barrels.
The game looks cool, the style reminds me a lot of the original Mario/Donkey Kong game, with the wooden pillars and barrels.
41
Python / Re: How Can i get Started with SFML On python (Is it a bad idea?)
« on: January 12, 2021, 05:09:23 pm »
Hello!
The Python binding is not maintained by the SFML team, but by Sonkun/intjelic.
Looking at https://github.com/intjelic/python-sfml and the blank website http://www.python-sfml.org/, I'm not sure how actively the project is still maintained. If you don't get a response here, maybe you could write the author an email directly?
Otherwise, there's an old version available on the Wayback Machine: https://web.archive.org/web/20161207102928/http://www.python-sfml.org/index.html
However, keep in mind that if it's not developed anymore, there will not be many people able to help you in case of problems or bugs with the library.
The Python binding is not maintained by the SFML team, but by Sonkun/intjelic.
Looking at https://github.com/intjelic/python-sfml and the blank website http://www.python-sfml.org/, I'm not sure how actively the project is still maintained. If you don't get a response here, maybe you could write the author an email directly?
Otherwise, there's an old version available on the Wayback Machine: https://web.archive.org/web/20161207102928/http://www.python-sfml.org/index.html
However, keep in mind that if it's not developed anymore, there will not be many people able to help you in case of problems or bugs with the library.
42
SFML projects / Re: Shadow Gangs
« on: January 10, 2021, 10:28:17 pm »
5 years, that's a lot of dedication!
If you want, you can add it here: https://github.com/SFML/SFML/wiki/Projects#video-games
But you should definitely also try other channels to advertise it (Twitter, Youtube, Reddit, ...).
The steam price seems a bit high to me, but it may also be because of the sheer number of indie games available at low price.
If you want, you can add it here: https://github.com/SFML/SFML/wiki/Projects#video-games
But you should definitely also try other channels to advertise it (Twitter, Youtube, Reddit, ...).
The steam price seems a bit high to me, but it may also be because of the sheer number of indie games available at low price.
43
SFML projects / Re: Shadow Gangs
« on: January 09, 2021, 04:58:22 pm »
Looks cool!
It's really nice retro art and feel, did you make the graphics?
It's really nice retro art and feel, did you make the graphics?
44
General / Re: How to make my game character jump C++
« on: January 06, 2021, 10:51:56 am »
Most people will not write the code for you. For jumping, what you usually need is a velocity, and a way to change that velocity over time (acceleration/gravity). The position of your character is then modified by that velocity, multiplied with the time of each frame.
If this sounds too abstract, there are tons of little examples and tutorials about basic platform movement on the Internet, I'm sure you'll find a good jump mechanic
If this sounds too abstract, there are tons of little examples and tutorials about basic platform movement on the Internet, I'm sure you'll find a good jump mechanic
45
General discussions / Re: Why would I choose SFML over SDL2?
« on: January 03, 2021, 11:00:54 pm »
It depends on what you need. Factors to decide can be:
- Are you going to use the extra platforms that SDL supports?
- Is there a feature in one or the other library which you must have?
- You have some experience in SFML, are you willing to re-learn?
- Is it worth to "downgrade" from C++ to C? It means you will need to do more things by hand, bother with memory management, etc.