Written both. Not sure why it needs to be deferred rendering specifically lol. A forward renderer (or a light deferred, or tiled deferred, or forward plus, etc) would easily prove the same point.
The precompiled logic thing is nonsense. This happens on the fly in games too. Shaders get compiled on the device, assets streamed in from disk or the network. Game behavior is typically scripted and patched, etc. Narrow selection of hardware? 10 years ago? Wrong. I work on a game engine that fully supports a 10 year old machine, and most state of the art engines can degrade to that level too.
Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves.
The game can scale to a mobile device believe or not. It just doesn't make sense to. Throttling draw calls or streaming only the lowest mip levels is trivial for a good engine.
The web is absolutely 100% less efficient than a commercial game engine and does far far less. The flip side is that the barrier to entry is way lower as well. It takes less experience to write a web app than it takes to author a game. I would argue that authoring a web renderer is easier than authoring a state of the art game renderer too, although there are certainly complexities there. The DOM scene graph compared to a game scene graph? Come on, is there even a comparison? I could dump a scene graph for you which is totally dynamically generated in real time that dwarfs the most complicated web page you could find. I mean, heck, we use BVHs, KD trees, octrees, and more to represent our scene graphs. You think the DOM has even a fraction of that complexity?
Too quote you, "seriously, just stop for a second and use your head."
"The web is absolutely 100% less efficient than a commercial game engine and does far far less"
I think you underestimate how much work web browsers are doing. The browser rendering engine lays out and renders thousands of character glyphs out of arbitrary vector typefaces (they might even have been downloaded over the network at runtime) at subpixel resolution, compositing over arbitrary backgrounds, keeping track of their precise location on the screen so you can, for example, select a chunk of text and copy it.
That's the equivalent level to the pixel-level shenanigans in a game engine. HTML and CSS descriptions of a webpage, with all its embedded images, are the equivalent of a complete description of a level's geometry and textures being loaded into a game. And most games, let's be honest, spend a lot of time displaying a 'Loading please wait' graphic while they pull all of that content into RAM and prepare it for rendering.
In graphics, everything is done at subpixel resolution. We also have to handle text and the aliasing that occurs not just from screen resolution downsampling but projective aliasing as well for text that is not camera facing or text that is wrapped on a surface. Keeping track of text on a screen is, to put it simply, not hard. There's a lot more state to a level's geometry and textures than just position. Momentum, for one thing, but tint, wind, pathing, any other behaviors, key frames, etc. Some of the meshes get skinned or dynamically deformed if its cloth or hair. Some meshes get generated on the fly. Still others move according to a script or analytic equation like particle quads. Not to mention audio that may be keyed per item and the physics tick.
The loading is sometimes more than just pulling stuff from RAM. Decompression, shader compilation, and more. Maybe textures are created dynamically or the level is randomly generated (terrain, creatures, and all). Usually, loading is full threaded and all reading happens asynchronously. Depending on whether you're on a console or not, different optimizations happen since the disk drives have different buffered reading characteristics.
I've read plenty of stuff on web browser tech and architecture, particularly because I've been following the Servo project with some interest. I'm not saying it isn't a lot of work (it's a lot of work, like anything worth doing), but I do think it's easier than you're making it out to be.
> Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves.
This is the crux of why you're wrong. You get to /choose/ which formats you use and support. You can completely avoid any and all of those, if you like, just by limited your asset support. The web? It has to support all of it's cruft, at all times. It's not optional.
Gosh, and that's ... hard? Image processing and compression is the easiest type of problem to solve. The algorithms are well documented and available.
Also, for your benefit, the formats listed all have different usages, and encode the different channels with varying precisions. They also have different compression artifacts and perform better or worse using different samplers.
I'll stick with my precompiled logic assertion. How many AAA games ship with a fully dynamic language like JS? Of those, how many then expose low-level APIs to those languages instead of just an operating environment suitable only for scripting? At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox?
As for "goofy image formats"--I'm going to be somewhat surprised if you aren't doing a preprocessing step to normalize your textures and images into either an atlas or at least some standard format (with texture compression or whatnot). I know that across the entire space of game engines there are bajillions of formats, but again, when you're building a custom engine for a game, I'm willing to bet that you can pick your battles in ways that browsers simply can't.
The "malformed XML" isn't a simple matter of just "Oh, a missing closing tag!". It's "quirks" mode. It's supporting weird old behavior, bug-for-bug, across browser versions (thank you Microsoft).
"The web is absolutely 100% less efficient than a commercial game engine and does far far less."
See, from a performance standpoint, I wouldn't hesitate to agree that the web engines are less efficient. Similarly, I wouldn't claim that a gas turbine is less efficient than piston engine. However, piston engines are a lot more common because they're more flexible, easier to make, and can put up with a lot more nonsense.
You lost me, though, when you said that the web does "far far less" than the specialized work a game engine does.
You're absolutely right--there's no comparison. Show me a modern game engine whose rendering pipeline is one tenth as complicated or well-specified!
Sure, bang around about your scene-management structures for visibility tests. I'm sure that'll impress your friend at GDC who similarly rediscovering techniques already mined out twenty years ago--better than thirty in the case of octress.
At the end of the day, game engines (from a display standpoint), are just rendering lots of triangles, with optional intermediary targets clever shading tricks. There may be some animation, there may be some physics, but all of that is relatively straightforward in implementation compared with the downright byzantine rules for, say, CSS:
I'm not saying that game engines aren't impressive feats of engineering--they are in no way, however, near as complicated from anything other than a technical perspective when compared with a modern web browser.
> How many AAA games ship with a fully dynamic language like JS?
Every single game that lets you use Lua to write game logic? AIUI, every Elder Scrolls game since Morrowind? The Crash Bandicoot games? The Jax and Daxter games? (The Jax and Daxter games use http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp and the Crash Bandicoot games use its predecessor.)
> At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox?
Every single game that permits custom levels that can include scripted elements fits this bill. See, though, this is a strawman. Almost every competently designed website is just like a AAA game in that all of the code that that site runs and all of the assets that it loads were explicitly selected by the dev team and tested by its QA team. Moreover, any user-supplied data is carefully handled and constrained so that processing of said data is low-impact and non-disruptive; just like in a AAA game.
I also note that you're refusing to engage with folks who call you out on the fact that your argument that "Having to handle a wide array of obscure image formats and potentially invalid XML makes page renders and reflows slow!" is bunk.
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.
> 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. :)
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.
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.
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:
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.
Preprocessing sure. But the different formats are necessary. Depending on the data in the texture, the compression algorithm may alter the data in a way that behaves better or worse (for example, textures representing normals vs material vs albedo).
Before I discuss rendering with you, can you first disclose your experience with game engines or rendering? It's sort of pointless to go into that discussion unless you understand how things have changed in the last 5-10 years or so.
edit:
Forgot to mention that shipping with a scripting engine is sort of easy. It's just a matter of whether it's exposed to the customer or not. Tons of games (even decade old ones) have shipped with turing complete editors for modding or making custom levels or what have you. I've written a custom VM for a homebrew project that can do precisely this.
Sure. Started out with some school projects that were beautiful object-oriented single-thread vistor-pattern for rendering in fixed-function OpenGL. This predictably led to terrible performance. At the end of school, friend and I decided to extract that code and try to build a real engine around it.
Upgraded to thread-safe rendering in OpenGL, one thread handling rendering and windowing tasks, other threads game logic and submitting draw requests, and ultimately other threads handling resource loading onto the GPU (though that came later towards the end).
Upgraded that to actually use the programmable pipeline, and finally added support for FBOs and uniforms and buffers and everything so we could actually start on deferred rendering as outlined in Engel's blog and other places. Never did transparency, but if I remember correctly the goal was to probably do something like screen-door+deferred. For the life of me I can't remember the paper we were looking at.
Eventual goal was to do full deferred lighting and PBR, but by that point I'd moved over to web development. Every time I went back to that codebase, clean and organized as it was, it was just such a pain in the ass to do anything compared to splatting some JS and Three onto the screen and being done with it.
Concurrent with that, I was doing 3D CAD software development in Java with Ardor3D. So, big annoying retained-mode scenegraph with all the BVH nonsense you could ever want, and a bunch of legacy files for things that, when one rendered a building all at once, would kill the graphics card. And don't even get me started on trying to sort out order-independent transparency for that...one of my great failures.
By contrast, nowadays I do multiple web workers with websockets to provide 30-60 fps display of waveform data on just bare 2D canvases, with Angular wrapping the components.
EDIT:
I'm aware of the scripting thing. Note that, until perhaps FarCry, it was pretty well held that scripting languages were "too slow" for most games, nevermind the success of such things as JIT Quake 1 bytecode, or the stuff in Out Of This World, or what have you. Even UnrealScript was considered godawful dog slow and to be avoided if possible, and was finally shown the door. But, in the end, scripting was discovered not to be the super worst thing ever.
I think Eve finally hammered that point home to everyone.
The scripting languages we have now have come a long way in terms of ease of embedding, with a possible exception for Lua, which has been easy as hell for a while now.
Then again, I don't think that many scripting languages have the sheer size of interface with native code that, say, JS in the browser does.
It's a shame you didn't continue. Where you left off (prior to deferred ... shading I'm assuming and PBR) is still a bit a ways from where things get a bit more interesting. Physically correct rendering changes the game a good deal. We can't haphazardly blur textures and add things and lerp like we used to.
The precompiled logic thing is nonsense. This happens on the fly in games too. Shaders get compiled on the device, assets streamed in from disk or the network. Game behavior is typically scripted and patched, etc. Narrow selection of hardware? 10 years ago? Wrong. I work on a game engine that fully supports a 10 year old machine, and most state of the art engines can degrade to that level too.
Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves.
The game can scale to a mobile device believe or not. It just doesn't make sense to. Throttling draw calls or streaming only the lowest mip levels is trivial for a good engine.
The web is absolutely 100% less efficient than a commercial game engine and does far far less. The flip side is that the barrier to entry is way lower as well. It takes less experience to write a web app than it takes to author a game. I would argue that authoring a web renderer is easier than authoring a state of the art game renderer too, although there are certainly complexities there. The DOM scene graph compared to a game scene graph? Come on, is there even a comparison? I could dump a scene graph for you which is totally dynamically generated in real time that dwarfs the most complicated web page you could find. I mean, heck, we use BVHs, KD trees, octrees, and more to represent our scene graphs. You think the DOM has even a fraction of that complexity?
Too quote you, "seriously, just stop for a second and use your head."