Clannad JPN -ULJM05338+ULJM05339

[sum2012]

Attached

OK, it would be helpful to have a log at DEBUG level when the performance is low. I do not need the DEBUG level from the beginning, only enable it when reaching the low performance screens and just keep it for 2 or 3 seconds.
I just need to see how one screen is being rendered in detail.

Thank you!

[gid15]

Attached

OK, it would be helpful to have a log at DEBUG level when the performance is low. I do not need the DEBUG level from the beginning, only enable it when reaching the low performance screens and just keep it for 2 or 3 seconds.
I just need to see how one screen is being rendered in detail.

Thank you!

Hmmm, it didn't capture any screen frame. Lets try it in a different way: press "Pause" when a slow performance screen is reached, select the menu "Debug / Tools / Debugger" and then under the "Misc" tab, press "Capture next frame". Then Press "Run" to restart the emulation. It will just run for one display frame but now, the log file should have captured the information I need. Images will also be created under the "tmp" directory, but I do not need them, just the log file.

Thank you!

[sum2012]

Attached.
The misc button is hard to find.

Attached

OK, it would be helpful to have a log at DEBUG level when the performance is low. I do not need the DEBUG level from the beginning, only enable it when reaching the low performance screens and just keep it for 2 or 3 seconds.
I just need to see how one screen is being rendered in detail.

Thank you!

Hmmm, it didn't capture any screen frame. Lets try it in a different way: press "Pause" when a slow performance screen is reached, select the menu "Debug / Tools / Debugger" and then under the "Misc" tab, press "Capture next frame". Then Press "Run" to restart the emulation. It will just run for one display frame but now, the log file should have captured the information I need. Images will also be created under the "tmp" directory, but I do not need them, just the log file.

Thank you!

[gid15]

OK, the application is using large textures in RAM (not VRAM), but those textures are 8BIT or 4BIT indexed. I will test this situation, but they probably should be excluded from the change in 8afa36f as their size in RAM is not so large than in 8888 format.

Code:

21:11:10 DEBUG       ge - GUI - tflush 0x097F2280, buffer_width=480 (512,512)
21:11:10 DEBUG       ge - GUI - tflush texture_storage=0x5(PSM_8BIT_INDEXED), tex_clut_mode=0x3, tex_clut_addr=0x097F1E00, texture_swizzle=true
21:11:10 DEBUG       ge - GUI -   sprite (0,0)-(480,272) at (0,0,0)-(480,272,0)
...
21:11:10 DEBUG       ge - GUI - tflush 0x096244C0, buffer_width=480 (512,128)
21:11:10 DEBUG       ge - GUI - tflush texture_storage=0x5(PSM_8BIT_INDEXED), tex_clut_mode=0x3, tex_clut_addr=0x09624040, texture_swizzle=true
21:11:10 DEBUG       ge - GUI -   sprite (3,0)-(4,80) at (0,199,0)-(480,279,0)
...
21:11:10 DEBUG       ge - GUI - tflush 0x088D6810, buffer_width=512 (512,512)
21:11:10 DEBUG       ge - GUI - tflush texture_storage=0x4(PSM_4BIT_INDEXED), tex_clut_mode=0x2, tex_clut_addr=0x0885DC10, texture_swizzle=false
21:11:10 DEBUG       ge - GUI -   sprite (0,0)-(512,512) at (16,207,0)-(528,719,0)
...
21:11:10 DEBUG       ge - GUI - tflush 0x095B5C40, buffer_width=128 (128,16)
21:11:10 DEBUG       ge - GUI - tflush texture_storage=0x5(PSM_8BIT_INDEXED), tex_clut_mode=0x3, tex_clut_addr=0x095B57C0, texture_swizzle=true
21:11:10 DEBUG       ge - GUI -   sprite (16,0)-(32,16) at (460,253,0)-(476,269,0)

[gid15]

OK, the application is using large textures in RAM (not VRAM), but those textures are 8BIT or 4BIT indexed. I will test this situation, but they probably should be excluded from the change in 8afa36f as their size in RAM is not so large than in 8888 format.

The indexed and compressed textures are now excluded from the timing settings in e24da20.
I guess this will return the performance for this application to what it was before 8afa36f.

[sum2012]

e24da20 version
The performance restore.

Remain case 3 in
https://www.emunewz.net/forum/showthread...#pid364849

[sum2012]

For the "Aborting current list processing due to too many errors"

Last good 82dad98
First bad 1f7ff95
It mean https://github.com/jpcsp/jpcsp/commit/1f...c0edf12d91
have problem

[gid15]

Could you please try to generate a log file reproducing the issue, at INFO level but with the following lines added to LogSettings.xml:

Code:

<logger name='hle.sceGe_user'> <level value='debug' /> </logger>
<logger name='hle.sceUtility'> <level value='debug' /> </logger>
<logger name='hle.sceDisplay'> <level value='debug' /> </logger>

[gid15]

Could you please try to generate a log file reproducing the issue, at INFO level but with the following lines added to LogSettings.xml:

Code:

<logger name='hle.sceGe_user'> <level value='debug' /> </logger>
<logger name='hle.sceUtility'> <level value='debug' /> </logger>
<logger name='hle.sceDisplay'> <level value='debug' /> </logger>

Were you able to generate a log with those settings?

[sum2012]

Sorry for late reply
The game 100% no problem with these setting.

Could you please try to generate a log file reproducing the issue, at INFO level but with the following lines added to LogSettings.xml:

Code:

<logger name='hle.sceGe_user'> <level value='debug' /> </logger>
<logger name='hle.sceUtility'> <level value='debug' /> </logger>
<logger name='hle.sceDisplay'> <level value='debug' /> </logger>

Were you able to generate a log with those settings?