|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: RII - Resolution Independent Interface[message #212080]
|
Fri, 03 April 2009 23:25  
|
|
 wanne (aka RoWa21) |
 |
Messages:1958
Registered:October 2005
Location: Austria |
|
|
@birdflu: A few questions to the VFS:
For example, if I want to put a new MOD in my JA2 root directory I have to do the following:
1.) Create a new folder in th "Profiles" folder (e.g. MyMOD)
2.) Copy all the needed ja2 data folders (interface, tabledata, ...) into "MyMOD". So these files will overwrite the existing ones from folder "Data" and "Data-1.13"
3.) Edit "vfs_config.ini"
3a.) Create a new Profile (e.g: [PROFILE_MyMOD]). Set NAME, LOCATION, PROFILE_ROOT and WRITE
3b.) Add the new profile at the end of the PROFILES string in the [vfs_config] section. I assume the last one will override the previous ones, right?
4.) Start the EXE
Is this correct, birdflu? So one general question: If I install new mods I put all the data files inside the Profiles/MY_MOD_NAME folder.
EDIT: The folder "Profiles/UserProfile" is used to save user specific data. So savegames, setting file and temp files are saved there. Correct?
EDIT2: For the JA2 multiplayer the VFS would be awesome when it comes to server -> client file transfer. File transfer is working but we need a way to store the multiplayer data on the clients harddisk. Can VFS be easily integrated into current SVN source code. How much files need to be changed?
Thanks for the infos.
[Updated on: Fri, 03 April 2009 23:31] by Moderator Report message to a moderator
|
|
|
|
|
| Re: RII - Resolution Independent Interface[message #212085]
|
Sat, 04 April 2009 01:25
|
|
| BirdFlu |
 |
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
In a simple case you would and up with something like this
[vfs_config]
PROFILES = P1, ... , Pn, MyMOD
[PROFILE_MyMOD]
NAME = Mod's name
LOCATIONS = rootdir
PROFILE_ROOT = global_or_relative_path
WRITE = true
[LOC_rootdir]
TYPE = DIRECTORY
PATH = relative_path_from_PROFILE_ROOT
MOUNT_POINT =
Quote:1.) Create a new folder in th "Profiles" folder (e.g. MyMOD) Actually it can be any directory as long as it is referenced correctly.
Quote:2.) Copy all the needed ja2 data folders (interface, tabledata, ...) into "MyMOD". So these files will overwrite the existing ones from folder "Data" and "Data-1.13" You will only need the files you want to replace. The rest will be taken from lower profiles.
Quote:3.) Edit "vfs_config.ini" Yes.
Quote:Create a new Profile (e.g: [PROFILE_MyMOD]). Set NAME, LOCATION, PROFILE_ROOT and WRITE Name is required and has to be unique.
Its LOCATIONS and can be a list of section names (actually section names are created from the elements of this list by prepending "LOC_" ).
PROFILE_ROOT is the directory of your mod (see point 1) and can be a relative or an absolute path.
Key WRITE is not required, but at least on Profile has to defined writeable (your new mod or one of the older mods), preferably the last one in the list.
Quote:Add the new profile at the end of the PROFILES string in the [vfs_config] section. I assume the last one will override the previous ones, right?
Yes. If a file can be found in the top profile, then it is used, other wide the system looks in the next profile and then in the next until it is found. So, actually you cannot "delete" a file in your profile as it may be found in another profile.
Quote:Is this correct, birdflu? So one general question: If I install new mods I put all the data files inside the Profiles/MY_MOD_NAME folder. In a simple case, yes. But you can also put a directory in any position in the VFS by using "MOUNT_POINT = ". For example you could take a directory "%ModRoot\Stuff" and insert the contents of it into "Tabledata\Lookup" be doing this
[PROFILE_MyMOD]
NAME = Mod's name
LOCATIONS = dir1, ...
PROFILE_ROOT = %ModRoot
[LOC_dir1]
TYPE = DIRECTORY
PATH = Stuff
MOUNT_POINT = Tabledata\Lookup
But there is a restriction. In one profile you cannot add two files with the same vfs path. You would have to use a second profile to do that, but then one of these files would be overridden and thus unaccessible by normal means. So, you probably don't want to do that.
Quote:EDIT: The folder "Profiles/UserProfile" is used to save user specific data. So savegames, setting file and temp files are saved there. Correct?
The UserProfile is the writeable profile. There you save all files that are written through the vfs. These are Savegames, Shadetables, Temp files, but also ja2.set and probably other files. So, the question is, do you want a "clean" user profile or do you want to mix in actual data.
The writeable Profile is special as is contains "exclusive" directories. These are "Temp", "ShadeTables", "SavedGames" and "SavedGames\MP_SavedGames". Exclusive means that if a file is not found for write or read access in this directory, the system does NOT look in other profiles.
Quote:EDIT2: For the JA2 multiplayer the VFS would be awesome when it comes to server -> client file transfer. File transfer is working but we need a way to store the multiplayer data on the clients harddisk. Can VFS be easily integrated into current SVN source code. How much files need to be changed? Is that kind of thing not possible now? Can't you just store (arbitrary) data in a file? What kind of data is this multiplayer data and why can't is remain in memory?
Integrating the VFS into the main branch should be relatively simple. First, all VFS code is located in a separate Project that compiles independently of anything else (OK, that's not true, it requires the libs 7z.lib and also libpng.lib). The integration into the rest of the code is done by "hijacking" the FileMan interface, basically doing this kind of stuff
BOOLEAN FileExists( STR strFilename )
{
#ifdef USE_VFS
return GetVFS()->FileExists(vfs::Path(strFilename));
#else
// First check to see if it's in a library (most files should be there)
if ( gFileDataBase.fInitialized &&
CheckIfFileExistInLibrary( strFilename ) ) return TRUE;
// ... then check if it's in the custom Data directory
if ( gCustomDataCat.FindFile(strFilename) ) return TRUE;
// ... then check if it's in the default Data directory
if ( gDefaultDataCat.FindFile(strFilename) ) return TRUE;
// ... lastly, try to locate it in the file system
DWORD attribs = GetFileAttributes(strFilename);
if ( attribs != INVALID_FILE_ATTRIBUTES && !(attribs & FILE_ATTRIBUTE_DIRECTORY) )
return TRUE;
return FALSE;
#endif
}
So, if "USE_VFS" is defined in vfs.h, then you use the VFS, otherwise you use the old system. There are also a couple of other files that look for VFS definition. This is mostly because of different path names for ini files. I also have an own INI file parser that is used by "hijacking" the INIReader class.
And i also disabled (or at least tried) all changes to the current directory, as it would royally screw up VFS initialization with paths defined relative to the exe. I also didn't "hijack" all functions from FileMan.cpp, only those that were actually used and had something to do with file operations.
There is another problem with the VFS, but it is not too dramatic. There are a quite some direct file accesses via the FILE C-interface or the fstream C++-interface, that are bypassing the regular FileOpen, FileRead, FileWrite interface from FileMan and thus bypassing the VFS. This would have to be changed.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: RII - Resolution Independent Interface[message #214103]
|
Sat, 25 April 2009 06:49
|
|
| SharkD |
|
Messages:350
Registered:July 2003 |
|
|
I would just like to add that the developers of Homeworld 2 created two sets of interface element images: one for 800x600 and one for 1600x1200. The game would then "guess" which set of images to use based on the requested resolution. For instance, if the game were running at 1024x768, then the 800x600 images were upscaled to fit the larger resolution. If the game were running at a resolution larger than 1600x1200, the latter set of images were used.
Also, the game used percentages instead of pixel coordinates for image placement. I.e., instead of placing an image at (200px, 400px), the game would place the image at (10%, 20%) of the screen dimensions.
I'm not sure, however, how the game dealt with other aspect ratios. I.e. did the game align everything in the center? Did it stretch the images?
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
|
|
|
Blog
Search
Help
Members
Register
Login
Home
