Live data from Hacker News

Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

forums.unrealengine.com

41–50 of 118 posts

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#41
post #27

Earlier quoted context omitted.

MS supporting Vulkan instead of DX would be shooting at their own feet. Makes 0 sense to them.

> MS supporting Vulkan instead of DX would be shooting at their own feet. Makes 0 sense to them. Same as supporting standard HTML instead of ActiveX and Silverlight? If not using lock-in is shooting in one's own feet, you have some strange notion of what's normal.

I don't see the parallel there. HTML was always a secular technology, unlike DirectX which was created and developed by Microsoft for Microsoft.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#42

Earlier quoted context omitted.

Why would a multi-platform game engine mainline changes that are only applicable to Windows 10 devices?

Why not? Since it's a multiplatform engine already, any platform specific code would have already been modularized from the very beginning.

It's also code that modifies the engine in a way that Epic's founder disagrees with.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#43
post #10
post #2

I hope it's not an EEE move[1]? MS aren't new to such things. I.e. make Unreal Engine work with certain things only on UWP platforms, putting everything else at a disadvantage. I don't have much trust in good intentions of MS when gaming and 3D graphics are concerned, given how they are dead bent on lock-in with DX12, while the industry is collaborating on Vulkan. [1]: https://en.wikipedia.org/wiki/Embrace,_extend_an…

It would be EEE if they, for example, ported DirectX to Linux. But here they're just ported other product to run on their "a-la Android for desktop" system. Possibly evil but not exactly EEE.

They can definitely also EEE with this. Take a game engine, create a fork for your platform, wait until your platform and fork has a significant market share, and then start introducing features to your fork, which are not directly available on the main-branch.

I can't seem to find anything on how UE4 is licensed, but even if Microsoft is forced to release all of their source code, if their fork is different enough from the main-branch, it might be extremely hard to backport all of these features into the main-branch.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#44
post #9

Earlier quoted context omitted.

Actually, this may be a valid concern. It does look like Microsoft is trying harder and harder to lock down PC gaming. See Gabe's [0] and Tim Sweeney's [1] complaints. [0]: http://arstechnica.com/gaming/2012/07/steams-newell-windows-... [1]: http://arstechnica.com/gaming/2016/03/tim-sweeney-to-microso...

Newell's comments are from 2012. Sweeney's comments have been pretty much directly invalidated by Microsoft's actions. Note that this year Microsoft made a point to address Sweeney's comments by demonstrating Steamworks in a UWP app, and the Windows 10 update releasing today makes it easier to install UWP apps without the Windows Store. They've repetitively reiterated that UWP apps can be sold through third party sto…

> That UWP apps are sandboxed (like Android and iOS apps) and therefore less able to act maliciously.

Many people don't want Console/phone like restriction on PC. Sweeney feared that MS will try to force everybody to use UWP, and later MS will change UWP policies. But then it will be late for everybody move away from UWP.

How many people you know downloads the apk on their android phone to get the app running? Do you have any say on the Google Play policy changes? MS will certainly repeat how convenient UWP is, but people are reluctant to trust MS because they don't know how MS will behave in the future.

That's what Tim Sweeney fears. Phasing out the open nature of the ecosystem, and replacing it with a locked down one where MS controls everything.

And that's a lock down. Maybe it's not for malicious reason, but people have enough reason to hold on onto the open nature that drove the growth of PC gaming(and malware). Secondly, when they don't know if MS will keep their words.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#45
post #27

Earlier quoted context omitted.

> MS supporting Vulkan instead of DX would be shooting at their own feet. Makes 0 sense to them. Same as supporting standard HTML instead of ActiveX and Silverlight? If not using lock-in is shooting in one's own feet, you have some strange notion of what's normal.

I don't see the parallel there. HTML was always a secular technology, unlike DirectX which was created and developed by Microsoft for Microsoft.

I guess you don't remember browser wars. Until MS started supporting standard HTML, they were pushing all kind of junk like ActiveX and Silverlight, in attempt to monopolize the Web with lock-in. Only when browsers competition intensified, they reluctantly started supporting standards (even WebGL). Some still suffer from that lock-in though, such as South Korea who are stuck with very bad decision of requiring ActiveX for bank transactions.

Exactly same thing here. They used DX to lock 3D graphics into their platforms.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#46
post #17

Earlier quoted context omitted.

If you read the linked post, it explains how you need to connect GitHub to your Epic Games account to see the repo if you see the 404 error. (I didn't know this sort of thing was a GitHub feature, so it was interesting to me. I initially made the same mistake.)

404 is Github's default answer for when you try to access a private repo you don't have access to. You can test it by logging out of our account and attempting to access a private repo url you usually can access.

Shouldn't this be a 403? Making it a 404 is confusing.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#47
post #17

Earlier quoted context omitted.

If you read the linked post, it explains how you need to connect GitHub to your Epic Games account to see the repo if you see the 404 error. (I didn't know this sort of thing was a GitHub feature, so it was interesting to me. I initially made the same mistake.)

404 is Github's default answer for when you try to access a private repo you don't have access to. You can test it by logging out of our account and attempting to access a private repo url you usually can access.

I was just noodling about this idea for my current project. I suppose 403ing would enable an adversary to know if something exists or not?

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#48
post #17

Earlier quoted context omitted.

404 is Github's default answer for when you try to access a private repo you don't have access to. You can test it by logging out of our account and attempting to access a private repo url you usually can access.

Shouldn't this be a 403? Making it a 404 is confusing.

The primary reason to do this is the same as why most logins will just say "incorrect username or password" rather than revealing the username is in fact, correct, and just the password is wrong. You don't want to reveal the identity or location of something that is hidden. If I have an unannounced project at github.com/ocdtrekkie/unannouncedproject, you might discover the name of my unannounced project by fishing for URLs that come up 403 instead of 404.

Confirming something exists narrows what someone looking to find out something secret has to look for. If you know what my username is, you only have to guess passwords for that username. If you know what my project name is, you only need to look for references elsewhere to that project name.

Just knowing the project exists could be telling, if your project was like... github.com/apple/nintendo-igameboyphone it would potentially be a really revealing thing if you hadn't announced it yet. Slack had a big fiasco when entering a fake @whatever.com address would let someone see whatever.com's teams prior to email verification. From just room names alone you could discern some potential acquisitions in negotiation, teams at Microsoft or Apple you might not have otherwise known existed, etc.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#49
post #45

Earlier quoted context omitted.

I don't see the parallel there. HTML was always a secular technology, unlike DirectX which was created and developed by Microsoft for Microsoft.

I guess you don't remember browser wars. Until MS started supporting standard HTML, they were pushing all kind of junk like ActiveX and Silverlight, in attempt to monopolize the Web with lock-in. Only when browsers competition intensified, they reluctantly started supporting standards (even WebGL). Some still suffer from that lock-in though, such as South Korea who are stuck with very bad decision of requiring Active…

Microsoft deservedly lost because they failed to innovate. But that isn't the case with graphics, where they have been at the forefront of innovation for well over a decade now. OpenGL has historically lagged behind DirectX in terms of features, ease of use and performance. Only in the last couple years has anyone (Mantle, Vulkan) actually begun to threaten Microsoft's dominance and if DirectX is inferior it should lose, but to equate that with how the HTML wars went is glossing over a lot of detail.

Re: Microsoft forks Unreal Engine 4 and ports it to Universal Windows Platform

#50
post #43
post #10

Earlier quoted context omitted.

It would be EEE if they, for example, ported DirectX to Linux. But here they're just ported other product to run on their "a-la Android for desktop" system. Possibly evil but not exactly EEE.

They can definitely also EEE with this. Take a game engine, create a fork for your platform, wait until your platform and fork has a significant market share, and then start introducing features to your fork, which are not directly available on the main-branch. I can't seem to find anything on how UE4 is licensed, but even if Microsoft is forced to release all of their source code, if their fork is different enough f…

> They can definitely also EEE with this. Take a game engine, create a fork for your platform, wait until your platform and fork has a significant market share, and then start introducing features to your fork, which are not directly available on the main-branch.

Exactly. Or if it's not even a fork anymore (let's say it was merged upstream), make those features platform dependent / unportable even in the main codebase. It will still be EEE.

Post reply on HN