ZSNES Looks Terrible!

[lordmissus]

MekaW (an SMS emulator) has a zsnes-like GUI too I believe...

you also missed the argument where no professional piece of software uses the standard windows decorations. like itunes, anything from adobe, steam, windows messenger (and media player, and office 2003 and 2007), ccleaner, dvdfab, even the bigfishgames loader, etc.

so basically, EVERY program looks out of place to you.

[rchuncleskeleton]

nooooooo...don't change the GUI!!! I love the current GUI, if someone wants to complain about it then they can use another emu or get a dang frontend. the gui is awesome and whoever said it's a pain in the a$$ needs to grow a brain and realize that all software is different and you need to adapt.

[sweener2001]

did you forget that the zsnes window is resolution-locked?

[byuu]

did you forget that the zsnes window is resolution-locked?

You can blit the internal 256x224 video inside a bordered window. Look at pagefault's first Qt screenshots for instance.

[FitzRoy]

Play a game and you won't see the interface. Frankly, why care what it looks like anyway, so long as it functions properly.

There are some genuinely annoying drawbacks about this type of GUI, let's not be blinded by retro manlove.

- There's generally just not much room to display any long strings of text for cheat descriptions or filenames at such low resolution. It's hard to know what you're loading because you can't often see the region tags at the end of the filename.
- No submenus, makes switching controller types a chore.
- No drop drown boxes or other fancy things, makes it hard to condense stuff without creating lots of sections and tabs.
- The mouse cursor has to be "captured" in the window.
- The minimize and maximize buttons are too darn small, looks like maybe they ran out of menubar space.

[Gil_Hamilton]

Play a game and you won't see the interface. Frankly, why care what it looks like anyway, so long as it functions properly.

There are some genuinely annoying drawbacks about this type of GUI, let's not be blinded by retro manlove.

- There's generally just not much room to display any long strings of text for cheat descriptions or filenames at such low resolution. It's hard to know what you're loading because you can't often see the region tags at the end of the filename.

Hardly unique to low-res custom GUIs.
I can point to plenty of standard Win9X GUIs with that problem.

- No submenus, makes switching controller types a chore.

Plenty of ways to handle that, hardly requiring a generic GUI of ass.
Hell, submenus could be added to the ZSNES style.

Though I think they should be used sparingly.

- No drop drown boxes or other fancy things, makes it hard to condense stuff without creating lots of sections and tabs.

Nothing says it can't be implemented. Again, sparingly.

- The mouse cursor has to be "captured" in the window.

MISC/GUI OPTS/TRAP MOUSE CURSOR
Thank you for playing.



Please don't misconstrue "the existing ZSNES GUI has some flaws" to mean "a generic Windows GUI is the only way to do things"

[alyxx]

I have no problems using the current GUI, except for that the filenames don't show correctly in ZSNES if they are too long, but that can be fixed by associating SMC-files with ZSNES and opening them via Explorer.

[grinvader]

The main issue of the gui as it is is not style or even source language but code location.
The emulation loop calls the gui instead of the reverse, causing many, many issues.

This is why it will be redone.
Eventually.

[lordmissus]

I guess my only real issue with the zsnes GUI in it's current form is how you can't copy/paste any text to/from it. Much of a hassle when it then mandates that I manually type out cheat codes (a bitch when I mistype it and fuck the entire game).

[Berret]

did you forget that the zsnes window is resolution-locked?

First off, picture=rofl.

But you bring up a good point sweener, even if you didn't intend to. I know this is apples and oranges, but ePsxe can shift resolution on the fly by stretching with borders. Once the rewrite is finished, I expect the new prog-lang and skinning profiles will accommodate to the current lack of functionality within a next-gen OS. It's true, the retro feel gives me good feelings all around, but honestly we have to admit that it will limit functionality and stop the future development of this emulator. (I am of course thinking in the very long run)

The rewrite is an excellent idea and should propose a fix to the fact that a "16-bit" interface, or whatever you want to call zsnes's gui, is now completely primitive to our technology today. Another thing the current interface cannot handle is tablet technology. The rewrite should be able to remedy this as well, if I am expecting the correct changes.(?)

[funkyass]

The UI has nothing do to if tablets would work in zsnes.

[Berret]

Alright, so if the UI doesn't then what does? No sarcasm here, it seems like you know.

[FitzRoy]

Hardly unique to low-res custom GUIs.

Yeah, and those are annoying, too. What's your point? I suppose you could eliminate the useless options in the load screen to free up a line for wrapping the text around instead of cutting it off. Even if you did that, though, you're still clicking on everything to find the right one because the directory list eats into names as displayed in the content list. That you can also only show 15 files in the list at a time is also a limitation easily overcome by modern GUIs. It's too hard to reach the location you want with that short a list and scrollbar when your directory has thousands of files.

MISC/GUI OPTS/TRAP MOUSE CURSOR

Sorry, that section has about 57 options with truncated words and descriptions scattered all over the place. It used to be that the mouse was trapped by default, but it's apparently been fixed after all these years, so I withdraw that criticism. But that's just it: this GUI type requires too much special attention, it's taken years just to get it to this point. Dropdown boxes "could" be implemented. You "could" have a browse feature instead of having to type in the paths. And then you're still stuck with limitations you can't possibly overcome, so why bother? Moving away from it makes sense.

[Berret]

Dropdown boxes "could" be implemented. You "could" have a browse feature instead of having to type in the paths. And then you're still stuck with limitations you can't possibly overcome, so why bother? Moving away from it makes sense.

I agree.

The developers have worked very hard on this project and have a lot to show for it, so it's not to say we don't like what we have (you guys rock!!), but it is to say that now is the time to take the next step in the development process.

Unfortunately I'm not a coder - I can't do much other than beta, suggest, and workaround - but I know that what we are discussing here is certainly possible, plausible, and efficient.

[sweener2001]

i like the part where people are talking about this like it isn't already being worked on

[Gil_Hamilton]

Hardly unique to low-res custom GUIs.

Yeah, and those are annoying, too. What's your point?

That blaming a stylized GUI for a COMMON design failure is disingenuous.

I suppose you could eliminate the useless options in the load screen to free up a line for wrapping the text around instead of cutting it off.

Or you could keep your file names under 36 characters, which is HARDLY an irrational limit for an SNES game collection. It is, interestingly, EXACTLY the number of characters that shows in my Standard Windows File Load Boxes.


Though you're still intentionally confusing the issue by throwing a restriction tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason NO NON-STANDARD IMPLEMENTATION can work.

Even if you did that, though, you're still clicking on everything to find the right one because the directory list eats into names as displayed in the content list.

A. 23 characters is HARDLY a handicap.
B. Arrow keys are your friend.
C. You're intentionally confusing the issue by throwing a restriction tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason NO NON-STANDARD IMPLEMENTATION can work.

That you can also only show 15 files in the list at a time is also a limitation easily overcome by modern GUIs.

It is, interestingly, EXACTLY the number of rows files that shows in my Standard Windows File Load Boxes.


Except that the Standard Windows File Load Box penalizes me by including directories in that list, because it doesn't have a separate directory view, while ZSNES GUI does.

But I'm confusing the issue by throwing a benefit tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason ALL NON-STANDARD IMPLEMENTATIONS can work.


Columns varies with name length, as the Standard Windows File Load Box defaults to "list view."
But we've already established that we're using LOOOONG file names, so you'll only get one column.

And you're still intentionally confusing the issue by throwing a restriction tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason NO NON-STANDARD IMPLEMENTATION can work.

It's too hard to reach the location you want with that short a list and scrollbar when your directory has thousands of files.

If you have thousands of files in a single directory, you will be scrolling extensively no matter WHAT the size of your load dialog box.
Much like the Standard Windows File Load Box, ZSNES includes a scrollbar with a drag-able button that doubles as an indicator of how far down the list you are.



Or you can just start typing the file name, which works in both the existing ZSNES GUI AND a Standard Windows File Load box. And actually works BETTER in ZSNES GUI than the Standard Windows File Load Box.

Though I'm confusing the issue by throwing a benefit tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason ALL NON-STANDARD IMPLEMENTATIONS can work.

MISC/GUI OPTS/TRAP MOUSE CURSOR

Sorry, that section has about 57 options

There's not room for 57 options in that window and you know it.

And you're still intentionally confusing the issue by throwing a restriction tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason NO NON-STANDARD IMPLEMENTATION can work.

But that's just it: this GUI type requires too much special attention, it's taken years just to get it to this point. Dropdown boxes "could" be implemented. You "could" have a browse feature instead of having to type in the paths. And then you're still stuck with limitations you can't possibly overcome, so why bother? Moving away from it makes sense.

You're either dense, or intentionally substituting "ugly decade-old patchwork of assembly code" for "anything with a design aesthetic" to confuse the issue.


NO ONE is saying that the underlying codebase of the ZSNES GUI should be kept.
No one's even said that the existing GUI is a perfect interface.


This is purely an aesthetics argument, and it's plainly clear from a number of active, thriving products that an appropriately-themed GUI in no way hinders functionality.
Hell, a lot of them don't even HAVE traditional drop-down menus.


Or in other words... you're intentionally confusing the issue by throwing a restriction tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason NO NON-STANDARD IMPLEMENTATION can work.

Please don't misconstrue "the existing ZSNES GUI has some flaws" to mean "a generic Windows GUI is the only way to do things"

[blackmyst]

The visual appearance of zsnes should be kept the same even after the rewrite, just to spite playstation generation crybabies, or douchebags who want to make some sort of fashion statement with their desktop. ;)

[Deathlike2]

The visual appearance of zsnes should be kept the same even after the rewrite, just to spite playstation generation crybabies, or douchebags who want to make some sort of fashion statement with their desktop.

There's an version of Gens IIRC that failed horribly using the menus in ways that make Baby Jesus cry.

I understand asthetics can annoy people, but on the other hand, extremely poor GUI design is some subtle creation of HILTER.

[byuu]

And then you're still stuck with limitations you can't possibly overcome, so why bother?

True platform independence: having the same UI on all platforms without dealing with issues like Qt not appending a trailing backslash on folder select on some systems, or not having a port available for the Xbox 360, etc.

In this case, obviously a hold-over to MS-DOS, which was the only target supported by ZSNES when the GUI first arose.

Or you could keep your file names under 36 characters, which is HARDLY an irrational limit for an SNES game collection.

Except of course the two biggest ROM cataloging tools easily exceed that. Of course, I use Linux whose dialog boxes can't match case insensitively, so I have to use lowercase names anyway. It is fun trying to remember what superfb.smc was at a glance.

It is, interestingly, EXACTLY the number of rows files that shows in my Standard Windows File Load Boxes.

The thing is, you can resize the standard boxes as you like. As of Vista and later, it actually saves this setting, even across reboots, and per application. Compare:





Lots of things that could improve even the rasterized approach: a variable-width font, auto color-coding the background item based on the region suffix (eg if(strpos(filename, "(J)")) backColor = #ff0000;), having the name at the bottom scroll back and forth, merging files and directories with icons to tell them apart, etc.

Except that the Standard Windows File Load Box penalizes me by including directories in that list, because it doesn't have a separate directory view, while ZSNES GUI does.

Ugh, there's a reason separate files and folders went out of style with Windows 3.1. We can argue preferences and <insert random person's name here>'s Laws of UI design, but the fact that no modern OS has done this for the last fifteen years is a good indication of majority opinion on the matter.

Or you can just start typing the file name, which works in both the existing ZSNES GUI AND a Standard Windows File Load box.

Win.

Only sucks for developers (and "gotta collect 'em all" types) who have to have all the regional variants of Zelda 3, for instance. Without renaming them, I literally can't tell which is which except through rote memory ("okay, there's no German or French version, so they must be E, J and U ... so pick the third one.")

This is purely an aesthetics argument, and it's plainly clear from a number of active, thriving products that an appropriately-themed GUI in no way hinders functionality.

Not even sure why we're arguing about this. ZSNES will have a Qt UI, and that UI can appear either completely standard or themed to look exactly like the old UI.

Everyone wins.

[Gil_Hamilton]

Or you could keep your file names under 36 characters, which is HARDLY an irrational limit for an SNES game collection.

Except of course the two biggest ROM cataloging tools easily exceed that. Of course, I use Linux whose dialog boxes can't match case insensitively, so I have to use lowercase names anyway. It is fun trying to remember what superfb.smc was at a glance.

Your screenshot shows that. I've never figured out who thought those Sailor Moon games had good filenames there.

It is, interestingly, EXACTLY the number of rows files that shows in my Standard Windows File Load Boxes.

The thing is, you can resize the standard boxes as you like. As of Vista and later, it actually saves this setting, even across reboots, and per application. Compare:

http://img7.imageshack.us/img7/9826/winjfs.png

http://img7.imageshack.us/img7/4765/zsnes.png

It saves it now?
That's very good.

It doesn't in XP. So I considered the resizing a moot point.
Don't think it was resizable at all in 9x/2K.

Lots of things that could improve even the rasterized approach: a variable-width font, auto color-coding the background item based on the region suffix (eg if(strpos(filename, "(J)")) backColor = #ff0000;), having the name at the bottom scroll back and forth, merging files and directories with icons to tell them apart, etc.

Oh, yeah... don't get me wrong, I'm not saying the ZSNES GUI is pefect by a longshot.

Except that the Standard Windows File Load Box penalizes me by including directories in that list, because it doesn't have a separate directory view, while ZSNES GUI does.

Ugh, there's a reason separate files and folders went out of style with Windows 3.1. We can argue preferences and <insert random person's name here>'s Laws of UI design, but the fact that no modern OS has done this for the last fifteen years is a good indication of majority opinion on the matter.

I admit I'm not a typical user, but I love having a directory tree available.

Admittedly, for most open dialogs it's overkill, or even detrimental.
But if you need to get far away from your current directory, or if you're in a directory with a lot of subdirectories(spoilers: my SNES games are sorted by genre and/or series), it's nice to have them broken out.

This is purely an aesthetics argument, and it's plainly clear from a number of active, thriving products that an appropriately-themed GUI in no way hinders functionality.

Not even sure why we're arguing about this. ZSNES will have a Qt UI, and that UI can appear either completely standard or themed to look exactly like the old UI.

Everyone wins.

Because it's the internet. Flamewars keep the tubes from freezing.
I'm doing my part to help the flow of information! What about you?

[franpa]

It is, interestingly, EXACTLY the number of rows files that shows in my Standard Windows File Load Boxes.

The thing is, you can resize the standard boxes as you like. As of Vista and later, it actually saves this setting, even across reboots, and per application. Compare:

http://img7.imageshack.us/img7/9826/winjfs.png

http://img7.imageshack.us/img7/4765/zsnes.png

It saves it now?
That's very good.

It doesn't in XP. So I considered the resizing a moot point.
Don't think it was resizable at all in 9x/2K.

It does save it for most Windows in XP, you just have to hold CONTROL down while closing the window/application to save the size. In Vista and newer it does away with the need to hold CTRL.

EDIT: Stupid quote layout.

[sweener2001]

most burning suites have a separate directory window, but i suppose that's different from an 'open file' box. oddly enough, itunes added a directory tree very recently to their 'add folder' option.

i find the argument stupid, since there is that whole thread about the new gui in the development forum.

but when it comes to basics, like opening a game and setting your controller and video options, i find that the zsnes gui is plenty adequate. it's the extra stuff that's come over time that's cluttered it up.

[byuu]

I've never figured out who thought those Sailor Moon games had good filenames there.

Mostly trying to follow a strict pattern, eg "put the entire title as it shows (in the game / on the box)" etc. Consistency is nice, but so is common sense.

I admit I'm not a typical user, but I love having a directory tree available.

It's honestly another argument for standard GUIs: you can choose between icon, list and compact views ... there should be a view that separates folders from files.

But just like having compressed-archive support built-in to the OS (if you're picking one file and it's a ZIP/7z file, auto-decompress the one file in it. If there's more than one file, enter into the archive as if it were a folder and let the user pick one), it'll probably never happen. OS designers love to make every last app developer re-invent the wheel.

To be honest, I dislike almost all custom UIs. It's actually part of the thing I hate about Windows: every vendor, even Microsoft, has to go out of their way to make things as different and confusing as possible. Paint in Win7 for instance is practically unusable. I can see the allure of OS X, it's just that I think the design (eg menubar at the top, document interface instead of window interface, etc) sucks, personally.

Flamewars keep the tubes from freezing. I'm doing my part to help the flow of information! What about you?

I've been mobilizing an army of accuracy zealots to go to war against ZSNES, of course :P

[Gil_Hamilton]

Flamewars keep the tubes from freezing. I'm doing my part to help the flow of information! What about you?

I've been mobilizing an army of accuracy zealots to go to war against ZSNES, of course

You're a good man!

[FitzRoy]

That blaming a stylized GUI for a COMMON design failure is disingenuous.

It's not a design failure, it's a design limitation. A 256x224 resolution window doesn't offer enough space to show long strings of text without putting scrollbars everywhere, and the scrollbars eat space themselves. What is this Windows equivalent you're talking about? The load box is it's own resizeable window, it isn't confined by the display area of the program.

Or you could keep your file names under 36 characters, which is HARDLY an irrational limit for an SNES game collection.

No, I'm not manually truncating game titles on my end.

Though you're still intentionally confusing the issue by throwing a restriction tied to THIS SPECIFIC IMPLEMENTATION as an example of a reason NO NON-STANDARD IMPLEMENTATION can work.

If they could create separate, resizeable windows, why haven't they already? Either it's not possible or it's too time consuming. I could care less if a PS2 emulator wouldn't have space problems, that has nothing to do with anything.

A. 23 characters is HARDLY a handicap.

You want modern operating systems to impose a 23 character limit on all files? How can you seriously suggest that would be enough?

B. Arrow keys are your friend.

There's an initial click to select the group you scrolled to, then the arrow or click are equally laborious ways of finding the tag you want in that group. All I have to do on other emulators is double click what I want because the filenames aren't truncated.

Except that the Standard Windows File Load Box penalizes me by including directories in that list, because it doesn't have a separate directory view, while ZSNES GUI does.

First of all, why would a rom directory have lots of folders within it? Secondly, who cares? It's so much larger that the "penalty" is more than negated by being able to view like 200 files or folders at a time.

If you have thousands of files in a single directory, you will be scrolling extensively no matter WHAT the size of your load dialog box.

If a directory has 3000 files, and the content box can display 15 items at once, and the scrollbar has 200 pixels to move along, that makes each pixel an interval, and each interval a 15 item teleport. Way too sensitive, you'll just be over and undershooting.

Or you can just start typing the file name, which works in both the existing ZSNES GUI AND a Standard Windows File Load box. And actually works BETTER in ZSNES GUI than the Standard Windows File Load Box.

Faster, yes, but if I can get away with not pecking a bunch of shit, I'm usually going to keep my hand on the mouse and gamepad.

There's not room for 57 options in that window and you know it.

It's hyperbole, I'm not going to count how many there are. Enough to conveniently eliminate any blank space.

This is purely an aesthetics argument, and it's plainly clear from a number of active, thriving products that an appropriately-themed GUI in no way hinders functionality.

If it's an aesthetics issue, then custom GUIs still suck, because then each program has its own predetermined theme and users can't make them all match to some central theme that they want. Yeah, really great having a program that's orange, next to one that's blue, next to one that's pink. It effectively makes every computer's theme "fruit loops".

I didn't think there was this much resistance to a standard GUI anymore. Whatever.