50 réponses à ce sujet

[FrozenDawn]

I am running on win 7 64 bit and its going pretty well. dont think I had crashes so far.
Maybe ur problem is something else?

[mjordan79]

vania z wrote...

mjordan79 "In fact, it's a driver problem."
Are you trying to tell me, that it was impossible to make it work on nvidia? I wonder, how other games worked. It had to be by sheer chance that every other game worked.
Also, scripting bugs do not depend on configuration. Tbh, very little depends on configuration apart graphics card vendor and os version.

No, I'm telling you that the slowdowns (in DirectX 11 mode) are caused by an nVidia driver bug (resolved in the latest beta drivers).

[vania z]

And I tell you, that slowdowns are caused by lack of testing on bioware/EA part.
They could have resolved issues themselves. And they promised they had, when they released demo of da2. 

Modifié par vania z, 20 mars 2011 - 02:06 .

[passionata]

Sadinar wrote...

This thread is filled with a lot of very bad information.

A 32-bit system simply means a single word in memory holds 32-bits. On the other hand, a 64-bit system's words are all 64-bits long. Since a 32-bit word obviously fits inside a 64-bit word, there is absolutely no problem running a 32-bit program on a 64-bit machine. The reverse, however, is not true and a 64-bit application would absolutely not work on a 32-bit system.

I agree that there is a lot of false Information in this thread including in your statement (at least it is misleading to a false conclusion)!
A 16bit word would easily fit into a 64bit word but you will not be able to run a 16bit application on your 64bit OS
Reason: http://msdn.microsof...249(VS.85).aspx

[EmeraldViper]

I also am playing on Windows 7 64 bit with know major issues(some fps issues once in awhile)

Windows 7 64 bit
AMD 940 oc'd 3.7 GHz
8G DDR 3 (1300)
NVidia 460 GTX (2GDDR5)

[xoxiin]

passionata wrote...

Sadinar wrote...

This thread is filled with a lot of very bad information.

A 32-bit system simply means a single word in memory holds 32-bits. On the other hand, a 64-bit system's words are all 64-bits long. Since a 32-bit word obviously fits inside a 64-bit word, there is absolutely no problem running a 32-bit program on a 64-bit machine. The reverse, however, is not true and a 64-bit application would absolutely not work on a 32-bit system.

I agree that there is a lot of false Information in this thread including in your statement (at least it is misleading to a false conclusion)!
A 16bit word would easily fit into a 64bit word but you will not be able to run a 16bit application on your 64bit OS
Reason: http://msdn.microsof...249(VS.85).aspx

^This.

The problem is that this whole thing stems from bad information, which would be just about anything technical coming from EA support. It's the equivalent of asking a 3-year-old for relationship advice. The best place to get support for Bioware games would be these forums. In all likelihood the game was built on 64-bit systems, and the problems with this game are not exclusive to 64-bit.

[Sadinar]

passionata wrote...

I agree that there is a lot of false Information in this thread including in your statement (at least it is misleading to a false conclusion)!
A 16bit word would easily fit into a 64bit word but you will not be able to run a 16bit application on your 64bit OS
Reason: http://msdn.microsof...249(VS.85).aspx

A 64-bit machine (this is a generic term, not specifically Windows 7) could easily could run 16-bit applications if it wanted to using the techniques I already mentioned. Instead of catching and sign extending only 32-bit data, it could do so with 16-bit data as well. For that matter, it could do it for 24-bit applications also (yes, they existed ever so briefly). Any word that is not caught and sign extended would obviously contain garbage for the bits between the last bit of the uncaught word and the 64th bit of the word in memory resulting in an incorrect number being stored.

Bringing up applications written for systems using less than 32-bit is entirely beside the point. Which types of applications to backwardly support is entirely up to the OS developer and Microsoft has clearly chosen not to support software that has been outdated since windows 3.1. The lack of support for words comprised of any random number less than 64 inside Windows 7/ Vista does not change anything I said before nor alter the explanation of how it works.

If you wanted to make a more valid nitpicking argument, you could have mentioned the fact that 32-bit Windows drivers will not work on the 64-bit version of Windows even though 32-bit data fits within a 64-bit space. Since drivers communicate directly with the hardware, the OS is unable to capture the data on the hardware end and sign extend it before it goes into memory resulting in garbage remaining in the upper 32-bits of the stored word. Again, this is not important to the discussion here because Windows x64 should not allow you to install 32-bit drivers in the first place and if you somehow hacked it together, it would fail well before trying to play a video game.

If you really want to know how all of this works, pick up a copy of Computer Organization and Design by Patterson and Hennessy. It is an undergrad text book, but don't expect light reading!

[PSUHammer]

vania z wrote...

Obviously, they didn't test the game at all before release. Mourning bug has near 100% chance of occurring, dx11 was not working on nvidia, almost all systems had missing drive bug with dx11 and so on. They just couldn't miss it, if they tested.

I didn't have any of those...I am running WIndows 7 x64 with an Nvidia GTX 570 and the game runs great.  Especially since installing the Beta Nvidia driver released on the game's release date.

I would think there are other things that could be causing some of these.  I think the missing drive bug was single core processor related?

[Mongoose22]

vania z wrote...

Obviously, they didn't test the game at all before release. Mourning bug has near 100% chance of occurring, dx11 was not working on nvidia, almost all systems had missing drive bug with dx11 and so on. They just couldn't miss it, if they tested.

If they really didn't test before release, the game likely wouldn't even run.  Modern games have millions of lines of code, thousands of data files, and PC testing is a complete nightmare; no testing facility has every combination of every compatible PC component in every machine sitting around.  Which is why QA likely gave more precedence to console; they're both easier to test for because the hardware is consistent, plus they're harder to patch later because Microsoft and Sony charge fees for console patches.

Which isn't to say bugs are fine, because they suck, but I've not met anyone who didn't try their darndest to squash them all before ship.  Even QA has pride in their work.  But there's a good reason PC games tend to have way more bugs than console games: the platform is inherently unstable.  Your compatibility testing is only as good as the number of rig configs the facility has.

[DABhand]

I am surprised Goran hasnt been in here yet

But there is no 5-15fps for wow6432 emulation, 32bit programs can run easily within a 64bit environment.

As for a dedicated 64bit binary (tech speak for executable files) for the game it is possible as for a difference in performance, not much. Except for a couple of instances like value calculation. Things like the rendering engine etc won't be affected, neither will any type of GPU function.

Just letting you know

[DABhand]

xoxiin wrote...

passionata wrote...

Sadinar wrote...

This thread is filled with a lot of very bad information.

A 32-bit system simply means a single word in memory holds 32-bits. On the other hand, a 64-bit system's words are all 64-bits long. Since a 32-bit word obviously fits inside a 64-bit word, there is absolutely no problem running a 32-bit program on a 64-bit machine. The reverse, however, is not true and a 64-bit application would absolutely not work on a 32-bit system.

I agree that there is a lot of false Information in this thread including in your statement (at least it is misleading to a false conclusion)!
A 16bit word would easily fit into a 64bit word but you will not be able to run a 16bit application on your 64bit OS
Reason: http://msdn.microsof...249(VS.85).aspx

^This.

The problem is that this whole thing stems from bad information, which would be just about anything technical coming from EA support. It's the equivalent of asking a 3-year-old for relationship advice. The best place to get support for Bioware games would be these forums. In all likelihood the game was built on 64-bit systems, and the problems with this game are not exclusive to 64-bit.

Let me add to this..

As said the 16bit value can fit into 64bit memory space, of course it can. As for the 16bit program -- thats an entirely different ship.

You cannot compare values and programming --- its 2 different things And one major reason why 16bit is not supported in Windows OS's these days is the fact of file size comes into it, 16bit cannot support 4gb sizes of 32bit OS's, only Windows 98 and Me managed that without being an NTFS based disc structure. It did use FAT32 compared to the old fashioned FAT16, but it was never really truly 4GB file sizes just a cheating way of doing it

Also people are getting mixed up on WORD sizes..

8bit sized value = BYTE
16bit sized value = WORD
32bit sized value = DWORD
64bit sized value = QWORD

Modifié par DABhand, 21 mars 2011 - 03:13 .

[Sadinar]

DABhand wrote...

Let me add to this..

As said the 16bit value can fit into 64bit memory space, of course it can. As for the 16bit program -- thats an entirely different ship.

You cannot compare values and programming --- its 2 different things And one major reason why 16bit is not supported in Windows OS's these days is the fact of file size comes into it, 16bit cannot support 4gb sizes of 32bit OS's, only Windows 98 and Me managed that without being an NTFS based disc structure. It did use FAT32 compared to the old fashioned FAT16, but it was never really truly 4GB file sizes just a cheating way of doing it

Also people are getting mixed up on WORD sizes..

8bit sized value = BYTE
16bit sized value = WORD
32bit sized value = DWORD
64bit sized value = QWORD

That is not true. While 8 bits is always a byte, word size is system dependent and determined by the hardware, not the software. A 64-bit CPU's data registers are all 64-bits long therefore all words are 64-bits long. Likewise, older computers had 16-bit words because all registers were 16-bits long. Before 16-bit words, computers actually used 8-bit words. Thanks to encapsulation and layering, word size is completely transparent to the upper levels including high level programming languages. As far as double and quad words, they are simply the system word size times two and system word size times four. The values you quoted were from computers from the late eighties and early nineties by the way.

I have no idea what you mean by saying programming and values are not related. Programs are nothing but a very long sequence of values. All instructions, program data, and user data are stored as uninterupted strings of binary values, so programming and data values are actually very closely linked. A 16-bit application and a 16-bit OS are two completely different things and since the OS is responsible for all memory management, a 16-bit application can run just fine on modern hardware. Look at DOS-box, which allows even 8-bit applications to run on modern hardware, for a clear example and simple proof of this. As Xoxiin already pointed out, just because it is possible does not mean it is automatically supported by a particular OS.

Again, the book I already mentioned explains all of this in complete detail and it has absolutely nothing to do with this thread.

Modifié par Sadinar, 21 mars 2011 - 04:30 .

[DABhand]

A 32bit sized value is indeed a DWORD - or Double Word. QWORD will be self explanatory

Especially when it comes to debugging..

MOV DWORD PTR [EAX],00

is not the same as

MOV WORD PTR [EAX],00

EDIT: Didn't expect me to spout out Assembly at you did you

Modifié par DABhand, 21 mars 2011 - 04:26 .

[Notick]

Draconus Kahn wrote...

I have this quote posted in another post, but since I believe this more than warrants its own post, here it is again.

There
is no 64bit support, and here is a direct quote from a Bioware tech
support agent in response to problems I have been having with crashes
and keyboard interface issues (all in the quote):

"Thank you again for contacting Tier 2 Customer Support.

I apologize for the inconvenience caused to you so far.

I
have gone through the e-mail and found that you are facing problem with
the crashing of the game "Dragon Age II". I am sorry to hear that you
came across such an incident.

Unfortunately the game is not
tested on Windows 7 or 64 bit environment. There is a work around that
you can try but still there is no guarantee about it. You can try to run
the game as administrator, to run the game as administrator:

1. Right-click on the shortcut icon of the game on your desktop.
2. Choose the option "Run as Administrator".
3. Choose to allow the game.

If
the game still not runs properly, Please try to play it in
Compatibility mode. Please visit the following link for the steps to
play the game in compatibility mode:
http://www.sevenforu...ility-mode.html

I truly appreciate your understanding regarding the issue.

We look forward for your reply.

Regards,

EA Rep Andrew
Tier 2 Customer Support
Customer via via CSS Web 03/08/2011 03:41 PM
My
game hangs, crashes, and then restarts after minutes of gameplay when I
am at very high settings and 720p with MSAAx4. I have also had a
bluescreen crash because of this issue. I have the latest drivers from
my manufacturer (Alienware) as well. If I set the game to high settings,
then the game plays fine.

Another issue I am having is my
keyboard movement in game. It runs very choppy with a rubberbanding
effect on frame rates whenever I use it to turn the camera and move my
character. If I use my mouse for movement and camera, I have no issues
with frame rate, but as soon as I need to take control with my keyboard,
it's a mess."


Here are my specs:

Alienware Aurora
i7 920 @ 3.6ghz OC'ed (turbo on)
Radeon HD 5970 (2gb VRAM--dual gpu)
6gb RAM
Realtek HD audio (onboard. up to date drivers)
Windows 7 64bit

Get a patch out to us ASAP BioWare; This is rediculous.

I play this game on Windows 7 Ultimate - 64bit Edition with absolutely no issues what-so-ever.



Two suggestions (9 years of IN FIELD tech support for high end Gaming rigs, Commercial rigs, and private-sector support.)

• Turn TURBO off of your CPU. (It's silly to have on if you're already OC'd... The purpose of this is to ramp up usage if needed... Which it isn't. It can also spike temperatures to cause a falure in software)
• Lower any OC from your graphics card (even if it's 'factory' OC) and create a 'profile' with the catalyst software to run at 100% fan potential while this game is running. Also, remove the heat-sink and put good TIM on it. (I'd forward you to www.hardforum.com and ask the HardOCP guys why this is important.)

Modifié par Notick, 21 mars 2011 - 04:43 .

[Sadinar]

DABhand wrote...

A 32bit sized value is indeed a DWORD - or Double Word. QWORD will be self explanatory

Especially when it comes to debugging..

MOV DWORD PTR [EAX],00

is not the same as

MOV WORD PTR [EAX],00

EDIT: Didn't expect me to spout out Assembly at you did you

Assembly language is not a high level language and you must use the correct type of assembly language for your execution environment. For example, PCSPIM is a free MIPS emulator available on sourceforge, which provides a 32-bit assembly execution environment. The emulator will clearly show you the size of all words is 32-bits.

Execute the following program and watch the value of the data area where the all 0's word value has its lower half word replaced by all F's and count it out if you don't believe me:

               .data
storage:.word 0                                          #initial value of "storage" in the data area is 00000000
       
              .text
main:    addi $t0, $zero, 0xFFFFFFFF     #sets $t0 to the maximum value, ffffffff
              sh $t0, storage                             #overwrite storage's low halfword with low halfword stored in $t0
           
              li     $v0, 10   
              syscall                                            #exit

I am sure you already know this, but every hex character is a shorthand to represent four bits. So, eight hex characters is thirty two bits. As you can clearly see after executing the program, storage's last four hex characters were changed which means a half word is four times four or 16-bits.

I am quite familiar with assembly and can provide additional examples via PM if you really want to continue this.

With the variety and sophistication of modern IDEs and debugging tools, no one in their right mind would debug using assembly anyway. All of your high level instructions are converted to a series of assembly instructions which you have no control over and do not clearly correlate to the high level instructions you entered through your code.

Modifié par Sadinar, 21 mars 2011 - 05:17 .

[DABhand]

PCSPIM = yuck.

mASM is better in that regards plus the added bonus of being a compiler too.

I didn't come in for a who knows Assembly better contest, I shown what I said as an example of how it is necessary, and the CPU Mnemonics do recognise BYTE,WORD,DWORD and QWORD. That is fact.

You can use any debugger you want, they will all show the same thing the declaration of size.

Moving specific sized values will be register dependent if you wish to only change the size part of the register.

For instance

MOV EAX, FFEEDDCC
MOV AX, DDCC
MOV AH, DD
MOV AL, CC

Obviously

MOV AL,EBX won't work different size types.. so you have to force the size

MOV AL, BL.. Or use XCHG EBX,AL

Anyways....

The windows API will always always always refer to 16bit values as WORD size. No if's but's or maybe's about that.

And the CPU can't operate on blind instruction on sizes, they MUST be defined.

[Sadinar]

It doesn't matter how many times you repeat it, you are wrong. Even the wikipedia page clearly shows that you are wrong and word size varies by CPU independently of the OS. Just because one assembly language uses 16-bit words, that does not mean they all do. This discussion is going nowhere, so this will be my last post on the subject.

[DABhand]

You're basing your facts on wikipedia... lordy. Thought you learned your stuff lol

You mean that its your last post because I am Winning Charlie Sheen style..

Lets see what Wiki has to say..

Oh look on your wiki page you love

"For example, Microsoft's Windows API maintains the programming language definition of WORD as 16 bits, despite the fact that the API may be used on a 32- or 64-bit x86 processor, where the word size would be 32 or 64 bits, respectively. Data structures containing such 32- or 64-bit words are referred to as DWORD and QWORD respectively. A similar phenomenon has developed in Intel's x86 assembly language – because of backward compatibility in the instruction set, some instruction mnemonics carry "d" or "q" identifiers denoting "double-", "quad-" or "double-quad-", which are in terms of the architecture's original 16-bit word size."

Thanks, end of line.

Now see that word Mnemonic... thats the CPU's instruction set... can't change that no matter the OS. Your argument is flawed.

Cheerio

[Draconus Kahn]

Notick wrote...

Draconus Kahn wrote...

I have this quote posted in another post, but since I believe this more than warrants its own post, here it is again.

There
is no 64bit support, and here is a direct quote from a Bioware tech
support agent in response to problems I have been having with crashes
and keyboard interface issues (all in the quote):

"Thank you again for contacting Tier 2 Customer Support.

I apologize for the inconvenience caused to you so far.

I
have gone through the e-mail and found that you are facing problem with
the crashing of the game "Dragon Age II". I am sorry to hear that you
came across such an incident.

Unfortunately the game is not
tested on Windows 7 or 64 bit environment. There is a work around that
you can try but still there is no guarantee about it. You can try to run
the game as administrator, to run the game as administrator:

1. Right-click on the shortcut icon of the game on your desktop.
2. Choose the option "Run as Administrator".
3. Choose to allow the game.

If
the game still not runs properly, Please try to play it in
Compatibility mode. Please visit the following link for the steps to
play the game in compatibility mode:
http://www.sevenforu...ility-mode.html

I truly appreciate your understanding regarding the issue.

We look forward for your reply.

Regards,

EA Rep Andrew
Tier 2 Customer Support
Customer via via CSS Web 03/08/2011 03:41 PM
My
game hangs, crashes, and then restarts after minutes of gameplay when I
am at very high settings and 720p with MSAAx4. I have also had a
bluescreen crash because of this issue. I have the latest drivers from
my manufacturer (Alienware) as well. If I set the game to high settings,
then the game plays fine.

Another issue I am having is my
keyboard movement in game. It runs very choppy with a rubberbanding
effect on frame rates whenever I use it to turn the camera and move my
character. If I use my mouse for movement and camera, I have no issues
with frame rate, but as soon as I need to take control with my keyboard,
it's a mess."


Here are my specs:

Alienware Aurora
i7 920 @ 3.6ghz OC'ed (turbo on)
Radeon HD 5970 (2gb VRAM--dual gpu)
6gb RAM
Realtek HD audio (onboard. up to date drivers)
Windows 7 64bit

Get a patch out to us ASAP BioWare; This is rediculous.

I play this game on Windows 7 Ultimate - 64bit Edition with absolutely no issues what-so-ever.



Two suggestions (9 years of IN FIELD tech support for high end Gaming rigs, Commercial rigs, and private-sector support.)

• Turn TURBO off of your CPU. (It's silly to have on if you're already OC'd... The purpose of this is to ramp up usage if needed... Which it isn't. It can also spike temperatures to cause a falure in software)
• Lower any OC from your graphics card (even if it's 'factory' OC) and create a 'profile' with the catalyst software to run at 100% fan potential while this game is running. Also, remove the heat-sink and put good TIM on it. (I'd forward you to www.hardforum.com and ask the HardOCP guys why this is important.)

[*]Already tried turbo off, and since my card isn't OC'ed your other point is moot. With Cat. AI off, the game runs worse, and the issue remains the same. Also, I have experienced marked increase in frame rate on many of the games I play with turbo on, so it stays on. My cooling system is very good, and honestly, I ran laps around Prime 95 for over 24hrs without a single hickup in temperature. It is also worth noting that other people with many different setups have the same problem as I have. Check it out here: http://social.biowar...index/6438943/1

[Silver]

forget it, post is moot...

Modifié par silverhammer08, 22 mars 2011 - 03:37 .

[Notick]

Actually, Draconus Kahn, my 2nd point isn't moot. I've had 100's (Yes - literally 100's) of graphics cards that over-heat with their stock coolers and TIM on them (Including non-overclocked cards). Easiest way to test this is by backing the Clock speed's down.

Try it... You may be surprised.

[Draconus Kahn]

Already have. I was trying to point out that my card does not overheat on stock settings. Point moot. 100% fan speed is unrealistic as well. The noise drives me crazy. It's a redundancy that is not needed on my system. My airflow is good enough to where if I had to set manual fan speed, 50% is the most I need. Tried, tested, and true.

[Sekhem]

DABhand wrote...

You're basing your facts on wikipedia... lordy. Thought you learned your stuff lol

You mean that its your last post because I am Winning Charlie Sheen style..

Lets see what Wiki has to say..

Oh look on your wiki page you love

"For example, Microsoft's Windows API maintains the programming language definition of WORD as 16 bits, despite the fact that the API may be used on a 32- or 64-bit x86 processor, where the word size would be 32 or 64 bits, respectively. Data structures containing such 32- or 64-bit words are referred to as DWORD and QWORD respectively. A similar phenomenon has developed in Intel's x86 assembly language – because of backward compatibility in the instruction set, some instruction mnemonics carry "d" or "q" identifiers denoting "double-", "quad-" or "double-quad-", which are in terms of the architecture's original 16-bit word size."

Thanks, end of line.

Now see that word Mnemonic... thats the CPU's instruction set... can't change that no matter the OS. Your argument is flawed.

Cheerio

Because the whole world is x86/Windows, right?  When programming for architectures other than x86 and for OS API's other than Windows, Word size can (and does!  Thanks Sparc64!) change dramatically.

[mikey3k]

Sekhem wrote...

DABhand wrote...

You're basing your facts on wikipedia... lordy. Thought you learned your stuff lol

You mean that its your last post because I am Winning Charlie Sheen style..

Lets see what Wiki has to say..

Oh look on your wiki page you love

"For example, Microsoft's Windows API maintains the programming language definition of WORD as 16 bits, despite the fact that the API may be used on a 32- or 64-bit x86 processor, where the word size would be 32 or 64 bits, respectively. Data structures containing such 32- or 64-bit words are referred to as DWORD and QWORD respectively. A similar phenomenon has developed in Intel's x86 assembly language – because of backward compatibility in the instruction set, some instruction mnemonics carry "d" or "q" identifiers denoting "double-", "quad-" or "double-quad-", which are in terms of the architecture's original 16-bit word size."

Thanks, end of line.

Now see that word Mnemonic... thats the CPU's instruction set... can't change that no matter the OS. Your argument is flawed.

Cheerio

Because the whole world is x86/Windows, right?  When programming for architectures other than x86 and for OS API's other than Windows, Word size can (and does!  Thanks Sparc64!) change dramatically.

But I thought the thread was about Windows, not other Operating Systems.

[Morgora]

@Draconus Kahn

I run the game on Windows 7 64-bit and have not experienced the problems you mentioned. Maybe this thread might help?

http://social.biowar...0/index/6712584