[angersock]

I've engaged specifically on the image formats--consider both GIF and XBM, for example, or WebM or whatever else. Do those show up frequently in games? Nope. Games have other things, like DDS and whatnot, but those are actually kind of designed for their use case (storing mipmaps, cubemaps, etc.), and game engine developers have the luxury of saying "We use this blessed format and anything else runs through our tools pipeline first to become this blessed format". Web browsers have no such luck.

The XML/HTML stuff I mentioned elsewhere is still the same: it's not just simple missing character stuff, it's dealing with old pages that are semantically (not syntactically) malformed and still rendering them properly. See also quirks mode.

By contrast, game engines have level and script formats that they support, with simpler document models, and they get to deprecate things whenever it suits the developers.

As for scripting, just look at some docs for the Morrowing stuff you bring up: http://www.quicenter.com/morrowind/files/Morrowind_Scripting.... That's hardly on the same class of utility as Javascript--it's basically a procedural wrapper for stepping through basic scripted sequences. And that's fine--it's built to do that and only that.

Every single game that permits custom levels that can include scripted elements fits this bill.

"Scripted elements" is very, very different from, say, loading an arbitrary IDE into the browser: http://repl.it/languages

On the average, most game scripting languages don't support running Ruby, Python, or Erlang interpreters.

[simoncion]

> I've engaged specifically on the image formats [and malformed documents]...

Yeah, you haven't. The comment which spawned your first statement was one that complained about rendering speed. Many people in this thread have noted that by the time an image or document (XML or otherwise) gets to the do-layout-and-render-pixels-on-the-screen stage of the process, it DOESN'T MATTER how malformed that document was or what format that image was when it came over the wire.

Why? Because when we're at this stage of the process, that data has been converted into whatever representation is most convenient for the web browser to use while rendering its screen. Just like in a video game, support for a new image type or document type is as "simple" as adding on a converter from $NEW_FORMAT to $BROWSER_INTERNAL_FORMAT.

> "Scripted elements" is very, very different from, say, loading an arbitrary IDE into the browser

No. It's a difference of size, not of complexity. The interpretation and validation tasks are the same in both examples.

> On the average, most game scripting languages don't support running Ruby, Python, or Erlang interpreters.

Heh. Nice of you to ignore my Crash Bandicoot, Jax & Daxter, and every-game-which-supports-lua-scripting examples. Lisp, Scheme, and Lua are every bit as complex as Ruby, Python, JavaScript and -to some degree- Erlang.

I've read your other replies in this thread. Your initial arguments are weak, and you continually choose to ignore evidence and assertions that contradict your initial argument. This is a real pity, because you're pretty well-written. If your behavior matched your tagline "Strong opinions, weakly held", you'd be far better off. :)

[angersock]

"It's a difference of size, not of complexity."

Again, no. "Scripted elements" is waaaay too broad, and includes elements for purely procedural work (move here, say these lines, move here, etc.).

Your example of Crash Bandicoot, by the way, isn't great--GOOL was compiled down into a form that shipped with the game. It wasn't dynamically compiled from external sources by the engine during runtime, unlike what we have to deal with with Javascript. Same criticism applies to Jak and Daxter with GOAL.

"Lisp, Scheme, and Lua are every bit as complex as Ruby, Python, JavaScript"

Scheme and Lua, certainly not--just compare their BNF grammars, much less their actual use. If by Lisp you mean Common Lisp, well, you have a point, but otherwise nope.

As for the rest, I don't ignore the assertions; it's just that the fine difference between "can support" and "must support" is apparently lost on most folks. Additionally, points on loading are all sidestepped by you folks ignoring that, as part of the browser, that flexible loading must happen, whereas in the engine you can assume the tools pipeline (you know, the 3DS plugins or whatever) have already done the work.

And then, for all that, people are still complaining about the platform of the browsers when all of there examples are of shitty and slow web apps running on it. It's like they've never seen badly-performing maps in a game engine, or a shitty Unity game which isn't optimized properly.

I'm trying to help educate folks here by clearing up misconceptions, but it's rather uphill.

[banachtarski]

Do you actually think it'd be hard to put GIF and XBM support in a commercial engine? I really wish you would stop commenting, and I also really wish I could ignore you, but given your last of experience, I'd appreciate it if you stopped talking out of your depth.

I'm not sure your last point makes sense to me. I can't run Ruby, Python, or Erlang in a web browser either.

[angersock]

but given your last of experience

s/last/lack

So, other than the annoyance of actual handling animating the GIF, I don't think that adding the image formats to a commercial engine would be that hard. Hell, I'd just link in FreeImage and be done with it. The point, though, is that a web browser pretty much has to support that, whereas a game engine doesn't. For any particular feature X that a browser has and an engine doesn't, sure, you could absolutely add that feature to the engine. Or just embed Awesomium and have a browser in your engine. Doing so, though, is more of "anything you can do we can do" argument instead of the issue at hand of "browsers are required to be more complicated than engines".

To explain my last point: both Python and Ruby there are available in interactive REPLs inside the browser, implemented in JS:

http://www.repl.it/languages/Ruby

http://www.repl.it/languages/Python3

Erlang has also been implemented in Javscript:

http://svahne.github.io/browserl/

The thing we keep disagreeing on is the basic premise that browsers are more complex than engines because they do more stuff, albeit less efficiently. Game engines, especially commercial ones like Unity or Source or whatever, are very nifty feats of engineering. I'm not disputing that. However, they aren't specified, they aren't standards conformant, they don't really have legacy stuff they have to put up with, they don't have security concerns in the same way browsers do, etc.

If you want to keep claiming that engines are more complicated than browsers, that's fine, but realize that that's a position far from settled. You have yet to, for example, answer any of the points about how much more complicated the operating and compliance environment of a browser codebase is.

[disusered]

Or PyPy, "compiled for the web via emscripten, with a custom JIT backend that emits asm.js code at runtime." http://pypyjs.org/

Or Windows 95 running in DOSBox compiled for web with empscripten http://win95.ajf.me/