Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (523)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
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  
  Why Doesn't this Alpha Work  (Read 2784 times)
0 Members and 1 Guest are viewing this topic.
Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Posted 2003-07-08 10:38:06 »

I'm trying to write a HUD for a 2d project , I want it to basically be a translucent black rectangle w/ items on it. I can draw directly to the Graphics object and everything works but it is painfully slow. When I try to use a buffered image instead, it always comes out solid black. I'm using the hardware acceleration flags. Any Ideas? Here is the code:
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  
/*
 * HUD.java
 */


package com.krypto.k2.graphics.hud;

import com.krypto.k2.graphics.GFXEngine;
import java.awt.AlphaComposite;
import java.awt.Color;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.Transparency;
import java.awt.image.BufferedImage;

/**
 *
 * @author  Krypto
 */

public class HUD
{
    LifeCounter lifeCounter = new LifeCounter(5);
    int x = 0;
    int y = 0;
    int width = 0;
    int height = 0;
    Color color = new Color(0.0f,0.0f,0.0f,0.5f);
    BufferedImage image = null;
           
    /** Creates a new instance of HUD */
    public HUD()
    {
        y = GFXEngine.screenHeight-100;
        height = 100;
        width = GFXEngine.screenWidth;
        image = GFXEngine.getGC().createCompatibleImage(width,height,Transparency.TRANSLUCENT);//new BufferedImage(width,height,BufferedImage.TYPE_INT_ARGB);
    }
   
    public void render (Graphics g)
    {      
        Graphics2D g2 = (Graphics2D)image.getGraphics();
        g2.setColor (color);      
        g2.fillRect (0,0,width, height);  
        g2.setComposite(AlphaComposite.Src);
        lifeCounter.render(g2,0,20);
        g.drawImage(image,x,y,null);
    }
       
}

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #1 - Posted 2003-07-08 12:45:51 »

Okay, Now it works but it is dirt slow Angry

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #2 - Posted 2003-07-08 13:03:26 »

Without hardware acceleration it would be.  Software alpha blending would require a read-modify-write to the graphics memory and reading from VRAM is VERY slow.

Maybe it is not accelerated for some reason.. you said you were using the flags to enable translucent HW acceleration.. but perhaps it isn't kicking in?  See if not setting those properties slows it down even more.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #3 - Posted 2003-07-08 13:17:25 »

I removed the flags and it runs just as slow. I did see the messages when starting up the jvm that said the options were taking effect. But it seems no faster. I'm also using the latest jdk. Huh

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #4 - Posted 2003-07-08 14:35:13 »

if you are modifying the ManagedImage 'image' every frame, then ofcourse it won't be accelerated.

If you want to modify an image in vram, you have to use a VolatileImage. Ofcourse, you need a translucent VolatileImage; and this is impossible with the current API.

The solution, is to stop using the intermediary HUD image; and simply blit each element of the HUD to the screen step-by-step.

This requires less Vram, and although will require more drawImage calls, will infact be quicker because the total area being copied will be significantly smaller.

This should do what your after :-


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  
package com.krypto.k2.graphics.hud; 
 
import com.krypto.k2.graphics.GFXEngine;
import java.awt.AlphaComposite;
import java.awt.Color;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.Transparency;
import java.awt.image.BufferedImage;
 
/**
 *
 * @author  Krypto
 */

public class HUD
{
    LifeCounter lifeCounter = new LifeCounter(5);
    int x = 0;
    int y = 0;
    int width = 0;
    int height = 0;
   AlphaComposite ac = AlphaComposite.getInstance(Alphacomposite.SRC_OVER, 0.5f);
  
    /** Creates a new instance of HUD */
    public HUD()
    {
   y = GFXEngine.screenHeight-100;
   height = 100;
   width = GFXEngine.screenWidth;
    }  
    
    public void render (Graphics g)
    {  
        Graphics2D g2d = (Graphics2D)g;
        Composite c = g2d.getComposite();//backup the old composite

        g2d.setComposite(ac);
        g2d.drawImage(lifeCounter,0,20,null);
        //draw the other elements of your HUD here

        g2d.setComposite(c);//restore the old composite so it doesn't mess up any future rendering
    }
}

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #5 - Posted 2003-07-08 14:47:27 »

If we get support for windows with alpha channels in AWT maybe you could use that.

Of course if you go the JOGL or LWJGL route then you can get what you want easily enough too.

Perhaps it is time to start learning more OpenGL...

Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #6 - Posted 2003-07-08 15:00:16 »

Thanks for the great reply, but I still can't draw a translucent background on th hud as soon as I do, it slows right down. However other hud items do show up translucent, ands don't seem to affect rendering speed. If i hack and use a black rectangle image, it is still slow, probably because it is too big for vram, so I make a 16x16 one and drawImage. This is translucent and doesn't slow rendering speed. How Do I draw it larger than It actually IS. i.e. scaled?

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #7 - Posted 2003-07-08 15:18:27 »

You may want to draw it multiple times instead of drawing it scaled, as the scaling code may slow it down more, depending on how it is implemented (e.g. scaled blits might not be HW accelerated)

That being said look at the various drawImage methods.. there are scaling versions.

Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #8 - Posted 2003-07-08 15:58:28 »

IF i understand correctly what your saying, the code below runs slowly?

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  
package com.krypto.k2.graphics.hud;  
  
import com.krypto.k2.graphics.GFXEngine;  
import java.awt.AlphaComposite;  
import java.awt.Color;  
import java.awt.Graphics;  
import java.awt.Graphics2D;  
import java.awt.Transparency;  
import java.awt.image.BufferedImage;  
  
/**  
 *  
 * @author  Krypto  
 */
 
public class HUD  
{  
    LifeCounter lifeCounter = new LifeCounter(5);  
    int x = 0;  
    int y = 0;  
    int width = 0;  
    int height = 0;  
    AlphaComposite ac = AlphaComposite.getInstance(Alphacomposite.SRC_OVER, 0.5f);
       Image backImage;

    VolatileImage hudBackground;
    
    
    /** Creates a new instance of HUD */  
    public HUD()  
    {  
   y = GFXEngine.screenHeight-100;  
   height = 100;  
   width = GFXEngine.screenWidth;  
       hudBackground = GFXEngine.getGC().createCompatibleVolatileImage(width,height);
       backImage = javax.imageio.ImageIO.read("yourFullscreenSizedBackgroundImage.png");
    }
      
    public void render (Graphics g)  
    {    
        Graphics2D g2d = (Graphics2D)g;
        Composite c = g2d.getComposite();//backup the old composite
        g2d.setComposite(ac);
        if(hudBackground.contentsLost()) //i know this check isn't bullet proof - but it should work most of the time
        {
            System.out.println("VolatileImage Contents Lost - recreating back image");
            Graphics hbg = hudBackground.getGraphics();
            hbg.drawImage(backImage,0,0,null);
            hbg.dispose();
        }
        g2d.drawImage(hudBackground,0,0,null);
        g2d.drawImage(lifeCounter,0,20,null);
        //draw the other elements of your HUD here
 
        g2d.setComposite(c);//restore the old composite so it doesn't mess up any future rendering
    }  
}


my appologises for the indenting (and any errors/typos you may find) im coding straight to the forums Wink

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

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #9 - Posted 2003-07-08 16:20:27 »

Abuse I took that last example, included the apropriate imports, and It compiles.
I only get get 9 fps. I was getting 30+ fps without the hud.  :-/

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #10 - Posted 2003-07-08 21:35:30 »

ahhhhh.

AlphaCompositing is only accelerated when being applied to an image that is already in ARGB format.

VolatileImages are RGB, hence applying an AlphaComposite to the image will NOT be accelerated.

To put it bluntly, i think your phucked :-/

The current implementation of hardware acclerated full alpha transparency is not complete.

I think your gonna have to wait until Java1.5 before you get hardware acceleration in that particular scenario Sad

Alternatively; (as suggested by palmer) you can completely forget about the Java2D API, and start learning the JOGL, JOAL and JInput APIs.

Put simply they are the future for Games on the Java platform.

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

« JGO Spiffy Duke »


Medals: 205
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #11 - Posted 2003-07-09 04:56:11 »

Quote
Put simply they are the future for Games on the Java platform.


Argh! Not again!!!! Its always going to be the case that its horses for courses. Especially at the moment when the new APIs arn't even core.

Put simply, always abstract away from your rendering layer, otherwise when someone else comes up with a "great" new idea, you'll be phucked again.

Kev


Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #12 - Posted 2003-07-09 05:46:37 »

Quote


Argh! Not again!!!!


Again?

We've never had an official Game Oriented Java API Huh

Quote

Put simply, always abstract away from your rendering layer, otherwise when someone else comes up with a "great" new idea, you'll be phucked again.


abstract abstract abstract.

If you keep abstracting for long enough; nothing gets done :-/

There is nothing wrong with tieing yourself to 1 API; just make sure its a capable API.
Java2D is NOT.
LWJGL is.
JOGL will be.

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

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #13 - Posted 2003-07-09 07:25:32 »

Quote
you can completely forget about the Java2D API, and start learning the JOGL, JOAL and JInput APIs.
Put simply they are the future for Games on the Java platform.


Thanks for the advice, but the whole reason I started this project is because my laptop (the machine I develop on) doesn't support J3D/ gl4java/ lwjgl quite well enough SO I was so excited to see I could actually get a good framerate w/ Java2D. Anyways this project is a learning experience, It won't kill me to wait for 1.5.


Thanks for trying though.


JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline kevglass

« JGO Spiffy Duke »


Medals: 205
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #14 - Posted 2003-07-09 12:29:55 »

Quote
Again?

We've never had an official Game Oriented Java API  


Again - somebody spouting on about how the only thing that is important in gaming is getting fast flash graphics to the screen and only [insert your own API] is good enough. blah blah blah blah blah...

Quote
There is nothing wrong with tieing yourself to 1 API; just make sure its a capable API.
Java2D is NOT.
LWJGL is.
JOGL will be.


Nothing's wrong with tieing yourself to 1 API (unless of course it goes tits up, re: Java3D).

Java2D is NOT? Its not capable of high speed 3d graphics, no.. you're quite right. However, that doesn't mean its not suitable for other types of game. Right tool for the job.

Come to think of it, I'm not even sure why I'm writing this, I'm sure you're a complete zealot of your view and arn't interested in hearing anything else.

Kev,
I mean Human,
I mean Entity,
I mean Matter,
I mean Energy.

Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #15 - Posted 2003-07-09 14:34:26 »

eek! don't get so rawled up! (hmm, rawled... is that even a word and is that how its spelt???)

I'm simply highlighting the limitations of Java2D that make it unsuitable for realtime 2D games.

AffineTransform is useless because of the garbage it causes; and because it isn't hardware accelerated.

AlphaCompositing is only hardware accelerated when the appropriate flags are set. Even then it is only partialy implemented.

It is impossible with the current API to have transparent/translucent VolatileImages.

I could keep going, but you get teh picture; you don't get very far into the development of a game before you realise Java2D cannot provide the necessary functionality.

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

Senior Devvie




If only I knew what I'm talking about!


« Reply #16 - Posted 2003-07-10 22:20:31 »

> AlphaCompositing is only accelerated when being applied to an
> image that is already in ARGB format.
> VolatileImages are RGB, hence applying an AlphaComposite to the
> image will NOT be accelerated.

This is not correct: assuming appropriate flag is set,
AlphaCompositing operations will be accelerated
if source image was created with createCompatibleImage(w,h,
Transparency.TRANSLUCENT), and the destination is either
screen or VolatileImage.
VolatileImage, which is the destination in this case, is typically
accelerated.

The problem is likely that the source image is being modified
on each frame, so it never gets accelerated.

You can use tracing flags to check if accelelrated loops are
being used:
java -Dsun.java2d.trace=log YourApp
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #17 - Posted 2003-07-10 23:07:47 »

I think you've mis-interpretted what I meant.

I was saying that applying an AlphaComposite operation to an image that has no Alpha Channel will NOT be accelerated.
Even if the image being used is a ManagedImage.

e.g.
drawn with an AlphaComposite :-

  • VolatileImages will NOT be accelerated.
  • ManagedImages with OPAQUE or BITMASK will NOT be accelerated
  • Only if the ManagedImage is TRANSLUCENT will the AlphaComposite be accelerated.

    (if these assertions above are incorrect, pls pls pls correct me Grin)
    (oh and im talking about the source image type. The destination image in all cases is a VolatileImage [or whatever the hell it is that is used for the backbuffers in BufferStrategy])

    Now the problem the poster had; was that he wanted an image in VRAM that he could modify, and then blit to the screen using an AlphaComposite.
    Obviously, as i stated earlier, and u repeated in your post, if you write to a ManagedImage, the copy in VRAM becomes invalid.
    This leaves you the only other alternative of using a VolatileImage, but VolatileImages are not accelerated when drawn with an AlphaComposite.
    Hence my ultimate summary. He is screwed Roll Eyes

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

Senior Devvie




If only I knew what I'm talking about!


« Reply #18 - Posted 2003-07-11 13:08:35 »

Yeah, looks like I misunderstood your posting. We're basically on the same page.
But I don't think he's screwed completely =)

One way he can fix this is have any text he wants to render to be stored in translucent images. Say, have image for all of the numbers, and letters, or just have one image with whole alphabet rendered to it.  Then using a simple lookup (symbol -> coordinates of the corresponding image) he can blit from that image with compositing to the screen and have it accelerated. This is a well known technique.

Now he is screwed =)
Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #19 - Posted 2003-07-11 13:34:43 »

So If i use a managed Image where the original image had an alpha layer , some translucence, it will be hardware accelerated?

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
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.

SHC (24 views)
2014-11-25 12:00:59

SHC (22 views)
2014-11-25 11:53:45

Norakomi (19 views)
2014-11-25 11:26:43

Gibbo3771 (22 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (74 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50

digdugdiggy (46 views)
2014-11-12 21:10:15

digdugdiggy (41 views)
2014-11-12 21:09:33

kovacsa (67 views)
2014-11-07 19:57:14
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!