I managed to load models with bones and probably animations. I almost found out how to load map files. Looks like map meshes are inside ms01_mpt.fhm file and textures are in ms01.fhm

Those models are so awesome, I so like to watch them in viewer

Have I told you already, how awesome I am? I can load almost any model’s geometry data now! 

Surprisingly, some models’ parts are out of place, maybe that’s what MNT chunks are for?

I also need to learn how to read locations data before working on flight model, which is my primary goal right now. I really want to work on graphics, but I should leave it for the phase 2. I’m going to post information about known parts of fhm file’s structure in the next post (I don’t want to mix technical information with emotional progress reports), so stay tuned. I also find this blog very motivating, and at this rate I’m going to achieve phase2 even sooner than I have thought.

I still haven’t got enough information, but it’s already much more than I expected from a first quick look. Aircraft configs are pretty much exposed by debug scripts, which, for some reason, were left in the game’s data. Did the developers wanted to make life easier for those who would dig through game’s resources, or they just didn’t give a fuck? Who knows. Horizon uses DDS as a texture format, so I will not have problems with textures at least.

So at this phase I only need to know how to load meshes and map files. I asked a friend of mine to use PIX  to collect some information about render
that could be useful in resource format research, but he returned depressed and exhausted, constantly repeating«so many batches… so many state changes… each camo layer bound as a separate texture…», so it won’t be a lot of help. Anyway, fhm file consists of 48byte header, uint32 chunks_count, chunk infos and chunks itself. NDXR-labeled chunk contains vertices and indices. I’ll post some already known data structure after I’ll obtain more info. I also found out that AH render uses triangle strips. The format is kinda odd and it’s difficult to understand their logic sometimes, but I managed to load and view various data. Some files render correctly and some looks like a complete mess, which provides me with another bit of useful information and gradually increases my understanding.

The games stores its resources inside six files: datafile.qdf, datafile.qdf1 … datafile.qdf5. The structure of qdf file is pretty obvious: first comes file header, then a set of structures that describe packed files (containing file names, offsets, and sizes), and then raw files’ data. Only the first file (datafile.qdf) contains header and files information. Each qdf file has no more than 1572864000 bytes of data. So, a single packed game file could be split among multiple qdfs, which we should take into account when reading data.

I decided to write an open source implementation of Ace Combat: Assault Horizon‘s render and flight model.

So far, my goal is to write an open platform for further gameplay experiments.

I love Ace Combat series and want to be able to play it in the way I want. And I want to see the guts: solving mystery of how does it work will be my special pleasure in this project. I’m using PC version’s resources in development.

In short, the plan is:

Phase one:

• Initial game resources’ data structure research
• Basic renderer, to allow visual testing of flight model
• Flight model reconstruction, with aim to get it as close as possible to the original game

After this phase, prospects of the project will be much clearer.

Phase two:

• Clean code rewrite under MIT license
• Further resources’ formats research
• Advanced renderer, attempt to recreate original AH’s eye-candy graphics.

As long as I will not provide original AH resources in my releases and will not use disassembly to get original algorithms, I hope it will not violate original game creator’s license.