dfreer
Junior Member
Posts: 75
|
Post by dfreer on Jul 23, 2007 13:13:29 GMT -5
Thanks for the awesome emulator! Just thought I would bring up an issue concerning the linux port, perhaps it can be included in the next version 1.13:
(1) Multi-user support. What this would entail would be to have the main executable pSX look for it's configuration file (psx.ini) in the current user directory (say ~/.psx/psx.ini) instead of the current directory (./psx.ini). This would allow multiple users to have seperate config files, including seperate memory cards/save states/etc.
|
|
|
Post by Gamesoul Master on Jul 23, 2007 13:48:28 GMT -5
Hmm... If possible, could you rename your thread to match your request (still including the OS in the title of course). I only say this because we've come to have the system of one request per thread to keep things from getting cluttered, and if people see that kind of title, they'll think they can post their requests in here.
|
|
|
Post by patrickp on Jul 23, 2007 14:27:07 GMT -5
On the other hand, it is a very salient request for Linux. It means the emulator can be properly installed with a .deb package, while the configuration files remain easily accessible for users. This is a common and sensible way of setting things up in Linux, but can't be done while pSX exclusively reads and writes its configuration file in its own folder.
In fact, I tried one of dfreer's pSX packages and thought it worked extremely well, but the reason I didn't continue with it was the hassle of accessing the configuration file for muckin' abaht.
It could possibly even smooth the way for including pSX in the official repositories - which would mean all users with the appropriate repository enabled would see pSX offered as an available package. ATM PCSX is the only Playstation emulator offered in the Ubuntu repositories.
|
|
dfreer
Junior Member
Posts: 75
|
Post by dfreer on Jul 23, 2007 14:39:38 GMT -5
Change name of thread = done thanks for bringing up that point Gamesoul Master, as you can tell by my post count I haven't spent much time around this forum. Yep, it would definitely make integration to the main repos much easier if this were to happen. Although I'm not sure if I myself would be the one to do so, I have lingering doubts about whether I can make the package up to par with debain/ubuntu packaging standards.
|
|
|
Post by pSX Author on Jul 28, 2007 5:58:17 GMT -5
Hi,
I am now implementing this, but do you think that the saves, memcards and screenshots paths should default to being in ~/.pSX too? Obviously this dir would be hidden and it seems kind of strange to put such potentially large directories in a hidden path.
These paths are all configurable anyway, but I want to make the default correct for multi-user usage.
Thanks, pSX Author
|
|
|
Post by patrickp on Jul 28, 2007 6:59:11 GMT -5
As you say, these paths _are_ configurable, pSX Author, and most other emulators in Linux seem to do it this way; ATM I'm using (as well as pSX, of course) ZSNES, GENS and MUPEN64 (when I can get it running right...). They all do this.
Although the configuration folders are hidden, they're not difficult to unhide if you want to access them - which is half the reason for this. The other half would be that, if you've set your /home folder up on a different partition to your root, as Linux users will tend to do, you can reinstall without losing your home folders, including your configurations and, in this case, game data. Hopefully, Linux users will also be a little more aware of the possibility of keeping game data in remote locations, as well - this is particularly useful for sharing that data between OSs.
Yes, I'd say do it the way you suggest (default game data as well as configuration to ~/.pSX), perhaps include a note in the readme that that's where the game data goes by default, and point out that you can also use whatever remote locations you want.
|
|
|
Post by Ultima on Jul 28, 2007 7:56:11 GMT -5
Hm. Should I need to be doing this for the frontend too? And it shouldn't matter that large files can/might/will be placed in a hidden directory. Wine does the same thing, storing drive_c in ~/.wine/, and I'm sure other applications do the same @psx Author: While we're on the subject of paths... By default, you set MemoryCardPath to be "cards," but there isn't such a directory (though there is a "memcards" directory). Maybe the included "memcards" directory should be renamed to "cards"? And I've another suggestion... *if* pSX sees psx.ini in its current directory, maybe it should use it instead of ~/.pSX/psx.ini (in case people still prefer the current method, or prefer it to be self-contained), and otherwise, default to using the user-specific directory instead?
|
|
|
Post by patrickp on Jul 28, 2007 9:57:30 GMT -5
Definitely, if pSX Author goes forward with this, you should do the same with the Frontend, Ultima. I suppose one alternative idea might be to have the path to pSX' configuration folder settable, perhaps on startup as the BIOS folder is? With the method that's being discussed, a new installation of pSX will only see a configuration file in its own folder if it's already created one - which, at the point of installation, it won't have. So new installations (as opposed to upgrades) will default to ~/.pSX anyway. This would mean, I think, that the majority of pSX users will be using ~/.pSX before too long, anyway. On reflection, I think I'd prefer to see a default of ~/.pSX, possibly with the option to set alternative paths on the Paths tab. That would make it simple and useful, but easily configured otherwise as people want. Personally, I think I'd be keeping my configuration in ~/.pSX, and all the other paths would point to a shared folder on an NTSC partition. Can't say I play much in Windows anymore, but it's useful to be able to rip images in Windows.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 28, 2007 11:44:24 GMT -5
@psx Author: While we're on the subject of paths... By default, you set MemoryCardPath to be "cards," but there isn't such a directory (though there is a "memcards" directory). Maybe the included "memcards" directory should be renamed to "cards"? Like this? This was fixed in 1.8 Windows version, it's funny that it creeped back with the Linux port.
|
|
|
Post by patrickp on Jul 28, 2007 13:45:44 GMT -5
Can't say I ever noticed, myself. I always reset all the paths anyway,
|
|
|
Post by Ultima on Jul 28, 2007 16:21:02 GMT -5
A configurable settings folder? Where is pSX gonna look to find the place where the settings folder is actually set? The settings folder, which is supposed to be set somewhere in the settings. lol, it goes into circular reasoning unless there is a known location for it to look for the settings. The only reason such a thing would work for many Windows applications is that the applications might use %appdata% or the Registry to store the location of the user-defined settings directory. %appdata% would be similar an idea to ~/.*, and the Registry... just doesn't *really* exist in Linux. IMHO, allowing users to configure... the settings directory is a bit overboard The only places I can imagine the settings being (sensibly) located are (1) in the current executable directory, or (2) a standardized location, like the proposed ~/.pSX/. I still think both should be used (first look in the current directory for psx.ini; if it's found, use it; else, use ~/.pSX/)... It's just an elegant way to fall back (IMHO). After all, it's straightforward, and doesn't require finding psx.ini, then looking in it to see if the settings directory is set to be somewhere else, then looking at that somewhere else. Edit: So yeah, that's how I implemented the psxfrontend.ini searching for the frontend. The implementation feels a bit "dirty" to me, but it works ;D Basically, it asserts that psxfrontend.ini exists in the same directory as the executable. - If the assertion is true, then no exception is thrown, that exception handling block is skipped, and the current executable directory simply gets used as the settings directory. - If the assertion turns out false, then an exception is thrown and it'll go into the exception handling block where the settings path simply gets set to ~/.pSX/ (and if that path doesn't already exist, create it). I'm handling psx.ini in a similar manner (if it doesn't find psx.ini in the pSX executable's directory, it'll search in ~/.pSX/ instead). Even if pSX Author doesn't implement it in this way in pSX, it (the frontend) will still be backwards compatible with pSX 1.11 and 1.12. @ patrickp: psxemulator.proboards54.com/index.cgi?board=support&action=display&thread=1155421460&page=32#1185567899Not sure if you missed this post yesterday, but I thought I'd remind you... I need to know if the aspect ratio thing is still (oddly) breaking the image selection
|
|
|
Post by patrickp on Jul 28, 2007 19:12:16 GMT -5
Well, since you removed the Auto entry, the problem's gone, of course, Ultima - it was selecting that that caused it. I guess selecting an option that didn't exist must have caused the code to throw a whoopsie?
What are you planning to do for the Frontend - have a ~/.pSXFrontend folder, or just use ~/.pSX?
|
|
|
Post by Ultima on Jul 28, 2007 19:28:59 GMT -5
For the frontend, I plan on putting it in ~/.pSX... unless anyone thinks I should put it in ~/.pSXFrontend?
|
|
|
Post by patrickp on Jul 28, 2007 19:39:06 GMT -5
I'd say ~/.pSX - who's going to be using the Frontend without the emulator? And the Frontend will create ~/.pSX if it doesn't exist; I already checked that.
|
|
dfreer
Junior Member
Posts: 75
|
Post by dfreer on Jul 29, 2007 3:16:49 GMT -5
Wow, I missed a bunch... ok, let me explain how I would set up the package, and then answer specific questions (note, IMO only): pSX gets installed (in my case to /usr/local/games/pSX/ ), and the only things it contains are the executable itself and README files. Where it gets installed is generally distro specific and not really relevant. Upon first startup, it checks for existence of ./psx.conf in this case /usr/local/games/pSX/psx.conf (exactly same content as psx.ini, only the filename is "linux-fied" ), and if not it creates the file *blank*. This file is a global config file, which means any setting in here is going to be copied into all freshly created user config files, and not all settings need defined. In my case, I would just define the path to the shared CD images folder: [Paths] CDImagePath=/usr/local/games/pSX/cdimages/ and leave the rest blank. So now it checks the user's ~/.pSX/psx.conf, and if it finds it blank it creates the folder ~/.pSX then copies /usr/local/games/pSX/psx.conf to ~/.pSX/psx.conf. If it doesn't find it blank, then it simply loads the config file as it did in previous versions. This solves several problems: (1) It becomes truly "multi-user", which is basically just neat. (2) The pSX author can upload his linux package in the same way as before, and can even create a ./psx.conf (./ = current directory) file to default to using the folders ./cdimages ./bios ./saves etc and it will run out of an extracted folder on the desktop, pretty much like normal. (3) Package maintainers (me!) can customize the ./psx.conf file to increase compatibility for the various distros themselves (in my packages, I generally specify some default paths, and tweak the sound settings so it isn't as scratchy). (4) The end user can override all of these settings with their own ~/.pSX/psx.conf file if they are so inclined. but do you think that the saves, memcards and screenshots paths should default to being in ~/.pSX too? Obviously this dir would be hidden and it seems kind of strange to put such potentially large directories in a hidden path. Just leave it as you have it, if you so like. As long as it looks for the config file in a "relative" location (relative depending on which user you are), instead of in the static current directory (which means only one config file is possible). Since these other paths can be defined, I don't think it is anything to worry about (I plan on mucking about with the paths myself in the packages I create). Hm. Should I need to be doing this for the frontend too? IMO, yes, and I see you already have done so. Kudos! And I've another suggestion... *if* pSX sees psx.ini in its current directory, maybe it should use it instead of ~/.pSX/psx.ini (in case people still prefer the current method, or prefer it to be self-contained), and otherwise, default to using the user-specific directory instead? This would be the case if my rambling idea above was implemented. [EDIT]The difference between mine and yours is that I would copy the old file if found in ./ into the ~/.pSX/ location, and use the copy instead of the original, essentially nicely forcing people to use the new method.[/EDIT] Basically, what would happen is those people you mention generally just dump the new executable into the original folder, correct? pSX would see the old psx.ini file as a global config and copy it into the user's ~/.pSX/ folder as described. The user wouldn't have to change a thing, and the new method would be in place! Note, I don't care whether you use psx.ini or psx.conf myself, it's simply a naming thing and has no effect on the file itself. If the name does get changed, you can even have it look for psx.conf AND psx.ini, and use whichever is present (backwards compatible). No biggie. I suppose one alternative idea might be to have the path to pSX' configuration folder settable, perhaps on startup as the BIOS folder is? I agree as well with Ultima here, that may be too much of an hassle. I believe most native linux programs don't even have this, I may be wrong. Basically I think the options for this idea are to: (1) use only ~/.pSX/psx.ini/psx.conf (even this only would be great) (2) use the already existing ./psx.ini method (not do anything) (3) use both in one of the methods described
|
|