Author Topic: What would it take to fix FF8's backgrounds (field files)?  (Read 35880 times)

Omzy

  • *
  • Posts: 205
    • View Profile
Hi all,

I just started playing the Steam version of FF8 and the characters and objects look nice and crisp but the backgrounds are so pixelated that it makes me die a little on the inside. When I had that feeling playing FF7, I resized them myself with long-handed photoshop algorithms, but I could conveniently rely on Aali's driver doing the import nice and clean.

However, with FF8, according to Aali (in response to Mcindus' Triple Triad HD project),
FF8PC emulates the playstation GPU for most parts of the game. Thats bad news for several reasons but just to name a few it means the game has limited memory available for textures, doesn't use relative UV coordinates and does not readily accept textures in any other size or format than it was designed to. I don't think you'll have much luck, unfortunately.

My problem is that I'm so obsessive that I can't take no as an answer. I know that if I take the game apart myself binary bit by bit, I can build it again, theoretically, so that it will work however I want it to, given an infinitum of time. My question for those who have the knowledge of game engines, gpu architecture, executables, drivers, etc, what is the path of least resistance to allowing this game to accept larger textures? This may include some reverse engineering, recompiling executables, creating DLL's, etc.

Please use this topic as a place to sound off and throw your ideas around.

My hope is that when I have time on my hands in about a year, this question will be answered, or at least someone can provide me with the right direction to learn the things necessary to complete this task. I really believe it is a step-by-step endeavor, but right now the steps are not clear to me.

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
Nice!

Hellbringer616

  • *
  • Posts: 1913
    • View Profile
Hi all,

I just started playing the Steam version of FF8 and the characters and objects look nice and crisp but the backgrounds are so pixelated that it makes me die a little on the inside. When I had that feeling playing FF7, I resized them myself with long-handed photoshop algorithms, but I could conveniently rely on Aali's driver doing the import nice and clean.

However, with FF8, according to Aali (in response to Mcindus' Triple Triad HD project),
My problem is that I'm so obsessive that I can't take no as an answer. I know that if I take the game apart myself binary bit by bit, I can build it again, theoretically, so that it will work however I want it to, given an infinitum of time. My question for those who have the knowledge of game engines, gpu architecture, executables, drivers, etc, what is the path of least resistance to allowing this game to accept larger textures? This may include some reverse engineering, recompiling executables, creating DLL's, etc.

Please use this topic as a place to sound off and throw your ideas around.

My hope is that when I have time on my hands in about a year, this question will be answered, or at least someone can provide me with the right direction to learn the things necessary to complete this task. I really believe it is a step-by-step endeavor, but right now the steps are not clear to me.

You'll want to contact edgbla: http://forum.emu-russia.net/viewforum.php?f=29&sid=7fcf6b31db2b046972d259884b764bec
His unreleased version of his GPU plugin can replace PSX textures. so if anyone will know, it's him

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
 Something wrong with the link...  :|

Hellbringer616

  • *
  • Posts: 1913
    • View Profile
Works for me. If it takes you to a Russian site it's supposed to. The guy is Russian But he can speak English fairly well.

Omzy

  • *
  • Posts: 205
    • View Profile
Thanks for the referral Hellbringer, I sent edgbla a message to ask what his thoughts are. I don't think he personally speaks english but he uses translating programs and has a friend on his forums that can do rough translations that he posts alongside his russian text. Here's what I found in regards to his psx gpu emulation:

Quote from: edgbla
Picture enhancement methods.

Internal resolution.
The most powerful method is an increase of the internal resolution.
This method allows you to increase the resolution of the image independently
in width and height by an arbitrary integer factor. In the manual I wrote that
the best in my opinion is the resolution of 2x2.
This does not mean that I cannot add larger factors, although it is somewhat inconvenient.
I believe that further increase in resolution degrades the image, as "soapy" textures
with perfect geometry leave a bad impression. Generally there is no restriction,
I can make it 8x8, which is equal to setting "Ultra / Ultra" (I guess)
in the hardware plugin OGL2 by Pete Bernert, but I doubt you can find a
computer capable of at least 3 fps in this resolution. :D

24-bit renderer.
Console has a 15-bit renderer, that's why Gouraud-shaded polygons have so
unpleasant colors. When you turn this mode, renderer goes into 24-bit mode
and the picture in this case is not only looks as good as on hardware plugins,
but also doesn't have their drawbacks, you should turn "Gouraud shaded primitives"
option for this. If you turn the "All primitives" mode, I'll tear your hands away :),
because in this case you'll see the artefacts similar to hardware plugins, like
various different colored borders around the picture.

Texture bilinear filtering.
The translators can't translate my text.  :lol:

Filters.
Then goes filters, btw, very good ones: Super Eagle, Sal, Hq, Scale.
For those who like them, I don't. :)
But there are 'fans' of them, so I've decided to add them.
I should say, that they're also very hardware-dependant, especially while
working in pair with the increased internal resolution.

Shaders.
Realized a partial support for shaders written for gpuPeteOGL2,
Only glsl shaders are supported.

What I gather from this is that he is able to set the output resolution to whatever he wants using a scaling factor and can use a filter for the upscale in addition to shaders. This by itself sounds like a big improvement. If you can use bilinear interpolation you can do a sort of poor quality upscale on the fly, especially if you add a shader to improve the result. However, its unlikely that there is any filter/shader combination that can achieve the results of the fractal algorithm that has impressed me so much. Since that fractal algorithm requires rendering/processing time that will exceed what can be done on-the-fly frame by frame, it would still need an external texture feature. I'm assuming that having an external texture feature would require a driver or importer specific to final fantasy 8, given the nature of the field files. I have no problem working with the playstation ROM/emulator version of FF8 since I can still play it on a PC. Perhaps this dialog will result in using his PSX emulator with a specific driver/plugin allowing external texture import. I've already written PuPu so some progress has at least been made in completing the chain of file conversions.

Do you guys think I've interpreted this correctly or am I missing something? I'll admit that I don't know much about this subject, especially as far as limitations go, so correct me if I've made any erroneous conclusions.

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
When I click on the link it gives me an "unable to connect" note.

Amazing find btw!!! :)
« Last Edit: 2014-05-17 20:54:55 by LeonhartGR »

Omzy

  • *
  • Posts: 205
    • View Profile
When I click on the link it gives me an "unable to connect" note.

Amazing find btw!!! :)
Maybe you have a browser plugin, firewall, or security software that is blocking it since it is all in russian. My forum registration was sent to gmail spam since it wasn't in english.

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
I wish this method works! Will it be just for the emulator then?

Omzy

  • *
  • Posts: 205
    • View Profile
I found some more information on what his GPU plugin allows:
Quote from: egdbla
Processing:

«Internal resolution»
Allows you to improve the image quality in 3D games, requires a powerful system.
( Possible values: 1 - 4. )

«Use 24-bit renderer»
This makes picture quality approach that of hardware accelerated plugins by eliminating color banding and smoothly painting the polygons.
"Disabled" — disabled.
"Primitives with dithering" — enabled only for primitives with dithering.
"Gouraud shaded primitives" — enabled for all Gouraud-shaded primitives.
"All primitives" — enabled for all primitives.

«Disable 'dfe' emulation»
Disable interlace emulation. All of the odd or even lines of the frame ( so-called fields ) are rendered in turns. This noticeably decreases the picture quality as that line alternation is clearly seen, and at the same time this gives rendering quite a speed boost because the fillrate needed is cut in half. This option disables this drawing and output mode and vastly increases picture quality, but reduces perfomance due to increased fillrate.

Postprocessing:

«Deinterlacing method»
Useful only when "Disable 'dfe' emulation" mode is disabled.
"Line doubling" — draws each line twice, causes a slight screen shaking, the best mode for dynamic games and the closest to a real TV picture.
"Field combination" — mixes odd and even fields, causes the "comb" effect, the best mode for static games.

«Filtering»
The entire frame buffer is filtered. You may choose a filter to your liking, but remember that they might be very CPU-intensive. 2D games usually look better with SuperSAIx2/SuperEagle, while HQ2x/HQ3x are more suitable for 3D games.

«Shader effect»
Use shaders written for gpuPeteOGL2. Put each shader in its own folder inside the «./shaders» directory alongside the emulator executable.

«Shader level»
( Possible values: 1(Minimum), 2(More), 3(Medium), 4(Maximum). )

«Bilinear filtering»
Reduces picture blockyness. Bilinear filtering is hardware-accelerated, speed reduction is almost unnoticeable.
Information on the SuperSal/SuperEagle/hq4x/4xBRZ filters can be found here on wikipedia: http://en.wikipedia.org/wiki/Image_scaling
Here's a nice tool that allows you to quickly compare a variety of upscale methods (does not include fractal): https://code.google.com/p/2dimagefilter/downloads/detail?name=ImageResizer-r129.exe&can=2&q=

Here are examples of all the major upscaling filters I am aware of:
original - http://postimg.org/image/49g9clby5/
4x SuperSal (2x run twice) - http://postimg.org/image/ilol1h0yz/
4x SuperEagle (2x run twice) - http://postimg.org/image/81rxh3cev/
hq4x - http://postimg.org/image/sjbjchosd/
4xBRZ - http://s7.postimg.org/vqbiixhmj/wake_4x_BRZ.png
4x fractal - http://postimg.org/image/fyh6ixf4t/
(for fractal, imagine characters and text box aren't there since fractal must be external textures only)

Most of these were invented to upscale 2d pixel art, not renders of 3d scenes or photographs. I think the 4xBRZ is the best-looking real-time filter but looks cartoony and misinterprets many boundaries. The reigning champion is still the 4x fractal but it is not suitable for real-time filtering due to both computational speed and licensing. The others aren't much of an improvement on the original. Consider also that if a filter was applied real-time it would apply to characters and text boxes, whereas external texture import would be applied only to selected textures like fields (backgrounds). I'm not sure what shaders could be applied on top of these filters to further refine the result.

Because of these things, I sense that external textures may still be the best way to go for quality's sake, but I welcome screenshots that can prove me wrong if there are any.

I wish this method works! Will it be just for the emulator then?

If this method works it will only work on the PSX emulator and edgbla's GPU plugin, meaning that support for other mods like Roses and Wine may need more work to allow them to function. I'm not really sure what that would entail or what the full implications would be and if anyone could spell that out, it would help.
« Last Edit: 2014-05-18 05:48:10 by Omzy »

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #10 on: 2014-05-18 09:35:43 »


Kaldarasha

  • *
  • Posts: 2449
  • Prince of Model Editing
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #11 on: 2014-05-18 12:22:05 »
Only as a node GpuBlade use the CPU for graphic rendering, so it is ve~ry slow.

What we need is a program which updates the textures in the video memory and it should lead the game engine to believe that everything is at it should be. The rerelease of FF8 uses now DirectX9 so maybe a modified version of Textool would work.

A fullscreen shader to smooth the backgrounds could be used with Aali's driver as well, if you know how to write one. In theory the shaders for Pete's Opengl plugin should work with Aali's Opengl driver.They would need of course some changes.

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #12 on: 2014-05-18 15:17:29 »
A pc mod would be amazing!!!

Aali

  • *
  • Posts: 1196
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #13 on: 2014-05-18 15:56:40 »
I would like to point out that actually replacing the textures is the easy part (in fact it is trivial), the problem is figuring out what to replace and what to replace it with.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #14 on: 2014-05-18 16:16:18 »
Only as a node GpuBlade use the CPU for graphic rendering, so it is ve~ry slow.
What we need is a program which updates the textures in the video memory and it should lead the game engine to believe that everything is at it should be. The rerelease of FF8 uses now DirectX9 so maybe a modified version of Textool would work.

I found the textool readme, which includes instructions:
Quote from: ficedula
Now you can go away and edit the BMP file all you like ... however, don't change the size *OR* the palette. Whatever palette the BMP has originally is what the game is going to use, so there's no point trying to change the colours in the BMP file.

This indicates that you can change the content of the textures but not the size since the game still expects the same texture size. Likewise, repackaging fields into the same files with the same size will not work since I am looking for a 4x rescale. (As a tangent, some people have asked why 4x? Why not 2x? My answer is that with Aali's driver, the resolution of the sprites/3d models actually is closest to the 4x textures and they look best when superimposed on 4x backgrounds). The convenient thing about Aali's driver is that it allows you to simply drag and drop your resized textures to an external directory where his driver looks first to replace textures. If a similar strategy can be incorporated using DirectX to allow external textures, that may be the best way. Does anyone know anything about the DirectX that is used by the Steam version of FF8? Can it be modified? Can additional files be added?

A fullscreen shader to smooth the backgrounds could be used with Aali's driver as well, if you know how to write one. In theory the shaders for Pete's Opengl plugin should work with Aali's Opengl driver.They would need of course some changes.

After looking into these shaders, it seems that they are the same algorithms used in the filters I described above, so the best you're going to get is the 4xBRZ, which in my opinion, isn't acceptable quality. I like this DirectX idea, though, if we can get more information on it.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #15 on: 2014-05-18 16:20:22 »
I would like to point out that actually replacing the textures is the easy part (in fact it is trivial), the problem is figuring out what to replace and what to replace it with.
Thanks for joining the discussion Aali. Would you mind expanding on this--are you referring to the driver or the game files, your driver or directx?

Edit: sorry for the double-post, didn't think.

Kaldarasha

  • *
  • Posts: 2449
  • Prince of Model Editing
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #16 on: 2014-05-18 17:35:46 »
There is a mod for Dark Souls, which allow changes of the textures with higher res versions of them. Maybe the author of it has some ideas.
http://www.nexusmods.com/darksouls/mods/19/?

Omzy

  • *
  • Posts: 205
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #17 on: 2014-05-18 17:55:42 »
There is a mod for Dark Souls, which allow changes of the textures with higher res versions of them. Maybe the author of it has some ideas.
http://www.nexusmods.com/darksouls/mods/19/?
I would like to point out that actually replacing the textures is the easy part (in fact it is trivial), the problem is figuring out what to replace and what to replace it with.

Ok, I think I understand what you mean now, based on Kaldarasha's link and a follow-up link I found: http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html
Quote
This is a program that intercepts all Direct3D 9 (D3D9) commands issued by a running application. These commands are then dispatched to a separate program that interprets and responds to them. The commands can be forwarded to the operating system, discarded, or modified as desired...
...The idea that enables this interception is that Direct3D (like most Windows APIs) is dynamically linked. Furthermore, Windows first searches for dynamic link libraries (DLLs) in the application's local directory. Therefore, to intercept calls to the D3D9 dynamic link library, d3d9.dll, all that is required is to make a custom version of d3d9.dll and put it in the application's local directory, which is exactly what this framework does. All intercepted calls are passed to a separate DLL, d3d9Callback.dll. This DLL decides what actions to take as a result of the command stream. It is also allowed to modify or discard the command stream before the interceptor sends it to the "real" version of d3d9.dll that was the intended target of these calls, which dispatches the commands to the graphics card.

So in order to swap in new textures, you need to identify the commands that call the internal texture files and change them to commands that call external texture files, but this is the hardest part, as Aali points out (if I interpreted that right).

Edit (notes for myself):
PIX for windows allows analysis of any directx3d program for function calls, objects, and playback for each frame. http://www.chromium.org/developers/how-tos/debugging/pix-for-windows
Getting PIX to work with FF8 is difficult. In order to start an experiment you must select the target exe and the correct target is FF8_EN.exe, however, only the launcher allows you to launch the game so it fails. The workaround is to have FF8_EN.exe targeted, have the launcher ready to press PLAY, then press 'Start experiment' in PIX and then PLAY in the launcher as fast as possible and it will hook itself to the process. Unfortunately, for whatever reason, the game crashes when I load a save. It did not crash when starting a new game, so it played the intro FMV then entered the scene where Squall wakes up. You can then capture a frame of information with the F12 key.

PixRun from waking scene: https://drive.google.com/file/d/0ByMkI_Nb8OmJLTNXT2xzUWtFNDA/edit?usp=sharing
To view renders/textures, click Render tab in Details window, then use Find event tool in Events window (magnifying glass) and search for SetTexture. Click on texture references to show in right panel.

Unique field texture EIDs found in a single frame (frame 3947):
12445
12510
12656
12823
12960
13606 - complete frame

There are more EIDs of the same textures with different palettes.

https://github.com/GuentherVIII/Final-Fantasy-VIII-Launcher
« Last Edit: 2014-05-18 23:13:46 by Omzy »

Aali

  • *
  • Posts: 1196
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #18 on: 2014-05-18 22:33:36 »
In FF7 I have basically rewritten the function that loads .tex files so that it stores the filename in a place where I can retrieve it once the game tries to upload it to a texture.

Since field files are not in .tex format I have rewritten another function that gets called when the game loads field files so that I can construct a meaningful filename and place it where the texture loader will find it. So far no problem.

However, in FF8 there are many many different texture formats each with their own loaders scattered all over the place usually with several levels of indirection (several textures inside multi-part files sometimes inside other multi-part files ???) and so very hard to replace with something that can construct a meaningful filename. Now even if we could tackle this issue these routines are just loading data into the emulated GPU VRAM, there's not even necessarily a 1:1 mapping from file to texture at this point. When drawing a scene, the emulated GPU uses a set of predefined textures which each represent a certain area of the VRAM and a certain palette (using some kind of cache system with 16? or so different textures so they're not each fixed to a certain area but get swapped around) so even if we had useful filenames at this point it would be extremely difficult to map them to these textures. For a while I was experimenting with keeping a map of VRAM areas to filenames and figuring out on the fly which area the game was trying to draw from but this turned out to be completely unfeasible and never really worked for anything but the credits screens.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #19 on: 2014-05-19 01:12:49 »
Thanks a lot for the explanation Aali! It does seem a daunting task, but maybe over time we can arrive at a solution.

Let me recap my new understanding of how all this works, based on what Aali wrote and my findings in PIX:
1) The game engine has a texture to VRAM uploader for all textures (tex and fields)--there may actually be several loaders for multiple texture formats
2) When a scene is drawn, a loader takes a texture file from the game files and writes part of the texture to an area of VRAM
3) Each texture file contains multiple parts (e.g. curtains, bed, wall in the example of the waking scene), each of which is loaded into different areas of the VRAM
4) Each of these parts requires a different color palette, which may be one of 16? or so cached palettes that determine the colors of the texture part written to that segment of VRAM
5) The resulting VRAM holds several separately colored sets of overlapping information all derived from the original source image
6) Only a part of that VRAM may be used (the segments of the parts which are correctly colored)
7) Collectively, these segments of VRAM contain all of the information required to correctly write the parts of a scene to the final output

From the Direct3D perspective:
1) D3D recieves a call from a loader to load a part of the texture file into VRAM with a certain palette applied.
2) D3D recieves many of these calls and VRAM is populated with the various parts of the entire texture
3) D3D recieves calls to write these parts (in the order that the parts were loaded into VRAM?) onto the surface image
4) At the end of the frame, the parts magically have assembled into the correctly colored scene

In other words, a D3D interceptor will be able to read the assignments of each texture part to the VRAM and the resulting texture after the palette has been applied, but it will not know the origin of the texture (filename).

This means that there are 2 possible routes towards the solution:
1) Modifying the game engine's texture loaders as Aali has described, in order to obtain filenames for external textures that can be loaded (limited by the difficulties Aali mentioned)
2) Inferring from the D3D calls which field file the frame wants to display with some sort of matching algorithm and replacing all instances of texture parts with the correct parts (no palette work necessary since we are already working with output but determining the filenames and parts to replace may be near impossible)

Both solutions involve finding which file the game wants to display and which part of that file belongs in which part of the VRAM. I still haven't considered what it takes to plug-in higher resolution versions--does this use U/V coordinates and are there D3D calls that determine the mapping?

Again, still learning here, so I may have made mistakes, correct 'em for me if you please.

Shard

  • *
  • Posts: 330
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #20 on: 2014-05-19 02:17:05 »
I thought D3D and DX interceptors like TexMod intercept textures based on hash checks (or a similar calculation), making it possible for multiple textures to accidentally get replaced by a singular texture. Texture mods with too many replacements break down with those types of programs for this reason. At least TexMod does, I've never used PIX.

I'm about as eager as anyone to get higher resolution texture support in FF8. Maybe when my VO project is done I can look into it more.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #21 on: 2014-05-19 04:58:40 »
I thought D3D and DX interceptors like TexMod intercept textures based on hash checks (or a similar calculation), making it possible for multiple textures to accidentally get replaced by a singular texture. Texture mods with too many replacements break down with those types of programs for this reason.
When I referred to a matching algorithm above, that sort of thing is what I had in mind--a hash function. As long as it is written such that no keys(field files) have collision or fall into the same 'bucket', then that should work. This is possible, I think, since we know what all of the texture data is before-hand. We'll have to test such a function to make sure there are as many unique keys as there are hashes. http://en.wikipedia.org/wiki/Perfect_hash_function

Aali

  • *
  • Posts: 1196
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #22 on: 2014-05-19 14:23:32 »
I have already used such a hash method in the past to debug the driver (so that I can set breakpoints when a particular texture shows up or compare output from the texture conversion process) but it is not workable in real-time.

Textures are usually 256 * 256, either 8- or 16-bit. Add 16 different palettes of 256 32-bit colors each and you've got 70-150kb of data to hash every time the game tries to upload a texture. Now add to the mix the fact that palettes are not static, the game (and especially field files) often writes directly to the palette causing the whole texture to be reloaded (and depending on how the palette is modified you could get a million or so different hashes just for that one texture). In FF7 that is still kind-of manageable, textures aren't reloaded all that often and you can disable these palette writes without completely ruining the game (you'll just make all the field scenes feel static and dead).

Of course, FF8 is a lot more liberal with these things. Every time the game touches the emulated VRAM it'll reload some texture, sometimes more than one, this process alone is enough to make the game run slow on a modern machine, I've already had to implement a bunch of checks just to make sure it doesn't try to reload the same textures every single frame. Now, as if that wasn't enough, both palettes and textures are not even guaranteed to be in a consistent form, you'll sometimes get a texture uploaded that just contains random garbage, wasting time and hash space.

Even if such an approach is theoretically possible it would be nothing but hacks upon hacks upon further hacks. It would be a nightmare to support.

LeonhartGR

  • *
  • Posts: 2577
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #23 on: 2014-05-19 15:43:17 »
I wish some team would re-design the game in an alternative engine like unity...

Hellbringer616

  • *
  • Posts: 1913
    • View Profile
Re: What would it take to fix FF8's backgrounds (field files)?
« Reply #24 on: 2014-05-19 16:29:37 »
I have already used such a hash method in the past to debug the driver (so that I can set breakpoints when a particular texture shows up or compare output from the texture conversion process) but it is not workable in real-time.

Textures are usually 256 * 256, either 8- or 16-bit. Add 16 different palettes of 256 32-bit colors each and you've got 70-150kb of data to hash every time the game tries to upload a texture. Now add to the mix the fact that palettes are not static, the game (and especially field files) often writes directly to the palette causing the whole texture to be reloaded (and depending on how the palette is modified you could get a million or so different hashes just for that one texture). In FF7 that is still kind-of manageable, textures aren't reloaded all that often and you can disable these palette writes without completely ruining the game (you'll just make all the field scenes feel static and dead).

Of course, FF8 is a lot more liberal with these things. Every time the game touches the emulated VRAM it'll reload some texture, sometimes more than one, this process alone is enough to make the game run slow on a modern machine, I've already had to implement a bunch of checks just to make sure it doesn't try to reload the same textures every single frame. Now, as if that wasn't enough, both palettes and textures are not even guaranteed to be in a consistent form, you'll sometimes get a texture uploaded that just contains random garbage, wasting time and hash space.

Even if such an approach is theoretically possible it would be nothing but hacks upon hacks upon further hacks. It would be a nightmare to support.

So short of a new game engine (like q-gears) we are sadly just not going to get support for it eh?

Maybe they redesigned the Steam version and we could use that? I know it's doubtful.. But a man can dream