Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Accelerated Image with Transparency.BITMASK on Linux  (Read 4769 times)
0 Members and 1 Guest are viewing this topic.
Offline cghislai

Junior Newbie





« Posted 2008-12-17 23:56:42 »

Hi all,

Im trying to use accelerated graphics for my game. I just discovered my VolatileImage were not accelerated. From [1], in the 1.5 API, only OPAQUE images were accelerated. I can't find any info regarding this with the 1.6 API. Somwhere on your forum, i see that only BufferedImage can be accelerated with transparency, but my code below shows that my BufferImage are never accelerated. My question is simple : how do i get an accelerated transparent image with Transparency.BITMASK on Linux (and, hopefully, all platforms)?

The code below is a small test i wrote while trying to figure out how to do this.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

package abricots.test;

import java.awt.AWTException;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.ImageCapabilities;
import java.awt.Transparency;
import java.awt.image.VolatileImage;

/**
 *
 * @author cghislai
 */

public class testAccel {

    public testAccel() {
        GraphicsEnvironment graphicsEnvironment = GraphicsEnvironment.
                getLocalGraphicsEnvironment();
        for (GraphicsDevice graphicsDevice : graphicsEnvironment.
                getScreenDevices()) {
            System.out.println("DEVICES : " + graphicsDevice.getIDstring());
            System.out.println("   - MEM :" + graphicsDevice.
                    getAvailableAcceleratedMemory());
            System.out.println("   - DISPLAYCHANGE : " + graphicsDevice.
                    isDisplayChangeSupported());
            System.out.println("   - FULLSCREEN : " + graphicsDevice.
                    isFullScreenSupported());
        }
        GraphicsDevice graphicsDevice = graphicsEnvironment.
                getDefaultScreenDevice();
        GraphicsConfiguration graphicsConfiguration = null;
        for (GraphicsConfiguration gc : graphicsDevice.getConfigurations()) {
            System.out.println("CONFIGURATION : " + gc.toString());
            System.out.println("   - BOUNDS :" + gc.getBounds().
                    getWidth() + " x " + gc.getBounds().
                    getHeight());
            System.out.println("   - BUFFER : FullScreenRequired:" + gc.
                    getBufferCapabilities().isFullScreenRequired());
            System.out.println("   - BUFFER : Multi:" + gc.getBufferCapabilities().
                    isMultiBufferAvailable());
            System.out.println("   - BUFFER : PageFlipping:" + gc.
                    getBufferCapabilities().isPageFlipping());
            System.out.println("   - BUFFER : BackBuffer Accelerated:" + gc.
                    getBufferCapabilities().getBackBufferCapabilities().
                    isAccelerated());
            System.out.println("   - BUFFER : FrontBuffer Accelerated:" + gc.
                    getBufferCapabilities().getFrontBufferCapabilities().
                    isAccelerated());

            System.out.println("   - IMAGE :  Accelerated:" + gc.
                    getImageCapabilities().isAccelerated());
            System.out.println("   - COLOR MODEL : " + gc.getColorModel().
                    toString());


            if (gc.getBufferCapabilities().isPageFlipping() &&
                    gc.getBufferCapabilities().
                    getBackBufferCapabilities().isAccelerated() &&
                    gc.getBufferCapabilities().
                    getFrontBufferCapabilities().isAccelerated() &&
                    gc.getImageCapabilities().isAccelerated() &&
                    gc.getColorModel(Transparency.BITMASK) != null) {
                graphicsConfiguration = gc;
                break;
            }
        }

        VolatileImage im = graphicsConfiguration.createCompatibleVolatileImage(
                20, 20);
        System.out.println("VImage accelerated :" + im.getCapabilities().
                isAccelerated());
        im = graphicsConfiguration.createCompatibleVolatileImage(
                20, 20, Transparency.BITMASK);
        System.out.println("tr VImage accelerated :" + im.getCapabilities().
                isAccelerated());
        ImageCapabilities caps = new ImageCapabilities(true);
        try {
            im = graphicsConfiguration.createCompatibleVolatileImage(20, 20,
                                                                     caps,
                                                                     Transparency.BITMASK);
        } catch (AWTException ex) {
            System.out.println("Cant create accel VImage");
        }

        BufferedImage bim = graphicsConfiguration.createCompatibleImage(
                20, 20);
        System.out.println("BImage accelerated :" + bim.getCapabilities(graphicsConfiguration).
                isAccelerated());
        bim = graphicsConfiguration.createCompatibleImage(
                20, 20, Transparency.BITMASK);
        System.out.println("tr BImage accelerated :" + bim.getCapabilities(graphicsConfiguration).
                isAccelerated());

    }
}


Thanks,

Charly


[1] http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #1 - Posted 2008-12-18 19:06:30 »

BITMASK Volatile images aren't accelerated in 1.5 or 1.6.

Why would you need to use one? VI is typically used as a back-buffer (better yet, of course, to use BufferStrategy for that).

In 6u10 TRANSLUCENT VIs are accelerated on Windows. On Linux, only with OpenGL pipeline enabled (since 1.5).

Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #2 - Posted 2008-12-18 19:10:51 »

To clarify: use TRANSLUCENT VI instead of BITMASK if you really need non-opaque VIs.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cghislai

Junior Newbie





« Reply #3 - Posted 2008-12-18 19:33:09 »

Thanks for reply. I was using VolatileImage because i found on the blog of one java graphic developper that they are good for managing acceleration. In addition, i tested accelerated TRANSLUCENT BufferedImage and VolatileImage ; only the last one gets accelerated.

I use 1 big volatile image as a backBuffer in addition of a buffer strategy. The buffer strategy holds the screen buffer, while my own buffer holds the whole game area. different cameras can point to different parts of the game area and render them on screen at the same time, so i draw needed sprites on my back buffer and draw part of it to the strategy. I use this to avoid drawing the same sprite more than one time when more than one camera sees it.

Anyway, thanks for reply, accelerated TRANSLUCENT VolatileImage works fine using the opengl pipeline. Can you provide a reliable source for this information? I guess ive skipped this during my searches...

Regards,

Charly

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #4 - Posted 2008-12-19 18:46:51 »

Can you provide a reliable source for this information?

trembovetski is probably the most reliable source of info you can get for anything Java2D  Wink

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #5 - Posted 2008-12-19 23:45:31 »

Thanks for reply. I was using VolatileImage because i found on the blog of one java graphic developper that they are good for managing acceleration. In addition, i tested accelerated TRANSLUCENT BufferedImage and VolatileImage ; only the last one gets accelerated.

Well, BufferedImages and VolatileImages serve different purposes, so they "manage acceleration" in differet ways.

Typically you'd use VolatileImage as a backbuffer, because rendering _to_ such image can be accelerated (as well as _from_). And you'd use BufferedImage for sprites and other things that don't get changed often, since rendering _from_ such image can be accelerated (once it gets cached in video memory).

You can get all fancy and use non-opaque VolatileImages for sprites (typically to save heap space) but it's more hassle, and as you found out sometimes they can't be accelerated.

Quote
I use 1 big volatile image as a backBuffer in addition of a buffer strategy. The buffer strategy holds the screen buffer, while my own buffer holds the whole game area. different cameras can point to different parts of the game area and render them on screen at the same time, so i draw needed sprites on my back buffer and draw part of it to the strategy. I use this to avoid drawing the same sprite more than one time when more than one camera sees it.

I would think that you'd want an Opaque VolatileImage for this case, not translucent or bitmask. Opaque VIs have the most chances of being accelerated across platforms and jdk versions.

Quote
Anyway, thanks for reply, accelerated TRANSLUCENT VolatileImage works fine using the opengl pipeline. Can you provide a reliable source for this information? I guess ive skipped this during my searches...

Unfortunately there isn't really a single source where you can get this kind of information.
There are some articles here and there, but they're mostly obsolete since they were written for 1.5 or pre-6u10.
One of these days I'll find time to write up something.

Dmitri
Offline cghislai

Junior Newbie





« Reply #6 - Posted 2008-12-20 14:30:07 »

Typically you'd use VolatileImage as a backbuffer, because rendering _to_ such image can be accelerated (as well as _from_). And you'd use BufferedImage for sprites and other things that don't get changed often, since rendering _from_ such image can be accelerated (once it gets cached in video memory).
Youre right, using transparency on my buffer is useless. But regarding my sprites that need to be rotated, i think i need both of them: a BufferedImage holding the sprite image,  the one loaded from file; and a VolatileImage holding the real image that is copied to my buffer. When the sprite's angle has changed, i clear the volatile and copy the Buffered applying the rotation.
Or is it better to just keep the Buffered one and apply the rotation when copying it to the buffer? I thought rotation was an heavy operation and i could skip if if uneeded by holding a copy of the rotated sprite.

So, to summary all this up ; correct me if Im wrong :
- Drawing TO and FROM VolatileImage is accelerated.
- Drawing FROM BufferedImage is accelerated once it has been cached in VideoMemory (thats automatically done when image is copied several times)
- BITMASK Volatile images aren't accelerated in 1.5 or 1.6.
- TRANSLUCENT Volatile images are accelerated on Windows or, using OpenGL pipeline, all platforms.
- OPAQUE Volatile images have the most chances of being accelerated across platforms and jdk versions.

Thanks,

Charly
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #7 - Posted 2008-12-20 14:39:58 »

I hate to say it, but you'll be much more productive if you use Slick.

It 'just works'. Something that cannot be said for the Java2D pipeline.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline cghislai

Junior Newbie





« Reply #8 - Posted 2008-12-20 16:52:58 »

I hate to say it, but you'll be much more productive if you use Slick.

It 'just works'. Something that cannot be said for the Java2D pipeline.

Yeah, Slick seems really good... But I'd really like to know the java capabilities (lwjgl uses opengl directly, im I wrong?), so Ill continue using only sun's java libs for now. Anyway, as i designed things, it really shouldn't be hard to switch to Slick, just a matter of implementing a couple of interfaces.

And regarding productivity, im somewhat satisfied. Things are going forward. Im just making sure everything works fine before adding more contents and logic.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #9 - Posted 2008-12-21 08:23:59 »

Youre right, using transparency on my buffer is useless. But regarding my sprites that need to be rotated, i think i need both of them: a BufferedImage holding the sprite image,  the one loaded from file; and a VolatileImage holding the real image that is copied to my buffer. When the sprite's angle has changed, i clear the volatile and copy the Buffered applying the rotation.
Or is it better to just keep the Buffered one and apply the rotation when copying it to the buffer? I thought rotation was an heavy operation and i could skip if if uneeded by holding a copy of the rotated sprite.

If the image transform operation is hw accelerated (which it is with the opengl or d3d pipelines), image rotation is basically free as it's a simple texture mapping operation. If there's now hw acceleration then indeed it may be better to cache the rotated version. But the latter only makes sense if you make more than one copy from this cached image.

If your rotation angles are predetermined you can pre-render all rotated versions into a single sprite sheet - an image containing all possible rotations of your sprite (either at run time or at build time) and just copy the corresponding rotated version from that sprite sheet
using drawImage(src rect, dst rect) variant.

Quote
So, to summary all this up ; correct me if Im wrong :
- Drawing TO and FROM VolatileImage is accelerated.

Yes.

Quote
- Drawing FROM BufferedImage is accelerated once it has been cached in VideoMemory (thats automatically done when image is copied several times)

Correct. There are cases when BI can't be cached (like if you got a hold of the data buffer, or if the image is too large, or if this type of image can't be cached - like translucent images on Linux w/o the opengl pipeline).

Quote
- BITMASK Volatile images aren't accelerated in 1.5 or 1.6.

Correct.

Quote
- TRANSLUCENT Volatile images are accelerated on Windows or, using OpenGL pipeline, all platforms.

Correct. See the D3D pipeline section in 6u10 release notes for details: http://java.sun.com/javase/6/webnotes/6u10.html .

Quote
- OPAQUE Volatile images have the most chances of being accelerated across platforms and jdk versions.

Yes. However, even if the image is "accelerated" it may not mean that all kinds of rendering operations are
accelerated. For example, in pre-6u10 jdk on windows only simple blits were hw accelerated (unless you
enabled the d3d pipeline with -Dsun.java2d.d3d=true), but not the transforms.

It's unfortunate that our hw-acceleration story is so complicated. =(

Thanks,
  Dmitri
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online CommanderKeith
« Reply #10 - Posted 2008-12-21 08:54:45 »

I hate to say it, but you'll be much more productive if you use Slick.

It 'just works'. Something that cannot be said for the Java2D pipeline.

To be fair, Java2D does always work because it has a software pipeline to fall back on. But performance is highly variable.

On the other hand, frameworks relying on OpenGL often do not work at all due to driver problems. But if it does work, it's lightning fast.

Offline cghislai

Junior Newbie





« Reply #11 - Posted 2008-12-23 17:06:03 »

If the image transform operation is hw accelerated (which it is with the opengl or d3d pipelines), image rotation is basically free as it's a simple texture mapping operation.
Thanks, rendering is effectively as fast as light doing the rotation each frame, and the code is really clearer.
I use opengl pipeline so it should work on all platform.

Quote
It's unfortunate that our hw-acceleration story is so complicated. =(
In fact it makes sense once you think about it. One should just know how rendering is done in all case. Your answers and this article (http://today.java.net/pub/a/today/2004/11/12/graphics2d.html) might help.

Regards,

Charly
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #12 - Posted 2009-01-03 21:42:28 »

In fact it makes sense once you think about it. One should just know how rendering is done in all case.

It's a failure of the abstraction if you need to know what is going on 'under the hood'.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (44 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!