Far Cry 4 Dual Core Woes...now resolved

[MrJim]

It's an age old problem - the cost/return for the PC market is so much worse than console.

I thought that the move to x86* processors would make porting better.. but I fear what's it's done is make devs spend even less time on it because they can get away with a minimum now. That has its benefits in terms of getting PC ports where they may not have been viable before, but could mean we're missing out on optimising the experience.

I'm sure you're absolutely right there. Nail on the head.

[MrJim]

That was a close call - could have ended up costing you a fair bit!

Very true! I would have had to upgrade my main PC (3570K) & transferred that over to my second machine instead. This new quad core Q8300 should now see me through until next year, when the new architectures are released. Hopefully.

[watercooled]

It's an age old problem - the cost/return for the PC market is so much worse than console.

I thought that the move to x86* processors would make porting better.. but I fear what's it's done is make devs spend even less time on it because they can get away with a minimum now. That has its benefits in terms of getting PC ports where they may not have been viable before, but could mean we're missing out on optimising the experience.

That's not necessarily the case at all though - the consoles share a base ISA with PCs but the similarities largely stop there. You cannot take an executable compiled for a console and run it on PC, and nor can you just recompile it with some different compiler flags or minor tweaks. There really are huge differences between the platforms especially when it comes to data movement, and on top of that you even have issues like having complete freedom to use newer codepaths on the consoles like AVX - doing that on PC would either break compatibility with the majority of systems, or require multiple binaries.

A minimally optimised, barely-tested PC port will always be a minimally optimised, barely-tested PC port. I don't see how high-level ISA compatibility changes that TBH. Though it still always seems popular to 'blame the consoles' for any problems the PC platform has, because, you know, the PC is incapable of having problems of its own. (Not aimed at you BTW, just something I hear/read a lot)

[kalniel]

That's not necessarily the case at all though - the consoles share a base ISA with PCs but the similarities largely stop there. You cannot take an executable compiled for a console and run it on PC, and nor can you just recompile it with some different compiler flags or minor tweaks. There really are huge differences between the platforms especially when it comes to data movement, and on top of that you even have issues like having complete freedom to use newer codepaths on the consoles like AVX - doing that on PC would either break compatibility with the majority of systems, or require multiple binaries.

Indeed, but the differences are fewer and lesser than with the powerPC and Cell based architectures.

A minimally optimised, barely-tested PC port will always be a minimally optimised, barely-tested PC port. I don't see how high-level ISA compatibility changes that TBH. Though it still always seems popular to 'blame the consoles' for any problems the PC platform has, because, you know, the PC is incapable of having problems of its own. (Not aimed at you BTW, just something I hear/read a lot)

Well no - the lack of gamers willing to pay enough to justify the costs of such a diverse install base are the cause of issues on the PC. The consoles just give us a glimpse of what might have been

[watercooled]

Agreed on both points. I'd expect the similar ISA to somewhat reduce porting time, but like I say it's only a part of the issue. It might reduce the time to get some functional code but it's quite an orthogonal matter;
High-level functions may be compatible despite ISA and architectural differences.
Low-level functions or e.g. in-line assembly can potentially break even with these x86 consoles, an example being AVX code, anything relying on internal busses exclusive to consoles, any non-CPU code (these consoles have a ton of potential for GPGPU programming as well as onboard DSPs and various other coprocessors, the code for which could not be directly copy-pasted to PC).

So I would think it's entirely possible that ISA compatibility only concerns a minority of porting time.
One example of something susceptible to suboptimal porting would be code which is directly compatible (e.g. AMD64 integer) but also specifically, perhaps hand-optimised for Jaguar, taking architectural idiosyncrasies into account. In theory code like this should still run on other desktop CPUs, but performance may be suboptimal.

However, I'm nonetheless uneasy with the theory that x86 consoles=faster porting=worse ports. There are just too many variables to assume that. Even assuming the faster functioning ports part is true, why does that directly lead to worse ports? If devs aren't interested in making a decent PC port and thoroughly testing it, why would having to spend less time on code porting exacerbate that?

Just as there's a difference between getting x86-console code functional on PC, to getting it running well on PC, that still applies to the starting point being PPC, ARM, MIPS, etc. After all, it's not like we didn't have terrible ports from the PPC consoles!