Engine building. If we make it, will they come?

[Chesso]

ahhh sorry i don't know much about Linux at all.

[Qhimm]

As far as writing our own encoders, we do have the source code for reading PSX movies. (Though you have to read the data by raw sectors as it's a mode 2 disk). I can play the PC movies in linux via Mplayer, (Abet upside down and backwards)

Well yes reading the PSX movies and decoding them works... for PSX. I was more concerned with the PC movies, which as it looks does not have an easy solution (hey, the porters couldn't even make them run upside-up on a single computer platform). I'm not sure how Mplayer works but I'd assume it somehow uses win codecs (or is Truemotion a standard format now?)... in which case we're left with some ugly code for linux. Windows gets by nicely with DirectShow, but I don't know a similar standard system for linux platforms.

Either way, an installer will probably be the best method to deal with the game.

Well... once we have something that can actually be made to run on anything but one specific linux configuration Nightmare scenario: "download installer: Updated FF7 engine v1.00 for halkun's computer"

Anyway after a weekend of research I can probably reconstruct much of the movie handling system for the Windows platform, in theory. The upside is that it's not that complicated, the downside is that it's because it relies so much on DirectShow. I don't even know where to begin to make efficient movie playback within OpenGL.

ahhh sorry i don't know much about Linux at all.

We can tell.

[Alhexx]

Well, for that movie decoding problem there is possibly a solution...
Remember someone called phaeron on this board? He helped us hacking the animations (IIRC), and he's the author of VirtualDub - a famous video editing software. Maybe he's got some solutions for us (?)

 - Alhexx

[Micky]

As far as writing our own encoders, we do have the source code for reading PSX movies. (Though you have to read the data by raw sectors as it's a mode 2 disk). I can play the PC movies in linux via Mplayer, (Abet upside down and backwards)

You could include a utility that dumps the mode2 sectors into a file once. I've got such a utility for MacOS, if anyone knows how to read mode2 sectors on Linux or Windows it would be trivial to convert.
The position of each movie is given in the iso 9660 filesystem, so all my utility does is scan the directories for the movie extensions, get start and size, and dump the sectors into a file with the same extension on PC.
This still doesn't help decoding them, the latest version of ffmpeg doesn't seem to support the ff7-specific format, even though it contains code for both raw and compressed mdec data.

[Cyberman]

Well, for that movie decoding problem there is possibly a solution...
Remember someone called phaeron on this board? He helped us hacking the animations (IIRC), and he's the author of VirtualDub - a famous video editing software. Maybe he's got some solutions for us (?)

 - Alhexx

If you have the codec for it your fine with Vdub. Are you considering reencoding the movies?  If that's the case you might consider heading to virtual dubs forums

The position of each movie is given in the iso 9660 filesystem, so all my utility does is scan the directories for the movie extensions, get start and size, and dump the sectors into a file with the same extension on PC.
This still doesn't help decoding them, the latest version of ffmpeg doesn't seem to support the ff7-specific format, even though it contains code for both raw and compressed mdec data.

You need to know the matrix information for decoding the FMV's SONY made.  The format of the sectors is rather complicated as well.  Essentially it's different.  The audio and video are interleaved as well.  Perhaps you can use the information from PCSX to decode the data in real time from an image made from the original media for Linux?

Cyb

[Micky]

You need to know the matrix information for decoding the FMV's SONY made.  The format of the sectors is rather complicated as well.  Essentially it's different.  The audio and video are interleaved as well.  Perhaps you can use the information from PCSX to decode the data in real time from an image made from the original media for Linux?

You should be able to grab the matrix information from a player, or get it from the game.
You don't have to worry about decoding the sector format or error correction, the drive does that for you. The raw sector is 2352 byte. For a mode 1 sector you can just skip 16 byte from the beginning and save out 2048 byte, for a XA mode 2 you have to skip 24 byte and depending on form can save either 2048 byte or 2324 byte.
The psx codec in ffmpeg works on data extracted that way.

[Cyberman]

You should be able to grab the matrix information from a player, or get it from the game.
You don't have to worry about decoding the sector format or error correction, the drive does that for you. The raw sector is 2352 byte. For a mode 1 sector you can just skip 16 byte from the beginning and save out 2048 byte, for a XA mode 2 you have to skip 24 byte and depending on form can save either 2048 byte or 2324 byte.
The psx codec in ffmpeg works on data extracted that way.

Your information is partially correct. Those first 24 bytes (the header) contain weather it's audio or video in the remaining data, and what channel it is (for audio).  You can have up to 32 channels of audio in one interleaved file (not that you would ever use it). This is the best method for extracting the video and audio.  Because not all PSX movies/formats are the same. Some of the movies for example are not 320x240 but can be 160x60 with no audio in them (basically just an animation). So it varies
If you want to play the original media information you need to know the matrix to decode the MDEC data properly as well. If you are going to RIP the data PSXmc works just fine with the codec of your choice. You can then use Vdub and precise bilinear filtering to enlarge the image then add a light sharpening affect.
Cyb

[Micky]

As we can't bundle the converted/enhanced files with the engine we would need to write a player, or at least a decoder that allows to transcode into divx or similar.

[Neo Bahamut]

As we can't bundle the converted/enhanced files with the engine we would need to write a player, or at least a decoder that allows to transcode into divx or similar.

If you tried to convert the current movies into another format, wouldn't you just lose more quality? Anyways, I'm probably gonna rip the movies from my PS1 version and try using them in FFVIIPC, I've never heard of anyone doing it before but for some reason, the movies have been bugging me so much lately... they are just so ugly

[Qhimm]

Why are you discussing converting the files to another format as a solution to the problem of reading them in the first place...?  -_-

[Micky]

Why are you discussing converting the files to another format as a solution to the problem of reading them in the first place...?  -_-

Well, there are bigger problems at the moment. But the reasoning could be this: Accessing XA data on a CD is a pain, so it makes sense to rip them to get normal files.  Then you can safe a lot of time developing a real-time decoder if you just transcode them into a format that has already quality codecs available. Then you can use existing software to render them into a texture and DirectX/OpenGL to draw them in the game.

[Cyberman]

Well, there are bigger problems at the moment. But the reasoning could be this: Accessing XA data on a CD is a pain, so it makes sense to rip them to get normal files.  Then you can safe a lot of time developing a real-time decoder if you just transcode them into a format that has already quality codecs available. Then you can use existing software to render them into a texture and DirectX/OpenGL to draw them in the game.

EEEK! How fast do you think encoding is? This simply will NOT work they are VERY asymetric (about 100 times the processing to encode than to decode).  I believe the best bet would be to do the following for the movies (which happens to work GREAT on the enhanced PSX plugins for ePSXe and PCSX).

Fetch video information take hoffman data and decode into PSX 8x8 blocks into a texture Paste texture with bilinear filtering to screen.  The movies look better and do not require your computer to cough up furballs done 1 fps with a 2.2ghz Athalon. Not only is it processor intensive it requires MMX SSE 3dnow and several other instruction mixes to do so.  It's a big gotcha and won't work unless you have a herculean computer (don't forget you still need to decode).

Cyb

[Synergy Blades]

I've been reading this thread with great interest, but it seems to be going off on a tangent/getting sidetracked. Could I possibly suggest getting back on track by doing something like opening a new forum here or some new stickies and putting all these suggestions for various parts of the engine in (potential problems/suggestions)? At least that way some headway would be made rather than getting stuck into very specific topics such as video playback, only for the thread to eventually 'tail out'. Just a thought.  

[Micky]

EEEK! How fast do you think encoding is? This simply will NOT work they are VERY asymetric (about 100 times the processing to encode than to decode).

Don't worry, I didn't plan to do the encoding/decoding simultaneously!   The thing is just, if you have them on HD anyway you can safe a lot of effort by doing any pre-processing off-line. You could run the highest-quality rescaling filter that you can come up with and compress with the highest quality encoder you can find. But as I said before, there are bigger problems to tackle than movie playback.

[Cyberman]

EEEK! How fast do you think encoding is? This simply will NOT work they are VERY asymetric (about 100 times the processing to encode than to decode).

Don't worry, I didn't plan to do the encoding/decoding simultaneously!   The thing is just, if you have them on HD anyway you can safe a lot of effort by doing any pre-processing off-line. You could run the highest-quality rescaling filter that you can come up with and compress with the highest quality encoder you can find. But as I said before, there are bigger problems to tackle than movie playback.

Ahh Ok dokey  

Suggestion for topic 'distribution'
the original thread started was 'is it possible' the answer is yes.  
Maybe we should break off the various discussions such as MOVIE, field information, battle information and script execution? Or maybe there just isn't enough interest for that yet
Perhaps we could discuse setup?

The big issue with the encoding and decoding isn't is it possible we all know it's very possible.  The real issue is really 'is it safe legally'.  I could for example RIP FF7 movies and reencode them with visual improvements etc.  However I don't believe it's legal to include those with the game engine. AND asking a person to download all the stuff to rip and reencode the movies might be an impedance to using it.  For windows or Linux this could be a problem.  The only potential solution I can think of is using XVid and have the installer use some automated method of getting the XVID windows libs or XVID Linux libraries for encoding/decoding.  Grabing an encoder then for CLI execution is the next step.  This requires the media though.  Under linux as halkun said this method would not work.  Windows it would.

Technical aspects, we need a resolution independant method of showing the movies in any case that matches well with the backgrounds.  I think the best method is as I mentioned a large background texture plastered onto a quadric.  The same can be done with the game sprites (using transparency).  All alignment can be done prior to rasterization.  This is going to be the biggest issue of having a multi resolution output.  3D is easy to scale in the game. 2d is not.  If any of you have played the PSX version under emulation you'll notice little regions where there are small lines visible in the background. I believe there are several ways of correcting this problem but we have to think things through carefully.  320x224 does not scale easily to 1024x768.  So my first suggestion is to NOT use standard window resolutions such as 1024x768.  Even if it's in a full screen viewing mode.  I nominate picking ratios compatible with 320x224 which has an aspect ratio of 10:7 not 4:3.  800x600 window would actually be 800x560 or 1024x768 would be 1000x700  1280x960 or 1024 ends up 1280x896. 1600x1280 1600x1120.  Not only does this make things simpler for the rendering engine. It also makes the display of all graphics MUCH better.  There would be a significant reduction in alignment issues. (Like none).

Other things, the Kernel handles the low level IO access for everything correct? I know everyone seems to have a desire to glob everything together (grin) and believes this easiest.  I will humbly submit from experience in a multi person project it's not.  Modularizing the whole thing and defining control interfaces is the wisest but slowest path.  If it's truely to be a multi  system project, it's a must pretty much. Otherwise you will be playing fast and the furious with code.  Everything up to the 'kernel' or basic system access should be identical. This keeps the basic engine running smoothly and consistantly.  It has the added benefit of allowing testing to be MUCH MUCH easier.  IE you can simulate the kernels access with whatever kernel code you have that works, until the kernel for a particular platform works well enough.  This works both ways for testing.  If existing code for testing the kernel is around, guess what? Making sure the kernel works is much easier too! (what a concept ).

So here are the basic questions.
What does the kernel consist of?
From my experience and observation thus for of FF7's behavior less than you would think.  It looks like the Kernel is nothing but low level IO and rudimentary application starting.   It appears to me that kernel.bin is the actually 'startup' code for the game. The kernel may contain internal references for all files in the game. So for the PSX version it make contain all references to sectors for each file on each game disk. For the PC  not sure probably similar data.

So my guess is the kernel grabs kernel.bin and loads the start menu which in turn loads the start of the game or the current field location.

For a Linux version it would be necessary to submit an update to the CD-ROM drivers for Linux to support Mode 2 access with disk drives or at least see if it is possible to do so.  This is not easy but might be more legal than say having them make an Image of each disk to access.

Cyb

[Chesso]

Is it possible for a utility that may automate the process of improving video quality? this might solve the distribution problem but obviously no where near as many options.

Anyway just a suggestion.

[L. Spiro]

Kernel.bin consists of GZip files containing text and data for the game engine (armor data, Materia data, player data, etc.)
It has nothing to do with any in/out handling.

halkun, didn’t you say the shop prices and shop information is still missing?
You said that when I described that mysterious section in Kernel.bin (which was later discovered to be the savemap).
If that information is still missing, why wouldn’t it be in one of the unhacked sections of the non-battle field files?

From memory, I understand that the field files have 9 sections, several of which were understood at least partially, including the ones related to drawing the 2-D images and the text for each field area.
I am just assuming what you said about the shop information being missing still applies, and I wonder why they WOULDN’T be found in the field files, probably directly after the text for each field area.

I do not look into those files much because I do not have good tools for doing so, but I am pretty sure if you are looking for the shop information you will find it in those files.


L. Spiro

[halkun]

The shop varibles are glabal. Kernel.bin is mapped, so it's most likely in shup.mnt then, which doen't have  PC eqivelent...

[Qhimm]

Yes, let's all preprocess the movies and store them on the users' hard drives, and while we're at it of course let the game run without the CDs, or even optimize it for the Ultima Version, or recompile the game data onto a DVD! Yes! Why not even let users download preprocessed files to use instead of the original game data!

Could we please get back to making it instead of making it "better"? We're in enough gray legal goo as it is without you guys start suggesting modifying game data and making the game run no-cd (as would be the case when the movies are on the frickin' hard drive already). You'd think you'd be able to add two and two together, i.e. a) games are made to be run from their original media and b) circumventing copy protection is illegal, which raises the rather interesting question why you would think the new engine (which would then allow you to play FF7 without having the original discs nearby) would be legal?

The very point was to make a technical demonstration of a new engine that would work as a drop-in replacement for FF7, not making a crack which "upgrades" your FF7 installation to "FF7 v2.0". If the engine tries to smooth movies in real-time while playing them, at least we could argue that it's just a display system. You're suggesting to actually modify game data, where enhancing movie quality is technically is no different from, say, modifying the game script. It's all bits of data, and we will not tamper with the for the sake of this project.

Oh, and I haven't compared notes on this with halkun, so I hope I'm not saying this on the complete contrary to his opinion on the matter. I'm not backing down though, I don't want this project shut down just because people couldn't get their chronology straight. Once we have a version complete, we can allow it to see the light of day, then you start worrying if it's safe to touch the game data for this or that purpose. The primary target is a modern, compatible engine for FF7. If the project is getting shut down, I at the very least don't want it getting shut down for anything else than that.

[Cyberman]

Hmmm Halkun I suspect BGINMENU.MNU might be the begining menu (NewGame/Continue screen) for the PSX version of the game I suppose I ought to add something to extract information from .MNU files. (which acording to your documentation that's it hmmm).  Alrighty I don't see any reference to it's structure however (MNU). Are these just uncompressed script files?

Qhimm: I kind of thought I was gently hinting at that hmmm need to use a hammer next time?

Cyb

[Micky]

So here are the basic questions.
What does the kernel consist of?
From my experience and observation thus for of FF7's behavior less than you would think.  It looks like the Kernel is nothing but low level IO and rudimentary application starting.   It appears to me that kernel.bin is the actually 'startup' code for the game.

I agree with that. Suggestion for Kernel: Creating OpenGL or DirectX context, managing savegame data (character sheets, inventory and quest flags), menu system, LZS and GZIP loader.

Otherwise I'd suggest recreating the Field interpreter that was mentioned in the discussion about script opcodes, without entering into random battles, at first. Is anyone actively looking at the PSX field files at the moment?

[Cyberman]

I agree with that. Suggestion for Kernel: Creating OpenGL or DirectX context, managing savegame data (character sheets, inventory and quest flags), menu system, LZS and GZIP loader.

Otherwise I'd suggest recreating the Field interpreter that was mentioned in the discussion about script opcodes, without entering into random battles, at first. Is anyone actively looking at the PSX field files at the moment?

I am as well as I'm fixing up some 'bugs' that are a result of my ineptitude in my scanner decoder peek-a-boo swiss army knife of FF7 ploinking (sorry I couldn't resist that).
The rendering layer I think needs to be abstracted from the kernel.  It looks like the 3d engine is part of the kernel in the PC and PSX versions.  I believe random encounters etc. are handled via the battle section.

The field files are a bit more known, the MIM files in the PSX contain the image BLOCKS for the backgrounds for example.  The DAT files contain the field location information, script, and dialog information.  BSX files contain field models for that field location.  DAT files may contain the sprite information and background tiling information in them.  Lots of fun there.  Right now I'm cleaning up my code mostly so I won't have headaches later with it.  Simple things like consistant decoding and the use of in memory decoding routines to improve speed.  At least my TIM scanning algorythm is very fast.

Back to the main subject howsumever.  Yes someone is working on the field stuff for the PSX.  I think I am going to sit down with some code tonight and grind through the script/dialog decoding. Once I can seperate all the sections of the DAT file cleanly I think things will be more readily acertained for the PSX.

Cyb

[Qhimm]

As part of trying to keep the topic (and thus the project) alive, I'll start posting my progress as I continue to examine various parts of the original FF7. These are some of the more generic points I've come across:

• FF7 is written in mostly (if not completely) C-style code. As I've only seen compiled examples, I can't tell if it was compiled as C++ code or not, but they have at least not used C++ features as part of their main code structure. That having been said, the C code is many, many cases written to emulate C++ features (objects with associated access methods), so if we are to write a new engine to emulate the structure of the original one, using C++ from the start is, after all, more effective.
• As stated earlier, the original FF7 was compiled completely without compiler optimizations, making the code very ineffective in a great many cases. Considering the code quality that lead to the Chocobo Races XP vulnerability, the program was most likely kept in debug mode simply because it wouldn't run when optimized.
  
• FF7 relies heavily on DirectX for its interface to the system, from graphics to sound to input. I think our best bet is to design a highly modular engine where you can write specialized sound/input/window/graphics(?) management modules for individual OS:s when you want to port the project. The engine core would remain completely portable, but we could allow it to take advantage of several features not exposed through the "standard portable" libraries like GLUT, and probably also to a lot nicer and more managable code.
• Something for the more budget modder... FF7 already has a complete rendering plugin system, and from what I can see it is exposed to enable anyone to write plugins, if you had the API specifications. FF7 itself uses this plugin system to select between hardware/software rendering through two internal plugins, and allows the user to select an external DLL as a plugin as well by modifying the registry appropriately. By combining this with a highres/window patch you could probably achieve flawless high-resolution, windowed(?) graphics without rewriting FF7.exe. You would still have the same crappy code base though, so FF7 would still be as crash-prone as before.
  [/list:u]
  So, that's what I've come across lately. Any progress from somewhere else to report?

[halkun]

Hmmm Halkun I suspect BGINMENU.MNU might be the begining menu (NewGame/Continue screen) for the PSX version of the game I suppose I ought to add something to extract information from .MNU files. (which acording to your documentation that's it hmmm).  Alrighty I don't see any reference to it's structure however (MNU). Are these just uncompressed script files?
Cyb

I have no idea what's in an MNU file. I tried picking one apart in PSX memory using savestates, but I didn't see anything rational in there. I can tell you that the MNU file is copied directly from the CD into RAM and executed. I don't know if it's native R3000A code or some kind of scripting langugae.

I don't think it's fieldscript as I don't recall the window() functions abe to do anything but display text.

However, the menu selector on the right is not part of the .MNU files.

The new game/continue is actually in the save menu module. That's where the buster sword graphics and the new game/continue text is. Save can actually load too.

[L. Spiro]

So here are the basic questions.
What does the kernel consist of?
From my experience and observation thus for of FF7's behavior less than you would think.  It looks like the Kernel is nothing but low level IO and rudimentary application starting.   It appears to me that kernel.bin is the actually 'startup' code for the game.

I agree with that. Suggestion for Kernel: Creating OpenGL or DirectX context, managing savegame data (character sheets, inventory and quest flags), menu system, LZS and GZIP loader.

Otherwise I'd suggest recreating the Field interpreter that was mentioned in the discussion about script opcodes, without entering into random battles, at first. Is anyone actively looking at the PSX field files at the moment?

Kernel.bin consists of GZip files containing text and data for the game engine (armor data, Materia data, player data, etc.)
It has nothing to do with any in/out handling.

Are we talking about a different Kernel.bin?
I can’t say what is in the PlayStation® version files.


L. Spiro