OPL (Open PS2 Loader)

PS2 Open PS2 Loader v1.1.0

Disc icons being 192x192 would likely result in the 1 pixel rounding error since it isn't a power of 2.
Have you tried it, or are just assuming ( *hint* at your post over from the other forum)? ;)
Why are they not 'a power of 2' (in you opinion)? Because if you put 64px in it, it amounts to 3 lines/fields (9 in total)?

I ought to believe, there is an error in that logic...

You'd want them to be either 128x128 or 256x256.
128*128 is too less, 256*256 is a bit too much and too much 'wasted' VRAM.

@Krah & @uyjulian : Sure if it is better and if support for it is available in gskit and if it would also 'set it up' and 'transfer' it in it's palletized form to the VRAM and can be used, I have no objections against it.
 
Last edited:
I've tested PNG's at 192xWhatever and they result in the rounding error.

Powers of 2 (for our purposes) are:
32, 64, 128, 256, 512, 1024.
 
Why are they not 'a power of 2'
32,64,128,256,512,1024,2048 etc are all power of 2.

192 is not, think of like when you buy sticks of RAM for your PC (in the older days when RAM was a lot smaller lol)

192*192 would not be guaranteed to display the pixel error but it is possible as it's not a power of 2.
 
I've tested PNG's at 192xWhatever and they result in the rounding error.

Powers of 2 (for our purposes) are:
32, 64, 128, 256, 512, 1024.
192/32=6...
So '192 divided by 32 is 6...'.

Edit: Oh you mean 'doubled' from a 'base' of 2... (or in our case 32)

So if only those 'powers of 2' you have mentioned are supported, shouldn't 512*384 Covers not also show the pixel-error?!?
 
Last edited:
32-bit images we should use width with multiples of 64, height multiples of 32.

8-bit images we should use width with multiples of 128, height multiples of 32.

Powers of 2 to avoid pixel rounding error.
 
Aaaah, yes I forgot that it was only related to images with transparency... It's weird tho', because it implies that it can be fixed. Which resolution do the textures of the buttons have now? 64px*64px*8Bit? 4Bit for the Buttons would be sufficient, tho'.


@Tupakaveli: How do you come to that conclusion/calculation specifically? Those who also read it, might not know where you derived it from. ;)
 
Oh... and I meant 'doubled from a base of 32'... I'm still a bit dizzy and half-asleep. :zzz:
 
I'm just going by what Maximus32 said. He explained it all a few times.

The button icons are 32x32 32-bit I believe. He also said we could actually use 4-bit and 8-bit PNG's (if I remember correctly) but they are extracted as 32-bit so there isn't much point.

I agree, there are definitely times where 4-bit or 8-bit PNG's would be quite useful.
 
I know, but those who didn't read the other thread(s) [especially in the other forum], would probably not understand the reasons for it, albeit being correct!
Some reasons: minimum texture-size, frame-composition, i-/p-mode, etc.


Well, let's hope we will have proper transfer&setup of some kind of format which supports 4Bit and 8Bit-palette and transparency at once.

I don't care that much if it is PNG or WebP as long as we get the best picture/texture-quality 'out of it', while sparing as much VRAM as possible (thus allowing very complex and high resoluted arts and themes).
 
32x32 32-bit
yea thats correct, I've never bothered experimenting with other bit depth PNGs as they are all extracted the same anyway and VRAM usage has always been on my mind rather than file size. we're talking about a few KiB difference so I never really concerned myself with it.

Edit: perhaps i'll test a couple tonight for the button icons to see just how much difference there is in KiB/quality

Edit 2: for not even 1KiB (file size) saved per image i'd rather use the 32bit icons personally (which is in the current PR)

 
Last edited:
If it would be correctly transfered&setup, a 64*64*4Bit-Texture would use half of the amount of VRAM, while quadrupling the resolution (doubled per axis/dimension).

That's as if you would switch from 800*600 to 1600*1200 on a PC-Monitor.
 
Edit 2: for not even 1KiB (file size) saved per image i'd rather use the 32bit icons personally (which is in the current PR)

You need to have the right software to resave the icons, otherwise it will look horrible. GIMP does a horrible job, but I don't own a Photoshop license. Which was why I had to ask @Berion for help with adjusting the icons.

I also used some Russian tool for reducing the bit depth, but I forgot its name. It also did the job though.
 
ou need to have the right software to resave the icons, otherwise it will look horrible. GIMP does a horrible job, but I don't own a Photoshop license. Which was why I had to ask @Berion for help with adjusting the icons.
I've got a photoshop license :) converted to 8-bit with photoshop but maybe a conversion tool like you suggested could be better

Edit: hmm why am I not shocked @sp193 is right, again! :-P just using https://tinypng.com/ produced better results in both image quality and compression at 8-bit (why did I pay for photoshop!?)

32-bit - 2.34KB


8bit - 1.21KB
 
Last edited:
Btw.: 32*32*32Bit=32.768Bit=4KB... On a 8Bit File that would be 1KB... On a 4Bit File that would be 512Byte...

Sooo... There seems to be something wrong with these files... oh... Possibly that rest is the pallette.

Anyway... I agree that we probably do not need to save much VRAM on those tiny textures, but quadrupling the resolution would certainly be nice!


Edit: ...and the 8Bit-File looks like an 8Bit File... NOT palletized!
 
I've got a photoshop license :) converted to 8-bit with photoshop but maybe a conversion tool like you suggested could be better

Edit: hmm why am I not shocked @sp193 is right, again! :-p just using https://tinypng.com/ produced better results in both image quality and compression at 8-bit (why did I pay for photoshop!?)

It may be the method used, but @Berion certainly used Photoshop files.

32-bit - 2.34KB


8bit - 1.21KB

How did you determine those sizes?
If you just measured the size of the PNG file, that is the size of the PNG file on disk, which has the texture compressed. Once decompressed, the sizes of the textures should be as follows:
32-bit: 32*32*4 = 4KB
8-bit (256 colours): 32*32*1 = 1KB

Of course, the 8-bit texture will also have a 256*4 = 1KB palette.
It is possible to have a 16-bit palette instead, resulting in a 256*2=512-byte palette.

Edit: ...and the 8Bit-File looks like an 8Bit File... NOT palletized!

It is possible to make an 8-bit palletized texture look that nice.
There is no 8-bit/pixel colour mode.
 

Similar threads

Back
Top