Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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  
  Accelerating BufferedImages  (Read 6885 times)
0 Members and 1 Guest are viewing this topic.
Offline Pyrodragoon

Junior Member




Art calculated with java...


« Posted 2008-09-04 19:31:54 »

I know that my BufferedImages are not accelerated
by using
1  
2  
3  
buffer.setAccelerationPriority(1.0f);
System.out.println(""+buffer.getCapabilities(MainGraphicsFrame.gc).isAccelerated());
System.out.println(""+buffer.getAccelerationPriority());


With the first one I can change the Priority and test it
with the third one.
With the second I know, that my BufferedImage buffer is not accelerated....
But I don´t know how to change this, the priority is worth sh... for this matter
because it doesn´t help me at all to have  400 PS in my car when there´s
no accelerator  Wink

I know you know how to do this,
please help me.
It´s really important to accelerate tile-images for a tile-based game , I guess Roll Eyes
Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #1 - Posted 2008-09-09 22:46:21 »

What I want to say is
how does it help me to change the priority of acceleration if
it isn´t even active.
So how can I tell Java to accerlerate certain Images ?
Offline fletchergames

Senior Member





« Reply #2 - Posted 2008-09-10 15:10:07 »

It depends on how you load the BufferedImages into memory.  Here's the code I use:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public static BufferedImage loadImage(final InputStream inputStream) {
   //load the file
  BufferedImage image = null;
   try {
      image = ImageIO.read(inputStream);
   } catch(Exception exception) {
      if(image == null)
         return null;
   }

   //NOTE: Use "copyImage" instead of "bufferImage" to keep alpha channel transparency
  //that is stored in the file.
  return ImageUtil.copyImage(image);
} //end loadImage


And here's the copyImage method:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public static BufferedImage copyImage(final BufferedImage image) {
   int width = image.getWidth();
   int height = image.getHeight();
   return createImage(width, height, image.getType() != BufferedImage.OPAQUE,
      image.getRGB(0, 0, width, height, null, 0, width));
} //end copyImage

public static BufferedImage createImage(final int width, final int height,
   final boolean shouldTransparencyBeAllowed)
{
   //get the GraphicsConfiguration
  GraphicsConfiguration graphicsConfiguration = GraphicsEnvironment.
      getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();

   //this enables/disables transparency and makes the Image more likely to be managed
  return graphicsConfiguration.createCompatibleImage(width, height,
      shouldTransparencyBeAllowed ? Transparency.BITMASK : Transparency.OPAQUE);
} //end createImage


I believe the main idea is that you have to use GraphicsConfiguration.createCompatibleImage to make the image actually get accelerated.  I guess the image's data has to match the screen resolution, color depth, etc.

It's sort of silly that it matters which methods you use to load the BufferedImages, but that's the way it is.  It should create "compatible" images unless told otherwise, but it only creates them when you use a method like GraphicsConfiguration.createCompatibleImage.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #3 - Posted 2008-09-10 22:06:20 »

Hi
Thanks for your help which I really appreciate Smiley
I've been thinking a lot about this matter and this
is not the first game where I thought:
Let's do it better this time  Wink
But I wonder why it still isn´t accelerated...
I used the
1  
createCompatibleImage()

method and it´s still the same, not even one accelerated BufferedImage.
It´s the same with BufferedImages created by the program.
I use 3*3 BufferedImages for the ground in my RPG´s world,
so I can easily scroll through the world.
I already don´t draw the ground every frame because of the FPS dropping.
I hoped accelerating would change this a bit.
In general I wouldn't mind not redrawing the tiles at all because once they are on
the BufferedImage I just need to put that on the screen.
But what to do if there´s animation in the groundtiles, f.e. with water ?
Is it maybe something with my Java (jre1.6.0_07), or Windows XP that
doesn´t allow this ?
Or should I use some other Image like VolatileImage?
Although I must admit that I didn't really get the advantages of it  Undecided
If you need more data, please say so.
I also checked my memory and Java says there's ~255 MB of accelerated memory available...
Offline fletchergames

Senior Member





« Reply #4 - Posted 2008-09-11 03:25:30 »

Maybe you have too many images?  It only accelerates the images that are used the most.

How big is the frame?  You have to take into account that the entire screen has to be stored on the graphics card.  If your frame is some huge high-resolution thing, it might take up alot of MB on its own.

Are you using BufferStrategy for rendering?  If you're doing something weird for drawing to the screen, it might screw everything up.

Honestly, I don't know what the problem is, but I'm surprised you haven't gotten a ton of responses.  This is a common problem.

Have the results of the following code changed?

1  
2  
System.out.println(""+buffer.getCapabilities(MainGraphicsFrame.gc).isAccelerated());
System.out.println(""+buffer.getAccelerationPriority());


It has nothing to do with Windows XP, and image acceleration has worked since java 5 (or maybe even java 4).  Still, upgrading to the newest JRE can't hurt.

Using VolatileImage shouldn't solve your problem.  BufferedImages usually get accelerated just fine.  If you use VolatileImage, you'll basically be rewriting the code that manages BufferedImages.
Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #5 - Posted 2008-09-11 10:00:40 »

I just have 9 images to be accelerated
with the same size as the screensize which is 1280*1024.
But I think there has to be enough memory available.
I start the game with a .bat-file containing the entry:
1  
-mx1024M

And 1,5 GB RAM and a 8600 GTS should do the job.
I already used the Fullscreen-mode with BufferStrategy as you mentioned
which in fact gives me more FPS.
But this has nothing to do with my BufferedImages because they are, as said above,
offscreen-buffer.
I use them to draw tiles onto and put the buffer on the screen using BufferStrategy
as suggested in the Sun tutorial.
 
The results of the code didn´t change.
1  
2  
System.out.println(""+buffer.getCapabilities(MainGraphicsFrame.gc).isAccelerated());
System.out.println(""+buffer.getAccelerationPriority());


It still has no acceleration.
If you´d say these images are to much for my memory I must say
that I print the capabilities for everey single image and it´s always the same:
false and 0.5
At least the first one should have enough memory to use.

If this is a common problem then why can´t Sun solve this ?  Undecided
Maybe when Java 1.7 is released...
Offline gimbal

JGO Knight


Medals: 25



« Reply #6 - Posted 2008-09-11 10:44:43 »

I am not sure, but isn't it true that Java 2D learns what to accelerate and what not? So if you check at the very beginning of the runtime of your app, it could well be that everything is still unaccelerated, but while your game is running and the images are being drawn, in the background they are being optimized by keeping them in videomemory?
Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #7 - Posted 2008-09-11 11:30:05 »

Hi  Shocked
you are permitted to be sure  Wink
I just tried again in my render-loop and
it turns out now all buffer are accelerated after some time.
But still after initializing them they aren´t accelerated at all.
When having done some rendering it happens,
what a surprise.
I guess another Java mystery has been solved  Grin
Thanks for that
and welcome to JGO (as it was your first post here).
Offline zammbi

JGO Coder


Medals: 4



« Reply #8 - Posted 2008-09-11 11:37:45 »

There is a flag to make them accelerated on first use, but can't remember it atm...

Current project - Rename and Sort
Offline CommanderKeith
« Reply #9 - Posted 2008-09-11 11:58:37 »


Using VolatileImage shouldn't solve your problem.  BufferedImages usually get accelerated just fine.  If you use VolatileImage, you'll basically be rewriting the code that manages BufferedImages.

I thought this was the case too, but just recently I found that it's not the case in java 6 update n, see this thread:

http://forums.java.net/jive/thread.jspa?threadID=39749&tstart=0

From the java2D man himself, Dmitri T:

Quote
I would suggest to reduce the number of operations you do
to BufferedImages. If you use some temp. buffered images
for rendering, consider changing them to translucent
volatile images (assuming you don't need access to pixels).
This will not affect performance when these are not
accelerated but will help when they are.

I'm not sure why BufferedImages can't just be wrappers for VolatileImages and do all the checking automagically, I though that was how it worked in older java versions, oh well...

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

JGO Knight


Medals: 25



« Reply #10 - Posted 2008-09-11 13:07:22 »

Hi  Shocked
you are permitted to be sure  Wink
I just tried again in my render-loop and
it turns out now all buffer are accelerated after some time.
But still after initializing them they aren´t accelerated at all.
When having done some rendering it happens,
what a surprise.
I guess another Java mystery has been solved  Grin
Thanks for that
and welcome to JGO (as it was your first post here).


Thanks. I've been reading the forum for a while now, but I usually hang around in the forums at java.sun.com Wink More hostile environment than it needs to be, but it makes me laugh.


Just to note, I find this wiki page to be very helpful in my own research into these matters:

http://gpwiki.org/index.php/Java:Tutorials:VolatileImage


It seems, especially with the excellent forum post that CommanderKeith linked to, that game developers should always use VolatileImage just in case hardware acceleration is available. But I must say it is a murky subject to understand properly.
Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #11 - Posted 2008-09-11 16:16:25 »

Thanks again,
that are both really helpful links.
I've been into this topic of Volatile Images for some time
but it has always bothered me that they so easily
lose there content.
Then again that goes for the BufferStrategy, too,
which I'm using already, so
maybe after reading that new tutorial in full
I will also use them for my issues.
Offline CommanderKeith
« Reply #12 - Posted 2008-09-12 08:23:30 »

Wow, I just switched from BufferedImages to VolatileImages and got a speed up from 30 fps to 70!

Yee-hah!

PS: for Pyrodragoon, try this VM option to get output on what java2D is doing:

 -Dsun.java2d.trace=,count

The more of these: calls to sun.java2d.loops.****, the worse, the more of these: calls to sun.java2d.d3d.**** the better.

Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #13 - Posted 2008-09-12 12:21:23 »

I changed my backbuffer also to VolatileImage
but the effect was really bad:
The FPS dropped a bit and for the worst part
when scrolling through the map and redrawing one of the buffers
it needs two seconds to do it.

With
1  
-Dsun.java2d.trace=,count

I got the following:

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  
27317 calls to D3DDrawLine
20 calls to sun.java2d.loops.Blit::Blit(ThreeByteBgr, SrcNoEa, IntArgb)
46 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
36 calls to sun.java2d.d3d.DelegateSwToTextureLoop::Blit(Any, SrcNoEa, "Direct3D
 Texture"
)
4896 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, A
nyInt)
276 calls to D3DDrawGlyphs
48 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, "D3D render
target"
)
47 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntArg
bBm)
20 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(ThreeByteBgr, SrcNoEa, I
ntArgbBm)
67 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbBm)
4916 calls to sun.java2d.loops.Blit::Blit(IntArgbBm, SrcOverNoEa, IntRgb)
15 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbBm, SrcNoEa, IntA
rgbPre)
47 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb)
561 calls to D3DFillRect
4896 calls to sun.java2d.loops.DrawPolygons::DrawPolygons(AnyColor, SrcNoEa, Any
Int)
15 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(IntArgbBm, SrcNoEa, IntA
rgbPre)
15 calls to sun.java2d.loops.Blit::Blit(IntArgbBm, SrcNoEa, IntArgb)
2537 calls to sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit("Direct3D Texture", A
nyAlpha, "D3D render target")
15 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbPre)
20 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(ThreeByteBgr, SrcNoEa, I
ntArgbBm)
47 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntArg
bBm)
45857 total calls to 21 different primitives



27317 calls to D3DDrawLine seems good
but what about
4916 calls to sun.java2d.loops.Blit:
and
4896 calls to sun.java2d.loops.DrawPolygons:
? Is there a way around ?
Offline gimbal

JGO Knight


Medals: 25



« Reply #14 - Posted 2008-09-12 15:53:04 »

Wow, I just switched from BufferedImages to VolatileImages and got a speed up from 30 fps to 70!

an increase of 40fps??? That seems a bit excessive :s Are you sure your BufferedImage objects were accelerated? Did you turn transparent images into BITMASK transparency in stead of TRANSLUCENT?

I get 60FPS no problem without VolatileImages (but with BufferedStrategy) and I do a lot of drawing per frame.
Offline CommanderKeith
« Reply #15 - Posted 2008-09-12 17:15:12 »

No they were TRANSLUCENT... so is that why they weren't accelerated?!

They really need to be translucent though - otherwise anti-aliased lines on a transparent-background sprite don't come out anti-aliased when the sprite is painted on another image.

Offline CommanderKeith
« Reply #16 - Posted 2008-09-12 17:17:44 »


27317 calls to D3DDrawLine seems good
but what about
4916 calls to sun.java2d.loops.Blit:
and
4896 calls to sun.java2d.loops.DrawPolygons:
? Is there a way around ?


I'm no expert, but blitting is when an image is painted to the screen, and by the looks of it that's done in software on your VM, rather than d3d. Are you running java 6 update N?

Offline Pyrodragoon

Junior Member




Art calculated with java...


« Reply #17 - Posted 2008-09-12 18:00:27 »

For N=7, yes.
As written above I have jre1.6.0_07 working on my Pc.
I think the images painted to the screen are
my tiles and that´s a lot:
3*3 buffers with size 1280*1024 and a tilesize of 128*64
makes 1440 images at first.
When scrolling to a side there is also drawing of 480 images to do.
Tell me if I'm wrong here, but that has to be normal for every tilebased RPG.
Or not ?
Is there any way to do this with 3D, too ?
Of course I would prefer that if it is faster.
Offline gimbal

JGO Knight


Medals: 25



« Reply #18 - Posted 2008-09-12 18:53:47 »

Quote
No they were TRANSLUCENT... so is that why they weren't accelerated?!

Seems like TRANSLUCENT BufferedImages are drawn through the software pipeline only, which is godawfully slow. When you switched to the VolatileImage however, they are now drawn through the D3D pipeline, which is a whole lot faster. That certainly explains the dramatic increase.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #19 - Posted 2008-09-12 20:08:51 »

If you want more reliable acceleration you should be using jre1.6.0_10.

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

Junior Member




Art calculated with java...


« Reply #20 - Posted 2008-09-12 22:02:05 »

jre_1.6.0_10, is it official ?
I read that in another topic but it was just a beta ?!

Seems like TRANSLUCENT BufferedImages are drawn through the software pipeline only, which is godawfully slow. When you switched to the VolatileImage however, they are now drawn through the D3D pipeline, which is a whole lot faster. That certainly explains the dramatic increase.
When I use VolatileImages for my tiles, which have as all isometric tiles have,
four transparent parts, will it also be drawn trough 3D?
I think this would help a lot,
I´ll do so tommorow...oh wait, it's already today  Wink
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.

CopyableCougar4 (19 views)
2014-08-22 19:31:30

atombrot (30 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 (24 views)
2014-08-16 06:12:11

Rayexar (63 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 (38 views)
2014-08-06 19:49:38
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!