Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
There is 349 MAGxxx.X files referenced in executable.
I'm not sure about the animated meshes. For example the time compression where you fight multiple sorceress you can see the battlefield vertices falling to the ground. That however could be done with a script so they are probably just a0stgxxx.X battlefields.
Not only GF environments I think. For example I have a pretty high suspect that Squall's blasting zone animation includes 3d geometry as well as Quezacotl's entry animation. That is based on the moving clouds which looks moving like the battle stage clouds, in circular rotation.
Okay. Naming cracked:
mag094_b.XyN
where:
X- Sequence number
y- Data type
N- ID number
Example:
mag094_b.2s2 is Sequence number two (read below about Siren's sequences), second geometry model (s2)
Siren sequences:
1- Sea is flooding enemy
2- Siren is playing on harp
3- "ending" point where there's effect of echo like rings on enemies.
MILESTONE! I got this. 1sN files are having header with offsets to data portions!
Case mag094_b.1s0:Code: [Select]offset point_offset data
1 1 header?
4 13664 UNKNOWN
8 12 Probably vertices? (with weight)
12 9012 Just a bit before quad data
I tried memory hacking and wipping out mag094_b.2s3, I left only header (containing pointers) and null'ied everything else. NOTHING. But when I try to delete whole file (so in fact 12B header) the game doesn't hop to sequence 2 and stops in infinite loop at the latest keypoint in sequence 1. Mhm... ;/
Okay. I got this:
Okay, almost every time in naming XyN where y is 's' the file build is:
First 4 bytes: count of pointers
Next 4bytes*count_of_pointers = pointers (for 4 bytes)
INDEX is NOT zero! That means, if count_of_pointers = 01 00 00 00 then real count is ==1, 06 00 00 00 is 6 (six) pointers and 00 00 00 00 is zero pointers (in some cases in data 00 means 1, that's what I mean)
That is the reason why the UV's are misplaced in the PC version and the road does not show the white lines.
Hey guys! I'm not sure if I'm following the issues with the road/rail textures properly, but this is the image that Tonberry dumps in the debug folder:
The image is always 256x256 in tonberry, because it takes a snapshot of the vram, but it looks like the TIM is actually 128x64 in a set of anywhere from 13-18 palettes - I haven't found the .TIM in tim viewer.
@UPDATE3: Altering accessed variables makes extremely weird things. For example spams with message "This shouldn't go now...", warping to Balamb, hidden emergency capsule (after coming from space), calling battle with UFO encounter... Weird.
@UPDATE4: Hello human... What a lovely tune.
@UPDATE5: "There is a stone pillar. If you look closely, there's something written on it"[/i]
..by the way if you are wondering how I got your code changes is because I was too lazy to ask for source and decompiled your code, sorry about that.
@kaspar01
Those castle portals are stored in wmsetXX.obj, I did a lot of studies on that before and I'm 90% sure that it contains the portals because it does contain lunatic pandora and other models used for world map.
Hey guys! I'm not sure if I'm following the issues with the road/rail textures properly, but this is the image that Tonberry dumps in the debug folder:
The image is always 256x256 in tonberry, because it takes a snapshot of the vram, but it looks like the TIM is actually 128x64 in a set of anywhere from 13-18 palettes - I haven't found the .TIM in tim viewer.
Oh btw, one thing about high resolution textures occurred to me sometime ago.
If we assume that the engine can handle larger size texture pages like 512x512, since it can manage 256x256 over 128x128, it could be possible to replace these files in wmsetXX.obj (and why not in texl.obj but it's not used in old release). The only thing I can see limiting this is that the headers are pointing to specific location in the file, so by changing those it could be possible to replace the old ones in the file. That will not work on texl.obj however because it doesn't have any headers.
Just a thought but should be worth a try, unless the wmsetXX.obj needs to be certain size.
I'll make that happen in new version. However would you really prefer if each segment was separate .obj file? I mean isn't it frustrating to import each file? If not then I can make a setting to change these properties so you can choose if you want it stitched or separated.
My code already names the segments in the obj file with corresponding integer id,so that 3ds max will import them as seperate mesh parts.
I added this code for exporting each segment as a separate wavefront part hope it would please someone.
not sure about javascript and how I am passing the segments as I converted my code from C++
That's really odd, I don't seem to get the same errors for some reason:Hum... maybe it's a 3ds max problem?
Well anyway, all the texture related problems should be corrected after next update except transparency which has to always be done manually. I'll release the updated version once I get normals working, textures corrected and the segment swapping done, may take a whileIf I may help you somehow let me know
Yeah I'll fix that .mtl file to not be mandatory to export everytime.
About invalid texture index. That's odd, I maybe encountered it once or twice when I first made the code but never after that. Do you know specific sections which launches this bug?Would help me to fix is ASAP.Actually if it's not severe issue I'll fix it with next update since the optimization should fix those kind of problems and also would make much less lag while editing the mesh.
About normals. I documented in reverse engineer forums that wmx.obj contains some sort of shadowing values. Well I now know that they are normals and probably used for Gourard shading which PSX GPU can utilize (look it up if interested). For the next version I'll include normals too so the shading is not a problem after it. Though before I put normals in use I want to improve to current algorithm for texture vertexes because right now it's taking too much memory as you can see from the file size. After optimizing the algorithm I would say the file size will drop about 1/4 or 1/3
I had to check the seam thing and it appears in FF8 also
Sorry for the first picture but I hope you can see it, my FF8 uses 128x128 textures since it's the older release. However these kind of problems occurs all over the map because of the developers. Also the odd stretches like in the kaspar01's picture are misplaced UV's by developers. There's probably nothing that can be done automatically to these unless all the UV's are re-generated.
However it looks better in game because of the renderer which makes it look more seamless, although the problem exists there even if it's harder to notice.
Interchangeables zones:
Eshtar
374 to 381 <==> 769 to 776
406 to 413 <==> 777 to 784
438 to 445 <==> 785 to 792
470 to 477 <==> 793 to 800
502 to 509 <==> 801 to 808
534 to 541 <==> 809 to 816
566 to 573 <==> 817 to 824
Trabia Garden
150 to 151 <==> 825 to 826
Galbadia Garden
268 <==> 827
Balamb Garden
275 to 276 <==> 828 to 829
Missile Base
328 <==> 830
Trabia Crater
215 to 216 <==> 831 to 832
247 to 248 <==> 833 to 834
Desert Prison
362 <==> 835
Seems like the road now has the white lines like in the PSX version. Show me if you see any UV misplacement's so I can try to fix them
Can I get a close-up of the train tracks? I'm interested in making a metro map of those (Once an for all)it's really low poly and low res but here it is : http://s2.postimg.org/jqe3yenjc/close_up.jpg
Well the UV's don't depend on the resolution so you can put higher or lower resolution images in blender or 3dsmax. However I'm not sure what happens to UV's when you put for example 1024x1024 texture, it may be messed up a bit, but then it's just a matter of new calculation and that's it. Speaking of it I can make an improvement so that when you export the world map you can choose which resolution textures you want to use so it doesn't mess up the UV's.
The problem with the UV placement is that they are presented in hex values 0-255, so I have to manually do the calculations because for example 0x7f is 127 in decimals and 127/255 = 0.498... while it's supposed to be 0.5 on UV grid.
Yeah, I should have probably mentioned that the game engine treats the rail and road textures as an one texture the same way as others. Timviewer shows them sepereated in wmsetXX.obj file but they are loaded to frame buffer in complete texture (128x128 I think). I found a program which can tell the VRAM locations here: http://www.romhacking.net/utilities/799/