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

Pages: [1] 2 3 ... 5
1
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.

 ;)

2
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

3
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:

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.

4
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? :D

5
SFML projects / Re: Screenshot Thread
« on: February 16, 2018, 11:40:07 pm »
That looks awesome! It has a Strongohld look to it!

6
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.

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

8
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.

9
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.

10
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.

11
Feature requests / Re: File drop
« on: August 26, 2016, 08:21:45 pm »
SDL's API is exactly how I imagined SFML to have it. Really, all I'd want is a file path, I can get the name, figure out what to do with it, etc. myself. Still, we're going down the "SFML is not SDL so stop comparing" and "give us a proper usage case" road. It seems the consensus is it's not going to happen unless somebody can produce a working PR (even then who knows?).

I should clarify I love SFML despite the tone of my post; I use it almost exclusively. It just seems that development is very slow due to... excessive thoughtfulness? It seems a topic, suggestion, or PR can be beat around for months at a time with no real progress to be made.

12
SFML projects / Re: Super Mario game
« on: August 15, 2016, 05:37:06 pm »
Unfortunately, it still crashes for me as well:


13
SFML projects / Re: Witch Blast (dungeon crawl shooter)
« on: December 09, 2015, 07:25:34 am »
How did you do save/load games? Can you go into detail? Did you use serialization from boost library? I am very curious to hear your explanation.. I love the game, very nice.
It's open source, so you can view it yourself: https://github.com/Cirrus-Minor/witchblast/blob/master/src/WitchBlastGame.cpp#L6165

Cirrus Minor, you haven't made any changes to the dev branch in a month! Are you giving up on Witch Blast? :(

14
Feature requests / Re: File drop
« on: October 08, 2015, 10:58:28 pm »
I like this feature request. I think it would fit well as an sf::Event? For example, lets say you have a media player. It'd be nice to allow a user to drag a media file from the desktop and drop it into the media player instead of having to go through a file->open type of dialog.

Formally:
In which way is SFML limited?
SFML does not have a way to know if something was dragged (such as a file) onto the running application window.

What use cases does the feature allow?
Allowing the opening of media files for a media player, save game/project files in some sort of editor (such as a scene designer), or dropping links/images from elsewhere to be modified in app.

How can other users benefit from the change?
Having a mechanism to interact with outside media makes sense for Simple and Fast Multimedia Library. End user convenience is in the aforementioned part.


How would it be implemented? I don't know. I've never used this feature in a lower level language, so I don't know the underlying considerations necessary to make a good proposal here. Here's a rudimentary idea:

enum MetaType {File, Text, Unknown};

struct DragData
{
     sf::String Text;
     MetaType Type;
}

//....Somehow be given a DragData struct from SFML:
DragData data;
if (Data.Type == MetaType::File)
{
     std::ifstream File(Data.Text.toAnsiString());
}
 

Then a window can have a function or event that can return a DragData. I honestly have no idea what types would fall into the "MetaData" enum (again, I'm not really educated with this aspect), or how a window would handle multiple files or "DragData" structs dropped into the window at once.

Anyway, aside from my terribly ignorant implementation idea, I think the overall suggestion may not be a bad one. Especially if SFML will support file systems (I believe this idea was thrown around in the forums somewhere too).

15
SFML projects / Re: Witch Blast (dungeon crawl shooter)
« on: August 26, 2015, 07:16:07 am »
How's the progress coming?

Pages: [1] 2 3 ... 5
anything