- EPSXE CHRONO CROSS PATHWAYS OFF HOW TO
- EPSXE CHRONO CROSS PATHWAYS OFF SOFTWARE
- EPSXE CHRONO CROSS PATHWAYS OFF CODE
Questions still applicable, answers needed to choose which path I'll finally go UPD: I found some opensource tim viewer, but in C#, it's not hard to me to rewrite it in C.
EPSXE CHRONO CROSS PATHWAYS OFF SOFTWARE
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.Īnd 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? 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. 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.Ĭ) give up on all that stuff and just handle texture uploads AND drawing with further ability to combine multiple textures at load time. With that being said, we can go with with this paths:Ī) 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ī) Write some sophisticated texture upload tracking system which will contains all transactions history for heuristic and not redundant dumping. I'am testing on Metal Gear Solid, and Konami logo seems to be splitted across multiple transactions.
EPSXE CHRONO CROSS PATHWAYS OFF CODE
There is a way to catch texture part upload during one transaction (or how does it called), when game code calls FB_WRITE.
EPSXE CHRONO CROSS PATHWAYS OFF HOW TO
Given nor poly vram dumping, nor texture page dumping is optimal, I'am trying to figure now how to catch texture upload. 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 thanks. 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 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. I'm not really sure what's the best way to deal with this. 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: The other possibility is to dump one texture page (256x256 pixels) at a time. 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?). For instance, running the dump on Medievil I end up with tiny texture chunks like: The obvious inconvenient of this solution is that you end up with many small files with tiny texture chunks. The most straightforward solution is to dump the textures one polygon at a time. I implemented 2 solutions (exposed through core options), each having its problems. The main difficulty is handling palettes correctly and figuring the best heuristic to decide what to dump.
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:
0 kommentar(er)
