bsnes v0.037a released

[franpa]

it spaces them, makes it easier to read, easier on the eyes. I don't see how there is no reason to keep it?

[FitzRoy]

You have pinstriped rows with two or less words on them, and you still need double spacing rules to help you read it? Wow. Just wow.

[Verdauga Greeneyes]

It doesn't bother me personally; I can read both versions just fine, but the new version does feel a bit less cramped. Besides, why the extreme focus on compactness? We're not trying to get bsnes to run on mobile phones here.

[FitzRoy]

Besides, why the extreme focus on compactness? We're not trying to get bsnes to run on mobile phones here.

It makes buttons shorter than hot dogs and reduces empty space in a way that doesn't involve overwhelming newbs with useless options and information. And I'll take that bet and raise you $1000 that a pandora-like device within the next ten years will run bsnes at 60fps.

Triple spacing would be even less cramped, so why not go there? You innately recognize that separating beyond what is sufficient for distinction scatters information across a wider swath of space and increases eye movement, or you wouldn't have stopped at all.

[Verdauga Greeneyes]

And I'll take that bet and raise you $1000 that a pandora-like device within the next ten years will run bsnes at 60fps.

Triple spacing would be even less cramped, so why not go there? You innately recognize that separating beyond what is sufficient for distinction scatters information across a wider swath of space and increases eye movement, or you wouldn't have stopped at all.

Even so, I don't think it's feasible to adjust the GUI to the point where it would look good on such a tiny screen. Anyway, while I recognise that more space isn't always a good thing, that doesn't mean there isn't a sweet spot between 'just enough to keep them apart' and the other extreme. I don't know if this is that sweet spot ... to determine that you'd need a slider to adjust the spacing with a preview (like character customization in games), and even then we might not agree.

[creaothceann]

Yeah, it might be 'too complicated' then.

[LiL_Stenly]

The author must import the languages in the next version .
I think that would be better if the languages can be changed by the menu .
Example with some base script .

Code: Select all

getlang
 set:{language(lang)
  if: {getlang = $Bulgarian(bg.cfg);
   then: {lang = !getlang|contunue;
  }}}
 }}
}

p.s. I don't know what is the type of that script , whatever ... the process is something like that .

[FitzRoy]

Even so, I don't think it's feasible to adjust the GUI to the point where it would look good on such a tiny screen.

640x480 isn't so tiny. Anyway, traditional separation is a couple pixels and I haven't seen a single person complain about this degree of separation in Windows. Where people try to deviate from this concept is not applications like this, it's where margins break up sentences in prose to create continuation points, requiring you to scan your eyes back and find it. The wider the page relative to the size of the font, the easier it is to mistake your continuation points. Which is why for academic papers, you see double spacing, but for books you rarely do, because of the difference in page width.

That people don't understand this and then try to apply it to everything else irks me. Take NSRT for example. In the navigation bar, each item is preceded by a pointless image that forces the line spacing to be about triple what is necessary. Not only does this halve the number of items that can be displayed at one time, it doubles the amount of space the tiny scrollbar has to represent, making it harder to navigate to items smoothly without overshooting. Is this better? Do I have 8" of columns here to pair up? Do I have any continuation points? Of course not.

[F-3582]

F-3582, cool thanks. You have the WIP URL, right?

Nope, don't have it.

I hope not to promise too much, because last time I tried Bsnes on my Linux box (a 1,7GHz Dothan Pentium-M with a mobilityRadeon 9700) it stuttered like hell. I suppose that stuttering in sync with the gameplay should already be enough to tell if you programmed the Pulseaudio support correctly, right?

[franpa]

Besides, why the extreme focus on compactness? We're not trying to get bsnes to run on mobile phones here.

It makes buttons shorter than hot dogs and reduces empty space in a way that doesn't involve overwhelming newbs with useless options and information. And I'll take that bet and raise you $1000 that a pandora-like device within the next ten years will run bsnes at 60fps.

Until that time, why make it compact?

Triple spacing would be even less cramped, so why not go there? You innately recognize that separating beyond what is sufficient for distinction scatters information across a wider swath of space and increases eye movement, or you wouldn't have stopped at all.

So you would rather a world where you don't need to move your eyes at all?

[FitzRoy]

Until that time, why make it compact?

Right, because it's a total given that byuu will be here ten years from now. And are you completely ignoring the part about the empty space still? By pointlessly using double space rules on a dinky gui, you are elongating the empty space in four sections. Address that already. Address it.

[byuu]

And are you completely ignoring the part about the empty space still?

If you used Linux, you'd see that the narrow listbox is very out of place compared to every other app. Kind of like the Windows port used to be (well, kind of still is) with 30px combo boxes. I realize Linux has a ~2% market share (probably ~10% of bsnes users), but it's the OS I use -- I want it to look good there, too.

Anyway, this really isn't a big deal. It adds 24px to the height, and we can cut back 40px when we move the "when emulator lacks focus" block to another panel. The window will then be 585x340, somewhere between 16:9 and 16:10 ratio.

Let's come up with a plan for the other stuff. We need places for the following:
- driver selection sans cap info
- out-of-focus input behavior
- NTSC filter settings (long overdue)
-- most important is the merge fields setting
-- would be nice to support profiles (S-Video, composite, RF, ...)
-- would probably be overkill to support hue / tone / etc.

We could add the following trivial things to make a section more coherent (in order of usefulness), but none of this is needed:
- input axis calibration
- allow invalid input
- UI transparency level
- UPS CRC check disable
- deep file-type inspection (really only benefits Mac users)

We could put multiple things on the same tab, and group them by category with frame boxes. Need a good name, too. "General" / "Miscellaneous" / "Other" / "Ninth Circle" ...

If you're still not happy, then perhaps it's time we start planning an auto-sizing system for controls. The #1 thing needed for this is the ability to determine the literal font height in pixels. Easy on Windows, feasible on Linux.

Also, there's a native port of GTK+ to OS X out now. It would be cool if someone could look into the prospect of porting bsnes now. Not to replace Bannister's port -- it'd be source only and not Apple HIG compliant, but to increase portability, have a big endian platform to test on, and potentially let more developers work on the core.

Right, because it's a total given that byuu will be here ten years from now.

D:

The author must import the languages in the next version .
I think that would be better if the languages can be changed by the menu.

Would be nice, sure but:

Problem 1: I don't have updated locales at the time of release. It's not a good idea to update the archive repeatedly, as sites like to cache and validate MD5SUMs and such against them. Especially for the Linux port.
We can't keep the UI strings the same for two days, let alone two releases :(

Problem 2: I don't even know how to change the text of menu items in Windows. And even if I did, I would have to make one massive routine to set the text for every single line of text in the UI. It'd add a good ~250 lines of very messy, hard to maintain code.

[FitzRoy]

If you used Linux, you'd see that the narrow listbox is very out of place compared to every other app. Kind of like the Windows port used to be (well, kind of still is) with 30px combo boxes. I realize Linux has a ~2% market share (probably ~10% of bsnes users), but it's the OS I use -- I want it to look good there, too.

I understand, I think more than anything I'm amazed at the discrepancy between the two. In windows, my lists populate 2/3 the height that the linux ones do.

Let's come up with a plan for the other stuff. We need places for the following:

First off, I realized today that the buttons in the input section could be removed at no cost. Double-clicking entries does the same thing as assign and is faster. Unassign isn't that useful, but duplicating that would be easy by creating an animated 4 second countdown on the capture window. If the countdown reaches 0 with no user action, the window closes and the button is unassigned.

Code: Select all

Assign a key or button to "Down"... 3... 2.... 1...

Next, the triple radio box can be simplified to one checkbox in that section and moved to the bottom of the section. Basically, there are two YES/NO things being conjoined here, only one having to do with input:

[ ] Allow input when window does not have focus.
[ ] Pause emulation when window does not have focus.

Now, most emulators only offer #2 if anything, including Nestopia which tries to make your breakfast. But I lost the battle to remove #1. #2 could be moved to the advanced section and disabled by default for the time being while we debate the worth of a Misc section. So that would resolve the logic of #2 being in the "Input" section and eliminate the only radio box in the gui.

Right, because it's a total given that byuu will be here ten years from now.

D:

Hey, I've seen enough people disappear or suddenly leave for health or financial reasons.

[Thristian]

If you're still not happy, then perhaps it's time we start planning an auto-sizing system for controls. The #1 thing needed for this is the ability to determine the literal font height in pixels. Easy on Windows, feasible on Linux.

AAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA!

Sorry, I realise I'm being a horrible effete GUI pedant here, but it pains me so every time I see you wrestling with trying to statically size dialogs to take into account every variation of font and theme, things that GTK+ does for free. I figured the pain of manually positioning and sizing controls in GTK+ was less than the pain of trying to automatically position and size them in Win32, but if you *are* going to automatically position and size them anyway, please just let GTK+ do its thing and patch up Win32 :(

<trolling>And if Win32 is too broken, the Win32 port of GTK+ has looked pretty convincing for a while now...</trolling>

[AamirM]

Hi,

<trolling>And if Win32 is too broken, the Win32 port of GTK+ has looked pretty convincing for a while now...</trolling>

I have been doing this myself lately. Its going pretty well and the results are pretty consistent (except the input) on both Linux and Win32 builds (though, SDL+DSound = SDL+ALSA). Sound stuff is a mess on Linux.

Problem 2: I don't even know how to change the text of menu items in Windows. And even if I did, I would have to make one massive routine to set the text for every single line of text in the UI. It'd add a good ~250 lines of very messy, hard to maintain code.

Very correct. I am not going to distribute localization files with a release myself due to these problems. In case somebody is wondering, here is a glimpse of "very messy, hard to maintain code" (probably even uglier than what byuu or someone else would've written ):

Code: Select all

#define GET_SHORTCUT1(Name, DefaultVal, Pos, ID, String, Submenu, Spos)		\
GetPrivateProfileStringW(L"Shortcuts", Name, DefaultVal, shortcut, 128, cfg_filew);	\
GetPrivateProfileStringW(L"Translations", Name, String, lngbuf, 256, lng_file);	\
if(set) set_shortcut(shortcut, Pos, ID);	\
swprintf(menustring, L"%s\t%s", lngbuf, shortcut);	\
ModifyMenuW(GetSubMenu(hMenu,Submenu), Spos,MF_BYPOSITION | MF_STRING, ID, menustring)

#define GET_SHORTCUT(Name, DefaultVal, Pos, ID, String, Submenu, Spos)	\
		GET_SHORTCUT1(L##Name, L##DefaultVal, Pos, ID, L##String, Submenu, Spos)

void load_shortcuts(int set)
{
	wchar_t shortcut[128];
	wchar_t menustring[512];
	wchar_t lngbuf[256];

	GET_SHORTCUT("LoadRom", "Ctrl + G", 0, ID_FILE_LOADROM, "Load ROM", 0, 0);
	GET_SHORTCUT("SoftReset", "Ctrl + R", 1, ID_FILE_SOFTRESET, "Soft Reset", 0, 4);
	GET_SHORTCUT("HardReset", "Shift + R", 2, ID_FILE_HARDRESET, "Hard Reset", 0, 5);
	GET_SHORTCUT("PowerOff", "Shift + P", 3, ID_FILE_POWEROFF, "Power Off", 0, 6);
	GET_SHORTCUT("SaveStateAs", "F11", 4, ID_FILE_SAVESTATEAS, "Save State As...", 0, 10);
	GET_SHORTCUT("LoadStateAs", "F12", 5, ID_FILE_LOADSTATEAS, "Load State As...", 0, 11);

......
}

It does demonstrates how to change menu item text on Windows though .

stay safe,

AamirM

[creaothceann]

<offtopic>

Why don't you indent the code like below? Maybe it's just me, but it looks unreadable...

Code: Select all

#define GET_SHORTCUT1(Name, DefaultVal, Pos, ID, String, Submenu, Spos)                 \
GetPrivateProfileStringW(L"Shortcuts", Name, DefaultVal, shortcut, 128, cfg_filew);     \
GetPrivateProfileStringW(L"Translations", Name, String, lngbuf, 256, lng_file);         \
if(set) set_shortcut(shortcut, Pos, ID);                                                \
swprintf(menustring, L"%s\t%s", lngbuf, shortcut);                                      \
ModifyMenuW(GetSubMenu(hMenu,Submenu), Spos,MF_BYPOSITION | MF_STRING, ID, menustring)


#define GET_SHORTCUT (   Name,    DefaultVal, Pos, ID,    String, Submenu, Spos)        \
        GET_SHORTCUT1(L##Name, L##DefaultVal, Pos, ID, L##String, Submenu, Spos)

void load_shortcuts(int set)
{
        wchar_t shortcut  [128];
        wchar_t menustring[512];
        wchar_t lngbuf    [256];

        GET_SHORTCUT("LoadRom"    , "Ctrl + G" , 0, ID_FILE_LOADROM    , "Load ROM"        , 0,  0);
        GET_SHORTCUT("SoftReset"  , "Ctrl + R" , 1, ID_FILE_SOFTRESET  , "Soft Reset"      , 0,  4);
        GET_SHORTCUT("HardReset"  , "Shift + R", 2, ID_FILE_HARDRESET  , "Hard Reset"      , 0,  5);
        GET_SHORTCUT("PowerOff"   , "Shift + P", 3, ID_FILE_POWEROFF   , "Power Off"       , 0,  6);
        GET_SHORTCUT("SaveStateAs", "F11"      , 4, ID_FILE_SAVESTATEAS, "Save State As...", 0, 10);
        GET_SHORTCUT("LoadStateAs", "F12"      , 5, ID_FILE_LOADSTATEAS, "Load State As...", 0, 11);

......
}

[grinvader]

I find his snippet much more readable than yours, as a matter of fact.

Linewraps in code == bleaaarghhh

[creaothceann]

That's just because the browser window is too small.

I'll try to fix it...

[Rashidi]

Linewraps in code == bleaaarghhh

i'm seeing things! perhaps that because my low-res (only 1280 pixel horizontal) monitor...

i envy those extra wide desktop

[Rhapsody]

i'm seeing things! perhaps that because my low-res (only 1280 pixel horizontal) monitor...

i envy those extra wide desktop

1680x1050 here (I'd prefer 1920x1200, but whatever), even the indented snippet takes up maybe a third of the horizontal space. The extra space does make working with multiple windows a lot easier.

[gllt]

I never knew it actually was referencing to the linewrap caused by the browser, because I almost quoted it and said AND LOOK IT GETS WORSE

but I thought you were all talking about something much more intelligent

how silly of me

[byuu]

In windows, my lists populate 2/3 the height that the linux ones do.

Yeah, it sucks. But there's only so much you can do to make two platforms look the same while still making the app feel natural. GTK+/Win takes consistency too far, and you see how that looks.

If I can keep the list item text centered, I would be okay further reducing listbox item padding.

Double-clicking entries does the same thing as assign and is faster.

But is it 100% obvious to double-click entries? This is why the cheat editor has a toggle button, as well.

it pains me so every time I see you wrestling with trying to statically size dialogs to take into account every variation of font and theme, things that GTK+ does for free.

Windows doesn't support that at all. So I'd have to write a Win32 native resizer. And I really don't like the GTK+ box packing model. I'd want something more simplistic. I may write something like this one day.

The win32 port of GTK+, I do not like. Both because of the DLL dependency (they are huge, not everyone has them), and because it doesn't flow with the OS. Resizing for instance has many rendering problems.

It does demonstrates how to change menu item text on Windows though

Thank you! I will try and incorporate this. Now, I don't suppose you know of a way to hide / show the menu options without rebuilding the menu from scratch?

[franpa]

Double-clicking entries does the same thing as assign and is faster.

But is it 100% obvious to double-click entries? This is why the cheat editor has a toggle button, as well.

No it is not, I always used the buttons, I was going to request it as a feature but stumbled upon it by mistake.

[creaothceann]

Dude, checkboxes!

[byuu]

Checkboxes inside a listbox control is a very complex metaphor for a simplistic API wrapper. I could only justify the complexity if I went completely platform-specific.