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.
Today is quite an interesting day for sure!  :lol:
Extremely promising work Aali, keep going!  :-D
 
This is how we can inject hi-resolution backgrounds into the field system. For every field  square drawn, we substitute it with a higher-resolution square as opposed to scaling the old graphic... It will look awesome :)

Now all we need are higher resolution backgrounds :)
 
This is how we can inject hi-resolution backgrounds into the field system. For every field  square drawn, we substitute it with a higher-resolution square as opposed to scaling the old graphic... It will look awesome :)

Now all we need are higher resolution backgrounds :)
Well there are ways of doing that.  Hmmm not sure which is best though.
Basically you need an 'Image' that fits the tile map and convert the tile map layers back to ... tiles. 
One will need multiple layers for sprites (animated things), background, and transparent things (things you walk behind).
I guess that would be toolmaking? The walk map in the background might make it easier to do.

In any case an interesting option :)

Cyb
 
Wow, this project looks VERY interesting O.o
I'll be keeping an eye on this

Now all we need are higher resolution backgrounds :)
I ripped a background of sorts from the Tech demo opening thing. would that be classed as a higher res Background?
 
Last edited:
Now I've hit a bit of a snag, as you can see in the screenshots, some textures look garbled or have wrong colors, this is because I don't know what to do with .tex files that have multiple palettes, how are you supposed to know which palette to use? (Fonts are 4bpp and have a 16*16 palette, for example)
 
Nevermind, the info was there all along, I was just looking in the wrong place, you don't know which palette to use until its time to render the texture :-)

I've also noticed that FF7 seems to work well even if you resize the viewport, which means you can use the hi-res patch at any resolution :-) (Higher resolutions wont improve quality, of course, but this makes it possible to run hi-res on widescreen 1280x800 displays etc)
 
how does that effect the backgrounds that expect a 4x3 aspect ratio or the battle menus that span the bottom of the screen?
 
I believe you can achieve pretty much any effect you want by tweaking the viewport and projection matrix :-)

Simply stretching everything over the full screen area is possible, but it should also be possible to add black borders to preserve aspect ratio

Menus are not really any different from the other graphics, infact, they're drawn by the same routine that does the world map

No more screenshots for now, reorganizing the code to more closely mirror the d3d driver instead of the (broken) opengl driver, but I think I know how to get field backgrounds and menus working properly now. Battle is a completely different beast, have to decipher the relatively complex 3d object (PCs, NPCs, field entities, high-res models on the world map etc) routine to make that work.
 
I would partially expect them to do object frustum culling, at least for the battle scenes where there is a dynamic camera floating around, before the driver-level. Mainly to avoid having to do skeletal transforms for off-screen models. But perhaps since those scenes are rather constant-cost, they just didn't care. I don't think you could really manage proper wide-aspect on most of the static background scenes without having to blackbar the sides, though. Or risk having the background image stretched to a bad aspect ratio.
 
Oh I'm not saying the in-game viewport (visible area) should be made bigger, the "internal" resolution would still be 1280x960 (with high-res patch) but the final output can be scaled and/or stretched.

That said, you *can* make the visible area bigger aswell, but that would lead to more glitches as MrAdults pointed out. (The game was never meant to be widescreen, after all)
 
Well done Aail, I'm highly impressed

Maybe you should also add the code to the Q-Gears SVN as well, because I would imagine this would help the project along a hell of a lot...not that it's really doing much... if anything at all
 
Finally made some progress with the palettes (still not quite right though)

ff7%202009-03-31%2013-15-21-90.png


ff7%202009-03-31%2013-15-33-40.png


I also implemented a very simple fragment shader that inverts colors, as a "proof of concept" :roll:

ff7%202009-03-31%2013-16-31-00.png


ff7%202009-03-31%2013-16-39-01.png
 
Last edited:
4 main issues to take care of before I can make a proper, playable release :-)

1. even though I now have the palettes all sorted out, field files still look pretty crappy, things that should be transparent aren't and vice versa

2. battle models and other 3d objects

3. blend modes; this one is pretty tricky, getting the exact same (or atleast close enough) blending effects as dx5 _in the right places_ will require some serious digging into both FF7 and DX5 internals

4. in-game movies simply hang the game for now, for the first release I'll probably just skip them
 
Seems like we can cross #1 off that list :-D

ff7%202009-03-31%2018-17-12-73.png
 
Last edited:
Wow this is amazing work, great job Aali, Keep it up! I'm pulling for a full working release soon  :-D
 
Awesome!  :lol:
What's wrong with battle models? Is it something weird with the transforms?
(Correct) Blending will be a nightmare unfortunatly  :-(
 
The "problem" with battle models is simply that I haven't written that routine yet :-)
(As you can see, field models are missing, battles show menus and text, the rest is just black)

A lot of stuff happens in that routine that I don't fully understand yet but now that I have (pretty much) everything else sorted out, it should be easier.

Worst case scenario I'll just "borrow" most of it from the d3d driver :-) (I do that with some things already, for example, every transform goes through the original code to ensure its correct)
 
I have to say I feel this is the most exciting new project to come out lately.

This project has the potential to dramatically improve the game if it pans out like planned.

Quick question though.  Wouldn't a fairly easy way to improve the background be to send them through a HQ4x shader à la pete's ogl2 fragment programs or something ?
 
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
 
Status
Not open for further replies.
Back
Top