Messages

1

Feature requests / Re: Image saving

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

The Pull Request is now open: https://github.com/SFML/SFML/pull/1597
Thank you for contributing in the discussion!

2

Feature requests / Re: Image saving

« on: July 04, 2019, 04:42:16 pm »

Unfortunately, this ultimately points us to asking even bigger questions, such as "what would sf::OutputStream look like?". And with the talk of switching to standard streams further on, it looks out of reach for the moment. Unless we could define an sf::OutputStream now.

For now, without implementing an output stream, we're looking at something like this:

bool sf::Image::saveToMemory(const std::string& format, std::vector<sf::Uint8>& buffer);

Or

bool sf::Image::saveToMemory(const sf::Image::Format& format, std::vector<sf::Uint8>& buffer);

With sf::Image::Format being an enum of png, jpg, bmp, etc. Although I personally feel that adding an enum is unecessary.

Discussion in the SFML Discord server pointed to a large preference towards sf::Uint8, so for the moment I plan on going with that.

3

Feature requests / Re: Image saving

« on: July 03, 2019, 10:29:08 pm »

Since saving to memory is not the typical game use case, it is probably occurring mostly when interfacing with a different rendering engine or image processing systems. Those usually have a rather low-level API based on char*/size_t pairs. Even if std::vector supports this format, for any scenario where ownership is transferred to a third-party system, the std::vector leads to a useless temporary copy.

Usually, these other systems have methods to load RAW RGBA data, which makes getPixelsPtr and width * height * 4 perfect for this use case. The whole idea of saveToMemory is to encode this data in a specified format. Otherwise we could just copy the internal pixel data.

std::vector is convenient, but I would add it only once we gather some knowledge about common use cases (e.g. which element type).

Two particular use cases I've ran into were the following:
1-) Saving a project file in json. One of the data types stored were base64 encoded images. Encoding directly from getPixelsPtr was particularly easy, however the final size transformed a 78KB JPEG into 5,6MB RAW RGBA. That's where saveToMemory comes in, encoding the image without accessing the filesystem (yet). By using std::vector, there is a minimal code difference here.
2-) A server application which modifies files and returns them through the network. Without adding additional libraries, saveToMemory could remove the need to write to the filesystem as a middleman, reducing SSD wear and API response times.

That said, a saveToStream really does sound like the better option, so we could propose something like:

bool sf::Image::saveToStream(sf::OutputStream& stream, const std::string& format = "png");

4

Feature requests / Re: Image saving

« on: July 02, 2019, 06:26:03 pm »

While I don't think it's a particularly good idea, nothing really stops us from having two overloads, one with char and one with unsigned char.

Particularly, I think using std::vector fits SFML a lot more, especially since getting an array from it is trivial. I suppose it just makes things a lot more simple.

5

Feature requests / Re: Image saving

« on: July 02, 2019, 05:14:37 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.

I see, good point. Well, then I personally have no preference for one or the other. What are your thoughts?

6

Feature requests / Re: Image saving

« on: July 02, 2019, 05:02:01 pm »

[C++11: 3.9.1/1]: [..] A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.11); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. [..]

From my understanding, this only became part of the standard in C++11, but I could be wrong.

7

Feature requests / Re: Image saving

« on: July 02, 2019, 04:36:31 pm »

One of the issues with any design is, that it would need to be adapted for audio and font as well.

While I'm not particularly familiar with the audio internals, I'll definitely take a look.

With the current design, one needs to be aware that the buffer can be resized by the save function. It should also be defined what happens with an already allocated buffer and with an over-sized buffer.

I can think of two approaches: clear the buffer before inserting data, or append the data to the end. Since it's a vector, it can be easily resized to either data.size() or buffer.size() + data.size().

Also one thing to consider whether sf::Unit8 is the best binary data representation.

If SFML's spec was set to C++11, then using signed or unsigned wouldn't make a lot of difference, execution-wise. However, since the idea is to target C++03 compilers as well, we need to remember that char can have some padding added to it by the compiler. While unsigned char has always been guaranteed by the standard to have no padding added to it iirc.
There's also the convention that char represents text while unsigned char represents binary data, although signed char could be used instead.
These are the points I can think of for unsigned, but I'd love to hear what everyone else thinks about it.

8

Feature requests / Re: Image saving

« on: July 01, 2019, 09:43:33 pm »

Of your idea of the method proposal, I would say the buffer would go first as the format could have a default.

So for now, this is the current syntax:

bool sf::Image::saveToMemory(std::vector<sf::Uint8>& buffer, const std::string& format = "png");

9

Feature requests / Re: Image saving

« on: June 28, 2019, 08:33:40 pm »

Before anything, sorry for reviving an old thread like this.

I've implemented a saveToMemory function and it has worked quite well for me.
I've been thinking of making a PR regarding this change, but first I need to know two things:

• Would this be a good idea?
• What syntax should be used for this?

In regards to the syntax, I've written something like:

bool sf::Image::saveToMemory(const std::string& format, std::vector<sf::Uint8>& buffer);

To be used as:

sf::Image image;
//fill the image with data
...
std::vector<sf::Uint8> buffer;
image.saveToMemory("png", buffer);

While this is perfectly functional, I feel like this API is very inconsistent with the rest of SFML. What is the general opinion about passing the buffer as a parameter? Also, should the format be determined using an enum? I'd usually go for that, but I wanted to be at least a bit consistent with the saveToFile API.

10

General / Re: DeltaTime

« on: January 13, 2016, 10:19:34 pm »

float dt = clock.restart().asSeconds();

is equivalent to

sf::Time time = clock.restart();
float dt = time.asSeconds();

dt has the same value both ways.

Oh, my mistake, I must've over-read it. I thought he did something like this:

time = clock.restart();
float dt = clock.getElapsedTime().asSeconds();

11

General / Re: Determining if player is on air/ground

« on: January 13, 2016, 08:30:42 pm »

You can check if player doesn't move down then he is grounded 

The problem is: I need to have this information in order to determine if gravity should be applied. Otherwise, the player will start going though the ground and coming back.

12

General / Re: Determining if player is on air/ground

« on: January 13, 2016, 05:46:09 pm »

Do you think this works?

        bool thereWasABottomCollision = false;
        for (auto &i : m_wmap->m_fixturerects)
        {
                if (rect.getGlobalBounds().intersects(i))
                {
                        float x = 0.f, y = 0.f;
                        if (rect.getGlobalBounds().left < i.left && i.left < rect.getGlobalBounds().left + rect.getGlobalBounds().width &&
                                rect.getGlobalBounds().left + rect.getGlobalBounds().width < i.left + i.width)
                        {
                                x += rect.getGlobalBounds().left + rect.getGlobalBounds().width - i.left;
                        }
                        else if (i.left < rect.getGlobalBounds().left && rect.getGlobalBounds().left < i.left + i.width &&
                                i.left + i.width < rect.getGlobalBounds().left + rect.getGlobalBounds().width)
                        {
                                x -= i.left + i.width - rect.getGlobalBounds().left;
                        }
                        else if (rect.getGlobalBounds().top < i.top && i.top < rect.getGlobalBounds().top + rect.getGlobalBounds().height &&
                                rect.getGlobalBounds().top + rect.getGlobalBounds().height < i.top + i.height)
                        {
                                y -= rect.getGlobalBounds().top + rect.getGlobalBounds().height - i.top - 2.f;
                                thereWasABottomCollision = true;
                        }

                        else if (i.top < rect.getGlobalBounds().top && rect.getGlobalBounds().top < i.top + i.height &&
                                i.top + i.height < rect.getGlobalBounds().top + rect.getGlobalBounds().height)
                        {
                                y += i.top + i.height - rect.getGlobalBounds().top;
                        }
                        move(x, y);
                }
        }

        if (thereWasABottomCollision)
                m_onair = false;
        else
                m_onair = true;

m_fixturerects is an std::vector<sf::FloatRect>, containing the tiles.

13

General / Determining if player is on air/ground

« on: January 13, 2016, 04:06:17 pm »

I've implemented some gravity and collision in my 2d side-scroller/platformer game, but i needed to know if the player is currently grounded or mid-air. I really can't think of anything, especially because I can't define a fixed minimum height (because of the tilemap i've implemented can have some weird combinations and i would like to avoid imposing limits to the level design).

Anyone has an interesting insight on this?

Maybe I'm just looking at it from the wrong perspective...

14

General / Re: DeltaTime

« on: January 13, 2016, 03:28:41 pm »

You are reseting the clock and storing the time as seconds after that, is that what you intended?
I might be mixing things up, but maybe you would want something like this:

float dt = clock.restart().asSeconds();

Then using it would be as simple as:

//Before the game loop
sf::Vector2f velocity(0.f, 0.f);
sf::Vector2f acceleration(0.f, 10.f);
...

//In the main loop
velocity.x = acceleration.x * dt;
velocity.y = acceleration.y * dt;

Then again, I might be mixing things up here.

15

Graphics / Re: Culling problem

« on: December 22, 2015, 05:16:07 am »

I think I got the hang of this, just one question: Is culling combined with the vertex array unecessary? I think it could potentially become a problem with really really big maps if it draws everything, but I could be wrong so...

Btw, thanks for all the help