New graphics API ready

[Laurent]

I also forgot to say that textures can now be repeated (SetRepeated / IsRepeated).

[Groogy]

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?
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 Must be stupidity on my side.

[Laurent]

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[]?

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

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.

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

Please focus on the API, there's no optimization yet so the performances are worse than before

[Groogy]

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.

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.

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.

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"

[Laurent]

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

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

[Groogy]

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 :twisted:

[Laurent]

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.

[Groogy]

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:
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?

[Laurent]

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?

[Groogy]

What's the purpose of a fake 3D renderer?

It's fun

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 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

[Haze]

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]

I wish RectangleShape had a ctor which doesn't require a Vector2f object

Already discussed in previous pages

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

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

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.

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

[Haze]

What a fast replay, as always

I wish RectangleShape had a ctor which doesn't require a Vector2f object

Already discussed in previous pages

Missed this request, my bad!

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

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

Basically, you can now write this:

Code: [Select]

window.Draw(sprite, sf::BlendNone);

Ok! It seems fine as well.

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]

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

[Laurent]

Is this a bug?

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

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.