Game-compatibility: Star Wars Obi-Wan [LA-001] [1.01]

Created on 10 Feb 2018  路  6Comments  路  Source: Cxbx-Reloaded/game-compatibility

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

issue-input region-us-canada state-interactive type-retail xdk-3911 xdk-3925 xdk-3948

Most helpful comment

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.

All 6 comments

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

image

Cxbx-Reloaded (Version 16256597 (May 16 2018)

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".

image

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.

image

having the same problem
could use a solution

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

We don鈥檛 do per-game work, but if we find out what is wrong with the input system that breaks this game, but doesn鈥檛 break other games then we鈥檒l 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.

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!

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Voxel9 picture Voxel9  路  3Comments

kennethedmonds picture kennethedmonds  路  3Comments

ghost picture ghost  路  3Comments

fatjohnny118 picture fatjohnny118  路  3Comments

equipeXomega117 picture equipeXomega117  路  3Comments