:
@mlg man, thanks. Those file formats looks like the most common files formats used for PS1 midi. However, I haven't found any documentation yet.
@Paul, mainly intuition. Before looking at the file format itself, I thought it was a sequence of events/actions, and that it would be likely to have a simple structure, fixed in size.
After some tests, I've dismissed the first bytes (which causes the game to crash if not set properly), extracted all the commands from the game's demos, and started working on it.
There are unknown fields yet. Maybe it has no use, or serves to other characters than abe, and that's why I tried to make a custom NxtP file for the demos... But it hasn't been successful yet.
I think the Path format is one of the most useful. There is one for each sublevel, and it seems to deal with "sublevel layout" (the position of the different CAM files), initial state and scripting.
You're saying it's using hardcoded offsets in the exe... That's what I feard... So, it's the same with the map's width and height, isn't it? My first goal being to reimplement the game engine, having all those values hardcoded is quite annoying...
PS: I would be interested in Bits and Anim formats :P
|
Reimplement the game engine? Check out my "open source ALIVE engine thread"
we have the same goal it would seem.
Based on what you've said I could use IDA to see if its easy to find out the demo command bytes. Is it the same format for oddysee? If you can give me a command thats way out of range in the first demo file or something that makes it crash I can back trace it to the switch/case on the commands to try to figure each one out