Messages

1

General / Re: What image formats are supported?

« on: December 10, 2023, 06:00:46 am »

https://www.sfml-dev.org/documentation/2.6.1/classsf_1_1Image.php#a9e4f2aa8e36d0cabde5ed5a4ef80290b

The supported image formats are bmp, png, tga, jpg, gif, psd, hdr, pic and pnm. Some format options are not supported, like jpeg with arithmetic coding or ASCII pnm. If this function fails, the image is left unchanged.

2

General discussions / Re: VertexArray transformations

« on: November 19, 2023, 04:05:34 am »

It seems to me that you have a lot of memory leaks using "new".

Just a question, how do you expect it to be faster than individual draw calls? You still need to do all transformations and in case you need to "draw" your way texture more times, it means copying a lot of data which then you need to transfer to a graphic card opposite using texture on the graphic card and drawing it several times.

This is C# so there won't be a memory leak.

The draw call is usually what takes time, not the matrix math. So "batching" is a very common technique to minimize the time spent on minimizing the number of draw calls. All this function does it creates a vertex array from a rotated/scaled sprite; it still requires mapping to a packed sprite texture. You make few very (or one) very large vertex array and map each to a texture. That way you avoid texture swapping and can draw huge numbers of things with a single call.

3

Graphics / Re: Issue with converting Texture to Image

« on: September 18, 2023, 12:38:39 am »

https://www.sfml-dev.org/documentation/2.6.0/classsf_1_1Texture.php

https://www.sfml-dev.org/documentation/2.6.0/classsf_1_1RenderTexture.php

An sf::Texture and sf::RenderTexture are different things. You're looking for Texture.copyFromImage() not RenderTexture.copyFromImage().

4

SFML development / Re: Introduce chrono to sf::Time

« on: December 25, 2021, 12:41:42 pm »

https://github.com/SFML/SFML/commit/dfff93fe04c3633f38315608ecd8b51b0aafea86

5

Window / Re: program execution hangs on RenderWindow construction (sometimes)

« on: November 22, 2021, 07:14:00 pm »

This sounds similar to something I had. Ended up being Corsair's keyboard RGB software of all things. Anything with OpenGL rendering took 30+ seconds to load, it was ridiculous.

6

General discussions / Re: Concerned and Eager

« on: May 26, 2020, 05:18:51 pm »

Unfortunately, I agree with this sentiment. I love SFML for what it is, and it's still great for quick prototyping, but the lack of development is off-putting. Yes, I realize it's community based without a dedicated developer, but there have been features that get discussed for months or even years with back and forth banter that inevitably resolves to either "not in the scope of SFML" or "it'll break API, maybe in the next version." I agree that good discussion and planning is important, but what's the point of nothing comes from it? I'm discouraged to even try to expand and submit a PR because I feel the time will be wasted while it sits stagnant on GitHub to be discussed to death.

Small bug fixes and infrequent quality of life changes are always welcome, but the project as a whole feels dead. Maybe this is a bit abrasive, but the apprehension to move forward has left me disappointed over the last few years.

 

7

General discussions / Re: Any Zelda clone or hack and slash game on sfml?

« on: November 17, 2018, 03:19:09 am »

This isn't open source, but a lot of the development thought can be seen in the dev logs. https://en.sfml-dev.org/forums/index.php?topic=18062.0

8

General discussions / Re: SFML 3: Goodbye OpenGL?

« on: August 19, 2018, 09:33:22 pm »

There have been a number of discussions about this already:

• Apple deprecating OpenGL
• Will SFML support Vulkan?
• What's the future of SFML's OpenGL-based renderer?

And more if you search the forums. I agree though, it would be nice to abstract the underlying graphics library, but upkeep of each backend seems impossible with the small number of contributors. Some people advocate updating OpenGL, some say retain old/backwards compatible OpenGL, some say drop it and go to Vulkan. What about DirectX? Metal for iOS? There are interesting projects on GitHub that implement the Direct3D and Metal API's in Vulkan, but that would require dependency on more people, potential license issues, etc. There are a lot of possibilities, however the designing of the frontend (SFML) and upkeep of the backends (graphics library implementation) are very real issues.

9

SFML projects / Re: TGUI: GUI library for SFML

« on: August 06, 2018, 02:54:45 am »

Awesome, texus. I'm really glad to see 0.8dev become the main branch! I've been away from TGUI for a while but always come back to it when I have interface needs! So when is 0.9dev branch opening?

10

SFML projects / Re: Screenshot Thread

« on: February 16, 2018, 11:40:07 pm »

That looks awesome! It has a Strongohld look to it!

11

SFML projects / Re: Nero Game Engine

« on: September 26, 2017, 08:41:58 am »

I really enjoy reading your progress post and tutorials! It'd be cool if you had saving/loading working so you could include a complete project. Also, I can't play with it because you didn't statically link gcc runtime stuff or include the dll's.

12

General / Re: getPosition() is returning 0,0 when the sprite visable elsewhere

« on: April 22, 2017, 05:23:12 pm »

You're passing the towers to the check function by value so the class is getting copied. Is the copy constructor perhaps zeroing out the position? Try passing it by const reference instead. You may be having the same issue when you push_back into the vector.

13

SFML development / Re: sf::NonCopyable and =delete

« on: April 04, 2017, 09:17:52 pm »

When I heard about SFML my main attraction towards it was that it used C++ natively. I began with SDL but I wasn't a fan of C much. As I learned SFML and the community more, I really appreciated the attention the big names around here gave to language standards and ideology (Nexus, binary, etc.); I learned a lot from it. Furthermore, it seems the common consensus is to stick with language provided things as much as possible (getting rid of sf::Thread for std::thread for example) and adopt C++11/14 practices. As such, keeping sf::NonCopyable feels like a half-assed transition from the older language specifications. I appreciate that inheriting from sf::NonCopyable makes the intent of the class fairly obvious, but putting all of the constructors/destructor at the top of the class definition isn't that difficult and is still a very quick skim to get the full details. Finally, SFML's documentation is stellar. I rarely ever look at the source files if I wonder about something, and mentioning a class isn't copyable in the docs is sufficient I think.

14

SFML projects / Re:creation - a top down action adventure about undeads

« on: October 07, 2016, 12:03:06 am »

Hey man, I haven't been following this thread on SFML forums for a couple months, but I saw your post on Reddit just now. People are really shitty, and I'm so sorry you've got to go through something like this. I hope things work out for you and this doesn't discourage you from continuing this awesome project and your blog posts (I really appreciate them, especially the Lua stuff!). Best of luck, Elias.

15

SFML projects / Re: TGUI: GUI library for SFML

« on: September 29, 2016, 07:32:59 am »

The connect function is given by:

template <typename Func, typename... Args>
unsigned int tgui::SignalWidgetBase::connect(const std::string& signalNames, Func func, Args... args)

I'm not sure what the purpose of disallowing a function as an argument would gain? If you need it for safety you could edit the source and ensure that "args" isn't a function (std::enable_if<> and std::is_function<>) maybe though.