The new graphics API in SFML 2

[Laurent]

Perhaps incorporating the word 'crop' would be more descriptive, that's what is used in image editing programs to describe essentially the same function as SubRect.

Can "crop" be used as a noun? I thought it was only a verb, with no corresponding noun.

[Nexus]

It can, but I spontaneously think of cereals when I hear it
And "crops" is probably more widespread, at least according to my experience...

It actually isn't expressive at all, one has to know the term to understand it. That's why I prefer something like TextureArea (or TextureRect?).

[Lo-X]

That make me think... It is possible to add a method sf::Drawable::GetCollisionRect(sf::View&) ? which return a rect but already with proper coordinates ? Not too difficult to do it actually but, I ask... :p

[Laurent]

sf::Drawable will disappear. And what would the view argument be used for? Collisions are usually computed in global coordinates, while views are used only for displaying things in a target. Moreover, a rectangle in global coordinates can be rotated, which SFML doesn't support.

[Mikademus]

"sf::Drawable will disappear"

That will have a rather huge impact on my codebase. Currently there are functions that works along this way:

Code: [Select]


void func( RenderTarget &rTarget )
{
Drawable *pDrawable = 0;

switch (something)
{
   case st1: pDrawable = &mySprite; break;
   case st2: pDrawable = &myCircle; break;
   case st3: pDrawable = &myRectagle; break;
}

pDrawable->SetPosition( myPos );
pDrawable->SetRotation( myRot );
pDrawable->SetColor( myCol );

rTarget.Draw( pDrawable );
}


How will the removal of th Drawable interface affect my code?

[Nexus]

Laurent also said:

I think I'll create a Drawable base class, but it would only define a virtual Draw function, so that people can write window.Draw(object)

I understand his latest statement in the way that sf::Drawable disappears in its current state (with all the transformations).

And in general, templates are a possible alternative to dynamic polymorphism.

[Laurent]

That will have a rather huge impact on my codebase

I know, and you're not the only one
The current API is too limited so it needs a complete redesign. I'll try to keep high-level classes as close to their current version as possible, but abstractions such as sf::Drawable won't work anymore.

So your function would be a little more verbose, but depending what you want to achieve their may be better strategies with the new API.

[Nexus]

The current API is too limited so it needs a complete redesign. I'll try to keep high-level classes as close to their current version as possible, but abstractions such as sf::Drawable won't work anymore.

Now you confuse me

I don't expect a definitive statement, but do you currently tend to provide a sf::Drawable class (just as drawing interface) or rather not? If not, how are objects drawn? sprite.Draw(window)? Personally, I'd like a sf::Drawable class for those abstraction reasons.

[Hiura]

I was thinking about renaming "SubRect" in sf::Sprite. Would "TextureArea" or TextureRegion" be better?

TextureArea sounds better than TextureRegion because region doesn't always have fixed boundaries.

[Laurent]

Sorry for the confusion

I'm sticking with the latest conclusions:

Code: [Select]

class Drawable
{
private :

    friend class RenderTarget;

    virtual void Draw(RenderTarget&) = 0;
};

class Transformable
{
    position / rotation / scale / origin
};

class Sprite : public Drawable, public Transformable
{
    texture, texture area, color
};

[gsaurus]

TextureArea sounds better than TextureRegion because region doesn't always have fixed boundaries.

Area also does not suggest a rectangular area. Maybe TextureRect

[Mikademus]

SourcePixels

[Nexus]

I'm sticking with the latest conclusions:

Okay, I already thought about an own Drawable wrapper that would store high-level objects via type erasure to allow abstraction nevertheless

Code: [Select]

class Drawable
{
private :

    friend class RenderTarget;

    virtual void Draw(RenderTarget&) = 0;
};

So, Draw() actually replaces the old Render()?

I was thinking about renaming "SubRect" in sf::Sprite. Would "TextureArea" or TextureRegion" be better?

TextureArea sounds better than TextureRegion because region doesn't always have fixed boundaries.

And TextureRect sounds better than TextureArea because it indicates a rectangular area. Plus, it is closer to the existing term SubRect, making code porting easier.

SourcePixels

Not good in my opinion, since the sub-rectangle doesn't store any pixels.

[Mikademus]

SourcePixels

Not good in my opinion, since the sub-rectangle doesn't store any pixels.

SourcePixelRect
SourcePixelArea

You can't get more descriptive and explanatory than that.

[Hiura]

Well, if we have sf::Texture it's more consistent to have TextureSomething than SourcePixelSomething.

Now about the "something"-part, like Nexus said "rect" seems to fit the job for sprites as they are rectangular. But what about shapes ? If shapes also have texture ( ? ) then rect doesn't fit and having two different names can be confusing. So if they have texture then "area" seems better to me, otherwise I agree with TextureRect.