|
Post by Ultima on Jul 31, 2008 12:36:16 GMT -5
ultima.psx.googlepages.com/psxfrontendv112winWIP4.7zVarious silly regression/bug fixes... Also added indeterminate states for advanced options so that not every single profile needs to overwrite current pSX options. That is, if you have bilinear filtering enabled in pSX (for example) and you don't want any profile to change that without having to go into every profile to make sure they all have bilinear filtering enabled, an indeterminate state will do that for you.. Basically, it says "don't bother using me to explicitly set any options in pSX." For the BIOS, an empty path indicates this. For the aspect ratio, "Default" indicates this.
|
|
|
Post by Gamesoul Master on Dec 16, 2008 7:00:50 GMT -5
Been using v1.12 WIP4 for quite a while now... haven't seen any bugs or problems. At this point, I think you should just toss in the option for changing the NTSC and PAL fullscreen resolutions and call it a day... ;D Well... maybe you could just call the current version a stable v1.12 release and then try those options out for a v1.13 WIP1 release. I am currently researching how to find out what display modes are supported via AutoIt code. Found a few places saying exactly how to find the current desktop resolution (can't remember why, but we were talking about that, and how neither of us could figure it out). Found that particular answer here (scroll down to the highlighted text to find it easily). Edit: Awesome! Easier than I thought. THIS will retrieve for you all the supported resolutions you'll need for the selection lists (scroll down to near the bottom of the page). You now have all the information you need to easily add the option for setting NTSC/PAL fullscreen resolutions. I'm expecting great things from you, Ultima...
|
|
|
Post by Ultima on Dec 20, 2008 10:20:29 GMT -5
What about refresh rate?
Dunno, I just don't feel like such an option is of that much utility :S How often does one really need to change their full-screen resolution?
Aspect ratio makes sense to me as an option because some games may not look too horribly under aspect ratios that other games may look pretty bad at.
The window size configuration makes sense to me in that a user might want to resize the window to a specific size because pSX's resizing facility doesn't force the height/width to resize in aspect ratio steps, so one could end up with weird resolutions using freeform resizing.
Full screen resolution, on the other hand, is a bit blurrier to me (in terms of "why"). What resolution a game runs at in full screen doesn't much affect the way in which a game looks.
(I'm not opposed to adding an option, but just not really sure if it makes sense to add)
|
|
|
Post by Gamesoul Master on Dec 22, 2008 2:25:26 GMT -5
Actually, the function I linked to also returns refresh rate (as "frequency"). So it does have all the information you need. And sure... it wouldn't be quite as useful as other options you have, but some people keep pSX on a portable drive, and use it on different computers (where it'd be nice to be able to select the best fullscreen resolution whenever they move to a different computer). There's also some people (I'm one of them) who likes to occasionally play with things like that, and the option *is* related to the other options you do have available to configure. And there's an even smaller number of people who use more than one monitor, and may not always use the same one each time for playing. And in those cases, there are many times where both monitors are not the same resolution (in my case, that's because I use a 22" LCD monitor and a 42" LCD TV... lol). If nothing else... you have the information you'd need to implement it, it would certainly come in handy for some people, and wouldn't it give you some kind of feeling of completeness to have that in there? Besides... it'll give you an excuse to bump the version number up to 1.13, the same as pSX currently. It'd make the frontend seem more of a match for the emulator since it always sounds nice to have a matching set where both items are the same version. Gives a (sometimes false) sense of the two being a perfect fit. Of course... your frontend is already a perfect fit, but a little added feeling is always nice too...
|
|
|
Post by Ultima on Dec 30, 2008 0:09:29 GMT -5
ultima.psx.googlepages.com/psxfrontendv112winWIP5.7zToo many code changes to remember precisely everything that changed. I refactored a TON of code, just because I was hating how everything was organized. As such, I may have broken some stuff -- play around, and look for any regressions, please! Some of the more obvious changes: - Full screen resolution option (affects both PAL and NTSC options) - In-listview profile renaming - Listview sorting - Del keyboard shortcut for deleting a profile And uh, just plain ol' general tweaking of code. I don't feel like bumping the version number just for a relatively trivial code change like full screen resolution options, and it'll quickly go out of sync again when pSX v1.14 gets released anyway Oh, and I would release this as 1.12 stable, but I'm not sure what I've broken in this release (nothing that I've seen so far, but I can only test so much). Edit: Seems like in-listview profile renaming isn't working when compiled as ANSI (rather than Unicode). Investigating... Edit: Yeah, stupid issue. Reuploaded.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 30, 2008 14:17:48 GMT -5
Just make it stable already so I can upload it to my mirror. Which reminds me, one of these days I should change the stolen layout to somewhat match my main site's simple theme.
|
|
|
Post by Gamesoul Master on Dec 30, 2008 16:05:17 GMT -5
Oh poo! Those changes are more than good enough to bump the version number... Especially since it's just a sub-version bump and not a full version bump. Anyway, definitely gonna play around with this. I'll do my best to run it through the gauntlet and let you know if I find anything or not. Edit: I'm sure this is probably meant to be default behaviour, but would it be possible for the export link functions to *not* default to the desktop after first use? Maybe even just allow something like a "DefaultExportPath" key for your .ini file (as an optional thing of course). It could be your first "hidden" feature... If you don't want to add any option like that, thank you at least for not having it go to the desktop folder in the user folders... Only thing I hate more than defaulting to the desktop, is it defaulting to the *true* desktop folder which requires me to back out all the way to My Computer before I can make my way to where I keep my stuff (folders deep on my D:\). Edit 2: When I exported a normal shortcut which (amongst other things) contained settings for two memory cards, importing it back in on a clean session only provided settings for the second memory card. The shortcut correctly sets both memory cards when used directly, so it seems the problem is with the frontend. Just looked through again, and it seems the frontend took that first memory card and loaded it into the "Extra Switches" box (to be exact, it put "-a0,D:\MULTIM~1\EMULAT~1\PLAYST~1\~pSX\cards\FINALF~2.MCR" (without the quotes) into that box). Edit 3: Importing an advanced shortcut for the current session (clearing the current session, then doing "File->Current Session->Import") went horribly unsuccessfully. Hardly any settings were loaded, the path to pSX actually pointed to the frontend instead, the path for the CD Drive I had set instead had the name of the Advanced Shortcut in it (though it somehow correctly set that I was using a CD Drive instead of an Image). Everything else was exactly as it was after I cleared the current session settings. Edit 4: Profile view settings won't change at all unless you're on the Profile tab. As in, the "Options->View" setting won't budge unless you're on that tab. The "Options->Double-Click" *does* change however. It would make sense for the View setting to change regardless of what tab you're on. On that note, I have a request. Those two profile options under Options should have their own sub-menu ("Options->Profiles->View" and "Options->Profiles->Double-Click"). Otherwise it isn't clear at all what those options are for. I think I'll stop testing for now, but if I come across anything else during usage, I'll obviously be sure to let you know.
|
|
|
Post by Ultima on Dec 30, 2008 17:15:03 GMT -5
1. Don't feel like adding hidden INI settings I'll stop making it default to desktop (not sure why I even made it do so, as it's pretty ugly design). Windows should then natively remember the last used directory. 2. Can't reproduce that here. I've exported/imported shortcuts without trouble, 8.3 short-filenames for memory card or otherwise. Testing this a few times did help me spot another bug though (the last saved current session was exported, not the actual current session). Can you provide me with an example profile? The relevant INI section should be enough. 3. I'm quite certain I've never supported importing of advanced shortcuts, and I'm not really sure why it should be supported when advanced shortcuts rely on having the profile already existing in pSX Frontend (in which case you might as well be loading the profile directly). 4. Yeah, I did that intentionally because it causes ugly behavior otherwise (see WIP 4 for the obvious example).
|
|
|
Post by Gamesoul Master on Dec 30, 2008 18:33:38 GMT -5
1) Well it wouldn't *really* be hidden. It would just be your own implementation of remembering the last directory used for an export/import. Would be as simple as it searching for one, defaulting to the pSX directory if it can't find one (or defaulting to the desktop if neither exist), and then creating an .ini entry after first use. It would simply be a similar thing to what you already have (pSX location), so it wouldn't be something odd in your program, but rather you expanding things for it to remember more than just where pSX is... 2) It's not the profile being loaded. It's an exported shortcut (a simple one, not an advanced one) *from* a profile (as stated in my first sentence of that edit). It's what I did before my 3rd edit (which was importing an *advanced* shortcut). 3) Well, to be robust, you'd have to find some way to restrict importing of advanced shortcuts (since the frontend very clearly lets you do it... ). I realize that currently, it doesn't make sense that you have that functionality there (for the reasons you gave), but there *could* be a use for it. Doesn't have to be in the form of a link, but it would be nice to have some way to export profiles in some way to preserve them. Consider that some people find themselves having to delete the .ini for whatever reason, and it'd be nice not to have to lose all their profiles in the process. One way you could do it without adding more export options or anything odd, would be to put the actual settings in the Comments field of the shortcut. You could do this for both simple and advanced shortcuts. That's a feature request, by the way... not expecting it to be put in *right now* if you don't want to... lol. That way, when you import *any* shortcut created by the frontend, it'll be able to recover all the settings that the shortcut came from. 4) LOL... Never noticed that in WIP4 (didn't do any heavy testing on it). There has to be a *proper* fix for it though. If you change the view while on the Profile tab, then leave the tab and come back, the view change is remembered. It has to be remembering it *somehow*, right? So why can't you just make it so that whatever is determining to block view changes when you're on a different tab, make that check function change the "memory" of what view the Profile tab is on? That way it won't do what it did in WIP4 because you won't be actually *setting* the view on a different tab, but merely modifying what the frontend remembers the view setting as when it goes back.
|
|
|
Post by Ultima on Dec 30, 2008 19:00:04 GMT -5
1. Having to store it seems to me like an overcomplication of what should be otherwise simple... As I said earlier, I think I'll defer that to the OS -- Windows natively remembers the last directory used by an application calling the file open/save dialogs. Or maybe you still have a chance to convince me otherwise 2. Whatever it is, I still can't reproduce the problem, so however it is that you're able to reproduce it, provide me with the materials/steps. I know it's about an exported shortcut -- I was planning on using the affected profile to export and reimport. It's a lot simpler to copy/paste the INI than it is to have you upload the LNK file to some other site and then have myself download it. Edit: I did find a very long-standing bug that could cause this, but not in shortcuts exported normally by pSX Frontend (unless you had some invalid extra switch, or edited the shortcut yourself). I've fixed it in my build -- hopefully it'll be fixed in the next release. Would still be nice to see the affected shortcut though. 3. Edit: I shall reconsider. I'll see if I can export "advanced" settings in regular shortcuts' description fields ( Edit: There seems to be a 260-character limit for shortcut descriptions). I still won't support importing of actual advanced shortcuts because it still doesn't make sense. At least regular shortcuts will now be self-contained. At any rate, it looks like 1.12 stable will be delayed a bit further ;D (I'm still dissatisfied with the current code organization, though it's certainly better than before. I'm going to be refactoring a bit of code again.) (My original response) 4. I ran into this problem long before 1.12 (in fact, probably when I first implemented view changing), and still haven't found an adequate solution that would work in all situations (though I guess I haven't tried too hard, since it's low priority to me). View changing is very ugly business. It's not a matter of remembering. The listview remains, and never gets destroyed when you switch tabs (why should it?), so of course it'll still be there in whatever state it was previously in when you switch back. The problem that's happening here is that setting the control style is forcing it to pop up in the z-order, and from what I can tell, it's an AutoIt problem. I still have the problem on my todo list of things to look at (and it's been there for a long time now), but for the moment, you're going to have to deal with the current implementation. FWIW, I still have some ideas I've yet to test.Edit: None of which worked, unsurprisingly... Edit: Got it after a bit of help. May incur some flickering when you're on the Profiles tab, but oh well. Aside: Indeed, you'll notice that I'm extermely picky about what I choose to implement. I'm all for flexibility, but not just for flexibility's sake. When I implement features/changes, I need to see real-world use cases that show that the feature is actually useful, or that it would fit in very well with the intents/purposes of rest of the existing functionality. Otherwise, I feel like I'm just implementing random features (read feature creep). I'd rather have my application be highly cohesive/coherent and a bit less powerful than see it have everything including the kitchen sink implemented in some helter-skelter fashion just because someone tells me someone else might hypothetically want to do this or that
|
|
|
Post by Ultima on Jan 1, 2009 0:39:00 GMT -5
Happy New Years! ultima.psx.googlepages.com/psxfrontendv112winWIP6.7zAs expected, I found several regressions since the last build. As well, I've implemented the extended standard shortcuts, now allow view change on tabs other than Profiles, and hopefully fixed the odd shortcut importing bug. Most of the refactoring is done. Now, it's just down to a bit of renaming minor things and moving a few things around for consistency, so hopefully, stable won't be too far off. Note about extended shortcuts: Because the description field in a LNK file is limited to 260 characters, I had to make some concessions as to how much I could export. As such, I don't bother exporting standard (non-Advanced tab) options that are unchecked at all. That means that profiles that define, say, memory card slot 2, but leave it unchecked, won't have that memory card exported anywhere, and upon re-import, that particular option will be empty and unchecked. I don't expect it to be much of a problem at all, though. Good enough.
|
|
|
Post by Gamesoul Master on Jan 1, 2009 5:14:38 GMT -5
I'll work a little backwards. Yes, your note on extended shortcuts makes perfect sense. If it's unchecked, I wouldn't expect it to be saved. Whatever you did, it *did* fix that shortcut import bug. I even tested it by importing the shortcut into WIP6, which loaded it correctly as it should. Testing using WIP6 shows that it was most definitely a problem with your Import function and not the INI file (so copy/pasting that for you would do you no good, since I tested exporting it from WIP6 and importing from WIP5, and it still bugged out that way). For your own testing pleasure, I have included this archive which is self-contained (has WIP5, the INI, and the shortcut), so you can extract it to a folder and test it right from there... lol. I suppose I can settle for last directory used in Windows. I had wanted you to create your own INI key for it because it would be simple to do, and would be something that is (surprisingly) lacking in most other programs. I would consider it to be something that *should* be done if you want to add final polishes to the program. Things like this wouldn't really qualify as "feature creep", but rather polishing features (since it's something that would benefit just about every user of the frontend). In fact, it's simply a step further than what you've done, and having the frontend use the last-used directory in Windows would be just as much feature creep as taking the extra step to have it go to the last-used directory in the frontend. They both achieve the same effect, except that my idea requires an extra INI key (almost not worth mentioning) and is more convenient. I'm not about adding every feature imaginable, otherwise I'd be requesting things like key configuration mapping/profiles, sound settings, etc. I just think that when you're at this point, it might be nice to add little extra polishes to really make this frontend shine from any current or future one. I'd do it myself, except I gave up on my frontend to throw my full support behind yours... ;D I'll test everything else later. I didn't plan on coming on here for long except to check on things. Good work as always though...
|
|
|
Post by Ultima on Jan 1, 2009 9:22:42 GMT -5
Oh, the path thing wasn't the target of the feature creep comment. It was the advanced importing thing that was I think I already changed my mind yesterday and was planning on doing it ( edit: implementing the path thing), just didn't bother after I finished working on the other things (late/tired).
|
|
|
Post by Gamesoul Master on Jan 1, 2009 16:53:26 GMT -5
Oh... I'm not really all that concerned about the advanced shortcut importing. I only gave the suggestion about it because you had that import/export function for shortcuts anyway, so I figured I'd give a suggestion to make that import function actually useful (since it's been pretty useless otherwise... no need or desire to import regular shortcuts). If you simply removed the import function completely, I wouldn't be all too heart-broken over it... lol.
|
|
|
Post by Ultima on Jan 10, 2009 10:09:20 GMT -5
Well, there it is, v1.12 final is done. Find it in the announcement thread. Haven't touched the Linux version since I released the last version, so it currently doesn't have a v1.12. I'll see if I can mess with it another time (though I'm not sure if that's too likely).
|
|