I've already talked about the source code issue - I even explain why in the video. I really do understand why you want it, but I've decided to not release it. That said, polygon clipping isn't that hard, and people should be able to get something together if they can get everything else working.

I think binding a texture is faster than computing the lighting fade-off in a shader (texture lookup vs. distance calculation), but if there's any difference, it's so negligible as to not be an issue. Additionally, I don't think you're realizing the advantages of using a texture - I can have masked lights! I could make lights out of any of these:

Good point. However, while I'm willing to explain my techniques, I'm keeping my code proprietary at the moment. I'll release it (along with tutorials and examples) later.

Basically, I want to finish my current game (since it's going to be commercial, I'm not going to be releasing code). Then, once I get jRabbit v2.0 released, I'll have my lighting system be an open-source plugin for that.

Probably - however, I'm probably going to finish my current game before I do anything like that.

I've been putting together a proto-version of jRabbit 2.0 as I go - there's a lot of very massive changes I need to do, so everything is being built again from the ground up. What I will probably end up doing is creating a series of "plugin" libraries that easily integrate with the base distribution. The lighting engine will be one of those, so you would be able to very simply add lighting to any game, but don't need to have unnecessary jars bloating your end product.

Ah... that's an interesting technique. I would not have thought of that.

However, I don't think that would work very well with what I'm trying to do. Colored lights, for example, wouldn't work, and it could potentially add up to a ridiculous amount of texture memory being used. One of the big things I am trying to do with my current setup is to keep my lights as lightweight as humanly possible (both from an API standpoint and used resources); I'm pretty close to that right now and don't want to add to it.

Still, thanks for the insight. Always good to see difference techniques.

@Riven Eh, I'm not sure it would be a significant enough jump in quality to warrant the extra render costs. I'll probably look back into this later to see if I can change the algorithm to make the lights have a penumbra, but it's not a high priority.

@matheus23Haha yeah, that's one of the main issues with pillars in my lighting engine. Straight-line terrain is fine, but curves are difficult, because the entire algorithm is based on line-segment polygon clipping.

The way that the lights work is that I render my scene normally into a texture, like this:

Then, I render my lights into a lighting mask texture:

And then I render the two buffers together in a shader, to make something this:

Voila. Easy-peasy lights.

To create the geometry for each light, I create the base geometry of a point light (a textured quad), and then I clip out sections using line segments as barriers. So, for the columns, I take the most efficient route and use the cross-section of the column as the barrier.

It looks great except for the top of the object.

It's possible that I can get away with this - one thing I did not show in the video was a "line of sight" mask that doesn't allow you to see through walls. The tops of the pillars will be covered, so the glaring discrepancy won't be as obvious.

Right now, the algorithm is just not set up to handle that whatsoever; the reason it's so fast is that I can cut corners (ensure that the geometry of the light is always clockwise, know that you never have to fade the light, just clip geometry, etc) - I'd probably have to do a full redesign to properly allow for that.

I also really like the look of hard lighting; I think it gives a scene a really sharp, edgy look, while soft shadows usually just make things look less dramatic.

That said, it's something I can come back to at any point in time; my lighting system is separate from everything else so I don't think there will be a major problem if I decide to upgrade.

I'm trying to find a good 2D graphics clipping algorithm. The view region can be moved and rotated, as can the entities that would appear in it.

The method I currently use is "lossy" - I have my viewing region, and I check if each entity's location is within its bounding radius away from the view. That way I don't have to do any complex math to determine if it should be rendered or not. However, I want to look at other, more specific methods, to see what else is possible.

Nice Game! I like the effect in the background of the game. So much i had to try it myself It took some time but it's so simple but looks awesome! Another thing is the blend effet when moving von one screen to another, ho did you do that? With a special blend mode?

Thanks! Glad you like. I was very please with how it turned out, too.

For the fade effect, I just use additive blending and render a white quad over the entire view. I switch worlds when it becomes fully opaque.

The speed of the ball was intentional. It just took way too long for the ball to move from one side of the arena to the other if it was significantly slower. Right now, it starts at a certain speed and then slowly accelerates up to double that.

There are a lot of ways in which I could add additional features, but since I made this game to take a break from a bigger, cooler game, I really want to get back to that. They are good ideas, though, and I might come back to it later.

As a break from another project, I've put together a Pong remake. It's not all that complex, but it's got single player and two player modes, basic pong, and "challenge mode" gameplay where the arena has complex terrain.

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