Client-side Appearance Scripts

Page: 1 2
ID:2207442
 
Feb 1 2017, 12:42 pm (Edited on Feb 1 2017, 1:01 pm)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
So we have this fancy dms thing. I'm not 100% sure what it does because the documentation is iffy, I know that it does macros and aliases and other client stuff, but it would be nice if it could also serve as a way to modify appearances client-side without bogging down the server with appearance churn.

I'm pretty sure the client only deals with appearances but the ability to modify appearances would be absolutely great in making the client more responsive even if all these scripts know about is appearances.

The next thing that would be needed is a way to use something like winset to change vars. With both of these, the dms code would look something like this:

winset(user, null, "hideLighting=1") // or something like that


.dms
// remove the lights
appearance/removeLight(a as appearance)
    set filter="icon_state=\"\";icons='icons/effects/alphacolors.dmi'"
    if(hideLighting)
        return null
    return a


Make sure this is only possible with server-assigned scripts though. Things that would also be nice:

- click events in dms.
- Something that gets called every tick. with the option of running before or after the appearance scripts. Maybe a set run_order = whatever
- ability to add create new temporary appearances on the fly.
- I'm not sure how the location of the appearance works, but include that information in the calls. I know that screen_loc is in there but information about where it is if it isn't screen_loc and the pixel offsets would be good.
- This appearance script should be called for every instance that appears on the screen, not for every appearance that the client has.

This would be really great in making BYOND a more responsive program to work with. It would make it possible to make the thing more responsive. For example, you click on an item and it transfers to your hand instantly instead of having to wait. Also, sexy shadowcasting system.
Feb 1 2017, 1:56 pm
Honestly I'm not sure what you're getting at here; it sounds more like you might still be a little confused on how appearances work in general. Modifying appearances isn't sensible, but altering the way a specific atom or image appears would be more in line with existing functionality (i.e., animations).
Feb 1 2017, 2:06 pm
Either way, a way to modify what's on the screen using only client side code would be a great thing to have to improve the responsiveness of BYOND.
Feb 1 2017, 2:10 pm
But in what way? I need a more concrete example. I can't make head or tails of the above script because it doesn't really tie in with an example I can wrap my head around.
Feb 1 2017, 2:26 pm
Ah, so I'm not 100% sure on how this stuff works, but before rendering a frame, you'd have the code go through all the things and use the above dms thing (and compare the appearance to the filter) and if the filter passes, it calls the proc and then if it returns null you remove that thing from the list of things that are to be rendered, and if the appearance gets modified it would create a new temporary "appearance" object and the list of things to object would reference that appearance object in the item in the list of things to be rendered.. That appearance object would only exist clientside.
Feb 1 2017, 8:14 pm (Edited on Feb 1 2017, 8:20 pm)
He wants a way to manipulate how appearances are rendered with a simple "script"-esque syntax (eg the filters but mroe robust)
I think it'd be nice to have clientsided DM scripts myself (or perhaps some kind of sandboxable scripting language that'd be very easy to bind in C/C++ for speed such as for example luajit cough cough) that'd let us handle have more control over the renderer.
Feb 2 2017, 4:47 pm
that's why you have javascript right :^)
Feb 2 2017, 4:48 pm
don't you dare
Feb 6 2017, 1:20 pm
Well, it could be translated into javascript when used on the webclient?

Either way.... make this happen, lummox.
Feb 6 2017, 2:17 pm
Again though, I'm still looking for a more concrete usage example. As in how would such things be used, and to what purpose?
Feb 6 2017, 3:51 pm
The idea is to give the DMS full control over the "list of things on the screen"

Example 1: "Shadowling Overbright" - Basically a mechanic where instead of black where there is no light and normal where there is light, have it be normal where there is no light, and white where there is light. This is the lighting system that will be used in this example

So, with this system, it would be enabled via winset:

winset(user, null, "enableShadowBright=1")


dms
//This would be called every tick for every unique
//appearance within the filter on the screen *if there's
//only the one appearance as an argument*, or every
//*thing* on the screen if pixel and step and x/y
//position is in the arguments

appearance/shadowBright(a as appearance)
    set filter = "icon_state=\"light1\""
    // a is basically the appearance object
    // with all the vars but clientside
    // it's immutable but calling derive()
    // on it would create a new appearance
    // or a temporary appearance or whatever
    // is the most performance friendly
    // way and appearance() as a global thing
    // would just create one not derived
    // Whatever this returns ends up being
    // what is rendered on the screen in place
    // of this instance of the appearance
    if(a.blend_mode == BLEND_OVERLAY) // Greyscale lighting overlay
        return a.derive(blend_mode = BLEND_ADD, alpha = 255 - a.alpha, color = "#FFFFFF")
        // Use additive blending, reverse the alpha and make the color white
    else // Colored lighting overlay
        return a.derive(blend_mode = BLEND_ADD)
        // all we need here


This is a pretty simple example.

Here's something else:

// Parallax with no server-side cost
appearance/parallaxScroll(a as appearance)
    set filter = "icon='parallax.dmi'"
    return a.derive(pixel_x = 128-client.eye.x, pixel_y = 128-client.eye.y)


And

// In response to PJB3005's comment of "Why is it so hard
// to make the player appear 5 pixels bigger on their own
// screen
appearance/makePlayer5PixelsBigger(a as appearance)
    // Also allow "set src in client.screen"
    set src = client.eye
    // make it literally 5 pixels bigger
    return a.derive(transform = a.transform.Scale((32+5)/32, (32+5)/32))


You would probably have to implement the non-byond specific functions of DM into DMS for this to be workable (last I checked params2list just gives an error when I try to eval() it)
Feb 6 2017, 7:07 pm
Shader support would also be a decent idea.
There are HLSL to GLSL shader converters in C++ that would allow for interopping between the webclient and dreamseeker.
Feb 7 2017, 12:13 pm
Shaders wouldn't work on software mode though
Feb 7 2017, 2:40 pm
In response to Monster860
Monster860 wrote:
Shaders wouldn't work on software mode though

Who still uses software rendering? It doesn't support a majority of DM's features.
Feb 7 2017, 2:55 pm
I'm kinda nearing the point where I'd like to ditch the software renderer outright.
Feb 7 2017, 2:56 pm
Not a single tear will shed. You should do some analytics to see what percentage of people actually use SW rendering.
Feb 7 2017, 3:32 pm
Everyone will when the hybrid laptop issue is ficlxed *cough* *cough* anyways is that a good enough example
Feb 7 2017, 3:32 pm
pretty much all intel processors come with an integrated "gpu"ish
Feb 7 2017, 3:54 pm
except that's not the issue with laptops
Feb 15 2017, 5:44 pm
So was this example good enough?
Page: 1 2