FF8 PC and Steam - bad UV's?

[Mcindus]

Hello everyone - I've been looking into other aspects of FF8 and have found a recurring theme!  On the PC version and Steam version, the UV's seem to be off by a fraction of a percent on ALL GF's, Enemies, Vehicle models, Roads, and everything else on the World Map (bad seams compared to PSX).  From what I see, this most likely translates to the entire game by the same ratio.

Any thoughts from you guys?  Would there be a way to effect UV's on a 'global' scale?

[Maki]

The problem is in game code. It is not related to files itself.

Fix is to find and produce Jump to instructions where you correct the scale variables over registers. The problem is- which register at which state holds texture size. Another fix is to prepare corrected textures made upon bugged code.

[Halfer]

What I encountered with the UV's while making the wmx2obj program is that the UV's aren't misplaced accidentally but on purpose by developers. The engine adds value 1 or subtracts 1 according to how the UV is placed on its grid.

Why it's done like that? Well in PC version it seems that if the value is exactly the same as described in the file, it creates an overlap to another texture tile. Here's an example:




If the value is exactly on the edge of UV map, it overlaps with another texture next to it. In this example it's the alpha layer on the other side. I'm not sure why this problem exists but maybe someone with better knowledge of 3d texturing could enlighten us with this.

That is one reason why in PC version UV's are "misplaced". I don't know how PS version handles these files but PS seems to handle these much better than PC does. I'm still looking for a solution to bypass this problem with PC version while I'm making next version of wmx2obj.

[Zervox]

Now I am not sure if this is correct though, but playstation one was integer points only right? could this be caused because PCs would normally use floats for texture coordinates instead of integers? I am thinking specifically about possible inaccuracy of integer to floating point conversion(as I am not read up on the data, but I am asuming they are using pretty much the same files for PC as they do for PSX), not sure how FF8 on PC deals with this conversion.

[Halfer]

Now I am not sure if this is correct though, but playstation one was integer points only right? could this be caused because PCs would normally use floats for texture coordinates instead of integers? I am thinking specifically about possible inaccuracy of integer to floating point conversion(as I am not read up on the data, but I am asuming they are using pretty much the same files for PC as they do for PSX), not sure how FF8 on PC deals with this conversion.

That actually can be true. Float has 24-bit precision while integer has 32-bit precision. However, I still do have some problems to understand how the conversion affects the UV's like that.

[Zervox]

I see the mention about its offset by a percentage, is this percentage fixed? eg the same for all of the same object, I am not aware if the shaders in FF8 is the same for all objects, and if its not, is every object textures off with a percentage? or is there only specific type of objects? like GF,Character mesh, world tiles?

I am thinking if the percentage is fixed, each coordinates is padded with additional offset like if you just get the coordinate at 1,1 its actually outside the texture at 0,0 and thus the final coordinate at 256,256 is 255,255 or the reverse occasion, 257 instead of 256.

Edit:
That or I could guess that the shaders might actually just use wrong samplers.
It seems the problem mention here is the same I've found in many cases when it comes to DirectX or GL and the link below actually shows similar/the same problem.
http://gamedev.stackexchange.com/questions/21910/how-to-fix-odd-artifacts-at-the-edges-of-textures-in-directx-11

[Halfer]

Well the values are from 0 to FF (0-255) so as you can see in my version of the program that I manually scaled the range to 0-256 and made some exceptions to 7F (127) and other values to represent what they actually should when exported.

So does that mean that the textures are not clamped thus overlapping with wrong regions. I could see that being a problem and why values are then changed in the engine to not go over its assigned region. I'm not sure if this can just be fixed by modifying the values, may need a modification on engine side.

[Maki]

I took a look at how engine treats texture and I see that it doesn't read TIM texture in real-time. What I want to write is: The engine loads .TIM texture, converts it to probably 24BPP bitmap and reads that bitmap. The error is probably bad 4BPP to 24BPP texture conversion. That one pixel indeed can be lost or added in this conversion process.

I replaced road TIM with train texture (byte to byte) and the road disappeared. That's really weird.

Here:


The .TIM texture has also origin X Y.

Thanks to this texture we can see what's really happening here.

[Mcindus]

Wow. This is why I love these forums.  You guys are amazing.

So... does anyone have any ideas on how to work around/fix this?  I'd love to update my world texture mod with a balamb that isn't distorted.

Why does the railroad texture flip 180 degrees every time it's repeated?  It looks almost like it's pulling in a pixel from the 'next' texture over.

[kaspar01]

Why does the railroad texture flip 180 degrees every time it's repeated?  It looks almost like it's pulling in a pixel from the 'next' texture over.

That's probably not a "bug" (and it's probably because of the original UV texture-optimization).
Take the Garden Halo ring for example.
you don't have a full ring on the texture but still you can enjoy a full ring since they mirrored it on a 4 quads plane.

This kind of stuff were really good whith low quality graphics but nowdays whith higher resolution texture you can easily see the seams-repetition..

You could maybe try to fix this changing UV of the 3d models in a 3D editor but it could take a lot of time and there is not yet a way to re-import a model into the game so..

[Maki]

Looks cool now, huh?
I grabbed the PSOne emulator memory, parsed it to file and streamed over to FF8 steam memory. This came up. What does it mean? Their load engine is somehow messed up. WMX dumped from PSOne to FF8 resulted in the same messed up UVs.
The problem is when the engine loads the data from file.

1.Engine loads given segment
2.Process some bad things on UV
3.Reads new processed segment
4.This processed segment remains in memory

If you'll write 0x9000 segment straight to memory, then you'd get correct world map segment. That's good, I can search now for the instruction that destroys the textures. 

EDIT:
FF8DISC1.IMG holds TWO worldmaps (sic!)
First one is at 0x108800 and second one is at 0x108800+(0x9000*835).
The one at 0x108800 is 100% similiar to the one in PC version (that's what my simple tool says)
Okay. The second one at 0x108800+(0x9000*835) is 71,52009% similiar.

Here's the proof:
https://youtu.be/-VMHtCKtj3s

Sorry for music and segment scattering. See 1:37

UPDATE (18:32)
This opcode in steam version accesses ALL* loaded uv's segments in game:
FF8_EN.exe+153D47 - mov [eax-01],cl

@UPDATE (23:00) : Well, not ALL, just copies from CL register. The UV messing engine uses CL, DL and BL registers (Byte register), so this could be only... U1 for example... Next OP is as far as I remember dl copy, so...

Link to patch: http://forums.qhimm.com/index.php?topic=16327

[Halfer]

That's great!

Do you have more in-depth info about this behavior in the engine? Also is it caused by the renderer or the algorithm or something else?

[Maki]

Square was, well.... weird. They did some weird things that we still can't understand, like putting G.Fs in three different archives with no reason, or some other newest sound revolutions (like the game uses hardcoded in EXE sound offsets instead of querying audio.fmt, but it still does work with this sometimes - nonsense). Here, the developer tried to overcome the bug that happens during the conversion. The game optimisation forces lossy conversion. (max CLUT color is 31 bit, so 255/31 = 8,1..., at some point you're inaccurate for at least 1-2 in colour. Something similiar happens in world map UV. Float is 4 bytes long, but world map coordinates are saved upon one byte. Engine needs to resolve 0.0-1.0 UV format from 0-255 variables. The programmers though about "brilliant" idea to workout some glitches that were appearing because of loosy conversion and they did several conditions to test, if the face UV is out of bounds (and if they were, they added or substracted 2 from this variable). I don't know why someone released a game with such a bug in code.

BTW> I don't remember if I wrote this before, but PSOne image has two wmx.obj. One is 100% identical to PC version, and second is 71% similar. Another Square "WTF?".

[paul]

Not sure if you figured it out but the reason the UV's seem wrong is due to texture filtering. If you force linear filtering it shouldn't have the problem. Usually in a texture atlas you have to repeat the last couple of pixels to make a border to prevent the texture atlas "bleeding".

[Yagami Light]

Regarding the two world maps in the ps1 version, maybe one of them is for disc 4 during the time compression world map period? Can you actually see what the differences are? I'm curious

[Halfer]

Regarding the two world maps in the ps1 version, maybe one of them is for disc 4 during the time compression world map period? Can you actually see what the differences are? I'm curious

I don't think it's for that. At least it shouldn't be because they could be easily scripted and it seems like they are scripted in wmsetXX.obj

[Maki]

I'll process the worldmap with wmx2obj soon and see what's going on there.

[Maki]

These are two dumped files (One PC Steam and second one is PSOne):
https://www.dropbox.com/s/xfp7yms52vc1wmg/WMX_PC_and_WeirdPSone.7z?dl=0

[Halfer]

I checked them with the wmx2obj. The difference between the files seems to be that they are in a different order and formed with a different algorithm. Also there was some occasions where areas only including water had a couple more normals than the ones in PC. However I cannot confirm if the added normals are not present in the PC version since the ordering seems to be different.

[Kaldarasha]

Regarding the two world maps in the ps1 version, maybe one of them is for disc 4 during the time compression world map period? Can you actually see what the differences are? I'm curious

I could imagine that it is for the low res textures or maybe it will be used when you are fly with Ragnorok or the Garden.