Messages

16

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.

17

SFML projects / Re: Super Mario game

« on: August 15, 2016, 05:37:06 pm »

Unfortunately, it still crashes for me as well:

18

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?

19

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

20

SFML projects / Re: Witch Blast (dungeon crawl shooter)

« on: August 26, 2015, 07:16:07 am »

How's the progress coming?

21

SFML projects / Re: Witch Blast (dungeon crawl shooter)

« on: March 20, 2015, 09:22:40 pm »

Any update on the new release? It just looks and plays better and better each time!

22

General / Re: Implementing InputStreams

« on: February 04, 2015, 08:03:45 am »

I don't know what will do compiler's optimizer, but "isOpen" better as inline in header file.
I can share as I made it in my framework - https://bitbucket.org/SteelRat/gipe/src/711aa6630f0db3f277c4484ffc15f99051d368a3/src/filesystem/?at=default

I do agree, but using "inline" in a header file is unnecessary; implementations inside header files are implicitly inline anyway.

23

General discussions / Re: Conditional C++11 Support

« on: December 31, 2014, 04:30:59 pm »

Has there been any talk amongst the staff on the official verdict of C++11 (14?) usage in SFML 3?

24

General / Re: Artifacts left on screen on plotting program

« on: November 22, 2014, 02:34:58 am »

Ah right, bad logic on my end! Glad you got it figured out though. I can understand why you'd want to avoid clearing it every time, so you have a couple of options:

• Allocate the memory at the beginning of the while loop so the allocation happens once (the vector will not have to grow repeatedly).
• Write your own vertex array class.

A vertex array is just an std::vector<sf::Vertex>. You could write a nearly identical class to SFML's, but keep track of the actual "working" number of vertices. This way you can still use a growing vector, but when you write the overloaded draw() function, you will only draw up to the "working" size. This is probably the best approach if you're comfortable with it. Look at the source of sf::VertexArray and you can copy and paste almost all of it. Just add a member variable for working number of vertices and slightly adapt the draw function. For your convenience: https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/VertexArray.cpp

25

General / Re: Artifacts left on screen on plotting program

« on: November 22, 2014, 01:58:49 am »

Davitosan, you're code isn't bad; the mistake (I believe) is a very simple oversight. The sf::VertexArray isn't being cleared. So As you fill up the vertex array it gets bigger, but when you update the vertices to a smaller number than what was there previously (by making L less) it doesn't remove the unused vertices at the end. Simplying adding "points.clear()" at line 196 should fix your issue!

By the way, people of the forum are going to complain about posting a minimal example. Next time you should try to minimize the code you post; it's difficult in the case though.

26

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 24, 2014, 12:52:56 am »

Consistently being an asshole isn't going to get anybody to agree with you. The dev team takes API changes and additions into great consideration before allowing it to become merged. It's great that you're contributing and doing a lot of research for the community and SFML itself, but you don't need to be so pushy. Your contributions won't go unnoticed, but they won't be pushed in hastily either.
I do agree with you it'd be nice for a decision to be made soon (so that we can actually use this addition officially), but there's nothing wrong with considering the long-term usage and expandability of a potential addition to a maturing project. Perhaps there should be a poll similar to the one about SFML context handling which lays out the pros and cons of each option?

27

SFML development / Re: SFML Context Management

« on: October 02, 2014, 12:42:25 pm »

binary1248, I'm still not fully grasping the contexts fully. Are you saying that every sf::GlResource will not be freed until the termination of the program? I get what you're saying about having the internal context and looking at ways to prevent these unnecessary globals, but does the context sharing create serious memory leaks?

The way I see it, sfml-graphics has to be rewritten to build on top of sfml-window more than it does now. There is still too much coupling between the modules for my taste. Hopefully with the module restructuring in SFML 3, we can try to solve this issue as well.

Wouldn't that mean sfml-graphics would depend on sfml-window? That seems counterintuitive to the goal of reducing coupling?

28

SFML development / Re: SFML Context Management

« on: October 02, 2014, 05:55:29 am »

I have to agree with Tex Killer; I was attracted to SFML because of its hardware accelerated graphics and abstraction over the nasty OpenGL stuff. I feel that SFML should continue to manage contexts internally, but if you're considering an internal rewrite of the context management perhaps it's time to think about rendering backend abstraction as well. It would be a massive amount of work I'm sure, but being able to choose a renderer (OpenGL, DirectX, Apple's Metal?, etc) could attract a wider audience. Also this may allow development on different platforms to be easier; Android with ES, Apple with Metal (have they concluded if they're dropping OpenGL support fully in the future?), Windows with DirectX, OpenGL with everything else.

If you guys aren't going to consider going down that road my vote is to let SFML keep handling the context(s). Nothing stops people from using OpenGL directly in SFML, and those that don't want to don't have to.

29

SFML projects / Re: WideVM for particles

« on: August 27, 2014, 08:26:15 pm »

but that's what shader does right now - SFML uses GLSL on every supported platform, it uses the same syntax and functionality everywhere. even it optimize code for given GPU. it's doing the same what you did there and it's doing it better & faster

I don't think FRex is disagreeing with you; this is just a proof of concept. I think particles are just an example (because that's what the paper used), but the same idea of the VM can be applied to things other than shaders.

30

General discussions / Re: An interesting reddit post about SFML : "why_do_so_few_games_use_sfml"

« on: August 14, 2014, 05:36:49 am »

I thought this was funny: "SFML is slow, very slow, and the API isn't really that clean. It's so heavily OOP it doesn't feel natural to use and is more suited to a Java application."

I don't find it funny at all.
Did the person who wrote that post refer to benchmarks to support his statement that SFML is slow? Or is it just his opinion? To me it looks like an assumption.
As for SFML's API, my opinion is that the API is clean, and I quite *like* the OOP approach; it *feels* natural. But I know that many seasoned game programmers prefer to use C++ as "C with classes" and eschew most OOP paradigms; such programmers may well prefer SDL, since it's a C library and as such is well suited for programmers that prefer to limit OOP usage to the bare minimum. Maybe they should try and use SFML's C binding.

I think you missed my point: it was funny because of how ridiculous of a statement it was. I completely agree, the OOP approach feels very intuitive and I don't see how much cleaner the API can really be. Calling SFML slow and unclean is probably coming from one who dislikes C++. Odds are he's one of the guys that don't like C++ and share the Linus philosophy.

While some of the points are valid, I think a simple explanation of why SFML isn't more utilized is marketing. SDL and many of these other libraries have had time and usage. People see the SDL logo or "Made with SDL" so over time it's developed rapport. Unfortunately SFML hasn't had this publicity yet so dismissal is easy. We all know SFML>SDL any day .

If we use the criterion of the number of released games built with each library, that is debatable; since I don't have numbers nor know for any recently released title why either library was decided for or against, I won't spout an assumption. Like @binary1248 said, it's like comparing apples to oranges. What I *can* state is, I've used both libraries and I can honestly say that I prefer SFML, because I find it more suited to the way I work.

I too have used SDL and made the switch to SFML. I found it more straightforward and intuitive. The "modern" (don't kick me) feeling and approach to things as well as focusing on C++ over C made me switch. Also, hardware accelerated graphics and the ability to rotate an image without using another library was attractive to me. I have zero thoughts of ever going back; SFML may not have the same time and mass of released product but it's clearly the better choice for my needs.