Problem in file path specification

[einherjar]

The remaining consider the FFVII case for convenience sake, but the
problem is not limited to it.

Today, file path convention considers that game data are located in a
subdirectory named "data/" located at the same place where q-gears is
run (from ffvii/kernel/Kernel.cpp: BinGZipFile("data/INIT/KERNEL.BIN"); ).
As it may be true for a FFVII PC full installation, it is not
appropriate when reading game data directly from PSX CDs.

A solution to this problem could be to use the part of the file path
that is common to PC and PSX version (e.g. "INIT/KERNEL.BIN") and let
the FFVII's GameFileSystem instance prepends the correct basename
("data/", "C:/Program Files/Squaresoft/FFVII/data", "E:/",
"/dev/cdrom/" or whatever, at user's discretion) (*). But for
non-original files (savemaps, etc.), we must use a file system
featuring read/write access and potentially using a different root
basename.

Let me describe the current implementation model:
- ffvii file types (LzsFile, DatFile, etc.) inherits from the class
  ffvii/filesystem/File;
- ffvii/filesystem/File class uses FFVII's GameFileSystem instance
  to perform all its file access.

The problem is that following the considered file, we want to access
the GameFileSystem (hard drive or CD drive, read only) or the
RealFileSystem (hard drive, read and write). Hence I think the "only
one file driver" approach used today is not valid, and that we need a
sligthly different paradigm for file access.

I have several ideas, but first of all: was I clear?
Do you agree with the analysis? Do you have any questions?
Do you have any solutions?

(*) I delivered this into the SVN repository some weeks ago, but it
seems to have been reverted lately in a wrong way, making q-gears
searching for "KERNEL.BIN" in "data/data/INIT/". So right now file
paths are totally wrong; I will remove the "data/" prefix addition
ASAP to stabilize the situation.

[gigaherz]

IMO, the file driver should only be used to access the game files, while savemaps and other files could work without a"file driver" or with it's own. That way the game file driver would "know" if it should use "program dir/data/" "cdrom/" or read the files from a disk image, and not afect the saves at all.

[einherjar]

IMO, the file driver should only be used to access the game files, while savemaps and other files could work without a"file driver" or with it's own. That way the game file driver would "know" if it should use "program dir/data/" "cdrom/" or read the files from a disk image, and not afect the saves at all.

I agree.

A way to do this is to add an attribute to the File class, referencing the file system to use.
So creating files would no longer be written:

  kernel_file = BinGZipFile("data/INIT/KERNEL.BIN");
  savemap_file = File("data/savemap");

but:

  kernel_file = BinGZipFile(GAMEFILESYSTEM, "/INIT/KERNEL.BIN");
  savemap_file = File(REALFILESYSTEM, "data/savemap");

What do you think?

(We could even imagine this style:

  kernel_file = BinGZipFile<GameFileSystem>("/INIT/KERNEL.BIN");
  savemap_file = File<RealFileSystem>("data/savemap");

It has several interesting implications; if you prefer it (actually, I do), let me know, I would describe them)

[Cyberman]

Please also keep in mind we have the nacient code for an ISO image file system.  Thus if someone makes ISO images of the FF7 PS1 disc set it should be able to use the rudimentary file access objects Akari has provided.  I'm extending these for ISO images, I just stoped working on it due to the fact there was no automake for me to find what was missing to cause OGL to freak out on me (lazyness?).

Cyb

[einherjar]

Please also keep in mind we have the nacient code for an ISO image file system.  Thus if someone makes ISO images of the FF7 PS1 disc set it should be able to use the rudimentary file access objects Akari has provided.  I'm extending these for ISO images, I just stoped working on it due to the fact there was no automake for me to find what was missing to cause OGL to freak out on me (lazyness?).

Yes, and I don't think there is a contradiction. A FileSystem points to a FileDriver, which is the true responsible of the lowest-level stuff.
So when a File is read, it is through a FileSystem, which delegates to its FileDriver.

Thanks to this layering, we can have a GameFileSystem using either a RealFileDriver (which relies upon classical open/read/write/close)
or the said ISOFileDriver or a LinuxCDXAFileDriver without a File instance knowing.

[Akari]

I think the best way will be "INIT/KERNEL.BIN" instead of "/INIT/KERNEL.BIN".

  kernel_file = BinGZipFile<GameFileSystem>("/INIT/KERNEL.BIN");
  savemap_file = File<RealFileSystem>("data/savemap");

Mmm I don't like streaming files which moved pointer to next data as soon as you read it. There are many reasons for that. In general I need to read the same data twice sometimes. Sometimes I need skip something of read it from the end of block. So I think It's good only as alternative, not the replacement. But in this case I think that the best way is to use same file reading all over the project.

[Cyberman]

Just being sure .. as for partitioning File space (which is basically what this discusion is about).

Absolutepaths with a specific game file system works fine however ISO variant the first will work just fine, the PC file system it will not unless it's translated internally (I assume this is what you want to do?)
Interesting things, how a Movie is accessed and other data is loaded is by numeric reference. This indicates some sort of table, I think I found some of the table once.  To be certain of how things are working it might be good to dump all file access of FF7 running, of course this would mean me having to finish writting some more software (sigh).

I'll write my inline CD plugin, since I know a bit about the ISO file system I will add in sector 'interpretation' of what the command is doing. (IE reading directory information, file information, volume information, random sector information from the disc etc. ).

It will be about a week, it's important to know "What is going on" with data access etc.  I believe it might alleviate some problems with using the existing data set.  I say this because, the PC data is similar but differently archived and indexed than the PS1, this indicates the original program did NOT use file paths at all.

Cyb

[einherjar]

I think the best way will be "INIT/KERNEL.BIN" instead of "/INIT/KERNEL.BIN".

OK.

  kernel_file = BinGZipFile<GameFileSystem>("/INIT/KERNEL.BIN");
  savemap_file = File<RealFileSystem>("data/savemap");

Mmm I don't like streaming files which moved pointer to next data as soon as you read it. There are many reasons for that. In general I need to read the same data twice sometimes. Sometimes I need skip something of read it from the end of block. So I think It's good only as alternative, not the replacement. But in this case I think that the best way is to use same file reading all over the project.

Understood. So, do we all agree on this replacement:
from:

kernel_file = BinGZipFile("data/INIT/KERNEL.BIN");

to:

kernel_file = BinGZipFile(GameFileSystem, "INIT/KERNEL.BIN");

[einherjar]

Just being sure .. as for partitioning File space (which is basically what this discusion is about).

Absolutepaths with a specific game file system works fine however ISO variant the first will work just fine, the PC file system it will not unless it's translated internally
(I assume this is what you want to do?)

Yes: for the PC file system, we will add the "root path" as a prefix. Something like this:

if (use_native_pc_version_p)
 GAMEFILESYSTEM = GameFileSystem::NewNativePC("C:/Install Path Of FFVII/data");
else if (use_native_psx_version_p)
 GAMEFILESYSTEM = GameFileSystem::NewNativePSX(os_cdrom_drive_path); // "/dev/cdrom" for unix-like, "E:" or "D:" for windows
else ...

Hence, for the native PC version, doing:

kernel_file = BinGZipFile(GameFileSystem, "INIT/KERNEL.BIN");

Would actually open the file "C:/Install Path Of FFVII/data/INIT/KERNEL.BIN".

I'll write my inline CD plugin, since I know a bit about the ISO file system I will add in sector 'interpretation' of what the command is doing. (IE reading directory information, file information, volume information, random sector information from the disc etc. ).

(Are you talking about a CD plugin for a PSX emulator? Anyway, I don't know if it could help you nor if it is relevant,
but you may have a look at the linux CD XA driver I wrote, I've found some interesting things on the usage of ISO & XA)

[Akari]

Understood. So, do we all agree on this replacement:
from:

kernel_file = BinGZipFile("data/INIT/KERNEL.BIN");

to:

kernel_file = BinGZipFile(GameFileSystem, "INIT/KERNEL.BIN");

BinGZipFile always working with GameFileSystem... why should we always specify GameFileSystem?

[stevenw9]

"Measure twice, cut once." A precaution, however stupid it may seem is good. That may just be me, but regardless of flexibility, if it can be more efficient in the end as to getting things to run properly i'd use it.

But i'm just a spectator. 

[einherjar]

"Measure twice, cut once." A precaution, however stupid it may seem is good. That may just be me, but regardless of flexibility, if it can be more efficient in the end as to getting things to run properly i'd use it.

I agree, but I think the point of Akari is: original game file formats (such as kernel's format) shall only be found
in original game data. If we/q-gears generate/handle non-original data, we will certainly not use the cryptic formats
used by the original game .
So for the beginning I will add the filesystem to the File class, which will be initialized to GAMEFILESYSTEM in the
case of original game files. I ever we need to specify another filesystem, we would add another constructor.