...and for this it is really small, really nice! The asm.js blob is just a 180 KByte download, including the WebGL and WebAudio wrapper (and it looks like an ogg-vorbis and/or mp3 software decoder is also included, although I don't know which one is used in the emscripten build).
Wow, the demo is just published with a level from the original game with the original assets… If OpenMW did a directly playable web version with the original world, Bethesda would not like that :D
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:
WebGL noob question - why is this silky smooth on Safari on my MacbookPro but Mine 3D [0] (and to be fair basically any other Web GL) is noticably low fps?
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.
Bats just followed me under water... Also I am unable to shoot them as long as they are attacking me. Is it a OpenLara bug or feature from the original game?
Ho my...Tomb Raider is my favorite game since I played Tomb Raider 2. I've got extremely excited about this project! Nice 60FPS, nice movements (although the controls are completely different from the TR1-5 games)!
Oh man this is positively insane! The original Tomb Raider games are probably my all time favorite video games. I recently revisited Tomb Raider for PlayStation in an emulator on my laptop. I find it a bit mind-blowing that OpenLara in the browser seems to be performing better than the native PSX emulator did.
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.
Wow. I remember playing the original almost 20 years ago on a PC that really didn't support it at a terrible framerate. The fact that I can play it now in a browser window on a netbook without it breaking a sweat is astonishing.
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.
They were great games hampered by some pretty abysmal controls, dual analogue wasn't exactly commonplace at the time (hell, the dual analogue controller was released the year after TR1 came out) so there was only so much you could do with just a d-pad. The controls got noticeably more tolerable as the series went on but even then it was the same tank controls full of animation lock-in (sidestepping being the main one).
Rock solid 60fps, works out of the box on Chrome. I am impressed.
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.
Nice! But if you're keeping the original PC controls, why swap alt/space? It's severely messing with my muscle memory.
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!
Space to jump seems quite normal to me, but what didn't was that A/D turned instead of side-stepped. I remember playing Tomb Raider when it came out, but I don't remember it doing that. I actually find it nearly impossible to move around with those controls, and I had the same problem with web ports of Wolfenstein.
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?
It was popular in competitive Quake play, was included as an option in Quake II and the original Half-Life was the first game to ship with the standard WASD + mouse scheme that every game uses today.
