Newbie, summary of research:

[hymatron]

Hey guys, as you can see by the subject header I’m new to this scene/subculture. I’m currently working on a game engine and I have a couple of questions concerning the hardware acceleration in java. Actually I have more of a summary of the research I’ve done.

1. Use VolatileImages for the backbuffer. They will blit to the screen faster because java will be moving image data from VRAM to VRAM
2. Use “Managed” images (applet.getImage()) for sprites and blitting to volatile images. Java takes care of the acceleration in the background through the API
3. Use bufferedImages if you need access to pixel data (special effects) slowest of all imges, no hardware acceleration.

Are the three asumptions I’ve made correct?

Another question: Currently my engine is setup to auto-detect hardware acceleration. I then load 1 of three renderes according to the following criteria:

1. If the system supports accelerated images and they are true volatileImages then load TrueVolatileRenderer
2. If the system supportts volatile images and they are not true volatile (ie linux… uses pixelmaps or something) use VolatileRenderer
3. If no accleration can be used use a bufferedImage renderer…

How does the logic sound up there? I divided the renderers up purely for speed… less calcs have to be made if the system is in state 2 then state 3 so I created a differed renderer etc…

Thanks, in advance

[jbanes]

Use a BufferStrategy instead of creating VolatileImages yourself. The BufferStrategy allows Java to choose the most efficient way of rendering the data to the screen.

[hymatron]

Umm, thanks for the suggestion… You didn’t answer any of my questions though… :-[

[jbanes]

Sorry, a bit tired. Here are a few other things:

1. Don’t use applet.getImage(). Use either Toolkit.getImage() or do like Abuse likes to do and load the image with ImageIO and copy it into an image created with GraphicsConfiguration.createCompatibleImage().

2. You don’t need different renderers if you use BufferStrategy. The job of BufferStrategy is to automatically use the best renderer.

3. We have a subculture? Cool! Where do I sign up?

Other than that, all your assumptions seem to be correct. Or maybe I’ll wake up tomorrow and find more. Either way, good night.

[Abuse]

[quote]Sorry, a bit tired. Here are a few other things:

1. Don’t use applet.getImage(). Use either Toolkit.getImage() or do like Abuse likes to do and load the image with ImageIO and copy it into an image created with GraphicsConfiguration.createCompatibleImage().
   [/quote]
   lol, you make me sound odd jbanes :

p.s.

Why does every1 insist on using toolkit.getImage() ?

public abstract Image getImage(String filename)

Returns an image which gets pixel data from the specified file, whose format can be either GIF, JPEG or PNG. The underlying toolkit attempts to resolve multiple requests with the same filename to the same returned Image. Since the mechanism required to facilitate this sharing of Image objects may continue to hold onto images that are no longer of use for an indefinite period of time, developers are encouraged to implement their own caching of images by using the createImage variant wherever available.

[hymatron]

Alright, I’ll give BufferStrategy a whirl… I won’t delete my other renderers yet though, I’ll just plugin a new BufferStrategyRenderer… and profile my code… Let’s see if suns code “Actually optimizes by choosing the best config” I’m somehow a bit skeptical. I forgot to mention, I’m not using fullscreen mode, so there will be no page flipping in my near future :’(

Thanks, again for the info.