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...
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?
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.