I don't suppose this would be too difficult a feature to impose, so how about a world variable which would dictate how the game handles the luminosity of areas, as far as appearance goes. This idea came to me a couple of days ago when I was pondering the effects of transparent icons in BYOND games.
I'd like to propose a system where the darkness can be replaced by an icon, and if that icon has an alpha value less than 255 or not all 1024 pixels are used up, the user can see what's beneath the darkness, in view() and all the like procedures. The luminosity of other atoms should still clear the darkness like usual. I have provided an example of my request here: http://www.byond.com/members/CaptFalcon33035/files/ Example_src.zip
If it is already possible, why should it become an official patch to BYOND? Well, if you saw the example, my response to that question is simple enough--movement appears too choppy and the system overall just seems... well, inefficient and hacky.
By the way, you readers have better ideas about the efficiency of my idea in DM code, please tell me. Most of all, I'd love if this could be smoothed out to go in sync with movement.
I've tried to use an overlay of a solid, translucent tile to cancel out the night overlay, but that's been ineffective so far. I can't figure out the appropriate colors and values of the tile. I really don't know if it's even possible--I'd assume it is, but if opposites don't work, what will? It seems only fitting that rgb(255, 255, 255, 50) over rgb(0, 0, 0, 155) would balance the colors, but alas! it does not.
ID:133678
 Mar 23 2008, 5:13 pm
|
|
I'm doing it in a more efficient manner that requires a single loop, but the movement still looks jerky. I've checked out your library and it appears to suffer the same exact jerky-looking movement that mine does.
| |
Could we not add luminosity_alpha? This variable would either be null to indicate default classic behavior, or an alpha channel to use for luminosity.
If luminosity is 0 (no lighting), it uses that alpha channel to make everything lighter. If it's 1 or above (lighting in this or surrounding areas) it removes that alpha channel. Or something. -- Data | |
You might try my dynamic lighting library, but replace the dithered darkness icon with a translucent one instead. I've been meaning to update sd_DAL to allow user defined darkness icons for a long time now, but my BYOND time is next to nothing these days.
Overlays don't work quite like that. Let me walk you through it how it calculates the values you see. The red component would be (overlay_alpha * overlay_red + (255 - overlay_alpha) * pre_overlay_red) / 255 rounded to the nearest integer. After you overlay (0,0,0,155) on pixel (R,G,B) the visible red component would be (155 * 0 + 100 * R)/255, which simplifies to 100R/255 or about 0.392R. The blue and green components are calculated the same way, using the appropriate color values. The visible color would be (0.392R, 0.392G, 0.392B) or roughly 39% the brightness of the original. Now if we overlay (255, 255, 255, 50) on it, the visible red would be (50 * 255 + 205 * (100R/255))/255, which is (12750 + 20500R/255)/255 or about (50 + 0.315R). The original R value is even less visible (31% of the original pixel showing) and now it is washed out by adding a flat 50.
Simply put, you can't apply a static overlay to cancel the visual effect of another overlay. The only solution is to selectively display the first overlay.