So, I've been toying around with dynamic tilemap lighting, and it's going okay-ish, but I can't wrap my head around combining lights. As of now, each tilemap holds values of the lighting of each individual tile, from 0 - 255. 255 being completely black. So anyway, here's a screenshot of the problem:

When you add a new light source, you do something like: Math.max(oldValue, newValue) for each tile affected. Or if you want over laps to be a little brighter, do something like add them some how?

Light "stacks" additively. Put two lights on the same spot and it will be twice as bright (though that does not mean that the human eye sees it as twice as bright, but to handle that you need tone mapping and preferable HDR rendering).

It makes a lot more sense to set 100% darkness to 0 and 100% brightness to 255. That way, each tile contains how bright it is, instead of how dark it is which makes a lot of things easier. For exampe, you can just add together the light contribution from each light to determine the brightness of each tile. I don´t know how you render the tiles in the end, but if you use OpenGL you can just call glColor3f(brightness, brightness, brightness); (need to cast brightness to byte though) and the tile texture color will be multiplied by the brightness. If you use Java2D, I don´t know exactly how to do it, but to multiply a color by the intensity you convert the 0-255 brightness value to a 0.0-1.0 float value and multiply it with the color of each pixel.

When you add a new light source, you do something like: Math.max(oldValue, newValue) for each tile affected. Or if you want over laps to be a little brighter, do something like add them some how?

Light "stacks" additively. Put two lights on the same spot and it will be twice as bright (though that does not mean that the human eye sees it as twice as bright, but to handle that you need tone mapping and preferable HDR rendering).

It makes a lot more sense to set 100% darkness to 0 and 100% brightness to 255. That way, each tile contains how bright it is, instead of how dark it is which makes a lot of things easier. For exampe, you can just add together the light contribution from each light to determine the brightness of each tile. I don´t know how you render the tiles in the end, but if you use OpenGL you can just call glColor3f(brightness, brightness, brightness); (need to cast brightness to byte though) and the tile texture color will be multiplied by the brightness. If you use Java2D, I don´t know exactly how to do it, but to multiply a color by the intensity you convert the 0-255 brightness value to a 0.0-1.0 float value and multiply it with the color of each pixel.

I'm doing in this in the simplest way possible, seeing as it's not a major feature of the game. So, essentially, it's just aesthetic; the 0-255 thing is the transparency of the black blocks that overlap the tiles ;p lol.

I did the exact same thing when I did 2D lighting. I imagined a "shroud" that had a transparency value that worked as an overlay over the game world, and I bumped into the same problem when lights started overlapping.

I did the exact same thing when I did 2D lighting. I imagined a "shroud" that had a transparency value that worked as an overlay over the game world, and I bumped into the same problem when lights started overlapping.

So if I use the brightness thing, I could just change the color and leave the transparency alone, right?

Can you fill me on how you achieved that isometric effect in the other article though? I originally planned to make my game's dungeons isometric, but couldn't draw the tiles, seeing as the whole game is essentially hand-drawn. Converting orthogonal tile-sets to look isometric would make my life awesome. lol

Can you fill me on how you achieved that isometric effect in the other article though? I originally planned to make my game's dungeons isometric, but couldn't draw the tiles, seeing as the whole game is essentially hand-drawn. Converting orthogonal tile-sets to look isometric would make my life awesome. lol

Heh, that was a copy paste fail, but anyway...

Drawing isometric tiles is no different from drawing normal tiles. The best looking way is to have an isometric tileset since it produces the sharpest textures. Using a normal tileset makes the tiles look blurry, which you can see in the screenshot in that thread. The only thing I did was rotate the whole screen by 45 degrees and then flatten it a bit by scaling. It´s all there in the source code, so take a look there.

That one was meant for drawing extremely large maps. The map there was 2048x2048 tiles = 4 million quads = 16 million vertices, which to be fair can actually be handled by a decent GPU at over 60 FPS. If you have that large maps you obviously needs some form of culling to get rid of the tiles that are outside the screen, as simply drawing all those quads is going to eat more vertex power. It´s inefficient for both the CPU and the GPU. Instead my program just draws a single 2048x2048 sized quad and then a shader figures out which tile to read for each pixel on the screen. Since parts that are outside of the screen is automatically clipped by OpenGL, no culling is needed, an the only limiting factor is the texture size the GPU can handle, but simply streaming parts of the texture to the GPU as the player moves across the world allows you to have maps of any size. Again, the source is there, so take a look if you want to.

This is obviously overkill for most games and has pretty much no connection to isometric tiles. I just put that there since everyone was talking about isometric tiles when I created that thread. xD The rotate and scale trick works for drawing tiles in any way, so you can just "convert" normal tilesets to isometric that way even if you just use normal quads.

Ooooh, new idea: combine this with tesselation and I have a brand new 3D tile terrain renderer! =D

By the way, I kinda can't get soft shading to work in my engine lol. Problem is, being the noob I am, I don't really know where to start.

I was going to use OpenGL, but the thing is my engine wasn't built to use it, so I don't have access to an OpenGL drawable canvas, I'd imagine.

I'm using Slick2d, and using a GameContainer and the Graphics object to draw things, not sure if there's some magical connection I could use for access to OpenGL. Slick tends to have magical connections like these that I don't know about until I make an idiot of myself on here asking about them, because they generally aren't in plain sight on the tutorial pages ;p

Would you know? Assuming I can't use OpenGL, how should I approach simplistic lighting?

theagentd is referring to LWJGL, implements the OpenGL API as static methods. JOGL uses a GL graphics context object that gets passed in, similar to awt/swing, while GDX uses a global object. Since Slick2D uses LWJGL under the covers, that's what you'd be using. Anyway, the LWJGL wiki will get you started on that static method API.

I'm sorry if these are real obvious, but I haven't used OpenGL directly at all...ever. lol

o_O Then this is a great opportunity to start! That article is what got me going with OpenGL. If you have no experience at all you should start out with doing some basic stuff; glBegin-glEnd, colors, texturing, e.t.c. The thing is that the lighting in that article is very easy to implement (at least only with hard shadows). The only things you need are FBOs, textures, very basic glBegin/glEnd geometry and blending pretty much. Even better, you´ll gain most of the basic knowledge needed to make games from just this.

I based my lighting system on this article as well for Daedalus ... in fact it is this article that motivated me to start to program my own game, and I saw a lot of other articles based on yours all over the internet ! It seems that you've inspired a lot of people with this ! Thanks !!

Lwjgl puts opengl functions in a class corresponding to the version (or extension) that the function belongs to. So GL11 contains all the functions defined by OpenGL v1.1 (ie. base opengl). All additional functions introduced in OpenGL v1.2 are in GL12, etc. Similarly any functions defined as an extension go in a class named after the extension (eg. ARBVertexBufferObject).

If a computer supports OpenGL, then it will always support GL11 functions. For anything above that you should check ContextCapabilities.

Often it's useful to choose a suitable base level (eg. GL20), check if that's available on start-up and then use whatever GL20 and lower functions you need afterwards.

Someone needs to find me a literal full explanation of how this thing works, I have no idea what I'm doing. Most of the tutorials I've found assume I know all of the terminology and what-not. It usually involves "conceptual code" as if I know how to convert to actual code. lol.

EDIT: For anyone who may read this, I found this. It's helping me a bit with terminology, but the above problem still persists at the moment :p Here it is: http://www.arcsynthesis.org/gltut/

One thing you can probably get rid of is that last glHint, since it's meaningless in every modern driver I'm aware of. The rest, you'll need to pick up an OpenGL tutorial to learn what everything does. It's doing a lot, nothing that can be answered in a few forum posts.

One thing you can probably get rid of is that last glHint, since it's meaningless in every modern driver I'm aware of. The rest, you'll need to pick up an OpenGL tutorial to learn what everything does. It's doing a lot, nothing that can be answered in a few forum posts.

That's the thing, all of the tutorials explain everything in the most complicated way possible with absolutely nothing visual for me to mentally grasp. Most of the time the shader tutorials don't have screenshots of what you're making either, so you have no idea on whether or not you're wasting your time or not.

I wish I had comforting words there, but learning OpenGL from online tutorials really is a damned tricky thing, requiring you to go between lots of different ones to pick up basics. Then there's learning it in Java, which have hardly any tutorials written using it. While LWJGL clones the OpenGL C API almost perfectly in java, the various books still tend to assume C++, and porting things like matrix classes from them can be very tricky if you don't already have C++ experience.

I found the original Red Book, obsolete as it is, to be an immensely helpful resource, but it's no help for learning the programmable pipeline. It could be that learning the fixed function pipeline then unlearning it for shaders is still the best way to ease into it.

I wish I had comforting words there, but learning OpenGL from online tutorials really is a damned tricky thing, requiring you to go between lots of different ones to pick up basics. Then there's learning it in Java, which have hardly any tutorials written using it. While LWJGL clones the OpenGL C API almost perfectly in java, the various books still tend to assume C++, and porting things like matrix classes from them can be very tricky if you don't already have C++ experience.

I found the original Red Book, obsolete as it is, to be an immensely helpful resource, but it's no help for learning the programmable pipeline. It could be that learning the fixed function pipeline then unlearning it for shaders is still the best way to ease into it.

Well, the lighting I want is really simple. I just want black if there's no light, and circles of light where there is. If you can just point out functions in the direction of doing this, I can just kind of bullcrap my way through.

I could do this the simple way, and make shading voxel style myself, but it'd look bad with the sketched graphics.

Yes, that looks like you have mismatched lwjgl jar + source setup in eclipse. The debug info from the .class file it's running says that the function is at line 2052, but when eclipse tries to find that in the source attachment you've given it it doesn't exist.

I'd suggest upgrading your lwjgl (jars + source + docs) to the latest so you know they're all the exact same version.

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