bsnes v0.038 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

blargg wrote:
blargg wrote:The question for the SNES is what gamma it applies when encoding composite and s-video outputs (and perhaps RGB). If it uses none, then proper conversion to the linear RGB values of the light leaving the display's surface requires applying a 2.5 gamma. If the SNES uses 0.5, then conversion requires applying a 1.25 gamma.
After an informal test of displaying a gray ramp, it looks as though the SNES encodes the video signal linearly, thus resulting in a gamma applied to the raw RGB values by the display. So SNES images in an emulator should look more or less correct on a PC without the emulator doing any gamma correction. In retrospect, this is the only approach that makes sense. Like with the PC, you want the RGB values in the framebuffer to have gamma applied by the display device.
3. SNES applies no gamma when encoding video. So we need to apply a 2.5*0.45 = 1.125 gamma.
This one.
I still don't really understand this gamma business. Say I wanted to make a program that displays the full range of colours in a gradient. The intuitive way to do this would be to use some constant delta between subsequent colours - this would give you Linear RGB, right?

Now say I wanted to display this using Direct3D, would I need to use the D3DPRESENT_LINEAR_CONTENT flag in the presentation parameters to get it to display correctly? (as opposed to the case of say, displaying a picture taken with a digital camera)

Now say I was to make a sprite in MS paint. My monitor is calibrated to use a gamma of 2.2, which would then be applied to the linear RGB values used in my image and influence my choice of colours. I save the image as a BMP and display it in my game, which uses Direct3D. Would I need to use the D3DPRESENT_LINEAR_CONTENT flag to get it to display the same way it did in paint? After all, the colour values I used were linear. Or am I misunderstanding this flag altogether?

Edit: information on the flag can be found here.
Last edited by Verdauga Greeneyes on Wed Jan 14, 2009 7:38 pm, edited 1 time in total.
byuu

Post by byuu »

deltaphc wrote:With the March release of Qt 4.5 comes the LGPL. Rather unexpected, but there you go. :P

Obviously I'm not expecting all this existing UI work in bsnes to be dropped all of a sudden, because it's more or less working fine. But this makes Qt that much more reasonable for consideration.
Actually, this may very well be a good idea. I've always maintained that Qt looked more promising, but its licensing was a non-starter.

Win32 is obviously non-portable, and GTK+ has serious integration problems on Windows and OS X (it stands out like a sore thumb.) Having to cater to the largest userbase with Win32 anyway resulted in hiro, which brings both APIs to their lowest common denominator: no auto-resizing windows, no superclassing textboxes for an in-place memory editor, bad icon support, etc.

If I can avoid the Q preprocessor / Makefile generator (bsnes' Makefile is too complex for qmake's markup), then we could have a real winner here.

Readme / License could be rendered using an embedded HTML widget, dynamic app locales could be possible, OS X support should become trivial, hiro could be eliminated, I could possibly even bypass needing to manually multi-thread the Win32 UI (even though it shouldn't be too hard). Cross-platform font issues would be solved. The lower-level control access means I may be able to bring back the debugger.

We could start getting fancy, too: listboxes with checkboxes in them, icons in the menus and lists, etc.

Something we should definitely consider for v040.

-------------------------------

Don't suppose any Qt whizzes can lend a quick hand?

Code: Select all

#include <QApplication>
#include <QColor>
#include <QHBoxLayout>
#include <QLabel>
#include <QLineEdit>
#include <QPalette>
#include <QPushButton>
#include <QWidget>

int main(int argc, char **argv) {
  QApplication app(argc, argv);

  QWidget window;
  window.resize(256, 244);

  QWidget canvas(&window);
  QPalette cpal;
  cpal.setColor(canvas.backgroundRole(), QColor::fromRgb(0, 0, 0));
  canvas.resize(256, 224);
  canvas.setPalette(cpal);
  canvas.setGeometry(0, 0, 256, 224);

  QPushButton exit("Exit", &window);
  exit.setGeometry(0, 224, 256, 20);
  QObject::connect(&exit, SIGNAL(clicked()), &app, SLOT(quit()));

  window.show();

  return app.exec();
}
For some reason, the canvas widget isn't showing up. I sincerely hope we can nest QWidgets inside other QWidgets :/

Also, how would I get the HWND (Windows) / Window (Xorg) handle from a QWidget? Want to try binding it to DirectDraw.

----------

EDIT: seems it was showing the canvas, just ignoring my background "palette" thing. I guess widget.setBackgroundColor() was too easy. winId() gets me the HWND, and processEvents() lets me run DD whilst processing window messages.

Biggest problem now is that the compiler goes crazy when I try and add my own slots with Q_OBJECT. I really hope this isn't the part I need to chain a pre-compiler to. qmake didn't set any of that up, don't even know where to begin. Plus I really don't want to chain their pre-compiler just to implement callbacks :/

I'm also really not fond of all the win/mac/X11 functions and flags. I know it's really hard to avoid due to design differences, but it'll pollute my code with lots of #ifdefs that I don't want. That was one of the main advantages of hiro ... absolutely no function / style was platform-specific.
deltaphc
New Member
Posts: 9
Joined: Mon Feb 25, 2008 5:21 am

Post by deltaphc »

Yeah, that's the thing with the Qt framework. A few custom steps in compilation if you want to do a serious GUI app.

When using the Q_OBJECT macro, I think you either have to use qmake or use the meta-object compiler (moc) by itself. Unfortunately, I don't know the nitty-gritty details behind that; I've barely started Qt programming myself. :S

The above is certainly a disadvantage, but if the benefits outweigh it, could it be worth it? Once you get past these initial steps, Qt can be fairly nice to work with.

As for DDraw and such: There's *probably* a way to do it, but a more cross-platform way would be to take advantage of QPainter, Qt's paint engine. I hear it's pretty quick. OpenGL integration is nice as well with QGLWidget.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: We could start getting fancy, too: listboxes with checkboxes in them, icons in the menus and lists, etc.
I think icon art next to menu items is tacky and distracting no matter what. The one place they might look okay is in the config list, similar to what snesgt does, but art is difficult and I wouldn't even know to graphically represent stuff like drivers and cheat codes. In fact, that's why you only see icons for obvious actions and objects in toolbars.

Qt looks interesting, sinamas uses it for gambatte. I don't really have any problems with hiro, except for some minor things like the lack of checkboxes and sorting in the cheat area, and text not being vertically centered in listboxes.

By the way, is there a reason you don't use the program icon for the key capture window?
byuu

Post by byuu »

When using the Q_OBJECT macro, I think you either have to use qmake or use the meta-object compiler (moc) by itself.
moc seems to work.

Code: Select all

//test.hpp
class MyWidget : public QWidget { Q_OBJECT
public slots:
  void customSlot();
};

::moc test.hpp -o test.moc

//test.cpp
#include "test.moc"  //test.moc #includes test.hpp for us

void MyWidget::customSlot() {
}

int main(...) {
  ...
  QObject::connect(&button, SIGNAL(clicked()), &mywidget, SLOT(customSlot()));
  ...
}
I'll set up an implicit makefile rule to run this on all ui/qt_*.hpp files or something, easy enough I guess.

I'm really not a fan of this signal / slot business. Especially the way it just silently falls back to doing nothing when you screw up and use the wrong signal / slot name. Though I'm sure some people love it and all the garbage .moc files it spits out everywhere.

Even with bsnes I've never had a need for more than functors. This seems to be adding super power toys for no other reason than because they can. But that's just me.

A bunch of poser libraries. GTK+ is a C library pretending to be C++, and Qt is apparently a C++ library pretending to be Objective C. What does Cocoa act like? Fortran?
As for DDraw and such: There's *probably* a way to do it, but a more cross-platform way would be to take advantage of QPainter, Qt's paint engine.
I got it working fine. window.winId() gives me the handle I need to take over with DirectDraw. Now I just need to make a menubar and make sure Qt doesn't block upon entering it.

QPainter probably won't have linear or point scaling as an option, and that may not be hardware accelerated. If it's both, I guess I'll be happy to use it but I'd be really surprised if that worked on the Linux port without requiring OpenGL.

----------------------------------

Hmm, well that was a pain. Had to make a QVBoxLayout to attach a menu, since regular QWidget windows won't let you do that directly. QMainWindow seems to be able to, I guess that's how you handle the main app menubar for OS X support.

Menus aren't too bad, at least. Probably going to be fun finding ways to manipulate these menu items as QAction pointers. A real lack of consistency here ... the menu items should be full fledged objects, eg QMenuItem, with its own associated functions that binds to a parent QMenuGroup via constructor or setParent / attach or whatever.

But I have to accept that short of NIH, I have to put up with what I perceive to be bad design choices. Sigh. Good news is that the menubar isn't modal.

I am a fan of the BoxLayout setMargin / setSpacing stuff. That should save me a lot of annoying hard-coded offsets, and also allow auto-resizing. That part is very welcome.

------------------------------------------------

To distribute a bsnes/Qt binary via LGPL, I'd have to dynamically link. Even using upx -9 on all the Qt / run-time DLLs, we're talking ~4MB (qtcore4, qtgui4, ...). And no more direct EXE, it'd have to be a ZIP or self-installer.

Advantages:
- avoid threading issues and get a non-modal menubar for Windows
- Linux/KDE users will like the new UI
- OS X users will be able to compile and use the app
- one API target, no wrapper library; lets me use more advanced controls

Disadvantages:
- much larger distribution on Windows (350kb -> 4.5mb)
- Linux/GNOME and Xfce users will hate the new UI
- have to re-write the UI again
- gives a free advantage of ~2-3MB off file size to GPL apps.

Code: Select all

qtcore4.dll:
uncompressed       1960960
upx -9              808448
upx --ultra-brute   732672

qtgui4.dll:
uncompressed       6908416
upx -9             2987520
upx --ultra-brute  2720768

Total size = 3,453,440 bytes
+ ZIP max compression = 2,731,905 bytes
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

OSX is relatively meaningless. I'd say keep hiro, but consider maintaining slightly different modifications per OS to fix the Windows port's icon and text bugs.
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

it looks promising and has some great advantages. I don't think the filesize is going to kill the end user that much, but it might strain your bandwidth if you suddenly get popular.

I'd say the advantages outweigh the disadvantages.
Last edited by Panzer88 on Sat Jan 17, 2009 10:17 am, edited 1 time in total.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
Thristian
Hazed
Posts: 76
Joined: Tue Feb 07, 2006 11:02 am

Post by Thristian »

byuu wrote:A bunch of poser libraries. GTK+ is a C library pretending to be C++, and Qt is apparently a C++ library pretending to be Objective C. What does Cocoa act like? Fortran?
It seems to me that GUI implementation is a specialised domain that really needs high-level dynamic language features to be non-painful. You'll notice that a lot of GUI APIs are either written for highly dynamic languages (Tk for Tcl, Cocoa for Objective-C) or are written with wrappers and boiler-plate so heavy the original language is nearly unrecognisable (GObject for GTK, moc for Qt)

I'm not sure if C#/.NET counts as an API for a highly-dynamic language (C#'s delegate system is basically custom-designed for GUI stuff) or an extremely heavy wrapper for the C-based Win32 API.
Disadvantages:
- Linux/GNOME and Xfce users will hate the new UI
It seems that Qt 4.5 will include a native-integration theme, so Qt apps should inherit your GTK+ appearance settings and look reasonably native. I haven't tried it myself, but Firefox is a good example of how closely a non-GTK+ app can fit in - I expect Qt-based bsnes would work just as well.
Locked