@AlchimiaStudios said:
Probably just the way the behaviors on the back-end operate. My guess is interpolate takes the integer, converts it to another var type temporarily (real or string maybe?) since you need this to achieve the effect of interpolate types and then feeds it back as that type.
In the GUI/change it is using the var type defined by you instead
If it is ever a real, then it should let me manually set it or use change attribute to a real.
If it is an integer, then it should not let back end process set it to reals, ever.
This front end and back end thing is what i call inconsistencies, this TileWidth should be reals then if back end is able to set it to reals.
You wouldn't want to make positions like that because calls to accelerate, moveto or whatever would work smoothly, but then when user tries to manually manipulate movements it would not be the same because of front end integer limitations.
Could the flag button be moved to the end of the row? It is very easy for lefties like me to accidently hit this button when scrolling on our ipads... before the flag button was put there I would hit the quote button, but at least I would notice.
@tintran said:
You wouldn't want to make positions like that because calls to accelerate, moveto or whatever would work smoothly, but then when user tries to manually manipulate movements it would not be the same because of front end integer limitations.
Not inconsistant. Probably literally necessary from a programming standpoint. There are times in very clean code where converting from one type to another is needed to accomplish certain tasks.
I think in LUA itself it actually auto converts numbers to the correct format to perform certain calculations.
I meant inconsistencies between front and back end....
it's an integer then why is the back end able to set it as real. While doing calculations yeah but storing it as a real back end, and then preventing front end from storing as real.
If we extended this model a step further and only allow front end to enter multiples of 10, while back end can manipulate them as reals...then you'd see what i am trying to get at. It shouldn't prevent front end from doing what back end can do..which is storing them as reals.
@pHghost said:
Just to make things clear, since we've had our (quite vocal) differences with Socks lately, I haven't flagged a single post of his and would never use the system in such a backhanded way.
Agreed, I actually know who was abusing the spam flagging system and it wasn't @pHghost.
@tintran said:
So tell me is it a real or an integer?
The front end shows an integer, but in the back end interpolate is able to set it to real.
The tile width attribute is an integer, like I say 'integer' or 'real' only applies to the storing of values in a attribute. The interpolate behaviour doesn't set anything to real (or integer), it simply performs a calculation on a number, once you read the value from an attribute all you have is a number, there is no hidden meta-data attached to that number telling GameSalad that it is not simply 17, but a certain kind of 17 (an 'integer' 17 for example), like I say there are not different sorts of 17 in maths (or GameSalad) only different sorts of storage 'spaces'.
Let me try another analogy.
Imagine the storing of values is done by a person with a notebook, you tell him you want game.power to only store integers and to be set to 100 . . . . you also tell him you want to store another attribute called game.points which is a 'real' attribute set to 100 . . . . he scribbles all this down for you, he is effectively your game memory . . . . you then ask him to randomly give you one of those values so you can perform a calculation on it, he reads out the number '100' (obviously given both your stored numbers are 100) . . . . are you then able to tell, by simply looking at the number, whether it is a 'real' or an 'integer' (or more correctly whether it had been stored as an integer or a real value) ? Or would you only be able to perform a calculation with one of these 100s and get a different result than if you were to perform the same calculation with the other 100 (for example divide by 200) ?
Of course if you were to perform a calculation on either of the 100s and the result was - for example 50.5 - then asking the guy with the notebook to store this new value in the game.power location will result in it being rounded, but besides forcing the number into a certain 'shaped' location (which will necessarily 'deform' the value) you are free to chop and change and multiply and constrain and interpolate the number any way you please.
@tintran said:
What I really meant was the display might read 20.3 but in reality it can only show things by whole pixels so it shows the actor at 20 not 20.3
That sentence seems to contradict itself ? It seems to be saying (if I'm reading it right) that displaying the value will read 20.3 . . . but it can only show whole pixel values ? So it 'might' read 20.3 but it shows the actor at 20 !?
A Text Display can show decimal places - and the display does read 20.3 if an actor is at 20.3 (rather than 20).
@tintran said:
This front end and back end thing is what i call inconsistencies, this TileWidth should be reals then if back end is able to set it to reals.
What !? There is not 'front end' and 'back end' that I'm aware of, the reason you can interpolate the tile width value through decimal places is because the tile width attribute is simply storing a number and numbers don't have secondary qualities beyond their numerical values.
@Socks said:
That sentence seems to contradict itself ? It seems to be saying (if I'm reading it right) that displaying the value will read 20.3 . . . but it can only show whole pixel values ? So it 'might' read 20.3 but it shows the actor at 20 !?
A Text Display can show decimal places - and the display does read 20.3 if an actor is at 20.3 (rather than 20).
If you print a value out and it's a real, then display text will show 20.3 yes.
I say display will read 20.3 because i don't know what display in memory looks like. But when it's viewed on the screen, it's all whole numbers since it's impossible to move a picture by a fraction of a pixel.
So an actor at 20.3 will actually display just like an actor at 20
@Socks said:
What !? There is not 'front end' and 'back end' that I'm aware of, the reason you can interpolate the tile width value through decimal places is because the tile width attribute is simply storing a number and numbers don't have secondary qualities beyond their numerical values.
There obviously is a back end to set tileWidth to a real, how else am i able to see real numbers (numbers with decimals) when tileWidth is being interpolated from 0 to 10.
There's even inconsistency in the front end alone.
If i manually enter a value for TileWidth as 9.7 I get a red rectangle around indicating error and it doesn't actually change the value to 10 (the nearest integer).
But when I use Change Attribute and set TileWidth to 9.7, it rounds it to the nearest integer 10.
So even that has inconsistencies, What should really happen is just make it a real that way interpolate will still work the way it does and front end (mean user) can still manipulate it manually giving it a real value.
@tintran said:
If you print a value out and it's a real, then display text will show 20.3 yes.
Agreed, when an actor is at x=20.3 and you display the actors x co-ordinate - and the actor's x co-odinate is a 'real' attribute, using a Display Text behaviour it will display 20.3 . . . . and the exact same thing will happen with an integer attribute !
@tintran said:
But when it's viewed on the screen, it's all whole numbers since it's impossible to move a picture by a fraction of a pixel. So an actor at 20.3 will actually display just like an actor at 20
No, that's not the case, an actor sat at x=20.3 will display a position of 20.3 (regardless of whether the co-ordinate attribute is real or integer) - and it is perfectly possible to move an actor ('picture') by a fraction of a pixel, the RGBA values will simply be distributed between adjacent pixels. An actor at 20.3 will not display the same as an actor at 20, hold on, I'll do just that, place an actor at 20 and at 20.3 and show you the result . . . back in a second . . .
. . . in fact, the whole 'place you actors on whole value co-ordinates' recommendation is to exactly ensure that images are not effected by being on sub-pixel locations . . . . i.e. an actor at 100 and an actor at 100.3 will display differently.
here's a fun one.
Interpolate tileWidth from 0 to 10 in 10 seconds
Constraint tileHeight to tileWidth
Display tileWidth and tileHeight
you'll see that Interpolate is able to set tileWidth to a real number
while tileHeight is restricted integers....
so tell me are they Integers or Reals? hehehe see there's a back end process that's able to set it to real which isn't revealed to the front end well only revealed by display texting it...can't set it to be the same number by the user.
@Socks said:
No, that's not the case, an actor sat at x=20.3 will display a position of 20.3 (regardless of whether the co-ordinate attribute is real or integer) - and it is perfectly possible to move an actor ('picture') by a fraction of a pixel, the RGBA values will simply be distributed between adjacent pixels. An actor at 20.3 will not display the same as an actor at 20, hold on, I'll do just that, place an actor at 20 and at 20.3 and show you the result . . . back in a second . . .
I put a default actor at 20.0 that's colored white
and i put another default actor changing it's color to black at 20.3
and well the black actor completely covered the white actor.
I am talking about actual single pixel movement, not effects such as distributing RGB values which is anti-aliasing done by software, The display only understand whole pixel values.
@tintran said:
There obviously is a back end to set tileWidth to a real, how else am i able to see real numbers (numbers with decimals) when tileWidth is being interpolated from 0 to 10.
Because you are interpolating the value 0 from 0 to 10, there is nothing about the value 0 (or any other number) that would limit it to only whole number results in a calculation.
@tintran said:
If i manually enter a value for TileWidth as 9.7 I get a red rectangle around indicating error and it doesn't actually change the value to 10 (the nearest integer).
Yes, you cannot store a real value in an integer attribute.
@tintran said:
But when I use Change Attribute and set TileWidth to 9.7, it rounds it to the nearest integer 10.
Yes, the Change Attribute behaviour stores a value in an attribute. You cannot store a real value in an integer attribute.
@Socks said:
. . . here you go, an actor at 100 and an actor at 100.3, you can see that placing the actor on a sub-pixel location will effect how it looks.
Technically it didn't just move? It moved and changed colors around the edges...as the square isn't a whole white square anymore..it's impossible to move the whole square by 0.3 a pixel is what i meant.
@tintran said:
so tell me are they Integers or Reals?
Integers
@tintran said:
hehehe see there's a back end process that's able to set it to real which isn't revealed to the front end well only revealed by display texting it...can't set it to be the same number by the user.
I don't believe in the back end conspiracy
I think how a number is stored and how a number is used is being conflated here.
I have a question for you, here is a number . . .
16
. . . . I've just read this number from an attribute, can you tell me (simply by looking at the number) whether that attribute was an integer or a real attribute ?
did you try my "Here's a fun one?"
I am convinced there's a back end process that changes that TileWidth to a real. Then back again to integer again or some similar sort of voodoo.
If you interpolate an integer attribute and display text ( query the value of ) that attribute during interpolation it will display a real value so during interpolation GS is storing a real in an integer attribute... or is simply using the attribute as a reference to the interpolation result.
@tintran said:
I put a default actor at 20.0 that's colored white
and i put another default actor changing it's color to black at 20.3
and well the black actor completely covered the white actor.
It might appear to you to be completely covering the white actor, but it's not, there will be some light coloured aliasing on the left side of the black actor, that is the white actor showing through, I will do the exact same process and take a screenshot . . . .
EDIT - bear in mind that the edge pixels of a blank actor in GameSalad (and with any platform using Box2D) will not be anti-aliased - but the rest of the pixels 'inland' will quite happily sit on sub-pixel positions . . . . this doesn't happen with images.
@tintran said:
I am talking about actual single pixel movement, not effects such as distributing RGB values which is anti-aliasing done by software, The display only understand whole pixel values.
I disagree, I'd say the correct interpretation of what happens is that a pixel based display will distribute the channel values in an image's pixels wherever you tell it to, even between pixels.
@Socks said:
. . . . I've just read this number from an attribute, can you tell me (simply by looking at the number) whether that attribute was an integer or a real attribute ?
simply looking at the number it's just the number 16,
if you gave me a decimal then i can tell you it's a real number.
16 could be an integer or a real or all i know it could be a string.
1 third of the lefthand edge pixel value is sticking out from behind the black actor.
And let's keep bring this back to the actual question, in a world where co-ordinates are stored as integers would positional constrains be effected in any way, for example would something contained to an increasing value visibly 'step' from pixel to pixel or smoothly flow like it does with the current 'real' coordinate attributes . . . this question implicitly relies on the notion that actors can sit on sub-pixel positions.
@tintran said:
simply looking at the number it's just the number 16 . . .
Exactly ! And that is how GameSalad looks at the number 16 too, whether it's come from an equation, an integer attribute or a real attribute or a user's touch input or the device's clock (etc etc), it's just a number, it's not an integer 16 or game.clock 16, so there are no restrictions on how it can be utilised.
So, if an actor were to use integer attributes to store its location, the values stored in those attributes can be processed in any way you like, they can be split up into tiny fractions if you want, there is no restriction in that regard, they are just numbers, not numbers with special properties meaning they react differently to other number when thrown into a calculation, but just plain old numbers.
@Socks said:
Here you go, x=400 (white) and x=400.3 (black)
1 third of the lefthand edge pixel value is sticking out from behind the black actor.
And let's keep bring this back to the actual question, in a world where co-ordinates are stored as integers would positional constrains be effected in any way, for example would something contained to an increasing value visibly 'step' from pixel to pixel or smoothly flow like it does with the current 'real' coordinate attributes . . . this question implicitly relies on the notion that actors can sit on sub-pixel positions.
That's good then I didn't know it did that...all the more reason to keep position as reals then.
@tintran sock told you like 20 posts ago that images, actors can sit on sub pixels..lol it took you that long to actually listen..lmao each pixel on a screen is an entity to it's self.
@The_Gamesalad_Guru said:
tintran sock told you like 20 posts ago that images, actors can sit on sub pixels..lol it took you that long to actually listen..lmao each pixel on a screen is an entity to it's self.
The reason is that when i did it on mine, the black square doesn't sit on sub pixels. it completely covered the white square when set to 100.3 and white set to 100.
Comments
If it is ever a real, then it should let me manually set it or use change attribute to a real.
If it is an integer, then it should not let back end process set it to reals, ever.
This front end and back end thing is what i call inconsistencies, this TileWidth should be reals then if back end is able to set it to reals.
You wouldn't want to make positions like that because calls to accelerate, moveto or whatever would work smoothly, but then when user tries to manually manipulate movements it would not be the same because of front end integer limitations.
Could the flag button be moved to the end of the row? It is very easy for lefties like me to accidently hit this button when scrolling on our ipads... before the flag button was put there I would hit the quote button, but at least I would notice.
Yep.. the engine/creator is definitely storing reals in integer attributes ( or some kind of floating reference is going on )
Not inconsistant. Probably literally necessary from a programming standpoint. There are times in very clean code where converting from one type to another is needed to accomplish certain tasks.
I think in LUA itself it actually auto converts numbers to the correct format to perform certain calculations.
See:
Javascript Type Conversion
Lua Numbers
Follow us: Twitter - Website
I meant inconsistencies between front and back end....
it's an integer then why is the back end able to set it as real. While doing calculations yeah but storing it as a real back end, and then preventing front end from storing as real.
If we extended this model a step further and only allow front end to enter multiples of 10, while back end can manipulate them as reals...then you'd see what i am trying to get at. It shouldn't prevent front end from doing what back end can do..which is storing them as reals.
Agreed, I actually know who was abusing the spam flagging system and it wasn't @pHghost.
If you want to beat my 33 spam flags you'll need to get a move on.
The tile width attribute is an integer, like I say 'integer' or 'real' only applies to the storing of values in a attribute. The interpolate behaviour doesn't set anything to real (or integer), it simply performs a calculation on a number, once you read the value from an attribute all you have is a number, there is no hidden meta-data attached to that number telling GameSalad that it is not simply 17, but a certain kind of 17 (an 'integer' 17 for example), like I say there are not different sorts of 17 in maths (or GameSalad) only different sorts of storage 'spaces'.
Let me try another analogy.
Imagine the storing of values is done by a person with a notebook, you tell him you want game.power to only store integers and to be set to 100 . . . . you also tell him you want to store another attribute called game.points which is a 'real' attribute set to 100 . . . . he scribbles all this down for you, he is effectively your game memory . . . . you then ask him to randomly give you one of those values so you can perform a calculation on it, he reads out the number '100' (obviously given both your stored numbers are 100) . . . . are you then able to tell, by simply looking at the number, whether it is a 'real' or an 'integer' (or more correctly whether it had been stored as an integer or a real value) ? Or would you only be able to perform a calculation with one of these 100s and get a different result than if you were to perform the same calculation with the other 100 (for example divide by 200) ?
Of course if you were to perform a calculation on either of the 100s and the result was - for example 50.5 - then asking the guy with the notebook to store this new value in the game.power location will result in it being rounded, but besides forcing the number into a certain 'shaped' location (which will necessarily 'deform' the value) you are free to chop and change and multiply and constrain and interpolate the number any way you please.
That sentence seems to contradict itself ? It seems to be saying (if I'm reading it right) that displaying the value will read 20.3 . . . but it can only show whole pixel values ? So it 'might' read 20.3 but it shows the actor at 20 !?
A Text Display can show decimal places - and the display does read 20.3 if an actor is at 20.3 (rather than 20).
What !? There is not 'front end' and 'back end' that I'm aware of, the reason you can interpolate the tile width value through decimal places is because the tile width attribute is simply storing a number and numbers don't have secondary qualities beyond their numerical values.
If you print a value out and it's a real, then display text will show 20.3 yes.
I say display will read 20.3 because i don't know what display in memory looks like. But when it's viewed on the screen, it's all whole numbers since it's impossible to move a picture by a fraction of a pixel.
So an actor at 20.3 will actually display just like an actor at 20
There obviously is a back end to set tileWidth to a real, how else am i able to see real numbers (numbers with decimals) when tileWidth is being interpolated from 0 to 10.
There's even inconsistency in the front end alone.
If i manually enter a value for TileWidth as 9.7 I get a red rectangle around indicating error and it doesn't actually change the value to 10 (the nearest integer).
But when I use Change Attribute and set TileWidth to 9.7, it rounds it to the nearest integer 10.
So even that has inconsistencies, What should really happen is just make it a real that way interpolate will still work the way it does and front end (mean user) can still manipulate it manually giving it a real value.
Agreed, when an actor is at x=20.3 and you display the actors x co-ordinate - and the actor's x co-odinate is a 'real' attribute, using a Display Text behaviour it will display 20.3 . . . . and the exact same thing will happen with an integer attribute !
No, that's not the case, an actor sat at x=20.3 will display a position of 20.3 (regardless of whether the co-ordinate attribute is real or integer) - and it is perfectly possible to move an actor ('picture') by a fraction of a pixel, the RGBA values will simply be distributed between adjacent pixels. An actor at 20.3 will not display the same as an actor at 20, hold on, I'll do just that, place an actor at 20 and at 20.3 and show you the result . . . back in a second . . .
. . . in fact, the whole 'place you actors on whole value co-ordinates' recommendation is to exactly ensure that images are not effected by being on sub-pixel locations . . . . i.e. an actor at 100 and an actor at 100.3 will display differently.
here's a fun one.
Interpolate tileWidth from 0 to 10 in 10 seconds
Constraint tileHeight to tileWidth
Display tileWidth and tileHeight
you'll see that Interpolate is able to set tileWidth to a real number
while tileHeight is restricted integers....
so tell me are they Integers or Reals? hehehe see there's a back end process that's able to set it to real which isn't revealed to the front end well only revealed by display texting it...can't set it to be the same number by the user.
. . . here you go, an actor at 100 and an actor at 100.3, you can see that placing the actor on a sub-pixel location will effect how it looks.
I put a default actor at 20.0 that's colored white
and i put another default actor changing it's color to black at 20.3
and well the black actor completely covered the white actor.
I am talking about actual single pixel movement, not effects such as distributing RGB values which is anti-aliasing done by software, The display only understand whole pixel values.
Because you are interpolating the value 0 from 0 to 10, there is nothing about the value 0 (or any other number) that would limit it to only whole number results in a calculation.
Yes, you cannot store a real value in an integer attribute.
Yes, the Change Attribute behaviour stores a value in an attribute. You cannot store a real value in an integer attribute.
Technically it didn't just move? It moved and changed colors around the edges...as the square isn't a whole white square anymore..it's impossible to move the whole square by 0.3 a pixel is what i meant.
Integers
I don't believe in the back end conspiracy
I think how a number is stored and how a number is used is being conflated here.
I have a question for you, here is a number . . .
16
. . . . I've just read this number from an attribute, can you tell me (simply by looking at the number) whether that attribute was an integer or a real attribute ?
did you try my "Here's a fun one?"
I am convinced there's a back end process that changes that TileWidth to a real. Then back again to integer again or some similar sort of voodoo.
If you interpolate an integer attribute and display text ( query the value of ) that attribute during interpolation it will display a real value so during interpolation GS is storing a real in an integer attribute... or is simply using the attribute as a reference to the interpolation result.
It might appear to you to be completely covering the white actor, but it's not, there will be some light coloured aliasing on the left side of the black actor, that is the white actor showing through, I will do the exact same process and take a screenshot . . . .
EDIT - bear in mind that the edge pixels of a blank actor in GameSalad (and with any platform using Box2D) will not be anti-aliased - but the rest of the pixels 'inland' will quite happily sit on sub-pixel positions . . . . this doesn't happen with images.
I disagree, I'd say the correct interpretation of what happens is that a pixel based display will distribute the channel values in an image's pixels wherever you tell it to, even between pixels.
simply looking at the number it's just the number 16,
if you gave me a decimal then i can tell you it's a real number.
16 could be an integer or a real or all i know it could be a string.
Here you go, x=400 (white) and x=400.3 (black)
1 third of the lefthand edge pixel value is sticking out from behind the black actor.
And let's keep bring this back to the actual question, in a world where co-ordinates are stored as integers would positional constrains be effected in any way, for example would something contained to an increasing value visibly 'step' from pixel to pixel or smoothly flow like it does with the current 'real' coordinate attributes . . . this question implicitly relies on the notion that actors can sit on sub-pixel positions.
Exactly ! And that is how GameSalad looks at the number 16 too, whether it's come from an equation, an integer attribute or a real attribute or a user's touch input or the device's clock (etc etc), it's just a number, it's not an integer 16 or game.clock 16, so there are no restrictions on how it can be utilised.
So, if an actor were to use integer attributes to store its location, the values stored in those attributes can be processed in any way you like, they can be split up into tiny fractions if you want, there is no restriction in that regard, they are just numbers, not numbers with special properties meaning they react differently to other number when thrown into a calculation, but just plain old numbers.
That's good then I didn't know it did that...all the more reason to keep position as reals then.
This is an Amoeba thread. I think we witnessed binary fission.
@tintran sock told you like 20 posts ago that images, actors can sit on sub pixels..lol it took you that long to actually listen..lmao each pixel on a screen is an entity to it's self.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
The reason is that when i did it on mine, the black square doesn't sit on sub pixels. it completely covered the white square when set to 100.3 and white set to 100.
here's my project
zoom in and i bet you see the 3 tens of a pixel. We need real attributes for smooth movement or you'd get jagged results.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS