Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (744)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (825)
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  
  CreateCompatibleImage using different bit depths  (Read 1650 times)
0 Members and 1 Guest are viewing this topic.
Offline immudium

Junior Devvie




Gorram it!


« Posted 2003-10-30 17:48:42 »

I've noticed that on older video cards I can a achieve a significant increase in frame rate in window mode if I set the desktop from 32 bits to 16 bits, for example.  However, I'm wondering if it's possible to achieve the same "effect" by enumerating through the GraphicsConfiguration array return by GraphicsDevice.getConfigurations() and then selecting the gc that corresponds to the desired bit depth.  The idea is to allow the user the select a "performance" or "quality" mode based upon the speed of their hardware.

However, all of the GraphicsConfigurations returned seem to contain no distinguishing information, but if I watch them in the debugger, I can see that each GC is in fact a sun.awt.Win32GraphicsConfig and that each one contains a variable call "pixel_fmt" that seems to contain the desired bit depth information I'm looking for.  However, since this class is not exposed, this is obviously the wrong way to obtain the information.  Calling gc.getColorModel().getColorSpace() returns 24 for each one.

So anyway, is there a way to get the supported bit depth for a particular GraphicsConfiguration through the abstraction?  Or is my understanding of the purpose of the GraphicsConfiguration wrong?  Is there a better way to obtain an accelerated image for n bits of color without forcing the user to change their desktop color space than what I'm trying to do?  Or is this not even a possibility technically?

Thanks for any help.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #1 - Posted 2003-10-30 21:24:18 »

The info you want is in the DisplayMode class...
Maybe gc.getDevice().getDisplayMode().getBitDepth() ?


Offline immudium

Junior Devvie




Gorram it!


« Reply #2 - Posted 2003-11-02 19:43:05 »

Thanks for the info.  It seems like it should work, but it only returns 32 for every gc.  I can't seem to crack this nut.  However, the more I've thought about it the more I wonder if it's worth the effort.  If the desktop is in 32 bit mode, I wonder if there is actually any performance improvement in drawing images using 16 bits other than the reduced memory requirement.  And even then I wonder if the desktop/video card/whatever would just convert the 16 bit into a 32 bit image before displaying it anyway.  My main intention was to experiment, but it doesn't appear as this is even a possibility currently.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-11-03 23:35:15 »

For best performance convert your sprites to match the bit depth of the display when you load them.  Otherwise there could be some slow on the fly conversions happening in your game loop.  (This seems to be a particular nuisance on the Mac which really likes to have the image format of sprites match the display.)

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #4 - Posted 2003-11-10 04:56:44 »

GraphicsConfiguration objects correspond to pixel formats.  
On windows the depth will always be the same as the desktop depth. On other platforms (i.e. Solaris sparc) there are video boards which can handle windows with different depths, so there you can have GraphicsConfigurations with different depths (GC objects correspond to X11 visuals on unix).

As for converting sprites to the format of the screen: it's not necessary, because they'll be cached in vram, so the conversion happens only once when they're copied from system memory to vram, after than it's vram->vram copy (well, at least, in our implementation)..


Offline immudium

Junior Devvie




Gorram it!


« Reply #5 - Posted 2003-11-10 15:58:53 »

Excellent, thanks for the clarification.  So GraphicsConfigurations do enumerate pixel formats as I thought they should, it's just that Windows doesn't really allow mixing different bit depths hence all the GCs returning 32 bits.  That also answered a number of other questions I had about the GC.  I always felt uneasy about simply calling getDefaultConfiguration to select the GC wondering if I was missing out on or not taking advantage of a more appropriate GC for what I wanted to do.  Now I know, at least on Windows, that they're all pretty much the same.
Pages: [1]
  ignore  |  Print  
 
 

 
Ecumene (149 views)
2017-09-30 02:57:34

theagentd (214 views)
2017-09-26 18:23:31

cybrmynd (301 views)
2017-08-02 12:28:51

cybrmynd (288 views)
2017-08-02 12:19:43

cybrmynd (297 views)
2017-08-02 12:18:09

Sralse (291 views)
2017-07-25 17:13:48

Archive (968 views)
2017-04-27 17:45:51

buddyBro (1094 views)
2017-04-05 03:38:00

CopyableCougar4 (1670 views)
2017-03-24 15:39:42

theagentd (1430 views)
2017-03-24 15:32:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
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!