SetScale in 1.6 displaces the graphics

[Sivak]

So, I've got this small graphic and when I used setscaleY on it to make the thing taller.  In 1.5 it worked fine, but here, I need to set its Y position higher in order for it to be positioned correctly...  I am using a scale of 60.

The greater the scale value is, the lower down it goes.  Setting the center to 0,0 does nothing either.

Any thoughts or is this just a bug?

UPDATE:  It also does it with X coordinates too.

[Laurent]

Dammit... It was reported a long time ago, and I was pretty sure that I already fixed it.

This is really annoying.

[Sivak]

Dammit... It was reported a long time ago, and I was pretty sure that I already fixed it.

This is really annoying.

Hey, it's not a huge deal for me.  I'm only using it for 2 stationary graphics and can just offset them for the moment.

Game logic is keeping me too busy to care.  

[Voroz]

How will i know when this is fixed?

[Laurent]

I don't know if this is going to be fixed, I was originally not planning to do a 1.7 release.

[Sivak]

I don't know if this is going to be fixed, I was originally not planning to do a 1.7 release.

Eh, we can hold out till 2.0.  

[Voroz]

Ok, can't you just update the 1.6 version with the fix or something? I will most likely go back to 1.5 if this isn't fixed, since my character is scaling all the time and i notice that it's scaling in a wrong way in 1.6.

[Laurent]

Ok, can't you just update the 1.6 version with the fix or something?

I would have to make a new release with a new version number. It's not that easy, actually.
I'm currently thinking about releasing SFML 2.0 "soon", a lot of planned features can be added in a future minor release of SFML 2.

[Voroz]

Ok, can't you just update the 1.6 version with the fix or something?

I would have to make a new release with a new version number. It's not that easy, actually.
I'm currently thinking about releasing SFML 2.0 "soon", a lot of planned features can be added in a future minor release of SFML 2.

I thought i edited that comment and wrote 1.61 ^^. Well i will revert back to 1.5 until sfml 2 is out then.

[Kaoron]

//topic hijacking in progress

Ok, can't you just update the 1.6 version with the fix or something?

I would have to make a new release with a new version number. It's not that easy, actually.

Ease it, actually. Postponing trivial but annoying bugfixes to the next major API destroyer release because of the version number incrementation toughness is ludicrous, and I am sure you're ashamed of it. Please find a way to drop this ball and chain and free the 1.6.01-oopsireleasedtooearly version number.

I'm currently thinking about releasing SFML 2.0 "soon", a lot of planned features can be added in a future minor release of SFML 2.

Is the API rock-hard enough to survive the whole sfml2 branch lifetime ? I'll never stop bothering you with this, hacking from time to time inside the python binding because of an API break from GetSize to GetBounds is bearable in the early stages of a major release, but thereafter should not happen 'till the next one (instead, you should provide a deprecation mechanism).
This may be a bearable annoyance for windows developers which are used to ship third-part libraries with their software and can stick to an obsolete version, but linux developers heavily rely on libraries shipped with the system. Breaking every six month populates distros with incompatible (hear unreliable) versions of the lib. This is a killer.

Plus, I lost the count of every API-breaking changes between sfml1 and sfml2, will there be a list of every deprecated (yet pruned) symbols and functions ?

Apart of this you're doing great job as usual, and I feel guilt for such a harsh posting. Keep up the good work !

[Laurent]

Ease it, actually

That's exactly what I've been working on since last week, actually

Postponing trivial but annoying bugfixes to the next major API destroyer release because of the version number incrementation toughness is ludicrous, and I am sure you're ashamed of it

Indeed I am.

Please find a way to drop this ball and chain and free the 1.6.01-oopsireleasedtooearly version number.

It's not just a problem of version number, to fix this bug I'll have to modify the rendering process and that will potentially break other things, I can't release a new version until I get enough feedback.
But anyway, you're still right I should release a new version with this bug fixed.

Is the API rock-hard enough to survive the whole sfml2 branch lifetime ? I'll never stop bothering you with this, hacking from time to time inside the python binding because of an API break from GetSize to GetBounds is bearable in the early stages of a major release, but thereafter should not happen 'till the next one (instead, you should provide a deprecation mechanism).
This may be a bearable annoyance for windows developers which are used to ship third-part libraries with their software and can stick to an obsolete version, but linux developers heavily rely on libraries shipped with the system. Breaking every six month populates distros with incompatible (hear unreliable) versions of the lib. This is a killer.

It's not going to happen in SFML 2. I will strictly follow the usual rules: minor versions (2.x) will be API backward-compatible, and patch versions (2.x.y) will be binary backward compatible. If any modification needs to break the public API then it will be postponed to SFML 3, or there will be a workaround to make the old version still work.

Plus, I lost the count of every API-breaking changes between sfml1 and sfml2, will there be a list of every deprecated (yet pruned) symbols and functions ?

I don't think so. There will be a list of what was modified/rewritten, but not a list of all the symbols that were removed. People will really need to read the new documentation and tutorials. It won't be just a matter of replacing/removing the deprecated symbols in your code, you will have to adapt to the new design of the API.

Apart of this you're doing great job as usual, and I feel guilt for such a harsh posting. Keep up the good work !

I love such messages, thanks a lot

[Kaoron]

That's exactly what I've been working on since last week, actually Wink
...
It's not going to happen in SFML 2. I will strictly follow the usual rules: minor versions (2.x) will be API backward-compatible, and patch versions (2.x.y) will be binary backward compatible. If any modification needs to break the public API then it will be postponed to SFML 3, or there will be a workaround to make the old version still work.

Glad to read this, I wish a long compatible life to sfml2

There will be a list of what was modified/rewritten, but not a list of all the symbols that were removed. People will really need to read the new documentation and tutorials. It won't be just a matter of replacing/removing the deprecated symbols in your code, you will have to adapt to the new design of the API.

Well, that was the idea. One could grep for any modified/removed symbol in his code base to easily find the spots that need to be recrafted, taking care of the big red warning heading the new tutorials.
Good code with careful encapsulation of sfml shouldn't be hard to migrate, but I bet there will be a lot of blood, tears and pain for the others.  :twisted:

It's not just a problem of version number, to fix this bug I'll have to modify the rendering process and that will potentially break other things, I can't release a new version until I get enough feedback.

It's understandable.
You seemed shocked to find out that this bug wasn't fixed yet, isn't there a way to add a "1.6 release-critical" flag in flyspray ?

[Kloyd Niel]

Hello Guys,

Thanks for the information that i read,
BTW im a newly one in this site but i learned lot of ideas about this site.
Thanks a lot for being part of this site. God Bless.





how to treat depression