Messages

1

General / Re: Exception thrown when attempting to run an SFML project

« on: April 17, 2020, 02:49:22 am »

It's due to that sf::Texture being global, it tries to access things that aren't ready yet when it's being constructed.

Although I can't now quickly find what code would fail (it might be loadExtensions at https://github.com/SFML/SFML/blob/master/src/SFML/Window/GlContext.cpp#L235 , it gets called eventually due to sf::Texture constructor being called, and it accesses globals, so there's the order conflict potential) or why and can't reproduce it but writing location 0x00000004 looks like attempt to write via pointer that's null.

Here's someone else's thread of similar issue years ago and answer is (and still is, I think) to not use globals because they might mess init order of SFML's own globals: https://en.sfml-dev.org/forums/index.php?topic=5654.0

2

SFML website / Links in Tutorials lead to outdated DoxyGen docs

« on: August 04, 2019, 11:32:51 pm »

Minor nitpick I just ran into.

They now lead to "Documentation of SFML 2.5.0" which has the "Warning:  this page refers to an old version of SFML. Click here to switch to the latest version." instead of "Documentation of SFML 2.5.1" which is now the latest one.

3

Graphics / Re: Commandline tool to convert svg files to png with optional scaling

« on: August 03, 2019, 06:44:19 am »

To be clear: ffmpeg can do jpeg and others to png. It can't do svg to png. ImageMagick can.

4

Graphics / Re: Commandline tool to convert svg files to png with optional scaling

« on: August 02, 2019, 07:20:36 pm »

ImageMagick can do it too if you have it installed or are willing to install it.

I once had a bunch of bmp files and wrote a similar tool to go from bmp, jpg, etc. to png ( https://github.com/FRex/topng/ ) because I didn't have ImageMagick and didn't want to install it just for this, but I later also found out ffmpeg also can do such conversions (and ffmpeg I do have installed) but mine is at least simple to invoke in find command or something.

5

General / Re: Link executable to work with all 2.x SFML libs

« on: July 21, 2019, 06:49:43 am »

I've seen app before bundle all needed files and use 'LD_LIBRARY_PATH' (see .wrapper script in these trial Linux versions): https://www.iforce2d.net/rube/#

There's also things like FlatPack and AppImage but I only ever heard of them as solution to this Linux distribution problem.

And SFML in repos is often out of date. :/

6

Graphics / Re: Array of rectangles

« on: July 08, 2019, 03:56:19 am »

std::vector has in it a copy of your original, this is how C++ works and it's different to Java and such.

Also: this isn't C question, you shouldn't use goto in C++, & is binary and - % is modulo.

7

Feature requests / Re: Image saving

« on: July 02, 2019, 05:39:32 pm »

Well, SFML uses void now because everywhere the buffer size is known and 'big enough'.

This can't happen with std::vector so a different API would have to be made to allow user to alloc a buffer and handle failure nicely, something like:

bool sf::Image::saveToMemory(void * buff, std::size_t size, std::size_t& outsize);

Where return bool would say if there was enough space to write it all out or not and outsize would always contain how much bytes would be written if there was enough space. Some C, POSIX and WinAPI functions do it that or similar way (like some signed size type as return and -1 there as error), even allowing calling with NULL ptr and 0 size to get just the output size but that's starting to get too un-SFML-like (and kind of cumbersome to use, I always wrap these myself to just do right thing with dynamic allocation in C and C++ when I need them or make sure the buffer is way bigger than required so they can't fail).

With std::vector (which I don't mind since it solves the size problem and SFML already uses STL a lot and isn't some tight no-lib-side-mem-alloc-ever low-level hardcore library) either char or uchar are fine. Either choice will have someone preferring the other one, since both have decent reasons for being used (char is 'default' byte type to use, and uchar has the nice property of being unsigned so no sign and sign extensions shenanigans take place).

Alternatively a callback function or class could be used and use a const void ptr there but that still leaves a sort of gap in API where reading can be done from 3 source (stream, file, memory) and writing to 2 (file, stream) with memory missing/part of stream (while for reading there is memory input stream but also outright loadFromMemory call that takes just const void ptr and size).

8

Feature requests / Re: Image saving

« on: July 02, 2019, 05:11:32 pm »

That part is there in C++98 and I've never heard of any 'padding' in chars (that'd then not be there for signed/unsigned chars). char, unsigned char and void ptrs get used to mean 'binary data' all the time in APIs.

9

Feature requests / Re: Image saving

« on: July 02, 2019, 04:42:58 pm »

What is that padding in char that you speak of? Char is often signed and that's the 'problem' but char, signed char and unsigned char are three same sized and distinct types (even though char is 100% like one of the other two).

10

Feature requests / Re: Image saving

« on: July 02, 2019, 02:42:03 am »

Audios yes but why fonts? There's a ton of ways to make an image and a few ways (stitch or mix two buffers, record, create samples programmatically) to make audio but there isn't any font editing/mixing/making in SFML. If you want to 'save' a font to a file in memory just take the file you're using and load it all into memory somehow and that's it there.

11

Audio / Re: Audio module, linker errors while static linking.

« on: June 30, 2019, 01:44:55 pm »

The missing functions are OpenAL ones. In first post you say you linked OpenAL but in your list in the second post it's missing. Can you double check that?

12

Network / Re: Build SFML for Steam on Windows

« on: June 29, 2019, 11:28:38 pm »

I'm assuming they meant that nothing special needs to be done on Windows where you just bring all the dlls or statically link all the libs you need?

13

DotNet / Re: Layer lighting help

« on: June 14, 2019, 07:01:17 pm »

Lights (of whatever colors) should be drawn with additive blending to the black texture (the order doesn't matter either), than that texture should be multiplied with the world (that is "100% lit" if drawing the lighting texture is off).

Here's an example: https://en.sfml-dev.org/forums/index.php?topic=22180.msg156718#msg156718

14

Window / Re: Error: Class 'application' does not have any field named 'window'

« on: June 13, 2019, 09:01:27 pm »

Remove the () from this line: sf::RenderWindow window(); //Creates a window

You also don't need sf::Event as a member, using namespace is not too good of a practice (especially std one), and you can call sf::VideoMode's static functions like: sf::VideoMode::getDesktopMode() instead of the way you do it now (instancing an object just to call a static method).

15

Graphics / Re: Drawing onto an externally-created context

« on: June 12, 2019, 06:56:27 pm »

SFML always creates its own OpenGL context, even if you embed it into an existing window.

This (yes, I see it's old 2018 post) is no longer true in code on GH btw if you don't want SFML's context: https://github.com/SFML/SFML/pull/1484

I don't think there's a way to make it use an external context.

Still true AFAIK.