Dynamic Lighting

I'm glad you like it, but we'll have to wait and see how many people actually use it in games =)

Being able to execute code on the client would be nice, but I'm not sure it'd help in this case. The lighting would still rely on having pre-rendered icon states representing each possible illumination state. A built-in solution could easily render the shading in a non-tile-based manner.

As for general code executing on the client - there are definitely problems and I'm not sure how difficult they'd be to work around. There are some decisions that would have to be made and it would be limited, so I'm not sure how useful it would end up being. It'd be limited because you can't do things like "for(var/mob/m in world)" and run it on the client because each client isn't aware of every mob.

I think it'd be useful for the client to be able to run code that changes properties of atoms as they're represented on the client. These changes would be local only - they wouldn't be propagated back to the server.

For example, suppose you create a dust cloud object and want it to slowly move by updating its pixel_x and pixel_y vars. Currently the server has to send updates to each client when the object is created and each time it moves. By executing code on the client you could have the server send a single message that tells the client there's a new dust cloud object and the clients figure out how to move it.

This would let developers make more elaborate visual effects without impacting the server. It would be just as complex (possibly less complex) than creating an object, flicking an animation, and deleting the object. You could have the client move and modify the object in a variety of ways and the network usage would be the same. This would greatly benefit from features like these two.

I was trying to get the library in shape to add shadows. There isn't much that has to change (mostly just the atom/light() proc, if you'd like to take a stab at it). There are still some internal things that'd need to change because light sources currently update when they move, but with shadows you'd need to update light sources when a nearby, non-light-source moves too.

Now that I think about it, having opaque objects move is fairly complicated. You'd have to undo the lighting effects as they existed prior to the opaque object's move, then recalculate them after the move. It's possible but it probably wouldn't be very elegant.

Shadows are what'll slow it down, so I'd be curious to see how it performs then. I might try it later, but if you try it first let me know how it goes.

Nice work as always :). One annoying limitation is that lighting seems to transform before the mob finishes moving tiles, as opposed to a smooth transition.

Forum_account's lighting:
0.000018 seconds per call (no shadows, linear dropoff)
0.001400 seconds per call (darke shadowcasting, quadratic dropoff)

Darke's lighting:
0.000029 seconds per call (no shadows, quadratic dropoff)
0.000273 seconds per call (darke shadowcasting, quadratic dropoff)

I'll keep you updated as I work on it. Since my approach isn't working very well, you might get better results if you implement shadowcasting your own way (or if you use a different algorithm)

More and more it feels like my game is based on nothing but your libraries..

When I first played around with your pixel-movement library, the isometric-demo inspired the current game I'm working on now. Not just the pixel movement but the jumping too. The game I am working on is about assassination, infiltration, and sabotage with an amazing historic background powering it.

The pixel movement, along with the ability to jump over walls that your library provided was essential to such a game.

I tried to comprehend how D4RK3 54B3R's lighting worked in his DarkeNyctoSource for the purpose of understanding how to go about making a lighting system of my own.. but knowing so little as I do about coding, I couldn't understand a thing hardly. To make matters worse, I have a hard time reading code as it is without #define u #define and u this asthis.. and what's with putting everything in a single line anyway? I'm sure he did it on purpose to confuse beginners >.<

As with most espionage games, things like jumping/climbing over objects and clever use of darkness are essential.

The lighting system in D4RK3 54B3R's d4_ASE is really amazing. I would like to see you continue to update this library in hopes that it is close in power to D4RK3 54B3R's lighting system but keeps its simplicity.

And compatability with isometric games would be nice too :D

I posted an update which has some drastic changes to the internals. Some of the changes were made to improve how the library runs and how it can be used, but mostly the changes were made to accommodate the addition of shadows.

Shadows are implemented entirely in the demo (a new demo called "shadows-demo" was added) by overriding the atom/light() proc and the built-in Move() proc. Aside from overriding those procs, to use shadows you just have to set the "opaque" var (which the demo defines for all atoms) on the objects you want to cast shadows. Defining light sources still works the same way.

Dragonsleeve wrote:

And compatability with isometric games would be nice too :D

I'm not sure how well it'd look on isometric maps, especially if you have jumping and elevation. The illusion of shading works best with a top-down view because the display is strictly 2D - each point on the screen represents a single position. With an isometric display with 3D movement the player can be in multiple positions that map to the same location on the screen.

For example, you can get to the same position on the screen by standing in one place, or by moving downwards from that position and jumping. When you jump you move into the same position on the screen you were previously in - your x and y are different but your pixel_z puts you in the same spot.

What this means for lighting is that the same shadow object is drawn over top of the player and may not look correct. The shading is based on what the illumination on the ground looks like, so when you jump the incorrect illumination will be shown on the player.

The simple way of applying this to isometric maps might not work to well, but I can try it if you'd like to see how it looks.

I noticed something that acts a little odd. When making a movement the light moves instantly and then the movement is executed. Not sure how feasible it is, but could the light slide along with the player? Or possibly have the light fade in when affecting new turfs and fade out when leaving turfs?