IE7, actually; nobody supports IE6 anymore, not even us.

To be honest I'm really not big on distributing the Chrome framework with BYOND--it's incredibly bulky. However unless we can be sure it would offer the same degree of hook support we get from IE's embedded browser, that's moot anyway. It's vital that we be able to intercept links, interact with JavaScript, and prevent Java from loading, along with preventing unnecessary message popups and other such stuff. I don't know enough about it to say. What I do know is it'd be a bit of a project to convert everything over even if it does support everything we need, and it'd be especially annoying to re-test the pager code in a new environment. (In theory it may all work fine. In practice I don't know. Chrome also has an annoying, longstanding bug with vertical-align that's likely to rear up all over the pager.)

This has my vote.
An embedded browser would definitely increase the appeal of the software IMHO.
It would also be a nice step in making BYOND portable to other platforms. Sacrificing a few megabytes in program size for potential portability would be a very acceptable tradeoff for me.

I won't even start on IE's borked render-engine, that's just a minor issue; who is using it for full-blown webcontent anyway.
But to get away from the security issues, that'd be a boon. Every time that beast opens a webpage I feel very vulnerable.
(Needs just one blackhat server running a 'game' that redirects ingame pages through sniffing/hijacking URLs in your client, that thing isn't sandboxed after all.)

A portable client could obsolete a Flash client - much nicer to get the full power of the native app. From a developer standpoint, that'd also save big time on maintaining another, totally different codebase (flash).

Also don't underestimate the possibilities that could be gained from an embedded browser. Besides a sandboxed environment, things could be configurable to a greater extent than the "wimpy" IE integration currently allows. (Although I like the current system.)

With that embedded thing in hand, you could forget Flash completely and possibly build an asm.js client instead. There is also future in that, for completely webbased MUDs.
Likely much faster to get running, too, as it can be cross-compiled from native c/c++ apps: https://github.com/kripken/emscripten/wiki (see, it runs UnrealEngine3... in your [FF22+] browser)

--

So then there'd be the question of what engine to embed. Currently the best bets seem to be WebKit or Chromium --modified WebKit. WebKit has a big 'embedded clientbase', therefore is well proven and likely has most ressources and codebase to be found. Chromium with CEF (chromiumembedded) seems to be upcoming competitor with greater unity between platforms.

Some quick examples for embedded browsers (with free sauce):
- LuaKit, a Lua browser with webkitgtk+ bindings.
- Desurium, Desura's client, using CEF
- QtWebKit for webkit with Qt bindings
- Berkelium does offscreen-rendering. (Not applicable, as BYOND is not an OpenGL/DX app, but for the source) C++ bindings for chromium
- there's also Webkit.NET (C# bindings) ...and many more

Hope this gets more votes, thanks for reading, and here's to BYOND5.0 running on Linux... eventually ;)
[p.s. don't start with f#%k'n WINE, please]

Ter13 wrote:

They are talking about switching the built-in browser that DreamSeeker uses to Chrome, not building a portable DS. Those are wholly separate ideas.

Indeed. I was merely adding this as one (important, IMHO) bullet point to take into consideration when voting about this issue. (And my P.S. was because the next reply after mentioning Linux usually reads "just go and use WINE, duh!".)

Nethack wrote:

potential portability

Ter13 wrote:

BYOND is actually currently a DirectX application. I think Lummox might be rewriting it in OpenGL right now, though.

Okay, I didn't know that. Thanks for the info.
But I would think this only applies to the client.screen window and offscreen-rendering a browser view there is still not relevant? It's more something you might want in a fullscreen 3D context.

(Though if the client is now utilizing DX and might become OpenGL, that'd be more awesome news for potential portability. Btw, both changes would also improve WINE useability already. BIG hugs.)

Ter13 wrote:

But I would think this only applies to the client.screen window and offscreen-rendering a browser view there is still not relevant? It's more something you might want in a fullscreen 3D context.

None of this is relevant, or makes any sense.

Though if the client is now utilizing DX and might become OpenGL, that'd be more awesome news for potential portability.

Not necessarily. The majority of the BYOND application is using, I believe GDI, to perform window handling and client messaging. A LOT of stuff would have to change before the client was in any sense portable. We'd more than likely have to swap to something like GTK.

Then there's the challenge of swapping the networking library over, because *NUX variants use different byte notation than windows for sockets.

There are a ton of considerations to make for going truly portable, and the project will be about four times harder to maintain and troubleshoot. You can see that Lummox's reasons for largely ignoring client portability for such a tiny chunk of the gamer demographic are more than just simple laziness/indifference.

I'm sorry but that was the dumbest and most uneducated post I've read this month

Also the libbyond.so that comes with the Linux server actually has client code in it too, just not used

Ignoring the utter bollocks you spewed about networking, since the renderer is OpenGL now(?), all porting that would actually have to be done is the window system, in which case GTK is the worst solution anyways

E: Also GDI is a goddamn rendering library, I believe they're using standard W32 windows, only the software render uses GDI anyways

Don't forget about Gecko: https://developer.mozilla.org/en-US/docs/Mozilla/Gecko

Gecko didn't work out. I suspect Chromium will be a lot better, but I've already mentioned the issues that stand in the way of implementing it. To sum up: 1) Iffy about distributing such a huge binary. 2) Retesting the entire pager isn't so tempting. 3) Not sure if CEF can do what IE can in terms of interaction.

Networking doesn't pose a portability problem, but the frontend interface does. That problem got a lot more complex as of BYOND 4.0. Also since I don't use Linux, this would be rather difficult to develop and test. And given my experiences with programs that use GTK, I'd probably gnaw off my arm before I considered that toolkit.

OpenGL is not the current rendering engine. We are still using DirectX (hardware) and GDI (software). I ran into several snags that were delaying 500 too much. I may well revisit this soon, but I was pretty amazed by how Google-proof the vast majority of my problems were. The worst problem I ran into, which finally convinced me to stick with DX for the time being, was that on occasion with a large map (I suspect over 512x512) DS's performance would suddenly get astronomically worse; this was unpredictable when it happened and also difficult to diagnose. Maybe there was some kind of error code I should have been catching, but Google was surprisingly unhelpful.

If you need any assistance with OpenGL you can probably just page me, it sounds like you're using immediate mode (glBegin/glEnd), which is depracated and can cause that kind of issues

Immediate mode pretty much dynamicaly slaps everything into a vertex array, if you go beyond the size of that reallocated array, you'll cripple the performance badly

I had similar issues with openGL where drawing vertex arrays worked fine, unless the "camera" was oriented close to a specific way and positioned very near (0, 0, 0).