Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: New graphics API ready  (Read 94299 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #15 on: December 03, 2011, 05:28:20 pm »
Quote
Anyway, the current parameter lists of sf::Sprite and sf::Text are a good compromise in my opinion.

Yes. So, applying the same design to shape classes, they should provide a constructor that takes all the properties that they declare (size for rectangle, radius for circle, ...).
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
New graphics API ready
« Reply #16 on: December 03, 2011, 05:59:57 pm »
Alright yay! :D

I'll get into testing as soon as I can. So far my walls are built up with shapes so they can't have textures. I'll now start looking into using VertexArray instead for that.

Though before I can start play around with it I have to track down an annoying graphical glitch.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
New graphics API ready
« Reply #17 on: December 03, 2011, 06:25:14 pm »
Okay, back to the star problem. Apart from "point" and "vertex", the term that soonest comes into question is "spike", but I'm not sure if it's really understandable.

But another question: Why do you want the user to access only the outer points (spikes or whatever)? I mean, he specifies the radius of the inner points, too. So he is aware of their existence, but has no access.

Maybe even one step further: Isn't a star shape too specific to deserve an own class in a basic multimedia library? Stars are rarely used as building blocks for more complex shapes. They are rather a nice feature for experiments, aka. "by the way, we have stars" ;) Additionally, I'd personally classify regular polygons (equilateral triangle, square) as more important. But in my opinion, both are a little bit too specific for SFML... At least that's my spontaneous view, perhaps this feature has been requested in the past.

To sum up, I think you shouldn't spend too much time on the interface of sf::StarShape, since stars are unimportant compared to the powerful new API, and they can be easily added later.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

JayArby

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
New graphics API ready
« Reply #18 on: December 03, 2011, 11:10:51 pm »
Stars might be real useful for particles, no?

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
New graphics API ready
« Reply #19 on: December 03, 2011, 11:13:38 pm »
Not really, too inefficient. A sprite with a star painted on it is much more efficient. When it comes to particles you want to limit as much as possible as of what you send to the graphics card as it becomes quickly the bottleneck. So increasing the amount of points is not good. (That's why with geometry shaders you can create the entire particle system on the GPU by sending data per cloud instead)
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #20 on: December 03, 2011, 11:20:53 pm »
Quote
So far my walls are built up with shapes so they can't have textures. I'll now start looking into using VertexArray instead for that.

Just to make it clear: shapes can have a texture with this new API.

Quote
But another question: Why do you want the user to access only the outer points (spikes or whatever)? I mean, he specifies the radius of the inner points, too. So he is aware of their existence, but has no access.

I don't want users to only have access to the outer points. It's just that StarShape::SetPointsCount defines the number of spikes, it's more natural like this.

Quote
Maybe even one step further: Isn't a star shape too specific to deserve an own class in a basic multimedia library? Stars are rarely used as building blocks for more complex shapes. They are rather a nice feature for experiments, aka. "by the way, we have stars"  Additionally, I'd personally classify regular polygons (equilateral triangle, square) as more important. But in my opinion, both are a little bit too specific for SFML... At least that's my spontaneous view, perhaps this feature has been requested in the past.

You're right, it's just to say "by the way we have stars", nothing more :mrgreen:
But it's the only valid shape that is not convex. So I thought it would be cool to provide it directly.

Quote
To sum up, I think you shouldn't spend too much time on the interface of sf::StarShape, since stars are unimportant compared to the powerful new API, and they can be easily added later.

So you suggest that I remove it, rename GetOutlinePoint/GetOutlinePointsCount to GetPoint/GetPointsCountand move them to the public part of sf::Shape?
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
New graphics API ready
« Reply #21 on: December 03, 2011, 11:45:27 pm »
Quote from: "Laurent"
Just to make it clear: shapes can have a texture with this new API.

I LOVE YOU! *cries a little* <3  :oops:
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
New graphics API ready
« Reply #22 on: December 04, 2011, 12:39:11 am »
Quote from: "Laurent"
I don't want users to only have access to the outer points. It's just that StarShape::SetPointsCount defines the number of spikes, it's more natural like this.
But then, GetPoint() is expected to return only points in this range, too -- that is, the outer points. If GetPointsCount() returned the number of all polygon points, you could have the convention that even indexes refer to the outer and odd ones to the inner points, just as an example. Or you provide additional methods like Get/SetSpikesCount() which halve that number.

Quote from: "Laurent"
So you suggest that I remove it, rename GetOutlinePoint/GetOutlinePointsCount to GetPoint/GetPointsCountand move them to the public part of sf::Shape?
Yes, I would provide GetPoint() and GetPointsCount() as an iteration interface. And if the sf::StarShape API doesn't conflict with the rest of the design, you can also leave the class ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
New graphics API ready
« Reply #23 on: December 04, 2011, 01:07:18 am »
Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.

Code: [Select]

Vector2f x = {1, 1};
Rectangle y = {1, 1, 2, 2};

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
New graphics API ready
« Reply #24 on: December 04, 2011, 01:15:54 am »
I didn't see the API yet, sorry, but I think a star class should be used as an example of a custom shape, either on sfml examples or provided at the wiki. It doesn't sound very useful as a built in feature of SFML.
Pluma - Plug-in Management Framework

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #25 on: December 04, 2011, 10:20:08 am »
Quote
But then, GetPoint() is expected to return only points in this range, too -- that is, the outer points. If GetPointsCount() returned the number of all polygon points, you could have the convention that even indexes refer to the outer and odd ones to the inner points, just as an example. Or you provide additional methods like Get/SetSpikesCount() which halve that number.

But there's no problem here, the two possible solutions are:
- leave everything as it is now
- rename SetPointsCount in sf::StarShape (to SetSpikesCount, for example), and set GetPoint/GetPointsCounts in sf::Shape public

Quote
Yes, I would provide GetPoint() and GetPointsCount() as an iteration interface. And if the sf::StarShape API doesn't conflict with the rest of the design, you can also leave the class

... and I still need to find a name for the "spkies" of a star :D

Quote
Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.

Yes, I'll probably add support for C++11 features in a future version of SFML 2.
Laurent Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #26 on: December 04, 2011, 10:59:51 am »
I've added constructors to all shape classes. And default constructors now create empty shapes.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
New graphics API ready
« Reply #27 on: December 04, 2011, 11:15:41 am »
When I add points to sf::ConvexShape, do they have to be oriented clockwisely? The documentation only speaks about "ordered", the following example doesn't create a line as expected. What do I do wrong?
Code: [Select]
#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

sf::ConvexShape cs;
cs.SetPointsCount(4);
cs.SetFillColor(sf::Color::Cyan);
cs.SetPoint(0, sf::Vector2f(20.f, 20.f));
cs.SetPoint(1, sf::Vector2f(20.f, 21.f));
cs.SetPoint(2, sf::Vector2f(140.f, 21.f));
cs.SetPoint(3, sf::Vector2f(140.f, 20.f));

while (window.IsOpened())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}

window.Clear();
window.Draw(cs);
window.Display();
}
}

And concerning the new semantics of SetPointsCount() and SetPoint() vs. the old AddPoint(): Is it always defined what happens when resizing? The problem is, there may now be invalid situations, when the amount of points is increased, but no new points are specified. Do these points get valid default values?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #28 on: December 04, 2011, 11:28:37 am »
Quote
When I add points to sf::ConvexShape, do they have to be oriented clockwisely?

This example is strange, for me the result doesn't depend on the order of the points, but rather on the thickness of the line.

Quote
And concerning the new semantics of SetPointsCount() and SetPoint() vs. the old AddPoint(): Is it always defined what happens when resizing? The problem is, there may now be invalid situations, when the amount of points is increased, but no new points are specified. Do these points get valid default values?

They are (0, 0) by default.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
New graphics API ready
« Reply #29 on: December 04, 2011, 12:01:50 pm »
Quote from: "Laurent"
This example is strange, for me the result doesn't depend on the order of the points, but rather on the thickness of the line.
At me, too, sorry. I just corrected it, but you were faster ;)

Might the problem be that you create two additional vertices in sf::Shape? Do you really need them? When I write an own shape class with direct access to sf::VertexArray, it works:
Code: [Select]
#include <SFML/Graphics.hpp>

struct MyShape : sf::Shape
{
virtual unsigned int GetOutlinePointsCount() const
{
return array.GetVerticesCount();
}

virtual sf::Vector2f GetOutlinePoint(unsigned int index) const
{
return array[index].Position;
}

virtual void Draw(sf::RenderTarget& target, sf::RenderStates states) const
{
target.Draw(array, states);
}

void SetPointsCount(unsigned int c)
{
array.Resize(c);
array.SetPrimitiveType(sf::TrianglesFan);
}

void SetPoint(unsigned int i, sf::Vector2f pos)
{
array[i] = sf::Vertex(pos, sf::Color::Yellow);
}

private:
sf::VertexArray array;
};

int main()
{
   sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

   MyShape ms;
   ms.SetPointsCount(4);
   ms.SetPoint(0, sf::Vector2f(20.f, 20.f));
   ms.SetPoint(1, sf::Vector2f(20.f, 21.f));
   ms.SetPoint(2, sf::Vector2f(140.f, 21.f));
   ms.SetPoint(3, sf::Vector2f(140.f, 20.f));

   sf::ConvexShape cs;
   cs.SetPointsCount(4);
   cs.SetPoint(0, sf::Vector2f(20.f, 20.f));
   cs.SetPoint(1, sf::Vector2f(20.f, 21.f));
   cs.SetPoint(2, sf::Vector2f(140.f, 21.f));
   cs.SetPoint(3, sf::Vector2f(140.f, 20.f));
   cs.SetFillColor(sf::Color::Green);
   cs.Move(0.f, 80.f);

   while (window.IsOpened())
   {
      sf::Event event;
      while (window.PollEvent(event))
      {
         if (event.Type == sf::Event::Closed)
            window.Close();
      }

      window.Clear();
      window.Draw(ms);
      window.Draw(cs);
      window.Display();
   }
}


Quote from: "Laurent"
I've added constructors to all shape classes. And default constructors now create empty shapes.
You should make constructors that can be called with one argument explicit. I always forget this, too... :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything