Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (602)
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  
  question about an active rendering implementation  (Read 1547 times)
0 Members and 1 Guest are viewing this topic.
Offline skinny boy

Junior Devvie





« Posted 2009-09-16 19:14:28 »

i was reading this ( http://www.gamedev.net/reference/programming/features/javarender/default.asp )

the code uses the graphics context of a BufferedImage, which is as big as the screen,
he draws on it,
and then uses the BufferStrategyClass.getDrawGraphics to acquire the graphics context of the buffer that the BufferStrategy uses

then the code draws the BufferedImage on the buffer

why not draw on the BufferStrategy buffer from the very beginning?

content lost issues??? (which might happen in case the rendering or gameLogic takes a lot of time)
Offline Karmington

Senior Devvie


Medals: 1
Projects: 1


Co-op Freak


« Reply #1 - Posted 2009-09-17 17:02:09 »

double buffering is based on drawing 'behind the scenes', and then flipping the complete image in one fell swoop to avoid flicker
unless i'm missing some nuance of the BufferStrategy itself?

Online Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #2 - Posted 2009-09-17 17:39:31 »

If you do what that tutorial is suggesting(draw onto a BufferedImage), you will never get hardware accelerated drawing.

Ignore that aspect of the tutorial, and draw direct to the Graphics context obtained from the BufferStrategy.

Seems like the author has mistakenly mixed the pre-BufferStrategy paradigm(Java 1.2-1.3), of using a BufferedImage as a back buffer, with the post-BufferStrategy paradigm (1.4+)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline skinny boy

Junior Devvie





« Reply #3 - Posted 2009-09-17 18:13:56 »

If you do what that tutorial is suggesting(draw onto a BufferedImage), you will never get hardware accelerated drawing.

Ignore that aspect of the tutorial, and draw direct to the Graphics context obtained from the BufferStrategy.

Seems like the author has mistakenly mixed the pre-BufferStrategy paradigm(Java 1.2-1.3), of using a BufferedImage as a back buffer, with the post-BufferStrategy paradigm (1.4+)

thats what i thought (about not having hardware accelaration)
though i am not so sure.... its the same as drawing my stuff to the graphics content of the BufferStrategy either straight up, or through an image
both manipulate the graphics context of the BufferStrategy, and i am not so sure that the drawing on a BufferedImage takes longer that drawing on the graphics context of the BufferStrategy

the BufferedStraegy uses VolatileImages (not so sure, have to recheck) for bufferes, so when you acquire the graphics context of a buffer which is currently not showing, i believe there is a chance that the speed of drawing on it is the same with the speed of drawing on a BufferedImage

the only difference (i think) is that if i use the BufferedImage, it needs one more step,,,,
which is useless (unless someone can find a reason why not)

any agrees/disagrees??
Offline ManaSink

Senior Newbie





« Reply #4 - Posted 2009-09-17 20:02:59 »

I used to do the two step process in the past because the graphics pipeline in 1.4 and 1.5 didn't support alpha blending for hardware accelerated images unless you added a command line parameter.   Hardware acceleration worked fine for opaque images, or bitmask (0% or 100% only) transparency, but translucent blends (50% like stained glass, shadows, fog, etc) had to be done on the heap, and the result blitted opaque as a second step.  I think the new VMs have accelerated alpha blending by default, so this may be a thing of the past.

BufferedImage WILL try to accelerate content, but any time you alter it's contents it gets flagged as dirty.  If you write to the image every frame, or access the backing pixel array, it will always be dirty, and always get copied from system memory to video memory (LAME).  If you avoid changing the image it will cache an  accelerated version in video memory.  I use this to avoid doing the really expensive stuff like scaling and rotating every frame.

If you are using the flip strategy on your BufferStrategy, it will block for the monitor vsync when you show it.  This will cap your framerate to the monitor hertz, typically 60 fps, and a small overrun on every frame would cut that in half waiting for the next vsync.  This does prevents tearing though, which pisses me off worse than a slower frame rate, but can surprise you if you don't expect it.

Hope that helps.   Grin
Offline skinny boy

Junior Devvie





« Reply #5 - Posted 2009-09-18 22:23:26 »

no it didnt,, but while i was reading it (again and again in order to grasp it) i was also thinking about what i had posted...
and this is what i have thought

if BufferStrategy uses VolatileImages for buffers, (in http://209.85.229.132/search?q=cache:4XHeW8Aaji4J:java.sun.com/j2se/1.5.0/docs/api/java/awt/image/BufferStrategy.html+bufferstrategy+uses+volatile+image+for+buffer&cd=1&hl=en&ct=clnkit says "Since the buffers in a buffer strategy are usually type VolatileImage.." )
then the graphics content you acquire through the getDrawGraphics method is probably working directly to the VRAM, as a VolatileImage inhabits the VRAM and not system RAM....

am i correct?
Online Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #6 - Posted 2009-09-18 23:48:08 »

no it didnt,, but while i was reading it (again and again in order to grasp it) i was also thinking about what i had posted...
and this is what i have thought

if BufferStrategy uses VolatileImages for buffers, (in http://209.85.229.132/search?q=cache:4XHeW8Aaji4J:java.sun.com/j2se/1.5.0/docs/api/java/awt/image/BufferStrategy.html+bufferstrategy+uses+volatile+image+for+buffer&cd=1&hl=en&ct=clnkit says "Since the buffers in a buffer strategy are usually type VolatileImage.." )
then the graphics content you acquire through the getDrawGraphics method is probably working directly to the VRAM, as a VolatileImage inhabits the VRAM and not system RAM....

am i correct?

Yes. Thereby allowing the draw operations to be hardware accelerated.

BufferedImages on the other hand keep their primary surface in system RAM.

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

Junior Devvie





« Reply #7 - Posted 2009-09-19 16:08:02 »

thank you for confirming my opinion
Offline ManaSink

Senior Newbie





« Reply #8 - Posted 2009-09-21 19:54:17 »


Sorry dude, didn't mean for my reply to be so hard to follow.   Sad

As Abuse pointed out, rendering directly using the BufferStrategy will hardware accelerate the operations on a modern VM.
For Windows, a modern VM is 1.6u10+
http://java.sun.com/javase/6/webnotes/6u10.html

BufferedImages are "managed" by default.  "Managed" images are cached in VRAM when they are drawn.  If the image is later altered, the cached copy is discarded.  Since the example code alters the image every frame, a cached VRAM copy is never used.
http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html

This snippet draws a blue box in a random location each frame, and is NOT accelerated:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
BufferedImage img = gc.createCompatibleImage( 640, 480 );  //whole screen buffer
while (true){
    Graphics gfx = img.getGraphics();
    gfx.setColor(Color.BLACK);
    gfx.fill(640,480);  //oops, image content altered..., VRAM cache discarded if present.
    int x = rand.nextInt(256);
    int y = rand.nextInt(256);
    gfx.setColor(Color.BLUE);
    gfx.fillRect(x,y,50,50);  //draw blue box in random location on large image
    gfx.dispose();
    Graphics bufGfx = bufferStrategy.getDrawGraphics();
    bufGfx.drawImage(img,0,0,null);  //draw large image, always modified since last draw, must copy from system RAM to VRAM
    bufGfx.dispose();
    bufferStrategy.show();
    // sleep, yield, etc...
}


This snippet does the same, but uses BufferStrategy acceleration and BufferedImage caching:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
BufferedImage img = gc.createCompatibleImage( 50,50 );  //small image of a blue box, so only 50x50.
Graphics gfx = img.getGraphics();
gfx.setColor(Color.BLUE);
gfx.fillRect(0,0,50,50);  //image is rendered only once.
gfx.dispose();
while (true){
    Graphics bufGfx = bufferStrategy.getDrawGraphics();
    bufGfx.setColor(Color.BLACK);
    bufGfx.fill(640,480);  // direct call on buffer, accelerated by DirectX or OpenGL
    int x = rand.nextInt(256);
    int y = rand.nextInt(256);
    bufGfx.drawImage(img,x,y,null);  //draw small image at random location.  image not modified, so quick copy from VRAM is possible
    bufGfx.dispose();
    bufferStrategy.show();
    // sleep, yield, etc...
}


Admittedly, for just drawing a blue box, there isn't much value in caching the image.  I was just trying to show how to properly use a BufferedImage to take advantage of hardware acceleration.

manasink
Offline skinny boy

Junior Devvie





« Reply #9 - Posted 2009-09-22 12:09:23 »

i get it now, thank you for reposting
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.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26: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
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!