PS2 Open PS2 Loader v1.1.0

[jolek]

WRC: Rally Evolved hanged on the Evolution Studios logo with the HDD blinking every few seconds. So I've fired up MODE1+MODE2 combined and it passed successfully. I've never tested the game further. I wonder if it's hardware or software issue, since in earlier OPL versions I didn't have to turn on compatibility modes.

I don't need any compatibility modes to play WRC: Rally Evolved v2.00 (SCES_532.47) through USB.
Tested with OPL-181019, OPL 1193.
It also works with 1180, without any additional modes:
http://www.psx-place.com/threads/open-ps2-loader-v0-9-3.13415/page-6#post-138578.

I've even tried quick race with success.
Although I've made these tests with "compatible" flash-drive.
I can try to make a test with Intenso, but I don't know when I'll have some spare time for that.
Probably when I'll copy WRC: Rally Evolved v2.00 on USB, the game will be fragmented
and it takes a lot of a time to defragment it, or copy it onto HDD, format, copy onto USB.

EDIT: WRC: Rally Evolved v2.00 also is working with Intenso without any compatibility modes.

One thing I forget to mention is that in first FMV, video & audio will be out of sync after some time.
Tried on SCPH-50004.
I haven't got this problem on SCPH-77004 (I think).
So this issue maybe revealing due the lower speed on PHAT.

@jolek: If you still have problems with USB devices, you can try to play with the test program to see whether the actual problem can be captured.
If there is some procedure that we are lacking in compliance with the USB specification, some adjustments can be made to how we do things in USBHDFSD. However, if it is just due to USBD getting stuck (perhaps due to the hardware getting stuck), then it cannot really be fixed without help from Sony or people who can actually work with USB.

Theoretically I've only problem with Kingson, with Inteso and build from OPL-181019, everything seems to be fine.
Although I'll try to test WRC: Rally Evolved v2.00 as I mentioned before.
Who knows, maybe this game is messing with us.

BTW Is there any new version of this USB test program,
or I needs to run OPL-181019 and use planetty?

 

[sp193]

Theoretically I've only problem with Kingson, with Inteso and build from OPL-181019, everything seems to be fine.

Ah I see. That's great!

BTW Is there any new version of this USB test program,
or I needs to run OPL-181019 and use planetty?

Other than the problem with Set Interface, there were no other changes to USBHDFSD that mattered. The last USB test program is still relevant.
OPL's logging system may not be working, so no debug versions of OPL were uploaded after that first one that did not work.

 

[jolek]

Attempt to load configuration file from the device that it is booted from, before trying all other devices.

Maybe the same loading config option can be added to OPL?
I mean, if I load OPL from HDD, config will be loaded from HDD.

Maybe even the same situation can be done with saving settings?
If OPL has been loaded from HDD then the config\settings will be saved on HDD (not on MC0 as it is now by the default).
Or an option to select where settings can be saved:
http://www.psx-place.com/threads/open-ps2-loader-v0-9-3.13415/page-4#post-126299.

 

[TnA]

I just had 2 idea for small changes.


Idea1:
What do you guys think about the size of the +OPL-Partition being dependent on the size of the HDD?

So essentially it should create a bigger partition for bigger HDDs and not just 'statically' 128MB...

Something along the lines of 128MB per 60GB, or so... For 1TB that would be ~2.1GB. If it is bigger to begin with, we can prevent the need for users to increase their partitions (or make it less likely atleast).

It could even request the user, if he wants another size (and give him/her a recommendation, based on the previously mentioned math).


Idea2:
The ART/Recources could have a 'per-game-recource'-folder, so instead of putting all files for all games into one folder, they should/could be placed in a sub-folder within ART, 'per game'...

So essentially instead of the Art-Folder being flooded with various files, it should have folders with the game-ID and in those, it should collect the various ARTs/RESources!

 

[jolek]

For me 128MB is a good choice (although it is even min partition size that PS2 HDD could have).
Currently I've almost ~200 covers taking ~11MB.
I don't use VMC, but I think ~100 MB for it will be enough for this feature.
Although it's my config, maybe someone else will have other needs?

Maybe this situation will change if I'll have more HD games covers?!

Anyway, user can also extend partition in wLe manually if he needs it as you mention before.

 

[TnA]

Well, maybe it should 'ask' the user when it wants to create the partition, which size it should have!


What about 'idea2'?
I think it would help organize it in a better way!

 

[ShaolinAssassin]

Between the 2 solutions, I think that the ask-which-size-to-use is better - mainly because uLE can not reduce partitions size.

I don't understand the need of the idea 2. I mean, all images are prefixed with the game-ID so it's not a mess IMO... Well, just my optinion.

 

[uyjulian]

Better idea: reduce the size of thumbnails by using WebP format, and auto compress/decompress VMC files with lz4 or similar format.

 

[TnA]

Between the 2 solutions, I think that the ask-which-size-to-use is better - mainly because uLE can not reduce partitions size.

If I remember correctly, I posted this version of idea 1 even back years ago... So the first was rather a variation of it...

Yes, I thought about this wLE-'issue' as well (when I posted and also THX to the previous post from @jolek, which reminded me of it... It's one reason why I posted the alternative idea 1.) and I agree!

I don't understand the need of the idea 2. I mean, all images are prefixed with the game-ID so it's not a mess IMO... Well, just my optinion.

Well, there is technically not (yet) 'a need' for it... However it would yield various advantages without causing any harm, IMO.

1. It's a rather easy change, compared to a lot of other things.
2. It would allow for a better overview and faster loading-times (if you open the folder on a PC and possibly elsewhere), especially how more Game-ART is installed!
3. It is a better base, to expand the feature if ever wanted. There are multiple ways, this still could be expanded like a 'art-config' (Idea 3, lol. I can elaborate that idea even more as well.), 'per game'.
4. etc.

Better idea: reduce the size of thumbnails by using WebP format,

Huh? Thumbnail? What do you mean by that?
It's probably not going to happen for various reasons:

1. OPL doesn't have support for this file-format.
2. The VRAM-Usage is quite restricted and the VRAM only uses uncompressed pictures (but does support palletized uncompressed formats, to save some space/memory), so every compressed image gets uncompressed and transfered to the VRAM in that state...

@Krah made a good post which has most important informations regarding textures, which formats essentially should be used for what and so on...

Currently palletized 8Bit-BMPs for non-transparent pictures is the best... 8Bit PNG for those with transparency... (because PNGs are currently uncompressed to 32Bit-Images, regardless of their palletization)

The best would be, if gskit would support palletized PNGs and could transfer&setup them in their palletized state to the VRAM.

That would yield:

1. A better palletization-algo (thus a bit more vibrant and exact [to original] colors than BMP).
2. The possibility of using high-resoluted 4Bit-palletized textures.
3. Transparent pictures using 1/4th or even 1/8th of the texture-space they use now, allowing an equivalent increase of the resolution!
4. Saving VRAM...
5. Making more Hires-Stuff possible...
6. etc. etc.

On another note, a compressed 'archive' per game (for the ART/RESource-files) however would indeed yield some space! I suggested and asked for opinions about a per-game-resource/ART-archive before, IMO!

The transfer to the EE would be faster (especially from slow devices), but the uncompressing would probably 'eat up' that speed-increase.

Auto compress/decompress VMC files with lz4 or similar format.

1. That would need code running during the game, to unpack, repack and keep the data-integrity... This would probably decrease game-compatibility!
2. ...or it would need to uncompress it before the game starts... and how would it compress the VMC back again then (if not more code should run during the game is running)?

 

[uyjulian]

It's probably not going to happen for various reasons:

1. OPL doesn't have support for this file-format.
2. The VRAM-Usage is quite restricted and the VRAM only uses uncompressed pictures (but does support palletized uncompressed formats, to save some space/memory), so every compressed image gets uncompressed and transfered to the VRAM in that state...

I was thinking about adding support for that format. WebP supports 8-bit palette format in lossless mode, so it does not need to use a lot of VRAM.

That would need code running during the game, to unpack, repack and keep the data-integrity... This would probably decrease game-compatibility!

I was thinking about doing the compression during the OPL loader.

...or it would need to uncompress it before the game starts... and how would it compress the VMC back again then (if not more code should run during the game is running)?

It would compress again when OPL loader is next launched.

Another solution would be "memorycard folders" or "memorycard archives", where save data would be extracted from the VMC images when OPL loader is launched and when running a game using OPL, they would be placed back into VMC images.

 

[Tupakaveli]

Support for lower bit depth PNG's would probably be the most useful thing to implement.

 

[TnA]

I was thinking about adding support for that format. WebP supports 8-bit palette format in lossless mode, so it does not need to use a lot of VRAM.

Alright that's interesting! I am not sure if it's quantization-algo for the palette is better than PNG's, tho'.

I was thinking about doing the compression during the OPL loader.

Huh?! You mean when the OPL is started again, it should compress the previously saved/changed VMC?
That would cause other issues and is structurally not good.

It would compress again when OPL loader is next launched.

I personally think, this is not a good structure/implementation for this kind of feature (and it would likely cause some issues), but others might have another 'opinion' (the word in marks, because I rather like to follow structural logic... Just Google 'AuB Logic' and the first entry/PDF shows what I am referring to. That's one of the things (1.Month: Math I) an IT got tought on 'Technical Universities' like ours in Chemnitz or the MIT [and yes, that comparison is indeed valid!]. It's not meant as an attack... I can give a more in-deep explanation - and I will do so, if you want - , why it's not structurally good in my opinion. But sometimes I'd like to hint others to what seems obvious to me in a subtle way, to let their brains work even more.).

Another solution would be "memorycard folders" or "memorycard archives", where save data would be extracted from the VMC images when OPL loader is launched and when running a game using OPL, they would be placed back into VMC images.

Well, that would need another way of how we could load saves from other devices than MC... Once we can do that, 'VMC's' become pretty much redundant...

Support for lower bit depth PNG's would probably be the most useful thing to implement.

Indeed! That would be sooooooo great! We could have sooo much fun even with multiple transparent overlapping, moving textures. Lol
...and the palletization/quantisation-algo seems to be better as well, even for non-transparent pictures/textures.

Actually, lower Bit PNGs (even 4Bit) should work well now... It is SOLELY the proper transfer and setup on the VRAM, instead of 'unpacking', which is missing.
However... That would probably need a lot of tests and work. :-|

 

[Krah]

Idea2:
The ART/Recources could have a 'per-game-recource'-folder, so instead of putting all files for all games into one folder, they should/could be placed in a sub-folder within ART, 'per game'...

Not sure what this would mean in terms of loading times and such but it could help with one current issue which is in wLE if you have ALOT of ART it only displays 255 I think? Was the number...Everything after that is still there but you can see it, need to hook your HDD up to a PC in order to edit/delete/rename files after that point..@tupakaveli could probably explain it better

Edit: OK I've been informed it's more like 2056 item max so it would only be a handful of people that would experience this.

I was thinking about adding support for that format. WebP supports 8-bit palette format in lossless mode, so it does not need to use a lot of VRAM.

Support for lower bit depth PNG's would probably be the most useful thing to implement.

+1

 

[TnA]

The PNG-Support would also enable us to tell the creators and users to just use either 4Bit (low color or resolution) or 8Bit (looks very much like the original 32Bit-Image) PNGs for everything and that's it!

That would enable a lot people to optimize themes for HIRES and create new for it.

All game-art would look great and some in even higher resolutions than the current highest resoluted art... The disc-icon is a good example... (192*192 would be my suggestion for it)

 

[Krah]

WebP format supports transparency too right? So that alone could be super useful but proper PNG support would be amazing.

 

[TnA]

Even if, it would still need to be 'set up' correctly on the GS&VRAM (palletized texture, to not waste VRAM).

Does it also support 4Bit-Palletization?

 

[Tupakaveli]

Agreed, even just proper 8-bit PNG support would give us a lot more VRAM to play with.

 

[uyjulian]

Even if, it would still need to be 'set up' correctly on the GS&VRAM (palletized texture, to not waste VRAM).

Does it also support 4Bit-Palletization?

Yes, check this out: https://developers.google.com/speed...stream_specification#color_indexing_transform

If lower-bit palettes are not outputted by libwebp, they can be supported easily with bitshifts and bitwise ors.

 

[Tupakaveli]

All game-art would look great and some in even higher resolutions than the current highest resoluted art... The disc-icon is a good example... (192*192 would be my suggestion for it)

Disc icons being 192x192 would likely result in the 1 pixel rounding error since it isn't a power of 2.

You'd want them to be either 128x128 or 256x256.

 

[Krah]

@TnA
Did some reading, WebP sounds better than PNG anyway.. if uyjulian did decide to spend some time to implement that lib into OPL I know theme creators would be excited (myself included)

All images could be converted to WebP, ART as well as compiled in images.