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

Pages: [1] 2 3 ... 15
SFML development / Re: How should SFML handle non-legacy shaders?
« on: February 25, 2018, 03:38:11 pm »
Nobody said a modern sfml-graphics implementation couldn't co-exist with the current legacy implementation. That is the aim of this discussion. Once we figure out how to support modern shaders through the API, anybody is free to start work on a modern sfml-graphics backend.

If this is the case, then perhaps instead of creating the new Shader API alongside the existing one inside SFML for 2.X, could it be a good idea to first create an optional separate library for trialling a modern Shaders API, and then bring that API into SFML proper for 3.0?

SFML development / Re: How should SFML handle non-legacy shaders?
« on: January 22, 2018, 01:10:59 pm »
I think that Shaders are an advanced feature by default. If you're just starting out, one of the nice things SFML has going for it over diving into full OpenGL is that it abstracts those away until you are ready to deal with them. I'd go far as to say the argument could be made that Shaders are the most advanced feature covered by the SFML API.

Being advanced features I also think that this means there's more leeway in how much elbow grease is required. Given that, I would suggest that by default SFML 3 should opt for the modern non-legacy shader model only, and the API should be built with that in mind.

Legacy Shader support can then be provided by a 3rd party community-driven library. So long as there are sufficient hooks for SFML, which since you can get at the underlying OpenGL context there should be, these kinds of legacy features can be supported without needing to 'dirty' the main branch with them.

That way, if you know what you're doing well enough to use Shaders and to know you need the legacy shaders in particular, then SFML provides the tools you need to get at that, but without impacting the cleanliness of the main SFML APIs.

Yes, requiring an extra library does complicate the user experience some-what (though SDL gets away with it...like, a lot), but for an advanced feature like shaders I'm not sure that matters as much.

On the topic of getters/setters, I'd also say to remember: You may not need a setter.

In fact, I'd argue that most of the time you don't need a setter, since that means some basic detail of the object and be reached into and fiddled with, which is a break in the encapsulation and simply surrounding it in a function doesn't actually change that fact. Plus it just sounds dirty ^^

When you find yourself needing to have one object reach inside another and change some fundamental property, ask yourself...why. If it needs to change the speed...well, does it? Or is it, in fact, accelerating the speed. If it needs to change the position, does it? Or is it in fact that you want to move the object?

A moveBy that takes the change in position, and an accelerateBy that takes a change in speed preserves encapsulation a lot more than getter/setters that give the object the reach around. An an update function that does the moving and acceleration could perhaps be said to hide it even better, in classical OOP at least.

(Note: I'm sticking to talking about OOP self-mutating objects here, there's a whole world of other approaches I could go into, and you don't want me to get started on traditional OOP vs functional and/or data-driven since we don't have all day xD).

SFML development / Re: C++ standards
« on: November 14, 2017, 08:48:36 pm »
My reply wasn't targetted specifically at you, it was just a general comment to the discussion about "auto" ;)

My apologies, jumped the gun a bit there I'm afraid. Whilst auto as a whole doesn't affect the end user, it is one of those things developers love to get worked up about isn't it? Though the adoption of such things does raise a question as to whether adopting them risks putting off the 'old guard' of C++ developers (though I imagine auto would actually feel very familiar to developers used to most of the not-Java-or-pre-C++11-languages).

Actually, that is a thought I think I may have stumbled on in my needless clarification. A lot of the examples I see coming out of the C++ committee members of late seem to use auto fairly regularly, though that may be a selection bias on my part. This makes me wonder if the C++ committee are attempting or hoping to take C++ into an 'auto-first' mindset.

And if that is the case, that poses the question of whether SFML should follow suit. And likewise if that is not the case, I am experiencing selection bias and as a whole the C++ committee members are fairly auto-light or auto-middling, that poses the same question as to whether SFML should again follow suit and adopt their approach.

That then goes into should SFML seek to follow the lead of the C++ committee members in general or not in terms of code style (snake_case aside because....just...just because).

SFML development / Re: C++ standards
« on: November 14, 2017, 08:23:51 pm »
I was merely weighing in with a counter-point to the "being explicit improves readability" argument, namely that the fault could be said to lie in the functions name, and auto helps avoid being overly explicit and capturing what is actually meant, the type information being largely tangential or even a distraction to the user outside of documenting and capturing contract violations.

My last comment, that I understand why the SFML team would avoid doing so, was also not meant as in "not doing so would negatively impact me", but as in auto is relatively new to C++, and keeping closer to a style other long-standing C++ developers would be more familiar with, thereby not putting off developers from submitting pull requests for outstanding issues due to the code being 'too different from what they are used to', may be considered a reason to avoid heavy use of auto in and of itself.

Sorry that wasn't clear.

SFML development / Re: C++ standards
« on: November 14, 2017, 04:39:20 pm »
I'd actually argue that the problem there isn't auto, it's that using auto reveals "getLocalBounds" isn't sufficiently named and instead should be something like:
auto bounds = sprite.getLocalBoundingRect();

But I'm a "type deduce all of the things" type of developer. I use var almost exclusively in C#, and tend to favour the approach closer to functional languages where you let the compiler figure out at much as possible. Types are just the contracts of the code, and only exist to catch contract violations at compile time and to work with the names of things to provide self-fulfilling documentation for those contracts.

However, C++ being a recent addition to the world of type deduction, I'd understand if the SFML team were skittish about committing whole to it to such a degree.

General discussions / Re: SFML 3 - What is your vision?
« on: October 31, 2017, 12:40:19 pm »
Maybe SFML just looks higher-level, because it is designed nicely with an object-oriented approach? ;)

Like I said, sf::Sprite is something of the representation of why SFML confuses me with what level to put it at. sf::Sprite has functions to move it, scale it, rotate it, get global and local boundaries that can be used in simple collision detection. These make it conceptually more than a dumb object passed around to give information to SFML for rendering, it makes it a higher-level of object and even if that's not the intention it encourages people to use it as such.

I know the docs describe these as 'convenience functions', but I'd argue they expand the domain of the object considerably and make it something beyond what a low-level library would, or even maybe should, provide. So perhaps my critique is with the very existence of sf::Sprite as a render-level primitive.

I guess it just feels like using sf::Sprite to simply be a POD to pass a blit of an image, even a scaled and rotated blit, into SFML is a kind of conceptual overkill due to the presence of these functions, which makes me doubt that it's what I should be doing. All doubts flow from that point, I guess.

There are a few other things, like sf::Image having functions to load images from the filesystem that I'd like to see moved outside of sf::Image and into some kind of global function instead. Perhaps even moved out of sfml/Graphics entirely and into new packages that 'higher level functionality' like that can live (though C++'s library system as out-right clunky as it is, that's maybe a step too far).

Separates the loading of an image from the file system straight out of the definition of what an image is, having image loading even as a static function conflates it with the very idea of an Image, and having it as a local function makes sf::Image needlessly stateful. To my mind, Image shouldn't even have a default constructor at all, and should require some kind of data be passed to it for it to even exist.

I'm pretty sure that's been discussed already though.

But this is what I mean by SFML being higher-level, it's got conceptually 'higher' ideas like loading an image from the file system living side-by-side with conceptually 'lower' ideas, like creating an image from a byte array, and that muddies the waters somewhat. Or Sprites, with boundaries and moving, mixed up with Blitting, which is just "here is a texture, here's the section to draw, here's a transformation, have at!".

I guess you could say my vision for SFML 3 is for it to finish the job started all the way back when Image and Texture were separated into two classes: Remove all these mixed concerns from the code, to make it simpler, purer and more streamlined.

On the whole multi-renderer thing, I've found the main thing that makes cross-renderer abstractions tricky is Shaders. DX12 and OpenGL have different shader languages, so how exactly you can abstract that away (not abstracting the existence of the multiple shader languages obviously, but the creation and passing around of those shaders) is a design question that I've not found any really nice answers, just 'somewhat acceptable work-arounds'.

I think it's wrong to ask an asynchronous version of XYZ feature when you can simply do
auto result = std::async([](std::string filename){sf::Image image; image.loadFromFile(filename); return image;}, "blop.png");

True, file I/O is just the thing other languages have conditioned me to think of as async-by-default, otherwise you're holding up a system thread even if you create a new thread just for loading it. But the more I think about it the idea does not carry over to C++'s async/threading model as well (yet), since most of those languages have the idea of some sort of task pools baked into the language or standard library (even the newer 'low-level' languages like Rust and Go).

Although, if the std filesystem API were ever to go with an async-first design, I'd then argue SFML should follow-suit for file I/O (or if SFML got it's much-suggested Filesystem API, that could declare 'f-u' and go async-based from the ground-up. But C++'s futures API isn't quite there yet, maybe when it inevitably becomes monadic).

General discussions / Re: SFML 3 - What is your vision?
« on: October 31, 2017, 10:12:00 am »
I understand that. I guess what I'm struggling with conceptually is I'm not sure what level of abstraction SFML intends to live at inside a large codebase.

So inside a large project, is it intended that I be calling SFML directly all over a codebase? Or is it intended to be abstracted away and only exist in the code in discrete, easy-to-swap-out abstractions, so it can be replaced with another library, for example SDL2, if I need to target a platform that SFML does not support (not even meaning say consoles. For example, if I intend to compile to Wasm/asm.js).

The former, means SFML is held back by the opaqueness of it's implementation. Parts of it can't be easily swapped out or plugged in, it's a whole package and you take it or leave it. Yes that aids in it's simplicity, but at a cost of flexibility.

If the latter, then fair enough. This is almost always the approach I wind up taking. It can sit behind an abstraction in the code, even the graphics rendering itself can be abstract just have different implementations of "initialise" and "render this game state" functions, and the rest of the system can be none-the-wiser.

I think the thing that exemplifies this confusion for me is sf::Sprite. It's never been entirely clear to me whether the intention with a larger game is that sf::Sprite is used as a part of the representation of entities in a game, or is the intention that sf::Sprites are created at-draw-time given some other representation of an entities state.

Or take image loading. With something much higher-level like MonoGame, you can plug your own asset formats into it's pipeline and it can load them. With SFML, you can't do that. If it's intended to be wrapped up in a facade anyway, that's fine since you'll be abstracting away the image loading into something more general purpose, you'll create your own pipeline for it. If it's not intended to be wrapped, you'd expect it to expose hooks instead.

This is something I've always struggled with when writing things that use SFML, I'm not entirely sure where's it's intended to live. SDL2 is low-level, it feels right to hide it away. SFML is higher-level by it's very nature, it's part of the reason it's easier to start out with, so needing to hide it away like that almost feels a bit like 'missing the point'.

This is all possibly just a result of SFML managing to straddle that sweet-spot of being usable for both smaller and larger projects (which is definitely a good thing), so it's not so much a flaw as it is a result of it providing tools usable for both and leaving the rest to you. But it does result in it dangling somewhat awkwardly between a high-level library and a low-level library in some regards, and that s something that's been bouncing around my head for awhile now about SFML, and I've never been quite sure how to word it xD


On a less dramatic note, I'd love if Image/Audio loading returned an std::future or had a "loadFromFileAsync" variant that returned an std::future :) Embrace the non-blocking file-io of the future (future future)

General discussions / Re: SFML 3 - What is your vision?
« on: October 31, 2017, 12:50:03 am »
Sorry if this wasn't clear, but I wasn't specifically suggesting actually maintaining multiple official backends. The key point was more:
* "If SFML allowed for this, even if it only had one officially supported driver, it would serve to document *how* a person who needs to can modify SFML to support a different rendering platform, which at the moment feels more like going in and 'hacking SFML apart until it works'."

That and the interface-driven point, namely interfaces enabling mocking out of SFML for easier unit testing of code that calls SFML :)

General discussions / Re: SFML 3 - What is your vision?
« on: October 29, 2017, 01:45:59 pm »
Not sure if this has been brought up before, probably has, but it occurs to me a current limitation with SFML is that you cannot dynamically swap the underlying rendering platform at runtime. To use Irrlicht as an example, you can create DirectX drivers, OpenGL drivers, and Software Rendering drivers and decide on which one to use at runtime.

If SFML allowed for this, even if it only had one officially supported driver, it would serve to document *how* a person who needs to can modify SFML to support a different rendering platform, which at the moment feels more like going in and 'hacking SFML apart until it works'.

This could aid future efforts for support for new platforms that may not necessarily have any OpenGL access, and would make porting to DirectX, or even back down to older versions of OpenGL, or to Vulkan, or to a chosen version of OpenGL ES easier for people who decide they want to do so for whatever reason.

It would also keep a migration path open for developers if/when SFML moves up to newer OpenGL versions as they come out and settle, allowing for older ones to have official support deprecated without immediately breaking code and requiring a new major release.

Additionally, if SFML was also 'interface-driven' (which fits nicely with the above), then SFML could be easily mocked out when unit testing the graphics code, and that'd also be quite nice. At present you need to write a facade around SFML to accomplish this. Though I admit, not as many people care about unit testing their game rendering code as should darn it :P

Graphics / Re: Asynchronous loading of textures causes Stack Overflow
« on: January 27, 2016, 10:39:06 pm »
And somehow I missed all of those when searching *facepalms self* Now I feel stupid, sorry :)

Thanks for the speedy reply :) This is what happens when I come back to C++ and SFML after a long absence, I miss alllll of the stuff.

For the record, the reason I was attempting this is an experiment in multithreaded coding where the update tick is entirely asynchronous and event based. Loading assets in update before sending them where they needed to go seemed cleaner code-design wise with that pattern.

Graphics / Asynchronous loading of textures causes Stack Overflow
« on: January 27, 2016, 10:02:47 pm »
The following code, which is my attempt at recreating the issue, appears to cause a stack overflow with the latest version of master of SFML (Debug or Release) in Visual Studio 2015. It also seems to crash gcc version 5.2.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project).

Loading with std::launch::deferred (So single-threaded) does not appear to cause any issue, suggesting it's a multithreading-exclusive issue.

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <future>

int main() {

        sf::RenderWindow window(sf::VideoMode(320, 240), "Possible bug with multithreading");
        std::shared_ptr<sf::Texture> texture = std::async(std::launch::async, []() -> std::shared_ptr<sf::Texture> {
                std::shared_ptr<sf::Texture> result = std::make_shared<sf::Texture>();
                if (!result->loadFromFile("simple.png")) { // <-- this line causes a crash
                        return nullptr;
                return result;

        if (!texture) {
                return -1;

        sf::Sprite sprite;
        sprite.setPosition(sf::Vector2f(0.0, 0.0));

        while (true) {

                sf::Event event;
                while (window.pollEvent(event)) {
                        if (event.type == sf::Event::Closed) {
                                return 0;

Battling the visual studio debugger would make it look like the code is repeatedly jumping in SFML between four functions:
    sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 155   C++
    sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 213   C++
    sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61   C++
    sfml-window-d-2.dll!sf::Context::Context() Line 61   C++
And this endless recursive loop leads to stack overflow. gdb gives similar output when running 'where' after the segmentatiom fault.

It seems the newing up of a ThreadLocal sf::Context is triggering a call to getInternalContext, which then sees there is no internal context, so it then news up an sf::Context, which calls getInternalContext, which then goes on ad infinitum.

Is multithreaded texture creation currently broken? It's something I can imagine not being too rare a use-case, wanting to load assets in a separate thread from the main.

Ah fair enough :) Sorry, still unsure on proper protocol with github issues but you're right, should of waited ^^

The InputStream in the original example was taken from http://www.sfml-dev.org/tutorials/2.2/system-stream.php, but I updated the code above to use sf::FileInputStream and re-ran it. Still goes "BOOM!", so the internal openFromStream implementation falls own on something the openFromFile does not.

This used to work perfectly and still does for images, and (known issue aside) FLAC files. I haven't touched this part of the code, updating SFML to a new build of master broke what was previously working. And this happens on both Windows and Linux for me.

FLAC streams in master have an issue.

So that's an unrelated issue, good to know.

Btw I've tried the openFromStream on Ubuntu with the orchestra.ogg and I get the same error so...yeah, github issue time? :) Using streams instead of files is a fairly common usecase I reckon, since it lets you write a generic file loader that can abstract away reading from zip files and file files.

Sorry to double post but to add more to the current state of Audio playing:
So FLAC files can play from a stream, but they do not loop successfully. Changing the above code to setLoop(true) and call .play() results in music playing once and never looping, and the exiting of the application to hang on exit.

Hitting CTRL+C results in "AL lib: (EE) alc_cleanup: 1 device not closed" being logged.

Calling getStatus() on the music file still reports a status of sf::Sound::Playing

The above applies to both openFromStream and openFromFile music.

Pages: [1] 2 3 ... 15