57 replies to this topic

[Ralgas]

Fooooo, on 02 May 2013 - 03:53 AM, said:

They stated a while ago that they have no plans to compile a 64bit executable for MWO anytime soon, if ever.

So in that sense, the game will always be stuck as 32bit.


Although they have changed their minds before on things they said would never happen....................

Depends on how hard it is for the flash/.net framework is to get working in a 64 bit enviroment without seperating them (which may not be possible without a full rewrite). Theres a argument for seperating a true 64 bit version when the alternative is their product not working on most gaming systems built in the last 4 or so years.

Expecting the playerbase to run dual boot or restrict their systems to 4 gb ram (a limitation of 32 bit os's) would only mean the death of much of the playerbasewith mid to high end systems.

Edit: and of course it needs to be verified it is the fix, while i dont doubt Kataris thats only 1 os that we know of and it still needs over time testing......

BTW Kataris, if you are following this which os did you use to test?

Edited by Ralgas, 02 May 2013 - 05:14 AM.

[Krzysztof z Bagien]

Funny thing: minimum RAM requirement to run MWO is 4GB, recommended is 8GB.
32bit versions of Windows* can't use more than 4GB, so to meet recommended requirements you need 64bit Windows. But then you have HUD bugs all the time.
Also, I belive that even if you have 64bit system, single 32bit application can't even use 4GB of RAM.
___
* well, some versions of Win Server actually can I belive.

[Ralgas]

Krzysztof z Bagien, on 02 May 2013 - 05:19 AM, said:

Funny thing: minimum RAM requirement to run MWO is 4GB, recommended is 8GB.
32bit versions of Windows* can't use more than 4GB, so to meet recommended requirements you need 64bit Windows. But then you have HUD bugs all the time.
Also, I belive that even if you have 64bit system, single 32bit application can't even use 4GB of RAM.
___
* well, some versions of Win Server actually can I belive.

the x64 bit os can assign the 4? gb to each 32bit process active though i believe, so assuming you have the system ram spare your still better off as it doesn't have to share with the residents unlike the x86.

Edited by Ralgas, 02 May 2013 - 05:48 AM.

[MajorChunks]

Krzysztof z Bagien, on 02 May 2013 - 05:19 AM, said:

* well, some versions of Win Server actually can I belive.

32 versus 64 is not just a window thing: It's a hardware architecture thing that occurs on all OS's, Linux and Mac included. The difference is simply that 32-bit systems use 32 bits for memory addressing (2^32 possible addresses), whereas 64-bit uses 64 bits (2^64 possible addresses). That's why the 4GB limit exists, since on a 32-bit system you literally run out of addresses for any amount of memory over that amount. The limit in 64-bit systems is...larger

THE MORE YOU KNOW

On topic, though, I would assume that the problem does not lie in 32-bit versus 64-bit versions of Windows, since Windows is for the most part smart enough to figure that stuff out as Ralgas mentioned. I'm going to go with the Adobe 64-bit binaries refusing to play nice with some obscure portion of Scaleform at the memory-access level. Some low-level optimization gone haywire or something, most likely. It's also probably safe to assume that PGI knows or at least suspects this, but is trying to fix it "correctly" (i.e. make it run with the 64-bit Adobe binaries) rather then requiring or enforcing the 32-bit binaries - That's what I would do personally, but then again I'm really picky like that.

[Krzysztof z Bagien]

Ralgas, on 02 May 2013 - 05:47 AM, said:

the x64 bit os can assign the 4? gb to each 32bit process active though i believe, so assuming you have the system ram spare your still better off as it doesn't have to share with the residents unlike the x86.

Ah, yes, you're right. 2GB is default value, but it can be 4GB with IMAGE_FILE_LARGE_ADDRESS_AWARE flag set for that process. I'm assuming MWO has it set.

Edit: I checked that, it has.

MajorChunks, on 02 May 2013 - 06:22 AM, said:

32 versus 64 is not just a window thing: It's a hardware architecture thing that occurs on all OS's, Linux and Mac included. The difference is simply that 32-bit systems use 32 bits for memory addressing (2^32 possible addresses), whereas 64-bit uses 64 bits (2^64 possible addresses). That's why the 4GB limit exists, since on a 32-bit system you literally run out of addresses for any amount of memory over that amount. The limit in 64-bit systems is...larger

Some versions of 32bit Windows use PAE to make using more then 4GB of RAM possible (first version of XP had it, but it was disabled in SP1 as it was causing trouble).

Edited by Krzysztof z Bagien, 02 May 2013 - 02:00 PM.

[Robin Wolf]

Flash? OMG!

[MajorChunks]

Krzysztof z Bagien, on 02 May 2013 - 06:24 AM, said:

Some versions of 32bit Windows use PAE to make using more then 4GB of RAM possible (first version of XP had it, but it was disabled in SP1 as it was causing trouble).

Oh cool, I didn't know that. I'm honestly useless with Windows. If I could reliably run MWO in wine on Linux, I would. But I can't, so here I sit...

[Krzysztof z Bagien]

MajorChunks, on 02 May 2013 - 06:43 AM, said:

Oh cool, I didn't know that. I'm honestly useless with Windows. If I could reliably run MWO in wine on Linux, I would. But I can't, so here I sit...

MWO - teaches, educates and expands your horizons since 2012

[TheSupergeek]

Downgrading my OS or reinstalling libs and etc. as 32-bit versions is obviously not a solution. I know that running Photoshop CS6 at the same time as MWO will completely Fubar MWO. (However, Photoshop still works...)

If other games have implemented Flash HUDs successfully, PGI needs to talk to the CryEngine folks or these other developers that know what they're doing and figure out what they're doing wrong.

Edited by TheSupergeek, 02 May 2013 - 08:19 AM.

[DCLXVI]

bump for a great justice

[Lugh]

Kataris, on 01 May 2013 - 05:00 PM, said:

Okay, after testing throughout the day. I do not receive HUD bugs at all. I do however, get a CTD about every 7-15 matches. I believe this is probably due to running a 64 bit windows, and I will be reinstalling tonight to 32 bit and will further test. Perhaps MWO simply will not work in a 64 bit environment.

False I ran just fine in the 64 bit environment in closed beta. I've only been having trouble since 1/5 with the game client.

Forceing the game client to run in 32 bit mode, with XP SP3 emulation doesn't solve the game crash issues currently occurring either. Been there done that. No change.

Edited by Lugh, 02 May 2013 - 08:42 AM.

[Sibs]

Lugh, on 02 May 2013 - 08:41 AM, said:

False I ran just fine in the 64 bit environment in closed beta. I've only been having trouble since 1/5 with the game client.

Forceing the game client to run in 32 bit mode, with XP SP3 emulation doesn't solve the game crash issues currently occurring either. Been there done that. No change.

It's amazing that you think you've done a full investigation of the issue. You need to work on your reading comprehension.

The 32-bit mode solution was reported to prevent HUD-issues, and not the CTD issues. You seemed to mix that up.

Good luck in summer school.

[Sand Lantern]

Would love to see an official dev response to this post (take you're time if you're looking into the information, I understand there's a lot to work through).

[MajorChunks]

Well, regardless if the adobe binaries are really the cause of all this, according to The Twitter it seems like a fix is coming down the pipe shortly. So hopefully we'll know for sure soon enough.

TheSupergeek, on 02 May 2013 - 08:19 AM, said:

I know that running Photoshop CS6 at the same time as MWO will completely Fubar MWO. (However, Photoshop still works...)

This makes me laugh and cry at the same time. Hey, at least we don't have to deal with Adobe Air, unlike that other F2P game...

[Sean Cove]

In terms with the HUD / UI, using Cryteks integration of Scaleform flash player( which can be built for 32bit and 64bit ). So your local install of adobe flash player is not used within MWO at all.

For the HUD corruption issue, myself and a couple other engineers are currently looking into the HUD corruption issue, and it currently is looking like a logic error within the engine which is proving difficult to debug and fix. It is separate from the CTD issue.

[Ralgas]

Sean Cove, on 02 May 2013 - 12:57 PM, said:

In terms with the HUD / UI, using Cryteks integration of Scaleform flash player( which can be built for 32bit and 64bit ). So your local install of adobe flash player is not used within MWO at all.

For the HUD corruption issue, myself and a couple other engineers are currently looking into the HUD corruption issue, and it currently is looking like a logic error within the engine which is proving difficult to debug and fix. It is separate from the CTD issue.

Sean, are you seeing the same issues in 32bit os's though on your side? (ie is setting up a dual boot worth it till a fix comes through?)

[ArcDemon]

Sean Cove, on 02 May 2013 - 12:57 PM, said:

In terms with the HUD / UI, using Cryteks integration of Scaleform flash player( which can be built for 32bit and 64bit ). So your local install of adobe flash player is not used within MWO at all.

For the HUD corruption issue, myself and a couple other engineers are currently looking into the HUD corruption issue, and it currently is looking like a logic error within the engine which is proving difficult to debug and fix. It is separate from the CTD issue.

Interestingly I just came here from reading the CryEngine documentation after I found the section on converting flash files to .gfx so they could be rendered with Scaleform GFx. Very relieved that my original assumption was correct and a major game engine is not using Adobe's appalling Flash OCX lib, a little spooked that a dev posted the exact same thing just 30 minutes ago.

[Sean Cove]

Ralgas, on 02 May 2013 - 01:24 PM, said:

Sean, are you seeing the same issues in 32bit os's though on your side? (ie is setting up a dual boot worth it till a fix comes through?)

I do not have a reason to believe that 32 bit or 64 bit os would effect the repro of the HUD issue.

There is a indication that memory usage does affect the frequency of the issue happening, that is the closer to 100% memory usage the frequency goes up. Though this is currently unconfirmed.

[Zolaz]

Sean Cove, on 02 May 2013 - 12:57 PM, said:

For the HUD corruption issue, myself and a couple other engineers are currently looking into the HUD corruption issue, and it currently is looking like a logic error within the engine which is proving difficult to debug and fix. It is separate from the CTD issue.

Looks like everything is going well over in PGI.

[Hovertank]

Krzysztof z Bagien, on 02 May 2013 - 01:06 AM, said:

Makes me think devs don't know what they're doing.

Q.F.E.