ID:1127915
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
It's kinda odd BYOND doesn't have any of the sort of basic graphics processing you would find in almost any other game engine. Being able to dynamically change the brightness, hue, and so on really does a lot for games. It can make day/night cycles look nicer, it can make horror games much creepier, it can be used to frost up a cold area or heat up a hot area.

Alpha blending screen objects is a poor substitute for actually being able to change the properties of the screen itself.
+1
Filters of any kind would be nice. Be it for certain icons or for the entire screen. Ideally client-side.
In response to Aaiko
Aaiko wrote:
for the entire screen. Ideally client-side.

Yeah, that's the idea.

I mean, you might be able to do this with creative use of icon blending but that would be impractical and silly to even consider using in an online environment.
Stuff like this is long over due.

+23,456.7
My support!

++++
What? My support? Never! Never would I choose not to offer it that is!
+1
+10000 do it.
+
Feature++
Screen and individual atoms, client sided, very useful.

+1
This really needs to be a feature. Seriously.
Definitely a feature to consider adding for the future. When testing F_a's lighting system in my project, with 50+ active clients, it just wasn't reliable performance wise.

Would use, along with many others, I'm sure.

+1
In response to Writing A New One
Writing A New One wrote:
Definitely a feature to consider adding for the future. When testing F_a's lighting system in my project, with 50+ active clients, it just wasn't reliable performance wise.

Would use, along with many others, I'm sure.

+1

Part of the reason it wasn't reliable for you was because his code, by default, is inefficient. I have written an article on how to make it much more efficient and work on a much larger scale in the Tutorials & Snippets forum.
Really keen for this, especially client sided.
In response to FIREking
FIREking wrote:
Writing A New One wrote:
Definitely a feature to consider adding for the future. When testing F_a's lighting system in my project, with 50+ active clients, it just wasn't reliable performance wise.

Would use, along with many others, I'm sure.

+1

Part of the reason it wasn't reliable for you was because his code, by default, is inefficient. I have written an article on how to make it much more efficient and work on a much larger scale in the Tutorials & Snippets forum.

I've tried your optimizations and they don't solve the issue of massive startup times. It takes extremely long for a map with potentially 800x800 total tiles or greater to load, enough that it's just not worth it in the long run.

I also was not able to get the lighting system with your optimized code to work, even with extensive tinkering.
You really should stay away from maps that are 800x800 in general.... z levels in maps can do much more for you.
Regardless of the amount of z-levels it still ends up being about the same as far as overall size -- things end up all compiled together in the final product.
Forum_account's lighting engine creates a layer of sharing objects when initialized. If you want to optimize it, you should create shading objects when clients move around, just outside of their view.
Page: 1 2