This site requires JavaScript, please enable it in your browser!
Greenfoot back

danpost's Comments

Back to danpost's profile

Remember to log onto the site so there will be no waiting on subsequent views of this scenario. Puzzles are reserved in UserInfo storage.
Updated to allow all major classes to be viewed (did not realize that some buttons for viewing classes were inactive until now).
Please remove this stolen scenario from the site.
@bilibull, this uses gridded world (cell sizes larger than one). Also, there are no walls here -- just blocks that are used to build the paths (players must remain on the block roads).
^^ My apologies, this is not the forum ^^
Any issues you have with programming can be discussed here in this forum. Just create a new thread for whatever issues you have.
@hoyaduyin, it is a bit hard to explain. Basically, the image itself needs to be rotated to the rotation of the actor to determine where each pixel of the image resides in the world. Only those parts of the image that are inside the largest circle you can draw within the frame of the image are guaranteed to remain within the frame of the image when rotating it. Therefore, the image needs to be drawn onto a larger frame before rotating it to avoid loss of image. That larger frame is what I called the 'image base'.
@hoyaduyin, I cannot be sure what the first part (deciding which image should be 'a_big' or 'a_small') is for or even if it matters. However, the rest is pretty straight-forward. Copy the images only a image base large enough to rotate them without losing any of the image, rotating them to the rotation of the actor the image belongs to and comparing the pixels that overlay each other to see if any set compared are both non-transparent.
@hoyaduyin, there are two 'touch' methods in the project. The one listed above iterates through the actors of the given class. If any of these actors are found to intersect this object, the other 'touch' method is called to check for non-transparent collision between the two objects.