Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

blog.mozilla.org

Post reply on HN
Print view View original

51–60 of 141 posts

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#51

Post by morsch »

cromwellian wrote: post #37

I just bought Titanfall yesterday. I run this on a watercooled PC, dual GPU setup. I wouldn't have bought such a PC setup just to run at 60% of system performance. I think Mozilla is marketing this wrong. Triple-AAA titles go for squeezing every last ounce of system performance. I don't think there is anything to be gained to putting a game like Titanfall, which has 5 gigabytes of assets (some UE titles are much bigg…

5 GB is about one or two hours at not-unusually-high speeds. You can probably start and run the game with much less assets. Having the assets available at multiple quality levels -- chances are that's the case already -- would shave off more time. And by the sound of it, 60% of your computer is still about as fast as the just-launched console generation.

Not big issues, I think. The big issue is having a robust ecosystem for all the things like networking, input handling, sound and video.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#52

Post by supergauntlet »

azakai wrote: post #41
cromwellian wrote: post #37

I just bought Titanfall yesterday. I run this on a watercooled PC, dual GPU setup. I wouldn't have bought such a PC setup just to run at 60% of system performance. I think Mozilla is marketing this wrong. Triple-AAA titles go for squeezing every last ounce of system performance. I don't think there is anything to be gained to putting a game like Titanfall, which has 5 gigabytes of assets (some UE titles are much bigg…

As the video shows, this is not just about the highest-end AAA games, there is a 2D platformer there too. But the important thing in working to port the highest-end games is to push the limits of the web platform, so it can be better optimized. Before UE3 was ported, people were - rightfully! - skeptical any such engine would work well on the web at all, and that port helped get to that point (and now to UE4). Also,…

Most games these days (with a few exceptions) are GPU bound. Battlefield, Far Cry, Assassins Creed, etc are all GPU bound. You can't get away with a completely awful CPU but you don't need a great one for these. For other games, like Starcraft, or Kerbal Space Program, the GPU isn't your limiting factor, but your CPU's performance. Skyrim, for example, will perform vastly different with the same graphics card with different CPUs. For many games the anemic CPU performance won't matter, at least not very much.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#53

Post by cwyers »

taeric wrote: post #31
meritt wrote: post #22

Earlier quoted context omitted.

The same can be said for all development over the past 15-20 years. The reality is development time and cost is drastically lowered when intermediate developers can produce working software with minimal consideration toward optimization, lowering resource usage or decreasing overall package size.

And better tooling helps here more than anything else. The giant elephant in the room nobody likes to speak towards is that Flash dominated not because it was a great language, but because they had awesome tooling around it. This is doing very little to address that. Now, the Unreal Engine is a great tool in and of itself. Having it target the browser is the questionable part to me.

If you look at the browser makers who primarily target operating systems other than their own (Safari doesn't count, as Safari for Windows is mainly a developer tool, not a product; and Opera doesn't count, as it's now based on Chrome, rather than being its own), they're pushing heavily for the browser to be the userspace, both in terms of shipping an OS based around their browsers (ChromeOS/FirefoxOS) and shipping apps to current OSes using their browsers rather than native code.

This demo may focus on the high-end graphics, but I doubt that's the reason anyone is investing effort into this. Mozilla wants cross-platform mobile games on Firefox OS, and Epic (I'm guessing) wants to be able to run games on Firefox OS/Chrome OS/Sailfish/Tizen/Ubuntu Touch/flavor-of-the-month that supports HTML 5, as a long-term hedging of bets. Not all of those explicitly support asm.js, but Chrome is going to get better at supporting asm.js even if it never gets to feature parity with Firefox, and the non-iOS world is likely to be running a derivative of Chrome or Firefox.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#54

Post by stcredzero »

taeric wrote: post #29
stcredzero wrote: post #17

Earlier quoted context omitted.

For a high level managed language, 67% would be pretty godlike. There are some C programs that are less than 67% the speed of their own -O2 compilations. If 67% native speed winds up being the average efficiency, that's plenty good enough for the vast majority of computing. As recent history has been teaching us, doing more with less has mainly to do with getting more mobile, distributed, and ubiquitous. We're quickl…

You ignored my 200% mark, though. If I could run this demo in the browser and it pegs all of my cpus, compared to running the same demo "native" and having half my system capable of idling, I'm not sure I see the win. Even if it gets to 100% of "native." (I hate that it sounds like I am claiming that is the case here, as I really don't know.)

A game like this is a singular and extreme case. I can see a really big win for lots of business software. With browser deployment, lots of logistical problems just disappear. Heck, the notion of traditional corporate structure starts to disappear: Corporations exist because they can provide lowered transaction costs in specific contexts of production.

I'm not sure I see the win. Even if it gets to 100% of "native."

Even if Unreal engine FPS don't get to 100% of native, that doesn't preclude the disruption of lots of other software distribution models, including entire subgenres of games. But it goes much farther than just games.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#55

Post by smacktoward »

supergauntlet wrote: post #52
azakai wrote: post #41

Earlier quoted context omitted.

As the video shows, this is not just about the highest-end AAA games, there is a 2D platformer there too. But the important thing in working to port the highest-end games is to push the limits of the web platform, so it can be better optimized. Before UE3 was ported, people were - rightfully! - skeptical any such engine would work well on the web at all, and that port helped get to that point (and now to UE4). Also,…

Most games these days (with a few exceptions) are GPU bound. Battlefield, Far Cry, Assassins Creed, etc are all GPU bound. You can't get away with a completely awful CPU but you don't need a great one for these. For other games, like Starcraft, or Kerbal Space Program, the GPU isn't your limiting factor, but your CPU's performance. Skyrim, for example, will perform vastly different with the same graphics card with di…

> Most games these days (with a few exceptions) are GPU bound.

Most AAA games are GPU-bound, you mean. It's very rare to find titles from indie developers or smaller publishers that come anywhere near taxing a modern GPU -- due in part to the massive expense required to create engines and assets that are capable of doing so.

(Which is also why the AAA game business model seems more and more to be teetering; AAA titles have differentiated themselves via graphics for decades, but the cost of being cutting edge is so high now that if the title sells at anything less than blockbuster rates it's a financial failure.)

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#57

Post by azakai »

taeric wrote: post #46
azakai wrote: post #43

Earlier quoted context omitted.

"67% of native speed" means that for a fixed CPU workload, it will take 1.5 times longer to run. Of course this depends a lot on the benchmark, some run better and some run worse. Note also that this is on the CPU. On the GPU, WebGL is already extremely close to native GPU speed.

The fixed CPU workload makes sense. I mistakenly took it to mean they simply got within 67% of the framerate of native. Mayhap my misunderstanding is even deeper and those mean roughly the same thing. I'm still not sure I see the compelling use case. The tooling to create games that target various platforms already exists. Does this really widen the ballpark?

Measuring performance by framerate is tricky actually - it usually maxes out, and it's an inverse value, etc. It's a good quick measurement perhaps ("game X gets 50fps in Y but 60fps in Z", then clearly Z is better) but it's not an accurate measurement in many senses (for example both could get 60fps but one might use less CPU cycles).

Measuring execution time for a fixed, deterministic non-stop workload is the best thing in my opinion.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#58

Post by azakai »

jebblue wrote: post #56

It's a YouTube video? Will it run on Linux? I still have UT3 in the box new, the promise of it running on Linux evaporated even though UT2004 ran better on my machine on Linux than when I ran on Windows on the same machine.

Yes, it runs on linux. (I use linux and I've tested many of these demos, perhaps not this specific build though.)

The only issue with linux is if you have older GPU drivers, they might be blacklisted by the browser and WebGL support will be off. But if WebGL is enabled and your drivers are stable, will work fine.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#59

Post by azakai »

taeric wrote: post #29
stcredzero wrote: post #17

Earlier quoted context omitted.

For a high level managed language, 67% would be pretty godlike. There are some C programs that are less than 67% the speed of their own -O2 compilations. If 67% native speed winds up being the average efficiency, that's plenty good enough for the vast majority of computing. As recent history has been teaching us, doing more with less has mainly to do with getting more mobile, distributed, and ubiquitous. We're quickl…

You ignored my 200% mark, though. If I could run this demo in the browser and it pegs all of my cpus, compared to running the same demo "native" and having half my system capable of idling, I'm not sure I see the win. Even if it gets to 100% of "native." (I hate that it sounds like I am claiming that is the case here, as I really don't know.)

> I'm not sure I see the win

For a user that can install a native build, the native build will run better. No doubt. But, most users in the world do not know how to install apps, and even if they did they shouldn't because of security concerns.

For that reason, game devs know that asking people to install a plugin or a native build will kill off most of the potential users of their game.

Instead, if you just give people a link to click and it jumps right into the game, that will maximize the amount of users able to play it. This is the main reason for the anti-plugin and pro-web movement in games.

Re: Mozilla and Epic Preview Unreal Engine 4 Running in Firefox

#60

Post by azakai »

taeric wrote: post #31
meritt wrote: post #22

Earlier quoted context omitted.

The same can be said for all development over the past 15-20 years. The reality is development time and cost is drastically lowered when intermediate developers can produce working software with minimal consideration toward optimization, lowering resource usage or decreasing overall package size.

And better tooling helps here more than anything else. The giant elephant in the room nobody likes to speak towards is that Flash dominated not because it was a great language, but because they had awesome tooling around it. This is doing very little to address that. Now, the Unreal Engine is a great tool in and of itself. Having it target the browser is the questionable part to me.

Regarding tooling, I agree Flash's tools were a huge benefit for it. The same is true for engines like UE4 and its competitors, they all focus a lot on tooling. When those engines are ported to the web, the tools are part of that.

Some tools might not just work, of course, like profiling tools or anything else that runs while the game executes on the target device, as opposed to the dev environment. But:

1. I have seen even things like profilers being ported together with the engines. Takes some porting but the result is you have the engine's normal full set of tools.

2. You have the in-browser tools as well - all modern browsers have profilers, debuggers, etc. And also they support source maps, which means they can see the original source code and not the hard-to-read compiler-output JS.

Post reply on HN