Replies: 88 (Who?), Viewed: 14593 times.
Page 4 of 4
Test Subject
#76 Old 1st Nov 2020 at 2:24 PM Last edited by Vila : 1st Nov 2020 at 3:44 PM.
Lab Assistant
#77 Old 1st Nov 2020 at 8:05 PM
Well.

Oh c'mon. There better be a point to all this stress I'm under.
Inventor
#78 Old 1st Nov 2020 at 8:19 PM
EA is ass like they always was...No 64-bit version for pc user, cuz I think, they perfectly understands that will end up in dropped TS4 sales. A lot of disappointed players would go back to ts3 if it would run better.
Test Subject
#79 Old 2nd Nov 2020 at 11:46 PM
Any word on if this is actually running as a 64 bit application, or if it’s the same basically neutered cider-Esque emulation with a mask on?
Mad Poster
#80 Old 3rd Nov 2020 at 2:35 AM Last edited by igazor : 3rd Nov 2020 at 3:16 AM.
Quote:
Originally Posted by dockamorpher
Any word on if this is actually running as a 64 bit application, or if it’s the same basically neutered cider-Esque emulation with a mask on?

It's actually running as a 64-bit application, however they managed to accomplish it. Cider is just a bad memory now (pun intended), and there isn't supposed to be a 4 GB cap either. I haven't stressed my test games out far enough to require more than just around 2 GB yet as I'm still getting my content copied over and noting/confirming unexpected in-game bugs that are showing up like those listed a few posts back, but others are reporting Activity Monitors showing higher usage rates. And, in a few alarming instances, the game is calling for as much as 62 GB of RAM where the user only has 8 or 16 installed and the macOS is telling it to get lost (or actually telling the user that they are out of memory). That's just evidence of what can happen when there's no proper gate on system resources when a process gets stuck or starts running wild, whereas before the game might have limited things to some extent or just crashed much earlier on.

The game engine is not designed to handle much more stress than many players were already giving it, on Windows anyway, so many of us are looking forward to seeing what huge overly complicated worlds stuffed with more residents than we know we should have subjected to one kind of story progression or another are going to look like.
Lab Assistant
#81 Old 3rd Nov 2020 at 7:48 AM
So far looks like they did their normal amazing job.
Lab Assistant
#82 Old 3rd Nov 2020 at 4:02 PM
Quote:
Originally Posted by igazor
And, in a few alarming instances, the game is calling for as much as 62 GB of RAM where the user only has 8 or 16 installed and the macOS is telling it to get lost (or actually telling the user that they are out of memory). That's just evidence of what can happen when there's no proper gate on system resources when a process gets stuck or starts running wild, whereas before the game might have limited things to some extent or just crashed much earlier on.

Good grief, that actually sounds terrifying to me. What kind of long term effect can that have on the users hardware? And save stability? Knock on wood and all but hopfully that gets fixed asap.
Test Subject
#83 Old 9th Nov 2020 at 10:04 PM
https://answers.ea.com/t5/Technical...es/td-p/9711411

Quote:
Hey all y'all TS3 macOS Simmers!


It's been a pretty danged exciting week or two, hasn't it? A TS3 for macOS, 64-bit was released. There's been some surprising under-the-hood issues. I've heard rumors of some other things happening in the world too but I'm unclear of the details.


Here's what's new in the build rolling out today:


Build number: 1.70.305 (visible on the bottom of the Launcher app)

Updates button: No longer present on the Launcher screen

Packs/DLC not lighting up icons in Launcher: Works as expected if you are on Origin Beta/"Early Access" release. Will be fixed for everyone in next Origin update

Minimized/Hidden Game window makes macOS sluggish: If your Sims window is set to a large(ish) resolution (say, 1900x1200 or more on my Mac - yours may be different) and you minimize, or hide, or otherwise have the game window 100% off the viewable monitor, the the system could get really slow (sluggish Dock, slow text input, etc). This doesn't happen now

The .app icon is hidden/invisible: Not any more!

Stuck forever in "Finalizing": Not any more!

CMD-Z and CMD-Y repeat forever: Now they don't repeat at all. I think that's probably better. Hard to say!


And a note about entitlements: If you own The Sims 3 in your Origin "My Library" (for macOS or Windows), you should now have the 64-bit version for macOS as well. If you don't then that is not by design. Please reach out to Customer Support for help on that.
Test Subject
#84 Old 10th Nov 2020 at 1:11 AM
can EA just release the source code so modders can engineer a 64-bit Windows version?

(i know they actually won't do this, but still)
Scholar
#85 Old 11th Nov 2020 at 3:28 PM
Quote:
Originally Posted by igazor
It's actually running as a 64-bit application, however they managed to accomplish it. Cider is just a bad memory now (pun intended), and there isn't supposed to be a 4 GB cap either. I haven't stressed my test games out far enough to require more than just around 2 GB yet as I'm still getting my content copied over and noting/confirming unexpected in-game bugs that are showing up like those listed a few posts back, but others are reporting Activity Monitors showing higher usage rates. And, in a few alarming instances, the game is calling for as much as 62 GB of RAM where the user only has 8 or 16 installed and the macOS is telling it to get lost (or actually telling the user that they are out of memory). That's just evidence of what can happen when there's no proper gate on system resources when a process gets stuck or starts running wild, whereas before the game might have limited things to some extent or just crashed much earlier on.

That just sounds like you are describing a memory leak. That still doesn't have to mean that it has become a native 64 bit application though. I hope it does, because that might mean they use MacOS as test case before they consider bringing this to Windows.
Quote:
Originally Posted by igazor
The game engine is not designed to handle much more stress than many players were already giving it, on Windows anyway, so many of us are looking forward to seeing what huge overly complicated worlds stuffed with more residents than we know we should have subjected to one kind of story progression or another are going to look like.

I agree. The game engine is not designed to handle more stress, it is designed to cause it and we as players are destined to handle it

Anyway, I hope they manage to turn it into a 64 bit application that can handle more memory. If they can do that and fix the main issues, we might see it on Windows too. This could bring in more sales for TS3 too. I also doubt it would change much for TS4. People who invested in TS4 don't suddenly drop that game. TS3 will still need some prep to run well, even as 64 bit application. Without it, you just get more taxis and limousines spawned before your out of memory error Joking aside, I just mean it would not be some miracle fix
Test Subject
#86 Old 13th Nov 2020 at 4:34 PM
https://answers.ea.com/t5/Technical...ight/true#M8717

Quote:
Hey everyone! Deep breaths. Deep breaths.


Let's remember that we're all Simmers and we all want to be able to play a game we love.
Please keep that in mind as you post 'cause we're all on extra excitement already!


It's natural for every player to want to know if/when the platform they prefer to play on is going to get an update.
Unfortunately we simply can't comment on roadmaps that have not been announced.
I realize this is frustrating, but I really hope you'll understand our position.
If we speculate about what might be, or could be, or won't be, then to a certain extent we are making a commitment that we might not be able to deliver on. It is preferable to have all options open, allowing us to invest effort wherever we determine the most need exists.


macOS players, please let me be as clear as possible about what's in this release:
This is a compatibility release that will work on macOS releases that require 64-bit applications (it will ALSO work on macOS releases that support 32-bit applications, but as a 64-bit application their support for 32-bit won't matter).
This release also anticipates the eventual end-of-life of OpenGL that Apple has begun warning about beginning in the Mojave release when it was announced that OpenGL is deprecated in favor of Metal ("deprecated," in this context, typically means "works as expected for now but is unlikely to receive any support other than critical fixes that may become evident. You should move off of this technology as soon as possible before we remove it.")
While addressing these basic technology issues we've uncovered additional technologies that required updating (replacing an outdated WebKit library, making it easier to install and manage via Origin, rearranging where some files are stored in the file system).
We have not made in-game changes except where absolutely needed, and these changes are almost guaranteed to be invisible to you.
The biggest changes you should see in this update are:
It now runs on newer macOS (yay!), it is easier to install, if your game is especially complex or you have a lot of DLC then the game will utilize more of the available RAM on your Macintosh.
Having more memory available to work with, and moving to a new graphics interface in the operating system, MAY have some performance improvements. I make no promises.


Windows players, I know you want 64-bit. I really understand why and all the arguments you're making to justify the ask are valid (well, OK, most of them). You don't have to convince me that it would be very much appreciated and has been desired for a long time.
We are not doing a Windows update at this time.
We have not announced any plans to do so. Please see above for why.
Please also see the paragraph just above this one for a better understanding of what is and is not changing.
Test Subject
#87 Old 13th Nov 2020 at 4:47 PM
https://answers.ea.com/t5/Technical...ight/true#M8751
Quote:
https://answers.ea.com/t5/Technical...ight/true#M8738
Quote:
Thanks for your updates and explanations over all these months@MaxisJoe!
Because no one has asked yet, and because I'm very curious, I'm wondering if you could divulge some technical details:


After dropping Cider as the compatibility layer, did you rewrite things in Objective-C and/or Swift? Or, did you use .NET or something similar to call into Cocoa and Metal APIs instead? And/or, did you develop some kind of a transpiler?


If some of the source has been rewritten in ObjC and/or Swift, are there other performance improvements unrelated to the increase in the addressable memory size? For example, does automatic reference counting in ObjC and Swift help with memory deallocation, or does it get in the way of allocation? And, if some sources are now in Swift, does the game now take advantage of Swift's copy-on-write value semantics? Will the game automatically become more performant when new ObjC and Swift runtime come with macOS updates?

Are there some limits imposed to the game now that it's native, in order to preserve compatibility with Windows? For example, are there some restrictions on characters a user can type into a text field, so that things like save files created on macOS will have filenames recognisable by Windows?

Lastly, if I'm understanding your posts and guessing correctly, the first change we the users will see is that, when the game launches, there won't be multiple game icons jumping in and out of the dock anymore, right?



@teddywhoo Now there's a set of questions I hadn't expected to see. Cool


The primary intent has been to maintain the core of the application in as cross-platform a way as possible and to spend as little time in non-OS-centric code as possible. Largely the migration went from C++ to Obj-C and Obj-C++. Whether memory allocation/deallocation optimizations may have been realized as a result of the porting work is, honestly, outside the scope of what I was paying attention to so I can't meaningfully speak to it.


I do recall early in the porting effort some issues were raised about charsets. I don't recall if the problem was in the portability of file names, or if it was something more inside-the-game (names of assets that might be shared cross platform? Something else?), nor do I recall what the resolution was. I wish I could be more specific for you. Some of the more challenging porting work was migrating off of OpenGL and onto Metal. These are not as similar as you might think, and some amount of tuning was required (I'm positive there are some OpenGL tricks we used that may have artifacts in Metal that we just didn't notice during testing).


It might be easiest to think in terms of what our objectives with the update. At a really high level they were:
  • Do not limit or overly complicate what we can do on other platforms with decisions we take here
  • Maintain forward compatibility of file formats from prior versions (files from older versions still work)
  • Maintain cross-platform compatibility of file formats (files from this version work with Windows, and vice-versa)
  • Maintain service compatibility with existing game services (thesims3.com and its various services, CC, etc)
  • Do not make changes that require the minimum specification to disenfranchise large sets of players (don't end up with a MinSpec of "must be played on 2020 iMac Pro!")
  • Change only technologies that are needed to assure the longest possible functional life of this update (taking into account supported life cycle, security implications, etc) and
  • Don't change things just 'cause we're elbow deep in the code already

Or, to put it as succinctly as possible:
  • Do as much good as we can, as quickly as we can, with the least amount of collateral harm

I really do wish I go into more depth with you but this isn't quite the right time or place (there is, after all, a rather large milestone on my calendar for tomorrow morning).


As far as one, two (or three?) icons bouncing in your dock - that's still a thing. Watch 'em dance! We have not changed the basic structure of Launcher and Game, and of course Origin is required too. When you double-click on The Sims 3 in Finder you will see Origin launch, then hide. You will see the plumbob dance, then persist as Launcher presents itself. Once you place that plumbob will go away the main game window (its own process) will take over. If, in game, you you select Options -> Open Launcher then you will see both plumbobs in your Dock.

Also note: The first time you launch The Sims 3 you'll see Finder doing a "Verifying The Sims 3.app" (or some variation of this). This takes a while. It's macOS Gatekeeper verifying the signature/signing of the whole 7+GB bundle. That can take a while depending on your CPU, where the .app bundle is stored, and how fast the interface to that storage is.
Scholar
#88 Old 16th Nov 2020 at 11:09 PM
EA : 'Look at this candy!'

PC players : 'Yay, candy!'

EA : 'What are you cheering for?'

PC players : .. ..
Virtual gardener
staff: administrator
#89 Old 23rd Nov 2020 at 11:56 AM
Nerd talk here! :p

It's quite interesting that they dropped OpenGL altogether here, actually. But it also makes it more up-to-date  I noticed when I was looking at how EA changed TS4 to 64-bit (windows) that they'd switched from OpenGL to Vulkan, which by itself is not a terrible idea! That's actually one of the reasons why the shader comp files are quite different when it came to how the shaders would do their 'shader-y' thing because of the first chunks that basically say "hey this is what the graphics card/video card can do, do this and that with the pixels on the mesh, etc". For ts4 it's much bigger and has a lot more info going on. TS3's however is quite small and compact, which is because of OpenGL I believe. Vulkan is also much much more performance friendlier for modern computers than OpenGL is, as far as my research goes.

But that does make me wonder... which I know many have in this thread :p, that they could potentially use the mac 64-bit code as a reference at least to do the same for windows. And the reason that makes me believe that it could be possible is the following:

Quote:
The primary intent has been to maintain the core of the application in as cross-platform a way as possible and to spend as little time in non-OS-centric code as possible. Largely the migration went from C++ to Obj-C and Obj-C++. Whether memory allocation/deallocation optimizations may have been realized as a result of the porting work is, honestly, outside the scope of what I was paying attention to so I can't meaningfully speak to it.
Because it almost feels like here they're more talking about the engine itself (which is written in C++, interactions /script mods are the ones that are written in C#) That anything that had nothing to do with the engine per se was changed to Mac OS code. Especially since it seems as if the engine code isn't *actually* that big, which one can easily say since a lot of the file reading is done through C# scripts and then processed to be readable by the engine itself. Which is probably also why there were some interactions missing

This is just really a big hypothesis, so feel free to take it or leave it :p
Page 4 of 4
Back to top