Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 6
1  Java Game APIs & Engines / JOGL Development / Re: Java2D/JOGL Interoperability Demo on: 2008-04-16 00:08:54
The problems I'm having, at least on some of these machines, are multi-monitor related.  Everything works fine on one monitor, and I can see from the debug console that the OpenGL pipeline is enabled for only one screen.  I'm also seeing a nice performance increase!  Is there a way to enable hardware acceleration on two (or more) monitors?

Hi Paul,

Unfortunately, on Windows, the OpenGL-based Java 2D pipeline is currently only configured to work properly on the primary screen (i.e., we enable it for the primary screen, but fallback on the GDI-based pipeline for other screens).  This is more an artifact from a few years ago when the OGL pipeline was first developed and drivers were less robust in multi-monitor scenarios.  With some more labor and testing we could probably remove this restriction, maybe in a future update release.

2  Java Game APIs & Engines / Java 2D / Re: Project Scene Graph started on: 2007-12-13 04:15:21

I don't like the timing framework (referring to properties using strings/reflection is such a hack), but having a scene graph for Java2D is very cool.

Although most developers will probably just end up using BeanProperty (and the convenience methods that use it under the hood) for the purposes of animating beans, we purposely provided the Property interface as an abstraction, and BeanProperty is just a minimal implementation thereof.  In other words, if you have your own preferred way of modifying properties, you can roll your own Property impl and still make use of the rest of the animation package.  No need to throw the baby out with the bathwater.

BTW, I imagine there's some overlap between Scenario and PulpCore (at least in the sense that both provide an optimized scene graph and an animation package).  Think there's any chance of porting parts of PulpCore to use Scenario?  Smiley  The current scene graph implementation isn't tuned for games, but it might be an interesting exercise to see where it's lacking in that regard, and maybe to tune for that case.

3  Java Game APIs & Engines / JOGL Development / Re: Blog: Easy 2D/3D Mixing in Swing on: 2007-10-11 20:53:12
All: I'm ashamed that it took me over six months to update the (one line of) source code to account for the change from sync() to markDirty() in the BezierAnim3D demo. Mea culpa. I've updated the source code and webstart binaries linked in the blog entry accordingly.  I'll hopefully post a more interesting demo in the near future...

Thanks, Chris.
4  Java Game APIs & Engines / JOGL Development / Re: OpenGL pipeline on a linux platform bombs out when enabled. on: 2007-09-14 18:01:51
Do you have any idea when this will be fixed?

Both ATI and Nvidia's OpenGL drivers have been in a state of flux lately, and there have been driver regressions in (at least) the FBO codepath that affect the OpenGL-based Java2D pipeline and the Java2D/JOGL bridge.  Those companies run an automated testsuite provided by Sun that exercises these codepaths, but unfortunately it still seems that regression bugs have crept through.  We're continuing to work with those driver teams to address these issues, but we don't know yet when those fixes will appear in production.

If running via the command line, you can try passing -Dsun.java2d.opengl.fbobject=false in addition to the usual -Dsun.java2d.opengl=True and see if that helps.

Also, could you post the driver versions with which you've had trouble?

5  Java Game APIs & Engines / JOGL Development / Re: feature suggestions: utility class for shaders on: 2007-08-13 03:23:24
i think JOGL's minimum-scene-graph project has also glsl utilities...

Indeed, see:

We decided to check it in as part of the MSG sources for now, but the Shader class is self contained (no dependencies other than JOGL), so feel free to take it and use it in your projects.  I was going to write a blog about it months ago, but that hasn't happened yet, unfortunately.

6  Java Game APIs & Engines / Java 2D / Re: Additive blitting? on: 2007-06-20 16:40:58
Well, there is no additive blending in Java 2D.

Not yet anyway... It's planned for JDK 7 though in a new class called PhotoComposite, which will offer other PhotoShop-style blending modes as well.  See this RFE:

7  Java Game APIs & Engines / JOGL Development / Re: java2d-pipeline / glReadPixels / alpha-component on: 2007-06-19 21:09:37
Here's the deal.  Swing's backbuffer is always opaque.  There is currently no way to specify that you'd like Swing to allocate an alpha channel with its backbuffer.  When you have the OpenGL-based Java 2D pipeline enabled, and you're using GLJPanel, Swing's backbuffer is allocated as a pbuffer or FBO without an alpha channel.  It is therefore expected that you will see all opaque alpha values if you read back directly from the Swing backbuffer using glReadPixels().

When the OpenGL-based Java 2D pipeline is not enabled, and you're using GLJPanel, JOGL will allocate a pbuffer that does contain an alpha channel, which is necessary for properly compositing the contents of that offscreen pbuffer onto the actual Swing backbuffer.  So in that case, you're using glReadPixels() to read back from that alpha channel enabled pbuffer, and therefore some of the pixels may appear to be transparent.

8  Java Game APIs & Engines / JOGL Development / Re: Argh, having trouble with transparency in with Overlay's Graphics2D on: 2007-05-24 20:10:21
I'm having trouble following your code as a whole, but I think your problem is probably in the way that you clear the Overlay.  You can't just do:
in the default SrcOver mode, because that would have the effect of blending completely transparent pixels over what's already in the Overlay.

Instead, you'd have to do:

But there's a better way to do this without creating/using that special transparent Color.  Simply use:

That's the easiest and fastest way to clear a translucent surface.

9  Java Game APIs & Engines / Java 2D / Re: Quality of AffineTransform.rotate on: 2007-02-25 09:21:31
I am using JDK 6 build 105 and only use "-Dsun.java2d.opengl=true" as VM arguments.

Okay.  This could be a bug in the OGL pipeline then.  Which video board are you using, and which driver version?  What kind of source image are you transforming (i.e. is it a BufferedImage or a VolatileImage)?

I assume that you don't see this bug if you don't pass -Dsun.java2d.opengl=true on the command line?

And I don't quite get what is so weird about my samples? As far as I see everything works just fine...

Huh?  The whole point of this thread is that rotation is producing blocky (buggy) images; isn't that why you started the thread in the first place?  Your second screenshot is clearly showing a bug; it's not what NEAREST_NEIGHBOR is supposed to look like.  That's what's weird.

10  Java Game APIs & Engines / Java 2D / Re: Quality of AffineTransform.rotate on: 2007-02-24 03:12:41
Yes ok, but with the KeyInterpolation set to Bileanar it works just fine Smiley

This is weird.  Which JDK release are you running on?  Which OS?  Are you passing any system properties such as -Dsun.java2d.d3d=true or -Dsun.java2d.noddraw=true?

If you're not using JDK 6, please try that release and see if you get different behavior.  (We reimplemented our transform loops in JDK 6 so that they're faster and more direct.)

11  Java Game APIs & Engines / Java 2D / Re: Quality of AffineTransform.rotate on: 2007-02-23 01:42:21
I want to draw a BufferedImage in an animation und rotate the original image each frame around an
increasing angle. Although I turned on Graphics2D-Antialias, I always end up with something like that -.-

Could you please post your source image (unrotated) and then take a screenshot of what it looks like rotated?  Also post the relevant source code.  It's hard to see what you're doing from just this one image.

12  Game Development / Performance Tuning / Re: Alpha Composite on: 2007-02-20 18:47:15
That made no decernable difference. It was suposed to ues directdraw 3D to accelerate the drawing of transparency right?

You haven't mentioned which JDK release you're using, or which graphics board, or which graphics driver version... All of these are required bits of information.

In JDK 6, you can use -Dsun.java2d.opengl=True or -Dsun.java2d.d3d=True (note the uppercase 'T'), which will print to the console whether or not the pipeline can be enabled.  For more startup details, set J2D_TRACE_LEVEL=4 (that's an environment variable) before running your application.

Either pipeline can accelerate the case you mention in hardware.  If you're not seeing a difference, then there's something about your configuration causing the problem.

13  Java Game APIs & Engines / Java 2D / Re: current state of 2D acceleration on: 2007-02-19 17:37:51
By the way drawing directly to screen destroys the opengl-backend's capability of Single-threaded-rendering.


This is not true.  Are you just making things up as you go along?  Smiley

So for comparison better draw to a VolatileImage and draw this one after the test has been finished.

This one I can agree with.  It's pretty rare that anyone renders directly to the screen these days, so better to do your benchmarking to an accelerated offscreen, like BufferStrategy or VolatileImage.  But then you always have to remember to call Toolkit.sync() at the end of your rendering loop, to ensure pixels are completely flushed to the destination.  These things are taken care of already for you if you use our standard microbenchmarking utility, J2DBench:

14  Java Game APIs & Engines / Java 2D / Re: current state of 2D acceleration on: 2007-02-18 20:47:21
The users were all using Java 6, and one had a top of the line ATI card (X1900), but then again, bad drivers can foul anything up. Still, LWJGL remains the safest option.

Did you file a bug report at  (Screenshots, exact driver version, etc would help.)  We can't fix problems that we don't know about.  You're correct that in most cases it's the drivers fault, but we can work with ATI/Nvidia/etc to correct the problem.

15  Java Game APIs & Engines / JOGL Development / Re: Blog: Easy 2D/3D Mixing in Swing on: 2007-01-23 20:55:06
I just posted another blog entry that covers things from the other perspective -- using Java 2D elements (text, animated rendering, etc) from within a JOGL application:

Source code and webstarted demo included.

16  Java Game APIs & Engines / JOGL Development / Re: OpenGL integration in Java SE6? on: 2006-12-13 21:17:43
still don't get it how JOGL fits into this update? is it included with Java6 or it just integrates better or something?

No, JOGL is not included with Java SE 6.  Read the blogs linked above for more on how JOGL is able to communicate more closely with Java 2D in the Java SE 6 release.

17  Java Game APIs & Engines / JOGL Development / Re: OpenGL integration in Java SE6? on: 2006-12-13 17:46:40
James Gosling is refering to the possibility to integrate jogl and java2d. One of the java2d implementations (not the default one) in jse6 is based on opengl. It has been designed so that you can take the opengl rendering context of a component and render on it using both java2d and jogl. In other words you can easily combine 2d and 3d rendering in a single component without having to render to intermediate images. See the Java2D/JOGL Interoperability thread for more detailed info.

For more details, I have two blogs that talk about the Java2D/JOGL interoperability stuff in Java SE 6:

And for more on the OpenGL-based Java2D pipeline improvements in Java SE 6:

18  Java Game APIs & Engines / Java 2D / Re: Fullscreen and Linux once again... on: 2006-12-05 16:44:27
Well if you window-manager is doing the wrong thing if the window is resizeable ... theres not a lot that can be done.
Either you can work arround (as you did) or better the window manager should been fixed...

Let's wait till the bug report is filed before we jump to any conclusions.  I'll need to do some testing on FC6 and see if the WM is behaving differently than other releases; it may just be that we'd want to workaround this case on the JDK side.

19  Java Game APIs & Engines / Java 2D / Re: Does the java2d-code already have an tesselator? on: 2006-12-04 06:42:23
I wonder wether some platform alread has an tesselator

Our non-antialiasing rasterizer (see the new ProcessPath and FillPath code in JDK 6, also the platform specific hooks in the OGL and X11 pipeline code) produces scanlines, which are basically 1-pixel tall quads that can be easily consumed by all of our low-level pipelines, esp. the software pipeline.  This approach is good for quality, but for larger shapes, it's a bit of a drag to send down lots of scanlines to OGL, for example.  We've considered (but not done much work) on alternate rasterizers (essentially tesselators) which would produce triangles (good for OGL and D3D) or perhaps even trapezoids (for XRender).  There are lots of triangle-generating implementations out there you can learn from.  It would be a fun project if you're feeling ambitious.

20  Java Game APIs & Engines / Java 2D / Re: Fullscreen and Linux once again... on: 2006-11-28 19:47:33
Sigh.  Fullscreen in JDK 6 was working great on all the Linux distros we tried.  The whole point of the _NET_WM_FULLSCREEN hint is to allow the WM to determine how/when to place a fullscreen window over the taskbar, so if the WM isn't honoring that hint, there's not much we can do.  There may have been some change in FC6 that causes the problem you're seeing.  Please file a bug report at, and include your fullscreen testcase as well as any other details that might be helpful.

21  Java Game APIs & Engines / Java 2D / Re: transparent png and Graphics.drawImage method on: 2006-11-16 19:16:09
But finding a good list of all available Java2D commandline arguments is a nightmare. I dont have a such list.

Umm, you mean like this one?

22  Java Game APIs & Engines / Java 2D / Re: Writing .jpg files on: 2006-11-13 06:10:53
Please read the evaluation of this bug report:

In short, it's a limitation in other native apps, not in Java.

23  Java Game APIs & Engines / Java 2D / Re: Graphics2D.drawPolygon bug ? on: 2006-11-13 06:07:11
... Well, i found the guilty thing ===> the openGL is responsible of these bugs.

Seems i need to leave that buggy thing alone now (what a shame it speeds up consequently my game).


Are you using JDK 6?  There were a number of bug fixes to improve exact rasterization with the OGL pipeline in that release, not to mention all the other improvements we've been harping on for the last year or so.

If not, which video card are you using?

24  Java Game APIs & Engines / Java 2D / Re: RenderingHints ignored by affineTransform on: 2006-11-07 23:03:21
These produces always bad loocking results. We are scalling the image down, original has a size of 2272 x 1704.

Well, it's somewhat subjective, but that's the result you get with the BICUBIC algorithm when downscaling (you can also try BILINEAR).  Note that neither is a silver bullet, especially when downscaling; often it helps to do filtered downscaling in a step-by-step fashion, which will produce results very similar to what AREA_AVERAGING used to provide.  For more on these techniques, I'd recommend reading this blog entry from Romain Guy, specifically the code about 5 slides from the end of the presentation:

The code looks something like this:
int width = image.getWidth(); 
float ratio = (float) width / (float) image.getHeight();
BufferedImage thumb = image;
do {
    width /= 2;
    // ...
    BufferedImage temp = new BufferedImage(width,
                                           (int) (width / ratio),
    Graphics2D g2 = temp.createGraphics();
    g2.drawImage(thumb, 0, 0, temp.getWidth(), temp.getHeight(), null);
    thumb = temp;
} while (width != thumbWidth);

25  Java Game APIs & Engines / Java 2D / Re: RenderingHints ignored by affineTransform on: 2006-11-07 06:50:43
Thanks for the tip, that seems to work! Thanks

But question remains, why doesn't the java2d thinks work? How can I scale down an image with java2d??? (in a good quality!)

I tried the AffineTransformOP stuff too.

Please, please, please, pretty please don't use Image.getScaledInstance().  It is much slower than using the scaling variant of Graphics.drawImage(), and it has other drawbacks.  See this FAQ entry:

As for your original question... Which JDK version are you using?  The BICUBIC hint was unimplemented in 1.4.2 and earlier, I believe.  BILINEAR should work for all releases though.  BICUBIC was implemented in JDK 5, and all scaling (NN, BILINEAR, BICUBIC) is much much faster in JDK 6.

Note that it's not necessary to call g.scale().  Instead, it's usually more straightforward to use the scaling variant of g.drawImage() as outlined in the FAQ item above.  For example:
    int newW = 100, newH = 100;
    BufferedImage img = new BufferedImage(newW, newH, ...);
    Graphics2D g = img.createGraphics();
    g.drawImage(origImg, 0, 0, newW, newH, null);

26  Java Game APIs & Engines / JOGL Development / Blog: Easy 2D/3D Mixing in Swing on: 2006-10-16 06:35:13
Since it may be relevant to folks on this forum (especially newcomers), I just wanted to mention a blog entry I wrote last week about mixing Java2D, JOGL, and Swing:

Source code and webstarted demo included.  Covers things like a simplified version of GLJPanel, using Chet's timingframework in a 2D/3D/Swing environment, the TextureIO utility classes, and more...

27  Java Game APIs & Engines / Java 2D / Re: Loaded images won't anti-alias. on: 2006-10-13 16:47:35
Ahh okay. And by the way, the images are drawn to a BufferedImage with a Graphics2D object, and the Graphics2D object is rotated (to rotate the whole game area). That's why I couldn't just anti-alias my images to start with, because they get jaggy when it's rotated. But if it can't be done, then that's alright, I can live with it. Anywho, thanks everybody, I appreciate it.

Ah, well you didn't mention that your Graphics2D is being rotated.  That does help explain why you're worried about antialiasing.  Anyway, as others have said in this thread, antialiasing doesn't apply to image rendering, but I suspect what you're after is some way to smooth the image when it is rotated, so try this:
    g.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);

28  Java Game APIs & Engines / JOGL Development / Re: Bug in glu.gluBuild2DMipmaps on: 2006-10-09 18:46:05
I think you want to have the target BufferedImage be created via GraphicsConfiguration.createCompatibleImage() in order to get reasonable performance, though I could be wrong about this. I'll see if the Java2D team can comment.

No, I would not suggest using createCompatibleImage() in this case.  That method is useful when you are creating an image that will be rendered to the screen/backbuffer by Java2D.  But in this case, we are creating an image that will ultimately be passed down to OpenGL via glTex{Sub}Image() or TextureIO, so it would be better to use a well-known image format for the destination: INT_RGB for opaque images, INT_ARGB for non-opaque.  This way you don't need to deal with arbitrary image formats when it comes time to upload the image to an OpenGL texture; you only need one or two codepaths to handle INT_RGB and INT_ARGB data.  Also, we're more likely to have fast scale/copy loops for those formats than any others.

I agree that Romain's ImageUtil.createThumbnail() method would be a good starting point.  Just change the line that does createCompatibleImage() to use "new BufferedImage(TYPE_INT_[A]RGB)" instead.

29  Java Game APIs & Engines / Java 2D / Re: clip an image on: 2006-09-01 15:33:52
Ah I also use the getSubImage() method to draw parts of the sprites (always using drawImage() in this way g.drawImage(image.getSubImage(0, 0, 20, 20), 0, 12, null)).

Don't use getSubimage() for this case, it will defeat image acceleration.  Instead use the variant of Graphics.drawImage() that takes both src and dst parameters:,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20java.awt.image.ImageObserver)

So taking your example:
g.drawImage(image, 0, 12, 20, 12+20, 0, 0, 20, 20, null);

We really should add an item to the FAQ about this.

30  Java Game APIs & Engines / Java 2D / Re: Resizing problem with Java 1.5, OpenGL and bufferStrategy on: 2006-08-14 16:46:12
What exactly am I doing wrong ? Is there a solution to this ?

You're not doing anything wrong.  It was one of many bugs in JDK 5's OGL pipeline that was fixed in JDK 6:

The solution is to use JDK 6...

Pages: [1] 2 3 ... 6
numerical (359 views)
2017-02-21 07:32:16

numerical (360 views)
2017-02-21 07:31:46

theagentd (471 views)
2017-02-18 13:42:33

theagentd (469 views)
2017-02-18 13:35:16

h.pernpeintner (1636 views)
2017-01-24 22:39:11

h.pernpeintner (1623 views)
2017-01-24 22:38:32

Galdo (2192 views)
2017-01-12 13:44:09

Archive (2151 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2691 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2355 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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‑
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!