You first need to rule out any error introduced by the xbox port, so you need a diff or you need to manually go through the differences.

I think you should look at how the xbox port is handling a file create on a file that is already open. Shouldn't matter if the file was opened in read or read/write mode.

It's actually a bug in Crystal Caves that it opens the file twice and only closes the second handle. The handle table will (eventually) fill up and cause problems.

ripsaw8080 wrote:

I think you should look at how the xbox port is handling a file create on a file that is already open. Shouldn't matter if the file was opened in read or read/write mode.

It's actually a bug in Crystal Caves that it opens the file twice and only closes the second handle. The handle table will (eventually) fill up and cause problems.

Basically the xbox port is kicking back an error on the second open attempt (I'm running in debug) with a file already open error. I've seen it happen before in other cases where a file handle was not closed after openint.

Yeah I kinda figured it is a little "quirk" of Crystal Caves. I know for sure that on the xbox if a file is already open for read that it will not allow another file handle to be opened for write on it. Not sure about read. Maybe I should force the code to open for read on the second try to see what happens.

But yes in theory the handler table could fill up. 🤣 Luckyily the save slots are limited to 10 and the handler table can handle 256 entries.

I'm thinking of just modifying the code to either close the original handle, if it finds the file was already open (rather than a flush), in the portion of code that checks and forces a buffer flush. The other thing I thought of is possibly having the second file (when a match is found) use the same file handle as the match found.

Both not the ideal solution. Either the handler table is gonna fill up, or maybe a read attempted on an already closed file. I cant think of any reason why a game would open two different file handles on a file.. but we see this happening with Crystal Caves so who knows. I'm just trying to think if there is some other way to handle this little oddity which seems to affect the xbox platform.

I'm thinking of taking this game and setting it up on maybe the PS3 or WII version of dosbox to see if I see the same behavior. I'm kinda curious about it.

maybe it would be *easier* making a patch for the game than patching DOSBox because of this game

That though crossed my mind.. however it does not negate two things...

1) The game works fine on an original PC
2) The game works fine running under dosbox on a windows XP machine.

Thus it is running "incorrectly" in the xbox environment. Even if the game is doing a no no. 😁

That being said.. if it is the only game that does it is essentially much ado about nothing. 🤣

I think the bug in the game exists because it doesn't announce its presence; at least not in a fully compatible environment. It is certainly possible that similar bugs exist in other games for the same reason. However, if resolving the issue is a thorny problem, you might want to wait for additional cases to crop up.

ok I will. The only other oddities that I have seen that could possibly be related is strange behavior with install scripts for several games. However in those cases I found it easier to do the install process on my PC and then copy the files over to the xbox.

I'll just assume that Crystal Caves is just a fringe case and that this is not something normal with dos games. 🤣

But at least I know what behavior to be on the lookout for.