The project description lists a suggestion to set the origin coordinates of the image sprite component using standard coordinates. What does this mean? Does this mean to specify if the x and y coordinates refer to leftmost and topmost edges or to the point which the user specifies? Or does it mean something else? I am not sure about this.
Also what can be some other possible improvements to the animation components besides the ones specified in the project description?
Help is appreciated.
We've had a couple different thoughts on this over the years. A common way of doing this programmatically is using u, v coordinates, which are coordinates on the unit scale. So a u,v of 0,0 is the top left of the sprite, 0.5,0.5 is the center, and 1,1 is the bottom right. This way the position of the origin is consistent even if the size of the sprite changes due to scalars or changes in the image being displayed. However, because this representation might not be entirely intuitive for our user base, we think that a visual means of picking the origin, such as dragging a marker of some kind within the bounds of the image, might be easier for many. For the Ball component @espertus introduced a CenterAtOrigin property which does this implicitly, but in the case of Ball it's often more intuitive for its origin to be at the center versus an ImageSprite where we don't know anything about the contents of the image.
I think the biggest thing to consider would be the three main types of transformations one would want to do: translational (glide), rotational, and scalar. For translational, we may want to provide a means of following a path as well so that the path could be visually drawn in the designer for those more comfortable with that (Versus coding the path in the blocks). Remember that compared to previous years GSOC is 175 hours, so make sure as you're scoping out your proposal you're confident you can complete the proposed work under this shorter time frame.
Thank you for your reply @ewpatton.
Currently to detect collisions between sprites, AppInventor uses BoundedBoxes to check for overlap. At present, collision detection does not work properly for rotated image sprites as bounded boxes are created for the unrotated sprite. What can be a better way to solve this problem? Overriding the colliding() method for rotated image sprites (using the same algorithm and creating bounded boxes for the rotated sprite) or using a different collision detection algorithm?
I was thinking for proposing the SAT method to detect collisions (works primarily for convex polygons). This method projects the shape onto some axes, and checks for overlaps in these axes. This will allow us to handle rotated sprites and is more flexible so we can add different sprites like triangles or hexagons in the future.
What do you think is the better way?
Yes, that might be a good idea. We'd have to look at the performance implications.
Yes, I too think that this way might be easier.
I think to implement this strategy, we need to have a property like OriginAtCorner so that backward compatibilty does not break. If the user has un-selected this property only then he will be able to use the draggable marker to mark his new origin. Do you agree?
Further, implementation of a drag marker will require a new property editor class. I am thinking this editor will create a pop-up of the image in which the user will be able drag a marker to mark the origin. Do you think this is a good idea?
Pondering further I realised we should also include a way to set the origin coordinates using unit vectors (u, v), as then it will be easier to choose the center, bottom right, or any other corner if the user so decides. Is it possible for one property to have to two editors? Please share your thoughts @ewpatton.
I think by default we would keep the origin at the top left corner, so unless they move the origin everything would be backward compatible.
Sounds reasonable to me. Maybe take a look at things like how I implemented Marker so that when you drag it the Latitude and Longitude properties update.
The Marker serves as a good example of how this works. We'd want to have the blocks available so these things could be modified programmatically as well.
The Marker is a separate component that we can drag on the Map. Are you implying that we use a similar strategy, i.e. use a separate component that works like Marker does? I was thinking of just having a property editor that had a draggable marker, not a new component.
I was not implying it would be a separate component. I was thinking more about updating a set of properties (Lat, Long) in response to a drag and drop operation in the designer. For the purposes of the proposed work, I would say that the "marker" for the origin would just be part of the component's UI in the designer.
Hi,
I had submitted a draft proposal, but I have not received any feedback yet.
@Himanshu2107 don't worry they will review as early as possible.
I have also submitted proposal and I got reviewed today early morning at 3 am