Qhimm.com Forums

Final Fantasy Forums => Scripting and Reverse Engineering => Topic started by: Halfer on 2015-01-13 16:55:51

Title: [FF8] .x battle fields
Post by: Halfer on 2015-01-13 16:55:51
Full documentation of battlefields done by MaKiPL found here: http://wiki.qhimm.com/view/FF8/FileFormat_X (http://wiki.qhimm.com/view/FF8/FileFormat_X)

Tool to extract battle stages found here: http://forums.qhimm.com/index.php?topic=16017.0 (http://forums.qhimm.com/index.php?topic=16017.0)




Hello!

I've started to study a bit of Final Fantasy 8 files and I happened to see that there was no documentation of .x battle fields in Qhimm's forum. I didn't find any threads about this file format or I completely missed it so I decided to make this thread.

After searching about this format I came to conclusion that this is DirectX file. However they are compressed and they are not lzs compressed (maybe a modified version?). Since I don't have any experience in decompressing, I wanted to ask if someone has already worked around this or if it's relatively easy to work on based on success of decompressing other files?

Accessing these files would be the next big leap after we finally got the textures working.

Also on side note (off-topic), I found something interesting from wmx.obj (world map object?) while opening it with NuGraf. NuGraf reported that the password was wrong so maybe it's encrypted?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-25 13:39:13
Completed WIKI page: http://wiki.qhimm.com/view/FF8/FileFormat_X
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-25 15:23:30
I took a0stg105, and HEX'd fun it.

Code: [Select]
#OFFSET IN HEX                                 #DEFINITION
0x48-49                                              Changing this does nothing
0x5C-5D                                              Before map load, there is a cursor that blink once, after that map loads. Sometimes
0x588-58E                                          Completely nothing.
0x5DA-5DB                                          Still nothing
0x5D6-9A5                                        ##CAMERA HERE! - I reversed bytes from end to start by this offset, and camera is fixed no matter what. Also some enemies can be off-screen.

Summary:

Whole code from 000-5F1 is probably the same. I'll check with other maps.

NULL'ing header makes no effect... really... Game doesn't care what it is.

0-23A can be NULL'ified and the game doesn't care. WTF?
Huh...
NULL'ied from 0x0 to 0x5d3 and guess what... NOTHING

EDIT2:
Finally, so te textures are like:

LINE1
0101 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
LINE 2
etc...
It's pallete colored. This is detailed somewhere here in Texture section. So, I nulled from beggining to 0x998 and still no vertex glitches or anything.
I nulled one line covered by those 0101010101, and here it is: (http://pics.tinypic.pl/i/00623/fmiqyeldxh6s.jpg)

EDIT3:
Yea, found something, probably reversed the "pallete" or UV. More like both.  it is 44CE to 4905
(http://images.tinypic.pl/i/00623/zt9b25xwdv51.jpg)

Summary:
File is divided in some parts, where:
Code: [Select]
STAGE 1 - from START to 0x??? - ???
STAGE 2 - from 0x5D6 to 0x9A5 - Camera *THIS NEEDS TO BE NARROWED! Narrowed by 1/2
STAGE 3 - from 0x??? to 0x??? - Vertex data
STAGE 4 - Search for first 0x/10,0x/00,0x/00,0x/00 - Texture
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-27 11:49:30
Okay. The texture is no more than just a TIM file, starting with 10 00 00 00. Thanks to paul and _Tom_ for TIM header infos.




DEPRECATED:
*Updated "summary" post above. I finally found where the texture starts. RGBA pixel format is probably 555, Didn't test it yet, but that's what wiki says here for FF7 textures.

The texture section, clearly starts at repeating 01 01 01... bytes. After each line it has a tendency to drop to small numbers. For example the first one header for top-one pixel line is 178 bytes long, where the next one header for second pixel has 176 as for a0stg105.x

So, to find the texture, and re-export it, or EVEN replace, just find the first appearance of 01 01 01 01 01 01 bytes starting from 0x0 offset, and you should get it in all normal BG's.
See below:
(http://images.tinypic.pl/i/00624/blt1tin6hdmb.jpg)
Title: Re: [FF8] .x battle fields
Post by: Ragna on 2015-01-27 14:14:37
.X files?

In FF7 those are gzip compressed files like BATTLE.X and others in the same folder.
If you could post the first 16 bytes... maybe is the same or similar?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-27 14:21:50
I tried to decode it using GZIP deflate, but it thrown exceptions. (GZIP string decompress and GZIP archive unpacking using built-in .NET System.Compression).
Also tried with RFC1950, this one used Knightshift for saves encoding, I had to write my own software for that, but when tried with FF8 files, it just thrown another exception for bad file.

The header for .X files in every stage file is the same, and the first 16 bytes are:

Code: [Select]
E8 FF BD 27 01 00 02 24 14 00 BF AF 11 00 82 10
The same
Code: [Select]
E8 FF BD 27 are used for Final Fantasy Tactics as in battle file there. That's what I read from someone's "Battle hacking" post.

However, I NULL'ed this, and 2560 (sic!) next bytes, and game doesn't care, nothing changed and everything is 100% functional. So, 2560 (currently, I'm going to nullify next bytes later to see what I get) non-needed data?
Title: Re: [FF8] .x battle fields
Post by: Ragna on 2015-01-27 17:04:10
Ah, I expected to see a
Code: [Select]
1F 8B 08 there in the middle but seems like I was wrong.  :|

Four first bytes are usually just a useless tag for format identification so you should try nulling further bytes in the 8-16 first bytes.
Perhaps there's data like compression type, offsets, or uncompressed file size or something? (that should affect the game...) ???

EDIT: Or maybe the file is not compressed at all? Or only parts if it is a multi-file compressed directory with offsets to files and flags for compressed/not-compressed?
Title: Re: [FF8] .x battle fields
Post by: paul on 2015-01-27 19:24:17
you can just call me paul, not "paulwork" :P

are you interested in hacking world map model format too? looks like you're making good progress with this.

Edit: P.S I would help you out but I don't own a copy of the game.
Title: Re: [FF8] .x battle fields
Post by: Zervox on 2015-01-28 00:04:46
Just wanted to say, even if a file has a .something extension doesn't mean it is the format you found.
Just like some Engines can use .obj doesn't mean it is necessarily wavefront .obj but rather an object in its entirety which could be
name of object
AI module link
Mesh info
Texture info
other engine's object properties for use in game like, stats or similar.
maybe it is keeping records of where in the world it was called from so that a player can be returned to that location.

and in this case .x seems to include other data than what would need to be in a normal directx .x file.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-28 11:37:48
are you interested in hacking world map model format too? looks like you're making good progress with this.

Edit: P.S I would help you out but I don't own a copy of the game.


Sure I am. I still however have no idea if it's just a big 3D Model, or this is a package containing maps, that are loaded when needed in parts. Just like in MMO games.

I could send you some samples with stages and this world.

@Zervox - of course it does. It's not normal DirectX file, also this one contains uncompressed .TIM hardcoded. That file contains camera data. I'm an Unreal Engine developer, and as far as I know OBJ's nor X files does NOT contain textures and camera. Things like that are available to FBX files (Autodesk), but obj has always contained mtl file and refferenced to external texture, so does DirectX file.


UPDATE: Narrowed the camera, looks like the camera X Y Z fixed is somewhere 0x5D5 and 7B8, as I FF'd it and camera was outside of battlefield.
UPDATE2: Uhum... FFVIII finally is going into infinite error loop (No exception, but still something wrong, so it's not going to next stage... God, wish to have a log option to see what it does generate... Looks like I need to copy original file again, and start from beginning knowing where to stop null'ying data. But I think camera is somewhere near. I can smell it.


Look at this:
(http://files.tinypic.pl/i/00624/ud73bm5qol20.jpg)

0x5d4-0x5d7 is responsible for OPENING battle camera. It is possible reverse byte. I'm trying to find how's it going, but every next byte is responsible for X/Y for key in camera animation, so changing one byte can make camera in some places jump, so it's clearly camera key movement edit.
Title: Re: [FF8] .x battle fields
Post by: Kaldarasha on 2015-01-28 12:29:21
Quote
Sure I am. I still however have no idea if it's just a big 3D Model, or this is a package containing maps, that are loaded when needed in parts. Just like in MMO games.

Maybe it would be good to extract the wm from the PSX game if possible and generate out of it a new wm with correct UV coordinates. At last this would be better as fixing the whole thing by hand.
Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-01-29 01:59:22
Maybe it would be good to extract the wm from the PSX game if possible and generate out of it a new wm with correct UV coordinates. At last this would be better as fixing the whole thing by hand.

Yes, mainly because it looks like the walkmesh is doubled over itself in the PC version (Kaldarasha has gone over this many times).  Essentially, if we could just find out the differences between the PC wm and the PSX wm, we should be able to fix the PC wm.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-29 13:56:09
@Updated my first post here with the newest info

GAH! Finally! I found the camera "header", or at least something, that makes the camera go crazy if changed one of the parameter. This pseudo-header is:

Code: [Select]
02 00 08 00 20Whether stage it is, it's always fixed.

Changing third byte from 08 to 07 makes camera freeze at the battle no matter what. Conclusion? Changing this makes the game not detect global camera (probably), so when it does no see 02 00 08 00 20, then the battle camera freeze.

What do we got now?

*Stage file contains normal .TIM texture starting with header
Code: [Select]
01 00 00 00*Camera data starts with header
Code: [Select]
02 00 08 00 20 Does this sound familiar to anyone of you?

EDIT: Yup, tested it on many stages, and looks like changing 08 to 07 will always freeze the camera at the end spot of opening scene.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-30 11:49:08
Click below for video
(http://files.tinypic.pl/i/00625/ierzxo6gtn57.png) (http://youtu.be/L8Zpwu4_QnA)

This video shows many aspects of camera edit, also reverse bytes of UV+vertices probably at the end.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-01-30 11:58:31
I'm not quite sure about this but correct me if i'm wrong. Isn't it a bit hard to analyze the camera settings or any other variables if you don't know if the file is compressed. I mean, can't variables change a bit randomly if it turns out it is compressed? Although I don't see any reason for it to be compressed unless the whole camera scene is included in the file which feels pretty dumb thing to do by a developer.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-30 12:02:49
This file does not look like compressed. Also, the camera data is having the same bytes in some characteristic places in all stages. Now I want just to get X Y Z of vertices, and just search for them inside stage file.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-30 14:33:00
MILESTONE! Updated first post, check it for summary, newest updates, and everything

Found geometry data!

(http://pics.tinypic.pl/i/00625/4i1ti6bz3rgj.jpg)

It is as I can see, on one battlefield, there is more than one or two objects here.
Now, I'm going to reproduce and see how's made, find the starting header offset, see where is the length byte, and try to reproduce it manually from this data part, to see if it's reverse bytes and etc.

Yup. Wiped out one geometry object, that starts with specific header I'm still looking for.
(http://pics.tinypic.pl/i/00625/yl645jmf5kkn.jpg) See? MaKiPL stole the sky! Oh no!

EDIT3:
Sky appears to be the very first geometry object here. Searching now for trees.

EDIT4:
Oops (http://images.tinypic.pl/i/00625/kvcu442q441f.jpg)
Nailed it.

EDIT5:
That's funny
(http://files.tinypic.pl/i/00625/3tqrtjr4gekd.jpg)

EDIT6:
HAHA!
(http://files.tinypic.pl/i/00625/ufmhi93by9g7.png)



Model set information:
Code: [Select]
Rotation rate for forest model REVERSE-BYTES!  0x7282-0x7285 (4 bytes).
EXAMPLE:
00 38 00 02 - is for forest model group, to be in correct way, changing last byte makes rotation go 90o, changing third byte makes rotation go up to:
00-0
FF-45o (probably)
and so on...


Extreme milestone!
I probably found out how single verticle is made, also how they're connected to faces. It needs some testing though.

Single verticle:
Code: [Select]
20 00 35 00 21 00 36 00 54 9c 80 3c 54 68 b2 00 7e 9c 7e 68 80 80 80 2c (24Bytes)

That's what I found is:
0x0 (1B) - Stands for ID, with every verticle it raises up by 1.
0x2 (1B) - Same as above (?)
0x3 (17B) - Not yet researched
0x21 (3B) - It does repeat in every single object
0x24 (1B) - End of object.

Way how they're connected into faces is TODO. Still there's a lot of work.





A debug tip!
FFVIII Steam release produce crash log file .DMP. This one can be really fast opened by Visual Studio, also with detailed exception name. All I got before was "Unknown exception", here in VS you can get detailed exception, also debug software with VS. Gonna check it later, I'm tired ATM.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-01-30 19:36:56
Okay here's something I pulled off.

Found at offset 0x3d90. this byte seems operate with ground mesh somehow
Code: [Select]
01 00 00 00Nullifing the first byte vanishes the ground, not sure if the object itself is removed, parts of it, or the texture.

(http://i.gyazo.com/c229bfb18601cadaed152e75370482cd.png)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-31 12:26:31
Okay. I tried to find some dependence on it, but no luck. Hm, by the way great find Halfer. Looks like there's still a lot to do.

EDIT2: Found again some vertices, this time for ground, it's just a some bytes after your found Halfer, nice job! Still working. If I find the good place I could change the values of specific vertices, to see how it's manipulated, and if it's X Y Z normal.

Also this 01 00 00 00 looks just like a hide option. It's starting parameter for this first geometry object. So I was wrong. The very first model here is ground, then forest and sky the 3rd one.

EDIT3: Hey, it appears, that the next bytes are the face connectors!
EDIT4: Mhm... Wait a second! I got something!
EDIT5: There're FOUR objects in this model.

Every objects starts with specific header:
Code: [Select]
01 00 00 00 08 00 00 00 01 00 00 38 00 02 00 00 03 00 00 00 14 00 00 00 84*Thanks Halfer again, this just opened my eyes for new aspect. Now I'm 90% sure I found every object start.
01 00 00 00 - Changing this either makes whole object ignore to load or crash
08- Changing this crashes level
01 00 - Changing first byte to 0 always hides the mesh, no matter what.
00 38 00 02 - rotation rate, calculated backward, so it should be read by: 02 00 38 00
00 00 03 00 - Currently finding out
and etc.

EDIT6: WAIT... OMG... What a strawberries... ;/ I'm off... It's just too much..
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-01-31 13:23:14
Yeah no problem, I found out also that the next parameters does something to the faces/vertices when bytes are reversed, seems like you also found it so keep us updated if you find the structure! :D
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-01-31 18:57:24
I just tried using some of the headers I found at a0stg105.x, to a0stg012, and... It doesn't work. So, it's compressed? Changing the parameter I had to show/hide objects is working here like a camera freeze... Ugh... I'm losing it... I'm off for today, maybe someone find something out. Could it be really gzip'ed with moved header? I don't know.

EDIT: Nope. I'm just tired and do mistakes. It works the same way as on other stages:
(http://files.tinypic.pl/i/00625/mqqfmnd4kcps.jpg)
Also there's 1981 vertices, so it does look like it only hides the mesh or craps it's UV map. Or maybe it was 3000 vertices before ground dissapearal? Nah, I'll leave it for the next time... Too tired now.

Also thanks to.. rcxrdx, for patch, to display more debug strings for debugger.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-01-31 19:04:54
That may be the case, I hope someone with lot of knowledge in compressions could have a look at this. I did find out that after the header in 0x3d90 the variables are for vertices/faces for the ground part.  However I thought about the structure for a long time but it just didn't make sense. Maybe more experiments would do the work but yeah.... Compression would still be a big limiting factor in cracking the format.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-01 13:30:26
Used Hex2OBJ, to visualize point cloud, as I was refereed to on XentaX forum.


*This ARE in fact vertices starting at this 01 00 00 00 08 ...
0x3D90 - 119 vertices
Object 1:
(http://pics.tinypic.pl/i/00626/fnotdtv3q1es.jpg)

Title: Re: [FF8] .x battle fields
Post by: paul on 2015-02-01 19:38:51
So that must be the ground plane?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-01 20:14:11
Yep. Two other objects are like spheres, but with some details. I'll take a photo of it tomorrow. Still searching for a faces info. I'm having a huge support on Xentax, so I think we'll find it eventually. I'll make you updated :)

Still however no one could identify this data from 0x0 to 0x5D4. On 5D4 is camera starting, but before that? Nothing. Completely nothing. If anyone of us could get the breakpoint when this portion of data is accessed would be awesome, as I'm having almost no experience in process debugging and etc.
Title: Re: [FF8] .x battle fields
Post by: paul on 2015-02-02 16:44:46
If its like FF7 there is probably some script data in there?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-02 17:14:20
That's the only possibility paul. This however doesn't make much sense. Every script is written right to enemy itself, or is scripted in engine. Maybe an animation? Diablos zone has animated background, also eight witches at time compression have deformation animation in it. I'll try to nullify those stages.

Probably found faces, but it's build is a little mess, so the software doesn't read it good. I'll need to manually delete this unwanted data and see what I get. I'm running out of time thou, as I do have a lot of work, so give me two days for update. After faces next step us UV. But I'm just aiming for this base mesh.

Mesh looks a bit more complicated than we though.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-02 20:41:55
Okay, I probably found out how the ground is formed.

(http://i.gyazo.com/6d32c5427bd95158dc28c2c81b224cc6.png)

I highlighted one unmodified section of mesh which seems to represent vertices. Each section at the header start (haven't checked much further) seems to contain 9 vertices which are connected to each other. The numbers colored with orange are nullified vertices and then I added hex number 01 to the possible Z-axis variable. This was the result:

(http://i.gyazo.com/8910e2fdd027b07744fe467bf8a0b25f.png)

It seems to go a little over the ground which is expected with 01 value since it's the first bit to represent the shortest distance in this 3d dimension. Also the XY-axis seems to collide in the middle which is also expected since they are 00 00 both now.

Here's a little clarification how it may work:
Code: [Select]
Offset: 0x3dd8
B3 F3   B3 F3     00 00
B3 F3   CD F7     00 00
B3 F3   E7 FB     00 00
B3 F3   00 00     00 00
B3 F3   1A 04     00 00
B3 F3   34 08     00 00
B3 F3   4E 0C     00 00
B3 F3   68 10     00 00
B3 F3   99 EF     00 00
X-axis, Y-axis,    Z-axis
X and Y axis may differ.

So to sum up it seems that each vertices has 6 bytes reserved where 2 bytes represents axis in XYZ-format. Hope this gives some insight for you MakiPL! :)

EDIT: I tested it with a0stg101.x and this is what I got (sorry for bad angle, maybe we can get better angles when we can alter the camera):
(http://i.gyazo.com/cc00d1bb0aea86ce4d0af9286ee0bd23.png)

This is what i changed: (http://i.gyazo.com/696b56d00f15128ebb28cd63c1bcfa98.png)
Seems to work how i described it. I'm tired now so going to sleep :/
Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-02-02 20:43:21
Yep. Two other objects are like spheres, but with some details. I'll take a photo of it tomorrow. Still searching for a faces info. I'm having a huge support on Xentax, so I think we'll find it eventually. I'll make you updated :)

Still however no one could identify this data from 0x0 to 0x5D4. On 5D4 is camera starting, but before that? Nothing. Completely nothing. If anyone of us could get the breakpoint when this portion of data is accessed would be awesome, as I'm having almost no experience in process debugging and etc.

Could that be the code for a different field?  Are all of the areas the same?  For example - do the planes operate the same way on the 'beach' battle field?  Or on the 'mountain' battle field?  Perhaps those codes are used for other scenes/functionality?  The only battle field I've seen you guys try to do is the forest.  I don't know a thing about the backend, though - so forgive my ignorance of the process :)
Title: Re: [FF8] .x battle fields
Post by: paul on 2015-02-02 21:17:21
Too bad I don't have a copy of FF8 to dig in to the EXE :(

Looks like you're making good progress anyway :)
Title: Re: [FF8] .x battle fields
Post by: Kaldarasha on 2015-02-03 05:04:48
Too bad I don't have a copy of FF8 to dig in to the EXE :(

Looks like you're making good progress anyway :)


You could be a help and try to find out in which freaking format the both event files are packed in the snowboard minigame of FF7. As long the files are unknown I   we can't replace the models there.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-03 13:31:25
Exactly Halfer, vertex is 6 bytes. I pointed it out on XeNTaX forum, but forgot to do it here. :D Thanks to you, we know it's standard X Y Z.

Sometimes the stages has some weird parameters. For a0st105 it's plain square, but, and that's interesting:

-Even if set the vertex to be higher than 00, it does is covered by the forest model, and player/enemy. It's hard to describe, but let's say we just CAN'T make the ground get higher, so example Squall would have to run thru ground to attack the enemy. Why? Because of the rendering options. The other example of rendering is the example of ground highering you made a test on. The ground mesh is combined with some high points in the background, so the rendering option is set to be normal 3D model, not some "weird one".

A few problems are still appearing:

1. Is X Y Z of vertex reverse-bytes? example 00 05 is higher than 05 00?
2. Still finding the UV and face indices. shakotay2 on XeNTaX made a face test with the data he found, and also rejected my idea. However, the test failed, here's his screenshot: (http://images.tinypic.pl/i/00627/vs04efnr1gvd.jpg)
3. Where are the length bytes? Really. For a0stg105 probably, there're 152 vertices, so 152*6 bytes, still can't find that number, yet. How does the game know for how long it needs to read next bytes.

So, the vertices data is after header 01 00 00 08, and for a0stg105 is as I remember ~152. So After:
01 00 00 00     08 00 00 00     01 00 01 00, after this 152*6 bytes is whole ground vertices data.

If you find the data portion, where the texture is going crazy, and it's before .TIM, then you'll find UV, that could be useful also.

Also, a0stg160 looks great for reversing. It's a cube with UV layout + sky. So only two objects, low res texture, less data portion. I'll take a look there by HEX reversing, see if I could find the UV map, and see if I can find the entry point where vertices does start, and when it does end, to see if there's something characteristic. If so, then possibility of writing a software to rip this stages raise drastically.


Also, I cut from the file all three objects, from 01 00 00 00 08... to another this pattern, so I could test only one mesh, and less data I had to look at.

I'll take a closer look at a0stg101, and try using this HEX2OBJ software, to get the vertices of this ground, and see if it fits. I'm at school ATM, so I don't have that exact file, I'll do it at home.

We're making a nice progress here. :)


Quote
maybe we can alter camera

Camera starts from 0x5da (a0stg105.x with header like 02 00 08 00 20 00...). Camera is dynamic, has pre-keyed prologue animation, miss animation, and camera locations for various enemies. It's hard to reverse camera data, if I have to work on random events. Oh...
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-03 13:48:58
Nice, May I ask what programs are you using in your picture and with the analyzing. Would also help me a lot to make faster analyzes.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-03 14:58:25
Here, a HEX2OBJ software: http://forum.xentax.com/viewtopic.php?f=29&t=10894
Also XeNTaX topic about the same thing: http://forum.xentax.com/viewtopic.php?f=16&t=12561

Aaaand... I think I found length byte. Here:
(http://images.tinypic.pl/i/00626/x8oaghcuersm.png).
I badly selected bytes here,  but see the very first 97? It represents 151 in decimal, and this stage when visualized is ~152. I still not have access to my PC, but we should check, if this 97 is repeating in any other stages, then it's not a length byte.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-03 20:05:52
Let's see. The expected length byte is 9B for a0stg101.x, so 155*6=930 bytes from 0x2b5e.
AND!!! YAY!!!!!!!!!!!!!! THAT'S IT! THAT'S IT!

1.Length byte is two bytes. In this case 9B 00 (Big endian). So 9B= 155, and when made a point cloud from it look what an crystal view appeared:

(http://pics.tinypic.pl/i/00627/kgpvbmm4jcfw.jpg). And even bigger awesome news! The verices after 930 bytes ends with series of 00 and then another section also with (I'm ATM sure of 80%) header length appears. It's a much bigger amount of data, and guess what, the length byte is also bigger and made from two bytes. I'll test it as faces.

STRUCTURE:
(http://files.tinypic.pl/i/00627/95ulprpvb7b6.jpg)
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-03 20:33:16
Great find! I wonder why it is showing as ellipse. Also the placement of vertices looks very odd in order to make a proper face with uv's
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-03 21:01:37
This ellipse as I remember is from Tonberry fight zone (So it has to be ellipse) or a0stg101, then it could be weird. But, to make you sure that it's 100% vertices data and it's structure is right here's the cake:

(http://files.tinypic.pl/i/00627/sruvs9nc36sh.jpg)

Straight from Ifrit's level. Also, that
Code: [Select]
01 00 00 00 08 00 thing only appears with FIRST object, on second and third instance you'll have to find this header object, but then pass at least 20 bytes, to find nearest
Code: [Select]
01 00 01 00 ** 00 XX XX XX
Where:
**- Would be length header
XX - Vertices info

This applies also for first instance, but for first one this appears just after this header, for second/third object as I wrote it's divided by some bytes, even 160!
See here:
(http://puu.sh/fr19r/2b3279f6bb.png). Yellow selected area is the bytes, that you have to ommit from 01 00 00 00 08 header, to get to byte length.

Do this ALWAYS!. Do NOT start to get vertices info just after header as I wrote some days ago, but after the length byte, that is ALWAYS after 01 00 01 00 **HERE**.


Also, for the SCRIPT section from start up to camera section (header 02 00 08...). It's almost the same on every map, BUT! The maps having animated texture like Ifrit's level, are having completely different this section. So it's 60% texture animation section. Still someone of us will need to null'ify this section up to texture and see what'll happen to lava. The thing game doesn't care for NULL'yfing (probably wrote it bad) 0x0-0x5D4 on forest level is that, there's nothing to animate on forest level...

Halfer, looks like .X file is breaking upon us. :))

EDIT2: Just checked the point cloud with a better shot of Ifrit's stage. It's 100% the same. Yep, we made it! I'm so happy. There's still two things to do:
1) Face indices
2) UV Map

EDIT3: Hey, remember the "opted battle stage" you posted in my topic of unused VIII's BG? I think I've seen a stage like this there. When we finish, I'll totally get a trip thru every stage in this game! Maybe it's just some simple meshes with details, but it's so exciting to look at it.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-07 13:25:55
Face indices are 24 bytes, and also have byte length, for faces they're REVERSE byte, so big-indian... Stay tuned!

Vertices byte length is two bytes long, and is also read reverse. Just after length, pass Length*6 bytes, and you can meet 00 00 00 00, thing, after that there's another length byte hidden in four bytes portion. Length * 24 bytes. After that, you'll pass to next object. Where's the UV?

I'll keep you updated.

UPDATE 15:50 - Looks like after vertices, there is 6 bytes of zero'es, then there's 4 bytes of:

1.Face indices byte length (2B) Yep, always 20.
2.UV (2B) always 24

Don't know which one is which.
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-07 14:43:32
Maki you are making amazing progress, even though I know very little about hex editing, I tried using reverse bytes to help you find UV/face vertices for a0stg101 do these pictures mean I'm near the UV since you said the texture data goes crazy or is that something else? 

(http://i.imgur.com/YagHbtt.png)

(http://i.imgur.com/w8URPwC.png)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-07 15:07:56
Yagami, this one is interesting, and really, I don't know why is it happening. In your image, the only thing with messed UV is enemy and player, which in fact are completely other files. This is strange. Also, I already found UV, and length byte in my latest post here (ignoring this one). See:

(http://images.tinypic.pl/i/00628/41uqnpe9o2gf.jpg). After I do some testing I'll end up with UV structure. Still, the face indices are our problem. They're 20 bytes per one.
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-07 15:28:00
Ok here is the byte data I reversed to get the top image, gfs,particle effects and spell effects all seem to be affected as well

(http://i.imgur.com/8toe2cU.png)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-07 15:32:54
You reversed portion of face indices data. Still, don't know why altering this destroys the other elements. I'll take a closer look at this after this UV's. Currently, I discovered 50% of UV structure, also it does have Brightness settings in it! So the game doesn't itself have lightning data, but just controls the lightning by UV brightness. Nice one Square!

Update: Face indices are QUAD's probably.

DAT Battle model file and Stage file are having some similiar things. This is the same system geometry is build as in DAT as in .X file.

01 00 00 00 - number of objects (but it's inside object itself, so it's always 1, or not*)
08 00 00 00 - Offset of object start
and offset 0x8 for this is 4 bytes of not Face indices/UV, but triangles/quads.
Of course read backward.


X Y Z is 16Bit Signed int.


Extreme milestone!
I'm going to run an "milestone like" test, if it pass, then the full geometry would be done.
Yup. It's done now. The .X file's geometry section has just been cracked.

Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-02-07 20:27:48
Amazing work!  Such progress on VIII in such a short amount of time.

Now Crestian and I have more incentive to finish the background textures.
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-07 20:29:05
Well done Maki, this will lead to great things in the future, I'm not sure about the dat files source code better off asking the noesis author
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-07 22:13:09
But, before we "dance" still there's some rendering problem
(http://images.tinypic.pl/i/00628/77nhn85zl0k1.jpg)

They are quad, but well... I need to browse old topics about .DAT files, I think they had the same problem.
Ignore the shadowing, it's renderer.
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-07 22:59:26
I will link you this thread

http://forums.qhimm.com/index.php?topic=8130.50

Satoh in there explains why half is missing on reply#60, this was a ps1 game after all something to do with storing data efficiently
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-08 09:42:40
I will link you this thread

http://forums.qhimm.com/index.php?topic=8130.50

Satoh in there explains why half is missing on reply#60, this was a ps1 game after all something to do with storing data efficiently

Oh! And that's what I was searching for. I even browsed this topic, but just missed it. Thanks Yagami. Still can't find a good workaround for this.
Title: Re: [FF8] .x battle fields
Post by: Zervox on 2015-02-08 13:25:13
Would it work to process it twice per quad?
tri1(Vertice1,Vertice2,Vertice3)
tri2(Vertice1,Vertice5,Vertice3)
- one quad
tri3(Vertice4,Vertice5,Vertice6)
tri4(Vertice4,getdata8,Vertice6)

that is I wonder on the edges of the mesh, if there isn't stored an additional vertices but not all three so the last row of that quad would be
3+1 instead of 3+2 offset?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-08 15:43:15
This is dumped OBJ file:
https://www.dropbox.com/s/5zj2j77b3m50m4a/test.zip?dl=0


Data is stored as Quad.
Example:
Code: [Select]
f 1 2 22 23
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-08 17:08:36
Looks to me like the triangles overlap, miscalculation somewhere?

(http://i.imgur.com/zwPgNJW.png)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-08 17:16:48
Looks to me like the triangles overlap, miscalculation somewhere?

(http://i.imgur.com/zwPgNJW.png)

If the blue triangle be mirrored vertically, this should work just fine. I'll take a smaller object, and see which one should have +/- 1 face index.
Maybe every second one needs mirroring? If so, then this could be easy to mod, however if it's more complitaced, then.. well, it's going to be more complicated then. xD
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-08 18:03:48
http://gamedev.stackexchange.com/questions/32254/missing-triangles-in-model

This person had the same issue, turns out the obj loader was the issue
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-08 18:57:00
Hmph, I don't know. It's neither backface culling and rendered "glitch". Maybe if We would write the viewer we'd make a special workaround for this, but...

I imported it into 3DS Max, and the face is just rotated 90o, or the vertex should be mirrored horizontally. Also the QUAD/Face translation:

(http://images.tinypic.pl/i/00629/t67ti8m1c8uf.jpg), (http://files.tinypic.pl/i/00629/npxqonz8unfe.jpg), (http://pics.tinypic.pl/i/00629/003w6jg4o16w.jpg)

After numerous tests I found it. Correct ABCD is:

ABD
ACD

So quad:
Code: [Select]
f 394 395 416 417will be:
Code: [Select]
f 394 395 417
f 394 416 417
Title: Re: [FF8] .x battle fields
Post by: paul on 2015-02-09 12:26:00
Nice work, this means reading mesh without U/V and texture information is fully reversed now?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-09 13:09:10
Nice work, this means reading mesh without U/V and texture information is fully reversed now?


Yup, UV info is stored in quad info, so getting working texture for it is just a little work to do. :)

Just a little update. My Quad>Triangle conversion is lil' bad. Instead of Quad to triangle shakotay2 on Xentax pointed a nice, clear way to fix model just by changing quad order from ABCD to ABDC. Looks fine:
*Ignore missing quad, that's my fault.
(http://files.tinypic.pl/i/00629/dh4xqknqegsl.jpg)

EDIT: Imported to Excel, and changed columns to automate ASAP my work. Here's full model:
(http://files.tinypic.pl/i/00629/ofy1hr0m8axu.jpg).

:)


EDIT2: I was just debugging process, had fun with noclip mod I've made, and after that I just noticed the amazing memory viewer with real-time value editing. So, I could see how's the camera made. If geometry is fully done (only texturing left), then this time let's have some fun with the camera. :) I'm on it.

EDIT3: I can in real-time alter camera, but it's still going to fixed location. Still, need to find that "fixed location" address that makes the camera go everytime there.
Title: Re: [FF8] .x battle fields
Post by: JeMaCheHi on 2015-02-09 19:34:27
Oh man, that thread caught my attention indeed... Finally someone is researching battlefield scenes. I think the .X files has much to do with the scene.out file...
Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-02-10 02:48:38
...here is an example of messed up UV/texture coordinates using Crestian's Railroad texture for Balamb town -

(http://www.13tomidnight.net/FF8/railroadbaduv.png)

Hey guys - I know this is off-topic, but it has to do with the UV/Walkmesh - and since that seems to be a hot topic, I'm posting this here in the hopes that someone knows what's going on with the UV/Walkmesh in the open world areas.  You cracked that .x file in NO time and you're work is really interesting to watch unfold! 
As you can see, the railroad texture doesn't line up with the tiles near it, but the textures are correct.  If you look closely at the front (or back) of the train station, you can see where the textures combine and the town model warps into the upper corner.  You can easily see this on the Balamb Garden texture as well - textures are zoomed too closely and edges are blown out of proportion in places.  Kaldarasha believes that the walkmesh may be 'doubled' over itself? The PSX version does not do this.

Here is to your amazing-ness.  I hope this can be solved - it would help the texture replacement process become so much more worthwhile.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-10 08:57:28
Of course I'm going to work on worldmap next. :)
Didn't touch the walkmesh yet, but as far as I just fast looked on those files is:

Wmrail is set of points. Probably points telling where tracks should go, just like splinemesh in UnrealEngine, but I'm not sure yet.
Wmtex is just a file containing textures only
Wmset is a file containing balamb garden model, train models, probably towns, consist similiar geometry data as levels and characters.
Wmsetus - almost same as above, but does have some differences?
And that biggest 20 MB file. Didn't test it out, but appears it doesn't have any textures in it.

I'll finish this .x file (texture support, and tool for it), then I'll start on worldmap. 
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-10 12:28:47
Great MakiPL, I'm glad that you can understand this so well and are willing to make tools for editing these files! Looking forward to these tools! :D.

P.S. I also wonder if we can someday change the restriction of texture sizes and other limits in the FF8 somehow.
Title: Re: [FF8] .x battle fields
Post by: JeMaCheHi on 2015-02-10 12:33:38
Of course I'm going to work on worldmap next. :)
Didn't touch the walkmesh yet, but as far as I just fast looked on those files is:

Wmrail is set of points. Probably points telling where tracks should go, just like splinemesh in UnrealEngine, but I'm not sure yet.
Wmtex is just a file containing textures only
Wmset is a file containing balamb garden model, train models, probably towns, consist similiar geometry data as levels and characters.
Wmsetus - almost same as above, but does have some differences?
And that biggest 20 MB file. Didn't test it out, but appears it doesn't have any textures in it.

I'll finish this .x file (texture support, and tool for it), then I'll start on worldmap. 

Wow, we'll take your word for it. That will be a really amazing tool indeed.
Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-02-10 18:58:18
Of course I'm going to work on worldmap next. :)
Didn't touch the walkmesh yet, but as far as I just fast looked on those files is:

Wmrail is set of points. Probably points telling where tracks should go, just like splinemesh in UnrealEngine, but I'm not sure yet.
Wmtex is just a file containing textures only
Wmset is a file containing balamb garden model, train models, probably towns, consist similiar geometry data as levels and characters.
Wmsetus - almost same as above, but does have some differences?
And that biggest 20 MB file. Didn't test it out, but appears it doesn't have any textures in it.

I'll finish this .x file (texture support, and tool for it), then I'll start on worldmap. 

You are amazing. :*)  I've upscaled the entire worldmap from the original textures and inserted it using Tonberry - but with this news, I'm going to continue my full worldmap texture replacement pack.  Currently, I've only done Balamb justice and no one has done anything to the towns because they are the most common objects to have messed up coordinates. 
Thank you!!
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-12 21:45:23
Just started writing that tool. God, that's so time consuming. My code is a total mess, but I do learnt some important things like how to deal with padding, how to read model and etc. Paul wrote, he'd help me with this tool if it'd be on QGears. :)

I already wrote some info dumpers for these stage models. I'll release one. It's no more than a just tool that say's where script, texture, camera and geometry sections are, it's length, vertices count, quad location and quad count. Only for first object. Also can rip .TIM texture.

https://www.dropbox.com/s/atp478d41trqk20/StageDump.zip?dl=0 (source included)

There's also another one, but it's still not fully working. Just give me a couple days, and we make it. :)
Thanks!
Title: Re: [FF8] .x battle fields
Post by: paul on 2015-02-12 22:43:42
Chrome thinks your zip is malware and won't let me save it.
Title: Re: [FF8] .x battle fields
Post by: Covarr on 2015-02-13 02:07:39
Chrome thinks your zip is malware and won't let me save it.

Go into the downloads window (Ctrl+J), find the download, and click "recover malicious file". You can save it from there, just not from the normal download bar.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-13 21:31:46
@UP - Yup, browsers automatically scans what's inside .ZIP file, and it sees it's .EXE. There's totally no malware inside it, but some antivirus softwares can just report is as "potentially risky". It's by the way just a stupid header dumper, that's all.

Getting back to World map. Wmrail is just some crap file. It does NOT contain the road/track points. It does contain some hardlinked path's to FFVIII work exe. Also, to prove, the roads and tracks are in fact in wmset.obj, here's the proof:
(http://images.tinypic.pl/i/00631/27rjwbsjohrx.jpg)(http://files.tinypic.pl/i/00631/uniy4deawk99.jpg)
Also, I hacked the camera. Finally, we can see that the world map is not loaded fully, but only it's part that are set to be visible. Researching 30 MB file is still painful. It has 16 bytes triangles in it. (Same as characters/enemies, for battle stages it's 20 bytes for triangles).
(http://files.tinypic.pl/i/00631/9br4vidzqzef.jpg)


@Getting back to Battle stages - I'm researching camera now. Debugger is doing the job much faster than normal HEX reversing.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-14 07:22:53
Wow cool! Especially with the camera shot!

Do the world map files contain the same headers as other files? I wonder if the rendering settings are fixed in the executable or maybe it's a setting in wmx.obj?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-15 15:32:17

Do the world map files contain the same headers as other files?

Unfortunately, they not. BUT! They contain some weird:
AKAO

Also, ran my info dump test, to see if it does contain some data as stage had. Nor script, camera, geometry data was found.
I think this wmx.obj is an archive.

Oh, going back to stages, here's the cake:
(http://files.tinypic.pl/i/00632/rer7ff0y45f0.png) ~350 poly. This is Tomb of unknown king level.
See this triangle holes? It's because it contained triangles, and triangles wing order is a thing I can research in minutes. ATM it's neither ABC nor ACB. So, there's like 9 possibilities to try. :) For quad it was ABCD>ABDC.
Forget it. I just wrongly calculated the triangles (I put the triangles manually). This should be uint16, instead I made it normal int. It works now.


EDIT:
Oh, forgot to wrote. I debugged battle camera today. After 30 minutes I could alter both camera rotation (signed 16 bit), its "skew". Even force the camera to move from orthographical image, so I could just look at "2D plane with moving texture" from side. Still I can't find X Y Z of camera in World.


EDIT2:
I am having hard time with UV's. Here's so far:

24 bytes quad:
Code: [Select]
uint16 X;
uint16 Y;
uint16 Z;
8 bytes of faces

Left 16 bytes:
Code: [Select]
Sample:
60 21 40 3c 40 21 b2 00 80 01 40 01 64 64 64 2c
Probably:
UU UU OP IX IX UU UU XX UU UU UU UU AM1 AM2 AM3 IX
Where:
UU - U or V of texture
OP - opacity sbyte/char (?)
IX - Texture ID, like I don't know...
XX - changing makes the texture go away?

AM:
AM1 - R (red) byte
AM2 - G (green) byte
AM3 - B (blue) byte

Yes, the texture can be colorized just how you want. :)
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-15 18:42:46
Nice progress being made, Vehek posted some great info for wmset.obj and wmsetus.obj
in here for the world map if you haven't read it.
http://forums.qhimm.com/index.php?topic=13799.0

I think the majority of the world map geometry is all stored in the big file wmx.obj

Reverse bytes made this happen

(http://i.imgur.com/NB0Nep0.png)

Problem is the file is pretty big, and you have to ride the ragnarok around whole map the spot differences.


Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-15 18:59:09
Nice progress being made, Vehek posted some great info for wmset.obj and wmsetus.obj
in here for the world map if you haven't read it.
http://forums.qhimm.com/index.php?topic=13799.0

I think the majority of the world map geometry is all stored in the big file wmx.obj
Reverse bytes made this happen

(http://i.imgur.com/NB0Nep0.png)

Problem is the file is pretty big, and you have to ride the ragnarok around whole map the spot differences.




Thanks, that sure is really much info. :)
If he found the model offset and how it corresponds with texture, then I can examine model itself.
Yagami, could you write which offset was that? That would help me much. Thanks! :)
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-15 19:22:05
here is the bytes I reversed I will keep trying till I affect the towns

(http://i.imgur.com/LH6hp9D.png)
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-16 09:29:31
Okay, I liked to jump a bit for wmx.obj and what i found out is that this file is containing the sea quads of the world:

There seems to be a header starting with 20 19 01 00 , and nullifying every corresponding variables it gave the following results.

(http://i.gyazo.com/871d367ec05cef5b4f335bc98be813f1.png)
(http://i.gyazo.com/1eeff0edb0486a59c23f6643fee43af9.png)
Here you can see how to sea is formed from big quads.
EDIT: Also worth to mention that I wasn't able to pass those empty blocks with ragnarok meaning that there is some sort of collision when land (or sea) is removed

That's interesting yagami light. I reversed a big chunk of bytes from that offset and it did very odd stuff following hard lock. Although the ff8.exe seemed to eat my CPU while it was freezed so I don't know what I did wrong :D

Also I would appreciate if MakiPL could say how you managed to hack that camera like that! Would really help a lot! :D
Title: Re: [FF8] .x battle fields
Post by: LeonhartGR on 2015-02-16 09:32:40
Awesome progress guys! Keep it up!
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-16 11:33:06
Okay, I liked to jump a bit for wmx.obj and what i found out is that this file is containing the sea quads of the world:

There seems to be a header starting with 20 19 01 00 , and nullifying every corresponding variables it gave the following results.


Here you can see how to sea is formed from big quads.
EDIT: Also worth to mention that I wasn't able to pass those empty blocks with ragnarok meaning that there is some sort of collision when land (or sea) is removed

That's interesting yagami light. I reversed a big chunk of bytes from that offset and it did very odd stuff following hard lock. Although the ff8.exe seemed to eat my CPU while it was freezed so I don't know what I did wrong :D

Also I would appreciate if MakiPL could say how you managed to hack that camera like that! Would really help a lot! :D

Those big quads are actually smaller quads combined see here

(http://i.imgur.com/xgMOOkb.png)

the engine seems to run slow if you modify even a small bit of the wmx file, I've had times when the vertex got moved high up in the sky and moving near it caused ragnarok to fly high up going crazy till you moved away, and reverse byting too much leads to ff8 not responding when you fly near the affected area, just something you have to be careful of.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-16 11:40:14
I see, anyway they seem to be "unmodified" particles meaning that every quad is similiar thus the effect seen in first image. The reason why there is still sea left in my screens means that vertice group is modified by landscape and has a different variables in place of 20 19 01 00. That may be a count or reference to something.
Title: Re: [FF8] .x battle fields
Post by: Kaldarasha on 2015-02-16 12:41:13
Now where I see the wire it looks like that they have baked the world map and the objects together. That might be the reason why the UV for the tile don't work anymore. I assume that on PSX objects (roads, cities, etc.) are placed on the world map in realtime. Maybe they couldn't done it for PC and simply baked everything together.

Seems like we need to extract the wm from the PSX version and fix the PC rendering. Hopefully this is doable.  :?
Title: Re: [FF8] .x battle fields
Post by: Yagami Light 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.
Title: Re: [FF8] .x battle fields
Post by: paul 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.
Title: Re: [FF8] .x battle fields
Post by: Maki 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:
(http://pics.tinypic.pl/i/00626/du223enf766f.png), and ground square with this texture associated as-is. :) I just reminded it.
Title: Re: [FF8] .x battle fields
Post by: Halfer 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 :/
Title: Re: [FF8] .x battle fields
Post by: Maki 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.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-18 19:27:51
Phew... UV cracked (EDIT: Nah, still working):
(http://files.tinypic.pl/i/00633/wugou6crgvb6.jpg)

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... (http://images.tinypic.pl/i/00633/csozg89fihmc.jpg)
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:
(http://images.tinypic.pl/i/00633/if6jh2osf8r5.jpg)

It is full dump, with triangles also. Ignore texture. 406 polys.
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-02-18 21:14:58
Wow! very nice progress, looking forward to your works! :D
Title: Re: [FF8] .x battle fields
Post by: LeonhartGR on 2015-02-18 22:08:21
Now that's what we call god! The creator! XD
Title: Re: [FF8] .x battle fields
Post by: halkun 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....
Title: Re: [FF8] .x battle fields
Post by: Yagami Light 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

(http://i.imgur.com/FIXc87X.png)

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
Title: Re: [FF8] .x battle fields
Post by: Maki 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. :)

(http://images.tinypic.pl/i/00634/jakf2i4gsv4v.jpg)

UPDATE:
Thanks to source of this FF9 viewer I noticed, that the Y of texture needs to be 1.0f (V1/255).
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-21 18:21:34
Done!
(http://pics.tinypic.pl/i/00634/q81cis3tbbf1.jpg)

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).
Title: Re: [FF8] .x battle fields
Post by: Yagami Light 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.
Title: Re: [FF8] .x battle fields
Post by: Maki 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:
(http://files.tinypic.pl/i/00635/xiwtuapos7k6.jpg)
I'm still missing some calculations.

My current source code for vt:
http://pastebin.com/uHABUT2X
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-02-23 15:37:21
That mesh is for the ground brick texture I think, use this texture and see what happens.

(http://i.imgur.com/BXBYNvc.png)
Title: Re: [FF8] .x battle fields
Post by: Maki 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.
Title: Re: [FF8] .x battle fields
Post by: Halfer 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.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-25 14:43:22
Added + 0.3f to U, and:

(http://pics.tinypic.pl/i/00636/lik64hdf9bo3.jpg)

Ehh.. Still.
Title: Re: [FF8] .x battle fields
Post by: Halfer 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
Title: Re: [FF8] .x battle fields
Post by: Zervox 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.
Title: Re: [FF8] .x battle fields
Post by: Maki 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:
(http://pics.tinypic.pl/i/00636/a1aja1mka0ay.jpg)

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.
Title: Re: [FF8] .x battle fields
Post by: Zervox 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, :)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-02-26 15:00:50
Multi-mesh test with Byte/768 + 0.3333f:

(http://files.tinypic.pl/i/00636/g0dwnfctxzl6.jpg)
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.
Title: Re: [FF8] .x battle fields
Post by: Maki 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:

(http://images.tinypic.pl/i/00637/tuiw21ta1bw8.jpg)
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.
Title: Re: [FF8] .x battle fields
Post by: Maki 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.

(http://images.tinypic.pl/i/00637/zqdbfympucwa.jpg)

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. :)
Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-02-28 21:48:04
This is from FFTactics research wiki:
That makes sense finally.

(http://images.tinypic.pl/i/00637/zqdbfympucwa.jpg)

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. :)
In the texture modding process, I have run across a lot of different .TEX and .TIM files.  I wish I could show screenshots, but my HDD died with all of my old file dumps and texture viewers.

Many of the .TIM files are set up in different segments of 128x256 blocks.  Other textures like the worldmap textures are 256x256 images (256*256 for low resolution, but there are 4x as many tiles), but the game is only pulling 64px textures (32px for low res) from each section of the texture, for 16 textures total. 
The backgrounds (and field background files) seem to be set up in ways that the .tex/.tim file far exceeds the resolution of the screen, just like the Triple Triad text .TIM, which is 768x216 texture, which only ever pulls up 1/3 of a page, or a max 256*256 texture.  The Triple Triad .TIM card texture file is a ridiculous 1792*256, which the game accesses in 14 chunks of 128*256, I believe. (could be 7 pieces of 256*256, but I don't think so).

So, in essence, the b1, b2, b3 pointers look like they are pointing to the first, second, third, etc. 128 byte sections of a larger texture? Or are they defining the entire size of the texture?  If they are pointers to a larger texture, b5 would be the part of the texture from 512-640px, but if they defined the entire texture width, b5 would be 128*5=640, or 5 pages at 128*256px each.

I hope any of that information helps.
Title: Re: [FF8] .x battle fields
Post by: Aali on 2015-03-01 13:20:20
You may want to read this document: http://psx.rules.org/gpu.txt (http://psx.rules.org/gpu.txt)

It's reasonable to assume that the file format is pretty much a 1:1 mapping of whats sent to the GPU.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-01 13:39:20
You may want to read this document: http://psx.rules.org/gpu.txt (http://psx.rules.org/gpu.txt)

It's reasonable to assume that the file format is pretty much a 1:1 mapping of whats sent to the GPU.

128px for 8 bit CLUT. Yep. Thanks. Adding Texture page thing to my automation algorithm is going to be super easy. I'll test this when I'll be free. I'm ill atm and I don't move from bed. :/
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-02 14:38:35
Adding Texture page thing to my automation algorithm is going to be super easy.

Here, working VT calculation algorithm with this texture page thing.
http://pastebin.com/bqbXRBxN

Code: [Select]
float UU1 = (float)U1 / (float)newSzerU + ((float)TPageINT/newSzerU);

Where:
newSzerU = TIM Texture hardcoded width * 2
TPageINT:
Code: [Select]
                //Get Bit
                string StrByte = OPN[currRUN + 6].ToString("X2"); //For example "B2" or "B4".
                StrByte = "0" + StrByte.Substring(1); //Just to make sure. I don't really know if it's always 'B'.
                Byte TPage = Byte.Parse(StrByte); //Parse to Byte only the second digit/char of this B2/B4/B0 thing, so we get only TPage number.
                int TPageINT = TPage * 128; //For 8 bit TIM's TPage is 128 sized.

Tested, working 100%
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-03-02 16:39:18
That is very cool! Are you planning on making an application for tools release once the whole file is cracked? Also this should be documented to qhimm wiki page also.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-02 16:52:35
Thanks. :) I've seen your thread, nice job, really! Just need to end things here and I'm coming to help you with world. :D

Also this should be documented to qhimm wiki page also.

I already did, but just a second after the whole wiki just crashed and atm is generating loads of warnings. Qhimm wiki is broken. :/

Also for that tool, yes. I'm still trying, already made a few drafts, and I'm going to be ready soon for coding full viewer/exporter. Thanks for all your support! :)
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-03 08:00:06
Maky PL I take this opportunity to tell you (and you all) if you could help us by extracting or giving us a tool, or directly, have the models of the worldmap (like car, lagunarock etc) battle map, and if someone can extract some secondary object like the shiva's stalactite, Siren's Rock etc.
We're working on 2 big project and we really need "That models" as a reference and for study that on the details...
Please help us...we're asking that for almost 2 years...but no one help =(

Here just "A Single work" (almost finished.....p.s. don't look the textures...i'm working on it, thats are random, just for take a preview example...):
(http://i59.tinypic.com/fm3lnr.png)
(https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-xpf1/v/t1.0-9/10410862_326020194274332_4076940850519179962_n.jpg?oh=da9d2e5876c44e254f95a2afd99c9ab2&oe=5573473D&__gda__=1433726551_70674995e88dabd4cc96fc94fc2e8934)
(https://fbcdn-sphotos-b-a.akamaihd.net/hphotos-ak-xap1/v/t1.0-9/10430856_326020000941018_6237546392628284847_n.jpg?oh=17f2bf034fa461fca801340f99ead639&oe=55945C6A&__gda__=1434269366_8b998b0b40876ac47798afda1f05168b)

We have did also other things like the ballroom, the student rooms etc....but we really need these models....=( 
(sorry for the english but i'm italian :P)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-03 09:17:08
Someone (probably you) on FFVIII is my soul group on FB posted this and I commented. :) This looks promising.

I'm working on the tool, but I can do manually rip some models as you wish. (textured of course). Just tell me which stage model you need.

World map model is at the moment not researched yet. Halfer has made a great progress on it here: http://forums.qhimm.com/index.php?topic=15979.0

For GF's levels. I completely have no idea where is that located. Probably m_* files in battle.fs. I've seen there a diablos summon textures, but didn't take a look at the file structure. Maybe there is indeed a model there. I don't know. Stages first, then world map, after this maybe GF's.
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-03 11:51:31
<3
As i said in first we need, (if possible of course),with the help of halfer every vehicles of the world map and also the 2 flying garden (but it can be done later or in future) , and as stage battle, we need in this moment that one with norg.
(for others places/things i have to speak with my work colleague).

For the other model (stalactite-rocks etc) they can be found on FF8.exe maybe later i can give you some informations/scripts so you can check accurately yourself....anyway there is no hurry on that.

If you have facebook please add me on my personal profile here the link:
https://www.facebook.com/Softtm17

Thanks in advanced for your kindness...really! You don't know the great help you're giving to us.
Very very very thanks!
Take your time with no hurry and thanks again!
Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-03-03 20:19:39
Here is the documentation for world map vehicles http://forums.qhimm.com/index.php?topic=13799.msg193791#msg193791

I'm not sure if there's every model but let me know if/when you export them how they look :). I'm pretty busy this week so I will get back on FF8 on next week, maybe this weekend.

That FF8 movie project looks very nice, looking forward to it!
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-06 07:30:30
Updated WIKI page:
http://wiki.qhimm.com/view/FF8/FileFormat_X
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-08 13:32:01
and as stage battle, we need in this moment that one with norg.

Here you are. I dumped whole stage. Sorry for 1t.obj has no UV mapping, but it's triangle, and I'm going in the next hour to my GF so I don't have a time to code software to calc triangles. But I will do. I'll leave here a note for triangle start index and it's count, so I can upload the mapped part later:

t=14 (st= 0x187c)

Here's the model:
One stitched together, and one with parts as they were dumped.

(http://images.tinypic.pl/i/00641/prvwi2qgofy4.jpg)
For norg battle, the tube in center is hidden.

DL link: https://www.dropbox.com/s/77u5sglz4e9evtw/norg%20Stage.7z?dl=0

BTW> This is only three objects... Probably the smalllest geometry I was working on. There's average 10-12 objects in a stage. *counting triangles as a indepedent object. Here, only four (Two quads only, and one triangle+quad)
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-16 13:56:26
Don't worry about the triangle issue, it's not a problem for me, i can re-made the entire texture of the stage if i want :P
Anyway great Progress & Work, you're awesome, keep it up, and thanks for this stage.
I'll let you update if we need something else.
(I'm always here watching you u,u)
Title: Re: [FF8] .x battle fields
Post by: Kaldarasha on 2015-03-17 06:10:28
(I'm always here watching you u,u)

https://www.youtube.com/watch?v=OMOGaugKpzs&t=28
 :-P
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-17 10:04:56
Kaldarasha, congratulations on your 1337 post. :)

Back to topic. I'm extremely busy this week. So I was before . I'll return to work on software somewhere 21 or 22 of March.
There's still a camera to research.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-17 21:55:22
Hi!

First thing to say: thanks for this!

I've been waiting for some news about these files for a long time  ;D

I've been working on a ff8 project and this stuffs are really important to me (I always need references for my 3D models).

I saw your files about Norg's battle stage and I already spent some time on it.

(http://s17.postimg.org/pggma5jpr/norg.jpg)

(I manually added Norg's Pod for fun  :-D)

Actually I'm pretty sure there is something missing..

The "floor" circle plane is supposed to have an "height" and not be just a plane.
the "height" is supposed to be textured whith the top right piece of the texture.

The result is supposed to be something like this (I manually created it):

(http://s15.postimg.org/fxenb878b/norg2.jpg)

If you look at this video:
https://www.youtube.com/watch?v=Ad80BW1__Cc
You can see it in the bottom of the screen at 1:47.


Hope this can help somehow..

P.S.

There are a few "battle arenas" that could be useful for my project and I'd be really thankful if you can help me to extract them  :)

P.P.S

Sry for my bad english  :P

Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-21 14:36:41
Umm... Can't see anything at 1:47.
I checked it with my newest converter, and it does detect only three models.

(http://files.tinypic.pl/i/00646/s8iy5xviwsjr.jpg)

I'm 70% sure it IS just a plane. However, there's still on my TODO list to hack battle camera, after that I'll see for 100% if it's really plane or not in-game.

Also I today (with finally free time) started from the beginning writting the FF8 stage to OBJ converter. I think whole thing should be done probably tomorrow. I wrote a completely new algorithm, used some of my previous codes and just passed thru the thing that I had the most problem with. Still there's much to code, but I completed the hardest thing. :)

BTW> I'll edit this post to put an updated VT calc code with triangles support.

EDIT:
Here. Updated script for triangle models texture calculation:
http://pastebin.com/wUxpPYuy
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-21 15:26:56
Umm... Can't see anything at 1:47.
I checked it with my newest converter, and it does detect only three models.


I'm 70% sure it IS just a plane. However, there's still on my TODO list to hack battle camera, after that I'll see for 100% if it's really plane or not in-game.

Also I today (with finally free time) started from the beginning writting the FF8 stage to OBJ converter. I think whole thing should be done probably tomorrow. I wrote a completely new algorithm, used some of my previous codes and just passed thru the thing that I had the most problem with. Still there's much to code, but I completed the hardest thing. :)

BTW> I'll edit this post to put an updated VT calc code with triangles support.

If you look at the bottom of the video you should see a little piece of the model I manually added in the second screen :)

Anyway camera hack should confirm if there is something missing or not.

Can't wait for that converter anyway!

Since I can't help whith code I'm doing something probably useless but maybe handy..

Here's a not yet complete(30%) list of the battle .x files whith corresponding area:

a0stg000.x  Balamb Garden Quad
a0stg001.x  Dollet Bridge
a0stg002.x  Dollet Trasmission Tower path
a0stg003.x  Dollet Transmission Tower (Top)
a0stg004.x  Dollet Transmission Tower (Elevator)
a0stg005.x  Dollet Transmission Tower (Elevator 2 ?)
a0stg006.x  Dollet City ? (Spice Spice Shop)
a0stg007.x  Balamb Garden entrance gate
a0stg008.x  Balamb Garden 1st Floor Hall
a0stg009.x  Balamb Garden 2nd Floor Corridor
a0stg010.x  Balamb Garden(Flyng Form) Quad
a0stg011.x  Balamb Garden Outer Corridor
a0stg012.x  Balamb Garden Training Center (elevator zone)
a0stg013.x  Balamb Garden Norg's Floor
a0stg014.x  Balamb Garden Underground Levels (Tube)
a0stg015.x  Balamb Garden Underground levels (falling ladder zone?)
a0stg016.x  Balamb Garden Underground levels (OilBoil Zone?)
a0stg017.x  Timber Pub Area
a0stg018.x  Timber Maniacs square
a0stg019.x  Train (Deling Presidential Vagon)
a0stg020.x  Deling City Sewers
a0stg021.x  Deling City (Caraway Residence secret exit path?)
a0stg022.x  Balamb Garden Class Room
a0stg023.x  Galbadia Garden Corridor ?
a0stg024.x  Galbadia Garden Corridor 2 ?
a0stg025.x  Galbadia Missile Base
a0stg026.x  Deep Sea Research Center (Entrance?)
a0stg027.x  Balamb Town (Balamb Hotel road)
a0stg028.x  Balamb Town (Balamb Hotel Hall)
a0stg029.x  ? Diabolous Lair?
a0stg030.x  Fire Cavern (path)
a0stg031.x  Fire Cavern (Ifrit Lair)
a0stg032.x  Galbadia Garden Hall
a0stg033.x  Galbadia Garden Auditorium (Edea's battle?)
a0stg034.x  Galbadia Garden Auditorium 2? (Edea's battle?)
a0stg035.x  Galbadia Garden Corridor
a0stg036.x  Galbadia Garden (Ice Hockey Field)
a0stg037.x  ?? Some broken wall place..Ultimecia Castle?
a0stg038.x  StarField?
a0stg039.x  Desert Prison? (elevator?)
a0stg040.x  Desert Prison? (Floor?)
a0stg041.x  Eshtar City (road)
a0stg042.x  Desert Prison? (Top?)
a0stg043.x  Eshtar City (road2 ?)
a0stg044.x  Missile Base? Hangar?
a0stg045.x  Missile Base? Hangar2?
a0stg046.x  Missile Base? Control room?
a0stg047.x  Winhill Village main square
a0stg048.x  Tomb of the Unknown King (Corridor)?
a0stg049.x  Eshtar City (road 3 ?)
a0stg050.x  Tomb of the Unknown King (Boss Fight room)?
a0stg051.x  Fisherman Horizon (Road)
a0stg052.x  Fisherman Horizon (Train Station Square)
a0stg053.x  Desert Prison? (Floor?)
a0stg054.x  Salt Lake?
a0stg055.x  Ultima Weapon Stage
a0stg056.x  Salt Lake 2?
a0stg057.x  Eshtar Road
a0stg058.x  Ultimecia's Castle (bridge)
a0stg059.x  Eshtar (square?)
a0stg060.x  Eshtar (?)
a0stg061.x  Eshtar (cave?)
a0stg062.x  Eshtar (cave2?)
a0stg063.x  Eshtar (Centra excavation site)
a0stg064.x  Eshtar (Centra excavation site)
a0stg065.x  Eshtar (Centra excavation site)
a0stg066.x  Eshtar (Centra excavation site)
a0stg067.x  Lunatic Pandora?
a0stg068.x  Lunatic Pandora
a0stg069.x  Lunatic Pandora(Adel?)
a0stg070.x  (Centra excavation site)
a0stg071.x  (Centra excavation site)
a0stg072.x  (Centra excavation site)
a0stg073.x  (Centra excavation site)
a0stg074.x  A wood whith ruins view?
a0stg075.x  (Centra excavation site)
a0stg076.x  Centra Ruins (Lower Level)
a0stg077.x  Centra Ruins (Tower Level)
a0stg078.x  Centra Ruins (Tower Level)
a0stg079.x  Centra Ruins (Odin Room)
a0stg080.x  Centra excavation site (Entrance)
a0stg081.x  Trabia Canyon
a0stg082.x  Ragnarok?
a0stg083.x  Ragnarok?
a0stg084.x  ? Diabolous Lair?
a0stg085.x  Deep Sea Research Center (Entrance)
a0stg086.x  Deep Sea Research Center
a0stg087.x  Deep Sea Research Center
a0stg088.x  Deep Sea Research Center
a0stg089.x  Deep Sea Research Center
a0stg090.x  Deep Sea Research Center
a0stg091.x  Deep Sea Research Center
a0stg092.x  ? ?
a0stg093.x  ? Eshtar shops?
a0stg094.x  Tear's Point
a0stg095.x  Eshtar
a0stg096.x  Ultimecia's Castle
a0stg097.x  Ultimecia's Castle
a0stg098.x  Ultimecia's Castle
a0stg099.x  Ultimecia's Castle
a0stg100.x  Deling City (Edea's Room)
a0stg101.x  Balamb Plains?
a0stg102.x  Desert Canyon?
a0stg103.x  Desert?
a0stg104.x  Snow-Covered Plains? (Trabia Region?)
a0stg105.x  Wood
a0stg106.x  Snow-Covered Wood
a0stg107.x  Balamb Isle? (Beach zone?)
a0stg108.x  ?Snow Beach?
a0stg109.x  Eshtar City
a0stg110.x  Eshtar City
a0stg111.x  Generic Landscape? Dirt Ground
a0stg112.x  Generic Landscape? Grass Ground
a0stg113.x  Generic Landscape? Dirt Ground
a0stg114.x  Generic Landscape? Snow Covered Mountains
a0stg115.x  Eshtar City
a0stg116.x  Eshtar City
a0stg117.x  Generic Landscape?
a0stg118.x  Eshtar City
a0stg119.x  Eshtar City
a0stg120.x  Ultimecia's Castle
a0stg121.x  Ultimecia's Castle
a0stg122.x  Ultimecia's Castle
a0stg123.x  Ultimecia's Castle
a0stg124.x  Ultimecia's Castle
a0stg125.x  Ultimecia's Castle
a0stg126.x  Ultimecia's Castle
a0stg127.x  Ultimecia's Castle
a0stg128.x  Generic Landscape?
a0stg129.x  Generic Landscape?
a0stg130.x  Generic Landscape?
a0stg131.x  Generic Landscape?
a0stg132.x  Generic Landscape?
a0stg133.x  Generic Landscape?
a0stg134.x  Eshtar City
a0stg135.x  Generic Landscape?
a0stg136.x  Generic Landscape? (Beach at night?)
a0stg137.x  Deling City (Edea's Room)
a0stg138.x  Ultimecia's Castle
a0stg139.x  Ultimecia's Castle (Tiamat)
a0stg140.x  Ultimecia's Castle
a0stg141.x  Ultimecia's Castle
a0stg142.x  Ultimecia's Castle
a0stg143.x  Eshtar City
a0stg144.x  Lunatic Pandora Lab
a0stg145.x  Lunatic Pandora Lab
a0stg146.x  Edea's Parade Vehicle
a0stg147.x  Tomb of the Unknown King (Boss Fight room)?
a0stg148.x  Desert Prison?
a0stg149.x  Galbadian something?
a0stg150.x  Generic Landscape?
a0stg151.x  Generic Landscape?
a0stg152.x  Balamb Garden (External Corridor?)
a0stg153.x  Balamb Garden (External Corridor?)
a0stg154.x  Balamb Garden (External Corridor?)
a0stg155.x  Balamb Garden (External Corridor?)
a0stg156.x  Balamb Garden (External Corridor?)
a0stg157.x  Generic Landscape?
a0stg158.x  Generic Landscape?
a0stg159.x  Generic Landscape?
a0stg160.x  Test Environment? (UV tile texture)
a0stg161.x  Generic Landscape?
a0stg162.x  Generic Landscape?


Many need to be confirmed.. let me know if someone have correction for it.
I'll update the list when I'll check remaining Files  :-D
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-22 15:43:09
(http://i.imgur.com/ODc1zC8.jpg?1)

My vertex calculation algorithm is 100% done. What's now? Copy code from my VT calulator 1.3a and progress thru unsigned face indices. It's like... Expect converter TODAY. Just give me an hour or two to finish things.

UPDATE: Software now does produce correct vertex + vertex texture coordinates (however only for quads ATM). Now, the face indices and VT match and.... we're done! :)

UPDATE2: Works like charm, but... It does produce the glitchy triangle model. I'm missing something. The funny thing is I was doing everything from memory, so probably I messed up something. Sec...

UPDATE3: Yup... Forgot about ABDC.

OK! Software now rips quad models! :)

It does miss triangle loop. Need a break and I'll get to it. Also it lacks of usemtl and material assign. Sec...

There's still some issues with triangles. Needs more testing.

Updated triangles. Now the geometry works, but UV is messed up... mhm. Need to browse thru my notes to see what was the UV order for triangle polygon.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-22 17:37:41
very nice :D

waiting for updates!

P.S.

I updated the list of the .x files now it's almost complete
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-22 17:50:31
Kaspar01, you we're right. I just ran a test on Norg's level and indeed. It did find this ground extension. Not only this. I think I'm ready to release this converter. It could be buggy and at first time weird, but it works. :) Give me a sec and I update this post.

Well, +1 for this software. :) My new extended search algorithm found these two objects and I didn't manually.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-22 18:31:59
Kaspar01, you we're right. I just ran a test on Norg's level and indeed. It did find this ground extension. Not only this. I think I'm ready to release this converter. It could be buggy and at first time weird, but it works. :) Give me a sec and I update this post.

Well, +1 for this software. :) My new extended search algorithm found these two objects and I didn't manually.

Aha I knew it! :D

Can't wait to try it and give you a feedback :)

Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-22 19:01:34
Here it is:

Final Fantasy VIII battle stage .X to OBJ converter - deprecated- see next page

(http://i.imgur.com/gni6R2E.jpg?1)

You'll need .NET Framework 4.5.1 !

Instructions inside!

Known bugs:
-Bad UV calculation for triangles
-Probably if you click resolve texture before opening any stage it will crash

TODO:
-Change rip triangle/quad button behaviour (disable if not any available)
-Limit those annoying MessageBox'es.
-Fix triangles UV calc.
-Auto texture size resolve after open
-Better MTL generation/ to make this faster
-Button for loop thru all models
-Throw away this message box in extended mode

BTW> 700 lines of code... (not counting designer code) Phew, I'm tired.
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-22 19:21:32
Fu***ng Awesome. (but i prefer selphie or rinoa XD)
Great work!

Edit.
I've tried it now...when i rip tris model, it's all ok,3ds max can import it and i can see it.
But when i try to export quads models, well in 3ds max i got an error:

(http://i60.tinypic.com/29z3no8.jpg)

If i try to change some option when i'm going to import it (for example , import as editable mesh) Bum! 3dsmax close instantly and i got the classic error when 3dsmax crash.

So......any idea? Because i can barely import 2/10 of a stage :P

Let me know.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-22 21:06:30
I see. Post me which stage this is, offset of model and version of your 3DS Max. It's night in my country ATM, but I'll test it with 3DS Max tomorrow ASAP. I'm crafting OBJ from scratch, so there maybe is a problem that I missed. Thanks for report! :)

BTW> I personally didn't test exported meshes with 3DS Max, only with Milkshape and Mootools 3DBrowser.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-22 22:02:00
I did some test too and I had same problem "invalid vertex index" when importing (had to open obj whith noesis and re-export again to fix that).

I'm using 3ds max 2014 anyway.


(http://s22.postimg.org/sefyy0h35/Norg.jpg)

Known bugs:
-Bad UV calculation for triangles





Yeah.. probably there is something flipped somehow.. don't know if my screen can help to understand what's wrong but here's it  ;D
(http://s1.postimg.org/dlqv8avxr/Triangles.jpg)


TODO:
-Change rip triangle/quad button behaviour (disable if not any available)
-Limit those annoying MessageBox'es.
-Fix triangles UV calc.
-Auto texture size resolve after open
-Better MTL generation/ to make this faster
-Button for loop thru all models
-Throw away this message box in extended mode

An "extract all to one .obj" function which gives you one already merged .obj would be the best since some stage seems to have more than 20 fragments..and merging them one by one can be pain in the ass  :roll: (but if it takes too much time no problem  :wink: )


BTW> 700 lines of code... (not counting designer code) Phew, I'm tired.

Have some rest .. you really deserved it  ;D




P.S.

This is amazing.. thanks Maki.. you made my day..really  :)




Update:

There is something weird whith stage 30 and 31..
(http://s29.postimg.org/uf0eq3eg7/battle_stage30.jpg)
(http://s23.postimg.org/xlx7blox7/battle_stage31.jpg)
it looks like there is one or more missing piece..I'm sure there must be some "border" filling the gap between the flat combat ground and lava.

Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-23 16:42:45
Yep. Checked that. 3DS Max hates meshes, that have too much vertex info. I'll tell you why this is happening:

There's Entry point for model.

At first it says how much vertex are there in this one segment.
Then there's X Y Z data for each vertex. After vertex data, so after 6*number of vertex there's 4 byte padding + MODULO from absolute position, but this is not important. After this there's count for triangles and count for quads. Not always triangle part of this model uses all of vertices. So in triangle part of model there's vertex data for both triangle+quad, but only data for triangle connection. That makes 3DS Max furious. Other softwares should get over it. Currently, I can't solve this problem, however... there's a small chance I'd like to write below.


I took a closer look how does a OBJ file with many objects stitched together look like... You won't believe. It's just one model after another. O_O It's like copying one model data to another's and it works! I though I wouldn't be able to figure a way to do this because of every model needs to use it's own vertex, vt and face info, and today I've just seen this. So a magical button for one way convert to ready, stitched model is just a matter of time.

Still can't find a problem with triangle VT. I didn't test this in 3DS Max yet. I'll do like I did with quads. I'll manually repair the texture, and see what result should I get from my file. This worked for quads, should work for triangles.

I did make some major changes. Made it faster now to rip models. No need to generate MTL, click on resolve texture or etc. Just select model and RIP. That's all.

I'll post the software updated to TOOLS category here. I'll edit this one to post a link for this.

However, I just found a logic bug. It caused in some rare cases to throw away an exception.

EDIT: Or wait a sec. I'll add that one model option

UPDATE: Nope. It didn't work. ;/
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-23 17:09:44
Thanks for explanation!

Indeed that 3ds max error is not a big deal (it can be solved using noesis in 2 secs)

I'm more worried about "missing pieces".

The "magical button" news sounds great!!!  :-D


P.S.

I don't know if anyone already made a check but.. any chance that some stage are "hidden" in ff8.exe file? (so many stuff hidden there.. it would not surprise me  :P )
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-23 17:42:25
The "magical button" news sounds great!!!  :-D

Ye. But I failed. Need more time.

Made a topic in TOOLS:
http://forums.qhimm.com/index.php?topic=16017.msg225783#msg225783
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-23 18:09:46
Ye. But I failed. Need more time.

Not a problem! that button would just make the process faster (I'd like it but I can live 1 or 2 day whithout it I guess :D )

The new version already speed up the process and that's already nice..I'm gonna test it in the next hours!


Update: I tested the new version and I don't know what you changed but I don't get anymore the error on 3ds max!
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-23 19:16:00
EDIT:
Sorry i didn't see the others post (Kaspar's problem, it's the same) XD so it's almost useless this post :P I have to try your update.

Anyway here my info:

- Net framework 4.5.1
- 3dsmax Ver. 2015 x64
- Stage a0stg100.x (Edea's room)
- Search model (strict) 9216 for example    (Vertices offset 0x2406 - Triangles // - Quads 0x248C)
And when i try to import it from the menù (and not with a drag and drop) , i got that error.
Meanwhile with a classic and fast drag and drop, nothing happens & nothing import.

Here the main file and the obj (9216) extracted (without any mtl, doesn't matter in this moment)
Link -> www.mediafire.com/download/l4t6rrm8ab7av9w/Model.rar (http://www.mediafire.com/download/l4t6rrm8ab7av9w/Model.rar)

Oh and sometimes when i try to extract some quads model (in the same file you can try the 9720)  i got an error from the program, here the log:


Le informazioni su come richiamare il debug JIT (Just-In-Time) anziché questa finestra
sono riportate in fondo al messaggio.

************** Testo dell'eccezione **************
System.FormatException: Formato della stringa di input non corretto.
   in System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   in System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   in System.Byte.Parse(String s, NumberStyles style, NumberFormatInfo info)
   in FF8_StageModel_ToObj.Form1.button5_Click(Object sender, EventArgs e)
   in System.Windows.Forms.Control.OnClick(EventArgs e)
   in System.Windows.Forms.Button.OnClick(EventArgs e)
   in System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   in System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   in System.Windows.Forms.Control.WndProc(Message& m)
   in System.Windows.Forms.ButtonBase.WndProc(Message& m)
   in System.Windows.Forms.Button.WndProc(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   in System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Assembly caricati **************
mscorlib
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18444 built by: FX451RTMGDR
    Base di codice: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
Final Fantasy VIII Battle stage model to OBJ
    Versione assembly: 0.8.0.0
    Versione Win32: 0.8.0.0
    Base di codice: file:///C:/Users/Administrator/Desktop/FF8%20.X%20to%20OBJ.exe
----------------------------------------
System.Windows.Forms
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.34238 built by: FX452RTMGDR
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
mscorlib.resources
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_it_b77a5c561934e089/mscorlib.resources.dll
----------------------------------------
System.Windows.Forms.resources
    Versione assembly: 4.0.0.0
    Versione Win32: 4.0.30319.18408 built by: FX451RTMGREL
    Base di codice: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_it_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------

************** Debug JIT **************
Per abilitare il debug JIT, è necessario impostare il valore
jitDebugging nella sezione system.windows.forms del file di configurazione
dell'applicazione o del computer (machine.config).
L'applicazione inoltre deve essere compilata con il debug
abilitato.

Ad esempio:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

Quando il debug JIT è abilitato, tutte le eccezioni non gestite
vengono inviate al debugger JIT registrato nel computer,
anziché essere gestite da questa finestra di dialogo.


Sorry for some parts on the log in italian languages :P (I'm italian :P)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-23 20:09:12
Yep, a problem you posted was fixed in 0.95, available to download in topic in TOOLS. This error was appearing when TPage resolving was trying to use UV translation bigger than the texture itself. I just had to break the loop one index earlier. Clearly my bad. :P

Keep me updated with any other bugs you'll encounter. Thanks. :)

Kaspar01, really? Well, I wasn't expecting that. I corrected only that loop that added one bad face indice due to breaking loop after doing instructions instead of checking condition before calculating. :P
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-23 23:38:52
Kaspar01, really? Well, I wasn't expecting that. I corrected only that loop that added one bad face indice due to breaking loop after doing instructions instead of checking condition before calculating. :P

Yep! I already tested it on many stages but never got that error again :)

The triangles uv problem is weird.. it looks like each triangle take the right piece of texture but it's shown "reversed"..

Maybe I'm wrong but it looks like the UV "positions" of each triangle are correct but they're not correctly assigned to their own vertex..
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-25 18:42:23
Converter has been updated to 1.1. Fixed the triangles, added magic button.
http://forums.qhimm.com/index.php?topic=16017.new#new

Thanks kaspar01 for providing screens before and after fixing UV.
Title: Re: [FF8] .x battle fields
Post by: Zervox on 2015-03-26 15:12:18

a0stg001.x  Whinhill Village? 


if I am not mistaken that is the bridge in dollet connecting to the communication mountain.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-26 15:32:32
if I am not mistaken that is the bridge in dollet connecting to the communication mountain.

You're probably right.

I made that list before MakiPL released the tool just looking at the first clut of the corresponding TIM texture so.. there are probably many errors (when you find at leas a "?" it's because I was not sure about it :) )

Thanks for your correction! later I'll edit the list.
Title: Re: [FF8] .x battle fields
Post by: Mcindus on 2015-03-26 20:27:32
You're probably right.

I made that list before MakiPL released the tool just looking at the first clut of the corresponding TIM texture so.. there are probably many errors (when you find at leas a "?" it's because I was not sure about it :) )

Thanks for your correction! later I'll edit the list.

Is there a way to rip just the TIM the .x file is calling?  This would be very handy for texture modders.
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-26 20:39:15
Is there a way to rip just the TIM the .x file is calling?  This would be very handy for texture modders.

Use TIM Viewer.
TIM texture is the last segment in .x file and is starting with header 01 00 00 00 09
Changing image data after header, CLUT and core info should work.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-27 11:16:43
Use TIM Viewer.
TIM texture is the last segment in .x file and is starting with header 01 00 00 00 09
Changing image data after header, CLUT and core info should work.

These days I'm manually fixing some textures extracted from tim files to create proper material in 3ds max (whith alpha map) but it's not always an easy task to guess the right color palette for each texture piece..so I wonder... there is any info about how the game "knows" which one is the right one?
How does it pick the right colors from the tim file?
I tried to read something about .tim format but it looks like those info are not contained in the texture files..(this would be an explanation about why there is actually no tool able to extract the correct and complete texture automatically).

The problem is that for battle stage the "palette sections" have different dimensions and they apparently do not follow any logic order..(unlike world map textures which are placed on a square grid whith subsequential order).

I'm not asking to work on it..I just wonder if anyone already looked at this stuff :)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-30 12:36:47
These days I'm manually fixing some textures extracted from tim files to create proper material in 3ds max (with alpha map) so I wonder... there is any info about how the game "knows" which one is the right one?
How does it pick the right colours from the tim file?

There are two PSOne GPU related instructions: 12's byte and 15's first byte digit (quad) [and that's probably this]. Changing those produced for example inverted colours. However, FFVIII engine uses texture colourization, so it's real-time colourized - 21's, 22's and 23's byte (it's generally used to imitate the fake lightning in VIII).
I found no way to use it though. (colourization) :C
Even if I could manage, to get values for pallete used (CLUT, not colourization) I still couldn't make any use of it. For generic .OBJ uses I'd have to colourize the texture itself, and it's out of my reach. Sorry. :C

I'm started to work on producing one .OBJ file. This would need, to convert quads to triangles by myself. Should not be a big deal. Mixing quads and triangle objects messes up texture coords and face indices of the others. Triangulating quads and stitching all should work, probably.

Candy for you:
(http://i.imgur.com/4fpHdPJ.jpg?1)
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-30 13:21:17
Actually the only thing I could guess is that each polygon or group or uv group is assigned somehow to the right color clut..
Something like multi-material in 3ds max but whith color cluts ID instead of material ID.. (I could be totally wrong anyway  ;D )

If I'm right then there is probably no way to automatically extract the "correct puzzle" from a TIM..

we at best could make a check to see if we're making it right :)


For the single .obj is a good thing even if I actually solved the importing time whith a useful script I found that allow me "multi import" .obj files in few secs  :-D

P.S.

I was wondering about some GF stuffs..
for example if you look at that sort of "cemetery ground" (or whatever it is) that GF Cerberus came out from during its summoning animation..
What's that? it looks like a sort of battle stage but it's animated (gate opens..)
I didn't find clues of where that environment could be located till now.. same thing for Alexander mountain and other GF animation "accessory 3d models".. maybe they have their own file format  ???

Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-30 13:46:51

For the single .obj is a good thing even if I actually solved the importing time whith a useful script I found that allow me "multi import" .obj files in few secs  :-D

Oh, could you upload this? I'd use that too. :)

I didn't find clues of where that environment could be located till now.. same thing for Alexander mountain and other GF animation "accessory 3d models".. maybe they have their own file format  ???



Same here. I'll run a software on FF8.EXE and see what will happen.
UPDATE: No. There's no .X files in EXE, nor 01 00 01 00 objects compatible with .X format.
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-30 14:07:57
Oh, could you upload this? I'd use that too. :)

Can't find that script right now since I'm not at home but you could try this (should work as well or even better ) :

http://www.scriptspot.com/3ds-max/scripts/batch-exportimport (http://www.scriptspot.com/3ds-max/scripts/batch-exportimport)

When I'll get back home I'll post the one I'm using :)

Edit:

Here's the one I'm currently using:

http://www.scriptspot.com/3ds-max/scripts/batch-merge


Same here. I'll run a software on FF8.EXE and see what will happen.
UPDATE: No. There's no .X files in EXE, nor 01 00 01 00 objects compatible with .X format.

That worth the try anyway  :'(

I think that probably there is some file format for "animation models" that could be similar to .dat combat model (like GF ones but probably not the same) that is used for stuffs like that like Shiva's "ice shards" or Ifrit's "magma ball" and so on..
There is a chance that same format is used for normal magic animation which actually spawn a 3d model (blizzard, blizzara, blizzaga..etc).




Title: Re: [FF8] .x battle fields
Post by: Halfer on 2015-03-30 15:39:16
I may be completely wrong but why don't you give a shot to mag999_a.dat file. Its size and name could mean that it includes something special, maybe all the ground models for GF animations?
Title: Re: [FF8] .x battle fields
Post by: kaspar01 on 2015-03-30 15:54:14
I may be completely wrong but why don't you give a shot to mag999_a.dat file. Its size and name could mean that it includes something special, maybe all the ground models for GF animations?

That could be an interesting point!

edit:

looks like battle/mag87 files contain environment textures for selphie's limit "the end".
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-31 17:42:31
I may be completely wrong but why don't you give a shot to mag999_a.dat file. Its size and name could mean that it includes something special, maybe all the ground models for GF animations?

I've already check it but i don't know how read/extract the data/models from over there.
If you hex edit that file, you can see this header in every "data blocks".

"XX XX XX XX 00 00 00 00 00 11 00 00 00 00 10 00 00 90 06"
Always the same but not the first 4, maybe are some kind of pointers i don't know.
Anyway the header it's always the same dimension 06 90 (is this the header.....i think xD)

We've tried some old Py scripts from this thread http://forums.qhimm.com/index.php?topic=15056.0 but are not the same "Kind" of model...so are totally useless...
If you can give a check...maybe MakiPL, you can understand something for make a new script/tool for make readable these "Blocks".

Edit:
IMPORTANT MakiPL
If you check this file "mag087_b.1r1" the structure is very similar to a battlestage...so let me know if there is something like the "the end" stage. If yes i'll give you other file with this type of "models".
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-31 20:13:37
Edit:
IMPORTANT MakiPL
If you check this file "mag087_b.1r1" the structure is very similar to a battlestage...so let me know if there is something like the "the end" stage. If yes i'll give you other file with this type of "models".

Indeed. Typical Quad info starts at 0x88c. However visualisation of this produces bad mesh.
There's texture in 1t0 and 1t1. The file is divided on parts. At the moment I can tell:

.1p0 file is UNKNOWN (p stands for... particle?)
.1r0 is start file, that the first unsigned int is size of the first pattern. Visualizing of vertices from this part produced this cloud: (http://i.imgur.com/G616Qd6.png?1?2141). Moreover 2240 MODULO 6 != 0, so it's not Short type X Y Z vertices. After this another pattern appears. Finally, a 8670 byte of this strange pattern. 8670 is dividable by 1,2,3,5,6,10,15,17,30 and 34. Never seen anything sized like that.
.1r1 is the same as above, but the pattern is almost the same like the stage. Starting from 0x8bc till the least 2c EOF byte, there's 5712 bytes, and this number is dividable by 24. Max face index is 545, this means I need at least 545*6 = 3270 Bytes of data for vertices. I found, that there's a pattern for either 4 or 8 bytes. 4 bytes of data, and four next bytes are 00 00 00 00.
.1s0 looks like the camera (has the same header as stage - but it's only a speculation)
.1t0 and .1t1 - divide parts of this texture: (http://i.imgur.com/txYH7mj.png?1)

Hm... I have an idea. Please, could you find a mag file that's responsible for some magic/GF that has objects in it? I could then real-time memory edit this to find out what will happen. OR, someone tell me if he/she recognise a spell/magic/anything that this texture may apply.


@Mag999_a.dat contains only AKAO sequences (this is: sounds info).
Mag184 is Shiva.

EDIT3: In .EXE, at 0x9b7db8 is ASCII hard-coded "mag150.TIM". I though about ASCII rip using Jaeder Naub , see what I get.
Title: Re: [FF8] .x battle fields
Post by: dheen on 2015-03-31 20:25:23
Yes Odin GF invocation.

Hum no. Let me search :) definitely remind me something

Hum seems like bahamut. The only zone with moon on it ....
Title: Re: [FF8] .x battle fields
Post by: Yagami Light on 2015-03-31 20:52:46
That moon is from Rinoas limit break called Invincible moon
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-31 21:00:45
That moon is from Rinoas limit break called Invincible moon

Yep. Thanks. https://youtu.be/5zfvk6SfLZQ?t=1m48s

So, it's just a plane with a moving clouds. That's probably it. Need to find better model. (other magic file)
Title: Re: [FF8] .x battle fields
Post by: dheen on 2015-03-31 21:08:04
Hum ..... I failed -_-
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-03-31 21:25:58
Hum ..... I failed -_-

At least you tried and that's what matters most. :)

I uploaded the ASCII RIP. Be warned, it's 30k lines per one link.

http://pastebin.com/aPE6LnSJ - #1 = most interesting, contains parameters, functions and .cpp leftovers.
http://pastebin.com/DTqEn9sc - #2 = See the ABCDEFGH... things? They're models with texture refference (after these patterns there's a ABC.tim refference)
http://pastebin.com/EW5fnT2S - #3 = See at the end of file. I've seen things like this in rail.obj, what could it be? Also, FF8.EXE contains quote of Buddha:
Code: [Select]
"What is evil? Killing is evil, lying is evil, slandering is evil, abuse is evil, gossip is evil, envy is evil, hatred is evil, to cling to false doctrine is evil; all these things are evil. And what is the root of evil? Desire is the root of evil, illusion is the root of evil."Also I wonder if it's just a contingency, or it's some sort of encoded thing:
Code: [Select]
:Yqcq _ qumpb a_jjcb
 
Wncag_j qigjj gq
Vclxmisicl< sqgle
 
Wgjclr< _lb _ `gr
 
Pmtcq rfc fmr bmeq
qmjb gl rfc K_pbcl
a_dcrcpg_;
Yqcq ajmqc amk`_r
dgefrgle qigjjq rm
bcdc_r clckgcq ugrf
nslafcq _lb igaiq;
El cvncpr k_piq2
k_l;  G_l sqc
qncag_jgxcb `sjjcrq
rm _rr_ai clckgcq;
HmcqlCr ncpdmpk
tcpw ucjj slbcp
npcqqspc;
Yqcq _ ufgn;
[fcl gl b_lecp<
sqcq kmlqrcp qigjjq
qfc f_q jc_plcb;
Lcp _bkgpcpq gl rfc
K_pbcl f_tc
dmpkcb _ d_l ajs`;
`cp md rfc
`cp pcqgqr_lac
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-31 21:30:59
Hm... I have an idea. Please, could you find a mag file that's responsible for some magic/GF that has objects in it? I could then real-time memory edit this to find out what will happen. OR, someone tell me if he/she recognise a spell/magic/anything that this texture may apply.

Try to search on Mag190 a/c.....in Mag190b you can find the doomtrain model...and i think anything else...meanwhile in mag190c i think there are 3 models and 1 texture.....in mag 190a there is something....maybe the "space structure" and the flames animation (i think)...but really i don't know....i can "See and recognize" something but i have to find some book or forum where i can study this "hex structure of a file" (i'm really curious)
If you have something like a pdf file or a book or a forum or anything where I can begin, I would appreciate it very much! (So i can give you a help literally >_>)
Let me know if i'm right.

(Here a video about doomtrain https://www.youtube.com/watch?v=Z4VjvBaMHJg so you can check the extra model and the "stage" (space))
Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-03-31 21:54:30
http://pastebin.com/aPE6LnSJ - #1 = most interesting, contains parameters, functions and .cpp leftovers.
http://pastebin.com/DTqEn9sc - #2 = See the ABCDEFGH... things? They're models with texture refference (after these patterns there's a ABC.tim refference)
http://pastebin.com/EW5fnT2S - #3 = See at the end of file. I've seen things like this in rail.obj, what could it be? Also, FF8.EXE

1) In the first one there is the structure of the game, functions, a complete list of all file inside the battle.fs etc.
2) Well i don't understand almost anything xD but yeah, there are some references of models and textures.
3)Rail.obj and the others one, just open deling and extract the content of World.fs -> c:\ff8\data\ita\world\dat\.... over there there are all. And you can find and see directly, with deling, some textures of the worldmap and gardens itselfs over the file -> textl.obj & wmsetXX  (XX -> IT/ US / DE / FR / ES ETC) i have for example the wmsetit (i'm italian :P)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2015-04-01 20:20:37
I real-time debugged process, and found some entries testing on Shiva.

At first, when you summoning G.F. nothing happen to data in memory, it's 00 00... or the state of previous G.F.
After the G.F. gauge runs out, the memory is written by some small data, and after the character animation of summoning passes (You know, that one when for example Squall puts hand from his face to enemy and disappears after) the data is written by .TIM texture. After 1-2 second of Shiva animation, right before she appears in the crystal a data is again written to .TIM texture place and data from mag184_e.dat appears. This is memory dump of this region:
https://www.dropbox.com/s/g2vrrradn7muj8s/MemDump.7z?dl=0

The first texture is broken. Don't know why.

After textures, there's at least 3MB of free space. The models have to be before, but all I can see are still NULL's. At the moment, where there's ice over enemies, and shiva is no more able to be seen, the data is again overwritten. That's the real problem. I can't help myself with real-time memory edit/debugging if the values and addresses are changing by the situation.

Title: Re: [FF8] .x battle fields
Post by: Softtm17 on 2015-04-01 21:45:00
That's can be a problem...you can't "pause" the game in that moment?  Have you tried to stop it "brutally" with an emulator like epsxe?

Anyway Shiva's model is on Mag184_E.dat, if you need (to compare) here the file raw (only shiva & unviewable with any software) and the elaborated one (viewable) : https://www.dropbox.com/s/bc35pa2ss6416cw/Mag184_e.rar?dl=0

You can view the model & the animation with Noesis -> https://www.dropbox.com/s/9boo262hyj3kucv/noesis.rar?dl=0
Title: Re: [FF8] .x battle fields
Post by: Maki on 2016-06-09 19:38:41
Month ago I posted japanese interview with every development team at: http://forums.qhimm.com/index.php?topic=15894.25
One coder from battle team said that they made a camera editor in-game (Yes, not external program). Some days ago I came up with some extreme idea:
"What if the unknown and unused battle stage section is in fact a CODE?"
So... I tried with intel and came up with nothing. That's not intel, of course it's written for PlayStation. So... I tried with MIPS big-endian and nope, a lot of unrecognizable assembly. But the file is little-endian, so I tried MIPSL (MIPS little-endian) instead and... I got full code with refferences inside (relative jumps in code), repeative memory copy, jumps to 0x800F07C0 and related (The same address range is when you disassembly the real FF8 PSX code file). I have totally no knowledge about MIPS, but maybe someone could prove it's only my fantasy and it's not a code:
*Fun fact is the disassembly fails to convert to code just as the unknown data section ends (so the camera starts)

Code: [Select]
ROM:00000000                 addiu   $sp, -0x18       # Add Immediate Unsigned
ROM:00000004                 li      $v0, 1           # Load Immediate
ROM:00000008                 sw      $ra, 0x14($sp)   # Store Word
ROM:0000000C                 beq     $a0, $v0, loc_54  # Branch on Equal
ROM:00000010                 sw      $s0, 0x10($sp)   # Store Word
ROM:00000014                 slti    $v0, $a0, 2      # Set on Less Than Immediate
ROM:00000018                 beqz    $v0, loc_30      # Branch on Zero
ROM:0000001C                 nop
ROM:00000020
ROM:00000020 loc_20:                                  # DATA XREF: ROM:00004264o
ROM:00000020                                          # ROM:00004654o ...
ROM:00000020                 beqz    $a0, loc_44      # Branch on Zero
ROM:00000024
ROM:00000024 loc_24:                                  # DATA XREF: ROM:00029E80o
ROM:00000024                                          # ROM:000364B8o
ROM:00000024                 lui     $a0, 0x8014      # Load Upper Immediate
ROM:00000028
ROM:00000028 loc_28:                                  # DATA XREF: ROM:00002130o
ROM:00000028                                          # ROM:000027A0o ...
ROM:00000028                 j       0x13E0A8         # Jump
ROM:0000002C                 nop                      # DATA XREF: ROM:000235A4o
ROM:0000002C                                          # ROM:00023894o ...
ROM:00000030  # ---------------------------------------------------------------------------
ROM:00000030
ROM:00000030 loc_30:                                  # CODE XREF: ROM:00000018j
ROM:00000030                                          # DATA XREF: ROM:0002F8A4o
ROM:00000030                 li      $v0, 2           # Load Immediate
ROM:00000034
ROM:00000034 loc_34:                                  # DATA XREF: ROM:00022370o
ROM:00000034                                          # ROM:0002A794o ...
ROM:00000034                 beq     $a0, $v0, loc_68  # Branch on Equal
ROM:00000038                 lui     $s0, 0x8014      # DATA XREF: ROM:00024D94o
ROM:00000038                                          # ROM:00029594o
ROM:00000038                                          # Load Upper Immediate
ROM:0000003C                 j       0x13E0A8         # DATA XREF: ROM:00006B30o
ROM:0000003C                                          # Jump
ROM:00000040                 nop                      # DATA XREF: ROM:000367ACo
ROM:00000044  # ---------------------------------------------------------------------------
ROM:00000044
ROM:00000044 loc_44:                                  # CODE XREF: ROM:loc_20j
ROM:00000044                                          # DATA XREF: ROM:000353CCo
ROM:00000044                 jal     0x13E0BC         # Jump And Link
ROM:00000048
ROM:00000048 loc_48:                                  # DATA XREF: ROM:00022F94o
ROM:00000048                                          # ROM:00023294o ...
ROM:00000048                 addiu   $a0, -0xEEC      # Add Immediate Unsigned
ROM:0000004C                 j       0x13E0A8         # DATA XREF: ROM:00028F94o
ROM:0000004C                                          # ROM:00029E94o
ROM:0000004C                                          # Jump
ROM:00000050                 move    $v0, $zero
ROM:00000054  # ---------------------------------------------------------------------------
ROM:00000054
ROM:00000054 loc_54:                                  # CODE XREF: ROM:0000000Cj
ROM:00000054                                          # DATA XREF: ROM:00022C94o ...
ROM:00000054                 lui     $a0, 0x8014      # Load Upper Immediate
ROM:00000058                 jal     0x13E2B8         # Jump And Link
ROM:0000005C
ROM:0000005C loc_5C:                                  # DATA XREF: ROM:00022994o
ROM:0000005C                 addiu   $a0, -0xEEC      # Add Immediate Unsigned
ROM:00000060                 j       0x13E0A8         # Jump
ROM:00000064
ROM:00000064 loc_64:                                  # DATA XREF: ROM:00022094o
ROM:00000064                 move    $v0, $zero
ROM:00000068  # ---------------------------------------------------------------------------
ROM:00000068
ROM:00000068 loc_68:                                  # CODE XREF: ROM:loc_34j
ROM:00000068                                          # DATA XREF: ROM:000253C8o
ROM:00000068                 addiu   $s0, -0x1A3C     # Add Immediate Unsigned
ROM:0000006C                 move    $a0, $s0         # DATA XREF: ROM:00035FCCo
ROM:00000070
ROM:00000070 loc_70:                                  # DATA XREF: ROM:000362CCo
ROM:00000070                                          # ROM:00036170o
ROM:00000070                 li      $a1, 0x8013E5B4  # Load Immediate
ROM:00000078                 li      $a2, 0x10        # DATA XREF: ROM:00024D8Co
ROM:00000078                                          # ROM:00033D64o
ROM:00000078                                          # Load Immediate
ROM:0000007C                 jal     0xB5078          # DATA XREF: ROM:000223B8o
ROM:0000007C                                          # Jump And Link
ROM:00000080                 li      $a3, 1           # Load Immediate
ROM:00000084
ROM:00000084 loc_84:                                  # DATA XREF: ROM:00022980o
ROM:00000084                 move    $a0, $s0
ROM:00000088                 lui     $a1, 0x8014      # Load Upper Immediate
ROM:0000008C                 jal     0xB50FC          # Jump And Link
ROM:00000090                 li      $a1, 0x8013E53C  # Load Immediate
ROM:00000094                 sh      $zero, 0xC($v0)  # DATA XREF: ROM:00019AB0o
ROM:00000094                                          # Store Halfword
ROM:00000098                 lui     $a0, 0x8014      # Load Upper Immediate
ROM:0000009C                 jal     0x13E26C         # Jump And Link
ROM:000000A0                 li      $a0, 0x8013E5D4  # Load Immediate
ROM:000000A4                 move    $v0, $s0
ROM:000000A8                 lw      $ra, 0x14($sp)   # Load Word
ROM:000000AC                 lw      $s0, 0x10($sp)   # Load Word
ROM:000000B0                 addiu   $sp, 0x18        # Add Immediate Unsigned
ROM:000000B4                 jr      $ra              # Jump Register
ROM:000000B8                 nop
ROM:000000BC  # ---------------------------------------------------------------------------
ROM:000000BC
ROM:000000BC loc_BC:                                  # DATA XREF: ROM:00005000o
ROM:000000BC                 addiu   $sp, -0x30       # Add Immediate Unsigned
ROM:000000C0                 sw      $s4, 0x20($sp)   # Store Word
ROM:000000C4                 move    $s4, $a0
ROM:000000C8                 sw      $s5, 0x24($sp)   # Store Word
ROM:000000CC                 move    $s5, $zero
ROM:000000D0                 lui     $v0, 0x800F      # Load Upper Immediate
ROM:000000D4                 sw      $s6, 0x28($sp)   # Store Word
ROM:000000D8                 addiu   $s6, $v0, 0x708  # Add Immediate Unsigned
ROM:000000DC                 sw      $s0, 0x10($sp)   # Store Word
ROM:000000E0                 move    $s0, $s6
ROM:000000E4                 sw      $s3, 0x1C($sp)   # Store Word
ROM:000000E8                 move    $s3, $s5
ROM:000000EC                 sw      $s2, 0x18($sp)   # Store Word
ROM:000000F0                 addiu   $s2, $s6, 0x20   # Add Immediate Unsigned
ROM:000000F4                 sw      $s1, 0x14($sp)   # Store Word
ROM:000000F8                 move    $s1, $s4
ROM:000000FC                 sw      $ra, 0x2C($sp)   # Store Word
ROM:00000100
ROM:00000100 loc_100:                                 # CODE XREF: ROM:000001A8j
ROM:00000100                                          # DATA XREF: ROM:0003055Co ...
ROM:00000100                 lw      $v0, 8($s1)      # Load Word
ROM:00000104                 lw      $v1, 4($s1)      # Load Word
ROM:00000108                 addu    $v0, $s4, $v0    # Add Unsigned
ROM:0000010C                 addu    $v1, $s4, $v1    # Add Unsigned
ROM:00000110                 beq     $v0, $v1, loc_174  # Branch on Equal
ROM:00000114                 nop
ROM:00000118                 lw      $v0, 4($v1)      # Load Word
ROM:0000011C                 nop
ROM:00000120                 addu    $v0, $v1, $v0    # Add Unsigned
ROM:00000124                 sw      $v0, 4($s0)      # Store Word
ROM:00000128                 lw      $v0, 8($v1)      # Load Word
ROM:0000012C                 nop
ROM:00000130                 addu    $v0, $v1, $v0    # Add Unsigned
ROM:00000134                 sw      $v0, 8($s0)      # Store Word
ROM:00000138                 lw      $a0, 0xC($v1)    # Load Word
ROM:0000013C                 nop
ROM:00000140                 addu    $a0, $v1, $a0    # Add Unsigned
ROM:00000144                 jal     0xBBB20          # Jump And Link
ROM:00000148                 sw      $a0, 0xC($s0)    # Store Word
ROM:0000014C                 addiu   $a0, $s6, 0x14   # Add Immediate Unsigned
ROM:00000150                 addu    $a0, $s3, $a0    # Add Unsigned
ROM:00000154                 move    $a1, $s2
ROM:00000158                 lw      $v0, 0($s0)      # Load Word
ROM:0000015C                 move    $a2, $zero
ROM:00000160                 ori     $v0, 0x700       # OR Immediate
ROM:00000164                 jal     0xBFBA0          # Jump And Link
ROM:00000168                 sw      $v0, 0($s0)      # Store Word
ROM:0000016C                 j       0x13E198         # Jump
ROM:00000170                 addiu   $s0, 0x2C  # ','  # Add Immediate Unsigned
ROM:00000174  # ---------------------------------------------------------------------------
ROM:00000174
ROM:00000174 loc_174:                                 # CODE XREF: ROM:00000110j
ROM:00000174                 lw      $v0, 0($s0)      # Load Word
ROM:00000178                 li      $v1, 0xFFFFFEFF  # Load Immediate
ROM:0000017C                 and     $v0, $v1         # AND
ROM:00000180                 li      $v1, 0xFFFFFDFF  # Load Immediate
ROM:00000184                 and     $v0, $v1         # AND
ROM:00000188                 li      $v1, 0xFFFFFBFF  # Load Immediate
ROM:0000018C                 and     $v0, $v1         # AND
ROM:00000190                 sw      $v0, 0($s0)      # Store Word
ROM:00000194                 addiu   $s0, 0x2C  # ','  # Add Immediate Unsigned
ROM:00000198                 addiu   $s3, 0x2C  # ','  # Add Immediate Unsigned
ROM:0000019C                 addiu   $s2, 0x2C  # ','  # Add Immediate Unsigned
ROM:000001A0                 addiu   $s5, 1           # Add Immediate Unsigned
ROM:000001A4                 slti    $v0, $s5, 4      # Set on Less Than Immediate
ROM:000001A8                 bnez    $v0, loc_100     # Branch on Not Zero
ROM:000001AC                 addiu   $s1, 4           # Add Immediate Unsigned
ROM:000001B0                 lui     $v0, 0x800F      # Load Upper Immediate
ROM:000001B4                 lui     $a0, 0x800F      # Load Upper Immediate
ROM:000001B8                 sh      $zero, 0x800F07C0  # Store Halfword
ROM:000001BC                 lw      $v0, 0x14($s4)   # Load Word
ROM:000001C0                 lw      $v1, 0x18($s4)   # Load Word
ROM:000001C4                 addu    $v0, $s4, $v0    # Add Unsigned
ROM:000001C8                 sw      $v0, 0x800F07BC  # Store Word
ROM:000001CC                 lw      $v0, 0x14($s4)   # Load Word
ROM:000001D0                 addu    $v1, $s4, $v1    # Add Unsigned
ROM:000001D4                 addu    $v0, $s4, $v0    # Add Unsigned
ROM:000001D8                 bne     $v1, $v0, loc_1E4  # Branch on Not Equal
ROM:000001DC                 lui     $v1, 0x800E      # Load Upper Immediate
ROM:000001E0                 sw      $zero, 0x800F07BC  # Store Word
ROM:000001E4
ROM:000001E4 loc_1E4:                                 # CODE XREF: ROM:000001D8j
ROM:000001E4                 lui     $v0, 0x8014      # Load Upper Immediate
ROM:000001E8                 addiu   $a3, $v0, -0x1A78  # Add Immediate Unsigned
ROM:000001EC                 addiu   $a2, $v1, 0x4CA4  # Add Immediate Unsigned
ROM:000001F0                 lwl     $a0, 3($a3)      # Load Word Left
ROM:000001F4                 lwr     $a0, 0($a3)      # Load Word Right
ROM:000001F8                 nop
ROM:000001FC                 swl     $a0, 3($a2)      # Store Word Left
ROM:00000200                 swr     $a0, 0($a2)      # DATA XREF: ROM:000347C4o
ROM:00000200                                          # ROM:00037DC8o
ROM:00000200                                          # Store Word Right
ROM:00000204                 lui     $v0, 0x800E      # Load Upper Immediate
ROM:00000208                 lui     $v1, 0x8014      # Load Upper Immediate
ROM:0000020C                 addiu   $a3, $v1, -0x1A74  # Add Immediate Unsigned
ROM:00000210                 addiu   $a2, $v0, 0x4E14  # Add Immediate Unsigned
ROM:00000214                 lwl     $a0, 3($a3)      # Load Word Left
ROM:00000218                 lwr     $a0, 0($a3)      # Load Word Right
ROM:0000021C                 nop
ROM:00000220                 swl     $a0, 3($a2)      # Store Word Left
ROM:00000224                 swr     $a0, 0($a2)      # Store Word Right
ROM:00000228                 li      $v0, 0x800E4E14  # Load Immediate
ROM:0000022C                 li      $v1, 0x32  # '2'  # Load Immediate
ROM:00000230                 sb      $v1, 3($v0)      # Store Byte
ROM:00000234                 lw      $a0, 0x18($s4)   # Load Word
ROM:00000238                 jal     0xBBB60          # Jump And Link
ROM:0000023C                 addu    $a0, $s4, $a0    # Add Unsigned
ROM:00000240                 lw      $ra, 0x2C($sp)   # Load Word
ROM:00000244                 lw      $s6, 0x28($sp)   # Load Word
ROM:00000248                 lw      $s5, 0x24($sp)   # Load Word
ROM:0000024C                 lw      $s4, 0x20($sp)   # Load Word
ROM:00000250                 lw      $s3, 0x1C($sp)   # Load Word
ROM:00000254                 lw      $s2, 0x18($sp)   # Load Word
ROM:00000258                 lw      $s1, 0x14($sp)   # Load Word
ROM:0000025C                 lw      $s0, 0x10($sp)   # Load Word
ROM:00000260                 addiu   $sp, 0x30        # Add Immediate Unsigned
ROM:00000264                 jr      $ra              # Jump Register
ROM:00000268                 nop
ROM:0000026C  # ---------------------------------------------------------------------------
ROM:0000026C                 addiu   $sp, -0x18       # Add Immediate Unsigned
ROM:00000270                 sw      $s0, 0x10($sp)   # Store Word
ROM:00000274                 sw      $ra, 0x14($sp)   # Store Word
ROM:00000278                 jal     dword_30C54+0x50  # Jump And Link
ROM:0000027C                 move    $s0, $a0
ROM:00000280                 li      $v1, 0x800EE0E8  # Load Immediate
ROM:00000288                 andi    $v0, 1           # AND Immediate
ROM:0000028C                 addu    $v0, $v1         # Add Unsigned
ROM:00000290                 lbu     $v1, 0xCDE($v0)  # Load Byte Unsigned
ROM:00000294                 lui     $v0, 0x800F      # Load Upper Immediate
ROM:00000298                 move    $a0, $s0
ROM:0000029C                 jal     0xC69C4          # Jump And Link
ROM:000002A0                 sh      $v1, 0x800F1260  # Store Halfword
ROM:000002A4                 lw      $ra, 0x14($sp)   # Load Word
ROM:000002A8                 lw      $s0, 0x10($sp)   # Load Word
ROM:000002AC                 addiu   $sp, 0x18        # Add Immediate Unsigned
ROM:000002B0                 jr      $ra              # Jump Register
ROM:000002B4                 nop
ROM:000002B8  # ---------------------------------------------------------------------------
ROM:000002B8                 addiu   $sp, -0x18       # Add Immediate Unsigned
ROM:000002BC                 sw      $ra, 0x10($sp)   # Store Word
ROM:000002C0                 lw      $v0, 0x18($a0)   # Load Word
ROM:000002C4                 jal     0xBDB8C          # Jump And Link
ROM:000002C8                 addu    $a0, $v0         # Add Unsigned
ROM:000002CC                 lw      $ra, 0x10($sp)   # Load Word
ROM:000002D0                 addiu   $sp, 0x18        # Add Immediate Unsigned
ROM:000002D4                 jr      $ra              # Jump Register
ROM:000002D8                 nop
ROM:000002DC  # ---------------------------------------------------------------------------
ROM:000002DC                 addiu   $sp, -0x40       # Add Immediate Unsigned
ROM:000002E0                 li      $a0, 0x54  # 'T'  # Load Immediate
ROM:000002E4                 sw      $ra, 0x3C($sp)   # Store Word
ROM:000002E8                 sw      $fp, 0x38($sp)   # Store Word
ROM:000002EC                 sw      $s7, 0x34($sp)   # Store Word
ROM:000002F0                 sw      $s6, 0x30($sp)   # Store Word
ROM:000002F4                 sw      $s5, 0x2C($sp)   # Store Word
ROM:000002F8                 sw      $s4, 0x28($sp)   # Store Word
ROM:000002FC                 sw      $s3, 0x24($sp)   # Store Word
ROM:00000300                 sw      $s2, 0x20($sp)   # DATA XREF: ROM:000356BCo
ROM:00000300                                          # ROM:000380C8o ...
ROM:00000300                                          # Store Word
ROM:00000304                 sw      $s1, 0x1C($sp)   # Store Word
ROM:00000308                 jal     0xB5D10          # Jump And Link
ROM:0000030C                 sw      $s0, 0x18($sp)   # Store Word
ROM:00000310                 move    $s4, $zero
ROM:00000314                 move    $s1, $v0
ROM:00000318                 addiu   $s7, $s1, 8      # Add Immediate Unsigned
ROM:0000031C                 lui     $t1, 0x800F      # Load Upper Immediate
ROM:00000320                 addiu   $fp, $t1, 0x1298  # Add Immediate Unsigned
ROM:00000324                 li      $t1, 0x800F071C  # Load Immediate
ROM:0000032C                 addiu   $v0, $t1, -0x14  # Add Immediate Unsigned
ROM:00000330                 addiu   $s6, $v0, 4      # Add Immediate Unsigned
ROM:00000334                 move    $s3, $v0
ROM:00000338                 li      $s2, 0x800F071C  # Load Immediate
ROM:00000340                 addiu   $s5, $s2, 0xC    # Add Immediate Unsigned
ROM:00000344                 li      $v0, 0x140       # Load Immediate
ROM:00000348                 sh      $v0, 0x40($s1)   # Store Halfword
ROM:0000034C                 li      $v0, 0xD8  # 'ě'  # Load Immediate
ROM:00000350                 sh      $v0, 0x42($s1)   # Store Halfword
ROM:00000354                 lui     $v0, 0x800F      # Load Upper Immediate
ROM:00000358                 lui     $v1, 0x8010      # Load Upper Immediate
ROM:0000035C                 lw      $a0, 0x800F182C  # Load Word
ROM:00000360                 lw      $v1, 0x800FB518  # Load Word
ROM:00000364                 li      $v0, 0xFFFFFFFF  # Load Immediate
ROM:00000368                 sh      $zero, 0x3C($s1)  # Store Halfword
ROM:0000036C                 sh      $zero, 0x3E($s1)  # Store Halfword
ROM:00000370                 sw      $v0, 0x48($s1)   # Store Word
ROM:00000374                 sw      $a0, 0x2C($s1)   # Store Word
ROM:00000378                 sw      $v1, 0x38($s1)   # Store Word
ROM:0000037C
ROM:0000037C loc_37C:                                 # CODE XREF: ROM:000004F8j
ROM:0000037C                 lw      $v0, 0x800F0704  # Load Word
ROM:00000384                 nop
ROM:00000388                 andi    $v0, 4           # AND Immediate
ROM:0000038C                 bnez    $v0, loc_3B8     # Branch on Not Zero
ROM:00000390                 li      $v0, 3           # Load Immediate
ROM:00000394                 move    $a0, $s2
ROM:00000398                 jal     0xBF670          # Jump And Link
ROM:0000039C                 move    $a1, $s5
ROM:000003A0                 beqz    $v0, loc_3B4     # Branch on Zero
ROM:000003A4                 move    $a0, $s2
ROM:000003A8                 move    $a1, $s5
ROM:000003AC                 jal     0xBFBA0          # Jump And Link
ROM:000003B0                 move    $a2, $zero
ROM:000003B4
ROM:000003B4 loc_3B4:                                 # CODE XREF: ROM:000003A0j
ROM:000003B4                 li      $v0, 3           # Load Immediate
ROM:000003B8
ROM:000003B8 loc_3B8:                                 # CODE XREF: ROM:0000038Cj
ROM:000003B8                 beq     $s4, $v0, loc_3D4  # Branch on Equal
ROM:000003BC                 move    $a0, $s2
ROM:000003C0                 lui     $t1, 0x800F      # Load Upper Immediate
ROM:000003C4                 jal     0xBFDE8          # Jump And Link
ROM:000003C8                 addiu   $a1, $t1, 0x1298  # Add Immediate Unsigned
ROM:000003CC                 j       0x13E460         # Jump
ROM:000003D0                 nop
ROM:000003D4  # ---------------------------------------------------------------------------
ROM:000003D4
ROM:000003D4 loc_3D4:                                 # CODE XREF: ROM:loc_3B8j
ROM:000003D4                 move    $a0, $s1
ROM:000003D8                 lui     $t1, 0x8014      # Load Upper Immediate
ROM:000003DC                 lw      $v0, 0x8013E5B0  # Load Word
ROM:000003E0                 move    $a1, $s7
ROM:000003E4                 sh      $zero, 4($s1)    # Store Halfword
ROM:000003E8                 sh      $zero, 0($s1)    # Store Halfword
ROM:000003EC                 sra     $v0, 3           # Shift Right Arithmetic
ROM:000003F0                 jal     dword_2E554+0x104  # Jump And Link
ROM:000003F4                 sh      $v0, 2($s1)      # Store Halfword
ROM:000003F8                 move    $a0, $fp
ROM:000003FC                 jal     dword_30654+0xBC  # Jump And Link
ROM:00000400                 move    $a1, $s7
ROM:00000404                 lui     $t1, 0x800F      # Load Upper Immediate
ROM:00000408                 lw      $v0, 0x14($fp)   # Load Word
ROM:0000040C                 li      $t1, 0x800F071C  # Load Immediate
ROM:00000410                 sw      $v0, 0x1C($s1)   # Store Word
ROM:00000414                 lw      $v0, 0x18($fp)   # Load Word
ROM:00000418
ROM:00000418 loc_418:                                 # DATA XREF: ROM:00002D10o
ROM:00000418                 addiu   $a0, $t1, 0x84   # Add Immediate Unsigned
ROM:0000041C                 sw      $v0, 0x20($s1)   # Store Word
ROM:00000420                 lw      $v0, 0x1C($fp)   # Load Word
ROM:00000424                 move    $a1, $s7
ROM:00000428                 jal     0xBFDE8          # Jump And Link
ROM:0000042C                 sw      $v0, 0x24($s1)   # Store Word
ROM:00000430                 lw      $v0, 0x800F0704  # Load Word
ROM:00000438                 nop
ROM:0000043C                 andi    $v0, 1           # AND Immediate
ROM:00000440                 bnez    $v0, loc_460     # Branch on Not Zero
ROM:00000444                 lui     $v0, 0x800F      # Load Upper Immediate
ROM:00000448                 lui     $t1, 0x8014      # Load Upper Immediate
ROM:0000044C                 lh      $v1, 0x800F07C0  # Load Halfword
ROM:00000450                 lw      $v0, 0x8013E5B0  # Load Word
ROM:00000454                 nop
ROM:00000458                 addu    $v0, $v1         # Add Unsigned
ROM:0000045C                 sw      $v0, 0x8013E5B0  # Store Word
ROM:00000460
ROM:00000460 loc_460:                                 # CODE XREF: ROM:00000440j
ROM:00000460                 lw      $v1, 0($s3)      # Load Word
ROM:00000464                 nop
ROM:00000468                 srl     $v0, $v1, 8      # Shift Right Logical
ROM:0000046C                 andi    $v0, 1           # AND Immediate
ROM:00000470                 beqz    $v0, loc_4E4     # Branch on Zero
ROM:00000474                 srl     $v0, $v1, 9      # Shift Right Logical
ROM:00000478                 andi    $v0, 1           # AND Immediate
ROM:0000047C                 beqz    $v0, loc_4E4     # Branch on Zero
ROM:00000480                 lui     $s0, 0x8010      # Load Upper Immediate
ROM:00000484                 lwl     $v0, 0x2B($s3)   # Load Word Left
ROM:00000488                 lwr     $v0, 0x28($s3)   # Load Word Right
ROM:0000048C                 nop
ROM:00000490                 swl     $v0, 0x47($s1)   # Store Word Left
ROM:00000494                 swr     $v0, 0x44($s1)   # Store Word Right
ROM:00000498                 move    $a0, $s6
ROM:0000049C                 sll     $v1, $s4, 3      # Shift Left Logical
ROM:000004A0                 lhu     $v0, 2($s3)      # Load Halfword Unsigned
ROM:000004A4                 nop
ROM:000004A8                 sh      $v0, 0x4C($s1)   # Store Halfword
ROM:000004AC                 li      $v0, 0x8013E590  # Load Immediate
ROM:000004B4                 addu    $v1, $v0         # Add Unsigned
ROM:000004B8                 lw      $t0, 0($v1)      # Load Word
ROM:000004BC                 lw      $v0, 0x800FB610  # Load Word
ROM:000004C0                 addiu   $a1, $s1, 0x28   # Add Immediate Unsigned
ROM:000004C4                 sw      $v0, 0x10($sp)   # Store Word
ROM:000004C8                 lui     $v0, 0x8010      # Load Upper Immediate
ROM:000004CC                 sll     $t0, 2           # Shift Left Logical
ROM:000004D0                 lw      $a2, 0x800FB608  # Load Word
ROM:000004D4                 lw      $a3, 4($v1)      # Load Word
ROM:000004D8                 jal     0xBDDA4          # Jump And Link
ROM:000004DC                 addu    $a2, $t0         # Add Unsigned
ROM:000004E0                 sw      $v0, -0x49F0($s0)  # Store Word
ROM:000004E4
ROM:000004E4 loc_4E4:                                 # CODE XREF: ROM:00000470j
ROM:000004E4                                          # ROM:0000047Cj
ROM:000004E4                 addiu   $s6, 0x2C  # ','  # Add Immediate Unsigned
ROM:000004E8                 addiu   $s3, 0x2C  # ','  # Add Immediate Unsigned
ROM:000004EC                 addiu   $s2, 0x2C  # ','  # Add Immediate Unsigned
ROM:000004F0                 addiu   $s4, 1           # Add Immediate Unsigned
ROM:000004F4                 slti    $v0, $s4, 4      # Set on Less Than Immediate
ROM:000004F8                 bnez    $v0, loc_37C     # Branch on Not Zero
ROM:000004FC                 addiu   $s5, 0x2C  # ','  # Add Immediate Unsigned
ROM:00000500                 jal     0xB5D6C          # Jump And Link
ROM:00000504                 li      $a0, 0x54  # 'T'  # Load Immediate
ROM:00000508                 lw      $ra, 0x3C($sp)   # Load Word
ROM:0000050C                 lw      $fp, 0x38($sp)   # Load Word
ROM:00000510                 lw      $s7, 0x34($sp)   # Load Word
ROM:00000514                 lw      $s6, 0x30($sp)   # Load Word
ROM:00000518                 lw      $s5, 0x2C($sp)   # Load Word
ROM:0000051C                 lw      $s4, 0x28($sp)   # Load Word
ROM:00000520                 lw      $s3, 0x24($sp)   # Load Word
ROM:00000524                 lw      $s2, 0x20($sp)   # Load Word
ROM:00000528                 lw      $s1, 0x1C($sp)   # Load Word
ROM:0000052C                 lw      $s0, 0x18($sp)   # Load Word
ROM:00000530                 addiu   $sp, 0x40        # Add Immediate Unsigned
ROM:00000534                 jr      $ra              # Jump Register
ROM:00000538                 nop
ROM:0000053C  # ---------------------------------------------------------------------------
ROM:0000053C                 addiu   $sp, -0x18       # Add Immediate Unsigned
ROM:00000540                 sw      $ra, 0x10($sp)   # Store Word
ROM:00000544                 lh      $v1, 0xC($a0)    # Load Halfword
ROM:00000548                 lhu     $v0, 0xC($a0)    # Load Halfword Unsigned
ROM:0000054C                 beqz    $v1, loc_568     # Branch on Zero
ROM:00000550                 addiu   $v0, 1           # Add Immediate Unsigned
ROM:00000554                 li      $v0, 1           # Load Immediate
ROM:00000558                 beq     $v1, $v0, loc_570  # Branch on Equal
ROM:0000055C                 nop
ROM:00000560                 j       0x13E578         # Jump
ROM:00000564                 nop
ROM:00000568  # ---------------------------------------------------------------------------
ROM:00000568
ROM:00000568 loc_568:                                 # CODE XREF: ROM:0000054Cj
ROM:00000568                 j       0x13E578         # Jump
ROM:0000056C                 sh      $v0, 0xC($a0)    # Store Halfword
ROM:00000570  # ---------------------------------------------------------------------------
ROM:00000570
ROM:00000570 loc_570:                                 # CODE XREF: ROM:00000558j
ROM:00000570                 jal     0x13E2DC         # Jump And Link
ROM:00000574                 nop
ROM:00000578                 lw      $ra, 0x10($sp)   # Load Word
ROM:0000057C                 move    $v0, $zero
ROM:00000580                 jr      $ra              # Jump Register
ROM:00000584                 addiu   $sp, 0x18        # Add Immediate Unsigned

Just look at this:
(http://s19.postimg.org/8gs812sr7/Bez_tytu_u.jpg)
It doesn't look random. It does look like a real code.

UPDATE:
Basing on FF8.exe (PSOne version) file, the sections LI (load immediate - I see it is some sort of Intel's MOV) takes values from .TEXT section which is constants and memory.. example: TEXT:8013E590                 .byte    0
Title: Re: [FF8] .x battle fields
Post by: Maki on 2016-07-05 16:45:35
Again back at MIPS:
Ran some tests on files, and the differences in MIPSL diassembly are as follow:
a0stg000:
Code: [Select]
addiu   $a0, -0x1020
jal     0x13E2BC

a0stg001:
Code: [Select]
addiu   $a0, -0x16FC
jal     0x13E2BC

a0stg012:
Code: [Select]
addiu   $a0, -0xEEC
jal     0x13E2B8

As you can see only the add or jump adresses are changed.
The code is 1416 bytes for a0stg000.x
IDA manages to find at least three complete functions. Anyway I found the online disassembler based on Little-endian MIPS that can produce pseudocode. This is a0stg000.x code section pseudocode:
Code: [Select]
//
// This file was generated by the Retargetable Decompiler
// Website: https://retdec.com
// Copyright (c) 2016 Retargetable Decompiler <[email protected]>
//

#include <stdbool.h>
#include <stdint.h>

// ------------------- Function Prototypes --------------------

int32_t function_2a4(int32_t a1);
int32_t function_2f0(int32_t a1);
int32_t function_314(void);
int32_t function_34(int32_t a1);
int32_t function_574(int32_t a1);
int32_t function_f0(int32_t a1);
int32_t unknown_13e0a8(void);
int32_t unknown_13e0bc(void);
int32_t unknown_13e198(void);
int32_t unknown_13e270(void);
int32_t unknown_13e2bc(void);
int32_t unknown_13e2e0(void);
int32_t unknown_13e464(void);
int32_t unknown_13e57c(void);
int32_t unknown_2e658(void);
int32_t unknown_30710(void);
int32_t unknown_30ca4(void);
int32_t unknown_b5078(void);
int32_t unknown_b50fc(void);
int32_t unknown_b5d10(void);
int32_t unknown_b5d6c(void);
int32_t unknown_bbb20(void);
int32_t unknown_bbb60(void);
int32_t unknown_bdb8c(void);
int32_t unknown_bdda4(void);
int32_t unknown_bf670(void);
int32_t unknown_bfba0(void);
int32_t unknown_bfde8(void);
int32_t unknown_c69c4(void);

// ------------------------ Functions -------------------------

// Address range: 0x34 - 0xef
int32_t function_34(int32_t a1) {
    // 0x34
    if (a1 == 1) {
        // 0x88
        unknown_13e2bc();
        return unknown_13e0a8();
    }
    // 0x44
    if (a1 < 2) {
        // 0x50
        if (a1 != 0) {
            // 0x58
            return unknown_13e0a8();
        }
        // 0x78
        unknown_13e0bc();
        return unknown_13e0a8();
    }
    // 0x64
    if (a1 != 2) {
        // 0x6c
        return unknown_13e0a8();
    }
    // 0x9c
    unknown_b5078();
    *(int16_t *)(unknown_b50fc() + 12) = 0;
    unknown_13e270();
    return -0x7fec1a38;
}

// Address range: 0xf0 - 0x2a3
int32_t function_f0(int32_t a1) {
    int32_t v1 = 0; // $s4
    int32_t v2 = -0x7ff0f8f8; // $s0
    int32_t v3 = 0; // $s3
    int32_t v4 = -0x7ff0f8d8; // $s2
    int32_t v5 = a1; // $s1
    int32_t v6 = *(int32_t *)(a1 + 4) + a1; // 0x14015
    int32_t v7 = v6; // $v1
    int32_t v8 = v6;
    int32_t * v9 = (int32_t *)-0x7ff0f8f4;
    if (*(int32_t *)(a1 + 8) + a1 == v6) {
        int32_t v10 = -0x7ff0f8f8; // 0x1c417
        int32_t v11; // bp+140
        int32_t v12;
        while (true) {
            int32_t * v13 = (int32_t *)v10;
            *v13 = *v13 & -1793;
            v12 = v2;
            int32_t v14 = v12 + 44;
            v2 = v14;
            v3 += 44;
            v4 += 44;
            int32_t v15 = v1 + 1;
            v1 = v15;
            int32_t v16 = v5;
            v5 = v16 + 4;
            if (v15 >= 4) {
                int32_t v17 = -0x7ff10000; // $a0
                *(int16_t *)-0x7ff0f840 = 4;
                *(int32_t *)(v17 + 1980) = *(int32_t *)(a1 + 20) + a1;
                if (*(int32_t *)(a1 + 24) + a1 != *(int32_t *)(a1 + 20) + a1) {
                    // 0x21c
                    *(char *)-0x7ff1b1e9 = 50;
                    return unknown_bbb60();
                }
                // 0x214
                *(int32_t *)(v17 + 1980) = 0;
                // branch -> 0x21c
                // 0x21c
                *(char *)-0x7ff1b1e9 = 50;
                return unknown_bbb60();
            }
            // 0x1a8
            v11 = *(int32_t *)(v16 + 8) + a1;
            v7 = v11;
            if (*(int32_t *)(v16 + 12) + a1 != v11) {
                // break -> 0x134
                break;
            }
            v10 = v14;
            // continue -> 0x1a8
        }
        // 0x134
        v8 = v11;
        v9 = (int32_t *)(v12 + 48);
        // branch -> 0x148
    }
    // 0x148
    *v9 = *(int32_t *)(v8 + 4) + v8;
    int32_t v18 = *(int32_t *)(v7 + 8);
    *(int32_t *)(v2 + 8) = v18 + v7;
    int32_t v19 = *(int32_t *)(v7 + 12);
    *(int32_t *)(v2 + 12) = v19 + v7;
    unknown_bbb20();
    int32_t * v20 = (int32_t *)v2;
    *v20 = *v20 | 1792;
    unknown_bfba0();
    return unknown_13e198();
}

// Address range: 0x2a4 - 0x2ef
int32_t function_2a4(int32_t a1) {
    unsigned char v1 = *(char *)((unknown_30ca4() % 2 | -0x7ff11f18) + 3294);
    *(int16_t *)-0x7ff0eda0 = (int16_t)v1;
    return unknown_c69c4();
}

// Address range: 0x2f0 - 0x313
int32_t function_2f0(int32_t a1) {
    // 0x2f0
    return unknown_bdb8c();
}

// Address range: 0x314 - 0x573
int32_t function_314(void) {
    int32_t v1 = unknown_b5d10(); // bp+340
    int32_t v2 = 0; // $s4
    bool v3 = true; // $fp
    int32_t v4 = -0x7ff0f8f4; // $s6
    int32_t v5 = -0x7ff0f8f8; // $s3
    int32_t v6 = -0x7ff0f8e4; // $s2
    int32_t v7 = -0x7ff0f8d8; // $s5
    *(int16_t *)(v1 + 64) = 320;
    *(int16_t *)(v1 + 66) = 216;
    *(int16_t *)(v1 + 60) = 0;
    *(int16_t *)(v1 + 62) = 0;
    *(int32_t *)(v1 + 72) = -1;
    *(int32_t *)(v1 + 44) = *(int32_t *)-0x7ff0e7d4;
    *(int32_t *)(v1 + 56) = *(int32_t *)-0x7ff04ae8;
    // branch -> 0x3b4
    while (true) {
        // 0x3b4
        if ((*(int32_t *)-0x7ff0f8fc & 4) == 0) {
            // 0x3c8
            if (unknown_bf670() != 0) {
                // 0x3dc
                unknown_bfba0();
                // branch -> 0x3ec
            }
            // 0x3ec
            // branch -> 0x3f0
        }
        // 0x3f0
        if (v2 != 3) {
            // 0x3f4
            unknown_bfde8();
            return unknown_13e464();
        }
        // 0x40c
        *(int16_t *)(v1 + 4) = 0;
        *(int16_t *)v1 = 0;
        *(int16_t *)(v1 + 2) = (int16_t)(*(int32_t *)-0x7fec1a4c / 8);
        unknown_2e658();
        unknown_30710();
        int32_t * v8 = v3 ? (int32_t *)-0x7ff0ed54 : (int32_t *)20;
        *(int32_t *)(v1 + 28) = *v8;
        int32_t * v9 = v3 ? (int32_t *)-0x7ff0ed50 : (int32_t *)24;
        *(int32_t *)(v1 + 32) = *v9;
        int32_t * v10 = v3 ? (int32_t *)-0x7ff0ed4c : (int32_t *)28;
        *(int32_t *)(v1 + 36) = *v10;
        unknown_bfde8();
        if (*(int32_t *)-0x7ff0f8fc % 2 == 0) {
            int32_t v11 = *(int32_t *)-0x7fec1a4c; // bp+488
            *(int32_t *)-0x7fec1a4c = v11 + (int32_t)*(int16_t *)-0x7ff0f840;
            // branch -> 0x498
        }
        int32_t v12 = v5; // bp+498
        uint32_t v13 = *(int32_t *)v12; // bp+498
        uint32_t v14 = v13 / 512;
        int32_t v15 = v12; // bp+520
        int32_t v16; // bp+528
        if ((v13 & 256) != 0) {
            // 0x4ac
            if (v14 % 2 != 0) {
                // 0x4b8
                *(int16_t *)(v1 + 76) = *(int16_t *)(v12 + 2);
                *(int32_t *)-0x7ff049f0 = unknown_bdda4();
                v15 = v5;
                // branch -> 0x51c
            } else {
                v15 = v12;
            }
            // 0x51c
            v4 += 44;
            v5 = v15 + 44;
            v6 += 44;
            v16 = v2 + 1;
            v2 = v16;
            v7 += 44;
            if (v16 >= 4) {
                // break -> 0x534
                break;
            }
            // continue -> 0x3b4
            continue;
        }
        // 0x51c
        v4 += 44;
        v5 = v15 + 44;
        v6 += 44;
        v16 = v2 + 1;
        v2 = v16;
        v7 += 44;
        if (v16 >= 4) {
            // break -> 0x534
            break;
        }
        // continue -> 0x3b4
    }
    // 0x534
    return unknown_b5d6c();
}

// Address range: 0x574 - 0x5bb
int32_t function_574(int32_t a1) {
    int16_t * v1 = (int16_t *)(a1 + 12);
    int16_t v2 = *v1;
    if (v2 == 0) {
        // 0x5a0
        *v1 = (int16_t)((int32_t)*v1 + 1);
        return unknown_13e57c();
    }
    // 0x588
    if (v2 != 1) {
        // 0x594
        return unknown_13e57c();
    }
    // 0x5a8
    unknown_13e2e0();
    return 0;
}

// --------------------- Meta-Information ---------------------

// Detected compiler/packer: gcc
// Detected functions: 6
// Decompiler release: v2.1.2 (2016-01-27)
// Decompilation date: 2016-07-05 18:14:25
You can of course see some totally wrong this like:
int32_t * v8 = v3 ? (int32_t *)-0x7ff0ed54 : (int32_t *)20;
^I do not understand why there are negative values. This looks like address, so 20 is also wrong.
Although the first function seems to be correct with the IDA disassembly.

Graphs:
(https://s19.postimg.org/wrlurnihb/Stage_Code_MIPS_cfg_function_2a4.png) (https://postimg.org/image/wrlurnihb/)

(https://s19.postimg.org/k1hmekaj3/Stage_Code_MIPS_cfg_function_2f0.png) (https://postimg.org/image/k1hmekaj3/)

(https://s19.postimg.org/sl10cbivj/Stage_Code_MIPS_cfg_function_34.png) (https://postimg.org/image/sl10cbivj/)

(https://s19.postimg.org/k41i1ee6n/Stage_Code_MIPS_cfg_function_314.png) (https://postimg.org/image/k41i1ee6n/)

(https://s19.postimg.org/rlapgm3pr/Stage_Code_MIPS_cfg_function_574.png) (https://postimg.org/image/rlapgm3pr/)

(https://s19.postimg.org/iesetbyhb/Stage_Code_MIPS_cfg_function_f0.png) (https://postimg.org/image/iesetbyhb/)

(https://s19.postimg.org/e727ybmfj/Stage_Code_MIPS_cg.png) (https://postimg.org/image/e727ybmfj/)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2016-07-08 11:57:11
Battle camera:

00B8B7D8 int  _battleCamera_worldXZ:
 This & FFFF0000 : Camera world location on X axis
 This & 0000FFFF : Camera world location on Z axis (up-down)

00B8B7DC int? _battleCamera_worldY: Camera world location on Y axis

00B8B7E0 int _battleCamera_LookAtX: Camera look-at target location on X axis in world. Maybe the other sint16 is Z axis, but I can't prove this

00B8B7E4 int _battleCamera_LookAtY: Camera look-at target location on Y axis in world. Changing the other sint16 doesn't seem to do anything?

Camera is always looking at look-at target.
Title: Re: [FF8] .x battle fields
Post by: paul on 2016-07-09 16:14:44
Maybe its more:

int32_t * v8 = v3 ? (int32_t *)-0x7ff0ed54 : (int32_t *)20;
*(int32_t *)(v1 + 28) = *v8;

Is

*(int32_t *)(v1 + 28) = v3 ? -(int32_t *)0x7ff0ed54 : 20;

And v1 is clearly some structure so it would actually be:

int32_t* g7ff0ed54; // some unknown global
v1->Field_28 = v3 ? -*g7ff0ed54 : 20;
Title: Re: [FF8] .x battle fields
Post by: Maki on 2017-02-19 20:45:14
Gold shovel for me! :)

After ten hours of extensive work I finally made it to produce my own battle stage from scratch and create working tool to convert OBJ meshes to FF8 battle stage. It's still mess as it's hard as hell (The UVs are messed up, there's also MOD jump that needs extreme amount of testing and also unknown GPU byte that sometimes needs to be 0x24 and sometimes 0x2C or sometimes all it show is just black screen)
Anyway, I'm tired, this is proof:
(https://s19.postimg.org/qec7296mr/actual.jpg)
It crashes after finishing camera animation in un-reversed function so I don't know what's messed up. I never had such problems earlier with test geometries before.
As it's now it doesn't require any manual tweaking
(https://s19.postimg.org/pdbyd4pn7/repack.jpg)
(https://s19.postimg.org/7ok7lidw3/max.jpg)
I made some further tests and...
actually FF8 supports triangles, quads and two unknown (in wiki I noted it as padding as it's always 00, but in code it's actually get parsed just like triangles and quads, touching that produces glitches)
FF8 doesn't support 24BPP textures
FF8 doesn't support second TIM texture, it's just a binary leftover, the engine never touches this
That might be all

Fast 5k triangle test (It's much more than the most complicated battle stage):
(https://s19.postimg.org/tqahvjydv/bak.jpg)
No problems at export, everything is fine. FF8 loads it without problems but there are a lot of graphical bugs, maybe I should split the meshes like in original FF8?
Anyway that's how it looks before it vanishes at the end of camera animation and soon after crashes(I think I know why, but I need to prove it)
(https://s19.postimg.org/gkuzpg4ib/actual.jpg)
Title: Re: [FF8] .x battle fields
Post by: paul on 2017-02-22 21:29:30
Have a look at psx gpu prims, the other types probably match onto that, POLY_FT4 etc. Perhaps the other types are g/flat/untextured shaded tri and quad?
Title: Re: [FF8] .x battle fields
Post by: Maki on 2018-06-26 13:22:15
I managed to somewhat break the camera structure. I updated http://wiki.ffrtt.ru/index.php/FF8/FileFormat_X#Camera_data

Case study:
a0stg101.x - balamb plains:

0x5D8 - camera start [via code]
02 00 is skipped
08 00 is pointer to camera settings
20 00 is pointer to camera animation

Let's jump to camera animation as it's the most important part here.

We will end up at 0x32. This is sub-section. We will work with pointers relatively to this position.
You'll get a ushort for number of camera animations - in this example it's 7. [a0stg101.x have 7 sets, therefore 7*8 animations, but a0stg000 or a0stg001 don't remember but they have only one!, so 1*8 animations!]

Now, when the game starts and encounter is loaded it magically resolves which animation to use to show the enemy well. You can of course break at getting camera anim index code and change the register so the camera will present the enemy like it's T-rex showing only one mosquitoe (I don't remember that fly name on Balamb's plain).

So, we are at pointers indicator, the engine now:
EAX + ECX*2 + 02, where:
-EAX - absolute memory pointer to 07 00 or 08 00 as said above;
-ECX - the camera index that it got from from static memory (pointer to pointer to some packed binary values)
02 - size of numberOfAnimations

Let's jump to last animation now:
considering 07 00 in our file is now offset 0x00:
(7-1)*2+2 = 0xE //because 00 means first index, so 7th index is in fact 6*2

Now get ushort pointer at 0xE= 0x1F10;
We will get to 0x1F10. Engine now reads 8 pointers, like in this case first pointer is 08 00 and next is 48 00. Now it calculates it by pointer*2. So first pointer actually starts at 0x16, second at 0x48*2=0x90.

UPDATE3:
grab the useful breakpoint:
0x5035AB (Newest steam english).

UPDATE4:
Engine camera animation parsing at: sub_503C8F
checking for FFFF: 00503C7B:
cmp ax, 0xFFFF, where ax is *(019399E2) (cameraSet 1+ anim 5)

Operands are bit operated...

There:
(https://s19.postimg.cc/lgis3z8pt/JPG.jpg)
Title: Re: [FF8] .x battle fields
Post by: Maki on 2019-01-04 13:00:52
New updates!

I wrote a python script to dump the pointers to cameras:
https://gist.github.com/MaKiPL/e0f2e36b5edb560ff047e12a33aba9be

Use it like shown here:
(https://i.postimg.cc/Mppmr31N/exm.png)

It requires python 2.7
also I updated the wiki page and uploaded the video:
https://www.youtube.com/watch?v=R9Y9PEhlMhs&t=2s
Title: Re: [FF8] .x battle fields
Post by: JWP on 2019-02-18 13:49:56
The structure that the camera animation is loaded into looks like:
Code: [Select]
struct CameraStruct {
BYTE unkbyte000; //000
BYTE unkbyte001; //001 keyframe count?
WORD control_word; //002
WORD unkword004; //004
WORD unkword006; //006
WORD unkword008; //008
WORD unkword00A; //00A
WORD unkword00C; //00C
WORD unkword00E; //00E total frame count/time?
BYTE unk[20] //010
short unkword024[32]; //024 - start frames for each key frame?
short unkword064[32]; //064
short unkword0A4[32]; //0A4
short unkword0E4[32]; //0E4
BYTE unkbyte124[32]; //124
short unkword144[32]; //144
short unkword184[32]; //184
short unkword1C4[32]; //1C4
BYTE unkbyte204[32]; //204
BYTE unkbyte224[128]; //224
BYTE unkbyte2A4[128]; //2A4
BYTE unkbyte324[128]; //324
BYTE unkbyte3A4[128]; //3A4
BYTE unkbyte424[128]; //424
BYTE unkbyte4A4[128]; //4A4
};
and the function that parses the animation into it looks something like:
Code: [Select]
short* parse_camera(short* camera_data, CameraStruct* cam) {
short* local2C;
BYTE keyframecount;
WORD totalframecount;
short* local1C;
short* local18;
short* local14;
short* local10;

short* current_position = camera_data;
if (*current_position == 0xFFFF) {
return NULL;
}

cam->control_word = *current_position;

current_position++;
totalframecount = 0;
keyframecount = 0;
switch ((cam->control_word >> 6) & 3) {
case 1:
cam->unkword004 = 0x200;
cam->unkword006 = 0x200;
break;
case 2:
cam->unkword004 = *current_position;
cam->unkword006 = *current_position;
current_position++;
break;
case 3:
cam->unkword004 = *current_position++;
cam->unkword006 = *current_position++;
break;
}

switch ((cam->control_word >> 8) & 3) {
case 0:
cam->unkword008 = ff8vars.unkword1D977A2;
cam->unkword00A = ff8vars.unkword1D977A2;
break;
case 1:
cam->unkword008 = 0;
cam->unkword00A = 0;
break;
case 2:
cam->unkword008 = *current_position;
cam->unkword00A = *current_position;
current_position++;
break;
case 3:
cam->unkword008 = *current_position++;
cam->unkword00A = *current_position++;
break;
}

switch (cam->control_word & 1) {
case 0:
if (*current_position >= 0) {
do {
cam->unkword024[keyframecount] = totalframecount;
totalframecount += *current_position++ * 16;
cam->unkbyte124[keyframecount] = *current_position++;
cam->unkword064[keyframecount] = *current_position++;
cam->unkword0A4[keyframecount] = *current_position++;
cam->unkword0E4[keyframecount] = *current_position++;
cam->unkbyte204[keyframecount] = *current_position++;
cam->unkword144[keyframecount] = *current_position++;
cam->unkword184[keyframecount] = *current_position++;
cam->unkword1C4[keyframecount] = *current_position++;
keyframecount++;
} while (*current_position >= 0);

if (keyframecount > 2) {
ff8funcs.Sub50D010(cam->unkword024, cam->unkword064, cam->unkword0A4, cam->unkword0E4, keyframecount, cam->unkbyte224, cam->unkbyte2A4, cam->unkbyte324);
ff8funcs.Sub50D010(cam->unkword024, cam->unkword144, cam->unkword184, cam->unkword1C4, keyframecount, cam->unkbyte3A4, cam->unkbyte424, cam->unkbyte4A4);
}
}
break;
case 1:
if (*current_position >= 0) {
local14 = current_position + 5;
local10 = current_position + 6;
local2C = current_position + 7;
local18 = current_position + 1;
local1C = current_position + 2;
short* ebx = current_position + 3;
do {
cam->unkword024[keyframecount] = totalframecount;
totalframecount += *current_position++ * 16;
ff8funcs.Sub503AE0(++local18, ++local1C, ++ebx, *(BYTE*)current_position, &cam->unkword064[keyframecount], &cam->unkword0A4[keyframecount], &cam->unkword0E4[keyframecount]);
ff8funcs.Sub503AE0(++local14, ++local10, ++local2C, *(BYTE*)(current_position + 4), &cam->unkword144[keyframecount], &cam->unkword184[keyframecount], &cam->unkword1C4[keyframecount]);
cam->unkbyte204[keyframecount] = 0xFB;
cam->unkbyte124[keyframecount] = 0xFB;
local1C += 8;
local18 += 8;
current_position += 8;
local2C += 8;
ebx += 8;
local10 += 8;
local14 += 8;
keyframecount++;
} while (*current_position >= 0);

if (keyframecount > 2) {
ff8funcs.Sub50D010(cam->unkword024, cam->unkword064, cam->unkword0A4, cam->unkword0E4, keyframecount, cam->unkbyte224, cam->unkbyte2A4, cam->unkbyte324);
ff8funcs.Sub50D010(cam->unkword024, cam->unkword144, cam->unkword184, cam->unkword1C4, keyframecount, cam->unkbyte3A4, cam->unkbyte424, cam->unkbyte4A4);
}
}
break;
}

if ((cam->control_word & 0x3E) == 0x1E) {
ff8funcs.Sub503300();
}

cam->unkbyte001 = keyframecount;
cam->unkword00E = totalframecount;
cam->unkword00C = 0;
return current_position + 1;
}

note: adding to a word pointer adds 2 to the value.
The size of the animation depends a lot on the control word and the amount of keyframes.
I haven't verified the code completely but it should be roughly correct with some possible minor errors.