Hacker News Reader

Comment by WalterBright | Hacker News Reader

> Therefore practically it does not matter.

You won't notice it on your desktop. But you will notice it in cases I mentioned. Top shelf games also are not going to give up that 1%, or so the game devs tell me.

View on HN

And yet even the likes of Sony and Nintendo are working in major titles with Unity.

Unity is also the official developer SDK for Microsoft's HoloLens Virtual Reality Toolkit.

And 70 million people go eat Mickey D's every day, doesn't make it good in any way. Whenever I play unity games (rarely to be honest as I play maybe 5-20 hours a year nowadays, but this has been consistent) I brace myself for a laggy experience. Most people don't care about this it seems but it really makes me want to close the game when there's a laggy scene (and definitely put the tech used in my blacklist).

I have the same happening to me with C and C++ games, so it isn't a given that the language along is the cause, rather the ability of the programmers.

The very vast majority of native games I played don't have the kind of lag that unity games have (and seem to do much more things). Only very bad one I could remember was Neverwinter nights 2.. that one was really unplayable even on god-tier computers

I would still blame the programmers.

Doing the game in C++ certainly hasn't helped Cyberpunk 2077 performance and being bug free.

what Cyberpunk 2077 does is incomparable with the games I'm mentioning having lag in unity, which are slow-paced 2D games

Or maybe you just don’t notice it with unity games that work decently? A classic case of confirmation bias.

the only games I noticed it to the point it was actively bothering me and distracting me from the game were:

- Unity games

- NWN2 which I mentioned

- CrossCode which is an HTML5 game (while being an absolutely great game, performance wise this one was by far the worst I ever experienced, it's laggy on a fucking GTX1070 / 8750H / 32GB RAM system for a 2D pixel-art rpg and made me quit the game in rage more than once)

A minor, not well-thought out use of shared pointers in C++ can easily add much more to execution time (and yes, I know it is not often used in game dev)

> And yet even the likes of Sony and Nintendo are working in major titles with Unity.

I don't think this is a reasonable remark.

The whole point is that the 1% penalty is added on top of whatever choices "the likes of Sony and Nintendo" make. If they have alternatives that ensure them a performance win just by chosing the right tool to work with Unity, they won't choose the wrong one.

It definitly is, because despite being mostly C#, outside the graphics engine itself, they have decided it is the right tool for some of their projects.

D had a chance in the games industry with Remedy and lost it, instead a language that supposedly lesser one, is being adopted by major platform owners.

> It definitly is, because despite being mostly C#, outside the graphics engine itself, they have decided it is the right tool for some of their projects.

No, it was not a reasonable remark. Pointing someone else's choice changes nothing. The point that you keep missing is that performance is a key decision factor, one among many, and baseline performance penalties imposed by a particular choice of programing is a factor that adds up to all other choices. If you degrade the performance of your offering without any relevant tradeoff, you're making it harder to justify it's adoption.

Feel free to insist in your personal assertion. Those who care about performance feel strongly about gratuitously pile performance penalties without any meaningful tradeoff to show.

A key factor and yet they are using Unity, because even for Sony, Nintendo and Microsoft, that tradewort is worthwhile from business point of view.

Minecraft wouldn't never have happened if Notch was busy discussing if it would be acceptable at all doing it in Java.

Just like too many in HN dream of being the next FANG, too many worry about the ultimate performance when their games would hardly win a fraction of Minecraft when placed into the market.

As somebody said above, there is a difference between performance choices made by platform providers vs application writers ( or game studios ).

Getting acceptable performance in my game despite my focus on playability and time to market is one of the benefits of platform choice. I want to focus on my game, not overcoming platform limitations.

I am not saying a single 1% makes a difference but the idea that performance in the platform does not matter is wrong.

It matters when it’s significant, eg. Python can indeed be an order of magnitude slower than a native, compiled language. But much more than 1% can easily accumulate from all the things that are forced on you by not writing assembly so I don’t think it is a fair cut-out point.

Especially that research OSs were written in managed languages, often with better performance!

> the idea that performance in the platform does not matter is wrong.

But nobody said this. Maybe we're too deep in the thread for anyone to remember, so let's refresh our memories. The claim was not that performance doesn't matter, or that 1% never matters, but that any language 1% slower than D is currently could categorically not be considered a systems programming language.

That's even more absolutist and absurd than "performance does not matter".

Reply on news.ycombinator.com