OpenLara – Web-based classic Tomb Raider engine remake
xproger.info
xproger.info
Yeah Emscripten and projects like this are pretty impressive
Edit: I apparently can't read
I played a good chunk of the demo level and only noticed a few glitches (e.g. bear getting stuck in the wall, some non-optimal camera movement - but maybe that matches the original?).
One error that I hit a good way through the level (in the room with the disconnected stairs and pool in the middle) is a JS stack overflow:
exceeded,RangeError: Maximum call stack size exceeded at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:113674) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632) at Bi (http://xproger.info/projects/OpenLara/OpenLara.js:5:118632)
I understand Chrome has better support, and I'm in the habit of launching Chrome to check out Web GL stuff. But I absent mindedly followed this link on Safari and was pleasantly surprised.
It is a sub-set of javascript that you can roughly think of as javascript-bytecode and this can be heavily optimised in the browser compared to full javascript.
First, they aren't apples to apples comparisons. The render loops of these two games will look completely different from each other.
OpenLaura is built with Emscripten, so it's actually a C or C++ program that is complied to ASM.js, a subset of JavaScript that some JavaScript interpreters can basically convert 1-to-1 to native code that runs directly on the C runtime rather than needing to be interpreted, specifically because it avoids the dynamic features of JavaScript that require interpreting.
Mine3D is straight, object oriented JavaScript. And while I haven't had time to dig too deep into the code yet, I know from experience that it can be very difficult to avoid garbage collections in such a design. There are a lot of places in JS where you implicitly create objects, and there are a lot of idiomatic JS patterns that involve creating short-lived objects that get dumped on the floor very quickly. It's possible to make high-performance, object-oriented JavaScript, but it's very hard.
So between the two (and again, this is just speculation), there could be upwards of an 8 to 10x improvement in "performance". That's difficult to put into meaningful terms, though, because again, the two games are built completely differently and do different things.
One of the ways in which they are completely different is that Mine3D is using relatively large image files for its textures. Almost all of the variations in materials in Mine3D appear to be done through the textures. I don't want to go to the trouble of checking, but I would not be surprised if the textures used in the OpenLaura demo completely fit inside one of the letters inside one of the Mine3D textures. However, I doubt that is the source of the problems. It could actually go either way. The large textures could be impacting fill rate, or having all of the materials based on the same texture could be improving draw call batching.
Much more likely is that Mine3D uses a lot of idle animation, transition effects, and DOM manipulation. A lot of modern graphic design (or rather, more modern than the original Tomb Raider games) emphasize having a lot of visual "breath" in a game. All of that sort of stuff runs on the CPU, where it will be hurt the most by not being tuned completely.
And it's really hard to get DOM and WebGL working together smoothly. There are a variety of things you can do in DOM that will trigger disabling hardware-accelerated 2D compositing in the browser, and I am not aware of anywhere they are documented clearly and plainly, so trying to mix the two is fraught with peril. It's best to just not do it and implement your UI for your game 100% in WebGL.
This is an incredible achievement though and just the sort of thing I love to see here on a Sunday!
I'll try to help this guys somehow.
I think perhaps the ctrl-action button is more sensitive here than it was in the original PC version? In order to get out of the water hole I had to swim into the corner basically. It was a long while since I played the original on PC though so who knows.
Mad respect.
They just need to fix the issue of the browser highjacking touch inputs and add fullscreen support.
Always thought the TR games were pretty awful, personally. Those were the days when they were still trying to get 3rd person 'right'. But the implementation here is solid.
EDIT: To swim forward under water, press space!
EDIT2: Somehow, there's a bug with climbing out of the water, making her climb up on the edge, then places her like half a meter forward and she plays the climb animation again (clipping into the ground), then places her half a meter forward, etc, until she is stuck in the wall.
Edit: Also a wolf followed me underwater and ran around normally. And I seem to have unlimited underwater time. Is there a tracker for how complete the project is/a roadmap? Either way, awesome stuff!
This port doesn't have configurable controls, but with Wolfenstein you can't even configure it to do strafe without a modifier key.
It seems like at some point all these 1st/3rd person games switched to strafing by default, and using the mouse to look/turn/aim. Anyone know when that happened? What game first allowed that configuration and what first used it by default?
Here's a more in-depth article on the history of WASD: http://www.pcgamer.com/how-wasd-became-the-standard-pc-contr...
Uncaught TypeError: Cannot read property 'getSupportedExtensions' of undefined
Cool effort, overall.