Development news: a dream of shadows

Page: 1 2 3
ID:2105563
 
Jun 24 2016, 1:36 pm
Version 511 continues to move forward. This week I added variadic #define macros, so you can finally do this:

#define mycall(a,b,c...) call(a,b)(c)

Also in place is support for fallback sounds in Dream Seeker, pending testing; that's something the webclient has had for a little while now, but it wasn't documented because DS had no support yet.

And at long last, I've gotten in the var access changes that Tobba recommended a while back and SS13 folks have been dying for. I did a lot of testing on that, and honestly, I'm not sure it's going to do much. After intensive profiling on Scream of the Stickster Volume II (a game that does plenty of processing and would deliver a good indication of real-world results), what I found was that the results were simply too inconsistent to get a good measurement. It looks like the var access change may represent a slight improvement, but a statistician would take one look at the data and say it needed about 100 more trials to get a good result. Ain't nobody got time for that, so this change is gonna go in the first 511 release and we'll see how it goes. The most likely outcome is it will have a very small speedup that won't be noticeable on any project except SS13; but if it does help that game out, then it was worth it.

Because I haven't given up on filters yet, I spent some time this week playing with shaders in an effort to pin down some basic effects I'd like to get to. I think Gaussian blur and outlines will work--and by that I mean I've made them work in tests--and therefore drop shadows are doable. The trick is, I really have no idea what a DM syntax for filter effects would look like, and everything I come up with is terrible--like IE 5 CSS filters terrible.

I confess part of the reason I want filters is for better maptext effects, which others have wanted for some time as well. Why draw maptext five times for an outline when you can do it once? Even if I can't come up with a filter syntax for atoms--and that would be a dirty shame--I might try to add CSS styles for this to maptext.

Also I'd really like to make a change to maptext that I may even try to sneak into a 510 maintenance release. Specifically, I think it would make a world of sense to cache any text that's drawn, and then draw it directly from cached sprites any time a match is found. The cache can be kept limited and pruned periodically to avoid things getting out of hand. That ought to improve performance a lot for games that use maptext. And if said maptext had those new CSS styles for drop shadows and outlines, the filter concept I have in mind for 511 could be cached right along with it.

It's a crazy ride and I don't know yet where it all ends, but so far so good. If you have some ideas for a filter syntax, feel free to chip in. And speaking of chipping in, don't forget to hit up the donation box or become a Member if you haven't yet. Your support is important, and much appreciated. And don't forget the Steam summer sale is on, so go try out EPΘCH--and NEStalgia too, while you're at it.
Jun 24 2016, 2:00 pm
Hurray, shaders/filters! And everything else! Yay, development! That is all.
Jun 24 2016, 9:08 pm
 
filter_mode = FILTER_OUTLINE
filter_mode = FILTER_OUTLINE | FILTER_GAUSSIAN


I think that'd be pretty nice.
Jun 24 2016, 10:28 pm
In response to Ishuri
Ishuri wrote:
filter_mode = FILTER_OUTLINE
filter_mode = FILTER_OUTLINE | FILTER_GAUSSIAN
I think that'd be pretty nice.

Won't work, unfortunately. Filters need parameters. An outline filter needs a size and a color. A Gaussian filter needs a size.
Jun 24 2016, 10:33 pm
In response to Lummox JR
Oh yea completely forgot about that. I guess if we can't just use params string like
src.filter(filter_mode = FILTER_OUTLINE, options="color=#FFAA22,size=2")

then maybe just a proc for each filter type could work. I certainly wouldn't mind it.
src.filter_gaussian(size = 2)
src.filter_outline(size = 1,color = rgb(255,0,0))
Jun 24 2016, 10:59 pm
Procs are the wrong way to handle it; this is a var situation. I'd want something that would be readable and accessible--even, if the filters were the same and in the same order, animatable.
Jun 24 2016, 11:10 pm
In response to Lummox JR
Lummox JR wrote:
Procs are the wrong way to handle it; this is a var situation. I'd want something that would be readable and accessible--even, if the filters were the same and in the same order, animatable.

This is a really tricky one. I can see it working if we had a proc that returned some form of string with jumbled up params.

So something along the lines of
filter(filter_mode = FILTER_OUTLINE,options = "color=#FFAA22,size=2")

would return a string of like:
"filter_mode=FILTER_OUTLINE;color=#FFAA22;size=2;"

almost similar to how rgb() returns the hex conversion.

so doing
src.filter_mode = filter(filter_mode = FILTER_OUTLINE,options = "color=#FFAA22,size=2")

could work out. I doubt parsing this would cause any performance hits.

And for multiple filters I guess doing
src.filter_mode = "[filter(filter_mode = FILTER_OUTLINE,options = "color=#FFAA22,size=2")][filter(filter_mode = FILTER_GAUSSIAN,options = "size=2")]"

could also work.
Jun 24 2016, 11:23 pm
If I used an RGB-like proc for this, I'd prefer a syntax more along the lines of filter("outline",color="#000",size=1), or something like that. Of course that doesn't help figure out how to chain these things.
Jun 24 2016, 11:31 pm
In response to Lummox JR
Lummox JR wrote:
If I used an RGB-like proc for this, I'd prefer a syntax more along the lines of filter("outline",color="#000",size=1), or something like that. Of course that doesn't help figure out how to chain these things.

The reason I'd prefer options over separate params per var is because some filters can get very "different" from other filters. For example, calling a motion blur would include an "angle" parameter that isn't really included in other filters. If it starts to get really full with the amount of filters, I'm sure an extensive documentation similar to how yall did for the skins wouldn't be bad. Or just a bullet list of each filter and their params.

The only way I can see it being chained is if it was searching for "filter_mode=" as it parsed the string. Even without a proc, winset pretty much demands an intake of params through string without a conversion proc so I don't think anyone would mind manually doing
src.filter_mode = "filter_mode=FILTER_OUTLINE;color=#FFAA22;size=2;filter_mode=FILTER_GAUSSIAN;size=2"

Or if it was possible to make src.filter_modes a list like contents. Then we can just do
filter_modes += filter(filter_mode = FILTER_OUTLINE,options = "color=#FFAA22,size=2")

and just do
for(var/v in filter_modes)
    ...

to manage it
Jun 25 2016, 12:10 am
A params list is simply too ugly a way to approach this. I won't go there. It adds a lot of unnecessary string building and parsing.
Jun 25 2016, 2:57 am
Would rather work with a list directly like with color matrices than a params string. Then again I'd prefer an actual datum like sounds and the transformation matrix than a generic list.

So either filter_mode = list(mode = FILTER_MOTION_BLUR, strength = 2, direction = 120)
or
filter_mode = new /filter/motion_blur(strength = 2, direction = 120)
Jun 25 2016, 9:20 am
I think a datum direction would make a lot of sense, or even a list of datums.
Jun 25 2016, 12:10 pm
I like the datum direction too. Something like the following, maybe:

var/filter/f = new()
f.mode = FILTER_MOTION_BLUR & FILTER_OUTLINE

mob.filter = f


Will this type of thing be animate()-able?
Jun 25 2016, 12:43 pm
cellshading
specular lighting
refractive lighting
MAYBE EVEN ANISOTROPIC?
Jun 25 2016, 2:09 pm
A datum would be great; it'd be cool if the datum thing can be expanded to animations as well, /animate
Jun 26 2016, 1:48 pm
Of course datums make a world of sense for this, as they do for many other challenges. Embrace the OOP, Lummy.
Jun 26 2016, 3:10 pm
The downside to datums is having to create them on read and also tying them into the atom's appearance info.
Jun 26 2016, 6:26 pm
Is there still some sillyish limit on datum references or did you lift that in days gone by? As long as having the datums doesn't hinder some 16-bit limit then I think a single creation is negligible. Furthermore, a single datum instance could be reused for every client.

If datum initialization is a major bottleneck, I'd wonder if improving that is possible, akin to improving var access. The implications could even be far-reaching into the creation of /mob, etc, though I have no such knowledge of the VM implementation to speak of such things.
Jun 27 2016, 12:29 pm
What about variables that are used for the settings for the filters, and then another variable which is used to switch filters on and off.

Example:

mob
   gaussian_size=5
   filter_mode= FILTER_GAUSSIAN


An issue is that you'd need to have these variables on every atom that can use them and they'd be wasted space if you're not using them... is there away for DM to ignore a variable's existence until another variable is switched on?
Jun 27 2016, 12:58 pm
In response to Bravo1
Bravo1 wrote:
What about variables that are used for the settings for the filters, and then another variable which is used to switch filters on and off.

Example:

mob
   gaussian_size=5
   filter_mode= FILTER_GAUSSIAN
An issue is that you'd need to have these variables on every atom that can use them and they'd be wasted space if you're not using them... is there away for DM to ignore a variable's existence until another variable is switched on?

No good, I'm afraid. The point of filters is that you may want to chain more than one together.
Page: 1 2 3