view() that ignores lighting

Page: 1 2
Jun 2 2015, 2:48 pm
It all comes down to: Is it worthwhile for Lummox, the only developer working on BYOND, to take time away from other features to add this?

(The answer is 'no', by the way.)
Jun 7 2015, 6:01 pm
In response to Nadrew
Nadrew wrote:
Because there doesn't need to be a proc like this, it's trivial to do on your own and it being built-in wouldn't dramatically decrease overhead.

The solution given by tur is hacky, adds the creation of a mob and moving it to a proc that needs to be fast, (protip: assigning a mob's loc is not fast) and flat out wouldn't be allowed in most ss13 code bases under the no hacky code rule.

Jun 7 2015, 6:06 pm (Edited on Jun 7 2015, 9:23 pm)
It's definitely a hack.

I will say that it has no negatives, though. The mob is only used between frames. It should always revert to a null location between uses, so it won't interfere with anything else going on in your world (unless you are iterating through all mobs in world, which is a problem of its own).

It's certainly good enough to use in the meantime for what OP requested, and I'm fairly certain that in a normal use-case, it's going to outpace any alternative that can be cooked up speed-wise... So I'm not sure where the speed complaint comes from. I could be wrong, but this seems like it'll wind up being faster than writing this function manually.

EDIT:

I decided to test the comment you made about assigning a mob's location being slow.

mob
    step_size = 8
    var
        testvar = 1
    verb
        test1()
            for(var/count=1;count<=1000000;count++)
                m.loc = src.loc
                m.loc = null
        test2()
            for(var/count=1;count<=1000000;count++)
                m.testvar = src.testvar
                m.testvar = null


Interestingly enough, after a million operations, the outcome of these two operations are borderline identical.

A million iterations for each resulted in:

Test1: 0.459 Total CPU
Test2: 0.405 Total CPU

The difference we're talking about here seems to be roughly 5.4x10^-8 CPU seconds per iteration.

When we compare this by percentages, we actually see that changing a mob's location and then changing it back to null appears to have roughly a 13.3% increased overhead over doing the same thing with any other variable.

Now, there may be something that's going on behind the scenes that could potentially be messing with my numbers. If we take and assign a bunch of objects to a turf's contents manually, at certain points I believe the contents list has to be recreated with a new length greater than what the current contents require. This is done periodically, and not every time an object is added. The potential length typically doubles at each point in a dynamic list implementation like this, so it's a progressive algorithm.

Then again, that may not at all be the case. Who knows? I mean, given a million operations my example function performs around 20 seconds, while a blank view() would perform roughly around 13 seconds. Let's examine where this extra time comes from:

Invocation overhead: ~0.805
Syncing mob hack location: ~0.491
Testing Center object type: ~0.695
Testing for Center existence: ~0.175
Setting see_in_dark: ~0.021
arg access: ~1.1
global acces: ~2.8
Calling view(): ~12.8
Assigning ret: ~0.1


Still a hack, though. There's no changing that. It's certainly not ideal.

Perhaps a better solution would be something along these lines:

var
    __restore
proc
    view2(Dist=5,mob/Center)
        __restore = Center.see_in_dark
        Center.see_in_dark = Dist
        . = view(Dist,Center)
        Center.see_in_dark = __restore


However, that really only brings us down to 16.5 CPU, and 16.7 if we avoid the global variable in favor of a local variable definition:

proc
    view2(Dist=5,mob/Center)
        var/__restore = Center.see_in_dark
        Center.see_in_dark = Dist
        . = view(Dist,Center)
        Center.see_in_dark = __restore


Then there's the issue that this func now only works on mobs, unlike the hacky version, which can be used for any perspective, even a turf.

So yeah... Overall, we're looking at a hack, but IMO, it's something that takes tens of thousands of calls per frame to have any kind of effect on anything. Seems kind of nitpicky to me to be worried about the speed of something that's 6-7 orders of magnitude below a single significant figure.

I mean, if anybody's got any better information or contradictions to this, I'm completely game to listen/banter.
Jun 7 2015, 6:22 pm (Edited on Jun 7 2015, 6:29 pm)
What about range? I haven't tested, but I would expect this to be what you're looking for.

If this wouldn't work, the less hacky alternative would be to use block and cycle through the returned turf contents.
Jun 7 2015, 6:42 pm
If this wouldn't work, the less hacky alternative would be to use block and cycle through the returned turf contents.

The reason I used the hack was because that way's pretty slow.

Sometimes hacks can be good, but are generally indicative of a missing feature. I agreed with OP in this thread that something like this would be useful, but adding to the existing functionality of view(), I think would be nice. For instance, allowing us to pass variables into the function to override the default view capabilities of the object as optional arguments rather than a whole new function, but that's just me.
Jun 7 2015, 7:31 pm
If view allowed changing the different vision flags in the arguments that would be simply wonderful
Jun 7 2015, 7:40 pm
http://www.byond.com/forum/?post=1868155

Lummox/Nadrew tend to respond more reliably to feature requests when the "how it works" bit is a little more fleshed out and they are given a good reason as to what it could be used for.

If OP wants credit for the feature request, he can post a duplicate and I'll gladly delete mine.
Jun 10 2015, 4:37 pm
This hack doesn't cut it, I added a version that even used global vars (seriously, deletions and creations at that level are just KILLING BYOND), and guess what's 10 % of the cost of the new lighting engine I required this for?
This hack.

(oh, and it's not exactly a very well optimized engine either (working on that))
Page: 1 2