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.


Messages - Halfer

Pages: 1 [2] 3 4 5 6
26
I briefly wrote about that before. That type of chara.one has a a footer (I mean a structure at the end of the file), much like the regular chara.one header, but with the order of the entries reversed, where the final 4 bytes of the file are the model count, the 4 bytes before that are the first model's first texture offset, and so on. Also, no EE EE EE EE separator.

http://wiki.qhimm.com/view/FF8/FileFormat_ONE

Seems like you are right, didn't cross my mind to look from the end. Also it looks that EE EE EE EE separators are FF FF FF FF in this file.

27
Great progress Halfer, has anyone delved into the world map chara.one file ? I think it contains geometry for ragnarok/garden/lunatic pandora/etc I also reversed these bytes and found possible beach animation data? Not sure, if anyone wants to have a look

Took a quick look and seems like you reversed bytes from one the 3 TIM textures for ragnarok. As Maki said, by doing this, values can get insane and may cause crashes or affect other elements in bad way which in theory shouldn't be affected by the values.

By a quick note about the structure I can say that Chara.one first 4 bytes indicates the size of the whole file. There are 15 textures and it seems like that after every corresponded texture (for example 3 textures for ragnarok) starts a new section with some kind of data.

Edit: Well, just looked again at the file for curiosity and the structure seems to go like this:

Code: [Select]
u32 Chara.one (whole file) size;    // only once in the beginning of the file
Tim texture(s)           // Every texture for one object comes before .mch structure
.MCH file                   

http://wiki.qhimm.com/view/FF8/FileFormat_MCH

28
Do Squeenix not own any actual computers to render videos, that initial grass flyover looked like it was encoded on an actual potato.

I think this trailer was all in-game rendered from PS4 version, not sure though.

29
I can't believe how I didn't think this sooner but Squaresoft was very lazy or stupid or even both with their world map formats.

The segment includes 16 blocks with their positions in segments header indicating where the block is in file. Well off course you can change the offset, but what I didn't think until now is that why the heck do blocks like the sea/water or any other block that repeats itself need to be separated? Well THEY DON'T!
You can have only 1 instance of that block and indicate all the 16 block headers to that offset. This way the block don't have to have maximum size of 0x900h, in theory it can be 0x9000 long. Only thing that limits it, is block header with the count of faces, vertices and normals which can only have maximum of 256 value.

I noticed that if I put all the block headers to indicate 1 block, texture coordinates changed drastically. However I think I learned how the engine tries to "fix" texture coordinates and I may need to reformat some things in my algorithm for that.

But this sure is really important information since any block that needs to be repeated inside segment can be referenced multiple times while having one instance of it in segment.

*I also did some experiment with the offsets and off course you can set the offset to be over the segment itself. This however doesn't work by itself, because  FF8 engine is changing the location of segments in memory each time you rotate camera. In other words, making it to work needs a hell lot modification on engine algorithms or memory managment.

30
So is this still going to be some kind of arcade game or is it going to be a console game at some point?

First arcade game, later going to be released for ps4

31
https://www.youtube.com/watch?v=M0oTJiy6j8g

Would like to share an opinion that I don't like how skinny they made Squall. Should have kept him a little more "buffed" although it's Amano's artwork. Also Zidane's model looks great!

Discuss!

32
Update, Current phase.

Texture coordinates and indices are now working. Here's a segment that I filled with water blocks. Water blocks were corrected so that 1 quad shows the texture instead of 4 quads as in original file, so it's 4x upscale actually.


I tried to subdivide it to upscale it more but seems like the developers were aware that the blocks including only water can have only 32 faces (32 triangles or 16 quads). So subdividing gave 128 faces which goes beyond the limit (0x900h) for one block (16 blocks in segment).

The importer currently creates a block from an imported wavefront object with:
  • Block header                                                               (Face count, vertice count, normal count, and unknown count (always 0x00))
  • Faces(vertice indices)
  • Texture Coordinates                                                  (Minor tweaks for calculation on works)
  • Manually set Material Properties for whole block
  • Vertices
  • Manually set 1 normal pointing upwards
(minimum information to form the block)

Features the importer doesn't do yet, but are planned to be added:
  • Write normals to FF8 format. (pretty fast to implement, not implemented yet because testing does not need them "yet")
  • Material property editing. (Meaning that user can't currently edit material for each face separately, but can set material properties for whole block. Materials include: Texture pages, CLUT id, info for walkability and landability)
  • Write the exported file straight to wmx.obj. (Meaning that the importer exports a separate FF8 format block which has to manually be set to wmx.obj through hex editor. This also means that segment header must be manually fixed if you change offset of blocks.)
  • Write wmx.obj straight to world.fs. (Using Deling currently to replace wmx.obj)

33
Update.

Texture coordinates are being worked on, need to replace the algorithm though, but working so far. Also I manually set texture indices to FF8 model since I haven't done that algorithm yet at all.




Seems like some combination of material property values are yet to discover because I just found about this:



34
Oh Halfer, you're a God! That's awesome! :3

There should have an option to select faces to block player movement. Also CLUT selection and texture selection. I keep my fingers crossed and wish you best. We want to see this finished! :3
Take care!

Definitely there eventually will be those options! I have couple of ways to implement those features but i'm open to suggestions!

35
Little update now!

Since I have a week off from school I started to make the importer finally. I feel kinda sorry that I haven't contributed as I planned but the fact is, that now the project is back and running.

I've built a simple algorithm that can import a model to ff8 world map format. This was the result:


So it's a cube (little stretched) with material properties that I manually set because the importer currently generates only vertices and faces.

Just a reminder though, although importing is possible, it's probably necessary to make many options for user because for example if user wants to add object over segment, it has to iterate through blocks. And same goes for multiple segments. Importing to one block however is rather easy as done in picture above.

So that concludes to my question, what options people would like to have in the importer? Also if you don't know what can be done through world map file, feel free to ask.

37
http://wiki.qhimm.com/view/FF7/Field_Module

I don't quite understand what you are striving for with that information. There's an order which the engine uses to load the field and 3d models but the time between their loading is probably so small that it's insignificant.

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

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

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

40
That's great!

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

41
Triple Triad info is found at 0x12F0 in the game save file. It may or may not be included in those infos. Triple Triad info in save file hasn't been documented yet, at least to the wiki.

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

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

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

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

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

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




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

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

45
that's a lot of files..
About the multiple sorceress battle I'm quite sure they used normal stage files since we have 2 edea's deling room in a0stgxxx.X battle stages: the one whith opened door (when you fight monsters attacking Rinoa ) and the one whith closed door (during the time compression).

Yeah, there are also lots of spells with different background "filters" and I think the spells itself are formed in 3d meshes, atleast I cannot think a way how the bending of textures could be done without 3d meshes. Also including MAGxxx.X files in executable would reduce the lag and disk I/O improving performance during animations which could be reason why they are not separate from the .exe .

This could also mean nothing and they can just be old references never used, but let's see how it turns out.

46
Yep!

I don't know how many .X file reference you found.. but since they have the same extension of battle stages I guessed that they could be the "environment" that sometimes game show during certain animations..it could make sense..

There could be many other file format in the exe (we already know it contains many .tim texture).

There should be many magic that clearly use 3D geometry (for example all the ice ones) but in most of case we have "somehow animated mesh" that we usually don't find elsewhere.

Another thing that has not been considered yet could be bone scaling.

I remember I read once here or on xentax that bone scaling is not used in this game but that's actually not entirely true..

I can think to only a sample of bone scaling but I'm actually sure it's used for GF Pandemona "tail" inflating animation..
Moreover there is Bomb/Piros "enraging animation".. even if that animation is not a bone scaling animation..more probably is scripted..

Many of magic geometry animation anyway could (probably) use bone scaling and I think we should keep that in mind :)



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.

47
I could be totally wrong but..

We actually know that there are some gf and other stuff that can be found only inside ff8.exe so what you're sayn' could make sense..

Moreover I would guess that those Mag###.X files could actually be "GF battle stages".. I mean places where GF are usually shown..for example the sea for siren , cemetery for cerberus and so on..

I'm sure  that ff8.exe file can reveal many secrets  ;D

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.

48
This was found in FF8.exe ASCII rip.



These files are listed right after all the battle.fs files. There are 349 of these entries and I think they contain the 3d properties of all the spells, summons, limit breaks and so on....

I'm not sure if they do really exist in FF8.exe or if they are left overs, hence can't really prove if these are files or just names left in the compiled version and never used.

49
I don't think they have completely dumped the Luminous engine for future games but as I see it is that it is developed simultaneously with FFXV and they had plans to use it as an editor but it turned out to be really complicated to be a game making engine yet since it's not even finished yet.

I think they don't want to repeat the same mistake with developing time for KH3 and FF7R since it's not finished and those are in development right. Saving time and making the games with working and finished tools is a wise thing from SE to do.

50
If they are not in scene.out then they may be in r0win.dat file. I'm really surprised if for some reason they are in battlefields, because that's just really bad optimizing especially for a game of this scale. Well I'm more than willing to help with these kind of things.

Pages: 1 [2] 3 4 5 6