Custom graphics driver for FF7/FF8 [v.1-.7.6]

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
Hey Aali, I was mesing around with TEX files and found out the original 1.02 version of FF7 was actually able to load textures of 16 and 24 bpp. It was a bit absurd though, becase they were rendered as greysacle versions of the image. I've tested the same textures with the new graphics driver and it simply skips the textures (they are treated as if they were fully transparent). I was wondering, would It be possible to add support for these texture formats?
 
I'm not sure where you went wrong there, I have been able to use 32-bit textures without problems with both the D3D driver and this one.

Of course, with the D3D driver it's all converted to 16-bit anyways but it still loads any texture just fine.

If you upload the .tex file somewhere I could probably point out the error of your ways :-P
 
Aali: Speaking of textures. Once you told me you hex edited a tex file to use 32 bit color. Could you let me have that texture please? You said it worked in game, which is awesome. If you could make it 512x512 or as large as ffvii will accept would be awesome. Then we can use omega to steal the header info and texture limits should be a thing of the past.
 
Last edited:
Actually, it was 24-bit, I copied the data straight from a .bmp file saved with paint.

This page; http://wiki.qhimm.com/FF7/TEX_format will tell you all you need to know about the header. I wish I had an example to upload, but I don't. Maybe I'll write some quick hack to do one for me.
 
You are right Aali, defintly I screwed somewhere, because I can't even load my custom 8-bit TEX files. Here is the header of one of my 24-bit files:
Code: [Select]
Code: 
        .Version = 1        .unk1 = 0        .ColorKeyFlag = 1        .unk2 = 1        .unk3 = 5        .MinimumBitsPerColor = 24        .MaximumBitsPerColor = 8        .MinimumAlphaBits = 4        .MaximumAlphaBits = 8        .MinimumBitsPerPixel = 8        .MaximumBitsPerPixel = 32        .unk4 = 0        .NumPalletes = 1        .NumColorsPerPallete = 2 ^24        .BitDepth = 24        .width = 512        .height = 512        .BytesPerRow = (24*512) / 8        .unk5 = 0        .PalleteFlag = 0        .BitsPerIndex = 0        .IndexedTo8bitsFlag = 0        .PalleteSize = 2^24        .NumColorsPerPallete2 = 2^24        .RuntimeData = 19752016        .BitsPerPixel = 8        .BytesPerPixel = 3        .NumRedBits = 8        .NumGreenBits = 8        .NumBlueBits = 8        .NumAlphaBits = 0        .Red8 = 8        .Green8 = 8        .Blue8 = 8        .Alpha8 = 8        .RedBitMask = -1        .GreenBitMask = -1        .BlueBitMask = -1        .AlphaBitMask = -1        .RedMax = 2 ^ 8 - 1        .GreenMax = 2 ^ 8 - 1        .BlueMax = 2 ^ 8 - 1        .AlphaMax = 2 ^ 8- 1        .ColorKeyArrayFlag = 0        .RuntimeData2 = 0        .ReferenceAlpha = 255        .unk6 = 4        .unk7 = 1        .RuntimeDataPalleteIndex = 0        .RuntimeData3 = 34546076        .RuntimeData4 = 0        .unk8 = 0        .unk9 = 480        .unk10 = 320        .unk11 = 512
And in case the porblem is outside the header, here is the file:
http://www.megaupload.com/?d=GUERPTXV
 
There seems to be an issue with the Fort Condor mini game in wine: When two enemies are standing close to each other and I want to attack them, the mini game hangs at the selection screen (where I should choose which enemy to attack). The animations of the creatures keep going, but there is nothing I can do but kill the game process...
APP.LOG hast multiple lines of
ERROR: COULD NOT CHANGE TO DIRECTORY C:\Program Files\Square Soft, Inc.\Final Fantasy VII\Data\minigame/data\
at the end...
 
lukas227: known problem in wine, possibly related to the quit bug

Borde: A few things;
The minimum/maximum bits per X are all used to determine which texture format to use, not just the minimum bits per color. However this is not the source of the problem since the D3D driver will fallback to a (more or less) compatible texture format. Also, the color fields in this section specify the number of bits per color component, so a value of 24 makes no sense.

A number of palette related fields are set, I don't think this will cause any trouble as long as the palette flag is 0, but to avoid confusion its probably best to set them all to 0 in this case.

Bitsperpixel is set to 8, it should clearly be 24.

The bitmasks are all -1 and the shifts aren't even in that table :P This is the source of the problem, these along with the "max" fields are the most important parts of any non-paletted image. The final component value will be calculated as such; (((pixel & mask) >> shift) * 255) / max, assuming a truecolor target. (where & is bitwise AND, >> is right shift)

So, assuming a standard BGR encoded windows bitmap the pixel format should be as follows:
red component;
mask: 0xFF0000, shift: 16, max: 255
green component;
mask: 0xFF00, shift: 8, max: 255
blue component;
mask: 0xFF, shift: 0, max: 255
alpha;
all zero, since we have no alpha
 
DOH! Thanks Aali, I completly missed the point of shift and mask fields. I can't get my textures working yet though. I guess I'll have to work on them a bit more...
EDIT: Ok, got it working finally. Looks like 32 bits textures are also supported by the new graphics driver (the original one just shows a grey texture) but the alpha channel seems to be ignored. I guess the blending would be troublesome anyway.
 
Last edited:
WOW... That is very exciting news. If 32 bit textures are supported and can be displayed in game then both you guys have done it again. All we will need is a simple progarm to create custom textures that will run in game.

Aali : I'm very impressed with the progress you've made with Palmer. It is just a short time now 'til we can make a background mod.
 
You can do that now.. or well, I can :-P

Import is working fine, now I'm struggling with (yet another) bug in LGP Tools.

This one is a little more difficult (not to mention ugly) to work around though, since it's not an artifact of the sh*tty implementation, it's a misunderstanding of the LGP format.

Borde: The alpha channel is not "ignored", FF7 just doesn't do any blending unless you tell it to (and even then, not all blend modes use alpha). Average and mode3 both use alpha, however the texture will be modulated with the vertex color (which has reduced alpha; 50% for average, 25% for mode3). FF7 was never meant to do any real alpha blending.
 
Last edited:
A funny little thing has happened - I enabled the fps counter in FF7 - now when I watch TV Episodes in MPC, the fps appears in the upper right corner!

Not that it's much of a bug report... it's quite handy actually. Just thought I'd share! (I'm not complaining, I could turn it off if I want to  :wink:)
 
Import is working fine, now I'm struggling with (yet another) bug in LGP Tools.

This one is a little more difficult (not to mention ugly) to work around though, since it's not an artifact of the sh*tty implementation, it's a misunderstanding of the LGP format.
Click to expand...
As someone who helped research that format with the meager resources that we had available, I would suggest you ask for your money back :P
 
As someone who helped research that format with the meager resources that we had available, I would suggest you ask for your money back :P
Click to expand...
Ahaha, no, LGP Tools is an old application and its bound to have issues, I'm not trying to belittle your work. :-)
I shall write myself a little tool to make LGP archives instead.

For future reference, the problem is that "_" (underscore) and "-" (minus) should be treated as k and l respectively when constructing the lookup table.

Try rebuilding flevel.lgp for example, FF7 will be unable to find c_eye2.tex along with all the other files that have _ as the second character. This is because FF7 is actually looking at the lookup table for ck*. If you rename the file to ckeye2.tex and repack the LGP, it will find the right entry in the lookup table and then dismiss it because the actual filename doesn't match.

The workaround in LGP Tools is to use advanced editing only and never let LGP Tools rebuild the lookup table. Inefficient and ugly but workable.
 
Ahh, that's why rebuilds didn't work too hot... You may want to update the wiki with that info.
 
Does this explain the issues with face textures not showing up with the PRP and other textures not showing up for weapons? Or is that completely unrelated?
 
As far as I recall there were no files with _ or - on their names on the PRP, so It shouldn't be a problem.
 
I meant with the newer things people are trying(tried) to do with it

EDIT: got offtpoic, this thread is for Aali's driver. Disregard :-D
 
Last edited:
If you do run into this problem, you'll get a nice obnoxius error message in APP.LOG; "OFFSET ERROR <filename>".
 
I haven't But i was curious cause SquallFF8 and Grimmy had issues with getting them to work, unrelated to LPGTools :-D
 
Is there anyway to lower the effect with the post processing, it's a bit too bright?
 
Status
Not open for further replies.
Back
Top