VolatileImages losing their contents is part of the API; your code has to account for it. (though I wish the API had been designed differently so this wasn't necessary...)Have a read of the volatile image tutorial.

As for your specific problem:

don't recreate the scratch VolatileImage - create one large enough for your largest sprite & keep hold of it.

If you want the flash itself to be alpha'ed, then you should use the DST_ATOP rule instead.It'll maintain your source's transparency channel but composite the colour channels of source & destination.

Here's a little test app. I knocked up the last time this thread was touched. Forgive the lack of documentation & crude means of animating, it was hacked together Oh, and don't use this as an example of how to do the compositing in a performant manner - this is purely a visualization tool for the compositing rules.

I have read the http://gpwiki.org/index.php/Java:Tutorials:VolatileImage before.Problem is: using the DX pipeline, the mentioned glitch happens, and when using a validation loop, as you should if you use volatileimage, it will result in a infinite loopIt also only happens if you have more than one screen connected and enabled in windowsI have actually found this Bug in the java bug database, so yeah its kinda strange.

I built a similar effect years ago and just used BufferedImages. I turned the images to white on the fly and stored them permanently.

The bit you might be interested in is that in order to get around the memory issues of having hundreds/thousands of images in memory was to store them behind a WeakReference object within a map. When I went to draw I'd grab the image out, if it's null I'd recreate it and store it in the map, then draw using the image. This way the JVM could garbage collect them (if it needed to) and the major JVMs are encouraged to garbage collect the least used weak references first.

In an ideal world this means you'll only ever be storing the whited (or redded) images for the enemies who are currently on screen.

I believe you can also use the other types of references (SoftReference and PhantomReference) if you wanted to try to optimize it further. I can't remember the exact differences, but I believe the JVM will prioritise certain types of references over others when looking to reclaim memory.

So if you find a situation where certain generated images are used waaaaaay more then others then you can cache those behind a different type of reference to reflect this.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org