Game Crashes In Two Ways

[Wolfie]

If the new client doesn't use DX10 or 11, then the same problem will be there. DX9 is old, busted, and largely unusable for modern programming and gaming.

Last I heard, Yoshi hired some people versed in Windows development though.

[TheRac25]

If the new client doesn't use DX10 or 11, then the same problem will be there. DX9 is old, busted, and largely unusable for modern programming and gaming.

Last I heard, Yoshi hired some people versed in Windows development though.

it has nothing to do with the dx version, its lazy developers (or cheap skate corporations, yeah thats you SE) that dont make a new dx object when it gets lost

[JohnSeret]

it has nothing to do with the dx version, its lazy developers (or cheap skate corporations, yeah thats you SE) that dont make a new dx object when it gets lost

so two statements both look like they know what they are talking about.
what is the truth do we have to googlebingyahooxxxit?

[Fear]

so two statements both look like they know what they are talking about.
what is the truth do we have to googlebingyahooxxxit?

DX9 is perfectly capable of supporting ALT + TAB on games, its just a shitty engine FF14 currently runs on, with FFXIV 2.0 the Game will still be DirectX 9 (but it WILL support ALT + TAB) but Yoshi has already said that once 2.0 is released they'll be working on a DX11 version.

[Wolfie]

it has nothing to do with the dx version, its lazy developers (or cheap skate corporations, yeah thats you SE) that dont make a new dx object when it gets lost

Straight from Microsoft:

By design, the full set of scenarios that can cause a device to become lost is not specified. Some typical examples include loss of focus, such as when the user presses ALT+TAB or when a system dialog is initialized. Devices can also be lost due to a power management event, or when another application assumes full-screen operation. In addition, any failure from IDirect3DDevice9::Reset puts the device into a lost state.

All methods that derive from IUnknown are guaranteed to work after a device is lost. After device loss, each function generally has the following three options:

• Fail with D3DERR_DEVICELOST - This means that the application needs to recognize that the device was lost, so that the application identifies that something isn't happening as expected.
• Silently fail, returning S_OK or any other return codes - If a function silently fails, the application generally can't distinguish between the result of "success" and a "silent failure."
• The function returns a return code.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

[Firon]

Straight from Microsoft:

By design, the full set of scenarios that can cause a device to become lost is not specified. Some typical examples include loss of focus, such as when the user presses ALT+TAB or when a system dialog is initialized. Devices can also be lost due to a power management event, or when another application assumes full-screen operation. In addition, any failure from IDirect3DDevice9::Reset puts the device into a lost state.

All methods that derive from IUnknown are guaranteed to work after a device is lost. After device loss, each function generally has the following three options:

• Fail with D3DERR_DEVICELOST - This means that the application needs to recognize that the device was lost, so that the application identifies that something isn't happening as expected.
• Silently fail, returning S_OK or any other return codes - If a function silently fails, the application generally can't distinguish between the result of "success" and a "silent failure."
• The function returns a return code.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

dude you could alt+tab on games when dx9 was the best version...