PS2 [Open PS2 Loader] Game Bug Reports

[Zarper]

Unless it is possible for the game to try to upload before reading is completed, but I think it should have been easier to glitch than this and would have affected faster devices instead of... slightly slow ones.

Well, fast devices are still affected, just a bit different.
You still get the glitch, just not as often, and it tends to go away after the next battle. However, that doesn't mean it's any less wrong, just affected differently.

USB/low transfer seem to be the only way to really fix it... yet at least.

 

[Grahf]

It was a patch for this game, meant for just a test.

We still don't know what's actually causing it, though, so maybe it's just better to limit the speed until we do? I think it's both safer and easier. IMO, it's just a matter of timing. The game was designed with the data flow of a mechanical CDVD in mind, so HDD and SMB deliver the data too fast.

 

[Peppe90]

We still don't know what's actually causing it, though, so maybe it's just better to limit the speed until we do? I think it's both safer and easier. IMO, it's just a matter of timing. The game was designed with the data flow of a mechanical CDVD in mind, so HDD and SMB deliver the data too fast.

You mean to use MODE 7 for this??

I think it would be a good temporary solution.
Sure there must be something related to the timing the game expect, about the way it is optimized for CD reading.
I wonder why certain games have this kind of particular request.

i.e. Crash Bandicoot the wrath of cortex, was the slowest CD player (it takes +50 seconds to load a level from the original CD!). Btw this game doesn't suffer at all from speed improvements (it takes about 15 secs from USB, 7 secs from SMB and 3 secs from iHDD).

 

[Grahf]

You mean to use MODE 7 for this??

No, some kind of blacklisting, which would cause OPL to pick 900 kB/s in Mode 1 for this game.

 

[Krah]

I personally fail to see how that is more preferable to a patch for the specific game based on the game id... That way the user doesn't need to do anything but boot the game.
Has anyone tested sp193s test build?

 

[Grahf]

I personally fail to see how that is more preferable to a patch for the specific game based on the game id... That way the user doesn't need to do anything but boot the game.

What if the game freezes at some point due to such a drastic change? This is a very long JRPG. Who's going to test it here in full? Limiting speed is less invasive.

 

[TnA]

Why is it forced to synchronicity in the first place, when it uses a LIFO/Buffer/Queue?

Maybe 'Mode 1' needs some additional code to include the times of the lasern 'jumping' to another position, or that is what 'Mode 7' could be used for... How further the laser would move in reality, so longer the driver delays the reads or so...

I agree to what @Krah said as well... There is no sense in binding the 'blacklisting' of games to a Mode, when the same can be applied to a Per-game-patch...

...and I am not sure if this was a change to the cdvd-emu-driver, or a per-game-patch... A per-game-patch certainly would not affect any other game!
If it is a change to the cdvd-emu-driver, it is worth to be checked on other games as well! If it decreases compatibility with other games, there might be another solution for the game... If it increases general compatibility, this could be merged as well...

 

[Zarper]

What if the game freezes at some point due to such a drastic change? This is a very long JRPG. Who's going to test it here in full? Limiting speed is less invasive.

There is a v3.0 of the English translation coming up. If a fix is found before that, there is a potential for a few testers going through the entire game.

 

[Grahf]

There is a v3.0 of the English translation coming up. If a fix is found before that, there is a potential for a few testers going through the entire game.

I would test it throughly myself, but I don't want to actually play something I don't own and this game is absurdly expensive nowadays. I don't think I'd pay that much even if I had the cash, actually.

 

[El_Patas]

@sp193, i tested the game Shadow Man: 2econd Coming (SLES-50446) and the
patch not works.

First the game needs Mode 1 for pass the freeze in the loading screen, but
in the game all the textures are still missing.

Tested with r1258 in the internal HDD.

Testing it with the build having the speed variation of 1500 or 1200kbs plus
the Mode 1 itself activated, then also pass the freeze and the textures are fine.

Best regards.

 

[Grahf]

@sp193, i tested the game Shadow Man: 2econd Coming (SLES-50446) and the
patch not works.

First the game needs Mode 1 for pass the freeze in the loading screen, but
in the game all the textures are still missing.

Tested with r1258 in the internal HDD.

Testing it with the build having the speed variation of 1500 or 1200kbs plus
the Mode 1 itself activated, then also pass the freeze and the textures are fine.

Best regards.

Ouch. I knew this wouldn't be so easy because one of the PCSX2 devs couldn't debug it in the end...

BTW, some textures will still glitch with 1500 kB/s, but everything is fine with 1200 kB/s on HDD and 850 kB/s via SMB.

 

[Peppe90]

Someone have the USA version of Shadow Man: 2econd Coming??

 

[Tupakaveli]

Someone have the USA version of Shadow Man: 2econd Coming??

I'm pretty sure I do. I'll test it when I get home.

 

[El_Patas]

I tested the NTSC-U (SLUS-20413) version of the game Shadow Man: Second Coming,
and the textures are working fine, (played only the first moment of the game),
tested with r1261.

Then seems that he patch is not working for the PAL version, at least for the (SLES-50446),
i don't have the PAL German version (SLES-50608).

Best regards.

 

[Peppe90]

I'm pretty sure I do. I'll test it when I get home.

I tested the NTSC-U (SLUS-20413) version of the game Shadow Man: Second Coming,
Best regards.

Please, can you two check the MD5 of the game??

 

[Grahf]

g the speed variation of 1500 or 1200kbs

I tested the NTSC-U (SLUS-20413) version of the game Shadow Man: Second Coming,
and the textures are working fine, (played only the first moment of the game),
tested with r1261.

Then seems that he patch is not working for the PAL version, at least for the (SLES-50446),
i don't have the PAL German version (SLES-50608).

Best regards.

Let the game's demonstrations run in full. There are at least 3 different ones and they are quite long, but let all of them run to make sure all textures load without glitches.

 

[El_Patas]

Please, can you two check the MD5 of the game??

The MD5 for the bin file of the NTSC-U version is b1f3a583d2e4afaf6cad325f16000ba0

I noticed now that the NTSC-U version do not needs the Mode 1.
I need check the PAL versions with the latest commit.

Let the game's demonstrations run in full. There are at least 3 different ones and they are quite long, but let all of them run to make sure all textures load without glitches.

Tomorrow with more time i'll check it with the latest commit.

Best regards.

 

[El_Patas]

I tested the game Shadow Man: 2econd Coming with all this versions:

(SLUS-20413)
(SLES-50446)
(SLES-50608)

All worked fine, they don't need any Mode, textures are working.
I saw the full game demonstration and i don't noticed any missing texture.

But i don't saw that there are 3 different demos, at least with the NTSC-U
version which is the one i used for check the demo, iI've seen the same
demo twice.

Tested with r1266 in the internal HDD.

Best regards.

 

[sp193]

Ouch. I knew this wouldn't be so easy because one of the PCSX2 devs couldn't debug it in the end...

The patch works. I just forgot to add the other 2 games to the list of IOP-side patches.

BTW, some textures will still glitch with 1500 kB/s, but everything is fine with 1200 kB/s on HDD and 850 kB/s via SMB.

This was observed because Accurate Reads doesn't change the rate of data transfers from the device. It'll read at whatever speeds the device will natively work at, but it'll delay the completion status of reading until at least the specified amount of time has elasped.

This characteristic matters for this game, as we need the IOP to win the race against the device, unless we patch SOUNDREL.IRX to correct the buffer overflow. It allocates 0x8000 bytes of space, but sometimes it'll read 17 sectors (0x8800 bytes).
Since Accurate Reads breaks up transfers into 8-sector groups, reading at "850KB/s" means that it'll read 8 sectors, before reading the remaining 9 sectors. If it was quick, then it'll wait until approximately 15ms (e.g. 8 * 2KB / 850KB/s * 1000 = 18.8ms, and so on) has elasped.

 

[Krah]

we need the IOP to win the race against the device, unless we patch SOUNDREL.IRX to correct the buffer overflow. It allocates 0x8000 bytes of space, but sometimes it'll read 17 sectors (0x8800 bytes).
Since Accurate Reads breaks up transfers into 8-sector groups, reading at "850KB/s" means that it'll read 8 sectors, before reading the remaining 9 sectors. If it was quick, then it'll wait until approximately 15ms (e.g. 8 * 2KB / 850KB/s * 1000 = 18.8ms, and so on) has elasped.

So how did you remedy this? Did you increase the buffer with the patch to the audio module to allow for the occasional overflow or was it some other method like limiting the transfer to 16 sectors?

I am not at all questioning your work I'm just curious and find it interesting but I don't know a lot about game debugging