Slick Forums

That might be part of it but it still doesn't explain the whole thing. The testing I've done produced inconsistent results so I couldn't even compensate for reversed or translated coordinates. Also, there seem to be color and transform inconsistencies.

_________________
Current Testing Machine:
Windows 7 x64, 4GB RAM DDR3, 3.3ghz AMD Athlon II X3 455, AMD Radeon HD 6800 series.

Color?

_________________
"The Keeper is aware. The Keeper understands. The Keeper has seen the enemy."

Yeah! I'm not in a position right now to reproduce this issue but what I remember is that I colored some other unrelated image or graphics object and it somehow affected the appearance of my next one. Truly bizarre but I didn't bother to document it because I figured it was broken and not worth anymore time.

_________________
Current Testing Machine:
Windows 7 x64, 4GB RAM DDR3, 3.3ghz AMD Athlon II X3 455, AMD Radeon HD 6800 series.

Yeah applies to many bugs with Slick, especially when using OpenGL directly - which, I know, isn't obviously supported

Some things to note.

1. There is a memory leak using new Image(256, 256) and then getGraphics -- I proposed a fix in the dev branch. More details:
   bug report
   further discussion / implementation
   
   It looks like this:
   
   Code:
   img = Image.createOffscreenImage(256, 256); //<-- creates FBO-bound texture
   g2 = img.getGraphics(); //<-- FBO-bound texture already created, no memory leak
   
   
2. When you call Graphics.flush(), the context is disabled. For example:
   
   Code:
   renderImage = Image.createOffscreenImage(256, 256);
   Graphics g2 = img.getGraphics();
   ... use it ...
   g2.flush(); //<-- now disabled
   
   From there, certain calls to g2 might not work as expected. Apparently copyArea did not check predraw/postdraw, which is why it would appear black. I've now fixed that in the dev branch; now you shouldn't need to draw your "outline" beforehand. For future reference, I would encourage using Graphics.setCurrent before rendering if you plan to switch contexts. Examples:
   
   Code:
   //I don't know why you'd want to do this... but let's say you do:
   g.flush(); //<-- disables the context
   Graphics.setCurrent(g); //<-- re-enables the context
   
   //here is a more realistic scenario
   Graphics.setCurrent(imgGraphics); //<-- anything below now safely goes to imgGraphics
   myImage.draw(0, 0, 800, 600); //<-- notice Graphics.drawImage isn't necessary
   imgGraphics.flush(); //<-- don't forget to disable once we're done...
   
   
3. Because you are still using the same graphics context, you don't need to flush it that many times. Just flush it once and for all once you're done rendering everything to it.

Unfortunately because of the way that Kev tried to conform Slick to Java2D standards, there are a few bugs here and there that come up with context switches and other lower-level OpenGL stuff. If it were up to me the whole Slick library would be rewritten to conform to better OpenGL coding standards, but of course nobody would like that. I'll try to add more of these gotchas into the wikis when I get a chance.

Regarding the flipping, it's occurring because of some difference in the projection matrix between FBO graphics and on-screen graphics. Not sure, will have to look into it further. For now you can fix the image by either using offscreen rendering to copy your images, or simply flipping the image after copying it (getFlippedCopy).

Groovy! Thanks for doing that.

_________________
Current Testing Machine:
Windows 7 x64, 4GB RAM DDR3, 3.3ghz AMD Athlon II X3 455, AMD Radeon HD 6800 series.