Accelerated translucency in 1.4.2....

Abuse · October 9, 2003, 1:16pm

It appears acceleration it only applied when drawing onto the back buffers of a BufferStrategy.

Which skuppered my plans for a cool blending effect for particle weapons/explosions and other fx :-/

I foolishly thought that because BufferStrategy uses VolatileImages for its back buffers, the accelerated translucency would be applied to all VolatileImage usage.

It turns out that isn’t the case - Accelerated translucency is only applied when the source image is a Transparency.Translucent Image, AND the destination is a BufferStrategy back buffer.


         VolatileImage blurBuffer = gc.createCompatibleVolatileImage(SCREEN_WIDTH,SCREEN_HEIGHT);
         BufferedImage blackImage = gc.createCompatibleImage(SCREEN_WIDTH,SCREEN_HEIGHT,Transparency.TRANSLUCENT);
         g = blackImage.createGraphics();
         g.setColor(new Color(0x55000000,true));
         g.fillRect(0,0,SCREEN_WIDTH,SCREEN_HEIGHT);

and then in the render loop :-


Graphics2D blurGraphics = blurBuffer.createGraphics();
blurGraphics.drawImage(blackImage,0,0,null); // <<this 1 line takes the fps from 150, down to 10 :-/

//misc effects drawing using blurGraphics

Graphics2D bufferGraphics = bufferStrategy.getDrawGraphics();
bufferGraphics.drawImage(blurBuffer,0,0,null);
//other misc non-blurred drawing

bahhhhhhh, thats annoying

MGodehardt · October 9, 2003, 1:54pm

Translusent Images are NOT accelerated in 1.4.2, u can enable a BUGGY version of transluscent acceleration, but i do not recommend this and sun does it also not recommend.

Abuse · October 9, 2003, 2:02pm

[quote]u can enable a BUGGY version of transluscent acceleration, but i do not recommend this and sun does it also not recommend.
[/quote]
Thats what I was refering to.

Herkules · October 9, 2003, 2:05pm

What is the switch to do so?

Abuse · October 9, 2003, 2:12pm

System.setProperty("sun.java2d.translaccel", "true");

it must be set before any awt stuff initialises.

MGodehardt · October 9, 2003, 3:46pm

But be careful, when enabled some strange things can happen, for e.g. when enabled some diagonal lines will not be drawn until proper Alpha channel settings are set.

I recommend, wait until sun releases 1.5, a customer is much more upset when your game crashes 1000 times, he will quit and i can not pay my bills, bad. Better give him a 98% bullet proof program with less features.

Abuse · October 9, 2003, 3:58pm

Im well aware of all the bugs and limitations in it.

The purpose of this Thread was to highlight 1 such limiation ;D

I’ve got tired of waiting for 1.5, and to find that 1.5 won’t include accelerated transforms on Windows??? sigh

What good is having

a) the image in vram
b) the backbuffer in vram
c) the composite operation done on the gfx card

if the transform has to be done by the cpu in main memory ???

It will result in so much reading back from vram, the end application will be 10times slower than the software only version ???

Oh well, im not gonna rant about it again, I promise :-/

MGodehardt · October 10, 2003, 7:35am

Oh sometimes the performance is 100 times worse with software rendering enabled, depends on your system.

I agree with you Abuse, hw accelerated transformations are a must for good games, isometric worls are not plain, i need some hills and without hw accelerated transformations, its impossible for me to implement this.

Ever played UO ? it uses military isometric and it was the first online game using this technic with success.

i use normal ( 30 degree ) isometric, but at the moment my world is flat, without transformations its impossible for me to transform a terrain tile into a hill, for e.g. one tile is at altitude 0 next is at altitude 10 ( 10 pixels above normal so the tile must be transformed to fill the complete hole between both.

i am using only standard jdk ( no jogl or similiar things ) and i will NEVER use anything not deployed from sun.

trembovetski · October 11, 2003, 3:51am

Hmm, there’s something strange going on. Rendering (or compositing) translucent managed images to VolatileImage is supposed to be accelerated (with the flag enabled, of course).

Try doing this in windowed mode, with bufferstrategy, it’ll use VolatileImages as the buffers.

Also, disable any other rendering except that drawImage call and the vi to screen copy, and run the app with tracing (-Dsun.java2d.trace=log) and see what loop is being used.

Here’s a version of what could be happening: the first copy to a vi will not be accelerated (we accelerate a managed image on the second copy), and the vi gets punted to system memory because we notice that it’s being read from to do the compositing, and it never recovers from it. I’m not really sure why this is not happening with BB. May be it’s because your Vi is smaller than BB, and we decide to punt an image to system memory surface based on percentage of the pixels we had to read from the image.

Try running the app with -Dsun.java2d.ddforcevram=true ,
or with -Dsun.java2d.accthreshold=0 (I think I explained sometime ago what these flags do)…

Abuse · October 11, 2003, 8:16am

ah,
It appears to be accelerated in fullscreen, but not in windowed mode.

Then i set the flag :-

System.setProperty("sun.java2d.accthreshold","0");

and it now works super fast in windowed mode as well

Seems there might be a bug with your acceleration threshold detection

trembovetski · October 13, 2003, 3:22am

So the ddforcevram flag didn’t help?
I wrote a test, and any of these two flags helped.

And I think the cause of this problem is the one I’ve described. It doesn’t happen in fs mode to backbuffer from BufferStrategy because we never punt those to system memory.
So, basically, it’s not a bug but an implementation restriction =)

The test (what am I doing wrong? the formatting
just sucks):


import java.awt.*;
import java.awt.image.*;

public class Test extends Frame {
    VolatileImage vimage;
    Image mimage;

    public Test() {
        pack();
        setSize(350, 360);
        vimage = createVolatileImage(300, 300);
        mimage = 
            getGraphicsConfiguration().
               createCompatibleImage(300, 300, 
                                     Transparency.TRANSLUCENT);
        Graphics g = mimage.getGraphics();
        g.setColor(Color.red);
        g.fillRect(0, 0, 300, 300);
    }

    public void paint(Graphics g) {
        Graphics vg = vimage.getGraphics();
        for (int i = 0; i < 100; i++) {
            vg.drawImage(mimage, 0, 0, null);
        }
        g.clearRect(0, 0, getWidth(), getHeight());
        g.drawImage(vimage, 5, 25, null);
        System.exit(0);
    }

    public static void main(String argv[]) {
        System.setProperty("sun.java2d.trace", "count");
        System.setProperty("sun.java2d.translaccel", "true");
        new Test().setVisible(true);
    }
}

And the output:
$ d:/devtools/java/j2sdk1.4.2/bin/java Test 2>&1 | grep D3D
$ d:/devtools/java/j2sdk1.4.2/bin/java -Dsun.java2d.ddforcevram=true Test 2>&1| grep D3D
98 calls to sun.awt.windows.D3DBlitLoops::Blit(“Integer ARGB D3D with translucency”, SrcOver, “Integer RGB DirectDraw”)
$ d:/devtools/java/j2sdk1.4.2/bin/java -Dsun.java2d.accthreshold=0 Test 2>&1 | grep D3D
100 calls to sun.awt.windows.D3DBlitLoops::Blit(“Integer ARGB D3D with translucency”, SrcOver, “Integer RGB DirectDraw”)

Abuse · October 13, 2003, 9:34am

yup,

soz I should have said; sun.java2d.ddforcevram=true also fixes it =)

I was just so happy that sun.java2d.accthreshold=0 fixed it, i didn’t bother trying the other 1

I’m gonna stick with the accthreshold=0 solution, cos it accelerates all the blits, (which avoids the ugly stutter you get with the forcevram solution, at the start of the app).

Setting the accthreshold flag also takes a few less bytes =) (its for a 4k app. im writing :P)