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

The journey to Nintendo Switch

factorio.com

Post reply on HN
Print view View original

81–90 of 169 posts

Re: The journey to Nintendo Switch

#81

Post by shadowgovt »

pdntspa wrote: post #59
naranha wrote: post #56

If the switch proves anything it's that you don't have to pay $1600 for a GPU to enjoy amazing games. Or the other way round, if you pay $1600 for a gpu it does not mean that you'll be able to play any good games.

Depends entirely on what you play. Cyberpunk 2077 in 4K with DLSS and raytracing is exquisite...

... as long as you ignore the places where CDPR didn't actually finish debugging the game and errors abound, from innocent things like a pathing error in a pre-rendered character animation causing them to steamroll through movable objects in a scene to arguable game-breakers like a mission neither being succeed-able or failable because some key internal flag is in the wrong state, with the only solution being to roll back to a save before the error occurred.

Re: The journey to Nintendo Switch

#82

Post by duskwuff »

ls612 wrote: post #50
kergonath wrote: post #5

Earlier quoted context omitted.

I would absolutely love an iPad version. Much more than the Switch version (which I am going to get anyway).

Well if they port it to Apple Silicon macs making an iOS build shouldn’t be crazy difficult right? (Famous last words)

Still waiting on the Apple Silicon port. The Mac build of the game is still x86-only.

Re: The journey to Nintendo Switch

#83

Post by bri3d »

jvanderbot wrote: post #57

> Removing all uses of undefined behaviour is probably a fool's errand, as it would require significant changes throughout the code that would take time and come with a performance impact, all for no immediate practical benefit. So I just hunted down the undefined behaviour cases that actually broke determinism. This was easy enough, as we have plenty of tools we use to test determinism. By comparing the game state C…

This kind of determinism testing is a fairly common approach in games that implement shared-state multiplayer, and I think that's why it was implemented for Factorio as well. Otherwise you get drift between clients that breaks the game.

Re: The journey to Nintendo Switch

#84

Post by camgunz »

jvanderbot wrote: post #57

> Removing all uses of undefined behaviour is probably a fool's errand, as it would require significant changes throughout the code that would take time and come with a performance impact, all for no immediate practical benefit. So I just hunted down the undefined behaviour cases that actually broke determinism. This was easy enough, as we have plenty of tools we use to test determinism. By comparing the game state C…

I built a similar system for a Doom port--compatibility was an important issue for me, and conveniently I was adding client/server multiplayer with state deltas, so I had all the infra built to do a full dump every tic. It sounds wild, but if your game is already deterministic and you support saving, you're 80% of the way there.

Re: The journey to Nintendo Switch

#85

Post by pdntspa »

candiddevmike wrote: post #18

> Now, the final startup time when the game is installed on internal storage is 70 seconds, but let's not get ahead of ourselves. Maybe I don't notice this with other games but that seems like a really long time.

How does a game like Factorio take so long to load? The game assets themselves are like megabytes. What is it doing?

Re: The journey to Nintendo Switch

#86

Post by SpacePortKnight »

Factorio's official requirement for x86 is a dual core 3.0Ghz processor & yet it's able to run on Switch which has a very weak 1Ghz quad core cortex-A57 ARM CPU.

How is this possible? I would imagine CPU requirements to be more or less same across any resolution / operating system.

This is what makes Nintendo Switch interesting to me. It's CPU is even less powerful than an Raspberry Pi 4. Even midrange android smartphones today are much more efficient and powerful than Switch and yet Switch can run Doom / Skyrim just fine.

Re: The journey to Nintendo Switch

#87

Post by Cyberdog »

SpacePortKnight wrote: post #86

Factorio's official requirement for x86 is a dual core 3.0Ghz processor & yet it's able to run on Switch which has a very weak 1Ghz quad core cortex-A57 ARM CPU. How is this possible? I would imagine CPU requirements to be more or less same across any resolution / operating system. This is what makes Nintendo Switch interesting to me. It's CPU is even less powerful than an Raspberry Pi 4. Even midrange android smartp…

Because the Switch is running Factorio on top of a bit of code optimized for running games. A PC is running Factorio on top of a full-featured general-purpose OS, and most PC users are going to be running other things concurrently; web browsers, Electron messaging apps, malware, etc.

Of course, being able to target a single hardware platform with very minor differences like the Switch also means the ability to make optimizations to that specific platform without having to care about possibly breaking compatibility with others. It'd be like being able to optimize your game for people with Nvidia cards and completely ignore those with ATI, Intel, or any other brands on the PC.

Re: The journey to Nintendo Switch

#88

Post by [deleted] »

simias wrote: post #46
rjh29 wrote: post #29

Earlier quoted context omitted.

BotW got some after-launch patches that significantly reduced the launch time. They did this by overclocking the Switch during load. I didn't see any mention of boost/overclock in the Factorio writeup, though.

Do you know if this technique is available for all games or just Nintendo's own? It seems like it would be easy to cause issues if games were allowed to mess with the clocking willy-nilly, so I assumed that it was only done on Zelda because it's a first-party title (and one of the biggest on the console).

[deleted]

Re: The journey to Nintendo Switch

#89

Post by Cyberdog »

fredoralive wrote: post #16
desindol wrote: post #13

Earlier quoted context omitted.

No. It’s a completely different graphic stack.

There’s already a Mac OS version, so it they’ve presumably already handled that side of things.

Like most macOS games, it most likely is an x86-64 game that Apple's x86-64 emulator does an admirable job of emulating. As far as I can tell, very few Mac games, even new ones, are proper ARM builds currently.

Re: The journey to Nintendo Switch

#90

Post by Rebelgecko »

TillE wrote: post #37

> It allowed me to make many Nintendo Switch specific optimizations, and even some optimizations for the PC version Are there significant CPU-specific optimizations that can be made for the Switch / ARMv8 that wouldn't apply to x86-64? I've never really dug into things at that level, I wouldn't know where to begin except for like vector instructions.

(Disclaimer: I haven't written assembly for a while so this may not be true any more)

One cool thing about ARM is that vector instructions run in parallel with the regular CPU pipeline. You can do some neat optimizations where you interleave sequential part of an algorithm runs while the SIMD instructions are executing. However if you do this yourself the code is going to be super non-portable. In general, knowing that something is always going to be running on a Switch lets you dig deeper into architecture specific optimizations, since x86 has so much variance it would take a ton of effort to really dial in performance on the whole menagerie of Intel and AMD CPUs

Post reply on HN