I'm not a fan of the endless decimals either, so if I need to, I just constrain my actors' co-ordinates to their floor values.
Thanks @pHghost for : "Actually, 0.5s are quite important. I use them regularly. The reason is the way GS works with retina devices. Currently, 0.5 in GS is 1 pixel on most devices. So a 1 in GS would be 2 pixels on device, which could result in jerky movement in interpolate and not enough precision."
@tintran said:
I know 7 people agreed to the above change but really think about what's going to happen
As @RossmanBrothersGames said, what people are agreeing to is actor snapping to 'integer grid' in the creator, when you drag-n-drop. Not changing over to integers.
Here's the thing. People come in here and say, "I need this!" Okay you're a few people amd other people come on here and say, "I need that!" Then when the parties don't get their way they throw a forum tantrum. GS is what it is, period. You all have been here long enough to know that. I believe they are doing their best, they are human. Everyone says, "I'm gonna try this tool then, bye." Days later they come back, "that tool sucks even more.", "it's too much work to learn to code." Et.... I wish we could get back to talking about games and game design and more productive things than a 24/7 bitch fest. If you really want power use, put in the effort and learn to code, then you have no obstacles at all. Life isn't perfect, gamesalad isn't perfect and we are not perfect. Deal with it.
@The_Gamesalad_Guru said:
I wish we could get back to talking about games and game design and more productive things than a 24/7 bitch fest. If you really want power use, put in the effort and learn to code, then you have no obstacles at all. Life isn't perfect, gamesalad isn't perfect and we are not perfect. Deal with it.
Considering the size of the changes, I think the forums handled themselves superbly. Very little aggression, very few posts throwing a fit, lots of calm and rational debate. By this point, though, I think you're right - everything worth saying has been said twice.
@tintran said:
Just not actually changing the type of position.x and position.y to integers because that will break it because then velocities will also turn into whole integer pixels and so will acceleration and that would be really bad.
Even if an actor's x an y positions were stored as intergers it would not effect acceleration or velocities in any way, but I doubt GS is going to make that change anyhow.
@kobayaashi said:
I'm not a fan of the endless decimals either, so if I need to, I just constrain my actors' co-ordinates to their floor values.
Thanks pHghost for : "Actually, 0.5s are quite important. I use them regularly. The reason is the way GS works with retina devices. Currently, 0.5 in GS is 1 pixel on most devices. So a 1 in GS would be 2 pixels on device, which could result in jerky movement in interpolate and not enough precision."
I hate to repeat this, but this information is simply wrong, honestly, interpolate would not suddenly be quantised to whole pixel values because it is operating on an interger, try it yourself make an actor with an integer attribute (let's call the attribute 'A' and give it a value of 10), now interpolate A from 10 to some other value like 20 . . . then display 'A' using a Display Text behaviour and see what you get . . . decimal places !
Nor is this limited to a Display Text behaviour, you can constrain the actor's position to A, you can use Move To to move the actor's position to A or Accelerate at speed A (and so on).
@RossmanBrothersGames said:
tintran the positions are only snapping to an integer when you place them on the screen. When they move in the game they will still move the same. Acceleration will still work the same objects will move fluidly through decimal points.
Exactly !
@RossmanBrothersGames said:
When dragging a object on to the screen in editor it is nice to have them snap to an integer. So you can line things up nicely when doing level design.
Yes, and even if you are a couple of pixels out you just need to quickly nudge the actor into position with the arrow keys, this will make life so much easier than having to open up every actor and manually round up two values.
GS is a bit free and loose with where and how it is storing values it seems. During an interpolate the stored value overrides the attributes type so an integer can happily display a real but interpolate to for example 10.65 and your display text will jump to 11 if showing an interpolated integer.
@Socks said:
Even if an actor's x an y positions were stored as intergers it would not effect acceleration or velocities in any way, but I doubt GS is going to make that change anyhow.
Yeah, it would affect acceleration.
Here's a sample project.
I have an accelerate toward mouse pointer's position.
and two constraints which are turned off. The constrain forces position x and position to be rounded values all the time to simulate the fact that they're integers.
When you preview the game, the actor accelerates toward the mouse pointer (very slowly).
Now try to turn these constraints on..and the actor won't move at all.
@tintran said:
The constrain forces position x and position to be rounded values all the time to simulate the fact that they're integers.
Ok ? What are you saying here ? That constraining a value to something results in that value being constrained to the thing you are constraining it to !?
I'm not quite sure what that is attempting to illustrate ?
It certainly doesn't illustrate the idea that an if an actor's position is defined by two integers that the actor cannot then move through sub-pixel positions if - for example - you were to interpolate the actor's position from A to B, or constrain the actor's position to game.time or any other process that would require it to move though sub-pixel positions.
The fact that to get the actor to stick to whole pixel values you specifically have to use a constrain to "force" it to whole pixel values pretty much makes that point !
When you are not forcing the actor to stick to whole pixel values it will happily move through sub-pixel coordinates even if its coordinate attributes were integers - as attribute type (specifically integer vs real) only define how an attribute is stored and not how those values behave when they are 'out of the box' - like I was saying elsewhere if you read the value from an integer attribute set at 6 and also read the value from a real attribute and it is also 6, you simply have two 6's, you don't have two different types of 6, one being an integer 6 and one being a real 6, when you use these values in a calculation or expression or behaviour they will act identically.
Integer 6 divided by 4 is 1.5
Real 6 divided by 4 is 1.5
But if you attempt to take that value of 1.5 and store it as an attribute, then the kind of attribute matters, but otherwise the history of the number (whether it used to live in an integer shaped box or a real shaped box) is irrelevant, as it will have no bearing on how the value is processed.
If positions were integers, they can't accumulate decimals, so they're always integers that's why the constraints are there, it's to show what would happen position xy were integers all the time.
It's fine though i don't think we don't have a problem anymore as ...i think every one pretty much agreed that it's just a GUI change and not actually a type change.
If moving actor from A directly to B, you could use game.time to calculate where the position should be so that's okay at a certain game.time,
but if you have an actor that is accelerating toward a moving location like a moving mouse pointer, you can't use game.time, because changes would have to be applied at each frame because mouse.pointer is potentially different at each frame, and the path wouldn't be a straight line so you can't use game.time so you'd want the position to accumulate decimals.
Once a value has been read from a real or integer attribute it is no longer real or integer, it is simply a number - so in that respect there are not always integers (if I understand what you are saying correctly).
@tintran said:
that's why the constraints are there, it's to show what would happen position xy were integers all the time.
It's really only showing that if you constrain something to X it will be X !?
That's simply not how attributes work, once a value is read from an attribute it loses all history/memory/shape of where it came from or what it was - when calculating equations there is no such thing as a integer 17 and a real 17, only 17.
If we have a integer self.attribute called ABC set at 17, and then calculate the following . . .
self.ABC / 2
. . . the result will be 8.5
@tintran said:
It's fine though i don't think we don't have a problem anymore as ...i think every one pretty much agreed that it's just a GUI change and not actually a type change.
Yeah, there would be no reason to change how actor coordinates are stored (or rather the type of attribute they are stored in), but this whole subject does relate to a confusion that comes up from time to time, where users occasionally are confused by why their integer attribute when processed can produce a decimal result.
What i meant by accumulate is this.
Let's say you have a position x as a real type starting at 20
and an x velocity of 0.3 pixel
next frame, you have new position at (20+.3) which is stored in position x which will be 20.3
so even though displaying it shows it's at 20, but because the position is of type real, it accumulates 0.3's
next frame, you have a new postions at (20.3+.3) which is stored in position x which will be 20.6
so now display shows it's at 21
If the type of position x were to change to integer.
you'd start 20,
next frame (20+0.3) but 20.3 can't be stored as integer so 20 is stored and you would have lost the 0.3 (in this case it doesn't accumulate).
next frame (20+0.3) so this ends up being not moving at all when it should've moved if it were stored as a real.
@tintran said:
Let's say you have a position x as a real type starting at 20
and an x velocity of 0.3 pixel
next frame, you have new position at (20+.3) which is stored in position x which will be 20.3
so even though displaying it shows it's at 20, but because the position is of type real, it accumulates 0.3's
The display will read 20.3 if the actor is at x=20.3 - rather than 20 -regardless of whether the coordinate attributes are real or integer.
@tintran said:
If the type of position x were to change to integer.
you'd start 20,
next frame (20+0.3) but 20.3 can't be stored as integer so 20 is stored and you would have lost the 0.3 (in this case it doesn't accumulate).
Like I've said elsewhere the type of attribute (with regard to integer or real) is only an issue when storing a value - what you are describing here is the storing of a value, you can only store an integer in an integer attribute, but otherwise you are free to divide and chop and constrain and change that value to whatever you want, so, returning to the question, if an actor's coordinate attributes were changed to integer it would have no effect on how that actor behaves when under the influence of constrains or interpolate behaviours (or anything that might see the actor need to position itself on a sub-pixel coordinate).
. . . . .
Try this, make a new actor, add an interpolate behaviour and interpolate the actor's Tile Width (an integer attribute) from 0 to 10 . . . over a period of 20 seconds or so . . . and use a Display Text behaviour to monitor the Tile Width attribute, you'll see a series of decimal places rather than a quantised progression of whole numbers, and in real world scenarios the actors tiled image will smoothly increase its width rather than stepping from 0 to 1 to 2 to 3 to 4 (and so on).
dgackeyAustin, TXInactive, PRO, Chef EmeritusPosts: 699
(Split from previous thread)
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
Makes sense, we've headed off in an entirely unrelated direction ! It'll also give the person marking all my posts as spam somewhere to concentrate his efforts, lol.
dgackeyAustin, TXInactive, PRO, Chef EmeritusPosts: 699
I deleted 3 nonsense posts from the thread and removed a bunch of unnecessary flags from @Socks posts.
Please stop flagging posts that are not spam, and ensure that your replies add to the discussion / have some value or your posting privileges will be revoked for a week.
Thank you!
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
@Socks said:
Try this, make a new actor, add an interpolate behaviour and interpolate the actor's Tile Width (an integer attribute) from 0 to 10 . . . over a period of 20 seconds or so . . . and use a Display Text behaviour to monitor the Tile Width attribute, you'll see a series of decimal places rather than a quantised progression of whole numbers, and in real world scenarios the actors tiled image will smoothly increase its width rather than stepping from 0 to 1 to 2 to 3 to 4 (and so on).
I gotta say after trying this... I see inconsistencies.
When I interpolate, and display the tilewidth, the numbers are shown are reals (obviously because it has decimals).
But when I enter 9.7 manually into tile width from GUI, I get no change in tile width and a highlighted red indicating error.
But when I added a change Attribute behavior to 9.7, I get a 10.
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.
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.
@Socks said:
The display will read 20.3 if the actor is at x=20.3 - rather than 20 -regardless of whether the coordinate attributes are real or integer.
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
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.
To anyone doing this: the flags are here to counter spam, not to be used against people who massively contribute to this community, whether you agree with them or not.
Comments
I'm not a fan of the endless decimals either, so if I need to, I just constrain my actors' co-ordinates to their floor values.
Thanks @pHghost for : "Actually, 0.5s are quite important. I use them regularly. The reason is the way GS works with retina devices. Currently, 0.5 in GS is 1 pixel on most devices. So a 1 in GS would be 2 pixels on device, which could result in jerky movement in interpolate and not enough precision."
This would be great! I want to make a platformer, but the level design is a pain without the ability to zoom in the scene editor.
Mental Donkey Games
Website - Facebook - Twitter
As @RossmanBrothersGames said, what people are agreeing to is actor snapping to 'integer grid' in the creator, when you drag-n-drop. Not changing over to integers.
Here's the thing. People come in here and say, "I need this!" Okay you're a few people amd other people come on here and say, "I need that!" Then when the parties don't get their way they throw a forum tantrum. GS is what it is, period. You all have been here long enough to know that. I believe they are doing their best, they are human. Everyone says, "I'm gonna try this tool then, bye." Days later they come back, "that tool sucks even more.", "it's too much work to learn to code." Et.... I wish we could get back to talking about games and game design and more productive things than a 24/7 bitch fest. If you really want power use, put in the effort and learn to code, then you have no obstacles at all. Life isn't perfect, gamesalad isn't perfect and we are not perfect. Deal with it.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
+1
Considering the size of the changes, I think the forums handled themselves superbly. Very little aggression, very few posts throwing a fit, lots of calm and rational debate. By this point, though, I think you're right - everything worth saying has been said twice.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Even if an actor's x an y positions were stored as intergers it would not effect acceleration or velocities in any way, but I doubt GS is going to make that change anyhow.
I hate to repeat this, but this information is simply wrong, honestly, interpolate would not suddenly be quantised to whole pixel values because it is operating on an interger, try it yourself make an actor with an integer attribute (let's call the attribute 'A' and give it a value of 10), now interpolate A from 10 to some other value like 20 . . . then display 'A' using a Display Text behaviour and see what you get . . . decimal places !
Nor is this limited to a Display Text behaviour, you can constrain the actor's position to A, you can use Move To to move the actor's position to A or Accelerate at speed A (and so on).
Exactly !
Yes, and even if you are a couple of pixels out you just need to quickly nudge the actor into position with the arrow keys, this will make life so much easier than having to open up every actor and manually round up two values.
@Socks
GS is a bit free and loose with where and how it is storing values it seems. During an interpolate the stored value overrides the attributes type so an integer can happily display a real but interpolate to for example 10.65 and your display text will jump to 11 if showing an interpolated integer.
Yeah, it would affect acceleration.
Here's a sample project.
I have an accelerate toward mouse pointer's position.
and two constraints which are turned off. The constrain forces position x and position to be rounded values all the time to simulate the fact that they're integers.
When you preview the game, the actor accelerates toward the mouse pointer (very slowly).
Now try to turn these constraints on..and the actor won't move at all.
Ok ? What are you saying here ? That constraining a value to something results in that value being constrained to the thing you are constraining it to !?
I'm not quite sure what that is attempting to illustrate ?
It certainly doesn't illustrate the idea that an if an actor's position is defined by two integers that the actor cannot then move through sub-pixel positions if - for example - you were to interpolate the actor's position from A to B, or constrain the actor's position to game.time or any other process that would require it to move though sub-pixel positions.
The fact that to get the actor to stick to whole pixel values you specifically have to use a constrain to "force" it to whole pixel values pretty much makes that point !
When you are not forcing the actor to stick to whole pixel values it will happily move through sub-pixel coordinates even if its coordinate attributes were integers - as attribute type (specifically integer vs real) only define how an attribute is stored and not how those values behave when they are 'out of the box' - like I was saying elsewhere if you read the value from an integer attribute set at 6 and also read the value from a real attribute and it is also 6, you simply have two 6's, you don't have two different types of 6, one being an integer 6 and one being a real 6, when you use these values in a calculation or expression or behaviour they will act identically.
Integer 6 divided by 4 is 1.5
Real 6 divided by 4 is 1.5
But if you attempt to take that value of 1.5 and store it as an attribute, then the kind of attribute matters, but otherwise the history of the number (whether it used to live in an integer shaped box or a real shaped box) is irrelevant, as it will have no bearing on how the value is processed.
If positions were integers, they can't accumulate decimals, so they're always integers that's why the constraints are there, it's to show what would happen position xy were integers all the time.
It's fine though i don't think we don't have a problem anymore as ...i think every one pretty much agreed that it's just a GUI change and not actually a type change.
If moving actor from A directly to B, you could use game.time to calculate where the position should be so that's okay at a certain game.time,
but if you have an actor that is accelerating toward a moving location like a moving mouse pointer, you can't use game.time, because changes would have to be applied at each frame because mouse.pointer is potentially different at each frame, and the path wouldn't be a straight line so you can't use game.time so you'd want the position to accumulate decimals.
How are you using 'accumulate' in this context ? It's vague term, does 'accumulate' relate to storing values or to processing values ?
Once a value has been read from a real or integer attribute it is no longer real or integer, it is simply a number - so in that respect there are not always integers (if I understand what you are saying correctly).
It's really only showing that if you constrain something to X it will be X !?
That's simply not how attributes work, once a value is read from an attribute it loses all history/memory/shape of where it came from or what it was - when calculating equations there is no such thing as a integer 17 and a real 17, only 17.
If we have a integer self.attribute called ABC set at 17, and then calculate the following . . .
self.ABC / 2
. . . the result will be 8.5
Yeah, there would be no reason to change how actor coordinates are stored (or rather the type of attribute they are stored in), but this whole subject does relate to a confusion that comes up from time to time, where users occasionally are confused by why their integer attribute when processed can produce a decimal result.
What i meant by accumulate is this.
Let's say you have a position x as a real type starting at 20
and an x velocity of 0.3 pixel
next frame, you have new position at (20+.3) which is stored in position x which will be 20.3
so even though displaying it shows it's at 20, but because the position is of type real, it accumulates 0.3's
next frame, you have a new postions at (20.3+.3) which is stored in position x which will be 20.6
so now display shows it's at 21
If the type of position x were to change to integer.
you'd start 20,
next frame (20+0.3) but 20.3 can't be stored as integer so 20 is stored and you would have lost the 0.3 (in this case it doesn't accumulate).
next frame (20+0.3) so this ends up being not moving at all when it should've moved if it were stored as a real.
The display will read 20.3 if the actor is at x=20.3 - rather than 20 -regardless of whether the coordinate attributes are real or integer.
Like I've said elsewhere the type of attribute (with regard to integer or real) is only an issue when storing a value - what you are describing here is the storing of a value, you can only store an integer in an integer attribute, but otherwise you are free to divide and chop and constrain and change that value to whatever you want, so, returning to the question, if an actor's coordinate attributes were changed to integer it would have no effect on how that actor behaves when under the influence of constrains or interpolate behaviours (or anything that might see the actor need to position itself on a sub-pixel coordinate).
. . . . .
Try this, make a new actor, add an interpolate behaviour and interpolate the actor's Tile Width (an integer attribute) from 0 to 10 . . . over a period of 20 seconds or so . . . and use a Display Text behaviour to monitor the Tile Width attribute, you'll see a series of decimal places rather than a quantised progression of whole numbers, and in real world scenarios the actors tiled image will smoothly increase its width rather than stepping from 0 to 1 to 2 to 3 to 4 (and so on).
(Split from previous thread)
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
Makes sense, we've headed off in an entirely unrelated direction !
It'll also give the person marking all my posts as spam somewhere to concentrate his efforts, lol.
@ice cream:
I deleted 3 nonsense posts from the thread and removed a bunch of unnecessary flags from @Socks posts.
Please stop flagging posts that are not spam, and ensure that your replies add to the discussion / have some value or your posting privileges will be revoked for a week.
Thank you!
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
Super yay to dropping and nudging in whole numbers
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
Why would someone flag @Socks comments as spam ?
Do you know what a flag is for?
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
Clearly not, hence the warning.
Dan Magaha · COO · GameSalad, Inc · danm@gamesalad.com
there are a few people who are using the flag system as a punishment for not liking what someone wrote.
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
Hey, I'm proud of my flags!
Not really
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
I gotta say after trying this... I see inconsistencies.
When I interpolate, and display the tilewidth, the numbers are shown are reals (obviously because it has decimals).
But when I enter 9.7 manually into tile width from GUI, I get no change in tile width and a highlighted red indicating error.
But when I added a change Attribute behavior to 9.7, I get a 10.
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.
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.
Follow us: Twitter - Website
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
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.
To anyone doing this: the flags are here to counter spam, not to be used against people who massively contribute to this community, whether you agree with them or not.
i got flagged too..wth?
Edit: I guess it was an accident and they unflagged me now