01-17-2014, 08:48 AM (This post was last modified: 04-13-2014, 03:01 AM by onelight.)
My friend gdmk tell me something wrong with GVG NEXT PLUS
This game is use 32 bit color depth, but jpcsp use 16bit color depth.
This bug just found in NVIDIA card
jpcsp 16 bit color depth
PPSSPP use 32 bit color depth
Kingdom Hearts Birth by Sleep Final Mix which game allow you choose 16 bit color depth or 32 bit color depth
16 bit color depth
32 bit color depth, true color
so gdmk suggest jpcsp use 32 bit color depth defualt also.
btw PPSPP run Kingdom Hearts Birth by Sleep Final Mix so good ,and the Texture Scaling , xBRZ is beautiful.
This is really interesting. Do you think the author would mind if I added support for this plugin in JPCSP?
I could adapt the code and implement xBRZ in Java, but I think it would be nice to use this feature as a plugin.
This is really interesting. Do you think the author would mind if I added support for this plugin in JPCSP?
I could adapt the code and implement xBRZ in Java, but I think it would be nice to use this feature as a plugin.
I think it is ok, you can added support for this plugin in JPCSP. But this plugin is Experimental, you need update it and fix some bug. You should also fix some bug in GVG next plus and Kingdom Hearts Birth by Sleep Final Mix.
This is really interesting. Do you think the author would mind if I added support for this plugin in JPCSP?
I could adapt the code and implement xBRZ in Java, but I think it would be nice to use this feature as a plugin.
I think it is ok, you can added support for this plugin in JPCSP. But this plugin is Experimental, you need update it and fix some bug. You should also fix some bug in GVG next plus and Kingdom Hearts Birth by Sleep Final Mix.
I've added experimental support for XBRZ4JPCSP plugin in r3438. This will also be used for any other plugins we might develop or receive.
All that's needed is to copy the .dll inside the new plugins folder and paste it into the lib/[OS ARCHITECTURE] folder (same place as xuggler's .dll file).
As for the color issue, I'm still looking into it. Are there any settings that fix this? For example, does saving GE to textures also uses 16-bit or it gets translated to 32-bit? Thanks!
This is really interesting. Do you think the author would mind if I added support for this plugin in JPCSP?
I could adapt the code and implement xBRZ in Java, but I think it would be nice to use this feature as a plugin.
I think it is ok, you can added support for this plugin in JPCSP. But this plugin is Experimental, you need update it and fix some bug. You should also fix some bug in GVG next plus and Kingdom Hearts Birth by Sleep Final Mix.
I've added experimental support for XBRZ4JPCSP plugin in r3438. This will also be used for any other plugins we might develop or receive.
All that's needed is to copy the .dll inside the new plugins folder and paste it into the lib/[OS ARCHITECTURE] folder (same place as xuggler's .dll file).
As for the color issue, I'm still looking into it. Are there any settings that fix this? For example, does saving GE to textures also uses 16-bit or it gets translated to 32-bit? Thanks!
As for the color issue
Use only GE graphics (32-bit but blinks)
This is really interesting. Do you think the author would mind if I added support for this plugin in JPCSP?
I could adapt the code and implement xBRZ in Java, but I think it would be nice to use this feature as a plugin.
XBRZ in java !? I don't dare to think it may run fast this way.
This is really interesting. Do you think the author would mind if I added support for this plugin in JPCSP?
I could adapt the code and implement xBRZ in Java, but I think it would be nice to use this feature as a plugin.
XBRZ in java !? I don't dare to think it may run fast this way.
Hehe, indeed. A lot of the texture scaling and filtering algorithms are too demanding for Java. This plugin approach gives much better results.
@onelight: Sorry, I forgot to mention the plugin is still disabled (internally), since I was still researching some graphical issues.
Also, I've found out what's going on with the 16-bit color depth, but I need to discuss it with gid first before making any changes.
Turns out we're correctly handling the textures in 32-bit format (internal format), but in the final frame buffer update (line 309 in sceDisplay) the sub texture being set (setTexSubImage at line 1698) is 16-bit (in Kingdom Hearts case).
In fact, if you comment out that portion of code you can see that the underlying texture is indeed 32-bit. While glTexImage2D uses an internal format (defined by us to be 32-bit), glTexSubImage2D doesn't and relies on the pixel format we are passing.
