Game-compatibility: RalliSport Challenge [MS-015] [1.01]
Information transferred from Cxbx-Reloaded/Cxbx-Reloaded#311
Description
Title goes in-game (if someone could post screenshots to verify it would be appreciated, I just transferred this issue and do not own the game)
Dumps
Status
Previous behavior:
Title crashed after showing the title screen. An error message shown: 0x0000001F is not a supported format!
Current behavior:
Goes in-game
Screenshots
Additional Information
Tested on 6c04ed5c (Mar 28 2017)
See also: #66
CakeLancelot
All 28 comments
Please see Cxbx-Reloaded/Cxbx-Reloaded#311 for any comments I may have not transferred over yet. Thanks.
CakeLancelot
on 8 Sep 2017
I modified the code to use the same handler for lin_A8 with LIN_D16, then it went through for a while eventually crashed without any message. here is the kernel log.
KrnlDebug.txt
jackchentwkh
on 4 Oct 2017
This log shows "Godzilla Save the Earth"?
PatrickvL
on 4 Oct 2017
oops, my bad. I tried Godzilla right after Rallisport without closing CXBX and reopening it again. so the log was over written. I think it's sort of bug since Cxbx didn't change the directory after I select a new xbe from the recent loaded xbe list.
here is the newest log for Rallisport Challenge.
KrnlDebug.txt
jackchentwkh
on 4 Oct 2017
ok, with the december 11th commit, I couldn't help to use my quick code for the linear 8 bit texture handler again to see whether it works or not.
here is my modification: in EmuD3D8.cpp, line#5382, I add the condition for X_Format == X_D3DFMT_LIN_A8 to use the 16bit linear texture handler. the reason why I am doing this is that I found the handler for 32 bit and 16 bit linear texture are identical, so I assume that the 8 bit linear texture should be able to adopt the same code.
else if(X_Format == X_D3DFMT_LIN_R5G6B5 || X_Format == X_D3DFMT_LIN_D16
|| X_Format == X_D3DFMT_LIN_A4R4G4B4 || X_Format == X_D3DFMT_LIN_A1R5G5B5
|| X_Format == X_D3DFMT_LIN_X1R5G5B5 || X_Format == X_D3DFMT_LIN_A8) // add 8bit linear texture support here.
{
// Linear 16 Bit
dwWidth = (pPixelContainer->Size & X_D3DSIZE_WIDTH_MASK) + 1;
dwHeight = ((pPixelContainer->Size & X_D3DSIZE_HEIGHT_MASK) >> X_D3DSIZE_HEIGHT_SHIFT) + 1;
dwPitch = (((pPixelContainer->Size & X_D3DSIZE_PITCH_MASK) >> X_D3DSIZE_PITCH_SHIFT)+1)*64;
}
after this quick code modification, Rallisport could get into menu quickly, fps is good. intro video loops, and the menu is shown. but seems it only renders a triangular area of the screen.
screen shots as below.
so far the controller is not working. The menu item keeps flashing, and there is a short sound repeating in the back ground seems like a controller button is being pressed in a quick manner. I am testing the controller and will update the status later.
KrnlDebug.txt
RalliSport Challenge-2e6f57ff.ini.txt
jackchentwkh
on 14 Dec 2017
From @DarkGabbz (#525):
Description
Game boots and instantly gives error message on the first splash/loading screen.
Cxbx-Reloaded
---------------------------
Received Fatal Message:
*0x0000001F is not a supported format!
---------------------------
OK
---------------------------
Dumps
1.06: Xbe.txt
KrnlDebug.txt
RalliSport Challenge-d78482b9.txt
Status
Previous behavior:
None
Current behavior:
Texture format not supported
Screenshots
Additional Information
ran on build 5ce5da/commit 5ce5da70368d5a3b0129b059a05c43e26fedf078
Voxel9
on 12 Jan 2018
with recent builds, the 0x1F unsupported format error message is no longer shown.
but the game boots to a black without any message, zero FPS.
after a few minuted, the game alerts a error messgae
and the log with the error message is
[0x2898] X86 : Write32 NV2A PFB(0x00000410, 0x00010000) [HandleNV_PFB_WBC]
[0x2898] X86 : Read32 NV2A PFB(0x00000410) = 0x00000000 [HandleNV_PFB_WBC]
[0x????] NV2A: dma_map 2, 0, 0 7ffafff
[0x????] NV2A: DMA pusher: max 0x07FFAFFF, 0x00000000 - 0x03F4F000
[0x????] NV2A: pb JMP 0x07F4F000
[0x????] NV2A: pb reserved cmd 0x07F4F004 - 0x56575797
[0x????] NV2A: DMA pusher done: max 0x07FFAFFF, 0x07F4F004 - 0x03F4F000
[0x????] NV2A: pb error: 4
by passing the error message window, the game went back to black screen with zero FPS again, the log seems to indicate the game is stocked in a DMA loop, unlike the demo version which can show the title screen.
the log file keeps raising up in size, repeating this line
[0x0D74] X86 : Read32 NV2A USER(0x00000044) = 0x07F4F004 [HandleNV_USER_DMA_GET]
I trimmed the repeated parts to reduce the log file size.
KrnlDebug - rallisport.txt
jackchentwkh
on 19 Feb 2018
It gets in game with PR1310, but crashed with PR1377.
Couldn't find a quick way to bisect the troublesome PR because all artifacts on appveyor are over 6 months an no longer available. need further bisecting.
jackchentwkh
on 16 Apr 2019
with recent release build of develop branch, commit 5589, RSC crashed when trying to start a new race.
but if you use a debug build and bypass alert(false) call, it will not crash and you can finish the race.
as for release build, the crash happens at line# 1072 of EmuNV2A_PGRAPH.cpp
the code is
if (method == NV_SET_OBJECT) {
assert(parameter < d->pramin.ramin_size);
uint8_t *obj_ptr = d->pramin.ramin_ptr + parameter;
uint32_t ctx_1 = ldl_le_p((uint32_t*)obj_ptr);
uint32_t ctx_2 = ldl_le_p((uint32_t*)(obj_ptr+4));
//crashed at line above. this is the code introduce crash
//it's a access violation.
//obj_ptr=0x42E18F69
//d_pramin.ramin_ptr=0xfd700000, this value seems to be the same across all crashes instances.
//d_pramin.ramin_size=0x100000
//parameter=0x45718f69, this value may change between each crashes, but they are all similar values.
// either parameter or d_pramin.ramin_ptr was wrong, that's my suspection.
uint32_t ctx_3 = ldl_le_p((uint32_t*)(obj_ptr+8));
uint32_t ctx_4 = ldl_le_p((uint32_t*)(obj_ptr+12));
uint32_t ctx_5 = parameter;
pg->regs[NV_PGRAPH_CTX_CACHE1 + subchannel * 4] = ctx_1;
pg->regs[NV_PGRAPH_CTX_CACHE2 + subchannel * 4] = ctx_2;
pg->regs[NV_PGRAPH_CTX_CACHE3 + subchannel * 4] = ctx_3;
pg->regs[NV_PGRAPH_CTX_CACHE4 + subchannel * 4] = ctx_4;
pg->regs[NV_PGRAPH_CTX_CACHE5 + subchannel * 4] = ctx_5;
}
d_pramin.ramin_ptr=0xfd700000 is correct; parameter should've failed the above assertion assert(parameter聽<聽d->pramin.ramin_size);
PatrickvL
on 24 Apr 2019
In any case, this code is part of the LLE NV2A GPU, most of which shouldn't get hit when HLE GPU is enabled. Perhaps a D3D patch is missing?
PatrickvL
on 24 Apr 2019
but with debug build and bypassing the alert(false) calls, RSC could finish the race without being crashed.
that could eliminate the missing patch possibilities.
on the other hand, LLE isn't enabled during the test, how the heck is this code being executed?
jackchentwkh
on 24 Apr 2019
LLE is always used because it's required for things like D3D bootstrap, without any LLE code, HLE can't even boot.
With the debug build, it probably works due to things like stack guards.
it's possible whatever missing patch causes this situation to happen is corrupting memory, but with a debug build, the stack guards prevent the corruption from harming anything important.
Need to disassemble the game to find out where this call originates from
LukeUsher
on 24 Apr 2019
RSC doesn't crash with PR1310. so I compare the HLE patch for PR1310 build and current build, there are two HLE patches missing:
HLECache: 0x0031c2c0 -> D3DDevice_SetRenderState_YuvEnable
HLECache: 0x001d7fe9 -> QueryPerformanceCounter
these two HLE patches are presented in PR1310 build, but not in current build.
jackchentwkh
on 24 Apr 2019
QueryPerformanceCounter is no longer patched (but should be detected), but D3DDevice_SetRenderState_YuvEnable still is and should be. So the question is, why is D3DDevice_SetRenderState_YuvEnable not detected?
LukeUsher
on 24 Apr 2019
SymbolCache: 0x0031c2c0 -> D3DDevice_SetRenderState_YuvEnable
it's detected by PR1590, the current build, but not patched
jackchentwkh
on 24 Apr 2019
D3DDevice_SetRenderState_YuvEnable patch has been disabled for 7 months now, that's quite a long time.
LukeUsher
on 24 Apr 2019
how could I re-enable the patch? just for a quick test?
jackchentwkh
on 24 Apr 2019
You'd need to copy the code for the patch from an old build of Cxbx-R and add an entry into patches.cpp to enable it
LukeUsher
on 24 Apr 2019
here are some logs from call stacks.
RSC:238880 call 2378A0h
sub_278a0h()
RSC:237e46 call XTL::EMUPatch_D3DDevice_EndPush();
XTL::EMUPatch_D3DDevice_EndPush()
Line#2661 call EmuExecutePushBufferRaw();
EmuExecutePushBufferRaw()
line#547 call pgraph_handle_method();
pgraph_handle_method()
line#1072 crash!!!
seems there are data corrupted in the push buffer which introduced a access violation when processing the push buffer.
using bisection, I found that Initial D3D9 port (#1375) is the actual PR crashes RSC in release build
jackchentwkh
on 27 Apr 2019
Here a link to connect this issue to that merged pull request : https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/1375
Also, the RallySport Challenge regression was already reported back then : https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/1375#issuecomment-411492037 (but no action was taken to resolve this).
Therefore, a new issue to followup on this is created here: https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/issues/1591
PatrickvL
on 27 Apr 2019
@jackchentwkh can you please give us an up-to-date XBE dump or at least tell us the title_id and version number of the game you're testing? There are six known versions of this game and we need to know what version you have
See
LukeUsher
on 27 Apr 2019
the xbe could be altered, it's v1.01 which is not in your list, but cxbx-r doesn't report and error regarding to xbe. here is the dump info.
1.01: RSC Xbe dump.txt
jackchentwkh
on 27 Apr 2019
@jackchentwkh interesting: You have a version of Rallisport Challenge that is not in the Redump database, meaning it could be an undumped/previously unknown revision. If possible, it'd be good to get this dumped to redump standards and reported to them.
LukeUsher
on 27 Apr 2019
@jackchentwkh please also test builds earlier than #1375, but each test with CXBX_USE_D3D9 defined, since the port was kept behind that define until then, so the actual breaking change might've been made even earlier
PatrickvL
on 27 Apr 2019
it most likely a memory corruption. in release builid, the push buffer was corrupted. and in debug build, the crashed code was never reached.
in XbPushBuffer.cpp line#547
CACHE_PUSH(dma_state.subc, dma_state.mthd, word, dma_state.ni);
in release build, when entering a race, it will call pgraph_handle_method(), means dma_state.subc ==0,
but in release build, when entering a race, the pgraph_handle_method() was never called.
jackchentwkh
on 4 May 2019
https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/1601 allows this to go ingame.
CakeLancelot
on 4 May 2019
Working great now. Menus and text look almost perfect. Game running way faster than 60fps. Textures and shadows appear to be working more accurately. Dev build September 20, 2019
lifter911
on 21 Sep 2019
Related issues
equipeXomega117
路
3Comments
Shideravan
路
3Comments
Voxel9
路
3Comments
PatrickvL
路
3Comments
fatjohnny118
路
3Comments
Most helpful comment
ok, with the december 11th commit, I couldn't help to use my quick code for the linear 8 bit texture handler again to see whether it works or not.
here is my modification: in EmuD3D8.cpp, line#5382, I add the condition for X_Format == X_D3DFMT_LIN_A8 to use the 16bit linear texture handler. the reason why I am doing this is that I found the handler for 32 bit and 16 bit linear texture are identical, so I assume that the 8 bit linear texture should be able to adopt the same code.
after this quick code modification, Rallisport could get into menu quickly, fps is good. intro video loops, and the menu is shown. but seems it only renders a triangular area of the screen.
screen shots as below.
so far the controller is not working. The menu item keeps flashing, and there is a short sound repeating in the back ground seems like a controller button is being pressed in a quick manner. I am testing the controller and will update the status later.
KrnlDebug.txt
RalliSport Challenge-2e6f57ff.ini.txt