Honestly, anybody that denies that the webclient is the most important thing that BYOND has ever done doesn't understand what the webclient really is.
It was in response to this.
I was just basically saying, wouldn't the most important part of BYOND be it's start, without it nothing else would matter.
It was in response to this. | |
Thanks for the technical breakdown, Ter. I consider myself a little more learned today. :p
I've honestly never tried making DM interact with anything other than itself, so I'm basically talking out of my ass. I just get really tired of people shittalking all of Lummox's hard work when the webclient is obviously such a huge step in the right direction. | |
I was just basically saying, wouldn't the most important part of BYOND be it's start, without it nothing else would matter. By that logic, the most important thing a person can do in their lives is be squeezed out of their mother. Does that sound logical to you? I've honestly never tried making DM interact with anything other than itself, so I'm basically talking out of my ass. I just get really tired of people shittalking all of Lummox's hard work when the webclient is obviously such a huge step in the right direction. There's a lot in terms of the webclient I'm not exactly happy with, but I will say that I understand Lummox and Tom's reasons for not tackling those problems. For instance, it unnecessarily complicates the development process in that not only do you have to be fluent in DM, but you have to be fluent in Dart, HTML, and CSS to really get a project off the ground. This is problematic because our existing developers struggle to learn DM, let alone Dart. On the other hand, why should a Dart/JS developer learn DM when he can just download a scenegraph API and networking API that's written in Dart already? By doing both, we're stuck in an ugly situation. Ideally, I'd like to see a DM to dart transcompiler and an open source basic client-side Dart API developed that would ease the transition. I'm also not fan of the way we currently hamfist interface elements into the engine via DMS. It's a pretty ugly solution, TBH, but it is at least a proof of concept. I do, again understand why things are coming together the way they are. Hopefully once things are open-sourced a little more some of the weight can be taken off of Lummox and Tom. Again, I don't want to come across as hyper-critical, but I really just can't wait until DS/DD/DM get open-sourced. I've got a DM language compiler that I wrote in C++ that can currently handle about 60% of the syntax BYOND uses (object tree definition, overrides, preprocesser instructions, and variable definition. It's missing the second pass, which is proc/verb parsing.), but I lack knowledge about the DMB file format to make it actually compile runnable binaries. I've also got a WebGL scenegraph and map renderer with batching techniques and whatnot that I wrote in pure javascript, which just needs a VM to drive it. Really, the only thing that BYOND does that I haven't done the research or taken the time to do myself is networking and a proper map editor. Though, honestly I'd much prefer to bootstrap the map editor in DM itself. I'd kill a man with my bare hands to get source access to BYOND's C source and start pushing revisions. | |
Sure, it's possible, but it'd be a lot more memory-intensive because it would all be done server-side instead of client-side... not to mention the fact that the most important thing they're undertaking, the load balancing using their cluster server system, would certainly not be possible without JavaScript afaik. I've used animate on a crap load of screen objects for stress testing. animate() is pretty good with handling a lot of objects. I don't think it'd be a big problem. Yes, you can mix animate() with JS (JS for a web version and animate for a DS version) and this will be better. But, just know that the webclient is still in a worse state than DS. That is, for games that are graphics-based. For some reason, rendering uses up a lot of CPU. I still need to get around to doing tests for that. @Ter13: I never realized. JS is used in my utility project for server file management. We just did everything through a browser with JS. By literally typing it out. It's good to know there are some interesting features like this just hidden... | |
No, the most important part of their life is being born not what they do with their life.
| |
Thanks for doing this for the community. It is really appreciated. Thank you.
| |
Ter13 wrote:
For instance, it unnecessarily complicates the development process in that not only do you have to be fluent in DM, but you have to be fluent in Dart, HTML, and CSS to really get a project off the ground. This is problematic because our existing developers struggle to learn DM, let alone Dart. On the other hand, why should a Dart/JS developer learn DM when he can just download a scenegraph API and networking API that's written in Dart already? By doing both, we're stuck in an ugly situation. Ideally, I'd like to see a DM to dart transcompiler and an open source basic client-side Dart API developed that would ease the transition. You don't actually have to know Dart or JS to develop a game for the webclient; you can leave all that alone and let the skin translator do the work for you. You only have to work with JS if you're planning to develop your own controls. | |
I guess it's a moot point, Lummox. I just don't envy you for having to design around an existing implementation, particularly when it's in such a fragile state.
| |
I believe the most important part of living is indeed, being born. After all, if you are not born, you do not live.
8^) | |
Aeon Catalyst is great in it's alpha stage. it's almost not an alpha because of how smoothly it runs
| |
Due to a glitch in the HTML rendering, I'm going to hold off on posting Within BYOND #13 until the problem is fixed (See the original post). A bug report has been made, and it will hopefully be fixed soon.
Sorry for (another) delay! | |
I've been wondering where the post has been. :P
| |
Actually, Lummox implemented Javascript interaction into the language a long time before the webclient. pretty much nobody uses it.
A framework for interacting with javascript from DM:
The javascript end of the framework:
The one downside to DreamSeeker's current javascript interaction model is that you need to manipulate GDI objects via client-side winset commands in order to make client-side interfaces really work. This means that without ugly hacks, you can't make a lot of things look as good as you could in the web client. HTML content can be overlayed on top of the map element in the web client, which allows you to do all sorts of impressive UI stuff that you couldn't even hope to do in DreamSeeker without using an unsupported and ugly hack:
The trick to acheiving this hack in DreamSeeker is using window transparency and javascript-initiated client-side winsets to anchor that window over the main map. Unfortunately, window transparency is completely broken on certain hardware configurations, and any time the client moves the game window, you need to detect that movement and update the position of the overlapped elements. This approach can get pretty ugly or necessitate a a constant loop checking the location of the anchored window.
Here's a video where I demonstrate the concept and/or rant about nothing:
http://youtu.be/7bhG96yrNdI
As for the rest of what you've said:
Memory's a non-issue with DM. If you hit 4 gigs of memory, you need to rethink what you are doing in the first place. CPU is the real bottleneck with DM. Because of the way BYOND doesn't use dirty-marking for the update loop, but rather checks every atom in view, screen, and images lists per player per frame for appearance changes, the more players you have on one server node, the more unprofiled CPU usage you have going on in the background. Unfortunately, I don't think this is ever going to be improved upon, and Lummox and Tom have little reason to do so because more tangible benefits can be achieved by the vast majority of projects around here by simply optimizing poorly written softcode than are likely to be gained by Lummox and Tom rewriting the entire map update loop.
Actually, javascript likely has nothing to do with it. I'm sure Doohl could confirm what they are actually doing, but there's absolutely no need to use javascript to manage any kind of server segmentation. It's more than likely that Doohl and WANO have some kind of a master server that communicates with the slave servers via World.Export/Topic. Link() would be used to transition a client from one server to another. --This would all be done without any javascript at all.
Again, the real advantage of this kind of an approach is that you gain access to more memory and more CPU. Since BYOND is 32 bit and (mostly) single core, you run into an upper limit on the amount of stuff you can do on a single server node. To get around this, splitting your gameworld up geographically and then again by instancing allows you to use a single 8-core, 8 gigabyte RAM server box (assuming you need a gig of ram max per node) for 8 separate server nodes.
This would work very well on a dynamic service like the Amazon cloud, where you can actually purchase server slices and use them on the fly.