Messages

1

General discussions / Re: SFML 2.5.0 released

« on: May 11, 2018, 12:42:51 pm »

I forgot to mention that SFML-2.4.2-windows-vc14-32-bit.zip is reported by only one of the engines, despite also containing said window.exe
I don't know to what extent these two files differ, but obviously, the AV engines seem to like the old version more ;-)

2

General discussions / Re: SFML 2.5.0 released

« on: May 11, 2018, 10:56:33 am »

Because AV stuff seems to be so much smoke and mirrors (and marketing??).
[...]

Thank you for your detailed answer (and thanks for all other answers, too). I also don't trust AV software very much (in fact, I'm not running any on my machines), but I found it noteworthy that so many engines seem to have trouble with this file. If it were only one or two, I would have dismissed it as a false positive.

I re-ran the scan, and now there are even 11 engines that claim to have found malware.
https://www.virustotal.com/#/file/ad50ded8aa8938373f853a4f3f43d3f4f496bb185df95cda86b10cb7851840b6/detection

window.exe is reported by 15 engines:
https://www.virustotal.com/#/file/a11d0bc18188d1dcdfa7cf75192fe992a71e1d0c1e51ed0248ed876501b11bf6/detection

What is this file supposed to do?

3

General discussions / Re: SFML 2.5.0 released

« on: May 10, 2018, 11:01:23 pm »

Any ideas why some AV scanners seem to think that SFML 2.5.0 for Visual Studio contains malware?

https://www.virustotal.com/#/file/ad50ded8aa8938373f853a4f3f43d3f4f496bb185df95cda86b10cb7851840b6/detection

4

Graphics / Re: How to use sf::Image:LoadFromMemory?

« on: February 05, 2017, 09:28:37 pm »

Thank you for the explanation.

5

Graphics / Re: How to use sf::Image:LoadFromMemory?

« on: February 05, 2017, 08:49:59 pm »

The size is not the image size, but the size of the memory block, so the function knows when to stop reading.

Thanks for the clarification
So it's basically the filesize of the image file in byte?

But I still don't quite understand why it is needed. If the function has a pointer to the start of the file data, it can (and probably must) read the entire file header to find out the image type, the bpp, and the dimensions. With all that information, shouldn't it be possible to calulate the size of the memory block? But perhaps I'm thinking too much in terms of uncompressed BMP images and it's more complicated for compressed image data?!

6

Graphics / How to use sf::Image:LoadFromMemory?

« on: February 05, 2017, 07:05:39 pm »

From what I have read in the documentation and some posts I found here in the forum, this function does not expect just an array of RGBA values, but an entire image (file) in memory, and therefore 'data' has to point to the first byte of the file in memory.
But if this is true, I don't know why the second parameter 'size' is needed and how it is interpreted.

If the function expects an entire file, it could determine the size of the image via the file's header, just as loadFromFile probably does (which doesn't expect a size). So I guess I understand something wrong here and hope that someone can explain why this parameter is needed.

7

SFML website / Re: Binaries for VC++ 2015

« on: September 06, 2015, 04:18:10 pm »

Oh yeah, they work
This was easier than expected.

Thank you for you help, and thanks for the good documentation and tutorials here on this site

8

SFML website / Re: Binaries for VC++ 2015

« on: September 06, 2015, 03:48:21 pm »

Sorry, you're totally right. The branch only contains binaries for SFML's dependencies -- but they're much more difficult to recompile than SFML itself. So, if you have CMake, it shouldn't take long to get working VS 2015 binaries for SFML 2.3.

Otherwise, eXpl0it3r provides nightly builds for VS 2015 RC, I'm not sure if they're still compatible.
http://nightlybuilds.ch/compiler/show/19/Visual%20Studio-2015RC-32/

In addition, some community members have provided binaries for VS 2015, but as they're not official, we cannot guarantee that they work:
http://en.sfml-dev.org/forums/index.php?topic=18243
http://en.sfml-dev.org/forums/index.php?topic=17455

I would recommend using the latest SFML version from GitHub (2.3.x branch, with binaries from the other branch) rather than pre-built binaries. Like this, you can benefit from newest features and bugfixes, and can give us feedback to improve things right away

Thank you. I'm glad I wasn't too stupid to find the binaries

I just installed CMake and will see if I'm able to built SFML as you suggested

EDIT:
Building the binaries worked. I copied the folders cmake, extlibs, and src from the VS2015 branch to the 2.3.x branch before running CMake and building.
Now I'll have to see if I the binaries are working

9

SFML website / Re: Binaries for VC++ 2015

« on: September 06, 2015, 03:19:27 pm »

Just in case it wasn't clear: the linked branch contains binaries that should already work. I'm using Visual Studio 2015 myself (but I haven't tested all configurations yet).

No, I didn't get that - thanks for the clarification.

The question might be stupid, but where in this branch do I find the binaries you mentioned? I only found binaries of external libraries needed to build SFML itself.

10

SFML website / Re: Binaries for VC++ 2015

« on: September 06, 2015, 02:59:22 pm »

It's a work in progress, see the feature/VS2015 branch on GitHub. It's a bit more complicated than you might think, because Visual Studio 2015 breaks compatibility to some C libraries.

Thanks for your reply and good to hear that you're already working on this

11

SFML website / Binaries for VC++ 2015

« on: September 06, 2015, 02:16:20 pm »

Hi there. Are there plans to include binaries for VC++ 2015 in the downloads for Windows? As the final version of VS2015 is released and available for download, I think these would be nice to have

12

System / Re: [SFML 2.0 RC] - Threads

« on: June 04, 2012, 10:23:39 pm »

It is implicitely included in the new API, as I showed you above

sf::Thread thread(&MyClass::Run, this);

(in case you didn't notice, thread can be a private member of MyClass and be initialized in the constructor -- so from the outside point of view there's no difference).

Yes, I did understand that - it's more the "nicer and cleaner" argument from above (and perhaps backward-compatibility) that made me miss the old API a little bit.

13

System / Re: [SFML 2.0 RC] - Threads

« on: June 04, 2012, 06:54:09 pm »

Yes, the new approach surely is more flexible, and I don't propose to replace it with the old one. I was just wondering why the old way wasn't kept as an alternative (especially as the old API also offered a similar constructor, taking a function pointer).

14

System / Re: [SFML 2.0 RC] - Threads

« on: June 04, 2012, 02:03:27 am »

Thank you for your answer.

It's cleaner because you don't inherit the public API of sf::Thread. It becomes a pure implementation detail. Well, you could use private inheritance but I think most people used public inheritance by habit.

I know too little about C++ inheritance - why is it a problem if a class inherits the public API from sf::Thread? Being able to call something like myObject.Wait(); seems quite natural if the object runs within a separate thread.

Oops, you're right. Sorry.

No problem. I just was not sure if I correctly understood the API at that point. I'm not very good with that template stuff - probably that's the reason I liked the old API better

15

System / Re: [SFML 2.0 RC] - Threads

« on: June 03, 2012, 08:10:49 pm »

I do not doubt that the new version is more flexible and powerful, but I'm not sure whether it's really cleaner.

If you have a class where each object should be 'active' (i.e., a separate thread), the old approach was well-suited and clean. I guess you could put the code you posted in the constructor of such a class to achieve that there's a thread per object without having to deal with Thread objects outside that specific class, but the resulting code  doesn't seem to be cleaner or simpler.

btw: Shouldn't the parameters in your example be the other way round? I don't find a matching constructor in the documentation.