Bravo1 wrote:
The problem isn't that byond can't do it, the problem is that byond can't do it efficiently enough to warrant using it in the first place.
These distance calculations use next to nothing. Even spamming them in a loop, with sleep(0.1), at 60 FPS, for every tile within view(8) uses 0% world.cpu.

> Because the standard keys are usually exactly what you want.
When was the last time that you played a game where pressing up, then right, made you stop moving up and start moving right instead? I don't know if I can even think of a single non-BYOND example game with basic movement controls that function so poorly.

> You've seen yourself how built in calculations can trump any soft-code.
They usually do, but this is just basic math, and the difference in efficiency is usually negligible anyway.

> Just like Pixel movement right?
It wasn't coded badly, byond just couldn't process it well enough, which is why it suffers as a platform, it's because it can be custom coded, but the custom code runs so horribly that the only way to ever get anything to work properly is to get a built-in version of it made.
Pixel movement wasn't inefficient to create ourselves, it was just plagued with problems. Mainly related to animation. It was implemented for the same reason that this should be, because it is obviously superior, but if it is not built-in, then nobody is going to use it.
Falacy wrote:
Bravo1 wrote:
The problem isn't that byond can't do it, the problem is that byond can't do it efficiently enough to warrant using it in the first place.
These distance calculations use next to nothing. Even spamming them in a loop, at a 0.1 delay, at 60 FPS, for every tile within view(8) uses 0% CPU.


The problem with this is that most people don't have the kinds of CPUs to support it. A 3.2ghz dual core gets a maximum of 1.6ghz to use on byond since it's single threaded. Anyone with a dual core below 3Ghz or a quad core and up will see massive lag when it comes to lighting systems.

If they could make BYOND run multithreaded then this would indeed be a non-issue. Te problem is that most people who see byond go for byond because on the outside it looks like it's meant for computers that aren't too powerful, but in most cases it's the opposite as the lag is too much for one core. My game Tanx actually ran better on my 3.4ghz single core than it does on my 3.2ghz dual core, even though every other program runs vastly better on my 3.2.

As for the efficiency of lighting. If you do it the way you suggest, 9x9 area (view of 8) then you're calculating for a total of 81 runs. Then a 0.1 delay would run 100 times per second, however it rounds to the FPS/tick_lag so you're looking at 60fps regardless. So that's 4860 calculations per second. I agree that's very fast. Now what if you want more than one player? It's multiplied for every player with a dynamic lighting element. Ultimately, unless your lighting is dynamically generated but statically displayed, it will be slow. In order for the lighting to be dynamic it would have to update, at the very least, once everytime someone moves.

If you have four people moving constantly then they're each calling calculations, resulting in something along the lines of 16K+calculations per second. Not to mention if you were to add in dynamic shadowcasting, which would probably triple that figure.

I can understand lighting it for a small area or using it one at a time, that's fine, but this is mainly for lighting systems with the added bonus of making circular area calculations easier. The this is more meant for lighting and less for ease of use. Now, we could always just ask for a built in lighting system that works better than general opacity, however this solution alone could make lighting systems much faster. It's not that they're badly coded, it's just that they're so numerously called that a built in solution would drastically effect how quickly these procs are called when put into the range of 20K-100K calculations per second. This is of course under the instance that everyone has dynamic lighting and they're all moving simultaneously. For one player, yes, it works fine, for multiple? Not so much...
Bravo1 wrote:
A 3.2ghz dual core gets a maximum of 1.6ghz to use on byond since it's single threaded.
The ghz rating is not split between cores. If you have a 3.2ghz dual core processor, then you essentially have two 3.2ghz processors.

> If they could make BYOND run multithreaded then this would indeed be a non-issue.
It would help. I'm not sure if it would be a non-issue. Not everyone even has multicore processors, and even if they did, everything still has to be processed at some point. You also have to take into account all of the problems that multithreading would cause in the first place.

> As for the efficiency of lighting. If you do it the way you suggest, 9x9 area (view of 8) then you're calculating for a total of 81 runs.
A view of 8 is a 17x17 area. Which is 289 tiles. So 17,340 calls per second at 60 FPS.

> Ultimately, unless your lighting is dynamically generated but statically displayed, it will be slow. In order for the lighting to be dynamic it would have to update, at the very least, once everytime someone moves.
The usage comes from the basic systems for graphically updating the lighting itself, for the most part. Not from the system doing an additional distance calculation. Running a simple loop for graphical changes to everything in view every time you move is going to use up a hefty amount of world.cpu, regardless of an additional distance calculation.
Falacy wrote:
Bravo1 wrote:
A 3.2ghz dual core gets a maximum of 1.6ghz to use on byond since it's single threaded.
The ghz rating is not split between cores. If you have a 3.2ghz dual core processor, then you essentially have two 3.2ghz processors.

Then I'm befuddled as to why my single core ran better.. I mean it wasn't a bit better it was much better. Then again, that was an Intel CPU and this is an AMD, I guess it's just quality factor as I hear Intel CPUs handle their memory caches much more efficiently, or so I hear.

> If they could make BYOND run multithreaded then this would indeed be a non-issue.
It would help. I'm not sure if it would be a non-issue. Not everyone even has multicore processors, and even if they did, everything still has to be processed at some point. You also have to take into account all of the problems that multithreading would cause in the first place.

True, though I hear there are technologies which make developing an engine for multicore use much more simple.

> As for the efficiency of lighting. If you do it the way you suggest, 9x9 area (view of 8) then you're calculating for a total of 81 runs.
A view of 8 is a 17x17 area. Which is 289 tiles.

Yes, I ballsed that one up, so the actual processing factor is much higher in that case.

> Ultimately, unless your lighting is dynamically generated but statically displayed, it will be slow. In order for the lighting to be dynamic it would have to update, at the very least, once everytime someone moves.
The usage comes from the basic systems for graphically updating the lighting itself, for the most part. Not from the system doing an additional distance calculation. Running a simple loop for graphical changes to everything in view every time you move is going to use up a hefty amount of world.cpu, regardless of an additional distance calculation.

Then what should we be going after when confronting performance issues like this? The graphics handling?
Bravo1 wrote:
Then what should we be going after when confronting performance issues like this? The graphics handling?
I don't think it is so much a rendering issue (though there are some serious rendering issues when it comes to transparent graphics) as it is the process of how you update lighting. To do even a basic full-32x32-tile based lighting system; You have to acquire a list of every tile within light range using something like view(), which is basically looping through everything in range and adding it to a list. Another loop then sets a reference to every one of those tiles as something like L in for(var/L in view()), by type checking them. You then have to calculate the light level for each tile, which is presumably just some basic math. Then change the icon_state of the tile to match some pre-set lighting icon, assuming that you aren't using rgb() to dynamically change the alpha levels of the lighting, which would raise world.cpu even further. The new lighting graphics then have to be updated over the network for every player in range every time they change. Throwing an additional distance calculation in there would be the least of my concerns.
I'm agreeing with Falacy?

Falacy wrote:
Bravo1 wrote:
The problem isn't that byond can't do it, the problem is that byond can't do it efficiently enough to warrant using it in the first place.
These distance calculations use next to nothing. Even spamming them in a loop, with sleep(0.1), at 60 FPS, for every tile within view(8) uses 0% world.cpu.

If these simple calculations did lag, what would that mean for things that you'll always have to code, like attacks and enemy AI?

> Because the standard keys are usually exactly what you want.
When was the last time that you played a game where pressing up, then right, made you stop moving up and start moving right instead? I don't know if I can even think of a single non-BYOND example game with basic movement controls that function so poorly.

Not only that, but how often are the arrow keys (and "5" on the numpad) the only buttons a game used? BYOND games get by because they rely on verbs that people click, but a decent game would bind actions to keys instead.

> You've seen yourself how built in calculations can trump any soft-code.
They usually do, but this is just basic math, and the difference in efficiency is usually negligible anyway.

Decreasing the CPU time of a single proc to 10% of the original time doesn't necessarily mean that the game's overall CPU usage will drop to 10% of its original usage. You have to consider how frequently the proc is called and how much of the game's overall CPU time was spent in that proc to begin with. Having this proc built-in would improve performance, but odds are that this proc wasn't a bottleneck in the first place.

> Just like Pixel movement right?
It wasn't coded badly, byond just couldn't process it well enough, which is why it suffers as a platform, it's because it can be custom coded, but the custom code runs so horribly that the only way to ever get anything to work properly is to get a built-in version of it made.
Pixel movement wasn't inefficient to create ourselves, it was just plagued with problems. Mainly related to animation. It was implemented for the same reason that this should be, because it is obviously superior, but if it is not built-in, then nobody is going to use it.

I disagree there. More people will use this if it's built-in, but none of those people will use it in meaningful ways. If people aren't prepared to write code to extend what BYOND gives you, they're never going to make decent games. If BYOND gave you a complete game you could customize I'd agree, but BYOND gives you barely anything and you have to add a lot yourself to make a game.
Personally I haven't investigated the benefits of making these alterations to view() or get_sight(), but I'm upvoting this because having an euclidean distance mode for get_dist() is convenient and emphasizes the counterintuitive fact that get_dist isn't euclidean by default. Actually, it would be a good idea to branch off the get_dist() section of this request (or actually, just the part about euclidean distance, the other modes don't seem useful/intuitive enough) because that shouldn't be hard to implement and the staff are more likely to consider it.
Bump, with a reminder of what the additional calculations could provide:
Chebyshev (current BYOND)
Manhattan
Euclidean
Shifted
++
Page: 1 2 3