←back to thread

285 points ashitlerferad | 2 comments | | HN request time: 0.001s | source
Show context
dmonitor ◴[] No.42063608[source]
This shouldn't come as a surprise to anyone. Nintendo has had a trend for the past couple decades of releasing "sequel" consoles that are essentially a modernized version of the old one with extra features, compatible with everything that released on the predecessor.

With all three major console manufacturers prioritizing backwards compatibility, and the rise in PC gaming (universally backwards compatible), people are starting to catch on to the fact that old games don't "expire" after 10 years. I wouldn't be surprised if backwards compatibility just becomes the standard for all gaming consoles going forward.

Tangential, but I'm also interested in seeing how games that released on old consoles and are continued to be played, like Fortnite, will support aging hardware. I don't like that Epic can one day announce the game just no longer works on that console, rendering your purchases null and void until you upgrade your hardware, but I can't expect them to update that version of the game forever.

replies(10): >>42063816 #>>42064395 #>>42064760 #>>42065199 #>>42065211 #>>42065278 #>>42067231 #>>42067586 #>>42067644 #>>42070675 #
qwytw ◴[] No.42064760[source]
> prioritizing backwards compatibility

Backwards compatibility is very "cheap" these days though? With no arcane architectures and chip designs. PS5 and Xbox are basically just generic PCs running a restricted OS and Switch is just a phone/tablet.

replies(2): >>42066373 #>>42069343 #
1. kimixa ◴[] No.42069343[source]
Depends on the level of hardware access.

If the GPU access is through a relatively "thick" API like DX/Vulkan and shaders stored in an intermediate representation like DXIL or SPIR-V, sure, swapping out the hardware implementation is relatively easy.

But if they're shipping GPU ISA binaries as the shaders, you'll have a much harder time ensuring compatibility.

Same with things like synchronization, on both the CPU and GPU (and any other offload devices like DSPs or future NPUs). If they use API-provided mechanisms, and those are used /correctly/, then the implementation can likely be changed. But if they cycle-count and rely on specific device timing, again all bets are off.

Things like DX12 and Vulkan have a large number of sync points and state transition metadata to allow different implementations to be "correct" in things like cache or format conversions (like compression). Not all those transitions are required for every vendor's hardware, and we regularly see issues caused by apps not "correctly" using them when the spec says it's required, as the vendor's hardware they happened to test on didn't require that one specific transition that another implementation might, or they happened across some timing that didn't happen to hit issues.

I guess my point is Compatibility is hard even if the APIs are intentionally designed to allow it. I have no idea how much the idea of such compatibility has been baked into console APIs in the first place. One of the primary advantages of consoles is to allow simplifications allowed by targeting limited hardware, so I can only assume they're less compatibility focused than the PC APIs we already have Big Problems with.

replies(1): >>42072989 #
2. fngjdflmdflg ◴[] No.42072989[source]
This exactly. NVN is lower level than dx12/Vulkan and is probably more comparable to Sony's graphics APIs in terms of how low level it is.* And even if the NVN version itself remained the same, consoles use precompiled shaders as you say, so unless you keep that API stable between generations as well you are going to need to do some form of translation between the new and old APIs.

* I've never used NVN but I imagine it must be very low level otherwise developers would not be using it instead of Vulkan which is also supported by the Switch. Feel free to correct me here or clarify if I'm right on this.