[FF8] world map and objects (world.fs)

  • Thread starter Thread starter Halfer
  • Start date Start date
Status
Not open for further replies.
You're a God Halfer! :)

It works indeed.
e12c0f4adc.jpg


Balamb part is at 1d13000-1d198a0.
Towns and garden is made from triangles and is part of world map, so yes, towns are in wmx.obj.

Also, I'm like 70% sure rail.obj is for trains movement. Deleting file makes train blink sometimes and go crazy on world map. Like show for 1/2 second on center of sea.

@EDIT: I don't know if it's in fact vertex data, probably not, but one byte operates shadow. Probably that unknown data is about shadowing.
 
Last edited:
Yeah, that would probably make sense. In the water sections where there is only water blocks the "shadow" part is only 0x01 long which is 8 bytes right after vertex data. That is probably why I had trouble looking at that data because the sea doesn't really need shadowing. However it looks like in continents and other areas where "ground" is present the "shadow" data matches the amount of vertices which may indeed be for shadowing. I'll edit this to structures.

So towns are in wmx.obj? That's interesting. I wonder where the sections are set to match the exact position in world. I looked in FF7 wiki for the world info and in FF7 files it seemed to be separate file which handled the positioning of loaded sections. I'm starting to feel that they are coded in .exe, hopefully not.

EDIT: Also worth to mention that the vertices can be positioned outside it's block and section but the collision settings don't follow the boundaries, but are stitched to its block or section boundaries. In other words the section which is subject to world has priority on its own area. Here's an example:

1fc4c3ed05ccf7750859ca8e29a61acf.png


Here the vertices are stretched on top of other section and while I can walk on the current area, I can't go over the area which is on top of water.

I'm not 100% if this is how it really works or if there are exceptions, but right now this seems logical.
 
Last edited:
Cool!

In the first post I stated that there was 768 segments in the world map and I based that in that 835 segments value since I found out that the last segments include great salt lake, the bridge and other areas. Seems like in reality it may be even less, maybe half of the size or something, since the sections don't need to be the same size unless they are preset somewhere.
 
Great breakthrough! Since you're both working on this, is it possible to use the hi-res worldmap textures and the UV coordinates from the PSX version?

Don't know if someone noticed before but PSX textures are better than PC as for the worldmap;  I've been looking in the world.fs file and there is 2 kinds of worldmap textures, one is low res and the other is 2 times bigger; the road doesn't even have borders... is the PC version uses the low res textures only ?

1419045508-worldmap.png
Click to expand...
 
Great breakthrough! Since you're both working on this, is it possible to use the hi-res worldmap textures and the UV coordinates from the PSX version?
Click to expand...
This is an interesting question. I still haven't looked on the textures for much but what I've been taking to note is that it should be possible to give faces a bigger resolution texture, so hi-res textures may be possible in the future. As for PSX version, there isn't any reason for PC to be any different when speaking of textures since they are similar. However it seems like the UV calculation for road isn't correct thus making the white lines disappear. It can also be that PSX version uses some polished version of PC world map, one way to confirm this is to get the wmx.obj from PSX files and import it to PC version assuming that the file hierarchy is same.
 
Last edited:
I could run a BinDiff on those two files, but I only have a PSN version of FF8, so I would have to "download" one.
 
Well I have PSX version on my parents house, but I can't get it for a while :P. But I hardly doubt that the files differ from each other, it may be instruction related problem with PSX GPU and computer GPU. But if that's not the case then the PC is indeed an older version of world map which is pretty hard to believe because it was released later than PSX.
 
Last edited:
I found it little hard to browse FF8DISC1.img, as almost every extractor for PSOne files is dead. I had to manually extract it. My HexEditor just exploded, so had to work with buffer blockcopy. Thank you Visual Studio. <3

wmx.obj:
FFVIII Steam 2013: A594059C0D6D16F5DBEB8A82C4BE696FEB8A0E3D
FF8DISC1.IMG 0x108800 (size: 0x1D5B000): A594059C0D6D16F5DBEB8A82C4BE696FEB8A0E3D
FF8DISC1.IMG 0x19C8800 (size: 0x1D5B000): 500A79C34243AE19A49078BF36AB156C361F1043
FF8DISC1.IMG 0x388B800 (size: 0x333000): 950BCB3B5C8A3FE7F236C248044EC44653781329

This is a bit confusing. Offset 108800 is the same file that is present in Steam release. I'll run a BinDiff on 0x19C8800 and Steam one.

Update: There is a massive difference in 0x108800 and 0x19C8800 file. See the example:
351adf35d9.png

 
I'll replace Steam wmx.obj with 0x19C8800 dump.

Well. It works. xD But I'm stuck inside some mountain and I can't move. Wait, I'll force ragnarok.

What the...

621e97982c.jpg
 
Last edited:
haha :D, seems like there is 2 wmx.obj in the psx image file? That's odd.
 
Probably done like FF7 where this is grid map and optimized for cd loading map?
 
If by grid map you mean the placement of sections and how they are loaded to match the map, it isn't like FF7. In FF7 they are separate files and in FF8 there is only wmx.obj container which contains the sections and other files which contain textures. However there may be the placements also but I think they are coded in .exe for optimization.

Edit: Well, to be honest, I don't even know that yet. wmx.obj is 30MB big and I'm 99% sure that it contains only the geometry and texture calls. Other files mostly contains textures, but there're still lot to inspect. If these files contains the geometry placements, then it's packed very well compared to what FF7 respective data takes.

Edit 2: As I suspected, I found water geometry and texture calls from wmsetus.obj, but it's only size of a block when comparing to wmx.obj. It does contain much more data than the models itself, probably metadata mostly. I'll take closer look tomorrow for wmsetus.obj since I can't manage to get any information from wmx.obj for now because the texture calls don't make sense.
 
Last edited:
Okay, little analysis I did today. Here's what I documented:

Tested by nullifying these offsets from the beginning of wmsetus.obj and little inspection from the offset also.
wmsetus.obj:

0xB38 contains texture calls for rails and streets. There are 13 different pieces which have own texture. Each call is 4 bytes long and is somehow connected to their respective texture.

0xB70 contains data for the transition from world to fields. If offset indicator from the beginning of file is nullified you can't enter towns, except ragnarok cockpit (probably garden also).

0x18D0 has something to do with visibility of world models, especially ragnarok.

0x1CE0 has something to do with lunatic Pandora on tear’s point, nullifying offset indicator disables whole entry.

0x21B8 contains world map dialogues, probably all the texts that are shown in world map.

0x1AB04 contains color and lighting options for world map.
 
Last edited:
Okay, little analysis I did today. Here's what I documented:

Tested by nullifying these offsets from the beginning of wmsetus.obj and little inspection from the offset also.
wmsetus.obj:

0xB38 contains texture calls for rails and streets. There are 13 different pieces which have own texture. Each call is 4 bytes long and is somehow connected to their respective texture.

0xB70 contains data for the transition from world to fields. If offset indicator from the beginning of file is nullified you can't enter towns, except ragnarok cockpit (probably garden also).

0x18D0 has something to do with visibility of world models, especially ragnarok.

0x1CE0 has something to do with lunatic Pandora on tear’s point, nullifying offset indicator disables whole entry.

0x21B8 contains world map dialogues, probably all the texts that are shown in world map.

0x1AB04 contains color and lighting options for world map.
Click to expand...
I learned a lot by modding the textures using Tonberry for the world map... here are a few notes:

1:  UV's are incorrect on the PC worldmap - textures are not 'seamless' and strange artifacts happen over the textures where the walkmesh is either 'doubled' over itself, causing strange wrapping issues, or some kind of glitch is present.

2:  The Ocean, Roads, and a couple other 'animation' effects that exist in the world map all 'rotate' to the same cycle of sprites.  If you change a 'road' texture from intercepting the textures at ram with hash-codes, unless you use a code that 'overrides' the entire animation, the road blinks between animation sprites.  As for the rails/streets Halfer was talking about - the textures for them are all on one texture page.

3:  When you are using the English version and are on the ground, the world textures are hi-res -- if you're flying around the world in the Ragnarok, textures 'pop' back down to lower resolution, so this behavior might help you guys figure out what's going on.

Thanks for all your hard work!
 
I learned a lot by modding the textures using Tonberry for the world map... here are a few notes:

1:  UV's are incorrect on the PC worldmap - textures are not 'seamless' and strange artifacts happen over the textures where the walkmesh is either 'doubled' over itself, causing strange wrapping issues, or some kind of glitch is present.

2:  The Ocean, Roads, and a couple other 'animation' effects that exist in the world map all 'rotate' to the same cycle of sprites.  If you change a 'road' texture from intercepting the textures at ram with hash-codes, unless you use a code that 'overrides' the entire animation, the road blinks between animation sprites.  As for the rails/streets Halfer was talking about - the textures for them are all on one texture page.

3:  When you are using the English version and are on the ground, the world textures are hi-res -- if you're flying around the world in the Ragnarok, textures 'pop' back down to lower resolution, so this behavior might help you guys figure out what's going on.

Thanks for all your hard work!
Click to expand...
Really? That's useful, thanks!
Couple questions though. You are saying that rails/streets are on one texture page. Do you know this for sure because tim viewer separates them as own images. Though if they are on same page then the hex values would make sense also.

And the hi-res textures. I don't seem to see any kind of difference in textures while on ragnarok or ground. Is there a setting which operates this behavior in ff8config?

Also, 0x15CC contains placement to world from field. Here's ending replicated in world map :P
c7b2b6ba1572979b57198cb35bd1c4e3.gif
 
Last edited:
Really? That's useful, thanks!
Couple questions though. You are saying that rails/streets are on one texture page. Do you know this for sure because tim viewer separates them as own images. Though if they are on same page then the hex values would make sense also.

And the hi-res textures. I don't seem to see any kind of difference in textures while on ragnarok or ground. Is there a setting which operates this behavior in ff8config?
Click to expand...
It's hard to tell because the images are so pixelated anyway, but have you used tonberry?  If you want to run a test, you can install Tonberry (1.6 or later), then install my 'horizonpack' mod and disable the low res png's by removing wm_texpg_low1, _low2, and _low3 from the 'wm' textures folder.  Then hop on ragnarok in Balamb and then dismount.  You will see how the textures are being swapped back and forth.

When I get a debug dump from Tonberry, I get a single bitmap dump with all 16 road/textures in one image - and Tonberry -normally- doesn't dump single textures, but the entire page the texture came from (sometimes this is estimated, since all blocks come into Tonberry as 256px images, even though many texture pages are 128x256, 128x128, 256x128, etc.  These textures fit in a 256x128 bitmap, I believe.
 
This is World map with wmsetus.obj with null'ied all textures. 0x1cbd8-0x86cf8 (First file which textures are in center of file, not at the ending)
5ce84ba4ef.jpg


NOTE: wmsetxx.obj also is responsible for forest walking particle. I have some theory about that ragnarok texture change. Give me a sec, gonna test it.

As I thoughŁ
2e3f9d7482.jpg


The textures in wmsetus(sp/it...).obj of world map are for Ragnarok. When you ride ragnarok, the game loads 1/2 sized textures from wmsetus.obj. When you land, the game loads texl.obj file.

TOWNS textures are gone too!
 
Last edited:
I see.... I can't replicate this for some reason. I nullified the textures from the file like this but I still see all the textures??:

Notice that the first texture is the water textures!
0556a5626da0495c2b447de69817fcf4.png


0d9c33c026eb54f8dcc460b3a3d847c8.png


b465726310cf8e1acfcf8d9ce1f48889.png
 
Oh, I mean that is how timviewer shows my wmsetus.obj when I nullified the header of tim textures. I nullified 6 or 7 textures from the beginning and 117720 is the first texture offset for me also. I just tried to demonstrate that for me the textures didn't change for some reason while and while not in ragnarok. I wonder if i have some settings differently because I use dxwnd for windowed screen
 
Status
Not open for further replies.
Back
Top