Development news: do you wanna build a...

ID:2564390
 
Apr 24 2020, 10:24 am (Edited on Apr 24 2020, 10:32 am)
Well, crap. The animation overhaul I was working so hard on appears to have stirred up more bugs than it fixed. Although I'm convinced these changes are moving in the right direction in terms of code clarity and future-proofing, a number of problems came up that I'm now working to address.

A lot of other stuff from the long-awaited 513.1518 update has been working fine though, so it's not all bad news. At the moment I can't speculate on when I'll have the next release ready, but I plan to make it soon once the animation bugs are quashed. The sooner the better, really, so I'm willing to risk the Friday curse if I can get those solved today. I've solved a few already this morning, but there's another test case incoming.

In spite of those crazy setbacks I'm still looking ahead. Lordovos had an interesting suggestion in Discord about possibly adding return types to procs, which is something I've been pondering for a while, but he has a pretty interesting syntax for it that I hadn't considered before. (I was thinking of using the "as" clause, which still might be the most consistent way to go, but anyway he got me thinking more about it.) Proc return types would allow the compiler to make smarter decisions when chaining after a proc call, if the compiler can be sure that won't change in an overridden proc. This has kind of led me to think more about hardening up types in some other ways, like perhaps a "strict" keyword in vars that would force a match to that var's declared type. The trick is, the .dmb format contains no var type information, so that would have to be a pretty significant change. Also for local vars, strict types could potentially be slower for all var accesses so it's not a change I'm sold on and I'll have to think on it some more.

Inline procs are another thing I keep wanting to work out how to do, and 514 would be a good time to look into them. This would involve delving into some parts of the compiler I haven't messed with like how proc local vars get defined, so there are a lot of moving parts to this, but inline procs have the potential to be game-changers for some projects. I was looking at someone's profile results from an SS13 server the other day and several procs had call counts numbering in the tens of millions, where I suspect performance would increase dramatically by inlining them. But inline procs do have a readability advantage that's hard to beat.

Anyway, that's a bit of my thought process for future stuff. I welcome your brainstorms on any ideas. The big 514 item is still slated to be particles, which I think have a huge wow factor.

Thank you all so much for your continued support via Membership, Patreon, etc., especially now. I'm not going to say one of the clichés going around because as it is, I'm thinking of writing up a drinking game to go with all the platitudes. But be nice to each other, except to anyone who unironically uses the phrase "the new normal". You don't even want to know the game rule for that one.
Apr 24 2020, 11:21 am
Very good news, keep it up !!
Apr 24 2020, 11:24 am
Neat ideas. Some thoughts:

I suggest making inline procs opt-in, to lower the logic burden and resultant problems of "getting it wrong"---e.g. inlining medium-sized procs into a million call sites. Some syntax thoughts, in order of preference:
proc
    Foo()
        set inline = TRUE
        // ...

    inline/Bar()
        // ...
Of course, there are certain logistical issues to work around as well, e.g. proc-static variables:
proc/Foo(mob/m)
    set inline = TRUE
    var/static/calls = 0 // or is it var/global? I forget. They seem equivalent.
    m << ++calls

mob/verb
    Bar()
        Foo(src)

    Baz()
        Foo(src)
While at it, it could be a good time to introduce other compile-time optimizations as---last I checked---the DMB output is pretty much a 1:1 instruction mapping of the input code.

Static type checking would be handy for sure, and if you go the distance of adding it to return types, I would also go the distance of checking arguments as well. (Also opt-in, for backward-compatibility.) You might also want to have considerations for mixed typing; e.g. using untyped code from typed code. I'm not sure what the interesting syntax you hadn't considered was, but I could see it like so:
#define STRICT

// Strict typing example.
proc/Foo(mob/m) -> /mob
    return m

proc/Bar() -> null
    Foo(new/obj) // error:type mismatch

// Mixed typing example. Foo() does not specify a type.
proc/Foo(mob/m)
   return m

proc/Bar() -> /mob
    return Foo(new/mob) // warning:type safety
Apr 24 2020, 2:59 pm
In response to Hiead
Inlining would absolutely require a keyword. I don't think the compiler should make assumptions about what the user wants in this regard.
Apr 24 2020, 4:12 pm
Can you do a bit of Quality of Life improvements after doing all these big features right?

Things that get people up and running fast. Like, I'm lost on what my custom color presets is supposed to do cause it sure doesn't seem to be what I think it should be...colors I want to use in all my icons. Like a custom palette, that would be nice.

1)Button to Create Custom Palette.
2)Window that asks the Name of the Custom Palette.
3)Window that asks how many colors you want on the palette.
4)Window like the one used when you double click a color in use, the "Change Color" window to add each color.
5)Add "Mask" color to palette.
6)Put it below the regular Palette and above "Colors in use".

If the feature exists, I totally don't see it. And that's a whole other issue.


Apr 24 2020, 4:26 pm
In response to 2DExtremeProductions
That really should be a separate feature request post. I like your ideas there so if you put up a post it'll be a good reminder to me.
Apr 24 2020, 5:17 pm
I like throwing things at the wall first just in case the feature exists and I am unaware.


Will do.
Apr 24 2020, 10:44 pm
Wow
Would it suffice for these function return types to be enforced only during compile-time?
Apr 25 2020, 5:17 am
Love these possible changes coming in 514!