Messages

46

Graphics / Re: Alternative to texture.update(pixelBuffer)? (too slow)

« on: March 11, 2019, 03:39:33 am »

Maybe OpenGL pixel unpack buffer could help here? SFML doesn't provide that though so you'd have to write your own code for that.

47

General discussions / Re: SFML featured in...

« on: February 26, 2019, 01:49:43 am »

Finnish YouTuber Bisqwit used SFML in two recent videos:

48

SFML development / Re: Removing dependency binaries

« on: February 23, 2019, 11:16:10 pm »

If user wants to link to system's dynamic binaries then doesn't it mean the bundled deps aren't built at all/CMake doesn't generate their projects/makefiles?

Is that related to SFML_USE_SYSTEM_DEPS? What does that one even do? If I check it in CMake with VS 2017 the Audio still references ogg, flac and others and Graphics references FT.

Right now the deps are static libs, get linked into dlls but not static libs (they were a long time ago but it was changed and now user must link them when linking SFML statically).

49

SFML development / Re: Removing dependency binaries

« on: February 23, 2019, 02:04:50 pm »

STB updates (2 years ago) produced huge diffs. No one ever mentioned that being a problem in any way and they are neatly stashed in a 'STB updated to x.yy' commit by themselves. Ideally no commits other than 'updated some lib or other to some version' will ever touch a given lib's dir. If a lib needs to be patched urgently because it derails SFML I'd rather it be done inline in the main repo too.

Most people using git might not even know submodules exist and if they do they will often not know the command off the top of their head (I fit into latter category). It's 1 extra command and more CMake checks for no real benefit to anyone.

The size of FreeType doesn't matter. Bigger (and less compressible) binary files are in the repo already. Amount of files doesn't matter either, git handles it, it's not some prohibitive amount (like thousands of files) and they will be stashed away in own dir and only touched by some 'FT updated to X.YY' commits. To build SFML you'd need to fetch it all anyway most of the time.

What do we care for git histories of deps? These libraries are ostensibly stable API solid C libs that will be updated rarely to some given x.y.z stable release version (so just how binaries were now except not in 5 copies of each anymore and without needing to build it all), not kept up to master or their repo where we need to debug them ourselves.

Even Qt repo linked in the first post doesn't use submodules for the third party libs. They dump all third party code into one repo and add a file saying what version it is in the root of their dirs. They discard all the history and produce huge diffs. I've seen them use submodules in some other repo (with chromium submodule for web engine and with their 'super repo' that is all submodules, maybe more) but that makes more sense for them than for SFML.

It's one more parameter or command (that most people don't know off the top of their head and even ones who know it might forget it exactly since it's such a rare operation to clone and build SFML) and extra checks in CMake, all for no real benefit/solving no real problem. These source dirs should be treated exactly like the binaries are now (except for there being like 5 version of the binaries) - totally opaquely, just changed once in a while in their own commit and used in builds (to build lib that then gets linked/installed) if the user doesn't check that 'use system deps' flag.

The reason why binaries are gonna be removed is not to ever work on these libs code but to make it more convenient to build SFML everywhere so adding submodules throws that small gain out the window instantly. Binaries were never a "I don't know what this binary's git history is" problem so just dumping C into the main repo is no worse from that standpoint either.

50

SFML development / Re: Removing dependency binaries

« on: February 23, 2019, 01:34:17 am »

I'd prefer just dumping all the C deps sources into the main repo. I can think of no upsides but only downsides to using submodules.

With submodules a simple git clone no longer clones the repo 'properly', a single commit/checkout is no longer all that you need to build SFML as it was in a given point in time and so on. It's not obvious at first what's even going on, what commands to use to get all the files in place, etc.

These C sources will be treated exactly like the binaries are now - dumped in there, used in configs where they are needed and updated once in a while. The advantage of few repos all pointing at one lib repo they all use doesn't apply here either since SFML is the sole 'end code' repo using all these libs.

Remove the binaries from the git repository, but instead include the source code of said dependencies and instrument our CMake build system to build the dependencies when building SFML itself.

This is exactly what I'd advise ('include the source code' as in - into the single SFML repo, no submodules).

This has the advantage that we cut down the size of the repo, remove the binary building maintenance cost on our side, can add more dependencies without mentioned concerns and if people want to, they can more easily modify or update the dependencies for their own needs.

Exactly. In (unlikely) case a change to a dep lib is needed there will be no wondering how main repo, submodules, commits, forks and so on all interact nor chasing submodule repos commit logs to find out who, when, where and why changed a thing (and what SFML commit said to reference that new commit's hash via the submodule). It'll all be a single SFML commit history instead.

Also, I assume since the binaries are gonna remain in the git history it'll be more like stopping the growth of repo size from each time new binaries appeared, not making it smaller, but it's still good.

51

Window / Re: Window resizing problem

« on: February 22, 2019, 06:39:23 pm »

He is using callbacks instead of events. SFML and SDL have events, GLFW has callbacks. I prefer events myself too. If you really want one over the other you can easily implement it yourself in own code in all these libraries without modifying them.

52

General discussions / Bisqwit using SFML

« on: February 21, 2019, 08:26:22 pm »

YouTuber Bisqwit used SFML in his OpenGL video from today.




It's not mine so I didn't put it in projects.

53

General / Re: Is this kind of Project even possible in SFML?

« on: February 17, 2019, 07:12:47 pm »

As he said he used OpenGL too. SFML lets you use own OpenGL code and OpenGL supports 3D.

54

Feature requests / Re: Image saving

« on: February 15, 2019, 03:28:12 pm »

And you're linking dynamically, right? Because there is a small issue with using your own STB image and image write along statically linked SFML: https://en.sfml-dev.org/forums/index.php?topic=25011.msg166598

55

Feature requests / Re: Way to use Window without GL (ALREADY DONE, woop), and maybe user data ptr in it

« on: February 15, 2019, 02:32:19 am »

¯\_(ツ)_/¯

It's not a big deal, it was just this chain of:

• SFML doesn't support something, e.g. drag and drop
• On Windows (arguably most common platform for games) you can do it yourself
• But you need a global (or make own subclass of one/two/three window classes) since SFML hogs the userdata pointer in window handle...

It's like two bads in one: not supporting a thing (which is fair) and getting in the way of someone ducktaping the feature on themselves (that's less nice).

56

Feature requests / Re: Way to use Window without GL (ALREADY DONE, woop), and maybe user data ptr in it

« on: February 13, 2019, 10:47:20 am »

Since this is for user data the only good way to do it that I can think of is void ptr that user then handles.

This is for situation like that one (this was example for how to do it yourself on Windows when someone requested drag and drop support again): https://gist.github.com/FRex/3f7b8d1ad1289a2117553ff3702f04af

I can replace the GWLP_WNDPROC to add handling of WM_DROPFILES but I can't use GWLP_USERDATA to store those paths I get somewhere since SFML uses that for sf::Window pointer. But if sf::Window itself had a user data field for people using SFML to use then I could retrieve that sf::Window pointer and do getUserData on it and cast that to my class and use it to stuff the filenames in there.

It's super niche I guess but I thought of it in addition to this first feature since both deal with sf::Window and maybe for something such a field in sf::Window (or rather sf::WindowBase) could be useful.

I'm not sure how it is outside of Windows, googling 'X windows user data' the only good result for me was: https://bugs.freedesktop.org/show_bug.cgi?id=12871

57

Feature requests / Re: Way to use Window without GL, and maybe user data ptr in it

« on: February 13, 2019, 09:58:24 am »

Well that's funny. I subscribe to RSS on the forum but not to GitHub issues so I didn't know.

And what about that user data part?

58

Feature requests / Way to use Window without GL (ALREADY DONE, woop), and maybe user data ptr in it

« on: February 13, 2019, 09:10:48 am »

Basically, SFML Window module is nice for input handling, and if someone knows how to use it they have two choices when they want to move to DirectX, Vulkan or use software: totally ignore the GL context or use something else.

So my idea is: why not add some flag to turn off/stop SFML from using GL at all, no creating context, no nothing.

This would allow someone to use DirectX, Vulkan or WinAPI themselves. It (making Window work without GL) could also be a stepping stone towards Vulkan coming into SFML in the future.


Woops, this was already done, I don't follow GH so I didn't know such a major thing got into there without going through here.

And a side idea is to add some user data pointer (just set/get void *). WinAPI has a user data pointer for the window handle, but SFML tucks its own Window pointer there. This came up when I did example of handling drag and drop with WinAPI and SFML. Getting list of filenames out of that message handler would require using a global variable or something like that, but if SFML Window had a user data ptr in it then I could get that pointer from window handle and from that pointer get my userdata.

59

General / Re: Having a hard time trying to get SFML to work with Visual Studio 2017

« on: February 09, 2019, 06:16:05 pm »

No, you need to copy (Ctrl-C, Ctrl-V) the dlls from bin near your exe.

Because of the license openal that SFML uses is under, SFML makes it always be a dll (even if you like audio statically).

Static vs. dynamic linking is broad topic and both have upsides and downsides.

60

General / Re: Having a hard time trying to get SFML to work with Visual Studio 2017

« on: February 09, 2019, 05:02:14 pm »

If you like dynamically you need to put the corresponding dlls from bin near your exe itself. If you link statically you need to define that macro and link all the dependencies yourself (there's a table in the tutorial) too. No matter what kind of linking you use, if you use audio then openal will be a dll (due to licensing).