Star Wars Obi-Wan [LA-001] [1.01]

jeltaqq commented 6 years ago

Description

Booting, but has crash immediately without displays an error message.

Dumps

Xbe.txt KrnlDebug.txt

Status

Previous behavior:

None reported

Current behavior:

state-booting

Screenshots

intro

Additional Information

Tested with 735a4bcf

frankyfife commented 6 years ago

I would like to add that the start screen can be seen and the menu music can be heard.

Cxbx-Reloaded (Version 16256597 (May 16 2018)

WickedPissah810 commented 6 years ago

I would like to add that Star Wars Obi-Wan does boot the start screen, show the LucasArts title card, and boots to the main game menu. It even plays the necessary sounds. However, no text shows that says "Press Start".

Once you wait a certain amount of time, it takes you to a random level of the game. In this example, I was taken to the initial training level of the game. On the top left, you also see a random silhouette. The game won't take any input, either.

gorillajackson commented 5 years ago

having the same problem could use a solution

aav7fl commented 5 years ago

I exchanged a brief message on Discord around the issue of no-input. Here was their response.

We don’t do per-game work, but if we find out what is wrong with the input system that breaks this game, but doesn’t break other games then we’ll fix it. The input subsystem is sensitive and minor changes can cause major issues: for example, tiny changes to the input system can make JSRF unable to boot at all.

So we have to be extra careful

I haven't been able to dig anything up though around the Xapi because I don't really understand it too well.

If someone else does understand the library well enough to fix it, I'd be happy to contribute a bounty on resolving this the broken input.

aav7fl commented 5 years ago

Progress!

Star Wars - Obi-Wan

(Shaders were disabled in the gameplay above or else the characters would be a flat grey. That's why it's all crazy colored.)

I'm going to copy what I posted in Discord:

I had to step through the disassembled code 50 or so times working backwards with each iteration. It involved a lot of manual bitwise calculations and I had to keep looking online to understand the instruction sets and register behaviors. I also relied pretty heavily on the memory mapping while I was debugging to see what was being changed.

When we assign the capabilities (https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/48ba828c42cbf379f0d6d8464e3499feabc2b45b/src/core/hle/XAPI/Xapi.cpp#L681-L683), we put a bunch of 0xFF bytes at the pCapa address.

It looks like the single byte before the ~22 0xFF bytes in the current pCapa address needs to be 0xFF. At least, according to the disassembled code it runs a bunch of instructions on it ensuring that it's something like that or else it will call one of the many instructions to trigger a close. Currently, that byte (in the Star Wars Obi-Wan game) is 0x0b. I found it to be different in other games.

Here is my code demonstrating this change. But I'm not sure if it will break other controllers because I don't understand the bytes immediately before the pCapa. This also isn't the right place to put it (should probably have a constant somewhere for the address offset if this is the correct thing).

https://github.com/aav7fl/Cxbx-Reloaded/commit/49f91eb7c600df9325a922542b5a12c14855b0fa

This actually makes me wonder, is our offset for the controller capabilities incorrect?

In the screenshot below, I think it would make sense if they were shifted over anywhere from 1-4 bytes. But I also don't understand what those first four bytes are before the capabilities.

debug

because that xor instruction needs the 0b and ff to xor nicely into eac, which then that specific byte (at 0b) gets used in a lot more comparisons later on.

so that 0b in the screenshot before the capabilities needs to be a ff

Later, @RadWolfie posted:

Hmm... I see the problem. The structure isn't aligned properly. https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/0077eb7ab296a1636bac54f32fb44f6d2c35e3ae/src/core/hle/XAPI/Xapi.h#L323-L340 The subtype is 1 byte + reserved is 2 bytes which means 3 bytes are used. The next offset is at 0x3. Which is what you're talking about. So, our structure is currently aligned by 4 bytes.

Which means we're on to something here!

aav7fl commented 5 years ago

Controller fix for this game has been merged into the develop branch in https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/1708. A new build will be available whenever the pipeline finishes running.

mnadareski commented 3 years ago

Using build 8087b15:

Start screen renders correctly with all background video and animations
Intro FMV has no notable issues
In-game, all environmental models appear rendering properly aside from some z-fighting on additional textures. Character models are all brown
Environmental glow is very pronounced. It's been a while since I've played on console, so I don't recall if this is expected
Overall playable. I was able to get to the end of the first level without much issue since enemy weapons render as expected

Notable messages:

[0x1940] INFO : D3D8    Please report that Star Wars Obi-Wan shows the following message:
LOG_TEST_CASE: Existing RenderTarget width/height changed
In ValidateRenderTargetDimensions (D:\a\Cxbx-Reloaded\Cxbx-Reloaded\src\core\hle\D3D8\Direct3D9\Direct3D9.cpp line 4184)
[0x1940] INFO : D3D8    Please report that Star Wars Obi-Wan shows the following message:
LOG_TEST_CASE: CreateHostResource : Depth != 1
In CreateHostResource (D:\a\Cxbx-Reloaded\Cxbx-Reloaded\src\core\hle\D3D8\Direct3D9\Direct3D9.cpp line 5826)
[0x6EB8] INFO : D3D8    Please report that Star Wars Obi-Wan shows the following message:
LOG_TEST_CASE: Existing RenderTarget width/height changed
In ValidateRenderTargetDimensions (D:\a\Cxbx-Reloaded\Cxbx-Reloaded\src\core\hle\D3D8\Direct3D9\Direct3D9.cpp line 4184)

Kernel Debug: KrnlDebug.txt

Cxbx-Reloaded / game-compatibility