Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
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  
  Tuning VolatileImage for software-accelerated graphics  (Read 4090 times)
0 Members and 1 Guest are viewing this topic.
Offline broumbroum

Junior Member





« Posted 2008-03-11 00:25:02 »

Hi!
It's been a while since Sun announced graphics acceleration input for their Java platform. It's "true", graphics are used as data buffers rendered to the graphics card output throughout various call-backs, such as RenderedImage's or VolatileImage's. Indeed OpenGL buffers provided the most of soft- and hard-ware acceleration for high-end graphics.
BUT the problem arises when the native librairies don't load on all system's or have to be disabled (e.g. the JAI codecsLib is disabled for Windows) or the System graphics layer are system-dependent (e.g. Apple's Quartz or M'soft DirectX or the open library OpenGL). Sun Java dev's released their Java 6th edition to provide more compatibility with the recent graphics cards buffers and routines, which has still some enhancements to be made till 7th edition.
One of the more accessible solution is to convert RenderedImage to VolatileImage instances to enter up into the VRAM buffers. Heading to this way, we face an uneasy situation where the VolatileImage is known to be instanciated OPAQUE. Now how to provide the same TRANSPARENCY and easiness of the RenderedImage's ?? The solution has become real (since 5th edition )with the VolatileImage TRANSLUCENT parameter. Well, this is not sufficient, the background of VolatileImage is still filled with some WHITE-COLOR that renders opaque. So here's the way to render ALL YOUR VOLATILE IMAGES W/ FULL TRANSPARENCY AS BACKGROUND :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
/**
     * Instances a new VolatileImage from an image object.
     * @param size dimensions
     * @return VolatileImage created
     * @see java.awt.image.VolatileImage
     */

    public static VolatileImage createVolatileImage(Dimension size) {
        VolatileImage vdata = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleVolatileImage(size.width, size.height, VolatileImage.TRANSLUCENT);
        Graphics2D g = vdata.createGraphics();
        Composite cps = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 1f);
        g.setComposite(AlphaComposite.getInstance(AlphaComposite.DST_IN, 0.0f));
        g.fillRect(0,0, size.width, size.height);
        g.setComposite(cps);
        return vdata;
    }
As you can see, the VolatileImage is given the TRANSLUCENT parameter and then Graphics are realized once to fill them with the AlphaComposite DST_IN and the alpha value to a floating zero. THIS CHANGES A LOT THE RENDERING SPEED. Wink
 Roll Eyes Roll Eyes Roll Eyes

EDIT : it should be reset back to the default Composite, which must be opaque SRC_OVER.

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline broumbroum

Junior Member





« Reply #1 - Posted 2008-03-11 21:21:30 »

one snap shot of the accelerated screen. ALL SPRITES ARE VOLATILE  Shocked

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #2 - Posted 2008-03-12 09:01:25 »

I wonder why you don't simply use BufferedImages for your sprites, if they are read-only?
This is what BufferedImages have been designed for (since 1.5), e.g. I know about my old GeForce488Go which has quite a high per-primitive overhead for each rendered VI, whereas thousands of BIs are no problem at all. (I guess the pbuffer state changes are killing it)

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

Junior Member





« Reply #3 - Posted 2008-03-12 16:21:36 »

indeed BufferedImage's are the most compatible. They are also known as RenderedImage in a 2D context. But they're not as fast as VolatileImage instances because each render cycle has to fetch pixels data from a RAM allocated buffer, unlike Volatile buffer which are known to solely use the VRAM allocation. That is like looking data into the harddisk compared to fetching "living" data into the RAM memory; i.e. your Graphics Card CPU would look directly into its VRAM buffer in a Volatile context where he could find valid Image's.
Smiley
further benchmarking are made with the BufferStrategy "pBuffer" and the usual JFC double-buffering, The "full-screen exclusive" mode can create 2+ Volatile buffers that are flipped or swapped as the render cycle processes graphics contents which is much faster.

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2008-03-12 17:13:51 »

.... BufferedImage's .... are not as fast as VolatileImage instances because each render cycle has to fetch pixels data from a RAM allocated buffer ...

I thought BufferedImages were backed by a Texture+FBO and a VolatileImage was backed by a PBuffer...

I never heard of that reading from RAM into vRAM each 'render cycle'. When all your drawing-operations are accelerated, there would be no need to sync with RAM.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #5 - Posted 2008-03-12 23:16:38 »

But they're not as fast as VolatileImage instances because each render cycle has to fetch pixels data from a RAM allocated buffer, unlike Volatile buffer which are known to solely use the VRAM allocation.

Sorry but thats not true. BufferedImages are, if accalerated, copied to VRAM and when blitted to another GPU resource the vram-copy is used.

lg Clemens
Offline broumbroum

Junior Member





« Reply #6 - Posted 2008-03-13 11:34:12 »

you don't even know what you're talking about....

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2008-03-13 13:53:49 »

This is why I gave up on Java2D about... hm... seven years ago now.

Cas Smiley

Offline thijs

Junior Member




Lava games rock!


« Reply #8 - Posted 2008-03-13 15:21:09 »

Quote
you don't even know what you're talking about....

Riven and Linuxhippy are right, check the source to Sun's implementation of the BufferedImage class if you don't take us on our word :s

Edit:
Unless you're doing direct modifications to the underlying pixelbuffer, which causes the BufferedImage to get unaccelerated... which implies sysmem -> gpumem copies

<a href="http://www.dzzd.net">3DzzD!</a>
<a href="http://www.arcazoid.com">Arcazoid!</a>
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #9 - Posted 2008-03-13 18:26:59 »

Quote
you don't even know what you're talking about....
Sorry but I know what I am talking about. If you're not modyfing your VolatielImages your work is completly useless - BufferedImages provide excatly the same functionality without the risk of loosing their content.

Quote
This is why I gave up on Java2D about... hm... seven years ago now.
Because BufferedImages are accalerated Wink ?

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

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2008-03-13 19:16:00 »

Nah, coz fiddling round with all the arcane runes and intoning the riddle of the bones to get consistent working performance just irked me too much...

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2008-03-13 19:31:59 »

Nah, coz fiddling round with all the arcane runes and intoning the riddle of the bones to get consistent working performance just irked me too much...

Cas Smiley

And we're all very grateful that it made you develop LWJGL !

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
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.

atombrot (27 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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

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

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!