A little more exposure... and smart pointers too.

[stubler]

I am using SFML for a rather non-traditional application. I am using it to animate a slide show. In doing so I have had to expose a few protected class members.

Reading large images fails because of texture size limitations. In order to load a large image, I have had to expose the ImageLoader. By doing so, I am able to read a large JPEG image and decimate it before creating a sf::Image using the LoadFromPixels function.

In animating the slide show, I often interpolate between transformation states. It would be easier to work directly with the transformation matrix. I see no reason not to expose GetMatrix as well as create a SetMatrix function.

I would also recommend some changes regarding images. Since images rarely change size, the overhead of STL vectors is not really justified. However, moving images around would be much easier if smart pointers were used to handle the allocation/deallocation of memory. In addition, if an image container also contained pointers to the start of every line, and appropriate operator[] functions were provided, then pixels could be accessed using doubly indexed notation such as: myImage[row][column].

Thanks for your consideration.

[Laurent]

Reading large images fails because of texture size limitations. In order to load a large image, I have had to expose the ImageLoader. By doing so, I am able to read a large JPEG image and decimate it before creating a sf::Image using the LoadFromPixels function.

This is more or less planned for SFML 2.
Basically, the concept of "image" needs to be split in two separate classes:
- one that loads/saves/manipulate pixels on the CPU
- one that represents a texture on the GPU that can be used by a sprite
However this would make the API too complicated and confusing (you would have to use 3 different classes before being able to actually display an image), so I have to think more about it.

In animating the slide show, I often interpolate between transformation states. It would be easier to work directly with the transformation matrix. I see no reason not to expose GetMatrix as well as create a SetMatrix function.

Matrices are purely an implementation detail, in the future the transformations may be implemented differently.
On the user side, there are only positions, rotations and scales. Why can't you interpolate these values instead of the whole matrix?

I would also recommend some changes regarding images. Since images rarely change size, the overhead of STL vectors is not really justified. However, moving images around would be much easier if smart pointers were used to handle the allocation/deallocation of memory. In addition, if an image container also contained pointers to the start of every line, and appropriate operator[] functions were provided, then pixels could be accessed using doubly indexed notation such as: myImage[row][column].

There's no need to store pointers to rows and provide an operator[]. An operator() taking directly x and y is cleaner and more efficient. It will probably be part of the class that I talked about above.

[stubler]

There's no need to store pointers to rows and provide an operator[]. An operator() taking directly x and y is cleaner and more efficient.

Your comment kicked off a discussion here at work regarding the relative merits of double indirection using row pointers vs. simply doing the pointer arithmetic. The final consensus was: it depends. It depends upon what you are doing algorithmically as well as the performance aspects of the compute environment in which you are executing. So I retract my request:

In addition, if an image container also contained pointers to the start of every line, and appropriate operator[] functions were provided, then pixels could be accessed using doubly indexed notation such as: myImage[row][column].

[Laurent]

There will also be function that returns a (non-const) pointer to the pixel array, in case you need something more direct than operator(). The latter will only be provided for convenience.

[Nexus]

I would also recommend some changes regarding images. Since images rarely change size, the overhead of STL vectors is not really justified.

Which overhead do you exactly mean, and what alternative do you consider? In case you are talking about dynamically allocated new[] arrays: They aren't really faster under the same circumstances (release mode and optimizations on). Concerning memory usage, the std::vector class itsself requires a few bytes like the size, and maybe begin/end iterators, which aren't relevant compared to the big amount of memory consumed by the image.

However, the allocation strategies of std::vector might be an issue. Imagine a policy that requests the double amount of memory at each reallocation. In the worst case, only the half of the allocated memory is in use. When dealing with a lot of images, this might indeed become a problem.

However, moving images around would be much easier if smart pointers were used to handle the allocation/deallocation of memory.

I think, an adaption on SFML's side would be too restrictive. Often, value semantics are enough, while the additional indirection results in a drawback. Additionally, storing a sf::Image in a smart pointer can be achieved by the user without much effort, so I don't really see the advantage of your suggestion.

[Spodi]

In animating the slide show, I often interpolate between transformation states. It would be easier to work directly with the transformation matrix. I see no reason not to expose GetMatrix as well as create a SetMatrix function.

Matrices are purely an implementation detail, in the future the transformations may be implemented differently.
On the user side, there are only positions, rotations and scales. Why can't you interpolate these values instead of the whole matrix?

Having the ability to set the transformation matrix (on the View) would allow us to perform other types of transformations, though. The only kind of rotation we can perform is on the X axis. It makes sense for strictly 2D, but its nice to touch up 2D with 3D-like perspective. For example, the "Mode 7" effect, which was recently requested by some of my engine's users ().

Exposing properties to just do all this stuff and keeping the matrix internal would work fine, too. I personally don't really care how it is done since I can see the pros and cons to both approaches, but more flexibility or exposure on it would be nice.

[Laurent]

The problem is that I can't extract the individual parameters (center, rotation, size if it's a view) from a custom matrix, so it's technically impossible to provide both features.

Providing more transformation attributes to drawables and/or views would be possible, what exactly would you need? 3D transformations (outside the XY plane) would probably require more 3D stuff like perspective projections, a Z component, a depth-buffer, etc.

[Spodi]

How opposed are you to adding transformations onto Sprite, too? Again, all I am interested in myself is the "Mode 7" thingy. Most all my graphics programming is 2d, so I may be wrong here, but I think it could be accomplished with just adding Y rotation onto sprites and the camera. Of course, if you have a 3d perspective, it only makes sense to be able to play with the Z axis, too, so you won't have to keep everything attached onto the floor. A depth buffer shouldn't be needed since the drawing order you use on top-down should still suffice since its still a 2d world.

For performance and simplicity reasons, these new properties could probably just be added to a specialized derived class of Sprite (Sprite3D?).

[Laurent]

I'm not opposed to adding new transformations (to the Drawable class, there's no need to createnew derived classes), but 3D... I'm not really convinced. I don't want to add perspective stuff and a Z component.