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 - Thrasher

Pages: 1 2 [3]
31
SFML development / Re: Allow for Limiting (Max & Min) Window Size
« on: April 27, 2023, 10:43:02 pm »
https://github.com/SFML/SFML/pull/2519

This PR is feature-complete and ready for testing and scrutiny.

32
How do you define this in the general case for all polygons?

33
SFML development / Re: Allow for Limiting (Max & Min) Window Size
« on: April 16, 2023, 06:52:30 am »
https://github.com/SFML/SFML/pull/2519

Work on this is well underway

34
SFML development / Re: sf::Clock should be renamed to sf::StopWatch
« on: March 17, 2023, 05:39:08 am »
Alternatively `sf::Timer` although "timer" may imply that it's counting down to zero instead of up towards infinity.

35
SFML development / sf::Clock should be renamed to sf::StopWatch
« on: March 14, 2023, 12:47:23 am »
A clock will tell you the time. This is what the clock on your computer, your wrist, or the wall tells you. It's also how the C++ standard uses the world "clock". A clock will give you a point in time.

sf::Clock does not behave that way. It only measures the elapsed time between two points in time. This is how it's implemented. It creates a time point upon construction then takes the difference between a new time point and the original time point to create a duration which is returned to the caller. Its interface exposes no concept of a point in time. It only understands durations. For that reason it ought to be renamed to sf::StopWatch in SFML 3. With that new name, it becomes much more natural to model the behavior of a stop watch, meaning adding the ability to stop and resume the timer at will.

We might even go so far as to rename sf::Time as sf::Duration since sf::Duration is homomorphic with a std::chrono::duration.

36
SFML development / Re: Allow for Limiting (Max & Min) Window Size
« on: March 05, 2023, 06:10:09 pm »
A way to specify a minimize window size would be great. The layout of your program is prone to break below a specific size so it makes sense to prohibit making it smaller than whatever that size is. I'm not sure what the use case of a maximum size is but I'm open to adding that interface.

My impression is that the X11 experiments about minimum window sizes showed that it was hard to get to get right. You say "it's basically impossible to fix, unless there's a minimum (or maximum) size defined beforehand.". Can you explain? If adding this API let us fix the X11 resizing issues that would be great.

37
SFML development / Re: How should SFML handle non-legacy shaders?
« on: February 20, 2023, 12:59:27 am »
https://github.com/SFML/SFML/issues/2423

I opened an issue to continue this discussion.

38
Feature requests / Re: (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: February 03, 2023, 11:48:15 pm »
https://github.com/SFML/SFML/issues/2389

I opened an issue to remove any reference to `BUILD_SHARED_LIBS` and thus change back to the CMake default of static libraries.

39
General discussions / Re: When roughly can we expect 2.6.0?
« on: January 13, 2023, 06:35:34 pm »
I'd prefer we set a deadline to release 2.6.0 in the next 30-45 days. If that means scan codes wait until 2.7.0 or 3.0.0 I'm fine with that. However I believe I'm the sole maintainer with this opinion so don't expect this to actually happen.

40
SFML development / Re: sf::Font Change & sf::Text Notification
« on: October 05, 2022, 01:25:20 am »
void sf::Font::onUpdate(const std::function<void(your-args-here)>&) is a compelling interface option to me. std::function provides all the utilities we need to easily implement this. I'm not convinced we need to support an arbitrary number of callables, at least not initially.

41
General discussions / Re: New SFML Team Member: Thrasher
« on: September 28, 2022, 12:55:25 am »
Honored to join! I've got a lot of stuff queued up for SFML 3 and really excited to see what we can make of it!

42
Window / Re: [OSX] setPosition inconsistency with getDesktopMode
« on: September 22, 2022, 05:26:05 pm »
https://github.com/SFML/SFML/blob/master/src/SFML/Window/OSX/cg_sf_conversion.mm#L94

This call to `scaleOutWidthHeight` takes the scaled resolution of my display (1728 x 1117) and converts it to the actual pixel values of (3456 x 2234). Removing that function seems to result in the corrected (scaled) size being returned. That solution feels wrong but maybe it will help lead us to a better fix.

43
Window / Re: [OSX] setPosition inconsistency with getDesktopMode
« on: September 22, 2022, 08:41:03 am »
I can recreate this with SFML master (3a3935d) on my Retina Mac. Unsure how to fix it but I can look into what may be going on.

44
Feature requests / Re: (CMake) Make BUILD_SHARED_LIBS=OFF by default
« on: June 20, 2022, 06:20:54 pm »
It's a very common source of frustration in the SFML Discord's #general channel having to copy SFML DLLs to the right directory to get their programs to run. I think it's worth reevaluating whether going against the CMake default is our best choice for SFML 3.

I'd love to hear more arguments for why some people think static libraries are "exotic." I've been writing C++ on Unix-y OSes for about 6 years now and static libraries always just silently worked and felt anything but exotic so I'm struggling to understand in more detail why the maintainers disagree.

Would you consider a middle ground solution where certain OSes default to shared libs and others to static libs? We have all the infrastructure to do that fairly easily.

Pages: 1 2 [3]
anything