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 - Elias Daler

Pages: [1] 2 3 ... 40
1
General discussions / Re: Difficuly of porting SFML to SDL
« on: November 30, 2022, 01:33:02 pm »
I'd recommend reading my post on my experiences of porting my engine from SFML to SDL: https://eliasdaler.github.io/porting-to-sdl/

Basically, the more you wrap SFML types/functions into abstractions, the easier it will be to port. I'd also recommend to use something like glm instead of sf::Vector/sf::Rect everywhere.

2
Feature requests / Re: (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: April 16, 2021, 12:34:14 pm »
I think if there's a strong opinion that shared libraries should be the default, then it's okay to leave it as is, I suppose. Just wanted to have some discussions on whether this was an intentional choice or not.

I hope that some day CMake will have something better to indicate if you want to built a static or shared library instead of this "BUILD_SHARED_LIBS" flag. :)

3
Feature requests / Re: (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: April 16, 2021, 03:15:56 am »
When you say, SFML's CMake sets it to ON, do you mean implicitly by using the SHARED keyword? Because there's no explicit setting of the mentioned variable.
No, I mean this line.
Ideally there'd be no such option defined/set at all - it'd be up to the user to set it.

Discussion about "SHARED" was in a reference to what Laurent has said.

4
Feature requests / Re: (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: April 16, 2021, 12:41:05 am »
My bad, I didn't check. I always create shared libs, whether it is at home or at work. Adding SHARED to add_library has probably become automatic for me, so that I don't notice it anymore.
You don't actually need to do this - if BUILD_SHARED_LIBS is set to ON, the libraries will compile as shared ones. But if you explicitly do add_library(some_lib SHARED) then it can only be compiled as a shared library and never as a static one.

I really wonder why STATIC is the default on CMake.
Maybe it comes from Windows projects where shared linking is kinda painful, because you need to do all this dllimport/dllexport stuff + copying of dll's to the executable's directory.

What's wrong about having to turn this flag off?
It's just a bit surprising, because I don't expect something to build as shared lib by default, because I don't set BUILD_SHARED_LIBS, but the library does it for me.

Also it forces programs which use SFML to explicitly set BUILD_SHARED_LIBS to some value so that when you call add_subdirectory(SFML), SFML will respect that. Otherwise your program will link everything statically, but SFML will set BUILD_SHARED_LIBS flag and set it to "ON" for itself anyway and build itself as a shared lib, even though the parent application didn't tell it to build as a shared lib.

But yeah, I guess I'll just have to say people to explicitly set BUILD_SHARED_LIBS before calling add_subdirectory(SFML) if they want the flag to work right globally.

5
Feature requests / Re: (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: April 14, 2021, 12:19:44 pm »
CMake builds shared libs by default (if nothing is explicitly specified), so why would you expect static libs?
Plus as mentioned, it's also the CMake default and what is normally expected.
This is not a CMake's default. BUILD_SHARED_LIBS should be manually defined and set to ON so that CMake builds a shared library instead of static one. E.g. this will produce static library:

# CMakeLists.txt
add_library(lib lib.cpp)

// main.cpp
void f(){}

# run:
cmake . && cmake --build . # will make liblib.a

---

It's a bit annoying that I have to "undefine" BUILD_SHARED_LIBS flag which is made for *enabling* shared library builds, but if there's such strong opposition to idea, I will not insist on changing the defaults.

6
Feature requests / (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: April 14, 2021, 12:16:18 am »
I propose to not set  BUILD_SHARED_LIBS to "OFF" by default (except for platforms where static linking is not supported).

Some projects using CMake are building shared libraries which can be convenient for some people, but doesn't really follow what "BUILD_SHARED_LIBS" is meant to do.

See the docs: https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html
Quote
If present and true, this will cause all libraries to be built shared unless the library was explicitly added as a static library.

This makes "BUILD_SHARED_LIBS" opt-in flag. But currently I need to "opt-out" from building shared libraries, which is not convenient, as I expect that static libs are built by default, which is the convention that a lot of CMake projects follow.

7
I don't think that it's worth it to maintain custom functions which are implemented in standard library, thoroughly tested and optimized for specific processors... Currently trigonometric function are far from being bottlenecks for SFML.

8
Feature requests / Re: Axis 9 and 10 for proper Xbox trigger support
« on: March 04, 2021, 12:52:59 am »
SFML only supports eight axes, because you need to implement XInput support to support analog triggers. Changing the enum won't work.

See more info here: https://docs.microsoft.com/en-us/windows/win32/xinput/xinput-and-directinput#using-the-xbox-controller-with-directinput

Quote
The combination of the left and right triggers in DirectInput is by design. Games have always assumed that DirectInput device axes are centered when there is no user interaction with the device. However, the Xbox controller was designed to register minimum value, not center, when the triggers are not being held. Older games would therefore assume user interaction.

The solution was to combine the triggers, setting one trigger to a positive direction and the other to a negative direction, so no user interaction is indicative to DirectInput of the "control" being at center.

In order to test the trigger values separately, you must use XInput.

9
SFML development / Re: C++ standards
« on: March 04, 2021, 12:37:58 am »
Nice to see some activity happening here! Also I agree with most of the points here and I'm particularly glad that we won't overuse modern constructs like trailed return types or noexcept.

Quote
Occurrences of unscoped enumerations (enum) should generally be replaced with scoped enumerations. We would use the enum struct variant, not enum class, as enums come much closer to a "bundle of data" than "object-oriented entity with methods".

Can't agree with that one. I think "enum struct" is very obscure and more people use "enum class". For example, if you pick almost any modern C++ book - "Effective Modern C++", "C++17 The Complete Guide", "The C++ Programming Language", etc - all of them use "enum class" for their examples and don't even mention "enum struct" at all.
More examples:
Google C++ standards
C++ Core Guidelines
cppreference - "enum struct"s are mentioned, but "enum class" are used in examples.

Quote
override and final
final is mostly pointless in my opinion. override is very good - it should be added everywhere, because it's a clear indication where something is overriding base-class virtual function + it adds additional compile-time checks that function signatures match.


Quote
using everywhere, or just for templates
I think using should be used everywhere instead of typedef as using is much clearer in every possible way, but especially for function pointers and multi-word types. Some examples:

typedef unsigned char Uint8;
// can become
using Uint8 = unsigned char;

typedef void(*ContextDestroyCallback)(void*);
// can become
using ContextDestroyCallback = void(*)(void*);
 



Also it would be nice to have something about attributes like [[nodiscard]], [[maybe_unused]] and [[deprecated]]. They can be helpful for improving API's clarity (and when we'll need to deprecate something in the future).

10
SFML projects / Re: [Release][GUI] ImGui-SFML
« on: February 28, 2021, 12:07:32 am »
Wow, I wasn't expecting any further releases on this since you changed over to your own engine.

Thank you, this is really nice and helpful.
Nope, it'll be maintained because I love SFML and I care about it's community even if I don't use it myself. Plus, it's still the most easy way to use Dear ImGui from scratch (compared to SDL/OpenGL way) - that's another thing which makes ImGui-SFML so important.

11
SFML projects / Re: [Release][GUI] ImGui-SFML
« on: February 23, 2021, 02:09:47 am »
ImGui-SFML v.2.2 is released. It's small, but it felt wrong to not have a release for the whole year...

https://github.com/eliasdaler/imgui-sfml/tree/v2.2

This release is an accumulation of small things which are important to release:

    - Dear ImGui >= 1.80 is now required. ImGui added imgui_tables.cpp and some
    of the functions were deprecated. It's important to stay up-to-date

    - Fixed Image/ImageButton and sf::RenderTexture problems (texture was
    shown upside down)

    - Removed an overload for Image/ImageButton which took sf::Texture and
    sf::IntRect textureRect. You should use sf::Sprite now.

    - Added sf::Cursor::Hand

    - Restored C++03 support

    - Fix MSVC warnings

12
Feature requests / Re: Make the sf::Time friends constexpr
« on: May 20, 2020, 12:27:19 pm »
Also this means breaking C++03 compatibility. Laurent says he doesn't mind it, but to this day no one dared to do it.

13
I haven't been posting here lately, but here's the big thing:
https://eliasdaler.github.io/porting-to-sdl/

My game works on SDL now, and I feel like posting on SFML forums will be a bit weird. I want to thank all the people who supported me here when I was making Re:creation - this support was motivational and sometimes people helped me solve the problems I had with the engine development, so now it's working out for Tomb Painter very well.

I'll be still posting updates about the game on my site and Twitter, so check them out from time to time. :)

14
Graphics / Re: ImGui-SFML / problem with resizing cursor
« on: May 01, 2020, 12:19:34 am »
This is a relatively minor problem with no easy fix. In the past I've devoted something like 6 hours trying to find the solution, but didn't find any.

15
Great job! Looking awesome. :)

Pages: [1] 2 3 ... 40