HTML5 client

ID:1448752
 
Dec 20 2013, 3:44 am (Edited on Dec 20 2013, 4:05 am)
Something I've been working on and off on the past week, uses WebGL for rendering

Screenshots of it running against a /tg/station build:



Of course a whole crapload of things left to do such as:
* Gliding has some issues
* Currently no sound
* No transform support (color works, not too hard to fix)
* No animate support (flick() works)
* Doesnt garbage collect appearances (semi-easy, I'll fix that when I fix the renderer code, obligatory fix though)
* Moving when receiving browse_rsc requests disconnects you for some reason
* Occlusion isnt implemented yet (need to decide on an algorithm for it too)
* Dynamic resources are semi-broken (reasonably easy fix)
* No DDMI support (which is the main reason for dynamic icon breakage, total pain in the ass to fix)
* Verbs dont really work yet
* Clicking doesnt work
* Doesnt pay attention to invisbility/infrared values (probably an easy fix)
* Main loops need to be entirely rewritten as they're pretty much glued together test code never intended for actual use
* Need to write an interface file parser and code the rest of the controls
* Doesnt pay attention to preload_rsc
* Glitz flags arent entirely paid attention to, causes problems with pixel movement (should be a reasonably easy fix)

Other than all that, it pretty much works, and I got this down in less than a week
Dec 20 2013, 4:14 am
THIS is precisely what I've been talking about for ages, with regard to a proper cross-platform port.

Is this a thin client?

If not, I assume this uses your own version of BYOND's built-in VM using the information you gleaned from taking apart the DMB format?
Dec 20 2013, 4:35 am
Its a "thin" client, it doesnt implement any VM currently, implementing the BYOND VM is one of the messiest things you can ever do
Dec 20 2013, 5:21 am
Oh, this is interesting. Is this more of a proof of concept, or do you intend on expanding on it to be more feature complete?

I'd also be interested in learning more about how this was made. I've thought plenty about a similar project, but nothing has come out of it due to limited networking experience and not having much of an idea about BYOND's protocol. (I'm not sure if that would be something Tom or Lummox would willingly share, and I have not tried to ask.)
Dec 20 2013, 5:22 am
In response to TheLionsRoar
TheLionsRoar wrote:
Oh, this is interesting. Is this more of a proof of concept, or do you intend on expanding on it to be more feature complete?

I'd also be interested in learning more about how this was made. I've thought plenty about a similar project, but nothing has come out of it due to limited networking experience and not having much of an idea about BYOND's protocol. (I'm not sure if that would be something Tom or Lummox would willingly share, and I have not tried to ask.)

IDA Pro, Wireshark and a steady hand. Planning to make it reasonably feature complete. I'd guess they're not terribly willing to share considering a lot of it is obfasucated out the ass.
Dec 20 2013, 12:14 pm
First someone makes a DM decompiler and now you've got a custom web client? What madness will you geniuses come up with next? Amazing!

I fear the remaining little things may be quite time-consuming, but you are clearly well equipped to handle the task. I feel bad because, due to the long delayed Flash project, we actually have a much cleaner format to relay the client data, where the server manages the appearances and such, but it's not public. Well, looks like you got past that already anyway.

This does put us in a bind, though, since we do rely on our users using our own client for the ads and Membership incentive, and any third party client would cut that out. On the other hand, I'm enough of an engineer to appreciate this achievement and I'm not going to go out of my way to try to fight it; indeed, this is something I consider very valuable to BYOND. I guess if you get this in a reasonably complete state where it is a legitimate alternative to the existing client, we'll have to talk. I want to do what is best for the community but if we don't bring in anything, Lummox JR is out of work! That said, if third-parties can untangle our spaghetti code and build better versions of our own tools, the project should probably just go the way of open source anyway.

So that's my two cents. Color me impressed!

PS: the obfuscation we do is merely meant to block basic attempts by script kiddies to game the system since, unfortunately (due to some ill-though legacy design), some of the commands are still largely driven by the client. Ditto with the rsc encryption (which, being two-way, is obviously an intractable problem); it is just a simple barrier to halt the rampant cache icon stealing we had going on way back when.
Dec 20 2013, 12:20 pm
An adaption of the weak-ass stream cipher used by the networking to use the wang hashes used by the SCrypt algorithm would probably have been a better choice for the RSC encryption, its pretty darn weak as it stands

By the way, using CRC32 to uniquely identify resources is a really bad idea, that stuff should be upgraded to an MD5 at very least (Not to mention that the CRC32 implementation seems to be incorrect, which just makes the problem worse)
Dec 20 2013, 12:31 pm
Like I said, our encryption was only meant to be a basic barrier because the old cache files had no encryption and icon theft was apparently a big problem (since we got tons of complaints). As far as I know, this isn't an issue anymore so it did its job. Clearly since the algorithm has now been cracked, one could release an rsc extractor but since, AFAIK, you are the only one who has figured it out, I'll just hope you won't do that.

Yeah, the CRC32 is very legacy (although I wasn't aware it was broken). However, is it causing problems? The chance of a collision is still extremely small and would manifest itself with the wrong icon showing up. Maybe this happens once in a while but I don't think it's really screwing up any games.

Remember, when we wrote half this code we were hosting games on 486s over dialup; we didn't ever consider that one day BYOND would have games like SS13 whose codebase is almost the size of BYOND itself!
Dec 20 2013, 12:40 pm
If you were hosting it over 56k you'd think at the least the turf networking would be less suboptimal, currently a single turf change can result in a 29x29 region being resent (for a 15x15 view)

Not sure if the CRC32 is actually broken or if its some arcane byte order flipped version though, its generally just bad practice to use CRC for unique identification, I'm not actually sure if its causing any issues

As for what I'm going to do next, I feel a little burned out with this client, so I'll probably be messing around with a compiler for a while
Dec 20 2013, 12:45 pm
Well, if you notice issues, please report them in the Bug or Feature forums. I know it seems like we ignore a lot of stuff but we do keep track of things and try to get to them as time permits.

I agree that the CRC identification isn't bulletproof but if it isn't causing problems, it's just not really a big deal. There is a laundry list of stuff that IS causing problems that take priority lol.

Good luck with your future endeavors!
Dec 20 2013, 1:04 pm
In response to Tom
Tom wrote:
I agree that the CRC identification isn't bulletproof but if it isn't causing problems, it's just not really a big deal. There is a laundry list of stuff that IS causing problems that take priority lol.

This is the first time I've ever seen Tom say "lol".



Dec 20 2013, 1:33 pm
In response to Flysbad
Frame it and hang it on your wall. The moment will last longer that way.
Dec 20 2013, 3:07 pm
In response to Flysbad
I think it's the second time I've seen it.

This thread is pretty fascinating, though. I don't like the idea of open sourcing BYOND, so I always get eh when I hear those words together, but I do love to see progress like the kind this client could help lead to. Plus it's just generally interesting regardless of what's done with it, or whether it's completed.