Did you take a look at the problems I posted on the first scenario you made? The ones about any coded GreenfootImages turning black or giving the program errors?

I tried to do what you did, but all my scenarios i ever made worked... I think i fixed the error while you found it out :) If it still happens with the latest version, please send me the error-log; via email ( GreenHouse@metropy.net ) or upload it somewhere and send me the link please.

It still has the same glitches as I mentioned before. Try scenarios like my Mouse Force 2.0 for the setting a coded GreenfootImage on an actor, and my Presidential Flash Cards for setting a coded GreenfootImage on the world background to see what I'm talking about

Ah, now i see :) sorry, i didn't notice that before. I updated the greenfoot.jar to fixed this problem. When the world initializes itself, the background gets drawn onto the 3d buffer; but if no image was set, it results null-pointer exception...

Hey, GreenHouse. I found another bug. I like that you fixed the previous problems with coded-imaged-actors, but I found another bug with something similar. I tried out my Raycast Scenario where I have no actors, just a "Camera" that renders the image and sends it to the world (Don't worry, I don't have any of the code connected to your camera). The problem is, the world will set it's first image, but it won't allow the GreenfootImage to change. I've added a statement to the world's saying setBackground(cam.getImage()), and it works, but it's gotten super laggy. I don't know if changes you've made to GreenfootImage has caused this, or if other reasons, but I think some of the lag may be reduced if you allowed the world to change to it's image by itself, like it can in the original greenfoot.

Ah, I think I found where the problem is in the source code. At the end of setBackground(), you draw it onto a newly created "bump" Image, and then change the bump to a texture. If you were to have a method, or edit the background image in a way, that it would change the texture along with the background image, you may get something. That's probably where the lag is coming from as well, changing a GreenfootImage into a Texture. Hope you figure it out.

@Game/maniac: i will add a link, after i created the doc :) @FlyingRabidUnicornPig: the texture that is created from the greenfootImage is first (like all other textures) stored into the render/buffer texture dump. Only these buffered images can be rendered, jpct is quiet blocked this way :/ This buffer can make jpct very fast (up to 200fps and more) but changing the textures every frame makes it slow/buggy... All in all the 3d buffer is not a good solution for fast texture changes :( Maybe i can fix this in an other way..

@JetLennit, with the little I know, and seen, you need to create a folder called "objects" in your scenario folder (along with the "images" and "sounds" folders) then you need to put a model in there (.3ds, .obj, etc.) Then you can reference it using setGeometry("fileName.3ds"). Take a look at GreenHouse's Alpha 3D test to see how he uses it (The Scenario won't work with current version of Greenfoot3D, but it still works with the Actor3D)