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

Pages: [1] 2 3 ... 602
General / Re: How do I finish my static CMake VS build?
« on: Today at 01:26:22 am »
Well if you want release libraries, you need to change the compiler to release build - this is about as basic C++/IDE knowledge as it gets and is pretty much expected before working with SFML. ;)

OpenGL, winmm, etc are system libraries and provided by the OS itself, so you just need to link them.

Read the tutorial on how to properly setup your VS project to work with SFML, especially the part about static linking and dependencies. ;)

General / Re: How do I finish my static CMake VS build?
« on: Today at 12:31:12 am »
You open the Visual Studio project, like any other Visual Studio project and then build the solution. If you've specified a reasonable path for CMAKE_INSTALL_PREFIX it's recommended to build the INSTALL project, which will copy all the libs and additional files neatly into one location. :)

General discussions / Re: PhysicsFS vs an SFML virutal filesystem
« on: January 18, 2019, 09:32:27 am »
I have split the thread as it was clearly off-topic.

Can I also ask to have a normal discussion here, without calling people trolls or being incapable to accept that others can have a different view point or a different personal preference, thanks. :)

General / Re: How do I pause an sf::Clock? (SFML 2.0)
« on: January 16, 2019, 09:12:20 pm »
There are two misunderstandings here.

Just because something has aged doesn't mean it won't work totally fine. sf::Clock and sf::Time have not changed in the past years and SFML 2.x is backwards compatible, so if it worked then, it will work now. ;)

The Wiki on GitHub is a community wiki, anyone can edit and contribute, as such it's by definition not an official code repository. My name is listed on a bunch of pages as the author, but that's just because I once brought a structure into the wiki, moving pages around and GitHub didn't track the history fully.

If there's something you have noticed not to work woth sftools, I suggest to open an GitHub issue on sftools repository. If there's nothing broken, then feel free to ignore the SFML 2.0 label. ;)

It's generally best to create a new thread unless it's 100% on topic. You can always just mention the thread you found and seen some parallels.

Most stuff that one is unfamiliar with will take a bit more time than expected. :D

Maybe the blur effect you picked is the wrong one.
As I said, I don't really understand how it works, but what you basically want to prevent is to combine the luminescence pixels with the transparent pixels, be it white or black. Instead you probably just want to have a gradient with the same color as the luminescence that decreases its alpha value from start pixel to the distance pixel.
So you basically have to make sure, to only deal with the luminescence pixels and to never sum/multiple it with the transparent pixels. At least that's my theory, whether that gets you the wanted effect, I'm not sure. ;)

I'm not familiar enough with GLSL to provide you an actual solution, but to me it seems you've already identified the issue that all transparent pixels are black. That isn't something that has to be the case, you can also have a "white" transparent pixel.

When you generate your luminescence image, can you make sure that the transparent pixel aren't (0,0,0,0) but (1,1,1,0) (or in SFML terms (255,255,255,0)?

Feature requests / Re: Define STB_IMAGE_STATIC and STB_IMAGE_WRITE_STATIC
« on: January 15, 2019, 04:44:28 pm »
Because we're only ever providing builds for three different VS versions. With VS 2019 getting released soon, that will be VS 2015, 2017 and 2019 which all use the Universal CRT (see here). I guess it's something to discuss with the rest and kind of off-topic here. :D

Feature requests / Re: Define STB_IMAGE_STATIC and STB_IMAGE_WRITE_STATIC
« on: January 15, 2019, 12:50:25 pm »
I'd rather pick the other option recommended in the SO answer to rebuild freetype with the "correct" VS 2015 version. Only question is then whether there could be some compatibility issues, but if it's just for an older version of VS 2015 or similar, then that's fine.

Soon we can drop the non MSVC universal libs, once VS 2019 comes out.

Feature requests / Re: Define STB_IMAGE_STATIC and STB_IMAGE_WRITE_STATIC
« on: January 15, 2019, 09:45:36 am »
Oh, I didn't want to sound ambiguous. :D

If there are no obvious down sides, then I don't see a reason, not to go ahead with it.

Feature requests / Re: Define STB_IMAGE_STATIC and STB_IMAGE_WRITE_STATIC
« on: January 15, 2019, 07:32:07 am »
Sure, why not. ;)

When initializing your animation object, you're never setting the frameSize/textureRect. It gets set for the first time in update(), but update() will call it for the first time once some some time had passed to fullfil the condition if(m_currentTime >= m_frameTime).

No, not next to CLion's executable, but next to your compiled SFML executable ;)

Feature requests / Re: Image saving
« on: January 14, 2019, 12:18:52 pm »
You could start now, because SFML 3 comes after SFML 2.6 and we don't really need to wait to get the first things started for SFML 3 IMHO. ;)

Feature requests / Re: Should VertexBuffer fallback to VertexArray?
« on: January 14, 2019, 10:37:32 am »
It's the same situation with shaders, if you don't check isAvailable() and shaders aren't supported on the end device, then you'll have a problem.
We already provide enough options, that we can trust the developers to do the right thing and implement checks and fallbacks if they really want to, instead of hand-holding them through every possible caveat.
Not to forget that vertex buffer is a OpenGL 2.1 feature, so we're still in deep legacy land here. ;)

The DLLs need to be next to your executable and not next to your project.

Pages: [1] 2 3 ... 602