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

Author Topic: New graphics API ready  (Read 94303 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 #45 on: December 05, 2011, 08:27:02 pm »
I also forgot to say that textures can now be repeated (SetRepeated / IsRepeated).
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 #46 on: December 06, 2011, 12:10:07 am »
Why couldn't you keep the AddPoint function on shapes? Ineffective sure but it's easier to get up and running and I don't see how it would interfere with the rest except being a nice natural way to add points with :)

Ow yeah on a side note, currently I'm doing my inter-thread messaging a bit lazy.... All I do is more or less send an ID, a drawable and what to do with it. Like a SpriteUpdate message would have me do a simple operation like:
Code: [Select]
*mySprites[ message.id ] = *message.spritePtr
And the same for shapes.

Though with this new API I am guessing that drawables will get heavier and I should start and do it properly? (Wrapper class on logic side and only have SFML stuff on render side)
Or will I still be able to stay with this lazy approach? :P
The less I need to implement the better ^^

Also maybe just me being lazy, but how about a GetSize and GetPosition on Rect classes? Just convenience functions really but would make code more elegant :)

Edit: Just did the conversion, holy shit ballz it's slow XD Just did it quite fast and ugly and will start looking at what is actually slow but daaaamn. I am having seconds per frame :P Must be stupidity on my side.
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 #47 on: December 06, 2011, 07:34:16 am »
Quote
Why couldn't you keep the AddPoint function on shapes? Ineffective sure but it's easier to get up and running and I don't see how it would interfere with the rest except being a nice natural way to add points with

In what kind of situation would it be significantly better than using SetPointsCount + operator[]?

Quote
Though with this new API I am guessing that drawables will get heavier and I should start and do it properly?

It depends. Drawables are now heavier to copy, but it may be even heavier to update their internal vertex array after updating one of their properties. So it's up to you to decide wether you want
- lightweight messages, no heavy copy but potentially expensive updates of objects
- bigger messages, a big copy to update the objects but no expensive operation

Quote
Also maybe just me being lazy, but how about a GetSize and GetPosition on Rect classes? Just convenience functions really but would make code more elegant

I find it strange to be able to write both rect.Width and rect.GetSize() (direct access vs function call). These functions can easily be implemented outside the class.

Quote
Just did the conversion, holy shit ballz it's slow XD Just did it quite fast and ugly and will start looking at what is actually slow but daaaamn. I am having seconds per frame

Quote from: "Laurent"
Please focus on the API, there's no optimization yet so the performances are worse than before
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 #48 on: December 06, 2011, 12:29:30 pm »
Quote from: "Laurent"
In what kind of situation would it be significantly better than using SetPointsCount + operator[]?
None actually, I just find it natural and easier to use. Also in a case where we want a variable amount of points it would be easier. Though the more efficient way would be to discover the amount and do the SetPointsCount way of course.

Quote from: "Laurent"
It depends. Drawables are now heavier to copy, but it may be even heavier to update their internal vertex array after updating one of their properties. So it's up to you to decide wether you want
- lightweight messages, no heavy copy but potentially expensive updates of objects
- bigger messages, a big copy to update the objects but no expensive operation
Hmm sounds like I should wait and see and see how it becomes. Do small scale tests of both ways and profile them.

Quote from: "Laurent"
I find it strange to be able to write both rect.Width and rect.GetSize() (direct access vs function call). These functions can easily be implemented outside the class.
Well it's just that I often will have to write:
Code: [Select]
sf::Vector2f( sprite.GetGlobalBounds().Width, sprite.GetGlobalBounds().Height )
And having a simple sf::Rect::GetSize that does that for you would just be for convenience.

Quote from: "Laurent"
Please focus on the API, there's no optimization yet so the performances are worse than before

Well yeah I did read that but I was very surprised in the difference. So my initial thought was "I must have done something wrong"
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 #49 on: December 06, 2011, 12:54:05 pm »
Quote
None actually, I just find it natural and easier to use. Also in a case where we want a variable amount of points it would be easier.

Ok, I have to think about it. I guess adding Clear() and AddPoint() wouldn't make the class ugly ;)

Quote
Well it's just that I often will have to write:
Code: [Select]
sf::Vector2f( sprite.GetGlobalBounds().Width, sprite.GetGlobalBounds().Height )

Write a GetSize(sf::Rect<T>) function ;)
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 #50 on: December 06, 2011, 12:59:48 pm »
Lol I like how my game lags a lot but my logic update time is still 0ms / Update ^^

Anyway I haven't seen any direct bugs or anything like that. I could more or less copy-paste this thing in. The only thing needed to be changed was sf::Shape to sf::ConvexShape

And you said you added texture support? I only see a SetTexture.... So...it calculates UV itself? OMG THAT'S SO SWEET! Time to texture my walls! Finally :D :twisted:
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 #51 on: December 06, 2011, 01:16:26 pm »
Quote
it calculates UV itself? OMG THAT'S SO SWEET! Time to texture my walls! Finally

By the way, why don't you use sf::Sprite for your textured walls? Do you have non-rectangular walls? If so, I hope that it's not to fake a depth effect, because texture mapping will most likely not produce the result that you expect.
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 #52 on: December 06, 2011, 01:24:56 pm »
Quote from: "Laurent"
Quote
it calculates UV itself? OMG THAT'S SO SWEET! Time to texture my walls! Finally

By the way, why don't you use sf::Sprite for your textured walls? Do you have non-rectangular walls? If so, I hope that it's not to fake a depth effect, because texture mapping will most likely not produce the result that you expect.


DANG! Ah well I'll look into it tomorrow or something like that. Worst case, I just write my own custom drawable class to handle it ;)

You can see what I do here: http://youtu.be/CdcDim0yR70
The white shapes, are the wall shapes, and will probably be a custom class later. Depending if I get it general enough, should I share it with you?
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 #53 on: December 06, 2011, 01:36:31 pm »
I think you'll have to modify many things to get correct perspective mapping. So... why don't you do true 3D directly :?:

What's the purpose of a fake 3D renderer?
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 #54 on: December 06, 2011, 02:07:06 pm »
Quote from: "Laurent"
What's the purpose of a fake 3D renderer?
It's fun :D

Well most basic reason. But I actually like the look and at Nordic Game Conference I attended a seminar where they talked about how limitations fuel creativity where they mostly refereed to the just released Nordic indie game Limbo. (And to honest they only talked about the graphics, but programming a game makes you into an artisan as well as it is a form of art ;) So the same applies to us)

And getting correct look without perspective correct textures are possible. Doom uses Affine texture mapping ;) Doesn't look bad. It all depends on the angle and I only have one angle really. That's why it is possible for me to fake the 3D at all.

Characters and objects will be a bitch to work with it :P But most probably they will just be flat sprites drawn in a 45 degrees angle in the drawing application. So it becomes a 2D "people" in a 3D world :P
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Haze

  • Full Member
  • ***
  • Posts: 201
    • View Profile
    • Github Profile
New graphics API ready
« Reply #55 on: December 06, 2011, 04:09:57 pm »
Hi, I've only tested the new API a few minutes, this is just an early feedback.

- I wish RectangleShape had a ctor which doesn't require a Vector2f object:
Code: [Select]
RectangleShape(float Width, float Height);

- Why did you rename sf::Blend::XYZ to sf::BlendXYZ?

- Where are the blend mode methods gone? (GetBlendMode/SetBlendMode)
Shouldn't they be implemented in sf::Drawable?

- I also miss several methods on transformable objects:
SetX, SetY, GetSize
Even if such operations can still be performed, I miss those higher-level methods, which I found convenient and avoid writing code like this:
Code: [Select]
sprite.SetPosition(42, sprite.GetPosition().y)

instead of:
Code: [Select]
sprite.SetPosition(42)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
New graphics API ready
« Reply #56 on: December 06, 2011, 04:22:17 pm »
Quote
I wish RectangleShape had a ctor which doesn't require a Vector2f object

Already discussed in previous pages ;)

Quote
Why did you rename sf::Blend::XYZ to sf::BlendXYZ?

For consistency. I don't think it changes the user code significantly.

Quote
Where are the blend mode methods gone? (GetBlendMode/SetBlendMode)
Shouldn't they be implemented in sf::Drawable?

It is in sf::RenderStates. Basically, you can now write this:
Code: [Select]
window.Draw(sprite, sf::BlendNone);
sf::Drawable has a different role now, it's not supposed to provide any service other than a Draw function.
It could be added to each high-level class (sprite, test, shape), but I'm not sure that it would be necessary.

Quote
I also miss several methods on transformable objects:
SetX, SetY, GetSize

I tried to cleanup the API a little bit. There was too many functions in drawable entities.
Let's see if enough users want them back ;)
Laurent Gomila - SFML developer

Haze

  • Full Member
  • ***
  • Posts: 201
    • View Profile
    • Github Profile
New graphics API ready
« Reply #57 on: December 06, 2011, 04:48:47 pm »
What a fast replay, as always :)

Quote from: "Laurent"
Quote
I wish RectangleShape had a ctor which doesn't require a Vector2f object

Already discussed in previous pages ;)

Missed this request, my bad!

Quote
For consistency. I don't think it changes the user code significantly

Indeed that's really no big deal, I was just curious.

Quote
Basically, you can now write this:
Code: [Select]
window.Draw(sprite, sf::BlendNone);

Ok! It seems fine as well.

Quote
I tried to cleanup the API a little bit. There was too many functions in drawable entities.
Let's see if enough users want them back ;)

Oh, it wasn't that bloated, IMHO.
To be honest, I would even take it one step further and request some extra GetX / GetY methods...

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
New graphics API ready
« Reply #58 on: December 08, 2011, 08:58:25 pm »
Is this a bug? I remember it looked like this if I turned on outlines on the old shape class but this just became visible when I added a texture to my shapes.



Also does it matter the order I create/use points with for the UV-coordinate generations? Let's say I would like to rotate the texture 90 degrees, so if I rotate the order of points would it then also be rotated?

Note: Damn your probably right, I should do this with 3D instead. =/
It's not fun anymore XD
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 #59 on: December 08, 2011, 11:52:23 pm »
Quote
Is this a bug?

Depends what you do to get it. A minimal and complete example would be appreciated ;)

Quote
Also does it matter the order I create/use points with for the UV-coordinate generations? Let's say I would like to rotate the texture 90 degrees, so if I rotate the order of points would it then also be rotated?

Nop, the texture is mapped according to the local position of points relatively to the local bounding rectangle. So the texture itself can't be rotated, you must rotate the shape.

But why don't you use sf::VertexArray directly? You obviously don't need shapes dor simple textured quads.
Laurent Gomila - SFML developer

 

anything