Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
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] 4 5 6
61  Java Game APIs & Engines / JOGL Development / Re: TextureData and null Buffer parameter on: 2006-03-02 22:20:44
Look further down in that paragraph: "The image is undefined if the user tries to apply an uninitialized portion of the texture image to a primitive." That implies to me that you have to download sub-images covering the entire texture image in order for it to be valid, so if you want to upload just a 5x5 upper rectangle and draw the rest then you need to initialize the whole 10x10 texture to black anyway.

I guess it depends on mantesat's use case.  I assumed that the uninitialized region would not be mapped (i.e. only the 5x5 region would be mapped at any time).  But I agree that you can't rely on the contents of the uninitialized area to be filled with black by default.  In the OGL pipeline we create pow2 textures (via glTexImage2D, NULL param) to hold non-pow2 image data (uploaded later via glTexSubImage2D), but we never map the uninitalized region, so this scenario works well for us.

Perhaps mantesat could clarify the intended usage...

62  Java Game APIs & Engines / JOGL Development / Re: TextureData and null Buffer parameter on: 2006-03-02 20:59:31
If you want to download sub-portions of the texture you first have to initialize the texture data to something. According to the spec for glTexImage2D you can not use NULL as the texture data to perform the allocation, update only a sub-portion of the texture, and then expect to display it. Because of this there would basically be no point in our adding support for null Buffers in the TextureData. You should allocate a zero-filled Buffer and pass it to the TextureData constructotr in order to get the background of your texture cleared.

Hi Ken,

Actually, you can pass NULL to glTexImage2D() as of OpenGL 1.1:

We used to pass a dummy array to glTexImage2D() in the Java2D OGL pipeline, but once I discovered that NULL was a valid parameter, I started using that and it definitely simplifies the code.  I think null should be allowed in TextureData for the use case mantesat describes; we do essentially the same thing in our OGL pipeline.

63  Java Game APIs & Engines / Java 2D / Re: scaling a buffered image on: 2006-03-02 20:52:51
Or since BufferedImage extends Image, you can just call getScaledInstance(int width, int height, int hints);  This also depends on the control that you want.  There are a lot more RenderingHints options with pepe's method.

Please don't use getScaledInstance().  It's old, and in many cases much slower than the scaling variants of drawImage().  We'd like to either a) reimplement getScaledInstance() so that it doesn't suck, but there a number of subtle issues that prevent us at the moment, b) add docs to getScaledInstance() discussing the limitations and point to the drawImage() methods, or c) deprecate it entirely, but this is really unlikely to happen.

Java 2D Team
64  Java Game APIs & Engines / JOGL Development / Re: TextureIO (Non power-of-2 textures, what's the problem?) on: 2006-02-22 09:41:20

In the JavaDoc, on the com.sun.opengl.util.textureTexture class, there is the following comment:


I was one of the original authors of that class.  The TextureIO stuff will try to leverage the GL_ARB_texture_rectangle and GL_ARB_texture_non_power_of_two extensions whenever possible.  If neither are available, it will just stick the non-pow2 image in a pow2 texture (without any special scaling), and then the texcoords will be calculated appropriately and returned via the convenience methods.  The only issues with these approaches (AFAIK) is in the area of texture wrap modes.  If we use the GL_TEXTURE_RECTANGLE_ARB codepath, then certain wrap modes are not legal:

Note that these restrictions do not apply to the non-pow2 codepath, or in the default pow2 codepath.  However, in the default pow2 codepath, if you rely on any of the wrap modes in your application (e.g. GL_REPEAT, GL_CLAMP_TO_EDGE) then wrapping may not work as you might expect (esp. when your image does not extend to the edges of the pow2 texture).  There are probably ways to deal with this in the TextureIO implementation, but they're all hacky (we have to resort to some of this in the OGL pipeline for Java 2D).

So anyway, the REMIND comment was referring to these issues.  I think the easiest way to resolve it is to clearly document these issues (i.e. if you rely on texture wrapping modes, then be sure to specify a pow2 image, unless you can be sure that the GL_ARB_texture_non_power_of_two extension is available).

REMIND: translucent images will have premultiplied comps by default...

This was another thing that should be added to the docs somewhere.  OpenGL developers often aren't aware that the image data (and things like glColor()) they typically deal with is non-premultiplied, meaning the alpha component hasn't been applied to the color components.  However, the typical Porter-Duff blending rules require that both the source and destination components are premultiplied.  99% of the time OpenGL developers just want "source over" mode, and all the tutorials will tell you to use glBlendFunc(GL_SRC, GL_ONE_MINUS_SRC_ALPHA), which is a clever way to get "source over" blending (with the components premultiplied as part of the blending step, but it's not strictly the same as the way P-D define it).

Anyway, it's much easier to do all blending in OpenGL if you're dealing with premultiplied components, so when I was working on the TextureIO stuff I made sure that translucent images are premultiplied before storing them in the texture.  This probably makes sense to those familiar with Java 2D's "_PRE" formats, but might not be obvious to OpenGL developers, thus the comment.

It would be great if someone could boil this down into the javadocs for the TextureIO stuff (I'm too busy with Java 2D stuff at the moment).

65  Java Game APIs & Engines / Java 2D / Re: Advanced compositing rules with hardware acceleration on: 2006-02-16 18:04:32
[Yep, I'd agree these effects are useful to a select group of developers, but we have a huge number of tasks on our plate already (that benefit a wider audience), so we haven't had a chance to add these new modes yet.  If you really want to see this happen sooner, please think about contributing code via the Peabody (aka jdk-collaboration) project.  It won't be easy, but we'd be glad to assist you along the way.
I wasn't aware that such files were part of the project. I thought that only files related to specs were public and special implementations remained private.
That's an other great news.
I would happily review the code for that. I've already signed JCA and struggled through J3D for some time. I wonder if J2D is as hard. Wink
Please contact me privately for the first steps.

This information is generally useful, so I'll post it here.  To get started with contributing to Mustang (or a later release), read the instructions on this page:

Once you download the latest Mustang sources and sign the contributor agreement, you could start by creating a new implementation of the Composite class (or perhaps adding additional constants in the AlphaComposite class).  When you get to that point, feel free to email me and I could walk you through the next steps.

66  Java Game APIs & Engines / Java 2D / Re: Advanced compositing rules with hardware acceleration on: 2006-02-15 19:24:50
That's a great news. Please consider updating the rfe with that info.

Just did that...

Nevertheless i would like to comment something.. I think -IMHO- that it's needed. It's not a feature that can eventually wait for next an other release. GUIs are going on a shiny road and those effects will be more than needed. Games have been needing them for years already.

Yep, I'd agree these effects are useful to a select group of developers, but we have a huge number of tasks on our plate already (that benefit a wider audience), so we haven't had a chance to add these new modes yet.  If you really want to see this happen sooner, please think about contributing code via the Peabody (aka jdk-collaboration) project.  It won't be easy, but we'd be glad to assist you along the way.

I wonder why you talk about shaders, btw. Can't the good old blending modes be sufficent?

For simple modes like "add", we could probably just rely on the built-in blending equations, but for more complex modes like "screen" we'd need the flexibility of shaders.  On the other hand, shaders aren't great when you need to interact with the destination (framebuffer) because you have to copy part of the framebuffer into texture memory to make it visible to the shader.  It's reasonably fast (I use that technique in some of the upcoming LCD text acceleration work), but it's a bit of a hassle.

67  Java Game APIs & Engines / Java 2D / Re: Advanced compositing rules with hardware acceleration on: 2006-02-15 17:13:06
I opened that rfe over one year and half ago, and it still hasn't been reviewed.
If only you could feel my despair about that issue....
I wonder if it will ever be implemented. Sadly i have the feeling that it would not be much work (if any...) to implement it in any of the hardware accelerated pipelines.
At least "add" is highly needed.

Don't worry, it's on our list, and definitely something I'd like to see in Dolphin.  The blending modes proposed there would be pretty easy to implement in the OpenGL and D3D pipelines using shaders...

68  Java Game APIs & Engines / JOGL Development / Re: Java2D/JOGL Interoperability Demo on: 2006-01-15 20:02:56
I mentioned above, I've upgraded to 81.98 and have the same problem.

Sorry, I was tuning in and out.  Is this crash-on-exit reproducible with non-JOGL apps, like just running SwingSet2 with the OGL pipeline enabled?

69  Java Game APIs & Engines / JOGL Development / Re: Java2D/JOGL Interoperability Demo on: 2006-01-14 21:47:03
Exiting crashes in native code related to OpenGL.  See attached error log.

This is a bug in NVidia's recent OpenGL drivers on Windows which apparently slipped through the cracks because they didn't run the Java2D/OpenGL regression test suite which Chris Campbell provided to them on that platform. From what I've heard it will be fixed in their next driver release.

Hey Scott,

See this bug:

As Ken mentioned, this was a regression in Nvidia's 81.85 driver release for Windows, and they quickly fixed it in 81.94.  Are your drivers up to date?

70  Java Game APIs & Engines / Java 2D / Re: Exception access violation using sun.java2d.opengl=true on: 2005-12-29 16:11:53
This is most likely a bug in the ati opengl drivers, you could try to install a new driver version.

Yes, this is a known bug in ATI's OpenGL drivers for Windows, see:

This bug only occurs when exiting a Swing application (or any Java 2D app that uses VolatileImages).  Unfortunately, ATI has not yet fixed this bug (as of their Catalyst 5.12 drivers), so upgrading won't help in this case.  The bug is not reproducible when you use the sun.java2d.opengl.fbobject=true property, but that will only work on new-ish ATI boards.

71  Java Game APIs & Engines / Java 2D / Re: OGL pipeline and window decoration offset on: 2005-12-27 18:13:11
The problem with ATI is that its so hard to get in touch with them.
You have to register, request support and and and ... I never managed to "report" a  bug, just sent my reports to support which did not know what to do with it.
Any suggestions howto reach the people who are responsible for development?

Yeah, no kidding.  By comparison, our relationship with Nvidia is so much more smooth and productive (they have actual bug databases, and simple email aliases like the one you mentioned).  ATI has some cryptic URLs for reporting driver issues, but I've found that these to be black holes in the past:

I've had better luck talking directly with their Developer Relations team ( and submitting bugs via email (their lack of a bug tracking system still frustrates me to no end).  The above address is intended for developers, not "end users", but seeing as how Sun has been much more open in our development of Mustang, I think it's fair to say that all of you who browse these forums are contributing in some way to Mustang.  So I'd say go ahead and help us report those driver issues directly to ATI via the alias.  If they feel otherwise, they can direct us to a more appropriate entrypoint.

Going forward I think it would be great to see more community participation in this area.  So many of you have reported issues with things like the OGL and D3D pipelines in Mustang via these forums, and that's great.  But I know that not many people have the time or patience to participate in hacking (and building) Mustang source code.  There are other ways to get involved, however, such as coming up with small reproducible testcases (sometimes Java, sometimes native) to help the various driver teams track down these bugs.  Much of our time at work is spent boiling things down to a small testcase that we can submit to say Nvidia.  If one of these driver bugs is especially problematic for you, we'd appreciate any help you can provide along these lines.

72  Java Game APIs & Engines / Java 2D / Re: OGL pipeline and window decoration offset on: 2005-12-27 03:12:38
This is a known bug in ATI's Linux drivers, and has been there forever.  We filed a bug report with ATI well over a year ago and yet they haven't fixed it.  It's very unfortunate that they haven't fixed it yet since it means that Swing apps are unusable on ATI boards on Linux with the OGL pipeline enabled.  I've tried lobbying them to fix it, but if you want to help us get Java apps working better on ATI's drivers, please get involved and report this issue to ATI.

(In general, if you see something that looks like a driver bug, please report it to Sun *and* make some noise to ATI as well.  Part of the problem with these driver bugs is that while ATI recognizes them as bugs, they don't always assign them the highest priority.  Usually, Java developers will report these bugs to us, and in turn we file a report with ATI, or Nvidia, or whatever.  Since they don't often hear directly from the Java developers and end-users, it's tough for them to understand that this impacts potentially millions of people, as opposed to "just" some small bug that Sun found in their testing...)

73  Java Game APIs & Engines / Java 2D / Re: Unable to change display mode when using OpenGL based pipeline on: 2005-12-09 21:52:18
Java 6.0 is working great! I am now able to switch screen resolution when using OpenGL pipeline!
The only weird thing (which was already in java 5.0) is that the first time my images are displayed, the colors are displayed in gray... This turn back into the real color as soon as they are displayed the second time. Do you know if there is a way to have them displayed in the real color at the first time ?

Hi Vincent,

Thanks for the comments.  Are you using an ATI board by any chance?  There is a known driver bug where the red/blue channels are swapped in some cases, which may cause the gray issue you are seeing.  Fortunately, this has been fixed in their latest Catalyst driver release, so you can download it and see if it helps.

In any case, please tell me which board/driver version you are using, just for the record.

74  Java Game APIs & Engines / Java 2D / Re: Could not enable OpenGL pipeline error on: 2005-11-18 21:20:32
Although I think having a broad support for the OpenGL pipeline is great (and supporting the intel chips in addition to nvidia + ati chips would make support quite broad) I am in doubt wether too many workarrounds would not cause the pipeline to become more and more unmaintable?

Wouldn't it be better so send a small native test-case to Intel, if Sun is contacting them I am sure they will hurry a bit more than some independet guy unhappy with their drivers would contact them.

lg Clemens

I'm in agreement.  I've strived to avoid adding workarounds in the OGL pipeline.  In fact, I can only think of one off the top of my head (in the Windows-specific code).  I wasn't suggesting that I would actually implement the workarounds in the JDK, it's just that the pipeline was unusable without them.  Ideally we would be able to work with Intel's driver team to fix the problems at the source, as we've done with Nvidia and ATI, but I'm not holding my breath.  And even if we do get the problems fixed in their drivers, I don't know many people that are able to download new drivers easily from Intel's website, which is why I don't think the OGL pipeline will be a good fit on Intel for the general population.  I'm willing to give it a shot, but I'm not confident.

75  Java Game APIs & Engines / Java 2D / Re: Will 6246760 be fixed in Mustang? on: 2005-11-18 16:34:00
As far as I can tell, this is a driver bug.  I just haven't had a chance to boil it down into a simplified native testcase for Nvidia.  Hopefully it doesn't require any changes on the JDK side, and hopefully Nvidia can get it fixed once I submit the bug report (meaning before Mustang ships).

76  Java Game APIs & Engines / Java 2D / Re: Could not enable OpenGL pipeline error on: 2005-11-18 16:31:16
Any update about the solution for issue 2?

I did most of the work a few weeks ago, but there were driver bugs that needed to be worked around, and at this point it's probably too late in the release cycle to get this in for Mustang (there are other projects that take priority).  Hopefully we can revisit it for Dolphin.

77  Java Game APIs & Engines / Java 2D / Re: VSYNC: When does FlipBufferStrategy really block? on: 2005-10-30 19:41:53
As far as I've seen vsync isn't supported in window mode at all.
You're right, it isn't.

Actually, when the OGL-based Java2D pipeline is enabled, flipping is vsynced, even in non-fullscreen mode (unless you've explicitly disabled that behavior in the driver settings).

78  Java Game APIs & Engines / JOGL Development / Re: JSR-231 in Early Draft Review on: 2005-10-24 20:53:14
I have a couple nits that I've noticed in trying to port some code to use the new JSR-231 codebase:

- GLJPanel.paintComponent() should be protected, not public.

- Regarding GLJPanel.shouldPreserveColorBufferIfTranslucent()... Ideally GLJPanel would clear the color buffer conditionally for the user, but I guess that can't be done due to the whole GLEventListener architecture.  So my only remaining complaint is about the name.  As it's written now, it sounds like you're asking whether the GLJPanel should preserve the color buffer, but it's really the application's responsibility.  How about one of the following names instead:
    - GLJPanel.isColorBufferClearRequiredWhenNonOpaque()
    - GLJPanel.isColorBufferInitializedExternally()

I realize those names aren't great, but I'm having trouble coming up with something better.  There must be something better than the way the method name is currently worded though Smiley

- Also from the GLJPanel docs:
"This class can not be  instantiated directly; use GLDrawableFactory to construct  them."

Does this mean that one is not allowed to subclass a GLJPanel?  I've been working on creating a simplified version of GLJPanel (a subclass of GLJPanel) that makes it easier for Swing/Java2D developers to jump into the world of JOGL.  This line from the docs makes it sound like I'm doing something bad/unallowed.  If GLJPanel (and GLCanvas) cannot be instantiated directly, perhaps they should be marked final (although I'm not suggesting this should be the case)?

- From GLCanvas docs:
"Overridden from Canvas to prevent Java2D's clearing of the  canvas from interfering with the OpenGL rendering."

To clarify, it's not Java2D that is clearing the canvas; it's AWT that triggers this.  Also, there are a few other places (like in the GLJPanel docs) that mention Java2D.  This might be accurate for Swing/AWT components where Java2D is involved in the painting process, but what about a LWJGL or SWT implementation where that might not be the case?  I just want to make sure the JSR-231 spec is not being overly restrictive here (and that it is not mentioning implementation details in the spec).

79  Java Game APIs & Engines / Java 2D / Re: can a translucent image be quicker to draw than a bitmask one? on: 2005-09-30 15:46:57
i'm using nvidia geforce mx400, with 60 mb of memory.
i've reduced the images sizes to 1024x256 and 64x1024, but they are still not cached... maybe they're just too big?

Yes, that's good advice from the other guys to try to use power-of-two dimensions.  We still handle non-pow2 dimensions internally, but in most cases we have to allocate a pow2-sized texture, so it can be a huge waste of VRAM if you have a 1066X266 BufferedImage, since that will require a 2048x512 texture (as the others have said).  I think GF2 MX400 has a maximum texture size of 2048x2048, so even your old images have the potential to be cached.

BTW, this is a great resource for finding out the capabilities of all kinds of graphics hardware, like available extensions, texture size limits, etc:

Anyway, I think I may know why your image isn't being cached when you use TexturePaint.  In JDK 5, TexturePaint operations will be accelerated by the OGL pipeline, but only if antialiasing is disabled, and only if the image has pow2 dimensions.  This is a reasonable restriction in cases like yours where you are using TexturePaint to tile a background image (AA will be of little use in this case).  So check to see if you have AA enabled when you use TexturePaint, and if so, comment that line  out.

This is covered in my article "Behind The Graphics2D: The OpenGL-based Pipeline":

Note that you could get around either/both of these TexturePaint restrictions by tiling your image manually with drawImage().  But I think the advice given to you so far about using pow2-sized images is useful, and TexturePaint was created for situations like yours, so give it a try and let us know if it helps.

80  Java Game APIs & Engines / Java 2D / Re: can a translucent image be quicker to draw than a bitmask one? on: 2005-09-29 16:45:28
Okay, that's a start. As Dmitri said above, -Dsun.java2d.trace=count is your friend. That will tell you what is being accelerated by the OGL pipeline, and what is not. So try again with both the opengl and trace flags, and post the output here.
what's the conclusion?

Well, it's still a bit hard to tell since you only show us a snippet of your source code.  But anyway, how many images are there in your "mountains" array?  Are there any other BufferedImages being used in your app?  And how large are they?

You can see from the trace output above that 6 images are being properly cached in texture memory.  But there are many other software blit calls (all those OGLMaskBlits) which leads me to suspect that your other images are not being cached for some reason (maybe because you're grabbing the Raster/DataBuffer using getRaster() and getData()?)... You can use -Dsun.java2d.trace=log to see where these software blit calls are coming from in your application and it will give you an idea of which images are problematic.

81  Java Game APIs & Engines / Java 2D / Re: can a translucent image be quicker to draw than a bitmask one? on: 2005-09-28 16:37:05
Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?  If so, what do you see printed to the console?


well, i've run it with -Dsun.java2d.opengl=True, and it outputed to the console: "OpenGL pipeline enabled for default config on screen 0". that's it...

Okay, that's a start.  As Dmitri said above, -Dsun.java2d.trace=count is your friend.  That will tell you what is being accelerated by the OGL pipeline, and what is not.  So try again with both the opengl and trace flags, and post the output here.

82  Java Game APIs & Engines / Java 2D / Re: can a translucent image be quicker to draw than a bitmask one? on: 2005-09-27 19:34:26
Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?

No way, are you serious? Uppercase T for verbose mode? Smiley


Good isn't it Smiley

Just think of all the hidden options you could have!

Almost as good as a png chunk name Tongue

Yeah, yeah, okay, mea culpa.  I can't believe how much flack we've caught for this one.  I remember reading a blog where some developer was fuming over the whole 't'/'T' thing.  I guess he really must've run out of things to complain about if something like this could keep him up at night Smiley

83  Java Game APIs & Engines / Java 2D / Re: can a translucent image be quicker to draw than a bitmask one? on: 2005-09-27 16:06:24
well, i've installed the latest driver from nvidia... it didn't help. any other ideas?

Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?  If so, what do you see printed to the console?

84  Java Game APIs & Engines / Java 2D / Re: can a translucent image be quicker to draw than a bitmask one? on: 2005-09-26 03:41:01
is this hardware can cause such problems or not... don't leave me hangin'...  Wink

Those drivers look really old.  Try installing the latest from I test the OGL pipeline on GF 2 MX 400 all the time without any issues.

85  Java Game APIs & Engines / Java 2D / Re: Could not enable OpenGL pipeline error on: 2005-09-17 19:05:26
The inhouse opengl guru Chris is in China currently giving a JavaOne talk, so I'm filling in.

I don't think the intel chips (and their drivers) have sufficient capabilities for
running our opengl pipeline, unfortunately.

There are two specific reasons why our OGL pipeline would not startup on Intel GPUs:
1. most of their chips/drivers do not support a PixelFormat with a stencil buffer
2. none of their chips/drivers support the GL_WGL_render_texture extension

We've effectively resolved (1) as of Mustang b51 now that we use only the depth buffer (and not stencil) for complex (shape) clipping.  Although (2) is still an issue, their drivers do support the GL_WGL_make_current_read extension, which we could use as an alternate way to copy pbuffers to the screen.  I've been thinking maybe it's time to do this so that the OGL pipeline is more useful on a wider array of GPUs out there (and Intel accounts for a pretty large majority).

86  Java Game APIs & Engines / Java 2D / Re: FBO accelerates translucent VolatileImages on: 2005-09-09 16:55:28
I have a bit off topic Q about the OGL Java2D implementation: how did you emulate the Porter-Duff alpha compositing rules (SRC_OVER mainly) with an ARGB offscreen buffer (i.e. the FBO or the Pbuffer) ?

I have no problems if the dest pixels are opaque, but  I'm getting black artifacts when the blending takes place on fully translucent dest pixels. It seems that the dest RGB is taken into account when computing the blend result.
I did a lot of experiments and I ended up to find only a viable workaroud but nothing more.

Please read this post if you have time:

Which black artifacts are you referring to?

We use the P/D rules in their theoretical form, meaning SrcOver corresponds to Fs=1, Fd=1-As (in OpenGL terms: GL_ONE, GL_ONE_MINUS_SRC_ALPHA).  But it's very important to keep in mind that the P/D rules operate on "pre-multiplied" components (meaning the color components have already been multiplied by the corresponding alpha value before the blending equations).  I think this is why your workaround "works", because it is effectively premultiplying your color values as part of the blending process, but it's also probably the source of your confusion in that thread.

I've always been really annoyed with OpenGL documentation because 99% of the time you will see SrcOver described as (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA), which may work out if you're not really concerned with the theoretical results, but it's totally wrong from that perspective, especially when dealing with translucent destinations.  I have never once seen OpenGL docs talk about "premultiplied" values, and how they're needed for true P/D blending.  Our AlphaComposite javadocs actually have a pretty good explanation:

So anyway, I suggest you just use glBlendFunc() as we do with the theoretical P/D rules as described in the AlphaComposite docs.  But then you will have to make sure that everywhere you are using premultiplied data in your OpenGL rendering code, which could be difficult given the complexity of your app.  (Not only does your source data has to be premultiplied, but you also need to make sure the destination values are also premultiplied, but the former usually implies the latter.)

What this boils down to is, if you want a 50% translucent white color, in non-premultiplied form it would look like:
glColor4f(1.0f, 1.0f, 1.0f, 0.5f);
but what you want is the premultiplied form, so that you don't have to fiddle so much with the blend func:
glColor4f(0.5f, 0.5f, 0.5f, 0.5f);

Hope this helps.
87  Java Game APIs & Engines / Java 2D / Re: FBO accelerates translucent VolatileImages on: 2005-09-08 21:28:08
Too bad current drivers (NVidia) do not support stencils yet.

Yeah, neither does ATI.  Fortunately for us, were able to move away from using the stencil buffer to just using the depth buffer, which reduced VRAM consumption, and improved performance in some cases (on top of making FBO support work properly):

88  Java Game APIs & Engines / Java 2D / Re: FBO accelerates translucent VolatileImages on: 2005-09-08 15:38:35

I knew you'd like that one, Mik Smiley  It will be available in Mustang b53 (in about two weeks).  Please give it a try and submit your feedback.

89  Java Game APIs & Engines / Java 2D / Re: How is subpixel-AA implemented in Mustang? on: 2005-09-06 18:25:03
I just wonder how slow this would be ;-)
Any better ideas?

Thanks in advance, lg Clemens

We have some code already for "accelerating" LCD-optimized text rendering for the OGL-based pipeline using shaders.  This works with our existing hardware glyph caching code nicely (FBO is not necessary).  I put accelerating in quotes because this approach is actually quite a bit slower (2-4x at best) than using our software loops.  The problem with using shaders in this case is that there can be quite a lot of overhead in enabling the shader and setting up multitexturing just to issue a few tiny texture-mapped quads.  The other big issue is that currently our LCD text rendering algorithm needs to read destination pixels in order to apply gamma correction properly, and this is obviously very slow in OpenGL.  I'm hoping to find some way we can "fake the math" so we can avoid this readback in most cases.

Anyway, the prototype code won't make it into Mustang beta, but I hope to work on it a bit more so that we can get something into Mustang.  The RFE is:

If you want to play around some more, you can look at the software LCD text rendering loops in src/share/native/sun/java2d/LoopMacros.h in the Mustang source drops.  The non-LCD aware OGL text rendering code is in src/share/native/sun/java2d/opengl/OGLTextRenderer.c.  Just be aware (as I've said), that the code for doing LCD text in the OGL pipeline is pretty much finished, so you might just want to wait until we put it back in the next few months so that you have some baseline to hack on, rather than reinventing the wheel.

90  Java Game APIs & Engines / Java 2D / Re: Draw to an off-screen Image on: 2005-08-31 21:58:07
After seeing the contents get lost when manually resizing a window I did add a check for contentsLost() and recreate the BufferStrategy, this was back in Oct 2004. But its really easy.

Unfortunately there were a few bugs in JDK 5 and earlier such that resizing a window that uses BufferStrategy was either painful or just plain didn't work.  We fixed most of these issues in Mustang (for both Blt and Flip strategies), so the developer shouldn't have to do anything special after a resize (like manually recreate the BufferStrategy); you should be able to create the BufferStrategy once and use it forever, even after a resize. 

That said, applications do need to call contentsLost() in their render loop when using BufferStrategy, just as you would when using VolatileImages directly.  The javadocs for BufferStrategy were cleaned up a bit in Mustang, so the example code is a bit more robust.  Check it out here:

I'm pretty sure this is working fine since Swing is sitting on top of BufferStrategy in Mustang and we haven't heard any complaints Smiley  If you could try this out on Mustang to make sure the issues are fixed, we'd like to hear your feedback.

Pages: 1 2 [3] 4 5 6
EgonOlsen (1573 views)
2018-06-10 19:43:48

EgonOlsen (1657 views)
2018-06-10 19:43:44

EgonOlsen (1145 views)
2018-06-10 19:43:20

DesertCoockie (1573 views)
2018-05-13 18:23:11

nelsongames (1174 views)
2018-04-24 18:15:36

nelsongames (1664 views)
2018-04-24 18:14:32

ivj94 (2421 views)
2018-03-24 14:47:39

ivj94 (1631 views)
2018-03-24 14:46:31

ivj94 (2719 views)
2018-03-24 14:43:53

Solater (884 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 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!