bsnes v0.036 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

Take your time byuu. :)
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
ZH/Franky

Post by ZH/Franky »

You're such a trooper. We all believe in you byuu.
gllt
NO VOWELS >:[
Posts: 753
Joined: Sun Aug 31, 2008 12:59 pm
Location: ALABAMA
Contact:

Post by gllt »

If I had tupperware, I'd mail you my soup.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: Updated nall::sort from insertion sort to merge sort* [O(n log n)], and then used that to add a "Keep cheat code list sorted by description" checkbox to the cheat code editor. I'll admit this probably isn't very useful, I really just wanted an excuse to implement a proper sorting algorithm and get rid of the embarassing O(n^2) sorting code I had in my template library. It's actually the first time in 11 years of programming that I've ever used a sort function in an application, believe it or not. I'll make it an advanced mode option if it really bothers people (eg as feature bloat.) It was only ~12 extra lines of code.
(* not using quick sort as I need a stable sort for my purposes (eg two descriptions that are the same, but with different codes -- it shouldn't bounce around every time the list changes or you toggle the sort option), and it's nice avoiding the worst-case O(n^2) issue with quick sort.)
What if someone wants to sort by code or status? Was it not possible to implement that standard moving arrow thing on the column tabs themselves?
Updated the mouse acquired check to work, but only on mouse input. Not that it matters much since I still don't have a method for distinguishing between mouse and joypad movement deltas. Eg this build only works with joypads, not mice.
I think a good idea at this point would be to forsake the mouse for now. Disable axis detection in the input window, add the peripheral entries to the input menus, and display their assignments in a grayed out area. The assignments could be preset to joystick axes, joystick buttons 0-3. That's still very usable.
byuu

Post by byuu »

What if someone wants to sort by code or status? Was it not possible to implement that standard moving arrow thing on the column tabs themselves?
Would be nice, but I haven't the first idea how to capture column header clicks and set the arrow states of those things on either Windows or GTK+ ... not even sure if it's doable under GTK+.

Really too bad we have to be cross-platform, so many cool things we could do like make the enabled/disabled text an actual check box right inside the listbox.
I think a good idea at this point would be to forsake the mouse for now. Disable axis detection in the input window, add the peripheral entries to the input menus, and display their assignments in a grayed out area. The assignments could be preset to joystick axes, joystick buttons 0-3. That's still very usable.
Maybe, it just sucks that we're so damn close now. All that's really needed is a scalar for mouse axes.
byuu

Post by byuu »

Another WIP.

A few changes here; I added on_change notifications to both Windows and Linux textboxes. I use that to only enable the "Add Code" button on the cheat code screen when a valid GG/PAR code is entered. A bit nicer than just not doing anything when you click "Add Code". Also disabled toggle / delete code when one is not selected. Minor touches.

Added on_input mouse capture to the canvas widget for Linux. Needed for the input.acquire() mouse capture hook.

Tried to use SDL_WM_GrabInput and SDL_GetRelativeMouseState ... doesn't work at all. Unless SDL creates the window itself, it doesn't give you any mouse info. SDL_WINDOWID hack doesn't work here either, same issue with the keyboard input and why I had to use raw Xlib there.

So, I use XGrabPointer + XQueryPointer + XWarpPointer and some magic to make my own invisible cursor. Major pain in the ass. It works okay, but it feels a bit too jumpy ... I'm going to try screwing around with the acceleration controls to see if I can smooth it out a bit.

And hooray, more fucking cross-platform headache:
Windows: button 1 = right, 2 = middle
Linux: button 1 = middle, 2 = right

I had to completely disable the scale for this build to get the mouse to work well on Linux, so no joypad axes for this one. I'd be interested to see how the mouse performs for FitzRoy; where the last one was too slow, this should be 5x faster. Surprisingly still playable for me, but a bit too fast for my tastes.

The scalar of 1 feels great for Windows with the cheapo 400dpi mouse here, too. I think this is a reasonable default.

-----

Detecting listbox column header clicks was easy enough on Windows:

Code: Select all

if(((LPNMHDR)lparam)->code == LVN_COLUMNCLICK) {
  printf("%d\n", ((LPNMLISTVIEW)lparam)->iSubItem);
}
And of course, there's no obvious way to do the same with GTK+:

http://www.gtk.org/api/2.6/gtk/GtkTreeView.html
http://www.gtk.org/api/2.6/gtk/GtkTreeViewColumn.html
http://www.gtk.org/api/2.6/gtk/TreeWidget.html

I have a couple of hangups about a column sort click, anyway.

1) there's no logical reason to sort by code (they're technically gibberish, especially encoded Game Genie codes), status (you want the list to change around when you toggle the status? yuck), or by reverse description (scroll to the bottom and read up, same thing.)
2) it won't save the setting across runs; each time you load a new game, you'll have to re-click to sort the list.
3) there'd be no way to stop sorting completely.

But again, we can make this a hidden option like deep filetype detection if it's too obscure.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Yeah, that works really well. I got to round 27 on lethal enforcers training, made captain at one point. Then it just gets ridiculously hard. I honestly think it just goes on forever like pinball and Tiger Heli.
byuu wrote:A
And hooray, more fucking cross-platform headache:
Windows: button 1 = right, 2 = middle
Linux: button 1 = middle, 2 = right
I don't even know if we can call this pedantic, because Windows is ordering priority instead of location which isn't that bad of an argument. Naturally, you'd want to concede things like this if you were looking to make transitional gains in the market, but... that's just not Linux's style. Clearly.

I have a couple of hangups about a column sort click, anyway.

1) there's no logical reason to sort by code (they're technically gibberish, especially encoded Game Genie codes), status (you want the list to change around when you toggle the status? yuck), or by reverse description (scroll to the bottom and read up, same thing.)
I don't know if the status one is all that crazy, I mean if you had a long list of codes, you could easily view all ones you had activated at a given time without having to scroll.

But even if only two of them get used, the real purpose is that it looks better than having some random checkbox options stuck in there.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

You could also number the cheats and have the default sorting be that column, i.e. the order in which they were added.

If this does get added, is there any chance of bsnes sorting subcategories as well? i.e. if you sorted by status, they would also be sorted either alphabetically or chronologically, depending on which sorting order you selected last
Actually, that's probably a natural side-effect of resorting in general. It's just that I've noticed that Windows Vista's search is insane here: if you sort by directory, the filename order will get completely messed up.
Thristian
Hazed
Posts: 76
Joined: Tue Feb 07, 2006 11:02 am

Post by Thristian »

byuu wrote:Detecting listbox column header clicks was easy enough on Windows:

Code: Select all

if(((LPNMHDR)lparam)->code == LVN_COLUMNCLICK) {
  printf("%d\n", ((LPNMLISTVIEW)lparam)->iSubItem);
}
And of course, there's no obvious way to do the same with GTK+
So, I went to the GTK+ homepage and clicked on Documentation. Right under "Tutorials" is a GTK+ 2.x TreeView Tutorial, and inside that, chapter 7 is all about sorting and section 7.3 tells you how to sort on column-header clicks.

Long story short, you don't catch the column-click event and invoke your sort algorithm, you tell GTK+ how to sort each column and it handles the rest.
byuu

Post by byuu »

So, I went to the GTK+ homepage and clicked on Documentation.
Geez, that probably would've helped when I was figuring out the rest of the commands from the API index. Thanks.
Long story short, you don't catch the column-click event and invoke your sort algorithm, you tell GTK+ how to sort each column and it handles the rest.
Meh, I don't like that at all; and it works nothing like on Windows. I know there's plenty of ways to "work around it", but none of them are at all pleasant. And none of them will be 100% transparent (as the 'sort function' is just for the comparator, not the actual sort), I would be forced to attach some sort of 'behind-the-scenes' IDs to each control to keep track of what sorted index referred what actual code in the list. Right now, my sort works on the underlying list, and I just re-add each code to the list after that in order. So I can easily do: Cheat::cheat_t info = cheat.get(listbox.get_selection());
(Again, I know how to work around it. Just seriously annoying to have to do so and make it portable to the Win32 API as well.)

Way too much trouble. I'll just move the cheat sort option to the advanced panel or something.
If this does get added, is there any chance of bsnes sorting subcategories as well? i.e. if you sorted by status, they would also be sorted either alphabetically or chronologically, depending on which sorting order you selected last
That requires a double-comparator for when the first comparator is equal. Yeah, I can add that, no problem. Just a tiny modification to cheat_t::operator<
I don't even know if we can call this pedantic, because Windows is ordering priority instead of location which isn't that bad of an argument. Naturally, you'd want to concede things like this if you were looking to make transitional gains in the market, but... that's just not Linux's style. Clearly.
Well, at least it's not as bad as Mac OS X. Such a shame that app developers are pretty much forced to code their applications for each and every platform if they want true integration. And for Linux, you get to do it twice: once for Qt, once for GTK+. Otherwise, someone's complaining about file dialog differences or something (valid complaints. But not ones to be directed at the bottom-tier app developers.)

So I wonder what happens on two-button mice ... is right-click then Button1? If so, how would you be able to tell when the right-mouse button was clicked if it's a moving target? If not, maybe I'll just forcibly swap the button order on one of the platforms to make it consistent.
Thristian
Hazed
Posts: 76
Joined: Tue Feb 07, 2006 11:02 am

Post by Thristian »

byuu wrote:I would be forced to attach some sort of 'behind-the-scenes' IDs to each control to keep track of what sorted index referred what actual code in the list. Right now, my sort works on the underlying list, and I just re-add each code to the list after that in order. So I can easily do: Cheat::cheat_t info = cheat.get(listbox.get_selection());
Yeah; from glancing at the documentation Win32 wants you to sort the Model while GTK+ will just sort the View - gtk_tree_selection_get_selected() returns items from the underlying unsorted list rather than indexes into the sorted list.

If I were writing an app, I'd much prefer GTK+'s way since it does a lot of the hard work for me, but I can see how it makes porting to simpler list-controls like Win32 much harder (imagine porting to Mac OS X's Cocoa GUI which tries to do even more work for you...)
So I wonder what happens on two-button mice ... is right-click then Button1? If so, how would you be able to tell when the right-mouse button was clicked if it's a moving target? If not, maybe I'll just forcibly swap the button order on one of the platforms to make it consistent.
X11 has been designed for three button mice since day 1 (maybe even as long ago as X10 or X9, who knows), so numbering the buttons 0, 1, 2 from left-to-right is pretty simple. Windows was designed for two-button mice, so left and right are 0 and 1 and any other buttons have to keep counting above that. Since the X11 protocol only really supports three buttons, two button mice generally have buttons 0 and 2, and button 1 is emulated by clicking both 0 and 2 together (this is controlled by the Emulate3Buttons option in xorg.conf).
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

Thristian wrote:X11 has been designed for three button mice since day 1 (maybe even as long ago as X10 or X9, who knows), so numbering the buttons 0, 1, 2 from left-to-right is pretty simple. Windows was designed for two-button mice, so left and right are 0 and 1 and any other buttons have to keep counting above that.
This goes back to the DOS "Microsoft Mouse driver" days. They just enumerated each button as it came along.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
byuu

Post by byuu »

New WIP, doesn't do much.

The core no longer scales axis values at all; and the platform input manager scales joypad axes only by 4096. Mice are unscaled here. Meaning you can use joypads and mice together at the same time now.

Also updated the input config panel to add all the new input devices. Assignment is still sketchy. My idea is to separate axis movement from button movement, and allow fast mouse movements (+/- 20 in a given direction) or strong joypad axis movements (~50% tolerance+) to assign axis stuff. For buttons, they'd work as before, but you can also click a mouse button with the mouse over the input capture window.

Disabled Xlib mouse acceleration during capture mode. I don't notice a difference, but I may as well leave it in case it matters somewhere. Sadly, it looks like buttons 4/5 are never set via XQueryPointer(), and you can only get buttons 6-9 with event callbacks. Since the input wrapper doesn't own the window (in actuality, GTK+ does), I can't safely bind the XEvents to capture those. So left, middle, right click only on Linux.

After that's done, we should start polishing for the next release.
gtk_tree_selection_get_selected() returns items from the underlying unsorted list rather than indexes into the sorted list.
Really? That's interesting. Not sure I like that. If I call listbox.set_selection(0), I would expect it to select the first entry, not the eleventh.

It does sound very convenient 99.9% of the time, though; I agree.
(imagine porting to Mac OS X's Cocoa GUI which tries to do even more work for you...)
Oh geez, let me guess. You can drag a listbox item out of one app, and drop it into another, and the other app can now invoke your callback functions for activate / change with it? :P
Since the X11 protocol only really supports three buttons, two button mice generally have buttons 0 and 2, and button 1 is emulated by clicking both 0 and 2 together (this is controlled by the Emulate3Buttons option in xorg.conf).
Excellent, very good to know, thank you. You sir, are a treasure trove of knowledge! :D

So, should I go the Windows way for the majority; or the Xlib way since it's a bit cleaner? At least, when you consider most mice have three buttons these days.
byuu

Post by byuu »

Another one, much closer this time to something releasable.

Rewrote all the non-core input handling code. Before I had giant lists of all controllers and various info about them all over the place. inputmanager.cpp had lists for the config setting -> keycode and state, another table to bind the input for each, another to poll each, another to return the state of each. inputsettings.cpp had one list to get name + setting, and another one to get list length + controller type. Really messy, so I dropped all that.

Now, all mappable input has a base class, InputObject, that stores the GUI name, type (boolean, axis), a reference to the config setting, the translated keycode, and the button state. Then there's an InputGroup class that binds sets of InputObjects together, eg InputGroup { LoadCart, PauseEmulator, ... } InputUIGeneral; and it also has name info as well.

This gets subclassed to InputDevice for SNES devices, which adds in the needed SNES::Input information (DeviceID, associated port, etc.)

After that, there's an InputDevicePool that groups every SNES controller together.

Each of these have iterators to go through all of their grouped objects. So instead of a bunch of hard-coded lists, there's only one for each SNES controller and GUI config group. Both the InputManager and InputConfigWindow classes use these lists, so they both dropped from ~15kb/file to ~3-5kb/file. I finally got a chance to use dynamic_cast<>, too! Use it to determine if an InputObject is really a SNES joypad to show the controller image or not. Cool stuff.

I also added code to block boolean settings from mapping to axes and vice versa, so the input config window is usable again; and I also mapped the Z-axis (scroll wheel) with DirectInput now.

Mouse buttons no longer require the mouse the be acquired, only mouse axes. And joypad axis scaling should be in a nice, semi-permanent place now.

The following bugs are known:
- once a game is loaded, the input config window stops mapping keys. This is because I can't poll the mouse outside the core, too, or it will throw off the relative mouse travel amount. I'll need to get everything polling from the same place.
- DirectInput joypad axis mapping is busted for some odd reason ... but it works fine with SDL. Map these by hand for now.
- the axis mapping is really super sensitive, I need to scale the state values down so that they require more force to map.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Your website got foobared somehow, I can't navigate to places.
byuu

Post by byuu »

New WIP finally adds non-ANSI filename support for GZ and ZIP archives. That plus the existing support for uncompressed filenames means it works with everything now but JMA archives. Compression support was enabled with this WIP for testing.

I used Nach's suggestion with gzdOpen() for GZ, but I had to modify ioapi.c for ZIP support, as there was no unzOpen() that took a file descriptor. No big deal, it was only a four-line change and it works great.

I noticed that the Windows hiro port wasn't sending the -1 position for when no items in a listbox were selected. That turned out to an absolutely major pain in the ass to support, thanks to the way Windows works. Say you switch from item #3 to no item, it will send "item 3 lost focus", but nothing for the fact that no item has focus. Easy enough, but then if you switch from item #3 to item #4, it sends "item 3 lost focus", followed by "item 4 gained focus." Since you can't tell after the first message if a second message will occur, you don't know whether or not to send a "no items selected" message; and if you try and wait and there is no message, you won't get a chance to send it again.

Took a lot of evil state tricks, but I got it working. That'll make the input config, cheat editor and advanced panel buttons gray out when nothing in the list is selected. Please let me know if you spot any oddities with that.

That ate up nearly all of my time ... with only an hour left, I fixed the input mapping once a cart was loaded; but I didn't have time to fix the Windows joypad axis mapping bug, which should be the only bug left at this point.
Your website got foobared somehow, I can't navigate to places.
I knew what it was before even looking, based on your description. Derrick's host turned off PHP register globals. Apparently we can't have nice things because a few dumb fucks can't remember to initialize variables. Whatever, it's fixed now.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote:Easy enough, but then if you switch from item #3 to item #4, it sends "item 3 lost focus", followed by "item 4 gained focus." Since you can't tell after the first message if a second message will occur, you don't know whether or not to send a "no items selected" message; and if you try and wait and there is no message, you won't get a chance to send it again.

Took a lot of evil state tricks, but I got it working.
I'm curious how you solved this; where should I look for it? Also, would having no items selected for a fraction of a second really be that much of a problem?

Edit: nevermind, found it :) Yay for sort by last modified? Also the big comment
ShadowFX
Regular
Posts: 265
Joined: Thu Jul 29, 2004 8:55 am
Location: The Netherlands

Post by ShadowFX »

Is it possible to add Verdauga Greeneyes's Video 'Stretch' option into the new bsnes? That would be totally appreciated. I'll wait it out until it can, if not.
[i]"Change is inevitable; progress is optional"[/i]
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

Did we settle on the best behavior for that? I can't remember.
Edit: dug around a bit, found my build. Here's the suggested change to the code: (in event.cpp, update_video_settings() )

Code: Select all

  switch(video_settings.mode) { default:
    case 0: { //windowed
      window_main.unfullscreen();
      //try and clamp windows larger than the screen to the screen size.
      //note that since APIs such as X11 lack the ability to get the full window size
      //(with border, etc), this can never be a perfect fit to the screen.
      int view_width  = hiro().screen_width();
      int view_height = hiro().screen_height();
      if(width > view_width || height > view_height){
        double ratio = max((double)width  / (double)view_width,
                           (double)height / (double)view_height);
        width  = width  / ratio + 0.5;
        height = height / ratio + 0.5;
      }
      window_main.resize(width, height);
      window_main.move(window_main.view, 0, 0);
      window_main.view.resize(width, height);
    } break;

    case 1: { //fullscreen
      window_main.fullscreen();
      int view_width  = window_main.get_width();
      int view_height = window_main.get_height();
      if(width > view_width || height > view_height){
        double ratio = max((double)width  / (double)view_width,
                           (double)height / (double)view_height);
        width  = width  / ratio + 0.5;
        height = height / ratio + 0.5;
      }
      window_main.move(window_main.view,
        //center view inside window
        (view_width  - width)  / 2,
        (view_height - height) / 2
      );
      window_main.view.resize(width, height);
    } break;
  }
(note I don't have the opportunity to test the code at the moment.. the old code worked, and this should be the same thing, but a bug may have crept in there somehow)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

I really have no idea what that code is trying to do, but an easy way to fix the problem is to create advanced entries where a user can define maximum scale width and heights. Then when bsnes performs a scale that exceeds this resolution, it knows how to restrain the aspect ratio correction to compensate for the fact that no full integer scale actually took place.

For example, let's say the desktop res is 1680x1050 and bsnes is on NTSC mode with aspect correction enabled. A 4x scale results in black bars on the top and bottom, 77px a piece. A 5x scale (on windows) goes beyond 1050. So instead of doing that, it stops it at 1050. That's a non-integer scale of 4.6875x taking place on the vertical resolution. But the horizontal had no limit, so it stretches to 5x. Aspect ratio screwed.

Now, if bsnes knew what the limit was per a user definition, it could predetermine that 4.6875x should be the maximum scale on both vertical and horizontal parts of the image, thus preserving the aspect ratio for users who want to eliminate vertical bars.

It might be possible on windows to detect and obtain these values automatically for the user at first start-up. You'd probably need to enter them yourself on Linux. That was the problem that prevented byuu for doing anything last time this behavior was requested.

And in case this part isn't perfectly clear, there should be NO special scale option added to the menu. This should be default behavior for any scale that exceeds desktop resolution. If someone wants to deviate from the aspect ratio, they can STILL do that via the AR settings.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

FitzRoy wrote:I really have no idea what that code is trying to do
It works the same way as my test build whenever the maximum window (windowed) or the screen resolution (fullscreen) is exceeded: it stretches the image so that it touches the inside of the window/screen without effecting the ratio. Also, this code is maybe half a dozen lines longer than what's in bsnes now :) (I just posted the whole switch/case because it would be a pain to describe)
byuu

Post by byuu »

Hoorah, MOTHER 3 is out. You might recognize the patcher style -- it uses hiro and nall::ups :)
(Along with xkas for the actual patch itself, hee.)
(Save 100% of praise and credit to Tomato and Jeffman, please. I spent 1/10,000th as much time as them on this.)

That means in a couple of months I'll probably be starting on FEoEZ. Still nothing really set in stone there.
I'm curious how you solved this; where should I look for it? Also, would having no items selected for a fraction of a second really be that much of a problem?
Hah, I wanted to elaborate, but figured I was boring everyone.
And that comment wasn't even nearly verbose enough.

Code: Select all

LPNMHDR nmhdr = (LPNMHDR)lparam;
LPNMLISTVIEW nmlistview = (LPNMLISTVIEW)lparam;

if(nmhdr->code == LVN_ITEMCHANGED && (nmlistview->uChanged & LVIF_STATE)) {
  if((nmlistview->uOldState & LVIS_FOCUSED) && !(nmlistview->uNewState & LVIS_FOCUSED)) {
    listbox.p.lostfocus = true;
  } else {
    if((!(nmlistview->uOldState & LVIS_SELECTED) && (nmlistview->uNewState & LVIS_SELECTED))
    || (listbox.p.lostfocus == false && listbox.get_selection() == -1)) {
      if(listbox.on_change) listbox.on_change(event_t(event_t::Change, listbox.get_selection(), &listbox));
    }
    listbox.p.lostfocus = false;
  }
}
First, note the difference between LVIS_SELECTED and LVIS_FOCUSED. The former means the item has the "blue" highlighted box thing. The latter means it has the dotted outline around the item, but it's not (always) actively highlighted (it can have either state or both set). I don't really see much point in the latter, but it comes in handy as you'll see below.

Basically, I watched all details of each message being sent.
A transition from no item selected to item #0 would send LVIS_SELECTED to item 0. Easiest case to handle, just test the old and new state to see if that's what changed.

A transition from 0 to no selection would send a cleared LVIS_SELECTED code. So at that point I can use listbox.get_selection(), which essentially scans the entire listbox to see if any items have LVIS_SELECTED. If not, I know to send a "nothing selected" message.

The tricky part was the 0->1 transition. First, it sends a lost LVIS_FOCUSED message to 0; then a lost LVIS_SELECTED message to 0; then a gained LVIS_FOCUSED | LVIS_SELECTED message to 1. This was tripping the above code trick to send the "nothing selected" message between the two transitions.

So I made it catch the focus removal message and set a "lock" flag, listbox.p.lostfocus ... so that the next message to remove the LVIS_SELECTED flag will not trigger a message.

Now let's say you have an item focused, but not selected; so you essentially have nothing selected; and then you click on another item. It will send a lost focus message to that old item, then the gained selection+focus to the new one. So to keep the above from blocking the message, and because a gained selection always results in a good message that a new item gained selection, I forcefully send the message in that case regardless of listbox.p.lostfocus.

In all cases, I clear the lostfocus lock on the very next message; just in case something goes screwy ... which it shouldn't, but yeah. It's really evil what I had to do here, I basically got it working through trial and error, so I'm seeding it to see if you guys spot any bugs that I missed.

The reason I had to do all that is because if I were to send a "nothing selected" message, followed by a "new item selected" each time the list entry changed, you'd see the buttons flicker to disabled and back really quick. Not very visually pleasing, and not consistent with the GTK+ port behavior.
Is it possible to add Verdauga Greeneyes's Video 'Stretch' option into the new bsnes? That would be totally appreciated. I'll wait it out until it can, if not.
I don't see what it does that my options don't. How about this, can someone post a screenshot of it in action? I'm guessing it's just giving a non-multiple height scalar to touch the bottom of the screen. I avoided that specifically because it makes things like the scanline filter look terrible, and 5x scale can fill a 1920x1200 monitor's height completely in PAL mode. And if you pick too big a scalar, it already does that non-multiple scale thing. Pics work better than words.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote:I don't see what it does that my options don't. How about this, can someone post a screenshot of it in action? I'm guessing it's just giving a non-multiple height scalar to touch the bottom of the screen. I avoided that specifically because it makes things like the scanline filter look terrible, and 5x scale can fill a 1920x1200 monitor's height completely in PAL mode. And if you pick too big a scalar, it already does that non-multiple scale thing. Pics work better than words.
I think the difference is that this way preserves the aspect ratio. But I'll see if I can get a screenshot of the difference.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: That means in a couple of months I'll probably be starting on FEoEZ. Still nothing really set in stone there.
That saddens me a little, not because I don't think you'd do a great job, but because there are far more people rom hacking than there are writing emulators or improving emulation.
I don't see what it does that my options don't. How about this, can someone post a screenshot of it in action? I'm guessing it's just giving a non-multiple height scalar to touch the bottom of the screen. I avoided that specifically because it makes things like the scanline filter look terrible, and 5x scale can fill a 1920x1200 monitor's height completely in PAL mode.
What we're suggesting doesn't affect anyone multiplying at or within their monitor's vertical resolution. Suppose you had a 1680x1050 monitor, you cannot perfectly fill that vertical resolution with any multiple of 224. Currently, you can use 4x to get 896 filled with 77px black bars, or 5x to get no black bars at the expense of non-integer scaling. Those are the two options, and there are plenty of people that hate the black bars MORE than the non-integer scaling. But the latter option currently fails to preserve the aspect ratio on widescreen monitors. At 5x on the above monitor, the image scales back vertically to achieve 1050 drawn lines, but the horizontal doesn't compensate, resulting in a displayed ratio wider than 4:3 even though aspect correction is enabled.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

Fitzroy put it well. Still, here is a comparison; current first, suggested second. Note the difference isn't very big here.. I figured I should leave some vertical bars to show the effect clearly, however if I'd used 5x instead the current method would have filled the screen. Screen resolution is 1440x900, but I scaled it down a bit for ease of comparison. As you may or may not be able to tell, the suggested method preserves the aspect ratio while the current method does not. If the menubar is hidden, the current method will be just as wide but fill the screen vertically, while the suggested method will get slightly wider and use as much of the screen as possible without distorting the image. (i.e. it will also fill the screen vertically)
Image
Image
Locked