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.
No, that will be in the next release, along with fixes for the battle camera, snowboard and submarine minigames and (hopefully) the directinput bug.
Oh and a very minor fix for non-paletted textures (I have found _one_ so far, the ropeway station background is in BGRA 5:5:5:1 format and wasn't working in 0.1a)

The screensize-feature is not terribly useful yet though, since it messes up field, but I have something in mind that will both fix that issue and in the long run make it much easier to replace field backgrounds :-)
 
I've just had an idea reading this topic, theres a program that can replace textures in realtime from the application called texmod. It might be possible to replace the background textures with this new driver...
 
If you got the idea reading the topic, you might want to read the thread... It's been discussed already :P
 
Working on movies right now though, I'm replacing the entire movie player with my own routines, using ffmpeg to decode them (so no more shitty propietary truemotion codec)

After that I'll probably make a 0.2b release, and THEN work on my new idea for field :-)
(that release will be fully playable, the only known problems right now are some missing effects and field glitches with custom resolutions)
 
Working on movies right now though, I'm replacing the entire movie player with my own routines, using ffmpeg to decode them (so no more sh*tty propietary truemotion codec)
You think this would make it possible to run FF7 in 32-bit without glitches? Because that would be awesome.

Good luck on this project, it looks very promising.
 
Err, this driver was never running in anything but 32-bit :-P

And I already have movies playing (no sync, no sound, just video) so that would be a definite yes :wink:
 
Err, this driver was never running in anything but 32-bit :-P

And I already have movies playing (no sync, no sound, just video) so that would be a definite yes :wink:
Hmmm interesting.  As for 32/64bit a warning to keep compatibility with older systems (IE not breaking them) I suggest you look at MS method of checking if a system is 32/64bit. Someone else forum didn't bother to do that on an open source project and it crashes on win2k as a consequence.  However the program is 32bit ... hmmm how would it behave correctly in a 64bit?

Erstwhile are you putting your DLL functions into the wiki for FF7PC? I think other people might find it 'fun' to do ;)

The functions themselves and there calling conventions might be handy for the Q-gears project namely it can give an idea of the API they used originally.

Cyb
 
I was talking about color depth, not machine word size :-P

And I assume Terid__K was too, since one of the known issues with running FF7 in 32-bit color depth is messed up movies.

64-bit systems will just have to pretend to be 32-bit systems, just like they do for FF7 itself :-)

The DLL exports only one pretty trivial function, the constructor for the graphics driver "object".

It's enough work to create this thing in the first place but I do intend to document my findings on .tex and .p file formats and if someone wants to have a look at the source code, thats not a problem.

I doubt it would be of any use to the Q-Gears team though, if anything, they should be trying to move away from the old outdated concepts used in the original engine. (And this driver just handles graphics after all, its 90% generic OpenGL code, 10% FF7 specifics)
 
The only thing thats holding off the 0.2b release right now is a bug in the ffmpeg truemotion2 codec that leads to oversaturated and sometimes just plain wrong colors.

It's still missing some battle effects, no idea why, but that is also the only big thing that sets it apart from the original drivers, everything else should be working now :-)
 
So is this running in 32 bit color to make the FMVs look slightly less terrible?  I can't believe this got so far so fast.  Fantastic job, I hope to see this followed up after the next release.
 
Nice job, Aali.

I just wonder that noone discovered the possibility of injecting a custom graphics driver into the engine before, especially since there have been several patches developed for the internal engine.

And we thought that we have already reached the limits of the original engine years ago...  :-P

 - Alhexx
 
This driver don't work with the french version of Final Fantasy VII. He said : "It's not the 1.2 version". Yet I have patched the game, but with the french 1.2 patch. :|
 
If you modify the backgrounds, you have to do it properly (improve the picture as a whole, then re-cut it)

Otherwise you'll get all sorts of artifacts as the different layers bleed over into each other

Even linear filtering for textures (standard feature in opengl) has to be disabled for field to look good
It's the way Square constructed the scenes.  Basically they have some sort of software Z buffering technique and assign each layer a depth. This determines the ordering of what is drawn, 3d objects inclusive. The 2d objects are not drawn in 3d but 2d but are depth sorted as stated.  So things go something like "background" which I suppose has infinite depth in this case. Then sorted 3d objects (character people etc) with sprite objects and lastly foreground objects (IE infinitely close to the camera). 

Transparent objects (alpha blend objects) also exist but they are done in the foreground depth (overlaying things). You see this in area's like the wall market.
That being said, if you want hirez tile sets they must be an integer multiple of the original tileset just like the screen needs to be as well.
I'm not sure if it's possible to use 3d objects strected and depths to give perfect alignment at various resolutions.
(render the background to a texture and paste the texture on a surface which would have the effect of something akin to wolfienstien).

The only way to make improved backgrounds is as said before they must be cut from the same template coordinates, or integer multiple, as used before.


Cyb
Going back to shaders and filters, what causes the glitches when you apply it to the whole scene ?  The fact that some layers show artifacts when rendered ?

If so, wouldn't it be possible to apply a filter/shader individually to each layer and skip the ones that show artifacts (the alpha layer comes to mind) ?  Pete's GPU drivers seem to use a similar principle for filtering and it works well for ff7 on epsxe.  I have to admit I don't recall if it improves the backgrounds at all though.

If it doesn't show, I don't know much about these things and I'm tossing (probably ridiculous!) ideas out there based on what little I do know but realistically, I think this is the closest somebody has ever been to improving the backgrounds as I doubt anybody is ever going to go through the 758 or so field files of the game to re-render them at a higher resolution!

Regardless, keep up the good work.
 
This driver don't work with the french version of Final Fantasy VII. He said : "It's not the 1.2 version". Yet I have patched the game, but with the french 1.2 patch. :|
Version detection is a bit of a hack, yes :-)
I might just remove it if its going to cause trouble with other languages.. (but that will make it crash instead of displaying the message if ff7.exe really is incompatible)
Could you please upload your ff7.exe somewhere so I can compare it to the US english version?
 
Going back to shaders and filters, what causes the glitches when you apply it to the whole scene ?  The fact that some layers show artifacts when rendered ?

If so, wouldn't it be possible to apply a filter/shader individually to each layer and skip the ones that show artifacts (the alpha layer comes to mind) ?  Pete's GPU drivers seem to use a similar principle for filtering and it works well for ff7 on epsxe.  I have to admit I don't recall if it improves the backgrounds at all though.

If it doesn't show, I don't know much about these things and I'm tossing (probably ridiculous!) ideas out there based on what little I do know but realistically, I think this is the closest somebody has ever been to improving the backgrounds as I doubt anybody is ever going to go through the 758 or so field files of the game to re-render them at a higher resolution!

Regardless, keep up the good work.
Its very possible to apply filters *after* the scene has been fully rendered (since it is essentially just a 2D image by then). But then you'll be filtering everything, not just the low-res field tiles.
 
Ah, that .exe IS incompatible with this driver, I should change the error message to include this possibility..

I can add support for other languages*, but its going to be alot more work than just disabling the version check. (And wont be in 0.2b)

* As long as you provide the .exe
 
Going back to shaders and filters, what causes the glitches when you apply it to the whole scene ?  The fact that some layers show artifacts when rendered ?

If so, wouldn't it be possible to apply a filter/shader individually to each layer and skip the ones that show artifacts (the alpha layer comes to mind) ?  Pete's GPU drivers seem to use a similar principle for filtering and it works well for ff7 on epsxe.  I have to admit I don't recall if it improves the backgrounds at all though.

If it doesn't show, I don't know much about these things and I'm tossing (probably ridiculous!) ideas out there based on what little I do know but realistically, I think this is the closest somebody has ever been to improving the backgrounds as I doubt anybody is ever going to go through the 758 or so field files of the game to re-render them at a higher resolution!

Regardless, keep up the good work.
Its very possible to apply filters *after* the scene has been fully rendered (since it is essentially just a 2D image by then). But then you'll be filtering everything, not just the low-res field tiles.
Meaning only the 2d would be filtered ?  Or the whole scene ?  Would that help improve the backgrounds (and the whole scene while we're at it) ?
 
The whole scene. It would be far from ideal (since by that time, you've lost any information associated with the objects on screen) and the best you could do without completely killing framerate would not be much better than what we have now. The point of filtering field backgrounds before they're drawn is that you only have to do it once, so you can apply any kind of expensive filtering and even make manual edits to really make it look better.
 
Status
Not open for further replies.
Back
Top