some suggestions

[tgm]

Hi, I started using SFML for some tiny 2D game...
Got some points that would make SFML way more comfortable to use:
1) Shader for sprites (at least Pixelshader)
2) Lines -> simple drawcall like App.Draw(Line(0,1,3,5)) -> draws a line between (0,1) and (3,5) (not sure about this one.. might be already implemented with:"Added a class to draw simple shapes (sf::Shape)")
3) a memory manager for resources (I know already on the list^^) but that ones REALY neccesary
Oh, and bevor I forget: GREAT Software!!!!
greetz

[Laurent]

1) Shader for sprites (at least Pixelshader)

It's already in my roadmap (I should really update the online one).

2) Lines -> simple drawcall like App.Draw(Line(0,1,3,5)) -> draws a line between (0,1) and (3,5) (not sure about this one.. might be already implemented with:"Added a class to draw simple shapes (sf::Shape)")

Yep, you can now do that :

Code: [Select]

App.Draw(sf::Shape::Line(P1, P2, Thickness, Color, [Outline], [OutlineColor]));

3) a memory manager for resources (I know already on the list^^) but that ones REALY neccesary

What kind of resource management are you thinking of ? As I'm still not sure of what to implement for it (a real manager, or just automatic update when resources get destroyed), I'd like to get your opinion.

[Lord Delvin]

An optional manager would be nice, as some of as(or at least my project) might have their own ressource management which might want to do things different.
And maybe you dont want to have some textures managed at all such as your logo, which appears so many times that it would be stupid to unload it.
Just my opinion.

[tgm]

I think some very simple version of res managment that will simply check wethere a file is already loaded and if so simply will return the already loaded one..
so lets say we create some extra (singelton) class that will check wether a given file is already loaded.. (by path, name and maybe size) for each loaded file it got a void ptr that will be casted to by a special factory class or something (so one could use the res managment for your own files) -should be reference counted

the manager got 3 main functions:
void *isLoaded("file")
void set("file",void *ptr) //if load returned NULL, the loader will give the manager the pointer of the file he did load
drop("file") //will decremten reference count by one and if zero -> delete the resource
so Image would ask the manager: is File ("blub/test.png") already loaded.
If the manager says: Yes it is! Here is the pointer to it: 0x00401234
The image class will simply say ok: The stuff is already loaded, simply return a pointer to it.
if it says:"Nope nothing loaded that looks like this!"
The image class would load it and give the manager the void ptr to itself.

Some other things:
The image::GetPixelsPtr () should return a read/write pointer since this would be way faster in some situations (copying huge amounts of memory  for example)
Maybe (woul be very cool.. I already coded this for Irrlicht so maybe I can do a port) Interpolated GetPixel (Linear Biqubic and Qubic)...
Accessing Vertex Color, Vertex Offset and vertex Texcoord might come handy for the sprites.

Some minor kind of collision detection  would be cool, too (though its not exactly a Media Layer thing.) But having a OBB class that features at least isPointInside(vector2D) and isCollisionLine (Line) and isCollisionOBB(OBB other)

And a last thingy: Drawables should get parents (other drawables). So every thing would be in the parents coordinate systems (Multipling the Parents matrix with the Childs Matrix at render Time) Extremly cool would be to be able to controll which porpertys depends on the parent.
(Like: My position is always relativ to my Parents one but neither my rotation nor my scale, or my sclae depends on my parent, but not my rotation and Position etc.)
greetz TGM

[Laurent]

Your manager is already too high-level for SFML. I mean, not everybody will want this kind of management. And it's more the job of an engine than a low-level API like SFML.

I was rather thinking to add a static function inside each resource class :

Code: [Select]

sf::Image& Img = sf::Image::Get("datas/image.tga");
// Loads if not already done, otherwise just return a reference to the loaded image
No need for an abstract void* manager (which is quite ugly BTW ), no need for reference counting and automatic unloading.

But I'm still not sure if it would be a good idea or not to add it myself.

The image::GetPixelsPtr () should return a read/write pointer since this would be way faster in some situations (copying huge amounts of memory for example)

I prefer provide such critical functions directly (and nicely wrapped) in sf::Image. Giving a write access to the internal buffer would be too dangerous for beginners.

Maybe (woul be very cool.. I already coded this for Irrlicht so maybe I can do a port) Interpolated GetPixel (Linear Biqubic and Qubic)...

For what purpose ?

Accessing Vertex Color, Vertex Offset and vertex Texcoord might come handy for the sprites

These informations are already available, but in a human-friendly interface (Drawable::GetColor, Sprite::GetSubRect, ...). I don't see the point of giving such low-level internal informations to the user.
Hey, it seems you just want to use plain OpenGL...

And a last thingy: Drawables should get parents (other drawables)

It's planned.  Although I'm not sure if I'll provide the choice of inherited settings.

Thanks for your suggestions.

[Avency]

An optional manager would be nice, as some of as (or at least my project) might have their own ressource management which might want to do things different.

I agree, since the implementation of a resource manager can heavily depend on what you are trying to achive.
Still, having an optional default manager could be helpful in certain situations.
But a file archives manager would be more useful and should be taken care of first (I know, it is already on the roadmap).

And a last thingy: Drawables should get parents (other drawables). So every thing would be in the parents coordinate systems (Multipling the Parents matrix with the Childs Matrix at render Time) Extremly cool would be to be able to controll which porpertys depends on the parent.
(Like: My position is always relativ to my Parents one but neither my rotation nor my scale, or my sclae depends on my parent, but not my rotation and Position etc.)

I like this idea. It could help to group drawables.

Edit:: Never leave the pc when writing a post  :wink:

[tgm]

Your manager is already too high-level for SFML. I mean, not everybody will want this kind of management. And it's more the job of an engine than a low-level API like SFML.

true.

I prefer provide such critical functions directly (and nicely wrapped) in sf::Image. Giving a write access to the internal buffer would be too dangerous for beginners.

is your SFML just aimed towards beginners? One question: If I would change something inside the read only buffer(tricking the const ptr by typecasting), would that actually change the image?

Quote:
Maybe (woul be very cool.. I already coded this for Irrlicht so maybe I can do a port) Interpolated GetPixel (Linear Biqubic and Qubic)...

For what purpose ?

Procedual textur generation (for example Perlin noise)

Quote:
Accessing Vertex Color, Vertex Offset and vertex Texcoord might come handy for the sprites

These informations are already available, but in a human-friendly interface (Drawable::GetColor, Sprite::GetSubRect, ...). I don't see the point of giving such low-level internal informations to the user.
Hey, it seems you just want to use plain OpenGL... Wink

true.. in a limited way. A Sprite always has to be a rectangel.. accessing the vertex offsets direckt would give one the power to distort the Sprite.. (maybe again a job for a Drawable subclass^^) -> same for texcoord
Accessing the Vertexcolor on per vertex base can be used for Lighting e.g.
Actually I like programming in pure GL.. (and cause you make it that easy to use pure GL in SFML I like it very much.. just had a look in the Drawable class - great simple OGL code in the render call :lol:)

[Laurent]

is your SFML just aimed towards beginners?

Of course not, it's aimed towards everybody. But an important thing in the SFML interface is that beginners should never get confused, lost or be able to do dangerous things. The first word of SFML is Simple

One question: If I would change something inside the read only buffer(tricking the const ptr by typecasting), would that actually change the image?

Absolutely not, that's why it would be a non-sense to get a write access.
Moreover, the Image instance and its OpenGL texture may have a different array of pixels because of potential padding.

accessing the vertex offsets direckt would give one the power to distort the Sprite.. (maybe again a job for a Drawable subclass^^) -> same for texcoord
Accessing the Vertexcolor on per vertex base can be used for Lighting e.g.

That's true for vertex offset and color. Maybe one day, if more than one person asks for it
But I disagree about texture coordinates : they are completely defined by the SubRect property. The only difference is that the coordinates are in pixel space instead of normalized space.

[tgm]

Quote:
One question: If I would change something inside the read only buffer(tricking the const ptr by typecasting), would that actually change the image?

Absolutely not, that's why it would be a non-sense to get a write access.
Moreover, the Image instance and its OpenGL texture may have a different array of pixels because of potential padding.

dammit.. didn't think about padding -_- sry  :oops:

But I disagree about texture coordinates : they are completely defined by the SubRect property.

and again mea culpa.... :oops: should read the manual more precisely
Vertex offset is not realy neccessary.. (Well, at least, I cannot imagine a real reason why one would have to use this -> allways able to make your own class on base of Sprite) But Vertexcolors might come handy..

[zarka]

hmm a nice resource caching would be real nice for images. something simple like this would probably suffice.

Code: [Select]


class Image
{
public:
static Image LoadImageFile(const std::string &path);
...
private:
static std::map<std::string, Image> mCache;
...
};


I'm not sure i would like a full fledged memory manager in SFML ... and if you do plan to add one you should make it easy to disable it so you can use your own

and if it's hunting memory leaks you want you can use vld (http://dmoulding.googlepages.com/vld) at least if you are using visual studio ...

[T.T.H.]

Hmm, my first thought about one of the suggested resource manager was "...and what happens with my pointer if I delete the resource or move it around in memory?". I guess I want to be in control of my resources, when they are loaded and unloaded. In case you need your logo so often, why not just store the image in a place where it stays over the whole lifetime of your application? I know that hugebigenginethings like e.x. Ogre3D have resource managers, but for something like images and sprites, do you really need resource managers?

I was rather thinking to add a static function inside each resource class :

Code: [Select]

sf::Image& Img = sf::Image::Get("datas/image.tga");

Some quick thoughts:
- how to unload that thingie? and do I need my own reference counting then?
- absolute vs relative file paths?
- thread safety? (two threads using the same sf:Image&)
- how would this work if I want to implement my own resource loading thread?


Regarding memory managers: as far as I know custom memory managers are needed very often when developing for any kind of consoles because their memory is usually your biggest limitation. In STL containers you can set your own "allocator" which is then used when new objects within the containers are created. But Scott Meyers, a C++ and STL guru, says a) when using allocations you really, really, really have to know what you're doing and b) it's actually quite hard to "be better" than the currently used memory allocators within modern STL implementations and modern C++ compilers.

[Laurent]

Good review of why I'm not so sure about providing such managers

But for sure, if I provide simple ones in SFML it won't be for advanced applications running several threads or using their own memory allocator. It's mainly for beginners, to avoid the "my sprite displays a white image, what happened ?!" just because they used a local sf::Image instance which has been destroyed. It's really troublesome for people to understand that they must keep their resources alive even after they assign them to the objects which will use them.

[tgm]

Well, I think you misunderstood me.. I realy ment a simple check wether a givenfile is already loaded, and if so it won't be loaded again^^
So you still got full controll over your ress.. you will load&unload them whenever you want... So "resource manager" might be a bit of

[T.T.H.]

...just because they used a local sf::Image instance which has been destroyed. It's really troublesome for people to understand that they must keep their resources alive even after they assign them to the objects which will use them.

My advice to them: "Learn coding! And to live without garbage collection..."

[Lord Delvin]

Learn coding!

Right.

And to live without garbage collection..."

Well. Thats only in most cases a good idea. In some cases its impossible or at least very hard to live without gc(that is, if you can have nameless objects) and in some cases (as for me for textures) the code is much faster with gc, as the gc knows everything, what is especially usefull if you can not know, which textures might be loaded, as the user of your game can load any amount of textures and you are unable to see that if you dont have a central texturemanager.
But i think in this case I have a somewhat special situation, as my users can do entire mods, not just add some units:)
But you are mostly right.