PS2 [OPL THEME] inceBtion 1.5

[Ripto]

You can find a zipped version of my hdd0:/+OPL here:

https://we.tl/t-4U5pNhvM5w

Turn off Auto Refresh in OPL Settings, this is likely an issue I would think.

I personally store my theme on my memory card, so I am not familiar with @gamerman 5000 's findings - but to combat this, I would just stick the theme on every device I'm using if relevant. or run theme from mc?:/OPL/thm_name/files
But I've never had an issue with HDD loading this theme, USB was the only time it'd sorta hang on occasion but pull through.

Maybe swap the smb cache to 8 and the hdd cache to 16.

 

[FZG]

Unfortunately no change. Guess I´ll stick to 720p which seems stable for me. I can barely tell the difference, anyway.

 

[Ripto]

I am deeply troubled by your issue.
Not only can I not replicate it, but no one else has reported it.
I'm stumped.
I'll see if I can re-arrange the script for optimized loading but I think its already pretty much optimized.

 

[FZG]

Sorry, didn´t mean to cause you a headache. The fact that no one else reported a similar issue makes me think it might be something super-specific to my setup (console / hdd adapter / hdd). As mentioned before, I am absolutely fine with the workaround I figured out.

 

[Ripto]

Sorry, didn´t mean to cause you a headache. The fact that no one else reported a similar issue makes me think it might be something super-specific to my setup (console / hdd adapter / hdd). As mentioned before, I am absolutely fine with the workaround I figured out.

No no, I'm glad you brought it to my attention.
But this means there may be others who have *not* reported it lol
I'm going to see what can be done in terms of loading order.

 

[FZG]

I think I resolved my issue by resizing the disc box artwork files. Some of them (from the "Krah_Berion8Bit_PNGStarter" pack) were 512x725 pixels. I converted them to 512x512 pixels and now the experience is 99% fine in 1080i video mode. There is still the occasional glitch but it is considerably more stable now. I also tried going even lower in image resolution (256x256 for box art and 128x128 for disc art). This was even more stabe (no glitches at all) but the loss in image quality was quite noticeable, so I setlled for 512x512 box and 256x256 disc size.

 

[TnA]

Seems I/we gotta do that "little" update we talked about! @Ripto

 

[Berion]

I like how this theme visualizes devices but I would also love a clean version (without the yellow light indicator etc.)

 

[Ripto]

Seems I/we gotta do that "little" update we talked about! @Ripto

Won't this increase vram usage rather than lessen it though?
I'm looking forward to seeing your work - I think its going to help me wrap my head around a lot seeing it implemented on this.

 

[Ripto]

Another solution, if they want to remove *all* device indicators, is updating this section of the conf_theme.cfg

main3:
    width=0
    height=0

 

[gamerman 5000]

I think I resolved my issue by resizing the disc box artwork files. Some of them (from the "Krah_Berion8Bit_PNGStarter" pack) were 512x725 pixels. I converted them to 512x512 pixels and now the experience is 99% fine in 1080i video mode. There is still the occasional glitch but it is considerably more stable now. I also tried going even lower in image resolution (256x256 for box art and 128x128 for disc art). This was even more stabe (no glitches at all) but the loss in image quality was quite noticeable, so I setlled for 512x512 box and 256x256 disc size.

It seems that making the theme with large-scale art support produces errors than with conventional resolutions.

 

[Ripto]

It seems that making the theme with large-scale art support produces errors than with conventional resolutions.

Probably best to not exceed 128x128 ICO (disc) and 512x512 COV (cover) based on these reports.
What is interesting, is I myself have not encountered the issue.
720p seems to fix everything for users reporting problems - but it hasn't been consistent enough to replicate on my hardware to try and resolve.

 

[gamerman 5000]

Probably best to not exceed 128x128 ICO (disc) and 512x512 COV (cover) based on these reports.
What is interesting, is I myself have not encountered the issue.
720p seems to fix everything for users reporting problems - but it hasn't been consistent enough to replicate on my hardware to try and resolve.

Not all media have the same transfer rate.
It can be left as is but only for (HDD and SMB).
For USB, the theme would have to be redesigned to support standard resolutions (at least I would do it), thus eliminating any risk of failure.

 

[TnA]

It has nothing to do with bandwidth of the storage device, but space occupation in VRAM!

 

[gamerman 5000]

It has nothing to do with bandwidth of the storage device, but space occupation in VRAM!

Imagine that you carry a can with a kilo of flour from one shore to the other.
The speed at which you move is fast because a kilo does not weigh much.
Now imagine that they exchange the can for a 30 kilo bag, the speed at which you move will be slower.
The transfer rate is an important factor for good performance in data transfer.
The more bps, kbps, mbps, gbps the file to be transferred contains, the more work it will cost to transfer it.
Now, the greater the number of pixels, the larger the image size you will have and therefore the greater the amount of information in bytes you will have to transfer.

https://perio.unlp.edu.ar/catedras/...5/2022/04/Las-imagenes.-Pixeles-y-tamanos.pdf

Logically, the speed of the PS2 port is so "poor" to transfer a "greater amount" of information, hence the nickname "heavy subject" that even the loading times make a notable difference compared to SMB media for example in where you can check how quickly these are displayed on the screen.

Finally, a "bottleneck" can cause the information to be processed to get stuck just like the traffic on the roads at "lunch" time generated by the data transfer rate.

https://bitacora.ingenet.com.mx/201...-importa-en-dispositivos-de-memoria-portatil/

 

[TnA]

The bottleneck is the amount of VRAM...

 

[gamerman 5000]

The bottleneck is the amount of VRAM...

Of course it's also involved, which is why @FZG's "experiments" optimized the time images are displayed on the screen by changing the resolution of the art.

 

[TnA]

No... It is THE cause...

If you go over the amount of VRAM, the PS2 has to continually send the cached texture (already free from any storage-device bottleneck) from EE-RAM to VRAM and it would need to do that:

• 180 times (3-pass VMode at 60Hz) at 1920x1080 at/times x-Bitdepth (11390,625MBit/s = 11,124GBit/s) + RAW texture sizes 180x/s vs.
• 180 times at 1280x720 at/times x-Bitdepth (5062,5MBit/s = 4,95GBit/s) + RAW texture sizes 180x/s

...within one second, which the bus from EE-RAM to VRAM can not handle fast enough (at least not via gskit and the current implementation of rendering)!

We already know that and have proven it in 2018 and some of the tests are even on video on my channel AFAIR.

What you claim is simply wrong and we KNOW what the cause is. But I digress... You will endlessly argue it, regardless how many people will tell you that.


tl;dr The BUS between the EE-RAM and the GS is the "bottleneck", NOT the bandwidth of the "storage-device" of the ART!
...and it is "triggered" by too much VRAM usage (which actually works to a certain degree, i.e. like 30% more than we actually have, before glitching).

 

[gamerman 5000]

No... It is THE cause...

If you go over the amount of VRAM, the PS2 has to continually send the cached texture (already free from any storage-device bottleneck) from EE-RAM to VRAM and it would need to do that:

• 180 times (3-pass VMode at 60Hz) at 1920x1080 at/times x-Bitdepth (11390,625MBit/s = 11,124GBit/s) + RAW texture sizes 180x/s vs.
• 180 times at 1280x720 at/times x-Bitdepth (5062,5MBit/s = 4,95GBit/s) + RAW texture sizes 180x/s

...within one second, which the bus from EE-RAM to VRAM can not handle fast enough (at least not via gskit and the current implementation of rendering)!

We already know that and have proven it in 2018 and some of the tests are even on video on my channel AFAIR.

What you claim is simply wrong and we KNOW what the cause is. But I digress... You will endlessly argue it, regardless how many people will tell you that.


tl;dr The BUS between the EE-RAM and the GS is the "bottleneck", NOT the bandwidth of the "storage-device" of the ART!
...and it is "triggered" by too much VRAM usage (which actually works to a certain degree, i.e. like 30% more than we actually have, before glitching).

Once again you have bad reading comprehension boy.
I am not stating that it is the cause, I am saying what could be one of the possible causes that is why I wrote and I quote "thus eliminating any risk of failure." and I also quote "Of course it's involved too" referring to the VRAM but it seems like you skipped that part.
which leads you to commit the scarecrow fallacy, you distort my arguments by passing them off as an affirmation to the solution when what I am giving is one more factor that could be involved, not an assertion that this has to be, capisci?
A bottleneck can occur both in the transfer from a port and in the VRAM, that is a statement that I make but not precisely saying that it is the case here, capisci?
If I were to rule out any alternative as you do, the "logical" thing is that a theme has subfolders with their corresponding images and I would conclude that "it has nothing to do with the fact that an image belonging to a subfolder is outside of it)(@Ripto tastes like what I mean)" but surprisingly it turns out that if you don't place them at the root as well, they simply aren't displayed.
and the themes "purple grape, green grape, heavenly glamour, retro luminous, gothic fantasy for official OPL" would never have existed, much less a theme manual.
Once again I am offering information about a factor that could be involved, whether you consider it or not, that is your business. Are you following me?

 

[TnA]

Yet again you argue with unscientific behavior like "boy", "capisci", etc. and make up claims that you can not substantiate and are false (especially those about me, as well as the topic at hand).
Like I wrote (and you have proven)... You will endlessly argue and resort to nonsense tactics to discredit someone who simply tells you the facts.

Are you capable to stay to the facts?


Since your assumed cause is false to begin with, your "workarounds" are no guarantee to work either.

The tests the guy did are ALL related to lower bandwidth needed on EE-RAM to VRAM transfers and he has just provided more evidence for what we know since 2018.

The ART is NOT "transfered from a port to VRAM" either, but "transfered from a port to EE-RAM, CACHED THERE, transfered to VRAM 180 times per second on a 60Hz 3-pass rendering High resolution mode".