And all the config files can be stored and readed from
the +OPL partition of internal HDD, or only from MC?
Regards.
Printable View
And all the config files can be stored and readed from
the +OPL partition of internal HDD, or only from MC?
Regards.
In my opinion the only correct place for the config files is on MC.
They have no business ever being stored anywhere else, as currently implemented.
A future exception could be if the split-up went even further. Like for instance having separate per-game settings files for each core device. Then, and only then, does it make sense to store those device-specific settings on the device they are intended for. Like storing the VMC config settings for a LAN fileshare in that LAN fileshare, and so on.
But the main config file should always remain MC based, and the same goes for every file with config info for more than one storage device, such as the presently planned split config files. Storing them on other devices than MC would only be proper (as stated above) for files containing settings only for the specific device the file is stored on.
I'm even hesitant about our current theme usage, storing them in the 'default' list device,
though I do recognize that this is motivated due to the large size of PNG background images etc.
But for normal ascii config files I see no motivation to store them on other devices than MC.
Best regards: dlanor
I agree with dlanor on this, as its impossible to use any configurations stored on a device until it has been loaded/started. So if you were to store your configuration file on your HDD partition, how would OPL read it to know it has to start the HDD device.....without first starting it so it can read the config file? :chinscrat
I understood, i'm only worried about space in MC and for if can
be more file splitting, and i suppose this is also applicable for the
language and the font.ttf files.
Regards.
@jimmikaelkael
are you still working on opl??
dont you think that the conf_compatibility.cfg should also have the location of the game i.e HDD, USB, SMB???
because right now if you have the same game on hdd usb and SMB it looks like thay can get messed up
for hdd it looks like this "SLUS_209.63_DMA=8" for instance
if this has already been taken in to consideration im sorry for asking
If used at all those must all be on the MC.
But I'm not at all sure if any of those are needed.
Since it is possible to start the program from scratch even without having any previous such MC folder, the program must have all the language and font stuff it really needs internally, embedded into the program elf. Exactly what is created on the MC when starting the application without such a folder apparently varies with different versions.
I just checked what I have on the MCs of the three consoles I use here, and in two of them I had "lang_xxx.lng" files for three languages, English, German and Norwegian. But since I never use anything but english I don't think the program would object if I remove the other two. Not that there is much point to it, with one being 1117 bytes and the other 973 bytes, with the total space regained being just three 1KB clusters on the MC.
The third console had none of those, but just a "conf_apps.cfg" of 145 bytes and a "conf_opl.cfg" file of 3413 bytes, with the total MC space cost thus being five 1KB clusters. So I'm obviously not going to worry much about the 5KB used on that MC.
The font.ttf file you mentioned is not present on any of my MCs, so I'm not sure what version may have given you that one. If it was the latest version, which I haven't tested yet, then I guess I'll get that one too. But if it is just a few KB it's not something I worry about.
Best regards: dlanor
I believe that the DMA setting is relevant only for HDD, so adding anything extra to specify this fact is not necessary.
Those DMA speed settings are only used to force the HDD drivers to deliver data at a slower pace, for games that rely on the slowness of normal CDVD access in order for their game engine timing to work right. When fed data at an unlimited HDD speed, some of these game engines will malfunction. So the DMA speed setting of the HDD transfers is used to force the emulated CDVD transfer rate closer to some optimal speed.
For the USB or SMB cores such slowdown is never needed, as they are normally slower than normal CDVD access to begin with, due to how these interfaces are implemented on the PS2.
As for the other compatibility flags, they are not intended to be device-specific, but should apply to all devices equally. Though that is something we may want to reconsider in the future, as different device drivers do cause differing IOP RAM usage...
Best regards: dlanor
Some precision:
- OPL elf embed the default English translations only, not to confuse with the lang_English.lng. The latter is for English users who would like some variations/corrections of the internal English language, and can modify it and put it into OPL folder (and select "English" into the settings)
- One language file is to be copied into mc?:OPL for each supported language
- In a similar way, OPL embed the default latin subset font only. Many languages need an enhanced font char-set for specific/accentuated characters, and thus must copy it to the mc?:OPL folder too. You can find enhanced ttf files for some common languages into the src/thirdparty folder, in fact it is often the same file renamed and maybe you can just use one of this for your own language
- As mentioned by dlanor, the DMA mode are only for HDD. However for other compatibility modes, we use a suffix to differentiate the 3 modes. So the config are not shared for the moment. I've thought this last days if we could use one setting for all, but I don't think it is recommended as we see that compat is varying upon the mode used
I've compiled and tested OPL rev451 and found a problem. I can't run all of my games installed on my internal HDD.:cry: No matter what games I've selected it's just frozen on OPL game list. Is there anyone who has encountered this problem?:confused:
I've reverted back to OPL rev447 and all my games works fine again.