Good Quality Background in future?

[mcpaper]

Like this?

[Covarr]

We'd love to implement higher quality backgrounds in the future. The only problem is, we can't. This may become a possibility with Q-Gears in the future, but chances of ever doing it successfully with the original exe or even a patched exe are very slim.

[Cupcake]

i've always wondered why that was

[Borde]

Well, we already know how to replace the backgrounds. It's not that hard. But what we don't know is how to display higher resolution backgrounds. It wouldn't be that hard if the EXE hadn't a fixed limit to the number of rendered tiles. The animated backgrounds and the trnsparent layers also pose a problem.

[mcpaper]

Well good luck in the future then. I really want to see this done - will be one of the best tweaks out there.

[Cupcake]

ahh, well is there any app that allows us to import the backgrounds at this point, or do we have to do it by hand, because that is the only thing that is truely stopping me from modding FF VII  (well that and i can't find discs 1 and 3)

[Cyberman]

cactusjack901 what is really going to stop you is the data.

AS Borde said it's the limits the FF7 original engine itself imposes that creates the dilema.  Bigger backgrounds are sort of possible.  How to make new ones isn't the problem, it's making them bigger that is the problem.  Simply put you can't make bigger backgrounds, because of the number of tiles you are limited too.
Now as for how Q-gears might enhance it... speculate away, as Q-gears is just starting to have the background decoding implemented.

Enhancement will NOT happen in Q-gears until it runs the basic data set completely.  Then and only then will any enhancement be considered.  Unless you want to add it yourself for yourself.  In any case those working on it will consider what is a legal enhancement and what is not, as well as what is a useful enhancement and what is not.

As for the existing data set (IE original background ata) the best method for enhancement is to create a scaleable mask layer. Then render/decode each tile layer and scale it using fractal interpolation, apply the priorly made mask layer to the results (think of using a cookie cutter) and recreate the data, substituting this new data for the original data (IE this all happens in memory and does not create a new file).  Depending on how the Q-gears engine defines it's tile set, will depend on how this whole concept would work.  Remember the tiles will be part of an OGL texture. They are 16x16 RGBA pixel blocks in an fixed texture block (256 512 1024?) If one used 256 x 256 texture blocks (like FF7 does) FF7 uses up to 5 such blocks for the field layer information.  This gives you 256*5 or 1280 tiles TOTAL for the original system.  Newer display cards can use larger texture caches (1280 x 256 texture size is only 327680 pixels or 1.2M of texture space). So quadrupling the surface area (IE 4x the tiles) is quite possible to do.  All the characters use very little texture space, (256x256 max for battle models and much less for field models).

Cyb

[stormmedia]

Well.... my question is why making them "bigger".. I mean if you mean raising the resolution of the backgroud... I think it be useless anyways because the backgrouds are basicaly just images files... So I don't think raising the resolution would fix the problem of blocky backgroud here... it's like if you find a picture too small... you zoom in and it gonna be blocky... event if you make the backgrouds at 1024x768(for exemple) it won't make the blocks magicaly vanish... the only way would be filtring them... but if there is a tiles limite... then I guess the only way is to mess with the code ...

[RW_66]

Somebody correct me if I'm wrong, but I think the only way to "correct" the problem would be to insert a sub-routine after the program outputs the BG/models info, and before the info is sent to the screen dump. Basically, I'm talking about bypassing the original rendering engine, which may or may not be realistically possible or practical.

If somehow the models and BG tiles could be "captured" seperately, they could be filtered and/or substituted with higher-resolution models or tiles. The Q-Gears team I'm sure will be looking into how the models and tiles are called and rendered in the future, after all the play mechanics are mapped-out and fully understood. However, there is the consideration of "practicality' here, as to whether this may or may not interfer with system or OS portability.. which would defeat the stated purpose of Q-Gears.

[Cyberman]

Ok the biggest issue for higher resolution backgrounds is you only can use integer scaling.  This is an artifact of the original system used for the tiles.  Sets of tiles are grouped in tile sets in texture memory on the PS1 and PC. You can (for example) scale each tile individually applying the filtering per tile.  However this has issues. Namely each tile edge will not look to hot, nor will the scaled tile (pasted into the scene) since it will be smudged and blured.
This is because traditional scaling methods involve interpolating data using data points to approximate luminositys and colors between based on the original data.  It's a data fitting algorythm.  This limits it to smering data or with cubic spline and Lacroz3 it's slope fitting. In either case the original idea is just magified and thus blurred.
Fractal compression is where you can get more approximated detail.  Fractals have the lovely abilitied to be infinitaly scalable and retain there shape and detail.  This is due to the nature of the affine transform and the use of iterative generation of fractal patterns.  Right so how does this work?  It takes a pattern of the image (not the actual image) and creates a data set of this pattern.  Next you change the scale of the patterns and regenerate the scene based on the fractal patterns. Although it might not be identical to the actual scene data from copy art in terms of details it will be close enough.  Much closer than traditional methods. All right this is cool... no it's not actually since recognizing the patterns is quite computationally intensive.  IE it will take a long time to do this on the fly.
Then comes the fact one is stuck with integral values of scaling (sorry no 1.244X * 1.334Y scaling). Why? It's surprisingly simple, sections of the background are never seen because a sprite layer covers over it. To prevent the scaling from making weird little green cyan and red spots appear, you have to DICE each sprite layer (remember the cookie cutter discusion) out.  After processing ALL the sprites and layers used, you then create the new background data which you feed into Q-gears instead of the old background data.  As for substituting new background data, that would require tools to create backgrounds in the FF7 format that would scale properly in Q-gears, or a new format with XML meta data to allow it to be used. None of these are TRIVIAL or even close to simple things to implement.  It's hard enough to get the original content to work consider that first.

Cyb

[RW_66]

Cyb,

Would it be possible to take each of the tile areas (as a whole, for instance the "Wall Market" area), put it through a fractal sharpening program, and then break it back up in to pallettized tiles? The reason I'm asking, is if it were possible, you could have the tiles "premade" for each area (hence, no computationally intensive work during the procedure), and then all that would be required would be a simple "substitution" program (that is seperate from the FF7 engine) to use the "hi-res" tiles, instead of the regular lo-res ones.

What I'm talking about would involve seperate rending code, so that when the FF7 engine called for palletes AA.p-22p, the "wrapper" program would actually grab the Hi-res AA-22 palletes, and return back to the FF7 engine for the next instruction. Same thing with models. Basically, I'm talking about substituting some of the graphical sub-routines, so that, in-fact, they are much more PC friendly and scalable like OpenGL than, the original re-compiled psuedo-PSX coding.

I know you and Halkun, and the rest of the team are no where near this area yet. But if the goal is to increase cross-platform/OS compatibilty, then the graphics coding is going to need to be over-hauled, because as-is, it's simply an un-workable mess. Obviously, Eidos simply just subistituted the bare minimum to the display coding, leaving a lot of useless and archaic codes. most of which even THEY probably don't know exactly how it works.

[halkun]

First, it was Square that did the port, Edios was the distributor.

There are serveral probelms with the backgrounds, other than listed above.

The game was created for the PSX, and was originally written just for that system. All the data, like the music, 3d models, and backgrounds were created just for the Playstation. The tools that were made to render or otherwise create the game data was exclusivly for that platform.

The backgrounds are based to tile maps that had to placed in special texture caches. The PC doesn't do graphics like this. Not only this, the PSX VRAM surface has all kinds of wierd properties that can't be duplicated on a PC. (Mutiple color depths on a single drawing surface for example, another is oddball resolutions that are dynamic by simply creating a rectangle on VRAM. 1024x240 anyone? (I've seen that used!) Whatever the size, the resolution is "squeezed" onto the TV screen. Let's see a PC card do that!

Because the backgrounds made up of tiles, any filtering will cause the tiles to "shatter" because each tile has no idea what kind of graphic data is sitting next to it. You need to know the color attribute of your neighbor pixels to do any kind of blending.

Also Square used god-awful colors under the layers for debugging. When a tile has some of this debug color, it will "bleed" out when filterd from under the top layer. This creates bright green and red outlines everywhere.

So repeat after me.

"The backgounds are not stored or rendered as bitmapped images."

They *look* like pictures in the end result, but they are actually a rendered texture matrix. This is incompatible with filtering that requires an entire image to work properly.

Now, Will Q-gears get higher resolution filters? Most likely yes, but not for a long time and it's going to require a multi-pass render first to get any kind of good data. (render and filter with all layers on as a "base layer" with no debug color, then render and filter every layer on top and hope that it doesn't bleed too badly) The current FF7 engine has no ability to do multi-pass renders and uses the tile system to create an illusion of 3D depth. It's just how the system works.

It's why we all wish for a new engine.