Open PatrickvL opened 7 years ago
Thanks for reporting this - yet another title to test with!
From @UlsterRose on February 5, 2017 20:36
Not sure if this is of much use, but whenever I'm in the car select, I get a perfectly consistent spam of this in the console:
[0x2098] EmuWarn: Trying fixed or recompiled programmable pipeline pixel shader! [0x2098] EmuWarn: We're lying about setting a pixel shader! [0x2098] EmuWarn: Not setting palette [0x2098] EmuWarn: Not setting palette [0x2098] EmuWarn: Not setting palette [0x2098] EmuWarn: Not setting palette [0x2098] EmuWarn: Not setting palette [0x2098] EmuWarn: EmuX86_Write32(0x0000042C, 0x00000001) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000430, 0x00000000) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000434, 0x001A6848) [Unknown address] [0x2098] EmuWarn: Trying fixed or recompiled programmable pipeline pixel shader! [0x2098] EmuWarn: We're lying about setting a pixel shader! [0x2098] EmuWarn: EmuX86_Write32(0x0000042C, 0x00000001) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000430, 0x00000000) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000434, 0x001A6848) [Unknown address] [0x2098] EmuWarn: Trying fixed or recompiled programmable pipeline pixel shader! [0x2098] EmuWarn: We're lying about setting a pixel shader! [0x2098] EmuWarn: EmuX86_Write32(0x0000042C, 0x00000001) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000430, 0x00000000) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000434, 0x001A6938) [Unknown address] [0x2098] EmuWarn: Trying fixed or recompiled programmable pipeline pixel shader! [0x2098] EmuWarn: We're lying about setting a pixel shader! [0x2098] EmuWarn: EmuX86_Write32(0x0000042C, 0x00000001) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000430, 0x00000000) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000434, 0x001A6848) [Unknown address] [0x2098] EmuWarn: Trying fixed or recompiled programmable pipeline pixel shader! [0x2098] EmuWarn: We're lying about setting a pixel shader! [0x2098] EmuWarn: EmuX86_Write32(0x0000042C, 0x00000001) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000430, 0x00000000) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000434, 0x001A6848) [Unknown address] [0x2098] EmuWarn: Trying fixed or recompiled programmable pipeline pixel shader! [0x2098] EmuWarn: We're lying about setting a pixel shader! [0x2098] EmuWarn: EmuX86_Write32(0x0000042C, 0x00000001) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000430, 0x00000000) [Unknown address] [0x2098] EmuWarn: EmuX86_Write32(0x00000434, 0x001A6938) [Unknown address]
This goes away when I go back to the main menu.
From @LukeUsher on February 5, 2017 21:17
The EmuX86 lines imply we are missing some HLE patches for this XDK, this could possibly 'fix itself' as we improve the HLE Database/function detection
From @jarupxx on February 6, 2017 9:24
I checked xdk 4361 and added a missing symbol. The EmuX 86 line has disappeared, but it crashes as well.
If interested, we can test it here. https://github.com/jarupxx/Cxbx-Reloaded/commits/fnc-3
From @LukeUsher on February 6, 2017 9:52
Is this crash dump (EIP := 0x6CA17EA0, etc) identical to the one documented in this issue, or did the details change after adding the missing symbol?
From @jarupxx on February 6, 2017 23:8
Crash dumps are different from documented. The value seems to change every time it is executed.
[0x24AC] EmuMain: Recieved Exception (Code := 0xC0000005)
EIP := 0x66E47EA0 EFL := 0x00010202
EAX := 0x63311791 EBX := 0x00000000 ECX := 0x66E47E90 EDX := 0x66E21070
ESI := 0x0F0AFACC EDI := 0x0F0AFB74 ESP := 0x0F0AFAB4 EBP := 0x0F0AFAB8
CR2 := 0x00000000
Not sure if this is useful, but before the crash Microsoft Visual C ++ Runtime Library Debug Error! Appears. If I Ignore this error, causes Line: 1175 similar Debug Error!
---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Debug Error!
Program: D:\Git\Cxbx-Reloaded-fnc-3\build\win32\Debug\CxbxKrnl.dll
Module: D:\Git\Cxbx-Reloaded-fnc-3\build\win32\Debug\CxbxKrnl.dll
File: d:\git\cxbx-reloaded-fnc-3\src\cxbxkrnl\emud3d8.cpp
Line: 1163
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
(Press Retry to debug the application)
---------------------------
Abort (A) Retry (R) Ignore (I)
---------------------------
https://github.com/jarupxx/Cxbx-Reloaded/blob/fnc-3/src/CxbxKrnl/EmuD3D8.cpp#L1163
From @UlsterRose on February 26, 2017 19:47
Oddly enough, Burnout 3 crashes on startup with a relatively similar error:
[0x141C] EmuMain: Recieved Exception (Code := 0xC0000005)
EIP := 0x00351A3A EFL := 0x00010286
EAX := 0x80000000 EBX := 0x00080000 ECX := 0x00000000 EDX := 0x00000000
ESI := 0x00000000 EDI := 0x00000000 ESP := 0x0E50FD94 EBP := 0x00080000
CR2 := 0x00000000
From @UlsterRose on March 18, 2017 18:3
The intro logos and title screen now display, which didn't happen before because they didn't display if you didn't have a save. The game used to black screen after the initial load screen if you had a saved game.
But when you press Start on the start screen, you get this message:
Update: I also transferred my Burnout save from my Xbox and used that instead of creating the save in Cxbx, but I still got the same message.
From @UlsterRose on March 24, 2017 17:1
There's been a regression, and now I can't get past the first loading screen.
Can you re-test this with build https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/commit/6e250dc345f0c538238070ebf9b933dba348a114 or later?
From @UlsterRose on March 30, 2017 15:34
@PatrickvL The regression has been fixed.
Cool! Thanks for testing. So now it's back to its initially reported behavior?
From @UlsterRose on March 30, 2017 17:7
@PatrickvL Yep!
From @UlsterRose on April 4, 2017 21:40
I'm not sure when this happened, but the issue where Burnout would fail to load the save game has been fixed. "Load Successful!" now displays before moving onto the main menu.
I suspect this commit fixed that : https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/commit/eec43cf5ac5a59b3bb867df9afdc75351f09e6aa
From @UlsterRose on April 24, 2017 19:26
The game now crashes immediately with this error. I traced this back to 574d1f89cd29a0c5d64701033b8d24ff013504ad.
I hadn't been testing for a while, but I also found out that for a little while before 574d1f89cd29a0c5d64701033b8d24ff013504ad, the game crashed with a 0xC0000005.
From @LukeUsher on April 24, 2017 19:29
This has been fixed in the latest versions, it was only broken by that single commit. You can try cleaning the HLE cache manually. Settings -> Cache -> Clear
From @UlsterRose on April 24, 2017 19:53
I'm still getting that error message, though. Clearing HLE cache doesn't work.
From @UlsterRose on May 7, 2017 19:44
I'm still getting the same error on the latest build, but now I get this error after running the game right after clearing HLE cache:
Each time after that, I get the same error as before.
From @UlsterRose on July 31, 2017 10:16
As of now, there is no longer an error message box when attempting to run the game, but the game still gives a black screen. I don't know when the above issue resolved itself though.
From @BenNottelling on July 31, 2017 15:45
@UlsterRose no error but still a black screen? Press f11 to toggle wireframe mode
From @UlsterRose on August 1, 2017 21:10
By black screen I mean Cxbx displays a black screen for about 20 seconds, then goes back to the default state with the Cxbx logo. I should've been clearer about that. F11 doesn't do anything, probably because the game doesn't seem to start now. The copy I'm using works perfectly fine on a real Xbox, so I don't think a bad rip is the problem.
I see there's an xbe-dump-needed label added here. Should I just upload the .xbe of my copy here?
No, don't upload the XBE, just the dump of the XBE info generated from Cxbx will do. :) (Edit -> Dump XBE info to -> File)
Xbe.txt
While this still appears to be modified, I guess it is better than nothing. Please ensure the software you're using to dump your games isn't modifying the xbe and reupload the Xbe.txt (DVD2Xbox is known to do this, try using FTP to get the files directly).
Please make sure that you are dumping the Xbe direct from the DVD, via FTP, and not pre-installed from the hard drive, that way you can pretty much guarantee that it is not being modified.
Edit (02/04/2018): Shows improved 3D visuals of the cars in the vehicle select screen. Well done! But this build used the un-merged extensive DSound WIP. However, the first title/load screen (Before the splash screens) froze the first time so the user rebooted and it proceeded further (With all FPS meters set to 0.00 permanently).
Crashed upon loading gameplay with an external error message:
Exception Code 0xC0000005 @ EIP:= 0x6E78A667
Edit (09/04/2018): Need to bump this thread up. This game now gets comfortably in-game according to two different users' videos! I have been waiting for this moment for like the longest time! Nearly good performance too.
All cars/vehicles are black, there's the darkened shading all along the horizon a bit ahead of the playable car (Bit similar to Mafia's problem?). Curiously, your car turns back to its correct texturing/shading while under a lit tunnel! GUI is good. There are erroneous pictures with low-pixels behind them during your car crashes with an overhead cam view that have some filter diagonally cut off.
Regressed.
KrnlDebug.zip CxbxDebug.txt is empty after the crash. Xbe.zip Burnout-129874fa.zip
Previous behavior: Was playable with major video issues.
Current behavior: Now crashes right when the race starts.
I confirm it works as described above in the PR#1037 build.
Boots only with the "Run Xbox threads on all cores" setting enabled, hangs on loading screen if disabled (same for both the old PR#1037 and the current PR#1311 builds).
PR#1601 fixed push buffer length calculation which seems to fix the regression of burnout. I can now finish a race in burnout. only issue is that the cars are rendered in black under day light.
But you can see that the cars are rendered correctly when you enter a tunnel.
I am suspecting that this might be a environment lighting issue. also in day light scene, the cars at distance are rendered correctly, but turn to black when you approaching them, could be mips map related, too.
275371 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_STENCILZFAIL, D3DSTENCILOP_KEEP) 74060971800
275372 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_CULLMODE, D3DCULL_NONE) 74060973400
275373 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_COLORWRITEENABLE, D3DCOLORWRITEENABLE_RED | D3DCOLORWRITEENABLE_GREEN | D3DCOLORWRITEENABLE_BLUE | D3DCOLORWRITEENABLE_ALPHA) 74060974800
275374 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_ZENABLE, D3DZB_FALSE) 74060977300
275375 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_ZFUNC, D3DCMP_LESSEQUAL) 74060996800
275376 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE) 74060998200
275377 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_SRCBLEND, D3DBLEND_ZERO) 74060999400
275378 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVDESTALPHA) 74061000500
275379 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_STENCILREF, 0x00000001) 74061001700
275380 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_STENCILFUNC, D3DCMP_LESSEQUAL) 74061002900
275381 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_STENCILMASK, 0x0000000f) 74061004100
this is the final stage of shadow volume used by burnout. the
275378 <0x10852268> IDirect3DDevice9::SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVDESTALPHA)
seems to be wrong since from the PIX rendering, the correctly rendered will be covered with black after this rendering. and I googled some shadow volume code examples none of them uses this setting. but it's very difficult to trace to the actual code setup this render state, so I did a trick/hack to force this kind of render state to be set with D3DBLEND_DESTCOLOR instead. hack code as below
case X_D3DRS_DESTBLEND:
if (Value == 0x305)Value = 0x306;//replace xbox D3DBLEND_INVDESTALPHA with D3DBLEND_DESTCOLOR
Value = EmuXB2PC_D3DBLEND(Value);
break;
this code is at Line#6169 of Direct3D9.cpp, function VOID __fastcall XTL::EMUPATCH(D3DDevice_SetRenderState_Simple with this hack, burnout can render the car correctly in the daylight scene
to quickly solve the black car rendering issue, one can patch the default.xbe to use a different DESCBLEND render state setting. find: BF 05 03 00 00 8B D7 B9 48 03 04 00 change the 2nd byte 05 to 06 or 07, and save the xbe. then you can get a correct rendering.
Wikipedia
From @UlsterRose on December 26, 2016 20:5
This is with Cxbx-Reloaded ea95cfc (25 Dec 2016.) I'm able to go through all the menus and even choose a car and track before the crash, although there are quite a lot of graphical issues, and there's no sound.
Here's the last bit of the log when it crashes:
EmuMain (0x1B98): Recieved Exception (Code := 0xC0000005)
EIP := 0x6CA17EA0 EFL := 0x00010282 EAX := 0x83BDFD6D EBX := 0x0AD421FC ECX := 0x6C9F1070 EDX := 0x7FFFFFFF ESI := 0x00000000 EDI := 0x00000004 ESP := 0x0E45FB34 EBP := 0x0E45FB38 CR2 := 0x00000000
The reason I'm reporting this is because of how similar it is to #63 (at least to a black-box tester of Cxbx like me.)
Copied from original issue: Cxbx-Reloaded/Cxbx-Reloaded#69