Falacy wrote:

Even Minecraft can easily run at several hundred frames per second, and trust me, its far more complex than anything on BYOND.

The reason BYOND's framerate is limited is because the client's refresh rate is tied to the server's ticks and the server is responsible for processing events for all clients. Dreamseeker can render the screen more than 100 times per second, but the server can't process all events for all clients 100 times per second.

In Minecraft, the client renders the screen (and likely manages its own movement) independent of the server. When I mentioned the option of BYOND having each client be responsible for its own movement (which is the benefit of Minecraft's design you are describing here), you said:

"Open client sided processing would cause so many other problems, complicate the language, and offer so few benefits that its hardly a feasible solution, especially for this specific feature. In vast majority of cases, it would actually offer far worse "performance" due to the networking requirements alone."

Minecraft is good because the client has more responsibilities, but making the BYOND client responsible for the same things would have "so few benefits" and not be "a feasible solution". I do agree that having the client handle movement isn't the way to go (though it'd work) because BYOND's benefit is that the server handles everything. It's because of that simplification that making a BYOND game is so easy, but there are obvious performance drawbacks.

Forum_account wrote:

The reason BYOND's framerate is limited is because the client's refresh rate is tied to the server's ticks and the server is responsible for processing events for all clients. Dreamseeker can render the screen more than 100 times per second, but the server can't process all events for all clients 100 times per second.

You seem to somehow be going under the assumption that processing in these other games isn't tied to the rendering frame rate? I can't speak for Minecraft's, but I know that for Unity that is the case. Each frame, the main Update function(s) you have setup are processed, the GUI is reprocessed, and all cameras are re-rendered, etc.

Minecraft is good because the client has more responsibilities, but making the BYOND client responsible for the same things would have "so few benefits" and not be "a feasible solution".

Until recently, Minecraft's multiplayer was quite fail compared to its single player, for a lot of the over complication reasons by comparison. It also runs 10s of times faster, and most likely has some competent network pre-processing, which I doubt client sided BYOND games would have - leading to a spam of already overwhelmed network traffic (more inbound than out, though), decreased performance, and even laggier games - especially on poor connections.

Forum_account wrote:

In BYOND, the server handles everything. In other games, the client program often has more responsibilities and can more fully respond to input. In these other games, each client's screen refresh rate is bound to the rate that it processes other things

Again, that isn't the case with Unity

When you distribute the processing across all clients you'll get better performance. This isn't a "fail" on BYOND's part, this is the reason why BYOND games are easy to develop.

You won't necessarily get better performance, or more like smoother gameplay. And though it does make it easier to develop BYOND games because the server is automatically forced to handle everything, they could just as easily automatically offload processing onto clients - like they now do with icon operations.

Forgive me if I expect a 3.6ghz computer to be able to handle 20+ mobs at 30 fps.

I can play Crysis 2 on this comp, but 20+ players at 30fps with pixel movement? I must be insane.

1.Forum_Account Wrote:

Having games run at 10 fps has spoiled you! No matter what we're talking about (pixel movement, AI, pathing, attacks, special effects, etc.), you'll find that you can get away with a lot when the game runs at 10 fps. When you want the game to run at a decent framerate, performance becomes more and more of an issue.

You were the one who told me not to expect good performance at 30fps and 20+ players with this system.

2. My GPU doesn't calculate the games physics, guidelines, control input, math, positioning, etc. It only processes and displays the results of what I see in the game. Much in the same way the server handles the cacluations and dreamseeker displays the results while also processing icon procs.

Yes, the brunt is being handled by the GPU, but the in-game physics are much more advanced than pixel_movement with 20+ players, bit it still runs smoothly, and both are being handled by the CPU.

3. You can have easy development and viable performance in the same field, it depends on the engine. Currently, Byond isn't that amazing of an engine, it needs to go through a lot of reform and updates.

The problem is: instead of working on updating byond to become a better development tool, they're arguing semantics.

The only reasons you shouldn't include a feature in a system is. A: redundancy, or B: incapability.

Byond can capably support a built in pixel based movement system.

Byond supporting a pixel based system would not be redundant, as the only current pixel based systems are soft-coded, and, as a result, are not viable as a permanent solution to the issue.


Let's say I want to get a bigger hard drive, from 160gb to 200gb. You're telling me I shouldn't because you have a 20gb flash drive that I could leave plugged in to my comp. That's fine and dandy, but transfer speeds and reliability with a 200 drive would be much higher, even though I'd have to take the time to transfer over all the data on my current hard drive.

And upgrade is always better than an add-on, whether or not it's a simpler task.

Bravo1 wrote:

Forgive me if I expect a 3.6ghz computer to be able to handle 20+ mobs at 30 fps.

I can play Crysis 2 on this comp, but 20+ players at 30fps with pixel movement? I must be insane.

You're comparing apples and oranges. Crysis 2 is pretty CPU-intensive but more than that it's GPU-intensive. Most of the work is not being done by your main processor. Even to the extent it is, Crysis is surely multithreaded and designed to take advantage of multiple cores. When you get right down to it, all the CPU has to do is handle AI, collisions, and so on, and possibly a physics engine.

BYOND servers run under a completely different architecture. The engine is single-threaded and this is for many reasons--some of it simplifies issues that would hugely complicate the engine, and other parts simplify the DM language.

You're falling into the "man on the moon" fallacy, which is that people like to say "If we can put a man on the moon, why can't we ____?" The answer is, simply, putting a man on the moon was a straightforward engineering problem with straightforward solutions, and the only thing holding it back was the need to throw gobs and gobs of money at it. Other major challenges are often never so simple.

On the other hand, if gobs and gobs of money were thrown at us we'd probably take a stab at multithreading.

Forum_account wrote:

Lummox JR wrote:

Multi-core processing won't be feasible except for internal operations that can run in parallel. That basically means stuff like icon operations, which we now offload to the client as much as possible. To parallelize that kind of thing though we'd still need to basically have a setup where the processing could split up but the main thread waited until all the workers were ready. Anything like allocations, deallocations, and interpreting code still has to be done single-threaded.
There's probably a better place to discuss this, but I'm curious to hear why this is the case. Interpreting code would seem like an ideal candidate for parallel processing - BYOND already has the idea of separate threads of execution, they're just not processed that way. If two players are moving in separate parts of the world, their calls to Move (and whatever other procs are called) are reading and modifying completely independent sets of variables. You can do them in parallel with no consequence.

Here's the rub: How do you tell the two procs can run without disturbing each other?

I've given this a lot of thought and I just don't see a feasible way around the single-threading. Quite aside from the fact that it'd require some significant changes in the engine to handle a multithreaded model at all, the problem of objects interfering with each other isn't soluble without author-controlled mutexes and semaphores.

As a simple example: Say I tried to automate this so I could just run procs willy-nilly and if one accessed a mob or something it would just lock it down. Proc A is working with mob X, and proc B is working with mob Y. Say X.bestfriend==Y. If proc A needs to make a change to X.bestfriend.group, it needs to lock down Y too. Obviously whichever proc got to Y first should get a lock on it, but this can result in deadlock. The only way to avoid deadlock is if proc A, which ran just barely first, got the lock on X and Y together, which it could do by looking at all of X's vars. Obviously though it would also have to look at all of Y's vars too, and so on. This could be limited only to the vars used in the proc, conceivably, but this automated mutex could get ugly really fast. Calls to other procs have to be handled too.

But not everything can even be handled that way, because you also need to account for locate(), which can pick up objects by reference. You need to account for vars[], which would be mutex-proof. get_step() has the same issue, at least if it's used in a loop. (In fact pretty much any var access in a loop is problematic.) Any proc using things like that would need a full lock. Even then I'm not sure deadlock is 100% avoidable. Doing any kind of locking, even very simple locking, can cause unexpected problems.

The only real way to make this work would be to add some complications to the language, and to the code underlying it, to allow code to run in parallel at the user's discretion and let them setup their own locks. The engine however would need a lot of work under the hood to make this possible, because right now if an object is deleted it can just be deleted outright, but now it would have to be deleted while no other parallel procs were running. This impacts not just refcount deletions but also the del() proc, because the latter actually has to search for references and null them out; in its place we would need some means of checking if a reference was still valid pending proper deletion. Also under the hood we would need to treat any object allocations and deallocations as critical sections.

Lummox JR wrote:

Here's the rub: How do you tell the two procs can run without disturbing each other?
I've given this a lot of thought and I just don't see a feasible way around the single-threading. Quite aside from the fact that it'd require some significant changes in the engine to handle a multithreaded model at all, the problem of objects interfering with each other isn't soluble without author-controlled mutexes and semaphores.

I'm not sure how well this would work, but here's my guess:

You split tasks up and run them in parallel (each event from a client, "player one called the North command", would be a separate thread). Each separate thread is reading and modifying vars, but the changes aren't permanent - you have them written to scratch space. When the processing is done, you look to see which threads have accessed the same vars. If one thread wrote to a var and another thread read it, you might have a problem (because if the events occurred in a different order you may have gotten a different result).

When you detect a problem like this you simply disregard the work done by the second thread. This is why changes were written to scratch space. If a thread reads vars that nobody else wrote to, there's no conflict and the changes are committed.

The worst case is that you split up the work, do it in parallel, then discover that everything conflicts and you have to do things sequentially. You could have a master thread whose work wouldn't be thrown away, so you wouldn't have to do everything over again. Because the work is distributed you'll find this out more quickly. Any time that was wasted was wasted by CPU cores that would have otherwise been idle.

The idea is that sometimes the overhead will outweigh the benefit, but more often that won't be the case. If you have a bunch of enemies running simple AI loops and moving around, unless two enemies try to move to the same tile there won't be any conflicts (separate threads can both read the same var, you only get a problem when there's some writing going on) and the work can all be done in parallel.

It wouldn't envy the person who tries to implement this, but it does seem like there's some potential to get something that is effective and transparent to the developer.

Lummox JR wrote:

The scratch idea is interesting, but I don't really see how it could be done. Everything would have to be modified into a more virtualized form where all reading and writing took place at a higher level.

When the interpreter needs to read a variable, it checks the scratch space first. If it's there, it takes that value. If it's not there, it loads it from the global set of values. When the interpreter writes to a variable it writes to its scratch space.

This'll take up more memory because you have to store all of these scratch spaces before the changes are all committed. You'd also need to make the necessary adjustments just to get things working this way. It shouldn't be that monumental of a change, but I wouldn't be surprised if the .dmb interpreter is rarely touched and is quite a mess.

making major changes to allocations and other such internals, and adding language features to let users control threading.

This just lets DM developers create a lot of situations that aren't fun to debug. An internal solution could be transparent to the DM developer and robustly execute independent code in parallel so there's no chance for race conditions.

My biggest concern is that it'd be hard to tell what code segments are independent, or that you'd end up having very few independent segments.

To check for dependencies between segments you need to look at what vars each thread read from and wrote to. This is fairly straightforward, but with a lot of vars it might prove to be time-consuming.

The way I described it, if you have two threads of execution (called A and B), and A writes to a global var and B reads that same global var, the outcome of B may depend on the order. The value of the global var at the time that B reads it depends on whether or not A happened first. If you assume all of these situations are dependent code segments and must be run sequentially, this code would allow for no movement to be processed in parallel:



Because every thread that runs Move() will be reading and writing the same global variable.

Bravo1 wrote:

The issue is that the second worker might place his work ahead of the first worker even though the first workers result should go first.

Not only that, but the work done by one worker might depend on the work being done by another worker. It actually changes the work that's done.



You can't pre-process thread B and sort the results out later because the result of B depends on whether or not A was executed first.