Resolution in Q-gears

[halkun]

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?

[Micky]

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

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.

[sfx1999]

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.

[Micky]

I don't think you can use 2xSaI in OpenGL. Unless you want to use fragment shaders, that is.

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.

[Cyberman]

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.

Cyb

[Qhimm]

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.

[Micky]

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.

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.

[sfx1999]

Aren't buffers kind of slow, though?

[halkun]

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.

[Covarr]

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...)?

[sfx1999]

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.

[Covarr]

Okay, I've compared Scale2x and hq2x, and got these results.

Nearest Neighbor (No algorithm)


Scale2x


hq2x


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.

[halkun]

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.)

[Covarr]

Lol, I didn't have a screenshot without cloud in it! (I'll have hq4x and 2xSai by tomorrow. Maybe SuperEagle, also.)

[sfx1999]

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?

[NobodyImportant]

When using a high resoultion, what about the .avi movies?

[bluesummers182]

they all look blurry except for the 3rd one.

[VincentVal]

I like them and I hope such a feature will be included...

(...Happy 1000 posts Halkun)

[Qhimm]

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:


Genuine Fractals:

[Alhexx]

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...

 - Alhexx

[BesideTheVoid]

ack!  Remember, buffers are FASTER than video mem surfaces when you're doing hard-coded per-pixel ops.

And just remember, you can SAI yourself silly but maybe you should have an optional grain filter.  This will "add" detail that simply doesn't exist in a stretched image.  I've especially tried grain (randomly affect LIGHTNESS only--that is, affect r,g,and b by the random value randomized each PIXEL) on stretched images that are even blurry and not using SAI (for photo editing work), and it makes stuff look good stretched.  For speed, you could apply any stretching or filters ONCE on LOADING the image if you're using a buffer anyway.  This will obviously speed up performance immensely.  However, it would look MORE REALISTIC if noise was applied every FRAME (slow, maybe have that as an option though).  Now don't distract yourself from coding the core just yet , but Another optional filter to add to the engine sometime should be an NTSC color filter (to make it look like it was really supposed to look on the TV, for which the textures and backgrounds were all designed).  Sorry for giving you too many ideas lol.
-ProtoArmor
http://www.expertmultimedia.com/protoarmor (go there and click contact for the contact form)

[Sad Jari]

And just remember, you can SAI yourself silly but maybe you should have an optional grain filter.

Very much agreed on this. I've never seen grain used in emulators, but I've used it in photoshop to hide either too severe jpeg-compression, or the artifacts from too large resizes. And of course last but not least; I use very small amounts of grain on ffdshow to hide compression artifacts on badly mastered DVDs. All that it does really well, I think that it would be worth a shot to try it.

It can't and won't add any real detail (one that would carry actual information with it), but it is much more pleasing to the eye than the alternative.

Not sure, but I suppose that ffdshow source might have a rather fast grain-filter in it, after all it is meant to be run on live video, up to very high resolutions.

[ChaosControl]

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

R4G4B4A4, It's faster

[sfx1999]

So what do they look like with HQ3X and HQ4X?

Anyway, for the ABGR, I made a table for the B, G, and R part:

http://forums.qhimm.com/index.php?topic=5695.msg73564#msg73564

What if someone made a preprocessor or something to do this before we run the program?

[Cyberman]

So what do they look like with HQ3X and HQ4X?

My guess is not much different than HQ2x?

Anyway, for the ABGR, I made a table for the B, G, and R part:
http://forums.qhimm.com/index.php?topic=5695.msg73564#msg73564

Yes I'm  sure most people are aware of that, however 'the official' accepted translation really implied that we need to spend time to be certain when a color is converted it's to the proper R8G8B8A8 numbers.  I know I have 2 conversion versions, they both work similiarly to what your table version does.  The primary difference is they examine the alpha channel. Fortunately FF7 uses it as a transparency bit and super black. (It's a strange artifact of the PS1) these do require consideration for alpha channel changing 0 00 00 00 is a clear color whereas 1 00 00 00 is black.  However  0 00 3F 00 is green (non transparent).  Fortunately 0 is the only exception so that makes things a bit easier.  The proper translation is needed for all color handling in FF7 except the menu background colors.  They used to guruad rectangle primitive for that and it accepts 4 B8G8R8 colors as part of the GPU opcode.

What if someone made a preprocessor or something to do this before we run the program?

No that would be altering the original content, which is of course something that the project wishes to avoid.  Even if just before the program runs it's still creating content from copyrighted content. Then there is the fact you have several hundred battle scenes, field scenes, and battle models to go through.  Decompress process fold spindle and otherwise mutilate. That would from a few minutes to .. quite a few minutes  (LOL).

choascontrol:
Ummm that would be true on older hardware now it makes no difference.  With 32 bit machines and 64 bit data path and a GPU that uses R8G8B8A8 internally it might actually be a little slower.

Cyb - silly mood