Try to use double values for the actors Location. Therefore you c an Import the smooth mover class in greenfoot and making it the superclass of all other ones. The driving would be much smoother.
A new version of this scenario was uploaded on Sat Oct 19 19:12:17 UTC 2013
Looks interesting, can't wait to see what you do with this. Also, my laptop has a resolution of 1280 X 800, so I can't see the whole thing at once in browser. If you are concerned at all about fixing this (And I don't really care if you want to focus on the people with lower-resolution monitors or not), lower the world resolution, then use Gevater_Tod4711's fullscreen methods to make it big (it works in the client, not the browser)
A new version of this scenario was uploaded on Sun Oct 20 17:26:24 UTC 2013
Thanks for the feedback guys, its still a work in progress. I will try to implement the smooth movement and i will also change the resolution later on. :)
About the double values for Actors, I don't think it's necessary. It won't give you a noticable effect, because pixels are still adressed using integers, not floating points. Sure, you have more variety in how much you can move each act cycle (you can then do 1.5 instead of 1 or 2), but that's just on paper: displays can't display sub-pixel movement.
@ SPower: You are right, that it can't be displayed. I didn't implemented in for long time in Tiny Tank. But as I've done it a few weeks ago, there was a huge difference. For example:
If my tank has a rotation of about 5 degrees he is only moving to the right and not changing it's y coordinate. That was very ugly because he was a kind of drifting. As I implemented the double values the little numbers for the y movement by 5 degrees rotation were saved in the double values instead of being 0 every time. So the tank moves now exactly into the direction it faces, now.
It wasn't a matter of speed only of precision...
and uglyness :)
@Kartoffelbrot That's a good point. Explanation (if you needed it, but this is just a theory): you save the non-rounded differences in your x and y value, and that way it adds up until it is visible on the pixel part.
That was something I didn't take into consideration, so forget my last comment: it will improve it all a little bit.
@ SPower: Thanks for your explanation, but I know it :).
I didn't thought of it for a long time, too and had no idea what it should be useful for. So I implemented it very late.
2013/10/16
2013/10/20
2013/10/20
2013/10/23
2013/10/23
2013/10/23
2013/10/23
2013/10/23
2013/10/23