Harukanaru Toki no Naka de - Hachiyoushou - ULJM06252

[nash67]

Harukanaru Toki no Naka de - Hachiyoushou - ULJM06252
using r 3054
comes up with one screen then after that nothing but a black screen
here is a compiler log

[sum2012]

It is mpeg probrem, I checked before

[gid15]

Several games seem to share the same video play functions. They all have the same thread names

Code:

ScePsmfPlayerOpenControlThread
ScePsmfPlayerAbortThread
ScePsmfPlayerMCThread
ScePsmfPlayerDecodeThread
ScePsmfPlayerReadThread

and these names also appear in the PSP official libpsmfplayer.prx library. Probably these games are statically linked with the libpsmfplayer and all have the same issue. I'm more investigating in this direction...

[sum2012]

I do not see libpsmfplayer.prx in isoindex.txt
only can see psmf.prx

Several games seem to share the same video play functions. They all have the same thread names

Code:

ScePsmfPlayerOpenControlThread
ScePsmfPlayerAbortThread
ScePsmfPlayerMCThread
ScePsmfPlayerDecodeThread
ScePsmfPlayerReadThread

and these names also appear in the PSP official libpsmfplayer.prx library. Probably these games are statically linked with the libpsmfplayer and all have the same issue. I'm more investigating in this direction...

[Hykem]

Actually these threads exist due to psmf.prx and not libpsmfplayer.prx (even though they're still used this way). This was how developers used to playback media with the limited capabilities of psmf.prx.
Based on the logs, each thread has a specific set of functions:

Code:

ScePsmfPlayerOpenControlThread (sets up scePsmf structure, controls psmf handling and registers MPEG stream):
- scePsmfQueryStreamOffset
- scePsmfQueryStreamSize
- scePsmfVerifyPsmf
- scePsmfSetPsmf
- scePsmfGetPresentationStartTime
- scePsmfGetPresentationEndTime
- scePsmfGetNumberOfSpecificStreams
- scePsmfSpecifyStreamWithStreamTypeNumber
- scePsmfSpecifyStreamWithStreamType
- scePsmfGetCurrentStreamType
- scePsmfCheckEPmap
- sceMpegRegistStream

ScePsmfPlayerReadThread (prepares sceMpeg to handle the data sent from scePsmf):
- sceMpegFlushAllStream
- sceMpegRingbufferAvailableSize
- sceMpegRingbufferPut
- sceKernelDcacheWritebackRange
- sceKernelDcacheInvalidateRange
- sceDmacMemcpy

ScePsmfPlayerDecodeThread (decodes and plays the psmf, but using sceMpeg):
- sceMpegRingbufferAvailableSize
- sceMpegChangeGetAuMode
- sceMpegAvcDecodeFlush
- sceMpegInitAu
- sceMpegGetAtracAu
- sceMpegAtracDecode
- sceMpegGetPcmAu
- sceMpegGetAvcAu
- sceMpegAvcDecodeYCbCr

ScePsmfPlayerAbortThread (returns an error code if something goes wrong).

ScePsmfPlayerMCThread (checks some values, probably controls the start and stop of all the other threads by tracking the decoding status).

[gid15]

Several games seem to share the same video play functions. They all have the same thread names

Code:

ScePsmfPlayerOpenControlThread
ScePsmfPlayerAbortThread
ScePsmfPlayerMCThread
ScePsmfPlayerDecodeThread
ScePsmfPlayerReadThread

and these names also appear in the PSP official libpsmfplayer.prx library. Probably these games are statically linked with the libpsmfplayer and all have the same issue. I'm more investigating in this direction...

Could someone try this game on a real PSP using JpcspTrace with the following JpcspTrace.config file:

Code:

sceMpegCreate 0xD8C5F121 7
sceMpegGetAvcAu 0xFE246728 4
sceMpegGetAtracAu 0xE1CE83A7 4
sceMpegAvcDecodeYCbCr 0xF0EB1125 4
sceMpegAvcCsc 0x31BD0272 5
sceMpegRingbufferPut 0xB240A59E 3
sceMpegRingbufferAvailableSize 0xB5F6DC87 1

Post the generated log.txt (from your PSP)

[nash67]

using r 3070
here is the JpcspTrace log with the added lines

[nash67]

using r 3342
still no change
here is a compiler log and Jpcsp trace logs

[gid15]

There has been several improvements in scePsmf and sceMpeg during the last months. A retest would be appreciated

[sum2012]

r3560 make java crash (I think in sceAtrac3plus) without error message.
r3553 last version don't have sound\crash problem