Advanced compositing rules with hardware acceleration

Java 2D
#1

Hi,

I am developing a java2D based game. I am trying to find a way to keep the hardware acceraleration offered by OpenGL and/or DirectX pipelines and being able to use the multiply, divide or overlay compisting rules to generate some special lighting effects.

I could probably achieve it by using JOGL, but I like the beauty of using standard java2D calls and benefit from DirectX optilmization.

So, does anyone know a way of implementing the overlay compositing rule (like Photoshop or Gimp) without loosing the hardware optimization ?

Are there plans in Mustang or later java release to have access to htese compositing rules as we are using the AlphaComposite right now ?

Thanks.

Vince

#2

Alpha composite (amoung other new hardware accelerated features) is now supported in Mustang. Simply develop a small class that perform alpha compositing with an image for example and compare it between java 1.5 and Mustang. The performance enhancements are stunning! :slight_smile: Check out the list of new performance enhancements in Java 2D for Mustang (I don’t have a pointer to give you about that for now sorry).

#3

I am currently using the Alpha composite with Mustang and it works definitely great.

My problem is that I am not able to have the lighting effects I want to have using only the alpha composite and the Porter/Duff rules.

The effect I am looking for is the overlay blending that you can find in Photoshop or Gimp. This allows to give some fancy lighting effects without making you image foggy as it is when you simply composite a bright image with alpha on top of the original image. The overlay blending allows to keep a good contrast by making the bright areas a bit brighter (and eventually colored ) while keeping the dark area almost untouched.

I have been try to develop a custom CompositeContext class and it gives me the results I want, but it is breaking the hardware optimization.

Ideally I would like to see new Composite in java2D API enabling advanced blending mode like multiply, divide, overlay, lighten, darken, etc… while keeping the hardware acceleration.

Vince.

#4

OK!

Then I think it’s a question for Dmitri Trembovetski or another member for the Java2D dev team.

Sorry for the misunderstanding.

#5

You should consider voting this RFE

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5094232

Cheers,

Mik

#6

Yes this is exactly what I did. I vote for it and I am still hoping this enhancement request will be considered as a must have…

The java development team is really doing great and it is very exciting to see how fast java is evolving ! Hope these advanced blending mode will be part of it soon !

If you have any idea how I can do it meanwhile without breaking the hardware optimization, that would be more than helpfull.

Vince.

#7

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.

#8

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…

Thanks,
Chris

#9

That’s a great news. Please consider updating the rfe with that info.
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.

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

#10

Just did that…

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.

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.

Chris

#11

It’d be so cool if arbitary subclasses of CompositeContext could be compiled into the appropriate shader code :wink:

#12

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.

#13

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:
https://mustang.dev.java.net/collaborate.html

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.

Thanks,
Chris

#14

An other agreement? err. well, okay. I’ve sent that one too.
* pepe wonders if each project needs its own agreement… :confused:

#15

i’ve now sent the agreement more than week ago and had no news. Is that something i should expect?

#16

Well you can start developing now and then when you receive the agreement you can check your code in.

#17

yes, of course, i’ve already checked the sources and have seen where to act. But there are many ways to go and it needs to be discussed in an appropriate jdk dev forum, as the procedure says. Unless i have my account created, i can’t get in and at least start discussing. (patching AlphaComposite -which would be the easiest and fastest way-? creating a new class and taking it in account in the pipeline? …)
If i were alone, the fix would have been made some days ago, but i don’t think it would have been the best mean (would have patched alphacomposite, because faster to implement, but the ugliest imho).
As i’ve many projects and since my free time is not that expendable, i need to do things once, not twice. So, even if i know how and what to do, i’ll wait for some sun advice before coding. I would hate for the solution to be refused after being coded.

#18

Hi,

I havn"t checked my original post for some time and I see that things are getting exciting ! Good news !
I have some time-consuming projects going on right now, but as soon as I am done with it, I would be glad to help you in improving the blending modes !

Good luck and thanks for taking care of these so expected feature !

Regards.

Vince.