It's too bad that you have to use hackish methods to get this to work, preventing actor rotation/transparency working without some extra code, but it looks and functions awesomely :D It might be an interesting challenge to make the Magnifier class completely self sufficient, so you wouldn't need any of the extra code in TheWorld, and you wouldn't need to but all other actors in a subclass of OtherActor. That way anybody could import your class into their scenario and have a magnifier :D

Yeah, I was going to do that originally, but I kind of forgot about it while making it >.< I'll sort it all out now, expect an update soon.

Thanks Builderboy2005 for making me make it self-sufficient :p Also, while writing this I've just realised that I forgot to add in support for rotated actor's, but I'm heading to bed soon so its likely that I'll do that tomorrow

That last update was a bug fix for rotated actor's support - before it was appearing to be cutting off the edges of rotated actors when they were magnified.

You might be interested to know that you actually can gain access to the Image the world displays (including actors). The code would be as follows; JPanel panel = WorldHandler.getInstance().getWorldCanvas(); BufferedImage buff = new BufferedImage(panel.getWidth(),panel.getHeight(),java.awt.image.BufferedImage.TYPE_INT_RGB); Graphics g = buff.getGraphics(); panel.paint(g); Through that code you are able to generate a Graphics and a BufferedImage that have the data of the World Image. There is no easy way to transform this data into a GreenfootImage as far as I can see, but you can easily access individual pixel color, which would make your scenario work extremely well I think. No matter how many actors on the screen, your code would still be running at the same speed, since you wouldn't need to redraw any of the actors.

Although that'd be amazing, it includes the magnify image itself (I might be wrong here, but I think that'd mean it'd be zoomed whatever the normal zoom is squared)... Actually I might have thought of a way round that. BRB :p (Major props if it works! - although it doesn't slow down the scenario at all on my computer - which only has a 3ghz processor - I'd noticed on slower computers it did)

It may be an undocumented and unsupported command, but I think it should stay :D How else can we do crazy things like hiding the mouse and scroll wheel access! And yeah Duta it might be tricky to make sure the magnifying glass isn't included, but I think it might be able to work.

I was going to do something along the lines of: getImage().clear(); getWorld().repaint(); <the code you supplied>

I was kind of expecting this, but the repaint()ing makes the image flicker, and my method doesn't seem to be working as it just gives the magnifier a black image :/ Here's my code: private GreenfootImage getWorldImage() { getImage().clear(); getWorld().repaint(); JPanel panel = WorldHandler.getInstance().getWorldCanvas(); BufferedImage buff = new BufferedImage(panel.getWidth(), panel.getHeight(), BufferedImage.TYPE_INT_RGB); //Note: buff.getWidth() - 2 == getWorld().getWidth() // (and the same for height) // (I assume this is the 1 pixel thick border around the perimeter of the world) GreenfootImage img = new GreenfootImage(buff.getWidth() - 2, buff.getHeight() - 2); for(int x = 0; x < img.getWidth(); x++) { for(int y = 0; y < img.getHeight(); y++) { Color colour = new Color(buff.getRGB(x + 1, y + 1)); img.setColorAt(x, y, colour); } } return img; } I'm assuming its a problem with the line Color colour = new Color(etc) line...

You didn't include Graphics g = buff.getGraphics(); panel.paint(g); That is actually important you know :P

Ah, you legend! :p I hadn't paid much attention to those lines >.< Its working now, I'll upload it soon - just going to comment some methods

This method does lag a little for me, but I think it's because you are creating a whole new GreenfootImage and looping through it pixel for pixel. It would be *much* faster to skip the GreenfootImage part and just sample the pixels needed to produce the magnified part

That (should be) fixed now - it took me longer than expected as it turned out I was barking up the wrong tree for a while on the cause of the error - I'd misread the line of code it quoted in the error message >.<

I've got one or two ideas for improving the efficiency of this further - I'll try it now, but it may be slow due to me being at college and the computer I'm working on is less than great...

I've just found that the panel.paint(g) code is causing an error when you click reset - This is only an issue if running it from within the Greenfoot IDE or via command prompt, as it still lets the world reset, it just gives you the error code - due to this it's not on my priority list to be honest