beetle-psx-libretro
beetle-psx-libretro copied to clipboard
libretro
[Feature Request] Add custom texture dumping/injection support to Beetle PSX core.
Bounty Requirements:
- Ability to dump textures from VRAM
- Ability to replace textures with full-color, high-resolution images that the PSX cannot support natively
- Should preferably support use of custom textures of any size. Must at least support injection of textures up to 2k resolution .
- Support use of common image filetypes (such as PNG and JPG)
- Support for loading texture packs
https://www.bountysource.com/issues/70820889-feature-request-add-custom-texture-dumping-injection-support-to-beetle-psx-core
Ohhhhh!
please, i need this!
I will use waifu2x in my all games hahahahah
I will use waifu2x in my all games hahahahah
@gamaghostmagus Thank you for showing me this nice piece of software :)
I will use waifu2x in my all games hahahahah
@gamaghostmagus Thank you for showing me this nice piece of software :)
And this is not even the better
And this is not even the better
Just found these, are you talking about that @gamaghostmagus ?
SFTGAN, DSFTGAN (Deep SFTGAN) Spatial Feature Transform
SRGAN, ESRGAN (Enhanced SRGAN) Super Resolution Generative Adversarial Network
And this is not even the better
Just found these, are you talking about that @gamaghostmagus ?
SFTGAN, DSFTGAN (Deep SFTGAN) Spatial Feature Transform
SRGAN, ESRGAN (Enhanced SRGAN) Super Resolution Generative Adversarial Network
yes it's!
i use ESRGAN, and it is... AWESOME
@autun12 If you have some ideas on how it could be done, go for it. No one else is working on it, AFAIK. If you'd like to discuss possible strategies, drop by our discord or IRC channels and we can talk through it.
@autun12 do it, and you'll be an hero for people of this lands: we will sing songs to celebrate your genius and bravery... Please, just do it XD
I just saw this issue, for anybody working on this I made a very quick and dirty texture dumping PoC a few years ago in beetle: https://github.com/simias/beetle-psx-libretro/tree/texture_dump The main difficulty is handling palettes correctly and figuring the best heuristic to decide what to dump.
I implemented 2 solutions (exposed through core options), each having its problems. The most straightforward solution is to dump the textures one polygon at a time. The obvious inconvenient of this solution is that you end up with many small files with tiny texture chunks. For instance, running the dump on Medievil I end up with tiny texture chunks like:
Note that there appears to be a bug in my texture dumping code because I end up with many mangled textures, I must've forgotten to handle a special case (maybe the texture mask bits?).
The other possibility is to dump one texture page (256x256 pixels) at a time. The inconvenient of this solution is that you end up with a lot of extraneous data (and each page is dumped multiple times because of the many palettes), for instance:
I'm not really sure what's the best way to deal with this. I assume that many other consoles have this type of issues though, so maybe it's worth looking into what other emulators that support texture replacement do? Dolphin in particular might be interesting to look at, because AFAIK GameCube games also often use palettes.
So that's just for the dumping part, for the loading it's a whole other can of worms, especially if you want to make it work with the GL/Vulcan code. I've actually started thinking about how to do that for Rustation, so I have a few ideas on how to do that if anybody wants to brainstorm it.
Oh and as a side-note, a potential difficulty with paletted texture replacement is that sometimes the same base texture will be used with multiple palettes. For instance in Crash Bandicoot you have red and purple carnivorous plants, they share the exact same texture but use a different palette. Handling these situations when implementing texture replacements might be tricky. Palettes can sometimes be used to simulate shading, using a darker palette when you get in the shadow and a lighter one when illuminated (this is probably less common on the PSX because the hardware has other, more flexible way of doing that sort of shading).
@simias looks promising, I've never coded for psx, but coded for openGL, so I came with another solution, palette lookup is not easy for me cause I got really bored with this specifications. Thanks for your code, will try to use your palette lookup
Btw I can miss something due to lack of knowledge, but is there a way to dump textures just from TIMs?
Actually I amend my previous comment regarding Crash's plant, it's even more devious than that: the texture and palette are purely black and white. Instead they use texture blending in the draw commands. Basically the way it works is that you can tell to render a texture (paletted or not) by blending it with a solid color. So it's an other layer of potential texture shenanigans on top of the texture+palette. Aku-Aku's feather in the same game are the same thing: black and white textures with 4 different colors blended. Here's the relevant code in the GL fragment shader:
https://github.com/libretro/beetle-psx-libretro/blob/18a9de19f3f079408eb8181aa4c5144e9434c5f7/rsx/shaders_gl/command_fragment.glsl.h#L851-L862
That being said these complicated situations might be left for later. Unfortunately I expect that they're fairly common on the PSX...
@Meetem what is a TIM?
@Meetem I'm not sure I understand what you have in mind exactly. Do you mean the texture format as stored in the CD-ROM instead of dumping it straight from the GPU?
Yes, I think this would help. Dumping from play is ok, but you cant replace all the textures then
On Fri, Jan 17, 2020, 18:57 Lionel Flandrin [email protected] wrote:
@Meetem https://github.com/Meetem I'm not sure I understand what you have in mind exactly. Do you mean the texture format as stored in the CD-ROM instead of dumping it straight from the GPU?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/beetle-psx-libretro/issues/492?email_source=notifications&email_token=AB2AF4TYGBSRFU3XODANT33Q6HIOJA5CNFSM4G3JOUMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJID2EY#issuecomment-575683859, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2AF4XDSQT6UT73KFNI37LQ6HIOJANCNFSM4G3JOUMA .
Ah that I've never looked into that so I can't really tell. Replacing the textures as stored in game files would obviously be the simplest approach, although then you won't be able to easily overcome palette limitations or change the texture size.
Beyond that I don't know how standard the texture formats are.
@simias actually I find more convenient way to dump textures, than taking them from polygon draw commands, but CDs TIMs would even better
Actually I want to dump from TIMs but replace textures not in CD, cause psx tims cant be large than 256x256
Well you can always compromise and dump PSX texture uploads, but then I'm not sure how you're going to match with palette data (except if you want to just replace the texture and not the palette I suppose).
In mednafen code texture upload starts with this command: https://github.com/libretro/beetle-psx-libretro/blob/18a9de19f3f079408eb8181aa4c5144e9434c5f7/mednafen/psx/gpu.cpp#L252-L275
You can see that you have the X/Y coordinates in VRAM as well as the dimensions in W and H (the VRAM always assumes 16 bits per pixel).
Then the actual data is received here, 32bits at a time: https://github.com/libretro/beetle-psx-libretro/blob/18a9de19f3f079408eb8181aa4c5144e9434c5f7/mednafen/psx/gpu.cpp#L985-L1019
Thanks, I've figured that out, now I need some time to make naive implementation, also have some ideas to optimize hash calculations
If you have questions about how the PSX GPU operates don't hesitate, I have a fairly in-depth knowledge about it. For texture dumping in general I'm sure you could get better inspiration looking at other project's implementation. Does any PSX emulator out there implements texture dumping and replacement? I seem to recall that gpuBladeSoft had something like that, but I don't really know how thorough it is.
@simias thanks. Given nor poly vram dumping, nor texture page dumping is optimal, I'am trying to figure now how to catch texture upload. There is a way to catch texture part upload during one transaction (or how does it called), when game code calls FB_WRITE. I'am testing on Metal Gear Solid, and Konami logo seems to be splitted across multiple transactions. With that being said, we can go with with this paths: A) Dump TIMs from cd image, and catch up clut in realtime (if lut changed via writing vram) this is relatively easy to make, but hard to implement cd image reading with headers e.t.c B) Write some sophisticated texture upload tracking system which will contains all transactions history for heuristic and not redundant dumping. This is actually hard way (but seems easy), because we need to catch up all texture uploading cases, and also save/load states, also texture is not always uploaded in the same order e.t.c, e.t.c. C) give up on all that stuff and just handle texture uploads AND drawing with further ability to combine multiple textures at load time.
I'am going to stick with way C, cause I don't have enough knowledge to go with A (cause there multiple TIM viewing software), and way B is really PITA as much as I can say for MGS.
Here's my question, does really game can upload software generated clut, or its locked to tims on disk? I think there is a way to change cluts in vram as you want, creating cool effects, don't know if any games using it. And one more: can I draw polys with any clut I want, e.g can I set clut position while drawing poly, without restriction by texture clut position in TIMs?
UPD: I found some opensource tim viewer, but in C#, it's not hard to me to rewrite it in C. So I might go for path A. Questions still applicable, answers needed to choose which path I'll finally go
Well I guess the golden rule of emulation is "if it's possible, somebody must be doing it". There's nothing special about palettes on the PlayStation, they're effectively just linear 16x1 or 256x1 textures somewhere in VRAM (actually "somewhere" has to be in specific portions of the VRAM due to the way they're addressed, but it's still fairly flexible).
As I mentioned previously the PSX supports "texture blending" with a solid color which can be used for certain effects where other consoles would mess with the palette instead (like the carnivorous plant in Crash Bandicoot as mentioned previously). But I'm sure some games must be using palette swapping for some effects.
Unfortunately I think the best way to decide which way to go would be to look at a sample of games and see how they handle textures. Maybe you'll be able to find a solution that works for most of them.
Very cool to finally see some interest in this. I've seen some of these Dolphin repacks where RE2/RE3-specific Dolphin builds are circulated and textures are replaced (RE Seamless Project), and while they look the part, there still seems to be noticeable audio stutter during scene transitions in those Dolphin builds. That and mods like FF7 Remako project, while they might successfully replace the background textures, they're still based on the old DOS Eidos version, with all the numerous defects of that version. So in the back of my mind I was always thinking it would be much more preferable if we could do this kind of texture replacement with a PSX emulator that already has features like PGXP to combat texture warping and polygon jitter, so I couldn't be more excited about people finally exploring solutions to this.
Decided to drop $100 into this bounty just as a show of appreciation - this isn't really about the money, just as a show of appreciation for the development going into this, so hopefully this won't be taken the wrong way.
The FF backgrounds would be a great target for replacement I think but unfortunately it's also not the simplest target. The problem is that, IIRC, the background texture is actually made up of many small square chunks that aren't laid out contiguously in VRAM. You can always dump all these chunks just fine, but you end up with a puzzle. I'm not sure why they do it that way but I think it's because they regroup every background "tile" by palette.
That being said I wouldn't be surprised if the PC port used a similar format, after all it seems like a very straightforward port so maybe they reused most of the assets as-is? If that's the case it would be interesting to understand how they handled it when they modded it.