I do per-pixel lighting in Rescue Squad 2. Basically there's three passes, first a full bright pass consisting of the visible sprites:

Then there's a lightmap pass where sprites and other light geometry are drawn to:

Both of those are captured to a texture, and the final pass just multiplies the two together:

The nice thing about this is that lights can be any shape (like the search light's cone of light) and quite detailed, since really they're just another sprite. And it works on pretty much any pc hardware too.

I mean, most likely you would do it kinda professional =DI would take a black color with an alpha value which is overall very high, and very low at lightsources

which means, since I'm using Java2D Graphics.setColor and fill methodsonly problem is that I cant render a square which a oval round which is empty =Pand I dont even wanna think about reflection in this regard

I mean, most likely you would do it kinda professional =DI would take a black color with an alpha value which is overall very high, and very low at lightsources

which means, since I'm using Java2D Graphics.setColor and fill methodsonly problem is that I cant render a square which a oval round which is empty =Pand I dont even wanna think about reflection in this regard

But you don't have to. If you do it like Orangy Tang explained, you can additively combine lights on top of an ambient light, and finally multiply the whole shebang with the unlit scene. You also get colored lights for free with this technique, unlike when you subtract alpha from black.

Although if you're stuck with Java2d then that's an entirely different kettle of fish - I doubt that method would run fast enough (although I'd be interested in seeing how fast it does run).

If you're stuck with j2d, then your best bet is to do the lighting manually per-pixel in a big working buffer - I believe L4kD does this so you might want to poke around the source for that. But you'll probably be limited to quite low resolutions with that method.

seems awfully tedious to do in j2DOverall I'm not that good of a programmer to do it like he did.

How difficult / how much is it to "convert" a j2d game in JOGL or slick or whatever you guys would suggest ?I mean of course that depends on my game, but afterall its just the rendering processes which isnt as much

Its probably pretty quick to convert to slick since the api is very similar to java2d. However if you decide to use JOGL or LWJGL you'll have to use the opengl api which will take longer to convert too.

I do per-pixel lighting in Rescue Squad 2. Basically there's three passes, first a full bright pass consisting of the visible sprites:

Then there's a lightmap pass where sprites and other light geometry are drawn to:

Both of those are captured to a texture, and the final pass just multiplies the two together:

The nice thing about this is that lights can be any shape (like the search light's cone of light) and quite detailed, since really they're just another sprite. And it works on pretty much any pc hardware too.

why cant this multiply be done in j2d?? without considering the performancecan someone plz give me a hint or link to the math behind this (pixel by pixel) multiplication??

I'm actually trying to create that affect. =) But, I'm not in that part of my development yet. I've always enjoyed the retro look of sprites, and I wanted to meld this with realistic lighting and shadow affects.

why cant this multiply be done in j2d?? without considering the performancecan someone plz give me a hint or link to the math behind this (pixel by pixel) multiplication??

thank you in advance

The j2d api only* provides out-of-the-box functionality for compositing using the alpha channel, not for colour compositing. You can easily implement your own custom ColorComposite**, but it obviously won't be hw accelerated, so will be all-but useless in relation to performance.

I'm sure there is an RFE somewhere in the bug database on the subject, as its absence significantly restricts the usefulness of j2d for many interesting effects.

(* Technically there is one color composite operation supported; XOR mode. It's a legacy bit of functionality from the early days of Java; it doesn't use the more modern Composite interface. Also I remember reading somewhere that it doesn't work [very well/at all] in the hw pipeline.)

( ** Though you also need to be aware you will run into all sorts of problems with custom composites if you try and use them when drawing onto a VolatileImage or BufferStrategy.)

if the values are float, then i suppose this works, (with a step of "1.0 (minus) "final result" " perhaps?)if the values of the three channels are integers, i cant seem to work it outfor example, a light red, value70, and the light source with value 200. multiplying them, the final result is out of the permitted range [0,255],so i guess there are two options:the multiplication is a logical ANDor the programmer decides upon the ratio of the two values (destination, light), perhaps 3/7 meaning that the destination number will be multiplied by 0.3 and the light number by 0.7, bigger values for the destination mean that the difference between illuminated areas and non-illuminated will be smaller...

i believe i should make a code example to prove it (to myself mainly, and to all who are interested secondly)... damned university, taking all of my sober time away...

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