LÖVE

T-Bone wrote:4. Try running in Release instead of Debug.

Just looked it up. PDB are files that VS uses to hold debug symbols. These errors are completely harmless. It means that you won't be able to debug any .dll that doesn't have it's respective .pdb file. All that matters is that the .dlls are being loaded.

So the error you are seeing has nothing to do with the output in the console. I think this might be a bug with LoveFTW. Could you post the model of your phone?

Even though it shouldn't matter make sure that you output in release mode like T-Bone mentioned so one more variable is gone.

I~=Spam wrote:So the error you are seeing has nothing to do with the output in the console. I think this might be a bug with LoveFTW. Could you post the model of your phone?

It has to do with the last few lines of the console output:

unek wrote:

Code: Select all

D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]
err: rx::SwapChain11::swapRect(638): Present failed: the D3D11 device was removed: 0x887A0006

slime wrote:It has to do with the last few lines of the console output:

unek wrote:

Code: Select all

D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]
err: rx::SwapChain11::swapRect(638): Present failed: the D3D11 device was removed: 0x887A0006

Ahh I missed that part. Sounds like a bug in LoveFTW to me... But I don't know. Do other games (using DX11 of course) work on your phone? If other games on your phone have this problem too that might show it is the fault of your phone. It could be a DX11 bug but I seriously doubt it.

Is it possible that it is a bug with the opengl to directx layer that LoveFTW uses?

I've tried the LÖVE game code that unek used, and it works fine on my 920, as well as the emulator. My guess of what's happening, based on the error message, is that some ANGLE process takes too long to finish, causing the OS to think ANGLE has gone unresponsive, and kills it. This assumes that unek is using a slower computer, which in Debug mode is running the graphics in the emulator too slowly.

Either that, or something is messed up with the way I packaged LöveFTW in the repo (it's missing something, or contains some file it shouldn't contain). Just to make sure it's not that, try downloading my setup exactly as it is on my computer (note: big download, 650 MB) here: http://1drv.ms/1DptXuB

This latest, Direct3D crash seems related to an ANGLE issue that got posted recently, details of which are at https://github.com/MSOpenTech/angle/issues/37

Perhaps the LoveFTW crash has a similar, or identical, root-cause to this ANGLE issue?

Cheers,
-- David L.

The love GLES code does indeed make use of gl_PointSize (even when GL_POINTS aren't actually used, in which case the GLES implementation is supposed to just ignore it, I believe.)

Interesting port..
What love.system.getOS() will return in this love implementation ?

gomez wrote:Interesting port..
What love.system.getOS() will return in this love implementation ?

It returns "Windows App". It's technically not an OS though, so I might change that later... Maybe "Windows Universal App Platform" would be better?

T-Bone wrote:

gomez wrote:Interesting port..
What love.system.getOS() will return in this love implementation ?

It returns "Windows App". It's technically not an OS though, so I might change that later... Maybe "Windows Universal App Platform" would be better?

That seems like a bit much (in terms of checking if it's that "OS"). Personally, I'd go with WinApp or something small if you're going to check the OS love is running.

T-Bone wrote:

gomez wrote:Interesting port..
What love.system.getOS() will return in this love implementation ?

It returns "Windows App". It's technically not an OS though, so I might change that later... Maybe "Windows Universal App Platform" would be better?

"Windows RT" would be a good candidate