xaaz
New Member
Posts: 25
|
Post by xaaz on Sept 13, 2007 23:52:59 GMT -5
Anytime. Glad I could help by being the guinea pig. With that bug squashed the universe is safe for another day. EDIT- Incidentally, would that final test executable be any different from the 1.11 executable beyond the bug you just fixed? I'd like to use it in the mean time before 1.12 comes out if that's allright with you.
|
|
|
Post by Ultima on Sept 13, 2007 23:57:39 GMT -5
Yep, the only difference was the bug fix, so it should be fine to use Edit: For anyone else wondering about this newer version... I don't think there's any need to announce it; it's a very uncommon bug that will be fixed in 1.12 (for which a test build *should* be released soon enough).
|
|
|
Post by Ultima on Sept 14, 2007 21:49:57 GMT -5
pSX Frontend v1.12 Windows WIP 1 ultima.psx.googlepages.com/psxfrontendv112winWIP1.rarv1.12 (????-??-??) ~ Minor tweaks
Windows Only + "Detailed" and "Small Icon" views added + Keyboard accelerators added for menus + VSync options (full screen and windowed) ~ "List" view in Profiles list behaves like real "List" view ~ Changed monitor detection to (hopefully) be more future-proof ~ Fixed "missing window" bug when closing on minimized state in Vista ~ Resizing frontend should update switches and profiles list more smoothly I don't feel like implementing listview sorting on Detailed view. Hiding column headers... I became too lazy to do that Same with resetting column header order/widths. Ugh, I think I've gotten burned out on working on pSX Frontend for the moment Feedback welcome as always! Aside: the column management went a lot more smoothly than I expected, and I've become quite fond of the Customize dialog xD
|
|
xaaz
New Member
Posts: 25
|
Post by xaaz on Sept 14, 2007 23:45:14 GMT -5
Nice release, Ultima. Your work is greatly appreciated.
I am however experiencing some odd behavior with the new build. Every time I run the Frontend it takes a good three to five seconds before the window appears, and in one instance it did not appear at all. Also when I first ran 1.12, while using my 1.11 INI file, and switched to Detailed view it began acting extremely odd. Many columns began to appear and dissappear very quickly, sometimes filled with specific profile information and other times with the word "Disabled" in them. This behavior went on for upwards of three minutes before I manually switched the viewtype to List. Immediately afterwards I switched it back to Detailed and everything displayed properly.
|
|
|
Post by Ultima on Sept 20, 2007 19:37:16 GMT -5
Dunno what to say about that... At this point, I'm not even sure if column configurability should be allowed any more; any trouble might be more trouble than it's worth So um, back to the drawing board regarding columns... What should be the defaults? As it currently is, I have BIOS, Switches, and Log (show/hide log window) shown by default. Are those details sufficient?
|
|
dfreer
Junior Member
Posts: 75
|
Post by dfreer on Oct 20, 2007 23:12:43 GMT -5
Hey Ultima, I'm finally getting around to making packages for Ubuntu Gutsy, and I'm running into a slight problem, I can't tell if it's a bug or an issue with my configuration. Advance warning, it's a bit of a long post: First off, I'm running a clean install of Ubuntu Gutsy i386 in a virtual machine under VMWare, and as such I have no sound output. Which means that pSX will let me choose the language, BIOS, and then crash That was expected. Anyways, pSX is located at /usr/local/games/psx/, with a symbolic link at /usr/bin/. pSXFrontend is located in the same directory as the main psx executable, also with a symbolic link at /usr/bin/. I also have a .desktop file in my gnome menu, launching /usr/local/games/psx/pSXFrontend. There is nothing in ~/.pSX/ yet, now on to my actual problem. When launching pSXFrontend from terminal, with /usr/bin in my $PATH as normal, I get a segmentation fault. But by directly launching it, either by specifying path like /usr/bin/psxfrontend or by changing to the directory, then launching it works fine. From gnome menu it also works fine... Here's some output to make myself clearer: ~$ whereis psxfrontend psxfrontend: /usr/bin/psxfrontend
## Here's the particular issue ~$ psxfrontend Segmentation fault (core dumped)
~$ /usr/bin/psxfrontend [... psx frontend launches normally from here ... ] ~$ /usr/local/games/psx/pSXFrontend [... psx frontend launches normally from here ... ] ~$ cd /usr/bin/ /usr/bin$ psxfrontend [... psx frontend launches normally from here ... ] /usr/bin$ ./psxfrontend [... psx frontend launches normally from here ... ] Anyways, am I doing something stupid, or is there some sort of bug here? I don't think it's due to running in a virtual machine (I mentioned it so that you'd have as much detail as possible), I'll try running a Live CD and see if I can replicate when I get some freetime.
|
|
|
Post by Ultima on Oct 21, 2007 10:40:49 GMT -5
I wouldn't be at all surprised if it were a problem with my directory detection, as I'm not very fond of it. Um, I'll try to gather a bit of time to look at it, though that'd require that I get a virtual machine up and running again... (still haven't gotten around to that :<). Thanks for the report
|
|
dfreer
Junior Member
Posts: 75
|
Post by dfreer on Oct 21, 2007 11:52:25 GMT -5
|
|
iamme
New Member
Posts: 2
|
Post by iamme on Oct 23, 2007 18:35:33 GMT -5
Contents of this post deleted as transgressing forum rules and totally inappropriate for this topic.
First, look at the Global Warning at the top of this and every other page in this forum, iamme.
Downloading games is illegal and dumb, and it's even dumber to admit to doing so in an emulation forum. Do not do this again. You've been warned; any further infringements will result in a ban. You will not receive help for a downloaded game.
Secondly, why on earth did you post your request in the Frontend development thread? It has absolutely nothing to do with the topic.
Before posting again, read the forum documentation: the Forum Rules, the FAQ and Things to Remember when Posting Reports.
patrickp
|
|
|
Post by Ultima on Oct 27, 2007 0:34:22 GMT -5
/me wonders if xaaz is still around... ultima.psx.googlepages.com/psxfrontendv112winWIP2.rarMind testing this build to see if the flickering and other oddities still occur? What was your INI like anyway, that it would be so slow...? Can you upload it somewhere for me to test? I've tried testing an INI with around 70 profiles, and it took probably 1 to 1.5 seconds to open up... (of course, 1.11 takes less than 1 second to load an INI with 70 profiles, but the slow speed with Detailed view is the price I pay for loading all the extra information). Also, what are your computer specs?
|
|
|
Post by Gamesoul Master on May 4, 2008 7:59:47 GMT -5
Wow... this got really old, didn't it? I feel really bad for not taking a look at this and actually helping report on this. I couldn't verify xaaz's bug, as everything worked perfectly fine for me (I tried messing with a lot of things too). WIP1 and WIP2 work pretty much the same way for me... perfectly, as far as I can tell. If I had one final suggestion/request (a small thing, something to do so you can make a "final" v1.12 build... )... With the window size display, remember how I had complained about being able to delete that "x", which forces the person to select a preset to "reset" the box for the "x" to reappear again? Well, instead of trying to code some way for that "x" to not be deleted, what if you just put the width and height in two separate boxes? You have to pull them as two separate values anyway, so all you'd really be doing is pulling two text box values and setting each value to its corresponding variable. Certainly beats reading the string, then taking all characters up to "x", converting them to an integer, setting that to the width variable, then reading the rest from pos+1, converting those to an integer, and setting that to the length variable. Maybe AutoIt provides some set of functions to automatically read and convert text strings to integers (which would have to be used on the assumption that the values *will* be integers, though your frontend does make sure of that by only allowing numbers to be typed in), but not only would my solution make messing up the custom size almost impossible (with no "x" to worry about and each variable being clearly defined in its own text box), but it'd make for much cleaner code too... ^^ Well, it's only a suggestion of course, but it'd be a nice way to dust off your code, make the small change, and release an "official" v1.12...
|
|
|
Post by Ultima on May 6, 2008 23:20:33 GMT -5
|
|
|
Post by Gamesoul Master on May 7, 2008 6:48:33 GMT -5
psxemulator.proboards54.com/index.cgi?board=support&action=display&thread=460&page=11#4146I see your post and raise the reply... It *has* reached that time I spoke of, so it seemed good to bring it up again. Please bear with me on my following suggestion... Some of the controls, I don't think should be resizing at all. The drop-down menus, specifically. And besides the "Pad Mode" control on the Basic tab, all the drop-down menus are on the last tab. Now to make life easier and solve all our problems here, all you have to do is set those drop-down menus to not resize or move when the window size is changed. This can be done via the GUICtrlSetResizing class. Now obviously, there is a reason I'm bringing up the drop-down menus that don't really seem to relate to this at first. The reason is... consistancy. It would look quite funny for two input boxes to not resize or move while all the rest do. The solution... make *all* windows that have no business resizing (as drop-down menus will *always* only need the width they're given) a static width. Obviously the other input boxes have a right to be resized, since they could potentially be holding long directory paths in them. And if two little input boxes for the width and height look a bit odd because of the free space left over, I see that if you increase the starting width of the whole window by a small amount, you could shrink the Aspect Ratio drop-down menu to a logical size for its contents, and put all three window size boxes (multiplier drop-down menu and two size input boxes) on the same line. It wouldn't look bad without doing that, but if you really don't like the free space left on the window size line, that's an easily implemented solution. It's not a lot of work to do, and it'll be good in that step towards putting the final shine on your program. And it solves the problems you were having before of course. Edit: Another thing for general tidying up... The context menu on the "Run pSX" button. No complaints about the "Do After" set of options at all, but having it as a context menu to a button sort-of makes it a hidden option. Might it be better to put it either in the File menu, or create an Options menu for that to go in? Context menus are great, but nobody really thinks to right-click a button.
|
|
|
Post by Ultima on Jun 23, 2008 20:31:46 GMT -5
ultima.psx.googlepages.com/psxfrontendv112winWIP3.rarDetailed view optimization, menus, resolution checking -- the whole nine yards... Toy with 'em This build should be MUCH faster, and the whole desktop should no longer flicker on startup/exit. Wewt! String manipulation is braindead simple in AutoIt, so parsing manually-inputted strings isn't too tough
|
|
|
Post by Gamesoul Master on Jun 24, 2008 3:16:01 GMT -5
I'll definitely be toying with this sometime in the next day. I'm heading off to bed now, else I'd take a look right now. I'm really happy to see an update though... ^^
|
|