Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Omzy on 2014-05-15 00:00:20
-
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.
-
Nice!
-
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
-
Something wrong with the link... :|
-
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.
-
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:
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 (http://forums.qhimm.com/index.php?topic=13444.0) 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.
-
When I click on the link it gives me an "unable to connect" note.
Amazing find btw!!! :)
-
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.
-
I wish this method works! Will it be just for the emulator then?
-
I found some more information on what his GPU plugin allows:
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 (http://forums.qhimm.com/index.php?topic=13715.0) 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.
-
(http://i.imgur.com/6ddwxQ4.png)
(http://i.imgur.com/ba96dqt.jpg)
-
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.
-
A pc mod would be amazing!!!
-
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.
-
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:
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.
-
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.
-
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/?
-
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
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
-
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.
-
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.
-
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.
-
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
-
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.
-
I wish some team would re-design the game in an alternative engine like unity...
-
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
-
Steam version was a re-release unfortunately... that's about all the fuzz for mods anyway... but they managed to make directx 9 to work with the game. Only graphical updates so far are the sweetfx image management.
-
Only graphical updates so far are the sweetfx image management.
And the Japanese version has a pretty updated high-res font. I don't know the first thing about how they did that though.
-
Yeah I should correct myself by defining graphical updates as the in-game ones...
-
Correct me if I'm wrong, but the menu system seems to be developed consequently for PC. There were different resolutions in the first place, so I think it was pretty easy for them to replace the fonts (we have done this already too).
-
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).
I wonder if a different hashing algorithm would make this easier. The hash can be computed from the values of specific pixels normalized to black and white and stored as a string of binary digits. Most backgrounds should have a different pattern of digits if enough digits are used and a few will fail this check if they are largely homeogenous like the credits having mostly black, etc. With carefully chosen pixels and enough of them we might achieve perfect hashing. This may eliminate dependence on palettes and be more specific to patterns. Did that make any sense or am I speaking crazy? I have yet to dig my fingers into the dirt so it might sound abstract right now but I'm going to do some experimenting with patterns and see if it works.
-
The original version offers the option to choose between the low-res PSX font texture (1 256x256px texture) or the hi-res PC texture (2 256x256px textures) but the 2013 version removed this option and the hi-res font is now set by default. As I pointed out in the SeeD thread, the new japanese PC release features really sharp font so it would be interesting to see how it works (several 256x256px *.tex files or maybe 1024x1024px/2048x2048px single texture). Also in the main.fs original files there is a 512x512px *.tim file but I'm not even sure if it is an unused file or not.
-
I've been playing with hash functions and came up with this, which samples 16 distinct pixels in the VRAM image and compares their grayscales to generate a hashvalue based on their differences. It uses a threshold value for how large the difference must be and that determines if a 0 or 1 is written. Based on only 1 frame of gameplay, this works, however it may need to be expanded to 32 pixels or additional comparisons instead of a linear comparison maybe odds vs evens, etc, if we are to expect different values for every texture/palette combo in the game. Hopefully this sort of technique can eliminate the need for distinguishing between palettes.
Written in python, forgive the poor syntax/lack of efficiency, I've never used it before so I just googled how to do things really quickly
import PIL
from PIL import Image
img = PIL.Image.open("5.bmp")
rgb_im = img.convert('RGB')
diff = []
binval = []
for i in range(0, 16):
diff.append(0)
binval.append(0)
currvalue = 255
for i in range(0,16):
x = i*16
pixel = rgb_im.getpixel((x,x)) # diagonal line of pixels to sample
value = (pixel[0] + pixel[1] + pixel[2]) / 3 #grayscale
diff[i] = currvalue - value # difference from last pixel value
currvalue = value
binval[i] = diff[i]
if binval[i] < 10: # convert to binary value based on threshold
binval[i] = 0
else:
binval[i] = 1
hashvalue = 0
for i in range (0, 16): #generate hash value from binary values
hashvalue *= 2
hashvalue += binval[i]
print hashvalue
a = input()
-
I wish some team would re-design the game in an alternative engine like unity...
This was something I was considering for a while. The problem being that the only legal way to make such an engine is to make it support the files that come with FF8, and we still don't completely understand how some of them work (as you can see from this thread). It's just not feasible at this time. Q-Gears is feasible because we know basically everything about FF7.
Given that we'd need to understand the game files completely before making such an engine (at which point we'd probably already have better texture support), the only real benefit you'd get is higher frame rates, shader support, and extended scripting capabilities.
-
...to make such an engine...
Oh... I was actually referring to Unity or any already made engine. And yes... Q-gears is for VII :|
-
You can't just port a game into another existing engine. It doesn't work that way.
-
Yes.. I know... :/
-
Oh... I was actually referring to Unity or any already made engine. And yes... Q-gears is for VII :|
I see what you're saying, I've played with Unity--it is the most awesome design tool around for sure. I could see someone rebuilding these games from scratch in Unity using code from things like Q-gears and rewriting systems entirely to support existing or modified Square assets, but it would take a dedicated team and a good chunk of time to pull off. Heck, being able to use Unity (porting Q-gears) might rally more developers to its cause, even. For now, I'm going to try to hack my way there--at least to see if its possible.
-
And Square hunts those type of projects as well, like beginning a kickstarter... I mean look what happened to the FFVII series project, they made them look untrustworthy and fools!
-
I've rewritten the hashing algorithm in C++ and have expanded it to 64 bits of comparison on 16 pixels. It compares the 16 pixels against each other in 4 different ways and generates a 64 bit hash value. If any two images differ by less than 10 bits, they are the same image with a different palette. Otherwise, they are different images. Typically, similar images with different palettes differ by only 3-6 out of 64 bits and images that are completely different differ by 20-45 out of 64 bits. When this algorithm is adapted to sample straight from VRAM instead of filling an image buffer first, it should run very fast.
Next stop, generate a dictionary of hash values mapped to filenames and try to see if it is accurate whilst the game is running. This dictionary will be placed in an external file in the game folder and read into memory when the game starts. That may take a bit longer to figure out.
*C++, uses CImg library
#include <iostream>
#include "CImg.h"
using namespace std;
using namespace cimg_library;
uint64_t hashval = 0;
int pixval[16];
void growhash(int columns)
{
int lastpixel = 127;
for (int i = 0; i < 16; i++)
{
if (i < 1 ) { lastpixel = 127; }
else if (i < columns) { lastpixel = pixval[i+(15-columns)]; }
else if (i < 16 ) { lastpixel = pixval[i-columns]; }
hashval *= 2;
(pixval[i] - lastpixel) < 0 ? /*nothing*/: hashval++;
}
}
void gethash(CImg<unsigned char> image)
{
int pixelR, pixelG, pixelB;
for (int i = 0; i < 16; i++)
{
int x = i*16;
pixelR = image(x/2, x, 0);
pixelG = image(x/2, x, 1);
pixelB = image(x/2, x, 2);
pixval[i] = (pixelR + pixelG + pixelB) / 3;
}
growhash(2*2*2*2);
growhash(2*2*2*1);
growhash(2*2*1*1);
growhash(2*1*1*1);
return;
}
int main() {
char filename[] = "1.bmp";
CImg<unsigned char> image(filename), visu(512,512,1,3,0);
CImgDisplay main_disp(image, filename);
gethash(image);
cout << hashval << endl;
while (!main_disp.is_closed())
{
main_disp.wait();
}
return 0;
}
Edit (notes):
VRAM order theory: VRAM loads the necessary parts of a scene by selecting the next necessary 128x256 portion of the field texture (block 1) and loading the next 128x256 block after it (block 2) to fill a 256x256 square of VRAM. It cycles through the necessary palettes for block 1 until it completes all portions of block 1. If there happened to be correct palettes for block 2, it will draw those portions but will likely need more palettes to complete block 2. It cycles and loads block 2 into block 1 slot and loads the next block into block 2 slot. The process repeats with the remaining palettes of block 1 loading and completing block 1, etc. The order of necessary blocks follows the file order in that blocks at the beginning of the file are prioritized first and blocks at the end are prioritized last. Animation blocks are not loaded at all unless the current frame demands a block containing a particular animation, in which case that block will be loaded when its turn in the file sequence comes.
This implies that instead of treating each texture file as a texture, each 128x256 block should be treated as its own texture since different combinations of the block will be loaded into the 256x256 VRAM square and recognized as a complete 256x256 texture by DirectX.
So, when checking filenames for DirectX textures, the first block should be identified and the second block should be identified separately with a different hash and in the dictionary these should be labeled filename_1, filename_2, filename_3...etc for all 128x256 blocks of the field texture file.
Rough total block count: 894 files x 1664/128/2 ~5000 blocks
-
You have lost me when you started to load block2 into block1: (http://s1.directupload.net/images/140521/7y8u6lwl.gif)
-
Maybe this graphic will help. The blocks cycle through the VRAM in the order of the texture file. At each point, the palettes cycle over the image, changing the colors in VRAM until no more colors are needed, then the cycle continues with the next blocks. The palettes needed for the block in the first position are prioritized, that's the point of keeping the next block in the VRAM next state, because it hasn't finished all of its palettes yet, just the ones in common with the block before it.
Keep in mind, this is a theory based on a very small amount of data so far.
(http://s28.postimg.org/3oerjsvp9/texblocks.png)
-
PSX textures are always 256x256 and on a real GPU there would be no reduction in performance if you were to access them on 128 pixel boundaries. From your point of view (I am assuming you're getting this from PIX) you will only see which textures need to be constructed to emulate the GPU commands from the game. There is no "good" reason for the duplication you're seeing other than that its necessary to properly emulate the GPU. This is one of the big issues with replacing textures in FF8, field backgrounds are used as if they were 128x256 but when they're uploaded to a texture the next 128x256 pixels from the VRAM will be uploaded with it because that's just how the GPU works.
-
There is no "good" reason for the duplication you're seeing other than that its necessary to properly emulate the GPU. This is one of the big issues with replacing textures in FF8, field backgrounds are used as if they were 128x256 but when they're uploaded to a texture the next 128x256 pixels from the VRAM will be uploaded with it because that's just how the GPU works.
I understand, so the second block in memory I'm referring to doesn't really do anything, its just there because the commands that load the first block automatically load whatever's next for no good reason. So the palettes cycle on the first block, then the next one loads, etc.
-
If I were to implement modpath/replaceable textures for FF8 the first step would be to rewrite parts of or maybe the entire GPU emulation. Not because it is flawed in any way (although it isn't very efficient) but because then I could start rewriting all the rendering code to use explicit textures instead of just VRAM coordinates.
It would be a massive undertaking. Good luck ::)
-
I'm ready to test my new dictionary of hashes in-game but I need to gain a bit more d3d9 knowledge first. I'm planning on making use of a d3d9 interceptor DLL located here: http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html. I'm trying to find out which files I absolutely need and which ones I can change to test texture replacement in-game. Basically I need to capture the SetTexture calls and replace them with any test texture. Any help/advice would be appreciated to help me go faster :-D
Here's the hash dictionary using the algorithm described above. It adds a numerical suffix to the filenames for each 128x256 block of the texture. There are a total of 6245 blocks in the game.
FF8 Field Hash Dictionary (http://pastebin.com/Dqeq7znv)
Edit (note):
http://www.gamedev.net/topic/178004-idirect3dtexture9-and-manipulation-of-single-pixels/
Update (preliminary):
I have verified that my hash function has been successful at identifying my first test case, bghall1, from the VRAM. At first I was a little worried, because the hash value showed up 3 times, but those were bghall1, bghall1a, bghall1b, which are all identical textures. More to come when I have time!
Update2:
I've got the game successfully running the hash function on every texture that is called by D3D. First, I load my hash map from a file of all the known textures (described above). Then, I run the hash function whenever a SetTexture call is made. I then compare that hash value against the hash values in the hash map to find the closest match (the texture with the least different bits of comparison). I've done a test run from bghall1 (first save point) to the front gates of balamb garden and I've recorded these matches in a file to see if the correct textures were found. Here is that file, with a few annotations thrown in regarding where I was at each point in time: http://pastebin.com/9UpAynEd
Explanation of the results--
line structure: filename_blocknum,mismatchedbits,thistexturehashval,closestmatchedtexturehashval
I've only recorded 1/100 texture calls in the results because the file would be too long to navigate if I didn't. Whenever a background is supposed to be set, the hash function correctly identifies the texture and spits out the file name. However, whenever a texture with mostly black or monotone pixels is called, like in intro screens, and some other screens, including some animations that have a lot of black but a few spots here and there like lights, the hash function fails, usually identifying another texture file that has mostly black or monotone pixels. Additionally, whenever a character sprite texture is called, the results show either NO_MATCH or may sometimes identify the wrong texture as a match.
Keep in mind, these are results of a completely untested hash function that has a ton of room for improvement. The number of pixels sampled, number of comparisons between those pixels, randomness of the pixels, and thresholds for matches and mismatches can be varied. Also, secondary hash functions can be used on textures that are mostly black, for example, and eventually special cases can be worked on separately.
Next step: test texture replacement in D3D
Update 3:
Successfully replaced textures in-game with a simple 256x256 fire texture. This slows the system down tremendously if the texture file is loaded from the disk every time a SetTexture is called. This is because SetTexture is called roughly 150 times per frame to render all the various parts of the scene. Since all of the parts of the scene, except the character and object sprites, are loaded from a single field texture file, this 1664x256 (or 1536x256) texture file should be loaded only on the first texture call of the scene and then referenced in memory for each SetTexture call. This should drastically improve framerate and reduce errors in hashing during the other 149 SetTexture calls in the scene to 13/6245 = 0.2% of the original error rate. This all hinges on the ability to detect the correct texture on the first call during the frame.
Update 4: I have now successfully replaced textures in-game with their appropriate textures, using the hash method. It is not perfect, but it reliable chooses the correct texture > 90% of the time so far. I've expanded the pixel selection from 16 to 64 pixels to make it more reliable. It needs some optimization to avoid lag and some other fixes, but I really need to work through the next huge hurdle: allowing resized textures in-game. This, I fear, will be very difficult, since there are many operations performed on the passed-in textures in order to render them to the frame buffer. These operations include drawing all of the geometry of characters/objects, etc, and I'm so far unsure how to resize only the field textures yet keep everything else unaffected. I'll be thinking on that...
-
Just wanted to update you all on my current progress. I've been able to resize a field file to 4x and get it working in-game. All of the animations and lighting effects seem to work. I've been working rather feverishly on this, more than I should readily admit.
My previous hash algorithm caused a lot of lag every time a texture was loaded since it was searching the entire hash. The new hash technique I'm working on should produce much more reliable hashing that is hundreds of times faster (17 iterations to find the texture vs 6256 iterations per texture). This represents the difference between an algorithm that searches linearly through a large data set and one that searches with a binary search algorithm. It should eliminate that lag altogether.
This method should work on all field backgrounds once I get polished, but also has the ability to work for all other texture-like files in the game including character/monster sprites, battle scenes, cards, menus, etc. In order to get it to work for those other texture types, I need to have directories full of those images extracted from the game files. I can see that myst6re's deling works to view most of those files, but extracting the textures from them is something I haven't tried. I'll cross that bridge when I come to it.
Stay tuned for a release within the next couple of weeks! (this will not include a resize pack, that is the next project)
-
Can this include better world map textures as well? The world map is easily the worst looking part of the game.
-
Covarr read my mind, it was a question I had since you started! The world map is muddy when put next the ps1 version.
So that issue being resolved would be amazing!
-
That's great news! Will this new algorithm work on the 3D models' textures, or just the 2D textures in-game?
-
The way this all works is that whenever the game wants to display ANY texture, it calls a CreateTexture command first and then does the processing it needs to draw the texture onto triangles on the screen. Even the field backgrounds are drawn onto strips of triangles that produce a flat rectangle. So far I know that these commands are called when field backgrounds, character sprites (the character models you speak of), object sprites like save points, character portraits, menus with text, and cards are drawn. By extension, I believe they are also called for the world map, battle scenes and spell effects, and everything else, but I haven't proven those because I haven't recorded PIX data on those scenarios yet. So, if a CreateTexture command is called, then this method can replace that texture.
All that I have to know in order to replace a texture is what it looks like in memory. So far, the field backgrounds look exactly like the mim file contents in memory (with various palettes applied). I've already done the legwork and have written algorithms to display every necessary permutation with all necessary palettes for the field files. Character and object sprite textures look just like they do in myst6re's deling program when you open a field file and go to 3d models section. I don't have any experience with those files yet. So the bottom line here is that if any of you guys want non-field textures to work as well, I'll need to get copies of all of those images so that I can run my hash algorithm on them.
Generating these images is not hard--in fact myst6re has generated most of them by reading the ff8 files in her deling program. Its a matter of writing little programs that read the ff8 files and output them to image formats like PNG. In order to see what they look like in memory, you can download the DirectX SDK (June 2010) and use the PIX tool to record all the directx calls. When viewing a PixRUN file, you can click the texture references on all the SetTexture calls and it will display what the textures look like in memory. My guess is that most of them look exactly like they do in deling, because field files are the most convoluted files to display and tex files, etc, are very simple.
If anyone wants to help speed up the progress on those other types of textures, feel free to write python scripts that output images from game files or send me rar's of images. For now, I'm focusing on field files. This process actually becomes more reliable (from 98%->100%) once I have hash values for EVERY texture in the game. As it is now, it is theoretically possible for my hash algorithm to place a field texture over a character sprite, for instance, if they coincidentally have the same hash value. Rare, but possible.
-
If only Myst3re could put a "mass import" feature in Deling to import a directory of field subfiles, rather than having to do them individually by hand. I'm going to need that anyway for my voiceover project.
Pretty please <3
Wrong thread. I'm guessing omzy's method doesn't actually modify the field backgrounds directly but on runtime with a thread interceptor.
-
Nearing the finish line. Here's a proof of concept release that is very preliminary. It includes the textures starting from the first save point in Balamb Garden all the way to the front gate. Please do read the readme before using it. Let me know if you're unable to run it for any reason--I haven't tested it on any other machines so there very well may be a problem or two I didn't consider regarding portability.
Tonberry PRE-RELEASE ALPHA Readme
by Omzy
Born at http://forums.qhimm.com/index.php?topic=15222.0
Credits to Matthew Fisher at Stanford University for developing the original d3d9Callback interceptor: http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html
*This only works for the Steam FF8 release which uses DirectX
1) Drop the contents of this folder into your FF8 directory that includes your FF8_Launcher.exe
2) Run your launcher
3) Play!
Notes:
*) The textures bundled with this pre-release were improperly resized with photoshop in 30 seconds, do not use fractals (only bilinear), so are meant only as a proof of concept, not as replacers. You will notice there are lines that make the background look like bricks due to the poor quality resize
*) This hasn't been tested on low-end systems, only 1 medium-high end modern system running Windows 7 64-bit, there may be some barely perceptible lag but it isn't that noticeable but if you have a lower-end machine, it may suffer considerably, similarly to running an emulator
*) Anytime a switch/door/trigger occurs in any scene, there is a lag associated with the texture 'pop-in' when it loads. This may be addressed in further releases
*) The hashing algorithm is unfinished and will exclude some ~150 of the ~13000 texture pages used in the game. This will be noticed as parts of the background being high-res and other parts being low-res
*) Only field backgrounds are replaced at this point, but this will be expanded in the future to other texture types
*) Included is a WrapperParameters.txt which has a BaseDirectory that should equal the location of your FF8 directory. The default is "C:\Program Files (x86)\Final Fantasy VIII"
Download : Tonberry Pre-Release Alpha (http://goo.gl/rsjBM6)
Edit: Also, is there a project named Tonberry already? I looked but didn't find anything obvious, curious since its such an iconic ff monster.
***Edit2: I had a friend test my first upload and it was missing a few things so I've fixed that and re-uploaded for those of you who downloaded earlier. Don't forget to change your WrapperParameters.txt if you need to!
-
Impressive, as usual Omzy! :o
Now I just have to buy myself a copy of FF8. ;)
UPDATE: Just bought it on Steam
-
Any screens yet?
-
Any screens yet?
Since it takes a lot of time and effort to write Photoshop scripts to do what FacePalmer did, I don't have any fractalized backgrounds made up yet, if that's what you're wondering. I'm about to release my Tonberry Beta, though, which is the DLL that supports external textures and should pave the way for a beautified game experience. Check the Tools section in a bit.
-
Excellent! Thank you Omzy!!! Looking forward for any in game screens as well!!!