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
SFML development / Re: SFML Roadmap
« on: June 28, 2023, 01:32:35 am »
I like this updated roadmap. We just merged yet another 2.6.1 fix so please keep using and testing 2.6.0 to find whatever remaining quirks there are so we can get them cleaned up.

When it comes to 3.0.0, I think the C++17-ification changes are almost done. Certainly there are no more big C++17 features to use. The remaining language usage upgrades are minor and/or can be done after 3.0.0 ships if need be.

As for API-breaking changes, those are harder to predict but I'd like to think most API changes are also done although some of the remaining API changes planned are pretty tough to write and test so don't expect them to get completed soon. My personal goal is to tentatively finish all these API breaks by the end of 2023 so we have time to let the API sit in a stable state while the final testing push occurs.

I expect we need on the order of >3 months of a stable API to be certain that what've written can withstand the test of time. I'm not sure where the other maintainers are at, but I'd like to ship 3.0.0 in the first few months of '24, hopefully soon enough to get it shipped into Ubuntu 24 LTS but that may be tough if we can't freeze the API by approximately November of this year.

General / Re: Help with Setting up SFML 2.6 with CodeBlocks 20.03
« on: June 26, 2023, 08:45:48 pm »
IS there a tutorial or any advice on getting this done.

Yes, Exploiter already gave the advice to use the CMake template here: https://github.com/SFML/cmake-sfml-project. Follow the instructions in the README. It uses normal CMake workflows so if you're familiar with CMake, this will just automatically work. It works on all OSes with all compilers and all IDEs.

General discussions / Re: Just wanted to say Thanks
« on: June 20, 2023, 10:19:46 pm »
I can't take credit for most of SFML but I'm still very happy to hear the kind words :)

SFML projects / Re: Selba Ward
« on: June 20, 2023, 10:18:39 pm »
So cool to see people building on top of v3!

Graphics / Re: Using sf::Text and sf::Font in Windows ×64 MinGW
« on: May 30, 2023, 09:49:49 pm »

If you come over to the Discord server you can get some help on this. There's a number of potential reasons you have linker errors

Window / Re: Clock in sf:Window
« on: May 17, 2023, 09:10:47 pm »

It's so funny you bring this up because I made this very PR yesterday! Please give this a thumbs up or approval if it's something you'd use.

SFML development / Re: RenderStates const ref in draw()
« on: May 10, 2023, 07:44:30 pm »

The previous version meant all draw calls necessarily copied RenderStates. Now that copy only happens when required. You have to explicitly make a copy if you want a copy but you're not forced to pay the price of that copy if you don't need it.

Is it a given that we still need 3 window types for the three use cases currently covered by WindowBase, Window, and RenderWindow? If we drop one of those use cases then I can see ways to simplify things but if we still need to support all three then I'm not sure what improvements are viable.

SFML development / Re: Allow for Limiting (Max & Min) Window Size
« on: April 27, 2023, 10:43:02 pm »

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

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

SFML development / Re: Allow for Limiting (Max & Min) Window Size
« on: April 16, 2023, 06:52:30 am »

Work on this is well underway

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.

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.

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.

SFML development / Re: How should SFML handle non-legacy shaders?
« on: February 20, 2023, 12:59:27 am »

I opened an issue to continue this discussion.

Pages: 1 [2] 3