Author Topic: [FF8] .x battle fields  (Read 58689 times)

Yagami Light

  • Crazy poster
  • *
  • Posts: 152
  • Karma: 25
    • View Profile
Re: [FF8] .x battle fields
« Reply #75 on: 2015-02-16 13:42:00 »
That wireframe picture is from the ps1 version, I used 3D ripper dx to capture it, can't get it to work with the pc version though, the pc version is just an earlier development build of the ps1 version which was the final build. Thats why there is only small differences, I noticed a lot of small areas on the world map with texture flickering above balamb towns door, parts of ragnarok, parts of mountains etc, which to me seems like mesh overlap, and then there are other areas like the grey path or the traintracks which has misaligned mesh/missing mesh altogether, need to see what the pc versions wireframe is like to be completely sure though.

paul

  • Crazy poster
  • *
  • Posts: 180
  • Karma: 33
    • View Profile
Re: [FF8] .x battle fields
« Reply #76 on: 2015-02-16 16:19:19 »
Isn't this format likely to be similar to FF7 where it is splitted into a grid and each grid contains a collection of meshes? Is FF9 WM the same way? If so the FF8 must be too.

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #77 on: 2015-02-16 17:21:34 »
Towns are in wmset.obj and wmsetus.obj (also Gardens, trains etc.), not wmx.obj.

For the camera:

x01CA92E4 this is 2 bytes.
Select mode by 'F' default on steam release, and make it zoomed out, then search for 80 02 (640). For zoomed in it's 00 04 (1024). 
But as I see VIII allocates memory on fixed addresses. More funny thing is that this zoom is also fixed.


So to summary:

ASM write instruction:
Code: [Select]
mov [eax*4+01CA927C],ecx at 0x0045D7FA (FF8_EN.exe+5D7DA)
Code: [Select]
FIXED address: FF8_EN.exe+18A92E4 / 0x01CA92E4
FIXED values:
-Zommed in: 1024 (2 Bytes) / 00 04 (uint16 ByteArray l=2)
-Zommed out: 640 (2 Bytes) / 80 02 (uint16 ByteArray l=2)
/[code]

@Yagami - that wireframe shot is cool. :)

@EDIT:
Still working on that UV. This is really weird thing. But, luckily there's a hidden stage there in files, that contains this texture:
, and ground square with this texture associated as-is. :) I just reminded it.
« Last Edit: 2015-02-16 17:34:35 by MaKiPL »

Halfer

  • Crazy poster
  • *
  • Posts: 142
  • Karma: 31
    • View Profile
Re: [FF8] .x battle fields
« Reply #78 on: 2015-02-16 18:58:11 »
Thanks anyway! Too bad that I don't have the steam version so can't find that line :/

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #79 on: 2015-02-16 19:21:59 »
Thanks anyway! Too bad that I don't have the steam version so can't find that line :/

Just search for this fixed array of bytes.
-Zommed in: 1024 (2 Bytes) / 00 04 (uint16 ByteArray l=2)
-Zommed out: 640 (2 Bytes) / 80 02 (uint16 ByteArray l=2)

JESUS! This UV drives me crazy!

EDIT2: I checked FF7 and FF9 documentation on model textures. None of them were identical, but FF9 finally had info about RGB + ??.
This way, the quad in FF8 level is:
Code: [Select]
## f
uint16 A; +1
uint16 B; +1
uint16 D; +1
uint16 C; +1

## vt
uint8 U1;
uint8 V1;
uint8 U2;
uint8 V2;
uint8 U3;
uint8 V3;
uint8 U4;
uint8 V4;

## engine specific
Unsigned 24 bytes:
Byte R; //Red
Byte G; //Green
Byte B; //Blue

##UNKNOWN
Byte ??

Where UV4 is top right corner, UV3 top left of bottom right? This needs to be converted to -1.0 - 1.0 and I completely don't know how. Like getting short, then a percentage? I need some sleep... Ugh..

UPDATE:
AAAAH! I get it now. In f after it get's texture the whole thing looks like:

f 1/2 2/1 etc...
where:
Vertex index/vertex texture index
I'll test this out, but tomorrow.
« Last Edit: 2015-02-18 19:35:49 by MaKiPL »

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #80 on: 2015-02-18 19:27:51 »
Phew... UV cracked (EDIT: Nah, still working):


U1V1 ?1 ?2 U2V2 ?3 ?4 U3V3U4V4 works fine, where:

?1 - Opacity. Like blending Alpha channel
?2 - Texture related?
?3 - This one is funny. It's like allocating texture to any other object in the game. That's why reversing triangles made up the enemy and player UV go crazy.
?4 - Related to above

U = Byte (0-255). Calculating this to 0.0-1.0 form is: X/Byte (like: 192/256). Same with V

Also, for faces this should be of course f1/1 f2/2 f3/4 f4/3, where f1=A, f2=B, f3=D, f4=C, Because ABCD> ABDC. Either one triangle of texture will be rotated 90o.

I'll try to code some automation tool, to test whole mesh.
** Missing triangles on mesh is because I didn't import triangle info, just want to test the UV on quads first.


UPDATE:
Ehh...
I wrote my automation tool.
But wait... I'll test something. I'll build whole mesh.

UPDATE2:
Yep... UV is still broken. Also, take full geometry dump of a0stg017.x:


It is full dump, with triangles also. Ignore texture. 406 polys.
« Last Edit: 2015-02-18 21:12:44 by MaKiPL »

Halfer

  • Crazy poster
  • *
  • Posts: 142
  • Karma: 31
    • View Profile
Re: [FF8] .x battle fields
« Reply #81 on: 2015-02-18 21:14:58 »
Wow! very nice progress, looking forward to your works! :D

LeonhartGR

  • No life
  • *
  • Posts: 2521
  • Karma: 36
  • ~Whatever...~ Enjoy life!
    • View Profile
    • LeonhartGR Productions
Re: [FF8] .x battle fields
« Reply #82 on: 2015-02-18 22:08:21 »
Now that's what we call god! The creator! XD

halkun

  • Global moderator
  • *
  • Posts: 2113
  • Karma: 23
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: [FF8] .x battle fields
« Reply #83 on: 2015-02-19 00:18:53 »
Remember to check out the PS1 GPU opcodes. Most of the time when programmer made models for the PS1, they usually used a format that could easily be placed into a linked list (Called an Ordering Table or "OT") so the DMA could chain the list from memory directly into the GPU (Having the GTE fill in the 3D blanks)

This means the OT looked something like this (GROSS GENERALAZATION!!! See GPU Opcode list)

GPUOpcode [arguments] [coordinates]
GPUOpcode [arguments] [coordinates]
GPUOpcode [arguments] [coordinates]
GPUOpcode [arguments] [coordinates]
GPUOpcode [arguments] [coordinates]

Keep in mind that the PS1 GPU only could draw dots, lines, triangles, and quads. The tris and quads could be flat, vertex shaded, or textured with a set kind of transparency.  The GPU could not do 3D so the 2D draw coordinates was normally calculated by the GTE (3d to 2d conversion) and patched into the OT. Then the ordering table was reorganized by Z depth and chained via DMA to the GPU to be drawn on the screen.

I was going to say that most often the 3D vertexes were "pooled" together so they could be calculated one right after another by the GTE, but it looks like you already found the vertex pools.

I hope that makes sense....

Yagami Light

  • Crazy poster
  • *
  • Posts: 152
  • Karma: 25
    • View Profile
Re: [FF8] .x battle fields
« Reply #84 on: 2015-02-21 11:25:32 »
I loaded that battle scene into psx v ram and the textures are 8 bit I think? see bottom left of picture



Also this person made ff9 battle scene exporter/viewer with source code included if that helps you

http://forums.qhimm.com/index.php?topic=12476.msg173501#msg173501

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #85 on: 2015-02-21 13:36:09 »
Yep, 8 bit, also UV is 8 bit too, I'm just lack of calculation. I'll take a look at the source of the software you just linked. Thank you. :)



UPDATE:
Thanks to source of this FF9 viewer I noticed, that the Y of texture needs to be 1.0f (V1/255).
« Last Edit: 2015-02-21 18:16:33 by MaKiPL »

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #86 on: 2015-02-21 18:21:34 »
Done!


Still, manual way is long. I'm trying my best to code a software for that, but it's a long way. I'll make a video how to rip this manually soon.

For triangle it's similiar, just ignore two 00 3c and b0 00 (this values can be different in some extreme cases).
« Last Edit: 2015-02-21 21:05:48 by MaKiPL »

Yagami Light

  • Crazy poster
  • *
  • Posts: 152
  • Karma: 25
    • View Profile
Re: [FF8] .x battle fields
« Reply #87 on: 2015-02-22 14:13:55 »
Good job, glad that source helped you, so uv fully works now? or is there still some issues.

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #88 on: 2015-02-23 13:25:04 »
Good job, glad that source helped you, so uv fully works now? or is there still some issues.

I though so it's 100% working, but take a look at other stage:

I'm still missing some calculations.

My current source code for vt:
http://pastebin.com/uHABUT2X

Yagami Light

  • Crazy poster
  • *
  • Posts: 152
  • Karma: 25
    • View Profile
Re: [FF8] .x battle fields
« Reply #89 on: 2015-02-23 15:37:21 »
That mesh is for the ground brick texture I think, use this texture and see what happens.


Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #90 on: 2015-02-24 20:14:43 »
@Yagami - yep, changing this manually to ground texture looks fine. :) So:

V looks okay in both appearances. Also, texture can have origin X Y, maybe that's the case?

V calc:
Code: [Select]
float VV1 = 1.0f - (V1 / 256.0f);
But That U (X axis <>) is just the bad one. This needs more testing. I'll see what I can do tomorrow/ day after tomorrow.

This is difference between VT of calculated from file, and manually fixed in 3DS Max:
http://pastebin.com/q4ftdBPr

See that V is fine?
If someone could end up with any solution, which calculation will end up with the same as that fixed one, then I'll be grateful. :)

Also my source code for getting to CLUT info with height and width of texture:
http://pastebin.com/xs5bCFhN

Ignore TextBox.text settings, it's for debug info/output.
PS> Yes, I know I could just read uint16 by passing index instead of copying to array, but I just left it for some later tests.
szer = szerokość = width
wyso = wysokość = height.
« Last Edit: 2015-02-24 20:31:03 by MaKiPL »

Halfer

  • Crazy poster
  • *
  • Posts: 142
  • Karma: 31
    • View Profile
Re: [FF8] .x battle fields
« Reply #91 on: 2015-02-25 10:59:16 »
IT seems like you are missing 0.3333 from every U value. Can you just take that in note and reduce it with script?

EDIT: now that I read my sentence again I realized how messed up it is :D but you'll get the point if it is that easy to solve.
« Last Edit: 2015-02-25 14:24:29 by Halfer »

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #92 on: 2015-02-25 14:43:22 »
Added + 0.3f to U, and:



Ehh.. Still.

Halfer

  • Crazy poster
  • *
  • Posts: 142
  • Karma: 31
    • View Profile
Re: [FF8] .x battle fields
« Reply #93 on: 2015-02-25 17:13:33 »
Do 0.3f and 0.3333f differ from each other? Not familiar with the f letter after number
« Last Edit: 2015-02-25 18:24:50 by Halfer »

Zervox

  • Cool newbie
  • *
  • Posts: 55
  • Karma: 7
    • View Profile
Re: [FF8] .x battle fields
« Reply #94 on: 2015-02-26 11:54:41 »
0.3333f and 0.3f differs 0.3f=0.3000f
f = floating point eg a decimal variable.
0.3333 would be a double precision decimal variable.
« Last Edit: 2015-02-26 12:00:27 by Zervox »

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #95 on: 2015-02-26 12:03:48 »
EDIT:
Ahh, Zervox, you were faster. :D

Do 0.3f and 0.3333f differ from each other? Not familiar with the f letter after number

f is cast to float. So:
0.3f = (float)0.3

Float is a data type that has a point.

I'm going also to try using decimal instead of float.

BTW> 0.33333 worked fine:


0.3f is 0.300000000000...
and 0.33333f is 0.33333000000...
That 'f' is only for code to transform this to float.

I'll see the texture now, to determine if the origin is moved.

UPDATE:
Texture data for a0stg027.x is: 0 for origins, 256 for Y (so height calc should be: 1.0 - Byte/256 - and it is). Width 384*2. Height = 256.
So it's still just a U (width) axis bad calc. I'll try with decimal, then 384 instead of actual width. Also I'll get some additional meshes.
« Last Edit: 2015-02-26 12:27:57 by MaKiPL »

Zervox

  • Cool newbie
  • *
  • Posts: 55
  • Karma: 7
    • View Profile
Re: [FF8] .x battle fields
« Reply #96 on: 2015-02-26 12:29:03 »
Glad it worked. It's nice when the problem is something really simple(unless one has spent alot of time debugging just to find it was way too simple).
That last screenshot made me dizzy for some reason, think its because of the shape, :)

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #97 on: 2015-02-26 15:00:50 »
Multi-mesh test with Byte/768 + 0.3333f:


This is only 1/2 of model!

LEGEND:
Red is triangle (I do have VT automation script only for quad byte order, I had changed it to triangles, but then just rewrote back to quads instead of saving this as a copy... Genius me... -.- )

Only the hotel texture is bad (see? The X axis is again moved, like it should be now added 0.6666f instead of 0.3333, where's the info for that? -.- ). Also:

Decimal instead of float - Doesn't do any difference. I'll keep floats
Uint16 TIM width instead of multiplying to two (This is needed to get real width) - Nope
Checking origin to correct texture calc - Script was already set to that

Next:
Check left 5 bytes of quad and see differences of the "working" texture quads. I think that there's info on how much to add or something. I don't know.
« Last Edit: 2015-02-26 15:05:14 by MaKiPL »

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #98 on: 2015-02-26 18:11:07 »
Next:
Check left 5 bytes of quad and see differences of the "working" texture quads. I think that there's info on how much to add or something. I don't know.

YUP:


This complicates things a little. -.-



Current quad info:
Code: [Select]
U1 V1 OP X1 U2 V2 MX X2 U3 V3 U4 V4 RR GG BB ID
OP - opacity?
X1 - Pallete or something. When changed makes the texture like inverse colors, blue domination etc. (Maybe CLUT pallete data?)
X2 - When 1 or odd makes the texture dissapear. When even or 0, the texture shows up.
MX - X axis matrix. Higher is left <---
ID - GPU related. Changing this "connect" one vertex to some object. It's clearly rendering thing and is useless for any other thing.
« Last Edit: 2015-02-26 18:15:57 by MaKiPL »

Maki

  • 0xBAADF00D
  • Freak
  • *
  • Posts: 608
  • Karma: 135
  • 0xCCCCCCCC
    • View Profile
Re: [FF8] .x battle fields
« Reply #99 on: 2015-02-28 07:30:50 »
This is from FFTactics research wiki:
Quote
The texture page number is multiplied by 256 and then added to the V coordinate for each point on the polygon. This is because the UV coordinates are stored as bytes, but the textures are 256x1024 pixels, so effectively there are 4 texture pages.

That makes sense finally.



However, adding 256 makes the texture get over with it's resolution. Because:
If 3 was 3*256, then 768 is already a max of this texture, and also adding U params to this makes it possible to use texture after 768px, so it has to be smaller than 256. 128 maybe?
See? B5 if 5*256 = 1024, so it exceeds 768px texture.
128*5 = 640 looks fine. :)
« Last Edit: 2015-02-28 07:51:53 by MaKiPL »