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

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

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.

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


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

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

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?

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.

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.

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

Did you not define SFML_STATIC? In bin you have dlls, which you don't need except for openal32.dll which is always dll due to licensing covering it. You also need to link all dependencies yourself if you link SFML statically.

Window / Re: Draw the window on top of other applications
« on: January 23, 2019, 02:22:17 pm »
"BringWindowToTop()" does not work.
Yes, it turns out it only worked when I had focus in the console of the program actually.

Yes, it works, where did you get that if you don't know these flags? You can read what flags do (NOMOVE and NOSIZE are obvious and that's why those 4 zeroes don't do anything and TOPMOST is why the window ends up on top) on: https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setwindowpos

Window / Re: Draw the window on top of other applications
« on: January 23, 2019, 12:41:17 am »
On Windows BringWindowToTop will put the window on top but it'll not steal focus/input. And yes, it's obnoxious.

Window / Re: Draw the window on top of other applications
« on: January 23, 2019, 12:00:28 am »
Does requestFocus do what you want?

Actually at least on Windows, it won't bring a window to front so on Windows try handle from getSystemHandle with: https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-bringwindowtotop

General / Re: Making a game playble on other computers
« on: January 19, 2019, 09:35:20 pm »
Yes, I'd say there's little point and if you ever make some mistake in your code that does it that destroys one bit or byte once in a while then you'll spend lots of time trying to find out what's wrong.

But a well made (non-solid and with not too high of a compression ratio) zip or 7z still has a point since one archive is faster to read from than many small files, you can even preload entire archive into RAM which would made it crazy fast or make one file shadow another (for patches, user settings, mods etc.). It'll also be smaller for average end user not only due to compression but also since loose files on disk waste a bit of space due to block size. For development you can still use loose files (that's the point/use of a virtual file system like PHYSFS) and just pack them up when sending the game to people, your game code stays the same.

Just remember to grab latest PHYSFS code from Mercurial since latest stable source code is broken on latest Windows 10 (and badly - you get a failed init + no error message or code at all).

General / Re: Static SFML unresolved external symbol
« on: January 19, 2019, 01:41:44 pm »
This doesn't affect the linking but your event loop should be a while loop and pollEvent doesn't always return an event so your code is now sometimes accessing an uninitialized sf::Event structure. You should also add clear and display to your main while loop. And your GPU and RAM amount also wouldn't effect the linking ;D , I wonder what it was though.

Pages: 1 2 3 [4] 5 6 ... 123