Resolution in Q-gears

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
H

halkun

Guest
Well, now that we have textures loading, we have an issue.

FF7 was designed for very dynamic resolution around 400x300 (plus or minus, it's a little goofy)

We should start looking into scalers to make the textures look decent in....say 1280x1024.

something like 2xSaI, but I've seen something better than that (posted on this board too)

Not biliniar filtering. That looks like blurry garbage when it's used.

Comments?
 
Not biliniar filtering. That looks like blurry garbage when it's used.
Click to expand...
Well, bilinear filtering is used by OpenGL if you're not using point sampling, so you can't avoid that. :)
I'd say worry about that when the game is running, because changing textures to a higher resolution is trivial. They're always parametised from 0-1 (except for rectangular textures which are a special case anyway), so once you decide you want a higher resolution texture you can just drop it in and it works.
 
I don't think you can use 2xSaI in OpenGL. Unless you want to use fragment shaders, that is.

Why not just use anti-aliasing on the backrounds and draw the people the same? If you are using floating point coordinates, that would be trivial. As for text, a font system like GLtext would work nicely.

Also, you could turn of filtering all together when drawing the backround.
 
I don't think you can use 2xSaI in OpenGL. Unless you want to use fragment shaders, that is.
Click to expand...
You would do that on the buffer that you use to create the texture. So instead of creating a 256x256 texture you you'd run the 2xSal on it and create a 512x512 texture.
 
This is the first challenge (of many).
It is also the identical problem there is with the background data.

First we need an Officially accepted translation process from ABGR 16 format to R8G8B8A8 or whatever texture format we plan on using.

There are some favorite methods for scaling textures.
Nearest neighbor (fill a pixel nearest to the scale factor).
bilinear filtering
trilinear filtering
cubic spline (use a polynomial exquation that is acurate to the slope in order to interpolate the color changes from rescaling).
etc. etc.

However transparencies are the problem here.
I think just filtering textures is a 'bad thing' the process probably should be done in 2 steps.
1) filter texture colors (cubic spline is pretty good for this).
2) Nearest neighbor the transparency and and black as well. (This is a must because transparent zones either are or aren't and black is black period in FF7).
3) set the alpha and black regions in data from step 1 using data from step 2

I believe it really needs to be done as a 2 stage process to prevent artifacts in the alpha channel.  I don't believe we can faithfully make it look like the original if we allow the alpha (transparency) channel to be filtered like the color channels. As then we get into semitransparent regions and we may end up with <explitive> green and blue lightened halos along with dark edges with fonts and background information.

Cubic spline will give fairly close color and lumanance transitions to the original even though it might be scaled up by odd ball number.

As a suggestion we should determine the exact resolution the script information, window, and menu data was designed for and plan scaling based off of that instead of speculating proper scale factors.  It might be possible to dynamically tweak and adjust this, however that shouldn't be necessary if the proper research has been done.  I guess the tweaking could be used to find what looks good and remove it later, heh. :D

Cyb
 
You're not going to get any decent results just by filtering the background textures, regardless of how you treat the alpha channel (although alpha does present a few additional snags). The reason would be the tiled nature of the background layers, and that the tile that is next to another tile visually is not necessarily stored next to that tile in the source texture, and the filtering is done in the texture lookup, not on-screen. This is further complicated by the fact that the neighboring tile in the source texture is not necessarily using the same palette as the current tile, which is why you sometimes get that familiar grid pattern when running the current FF7/FF8 with anti-aliasing turned on... part of the neighboring texture data is used in the filtering, but those pixels actually belong somewhere else on the screen and/or uses a different palette, resulting in strange, oddly colored lines around the tile grid.

You could improve this a bit with fragment shaders (implementing 2xSAI or whatever) by restricting filtering to not include image data on the other side of tile boundaries, but this both raises hardware requirements and is not perfect, as you would get a "grid" pattern of less-filtered image data along the tile boundaries. It's probably won't look that prominent though, so I'd actually say this is a decent compromise solution. And fragment shaders will also help you easily get around paletted textures, since that feature is present and enabled in far from all graphics cards today.

To truly get nice looking backgrounds, you'd have to pre-paint the background onto a render texture, somehow preserving layer information (explicitly writing to the depth buffer perhaps?), and then filter that texture when drawing it to the screen. Edges where the characters are partially obscured by the background will still look a bit funny (very sharp edges on a fuzzy background), then again it looks like that anyway.
 
To truly get nice looking backgrounds, you'd have to pre-paint the background onto a render texture, somehow preserving layer information (explicitly writing to the depth buffer perhaps?), and then filter that texture when drawing it to the screen. Edges where the characters are partially obscured by the background will still look a bit funny (very sharp edges on a fuzzy background), then again it looks like that anyway.
Click to expand...
As I mentioned in the other thread, you could compose each individual layer into its own buffer. Then you don't need any fancy shader tricks or extensions. To avoid tinting the pixel next to a pixel filled with a debug colour you could use a dilution filter (basically filling each pixel with the average of its neighbours) or get the colour from the layer that covers it. This needs to be done only once when a field script is loaded. But then I thought that you were against "improvements", at least until something is working?
If I get time this weekend I'll try to add this code to my field viewer if you want to, then you can rip the algorithm for Q-Gears. But I'm sure that other people can come up with the same solution.
I originally thought that Halkun speaks about the textures used for 3D scenes, where you don't have to worry about this that much.
 
I'm looking and scalers and seeing what's cool.

I like the buffer idea. This will require the background layers to be "pre-published" and then scaled. I'll all for dumping the current way FF7 renders the background. It's cool for low-resolution embedded devices, but bearly tolerable on even compter displays back when the PC port was released.

Here's what I've come up with.

Scale2x

2xSaI

The next three ROCK. I recommend these for testing

hq2x
hq3x
hq4x

Let's do some tests on these on a few field backgrounds.
 
Last edited:
How well will these work with sizes that AREN'T multiples of 640*480? Specifically, 800*600 and 1024*768? Perhaps even widescreen (Impractical and stupid as it may be...)?
 
You have the links wrong for HQ3X and 4X.

I am concerned how those will look on FF7 backrounds. Those are all cartoons.

Also, leave room so someone can make a fragment shader for it, if possible.
 
Okay, I've compared Scale2x and hq2x, and got these results.

Nearest Neighbor (No algorithm)
1255259bv.jpg


Scale2x
scale2x7ak.png


hq2x
hq2x8jj.png


I'll add 2xSai later if I get the chance. It's the only one I didn't already have, so it's a tad less convenient.
 
I would like to see what hq4x would look like.

(This is just for the background mind you, cloud there and the save point will be rendered and scaled in 3d.)
 
Lol, I didn't have a screenshot without cloud in it! (I'll have hq4x and 2xSai by tomorrow. Maybe SuperEagle, also.)
 
Wouldn't it be better to NOT filter the player models, but to them AFTER the backrounds? That and to keep the text after it, too?

Also, no one seems to answer me about this, but wouldn't GLText be useful for getting higher resolution fonts?

On a side note, borders could probably be reimplemented as higher resolution. Just get someone to make a higher res version of them, maybe even make them look better?
 
I like them and I hope such a feature will be included...

(...Happy 1000 posts Halkun)
 
Shame that hq4x and similar filters are all mainly designed for "cartoony" images, and not photographic imagery. There are of course filters that extract features from photographs and reproduce them at higher resolutions as well, though they are a tad too processor-intensive (we'd need to reprocess the background as soon as it changed, no?), and also most likely patent-protected. ;) For reference though:

hq2x:
hq2x8jj.png


Genuine Fractals:
ff7_frac_scaling.jpg
 
Last edited:
As usual, fractal interpolation rocks. But I suppose that a player would need a 15 GHz Quad-Core CPU to use fractal interpolation for in-game realtime rendering... :-P

 - Alhexx
 
Status
Not open for further replies.
Back
Top