Final Fantasy Type 0 Psp Textures

[Joseph]

While looking over an old script for unpacking the Final Fantasy Type-0 HD files I noticed a lot of files were missing. I had updated an old script by chrrox to not only include all files but unzip them as well. I included a few other scripts, an app and a 010 template for the game models made by others in an attempt to centralize information about the game systems.

Error: incomplete input file 3: C:\Users\jaker\Downloads\Final Fantasy Type 0 HD\pack0.pac
Can't read 55760 bytes from offset 0000000066c6b3fc.
Anyway don't worry, it's possible that the BMS script has been written
to exit in this way if it's reached the end of the archive so check it
or contact its author or verify that all the files have been extracted.
Please check the following coverage information to know if it's ok.

Do you think it would be possible to create a BMS script to extract texture from the model's BIN files ?
My goal is to extract them, modify and rebuild.
I tried but I'm not good enough for this kind of things.

As far as replacing textures. I'm sure there is already tools for replacing dds textures. The model viewer might give you clues for where other textures are located. As far as repacking, you would have to reverse the .pac file unpacking process, it's very messy but should be possible. Not sure what type of errors it would lead to as my script overwrites dupe files that may be important.

The other obvious limit is texturing. Texture pages on the PS1 hardware had a limit of 256 by 256 pixels and so it seems this was generally the largest texture size most models used. These days games often use multiple 4k (4096x4096) textures per model, especially for hero props or primary characters so this is somewhat limiting.

A YouTuber named LittleNorwegians has an excellent tutorial showing how PS1 textures are often made in games like Metal Gear Solid and Silent Hill. There is a common thought that PS1 models must have textures made from spliced and edited real photographs, and while real photographs were used in PS1 textures, in all the research I did, textures were combinations of images, hand painting and various effects as is shown here.

If you attempt to make some PS1 style art you might find that large environmental artwork such as buildings, streets, and so on are very difficult to do with such restrictive texturing limits. You find it interesting to note that the technique I found to be most popular among a lot of PS1 games was to break the environment up into tiles and then each tile maps to a specific section of a texture.

When you combine this with an output resolution of 320 by 240 pixels, it can be very obvious that the polygons are jittering. If you pay close attention you can see that the actual shape of the polygon is changing due to the vertices moving to the grid, so the whole triangle sort of shakes and wobbles.

The PS1 had no such depth buffer and it was up to the developer to draw all the necessary primitive shapes in the correct order, starting at the back and drawing closer things later. The PS1 development libraries had things called ordering tables to help you do this. Primitives would be placed in the table at a location tied to their distance from the camera, then the list would be walked through to render the scene. Sometimes though multiple things might disagree about their depth and flickering bugs would occur.

\(\alpha \) here is some 0-1 value on the screenspace surface of the triangle. So there are two alpha values (you'd use the other one for the \(v\) coordinate), and they allow you to define a point on the surface of the triangle. Since they smoothly blend across the triangle, you can use them in the above equation to blend the UV coordinates from each vertex. The result will be a UV coordinate that you can use to lookup in the texture.

I admit this is a little difficult to get your head around. But if you use your fingers on your screen right now, you can verify that in the rotated quad, the central blue line does in fact cut through the centre of the diagonal. This is precisely the issue. This primitive screen space approach gives a warped view of the texture when depth varies a lot.

So how does one fix this? Well, the way it is done in modern GPUs is to take advantage of the fact that you can do linear interpolations if you can convert the 2D coordinates into something linear in screen space. A way to do this is to divide them by the depth value of the coordinate.

Since this is now linear in screen space, we do our interpolation like normal and then multiply by the depth value to get back to texture space. The resulting interpolation algorithm looks like this for the \(u\) coordinate,

If we try this again on our quad, you can see how the vertical lines are mapped from the quad onto the texture map. It perfectly solves our problem, but how? Well if you think about points along the diagonal edge, distances between the points are larger on the screen the closer the edge is to the near plane of the camera. So naturally, the sections closer to the camera need more texture density to look correct, which ends up biasing our texture lookups to be larger on the side closest to the camera.

Anyway, implementing this is extremely easy on modern GPUs, since you can explicitly ask vertex data to not be interpolated with perspective correction. Using both hlsl or glsl you can specify the noperspective type qualifier on vertex input data, and voila, it is done.

The second reason, if of course to alleviate warped texture issues. If you have more polygons, then there are fewer pixels where you must interpolate the texture coordinates, and so the less warped it will be.

This is another feature that I have not yet implemented in my PS1 renderer, again because it does not contribute enough to the look considering the work involved in implementing it. I will update this article should I get to implementing it in the future.

Flat shading is the most basic kind of shading you can do. The lighting values are constant for each primitive, which back in the PS1 days is a big boon to performance. For most aesthetics though, this is not sufficient to make things look smooth and realistic.

Implementing this on modern hardware is fairly straightforward. You do your lighting calculations in the vertex shader and output a colour per vertex to mix with the texture mapped colour in the fragment shader.

Peter "Durante" Thoman is the creator of PC downsampling tool GeDoSaTo and the modder behind Dark Souls' DSfix. He has previously analyzed PC ports of Final Fantasy XIII, Dark Souls 2, The Witcher 3 and more.

Certainly an upgrade over the initial, and even the updated, state of FF13's launcher. However, my joy about this improvement was short-lived: the "resolution" setting has exactly two options: 720p and 1080p. Sadly, all the options for the game are stored in a binary file which seems to be either compressed or encrypted, so there is no simple way to challenge this restriction. While bad enough on its own, given what I learned when looking at the game's rendering in more detail, it's a puzzling and infuriating omission. But more on that later. Let's first have a look at what all these graphics options actually do.

FFT-0 offers a respectable set of rendering options, and sometimes labels them with unusual terms which can make understanding their effect challenging. Therefore, I'll quickly go over most options and describe or show their visual impact.

This option implements a variant of SSAO (screen-space ambient occlusion), which tries to approximate the impact of global illumination on the ambient light level of surfaces. It's not a particularly high-end version of the effect, but nonetheless it enhances the depth of most scenes, and its performance impact is small.

Another effect which doesn't require much performance, but generally improves the image significantly, this option is more commonly known as screen-space reflections (SSR). It is applied quite liberally, sometimes even on surfaces which you might not expect to be quite that reflective.

Type-0 offers three shadow quality options: none, "Normal" and "Detailed". I believe that "Normal" is what the console version uses. With "Detailed", we see a significantly higher quality effect, with smooth soft shadow edges even when zooming in on problematic angles and almost no edge crawling even on distant shadows.

More specifically, I found that "Normal" shadows are rendered in a single pass to a 2048 surface, while "Detailed" shadows render three separate passes to 3072 targets each. Naturally, this also results in a slightly more pronounced performance hit.

Here the game provides a "Low-res" alternative to "Normal" textures. Given that many textures already show the game's portable roots, I don't believe the lower setting to be of interest to anyone using even a remotely recent PC.

There are a number of settings that have almost no performance impact and come down purely to aesthetic preference. This includes Depth-of-Field, Lens Flares, and the level of motion blur. The last is quite strong even at normal level, and personally I prefer the "Weak" setting.

I was surprised to see some options for different Color Correction filters. While these are apparently designed to counteract some types of color blindness, there's nothing preventing you from choosing one out of preference. Here is an overview of what each of them looks like:

I have to admit to keeping the best for last here. What first struck me after launching FFT-0 and getting beyond the initial videos was just how amazing the image quality on display was, despite the apparent 1080p limitation in resolution. Honestly, I could not believe that the game actually rendered at "only" 1080p.

"Normal" uses a good implementation (correctly leveraging motion vectors) of an accumulative temporal AA mechanism. What this means is that it offers very good edge quality in stills, with an extremely low performance impact. This comes at the cost of some sharpness and various artifacts related to movement, especially of small sub-pixel structures.

c80f0f1006