Any chance of BYOND becoming "double-threaded"? in BYOND Discussion

ID:601226
 
Mar 29 2012, 10:32 pm
I understand that BYOND runs on a single thread out of simplicity, and because the core engine was built that way. However, will we ever have the option of utilizing a second thread?

I love this engine - I just would like to see a bit more power infused into it.
#1 Mar 29 2012, 10:38 pm
I really don't think it is needed at all...

We don't even have 3D capabilities.. and efficiently programmed games won't use much CPU
#2 Mar 29 2012, 11:36 pm
I think it would be great because I find that building a pixel based game that's decent in size will cause a lot of lag and I don't see why 3D mechanics seem to be the only justification for more power.

In the future I would like to see a lot more client sided and improved performance.
#3 Mar 30 2012, 3:16 am
If I recall, Lummox responded to this question before and the conclusion was that it would make DM a bit more complicated than it is now and that they like the current level of simplicity.

I'm not very tech-savvy and have a horrible memory so don't quote me on that.
#4 Mar 30 2012, 3:27 am
I thought I read something along those lines recently, as well; so I did a little searching and here is a quote from Lummox when he was replying to someone else who had asked if BYOND supported multi threading.

This has been discussed to death in the feature requests tracker, but in a word: No. Multithreading is impossible for many many reasons. It is theoretically possible to take advantage of multithreading for some stuff like icon operations, or sorting the graphics for drawing, but code execution can't be multithreaded. There would be no way to do so without not only modifying the language itself (so that users could activate the feature, because it absolutely positively could never be done on an automated basis), but also heavily modifying the internals to prevent thread collisions on the same objects and pointers, and to resolve deadlocks. Resolving deadlocks is a whole subset of issues unto itself.

For the full post, and the topic that it was posted in, just use this link. http://www.byond.com/ forum/?post=122390&page=9&hl=byond%20multi%20threaded#commen t634785
#5 Mar 30 2012, 5:25 am
Now if only they'll actually implement image operations on a second thread, I could make an Ultimate Jigsaw server.
#6 Mar 30 2012, 6:11 am
What's your use case for threading icon operations separately? How are you currently going about manipulating icons, are you using the results in variables etc?
#7 Mar 30 2012, 6:40 am
I don't see how doing icon operations in a second thread would help that much. If you're not using the result (ex: you're not doing something like if(icon.GetPixel(1,1) == "#something") after generating an icon) then the operation should be handled clientside. If you are using the result, you'll have to wait for the icon operations to complete. It'd look like this:

Single Thread
1. do some icon operations
2. do something with the result

Multi-threaded
Main Thread     Icon Processing Thread
                1. do some icon operations
2. do something
   with the result

If all icon operations are done in series the main thread has to wait for all of them to complete before it does anything else. What'd be beneficial is if you could have many threads to do icon operations in parallel, but then it becomes quite a specific feature.

Why don't you just split the image up into the puzzle piece icons, save the result as a .dmi, use that .dmi, and not do any icon operations at runtime?
#8 Mar 30 2012, 8:55 am
I'm not actually sure that multi-threading would help in my case, just anything to speed this bit up. I'm pretty sure that most of the puzzle generation can now be handled client-sided, if I work it right, but this is the bit used for outlining pieces, which I cannot figure a better way to do.

icon/proc/InnerOutline(color,bold,blending)
    if(!color || !findtext(color,"#")) color="#FFFFFF"
    if(!blending) blending=ICON_OVERLAY
    var{w;h;icon/i=new(src)}
    for(w=Width(), w>0, w--)
        for(h=Height(), h>0, h--)
            if(i.GetPixel(w,h) && ((bold && (!i.GetPixel(w-1,h-1)||!i.GetPixel(w+1,h-1)||!i.GetPixel(w-1,h+1)||!i.GetPixel(w+1,h+1))) || (!i.GetPixel(w-1,h)||!i.GetPixel(w+1,h)||!i.GetPixel(w,h-1)||!i.GetPixel(w,h+1))))
                DrawBox(color,w,h)

I figured that I could run GetPixel() and save all of the hits to a list and then run a second operation that runs DrawBox() and that should run it client-sided, EXCEPT that the amount of DrawBox()s potentially puts the call size too high for the imposed limit to actually send the information to the client.


I would not do what you suggest because that pretty much negates everything that I've accomplished with the puzzle generator. It would be playable, but it wouldn't use the features that I'm proud of.
#9 Mar 30 2012, 11:25 am
If you save the resulting .dmi you create, your game still uses the feature you're proud of.

I'm not sure if this would work better for outlining. If you make an all black version of the icon you're outlining (black where the original icon has a color, transparent where the original is transparent), make four copies of that, shift each one by a single pixel in each direction (up, down, left, right) and blend them as underlays on the original icon you'll get a black outline. It'd work best if you don't need to generate the black icons at runtime.
#10 Apr 16 2012, 4:16 pm
This may now be possible (though in a limited manner) by using the dmjava library and putting the code you want executed in a different thread in Java. This will only work for non-core components though, as the Java part can't talk to the client or do any of the BYOND-specific tasks the server can do (such as managing the map).
#11 Apr 16 2012, 6:41 pm
In response to Forum_account (#9)
It seems that I never actually responded to you, Forum_account. There are several reasons I cannot just output the pieces to a file. One, when you connect the pieces, the game combines the two pieces into a single icon. Two, the file-size would be much, much larger, as I could not reuse an image for multiple difficulties of puzzles. Three, this would disallow or at least further complicate a feature I've been meaning to add, which is user created puzzles.

Then we have the issue of the outlines, the method that you mentioned is one that I had used in the past, but it doesn't allow for any more complicated functions. Right now, I can outline and outline the inside of the icon, with differing boldness, as well as output just the outline to its own icon.

And now that it's mentioned, I have not worked on the game in such a long time that I wouldn't know what could be improved or where.