• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
This has happen all the time, for example, when moving from windows 98 to windows XP, from windows XP to vista.. from vista to.. "If you upgrade the OS, the games stop working!".

Although in these case Microsoft was "the devil" for dropping the support (well, to be fair because the changed the core of the OS in these examples), but now in this case the devil are the lazy developers? In any case, I'm probably sure that the games that has actual support (from CK2 onwards) will have a 64 bits version even if the engine is not 64 bits native, dropping the old versions of the games (ask apple to implement a "beta tab" with older versions of the OS :eek::eek:, just kidding :)).
 
"is it worth making the 64-bit jump for only a year before you run into the OpenGL problem?"
And I think the answer for most cases (not only limited to PDS) is "No".

This has happen all the time, for example, when moving from windows 98 to windows XP, from windows XP to vista.. from vista to.. "If you upgrade the OS, the games stop working!".
o_O
I litterally have a copy of MoO2 on my HDD that was installed on my first PC (Windows 95), got copied and transfered from upgrade to upgrade and it still runs perfectly on Windows 10. Without DOSBox, mind you.
All I want to say: It's a bad example. And true, some games are having... issues... with more modern OS...
 
  • 1
Reactions:
This has happen all the time, for example, when moving from windows 98 to windows XP, from windows XP to vista.. from vista to.. "If you upgrade the OS, the games stop working!".

Note that with Windows, it has always supported backwards compatibilty. Very few games stop working because you upgrade the OS.

Although in these case Microsoft was "the devil" for dropping the support (well, to be fair because the changed the core of the OS in these examples),

The only time Microsoft 'dropped support' for anything that actually broke something was the removal of certain DRM functionality from the kernel in Windows 10. By and large 99% of games you've ever bought on windows XP, work on Windows 10.

[quote\]but now in this case the devil are the lazy developers?[/quote]

Bit of a straw man there. The point is that the effort to make very old games like CK2 64-bit compatible is not worth the financial cost. many developers are going to say "I am not going to spend 3-5 months migrating my game to 64-bit on Mac, so I can make $200 a month of sales"

In any case, I'm probably sure that the games that has actual support (from CK2 onwards) will have a 64 bits version even if the engine is not 64 bits native

That's not how this works. If a game, like CK2, is not compiled in 64-bit it WILL NOT WORK on future OSX versions. Period. The 32-bit libraries WILL NOT EXIST in future OSX versions. Games like CK2 WILL NOT WORK. Period.

And again I'd point out that there is no 'oh just push this button and a 64-bit exe comes out the other side', does not exist even in Unity. It seems unlikley that converting CK2 to 64-bit is worht it, or even possible given how old it is.
 
  • 1
Reactions:
https://www.theverge.com/platform/amp/2018/10/17/17990924/apple-mac-processors-2020-kuo-rumor

Oh by the way, all your games will also stop working on new Macs potentially starting in 2020

So on top of migrating to Metal,compiling to 64 bit, you now also have to support x86 and ARM for Macs too

That's just a rumour. It's been floating around in one form or another for several years now. Not only is it not worth doing anything about it, but you literally can't since ARM Macs don't exist....

Plus, it's not the first time Mac's have jumped processor architecture. I didn't use them last time, but I'm lead to believe that the transition to intel went smoothly, with excellent fast emulation tools supporting old software for years afterwards.

Let's stick with the known problems of 64 bit & Metal. And the question of "What current Paradox games are going to make the jump (if any)?". Because like the other Mac owners in this thread, I'm not sure I want to buy any more games or DLC without knowing if they'll still run this time next year...
 
That's just a rumour. It's been floating around in one form or another for several years now. Not only is it not worth doing anything about it, but you literally can't since ARM Macs don't exist....

The point being is that ARM is definitely coming to Macs. and that means EVERYTHING you own on a Mac will in the near future stop working on

Plus, it's not the first time Mac's have jumped processor architecture. I didn't use them last time, but I'm lead to believe that the transition to intel went smoothly, with excellent fast emulation tools supporting old software for years afterwards.

It kinda shows you weren't around because that migration was 99% terrible. And that was at a time when Mac usage was not main stream and mostly relegated to Marketing departments. Once Photoshop was migrated over most people stopped caring. That is NOT the case now.

https://store.steampowered.com/search/?category1=998&os=mac

There are 8000-9000 games on Steam that support the Mac. ALL OF THEM will stop working once Apple jumps to ARM. ALL OF THEM. Guess how many of those games are going to be recompiled to ARM? If you guessed "basically none" yes

This migration is going to look NOTHING like the migration from PowerPC to x86. Its going to be an unmitigated disaster.
 
  • 1
Reactions:
Is Boot Camp Assistant or a contemporary equivalent no longer a thing Mac side?

Or maybe I should be asking is it going to not be a thing in the near future, heh.
 
Last edited:
The point being is that ARM is definitely coming to Macs. and that means EVERYTHING you own on a Mac will in the near future stop working on

No, it's not "definitely" coming to Macs. It's a _rumour_. One that's been been repeated often enough & for long enough that the tech press rolls it's eye's at it these days. It might happen, but it's far from definite. It's more likely Apple have a prototype running & are using it as political capital against Intel in negotiations.

Also, they're not going to come & change over the CPU in existing Macs! Even if they did swap in 2020, it'll take a few years after that for the majority of the install base to shift. The MacOS shift to 64 bit & metal will affect most Macs in use, any ARM shift will only affect new Macs. It's a huge difference between "software stops working on hardware it's always run on" & "software never works on new hardware". Any shift to ARM will make *no difference* to if intel mac software keeps running on intel mac hardware....

Anyway, back on topic: the 64 bit & metal migrations are a particular problem for paradox & its long dlc support model. Most other games I'll play until I'm done with them & never come back to. Yeah, losing the option to play them again is irritating, but in practise no real loss. Stuff like Stellaris I'll play, leave for a while, then come back to & see what the new changes are. Losing that option will be painful.
 
Is Boot Camp Assistant or a contemporary equivalent no longer a thing Mac side?

Or maybe I should be asking is it going to not be a thing in the near future, heh.

Boot Camp is a pretty reasonable solution for getting 32-bit & OpenGL stuff working on current Mac hardware once MacOS drops support, though it'll cost you for the Windows copy.

Windows 10 ARM machines are available, so if hypothetical ARM Mac OS machines turn up Boot Camp could easily still be a thing, though it might be less useful letting Intel stuff work. I've no idea how well Microsoft's "running intel stuff on ARM chips" tech works in practice. A quick bit of research makes it look like ARM Windows doesn't support OpenGL or 64-bit Intel software.
 
Is Boot Camp Assistant or a contemporary equivalent no longer a thing Mac side?

Or maybe I should be asking is it going to not be a thing in the near future, heh.

Boot camp is only relevant if both OS have the same underlying architecture. Since OSX and windows both run on x86 it’s possible

This will not be the case once Apple migrates to ARM. Note that at that point only emulation is possible not native installs.

The only way is to emulate x86 on ARM and if you want to know how that looks like right now?

https://www.techspot.com/amp/review/1599-windows-on-arm-performance/page4.html

It’s BAD to the point of unusable for anything other than notepad.exe.
 
  • 1
Reactions:
It's worth noting that Apple customised ARM chips (like you find in the newest iPhones & iPads) are the fastest ARM chips around by quite a margin. But there's no reason to think that Apple can do a better job doing x86 on ARM emulation than Microsoft. So yeah, would still be pretty bad performance-wise.
 
Boot camp is only relevant if both OS have the same underlying architecture. Since OSX and windows both run on x86 it’s possible

This will not be the case once Apple migrates to ARM. Note that at that point only emulation is possible not native installs.

The only way is to emulate x86 on ARM and if you want to know how that looks like right now?

https://www.techspot.com/amp/review/1599-windows-on-arm-performance/page4.html

It’s BAD to the point of unusable for anything other than notepad.exe.
Technically, you can perform a JIT transformation of the code from x86 to ARM (or whatever). You only need to make sure that on the new platform the API function calls of the original source system still exist with the same parameters. It's not easy to pull off, but it can be done. If you do this, then the thus transformed application will run at (near) native speed on the new target platform. Depending on how easy one API translates into another.

From an engineering perspective, it's just another type of compiler. Not one that converts c++ into x86 (or ARM or whatever), but one that compiles x86 into ARM.
 
  • 1
Reactions:
Technically, you can perform a JIT transformation of the code from x86 to ARM (or whatever). You only need to make sure that on the new platform the API function calls of the original source system still exist with the same parameters. It's not easy to pull off, but it can be done. If you do this, then the thus transformed application will run at (near) native speed on the new target platform. Depending on how easy one API translates into another.

Note that's pretty much what MS is doing with the article indicated above

And the performance is basically 'utter garbage'

This is to be expected given that APIs and calls never actaully match up 'exactly'. let alone the instruction set underneath as well since x86 is CISC while ARM is a RISC instruction set. Same issues with their PowerPC conversion going from RISC to CISC.

You're also forgetting the problem of 64-bit conversion and the fact that OpenGL is basically going to be removed from Macs within 1-2 versions as well.

From an engineering perspective, it's just another type of compiler. Not one that converts c++ into x86 (or ARM or whatever), but one that compiles x86 into ARM.

This totally ignores nearly a dozen problems like
1) your middleware having several seizures because they don't actually exist on ARM
2) your graphical APIs not actually existing

You don't just clikc a radio button for "ARM" on the compiler and magically pop out a working build. That magic doesnt even wrok on Unity and that's on a platform custom designed for cross compatibility-ish.
 
Last edited:
  • 1
Reactions:
You don't just clikc a radio button for "ARM" on the compiler and magically pop out a working build. That magic doesnt even wrok on Unity and that's on a platform custom designed for cross compatibility-ish.
Actually, I do just that with my development tool.

One source pool. One framework. And from that I can target x86, x64, IoS and android.

Check out Embarcadero RAD Studio Enterprise ;)
 
  • 1
Reactions:
I don't see what's the discussion even

32bit suffers from being limited to 4GB of RAM. 64bit allows access to more RAM, which means more content available at once, regardless of CPU power

It's not about supporting Mac, it's about supporting more RAM
 
Actually, it's not

The Paradox title with the biggest memory footprint to date (Hearts of Iron 4) still only uses roughly 1.5 GB of RAM. That's not even close to half the max amount of memory accessible in 32 bits mode.

In other words, when looking at the amount of RAM needed, there is absolutely no reason to move to 64 bit.
 
  • 1
Reactions:
Actually, it's not

The Paradox title with the biggest memory footprint to date (Hearts of Iron 4) still only uses roughly 1.5 GB of RAM. That's not even close to half the max amount of memory accessible in 32 bits mode.

In other words, when looking at the amount of RAM needed, there is absolutely no reason to move to 64 bit.

Actually, it is. Technical RAM support has nothing to do with how much RAM currently being used. Even so, while current Paradox titles do not need large amount of RAM, it doesn't mean Paradox won't try to branch out to something that does.

For example, Age of Wonders III suffers memory issues on Linux due to being unable to implement their own heap manager, it's 32bit and is limited to 4GB of RAM. Once you've reached 4GB, usually from playing on larger maps, you'll crash. Age of Wonders: Planetfall will be launched as a full-fledged Paradox title, and I believe it'll support 64bit. It's technically not from Paradox Development Studios true, but it's a direct subsidiary of Paradox Interactive
 
I don't see what's the discussion even

32bit suffers from being limited to 4GB of RAM. 64bit allows access to more RAM, which means more content available at once, regardless of CPU power

It's not about supporting Mac, it's about supporting more RAM

Again this kind of ignore the entire 'there is no magic flag that makes a working 64-bit exe pop out the other side'

note hte 'working' part. You can set a flag to compile in 64-bit and then watch the compiler basically have a seizure as you realize "oh yeah all this other stuff I've been using isn't 64-bit......"
 
  • 1
Reactions:
Actually, I do just that with my development tool.

One source pool. One framework. And from that I can target x86, x64, IoS and android.

Check out Embarcadero RAD Studio Enterprise ;)

There's a difference between

* There is a radio button that compiles ARM

vs

* What comes out the other end actually works
 
  • 1
Reactions: