Update to v094r20 release.
byuu says:
Main reason for this WIP was because of all the added lines to hiro for
selective component disabling. May as well get all the diff-noise apart
from code changes.
It also merges something I've been talking to Cydrak about ... making
nall::string::(integer,decimal) do built-in binary,octal,hex decoding
instead of just failing on those. This will have fun little side effects
all over the place, like being able to view a topic on my forum via
"forum.byuu.org/topic/0b10010110", heh.
There are two small changes to higan itself, though. First up, I fixed
the resampler ratio when loading non-SNES games. Tested and I can play
Game Boy games fine now. Second, I hooked up menu option hiding for
reset and controller selection. Right now, this works like higan v094,
but I'm thinking I might want to show the "Device -> Controller" even if
that's all that's there. It kind of jives nicer with the input settings
window to see the labels there, I think. And if we ever do add more
stuff, it'll be nice that people already always expect that menu there.
Remaining issues:
* add slotted cart loader (SGB, BSX, ST)
* add DIP switch selection window (NSS)
* add timing configuration (video/audio sync)
2015-05-23 05:37:08 +00:00
|
|
|
#if defined(Hiro_Window)
|
|
|
|
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
namespace hiro {
|
|
|
|
|
|
|
|
static auto Window_close(GtkWidget* widget, GdkEvent* event, pWindow* p) -> signed {
|
|
|
|
if(p->state().onClose) {
|
|
|
|
p->self().doClose();
|
|
|
|
} else {
|
|
|
|
p->self().setVisible(false);
|
|
|
|
}
|
|
|
|
if(p->state().modal && !p->pObject::state().visible) p->self().setModal(false);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_expose(GtkWidget* widget, GdkEvent* event, pWindow* p) -> signed {
|
|
|
|
if(auto color = p->state().backgroundColor) {
|
|
|
|
cairo_t* context = gdk_cairo_create(widget->window);
|
|
|
|
|
|
|
|
double red = (double)color.red() / 255.0;
|
|
|
|
double green = (double)color.green() / 255.0;
|
|
|
|
double blue = (double)color.blue() / 255.0;
|
|
|
|
double alpha = (double)color.alpha() / 255.0;
|
|
|
|
|
|
|
|
if(gdk_screen_is_composited(gdk_screen_get_default())
|
|
|
|
&& gdk_screen_get_rgba_colormap(gdk_screen_get_default())
|
|
|
|
) {
|
|
|
|
cairo_set_source_rgba(context, red, green, blue, alpha);
|
|
|
|
} else {
|
|
|
|
cairo_set_source_rgb(context, red, green, blue);
|
|
|
|
}
|
|
|
|
|
|
|
|
cairo_set_operator(context, CAIRO_OPERATOR_SOURCE);
|
|
|
|
cairo_paint(context);
|
|
|
|
cairo_destroy(context);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_configure(GtkWidget* widget, GdkEvent* event, pWindow* p) -> signed {
|
|
|
|
if(!gtk_widget_get_realized(p->widget)) return false;
|
|
|
|
if(!p->pObject::state().visible) return false;
|
|
|
|
GdkWindow* gdkWindow = gtk_widget_get_window(widget);
|
|
|
|
|
|
|
|
GdkRectangle border, client;
|
|
|
|
gdk_window_get_frame_extents(gdkWindow, &border);
|
|
|
|
gdk_window_get_geometry(gdkWindow, nullptr, nullptr, &client.width, &client.height, nullptr);
|
|
|
|
gdk_window_get_origin(gdkWindow, &client.x, &client.y);
|
|
|
|
|
|
|
|
if(!p->state().fullScreen) {
|
|
|
|
//update geometry settings
|
|
|
|
settings->geometry.frameX = client.x - border.x;
|
|
|
|
settings->geometry.frameY = client.y - border.y;
|
|
|
|
settings->geometry.frameWidth = border.width - client.width;
|
|
|
|
settings->geometry.frameHeight = border.height - client.height;
|
|
|
|
settings->save();
|
|
|
|
}
|
|
|
|
|
|
|
|
Geometry geometry = {
|
|
|
|
client.x,
|
|
|
|
client.y + p->_menuHeight(),
|
|
|
|
client.width,
|
|
|
|
client.height - p->_menuHeight() - p->_statusHeight()
|
|
|
|
};
|
|
|
|
|
|
|
|
//move
|
|
|
|
if(geometry.x() != p->state().geometry.x() || geometry.y() != p->state().geometry.y()) {
|
|
|
|
if(!p->state().fullScreen) {
|
|
|
|
p->state().geometry.setX(geometry.x());
|
|
|
|
p->state().geometry.setY(geometry.y());
|
|
|
|
}
|
|
|
|
if(!p->locked()) p->self().doMove();
|
|
|
|
}
|
|
|
|
|
|
|
|
//size
|
|
|
|
if(geometry.width() != p->state().geometry.width() || geometry.height() != p->state().geometry.height()) {
|
|
|
|
p->onSizePending = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_drop(GtkWidget* widget, GdkDragContext* context, signed x, signed y,
|
|
|
|
GtkSelectionData* data, unsigned type, unsigned timestamp, pWindow* p) -> void {
|
|
|
|
if(!p->state().droppable) return;
|
|
|
|
lstring paths = DropPaths(data);
|
|
|
|
if(paths.empty()) return;
|
|
|
|
p->self().doDrop(paths);
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_keyPress(GtkWidget* widget, GdkEventKey* event, pWindow* p) -> signed {
|
|
|
|
if(auto key = pKeyboard::_translate(event->keyval)) {
|
|
|
|
p->self().doKeyPress(key);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_keyRelease(GtkWidget* widget, GdkEventKey* event, pWindow* p) -> signed {
|
|
|
|
if(auto key = pKeyboard::_translate(event->keyval)) {
|
|
|
|
p->self().doKeyRelease(key);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_sizeAllocate(GtkWidget* widget, GtkAllocation* allocation, pWindow* p) -> void {
|
|
|
|
//size-allocate sent from gtk_fixed_move(); detect if layout unchanged and return
|
|
|
|
if(allocation->width == p->lastAllocation.width
|
|
|
|
&& allocation->height == p->lastAllocation.height) return;
|
|
|
|
|
|
|
|
p->state().geometry.setWidth(allocation->width);
|
|
|
|
p->state().geometry.setHeight(allocation->height);
|
|
|
|
|
|
|
|
if(auto& layout = p->state().layout) {
|
|
|
|
layout->setGeometry(p->self().geometry().setPosition(0, 0));
|
|
|
|
}
|
|
|
|
|
|
|
|
if(!p->locked() && p->onSizePending) {
|
|
|
|
p->onSizePending = false;
|
|
|
|
p->self().doSize();
|
|
|
|
}
|
|
|
|
|
|
|
|
p->lastAllocation = *allocation;
|
|
|
|
}
|
|
|
|
|
|
|
|
static auto Window_sizeRequest(GtkWidget* widget, GtkRequisition* requisition, pWindow* p) -> void {
|
|
|
|
requisition->width = p->state().geometry.width();
|
|
|
|
requisition->height = p->state().geometry.height();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::construct() -> void {
|
|
|
|
lastAllocation.width = 0;
|
|
|
|
lastAllocation.height = 0;
|
|
|
|
onSizePending = false;
|
|
|
|
|
|
|
|
widget = gtk_window_new(GTK_WINDOW_TOPLEVEL);
|
|
|
|
gtk_window_set_resizable(GTK_WINDOW(widget), true);
|
|
|
|
|
|
|
|
//if program was given a name, try and set the window taskbar icon from one of the pixmaps folders
|
|
|
|
if(!Application::state.name);
|
|
|
|
else if(_setIcon({userpath(), ".local/share/icons/"}));
|
|
|
|
else if(_setIcon("/usr/local/share/pixmaps/"));
|
|
|
|
else if(_setIcon("/usr/share/pixmaps/"));
|
|
|
|
|
|
|
|
GdkColormap* colormap = gdk_screen_get_rgba_colormap(gdk_screen_get_default());
|
|
|
|
if(!colormap) colormap = gdk_screen_get_rgb_colormap(gdk_screen_get_default());
|
|
|
|
if(colormap) gtk_widget_set_colormap(widget, colormap);
|
|
|
|
|
|
|
|
gtk_widget_set_app_paintable(widget, true);
|
|
|
|
gtk_widget_add_events(widget, GDK_CONFIGURE);
|
|
|
|
|
|
|
|
menuContainer = gtk_vbox_new(false, 0);
|
|
|
|
gtk_container_add(GTK_CONTAINER(widget), menuContainer);
|
|
|
|
gtk_widget_show(menuContainer);
|
|
|
|
|
|
|
|
gtkMenu = gtk_menu_bar_new();
|
|
|
|
gtk_box_pack_start(GTK_BOX(menuContainer), gtkMenu, false, false, 0);
|
|
|
|
|
|
|
|
formContainer = gtk_fixed_new();
|
|
|
|
gtk_box_pack_start(GTK_BOX(menuContainer), formContainer, true, true, 0);
|
|
|
|
gtk_widget_show(formContainer);
|
|
|
|
|
|
|
|
statusContainer = gtk_event_box_new();
|
|
|
|
gtkStatus = gtk_statusbar_new();
|
|
|
|
gtk_statusbar_set_has_resize_grip(GTK_STATUSBAR(gtkStatus), true);
|
|
|
|
gtk_container_add(GTK_CONTAINER(statusContainer), gtkStatus);
|
|
|
|
gtk_box_pack_start(GTK_BOX(menuContainer), statusContainer, false, false, 0);
|
|
|
|
gtk_widget_show(statusContainer);
|
|
|
|
|
|
|
|
setBackgroundColor(state().backgroundColor);
|
|
|
|
setDroppable(state().droppable);
|
|
|
|
setGeometry(state().geometry);
|
|
|
|
setResizable(state().resizable);
|
|
|
|
setTitle(state().title);
|
|
|
|
|
|
|
|
g_signal_connect(G_OBJECT(widget), "delete-event", G_CALLBACK(Window_close), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(widget), "expose-event", G_CALLBACK(Window_expose), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(widget), "configure-event", G_CALLBACK(Window_configure), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(widget), "drag-data-received", G_CALLBACK(Window_drop), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(widget), "key-press-event", G_CALLBACK(Window_keyPress), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(widget), "key-release-event", G_CALLBACK(Window_keyRelease), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(formContainer), "size-allocate", G_CALLBACK(Window_sizeAllocate), (gpointer)this);
|
|
|
|
g_signal_connect(G_OBJECT(formContainer), "size-request", G_CALLBACK(Window_sizeRequest), (gpointer)this);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::destruct() -> void {
|
2015-06-25 09:52:32 +00:00
|
|
|
gtk_widget_destroy(widget);
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::append(sLayout layout) -> void {
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::append(sMenuBar menuBar) -> void {
|
2015-03-03 10:14:49 +00:00
|
|
|
_setMenuEnabled(menuBar->enabled(true));
|
|
|
|
_setMenuFont(menuBar->font(true));
|
|
|
|
_setMenuVisible(menuBar->visible(true));
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::append(sStatusBar statusBar) -> void {
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
_setStatusEnabled(statusBar->enabled(true));
|
|
|
|
_setStatusFont(statusBar->font(true));
|
|
|
|
_setStatusText(statusBar->text());
|
|
|
|
_setStatusVisible(statusBar->visible(true));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::focused() const -> bool {
|
|
|
|
return gtk_window_is_active(GTK_WINDOW(widget));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::frameMargin() const -> Geometry {
|
|
|
|
if(state().fullScreen) return {
|
|
|
|
0, _menuHeight(),
|
|
|
|
0, _menuHeight() + _statusHeight()
|
|
|
|
};
|
|
|
|
|
|
|
|
return {
|
|
|
|
settings->geometry.frameX,
|
|
|
|
settings->geometry.frameY + _menuHeight(),
|
|
|
|
settings->geometry.frameWidth,
|
|
|
|
settings->geometry.frameHeight + _menuHeight() + _statusHeight()
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::remove(sLayout layout) -> void {
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::remove(sMenuBar menuBar) -> void {
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
_setMenuVisible(false);
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::remove(sStatusBar statusBar) -> void {
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
_setStatusVisible(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setBackgroundColor(Color color) -> void {
|
|
|
|
GdkColor gdkColor = CreateColor(color);
|
|
|
|
gtk_widget_modify_bg(widget, GTK_STATE_NORMAL, color ? &gdkColor : nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setDroppable(bool droppable) -> void {
|
|
|
|
gtk_drag_dest_set(widget, GTK_DEST_DEFAULT_ALL, nullptr, 0, GDK_ACTION_COPY);
|
|
|
|
if(droppable) gtk_drag_dest_add_uri_targets(widget);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setEnabled(bool enabled) -> void {
|
|
|
|
if(auto& menuBar = state().menuBar) {
|
|
|
|
if(menuBar->self()) menuBar->self()->setEnabled(menuBar->enabled(true));
|
|
|
|
}
|
|
|
|
|
|
|
|
if(auto& statusBar = state().statusBar) {
|
|
|
|
if(statusBar->self()) statusBar->self()->setEnabled(statusBar->enabled(true));
|
|
|
|
}
|
|
|
|
|
|
|
|
if(auto& layout = state().layout) {
|
|
|
|
if(layout->self()) layout->self()->setEnabled(layout->enabled(true));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setFocused() -> void {
|
|
|
|
gtk_window_present(GTK_WINDOW(widget));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setFullScreen(bool fullScreen) -> void {
|
|
|
|
if(fullScreen == false) {
|
|
|
|
gtk_window_unfullscreen(GTK_WINDOW(widget));
|
|
|
|
} else {
|
|
|
|
gtk_window_fullscreen(GTK_WINDOW(widget));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setGeometry(Geometry geometry) -> void {
|
|
|
|
Geometry margin = frameMargin();
|
|
|
|
gtk_window_move(GTK_WINDOW(widget), geometry.x() - margin.x(), geometry.y() - margin.y());
|
|
|
|
|
|
|
|
GdkGeometry geom;
|
|
|
|
geom.min_width = state().resizable ? 1 : state().geometry.width();
|
|
|
|
geom.min_height = state().resizable ? 1 : state().geometry.height();
|
|
|
|
gtk_window_set_geometry_hints(GTK_WINDOW(widget), GTK_WIDGET(widget), &geom, GDK_HINT_MIN_SIZE);
|
|
|
|
|
|
|
|
gtk_widget_set_size_request(formContainer, geometry.width(), geometry.height());
|
|
|
|
gtk_window_resize(GTK_WINDOW(widget), geometry.width(), geometry.height() + _menuHeight() + _statusHeight());
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setModal(bool modal) -> void {
|
|
|
|
if(modal) {
|
|
|
|
gtk_window_set_modal(GTK_WINDOW(widget), true);
|
Update to v094r29 release.
byuu says:
Note: for Windows users, please go to nall/intrinsics.hpp line 60 and
correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before
compiling, otherwise things won't work at all.
This will be a really major WIP for the core SNES emulation, so please
test as thoroughly as possible.
I rewrote the 65816 CPU core's dispatcher from a jump table to a switch
table. This was so that I could pass class variables as parameters to
opcodes without crazy theatrics.
With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^=
stuff, and all of the template versions of opcodes.
I also removed some stupid pointless flag tests in xcn and pflag that
would always be true.
I sure hope that AWJ is happy with this; because this change was so that
my flag assignments and branch tests won't need to build regs.P into
a full 8-bit variable anymore.
It does of course incur a slight performance hit when you pass in
variables by-value to functions, but it should help with binary size
(and thus cache) by reducing a lot of extra functions. (I know I could
have used template parameters for some things even with a switch table,
but chose not to for the aforementioned reasons.)
Overall, it's about a ~1% speedup from the previous build. The CPU core
instructions were never a bottleneck, but I did want to fix the P flag
building stuff because that really was a dumb mistake v_v'
2015-06-22 13:31:49 +00:00
|
|
|
while(!Application::state.quit && state().modal) {
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(Application::state.onMain) {
|
|
|
|
Application::doMain();
|
|
|
|
} else {
|
|
|
|
usleep(20 * 1000);
|
|
|
|
}
|
Update to v094r29 release.
byuu says:
Note: for Windows users, please go to nall/intrinsics.hpp line 60 and
correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before
compiling, otherwise things won't work at all.
This will be a really major WIP for the core SNES emulation, so please
test as thoroughly as possible.
I rewrote the 65816 CPU core's dispatcher from a jump table to a switch
table. This was so that I could pass class variables as parameters to
opcodes without crazy theatrics.
With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^=
stuff, and all of the template versions of opcodes.
I also removed some stupid pointless flag tests in xcn and pflag that
would always be true.
I sure hope that AWJ is happy with this; because this change was so that
my flag assignments and branch tests won't need to build regs.P into
a full 8-bit variable anymore.
It does of course incur a slight performance hit when you pass in
variables by-value to functions, but it should help with binary size
(and thus cache) by reducing a lot of extra functions. (I know I could
have used template parameters for some things even with a switch table,
but chose not to for the aforementioned reasons.)
Overall, it's about a ~1% speedup from the previous build. The CPU core
instructions were never a bottleneck, but I did want to fix the P flag
building stuff because that really was a dumb mistake v_v'
2015-06-22 13:31:49 +00:00
|
|
|
Application::processEvents();
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
}
|
|
|
|
gtk_window_set_modal(GTK_WINDOW(widget), false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setResizable(bool resizable) -> void {
|
|
|
|
gtk_window_set_resizable(GTK_WINDOW(widget), resizable);
|
|
|
|
gtk_statusbar_set_has_resize_grip(GTK_STATUSBAR(gtkStatus), resizable);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setTitle(const string& title) -> void {
|
|
|
|
gtk_window_set_title(GTK_WINDOW(widget), title ? title : " ");
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setVisible(bool visible) -> void {
|
|
|
|
gtk_widget_set_visible(widget, visible);
|
|
|
|
|
|
|
|
if(auto& menuBar = state().menuBar) {
|
|
|
|
if(menuBar->self()) menuBar->self()->setVisible(menuBar->visible(true));
|
|
|
|
}
|
|
|
|
|
2015-03-03 10:14:49 +00:00
|
|
|
if(auto& layout = state().layout) {
|
|
|
|
if(layout->self()) layout->self()->setVisible(layout->visible(true));
|
|
|
|
}
|
|
|
|
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(auto& statusBar = state().statusBar) {
|
|
|
|
if(statusBar->self()) statusBar->self()->setVisible(statusBar->visible(true));
|
|
|
|
}
|
|
|
|
|
2015-03-03 10:14:49 +00:00
|
|
|
//GTK+ returns invalid widget sizes below without this call
|
|
|
|
Application::processEvents();
|
|
|
|
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(visible) {
|
|
|
|
if(gtk_widget_get_visible(gtkMenu)) {
|
|
|
|
GtkAllocation allocation;
|
|
|
|
gtk_widget_get_allocation(gtkMenu, &allocation);
|
|
|
|
settings->geometry.menuHeight = allocation.height;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(gtk_widget_get_visible(gtkStatus)) {
|
|
|
|
GtkAllocation allocation;
|
|
|
|
gtk_widget_get_allocation(gtkStatus, &allocation);
|
|
|
|
settings->geometry.statusHeight = allocation.height;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if(auto& layout = state().layout) {
|
|
|
|
layout->setGeometry(self().geometry().setPosition(0, 0));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_append(mWidget& widget) -> void {
|
|
|
|
if(!widget.self()) return;
|
|
|
|
if(auto parent = widget.parentWidget(true)) {
|
2015-03-02 09:13:28 +00:00
|
|
|
if(auto instance = parent->self()) widget.self()->gtkParent = instance->container(widget);
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
} else {
|
|
|
|
widget.self()->gtkParent = formContainer;
|
|
|
|
}
|
|
|
|
gtk_fixed_put(GTK_FIXED(widget.self()->gtkParent), widget.self()->gtkWidget, 0, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_append(mMenu& menu) -> void {
|
|
|
|
if(menu.self()) gtk_menu_shell_append(GTK_MENU_SHELL(gtkMenu), menu.self()->widget);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_menuHeight() const -> signed {
|
|
|
|
return gtk_widget_get_visible(gtkMenu) ? settings->geometry.menuHeight : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setIcon(const string& pathname) -> bool {
|
|
|
|
string filename;
|
|
|
|
|
|
|
|
filename = {pathname, Application::state.name, ".svg"};
|
|
|
|
if(file::exists(filename)) {
|
|
|
|
gtk_window_set_icon_from_file(GTK_WINDOW(widget), filename, nullptr);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
filename = {pathname, Application::state.name, ".png"};
|
|
|
|
if(file::exists(filename)) {
|
|
|
|
//maximum image size GTK+ supports is 256x256; scale image down if necessary to prevent error
|
2015-06-18 10:48:53 +00:00
|
|
|
image icon(filename);
|
|
|
|
icon.scale(min(256u, icon.width()), min(256u, icon.height()), true);
|
|
|
|
auto pixbuf = CreatePixbuf(icon);
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
gtk_window_set_icon(GTK_WINDOW(widget), pixbuf);
|
|
|
|
g_object_unref(G_OBJECT(pixbuf));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setMenuEnabled(bool enabled) -> void {
|
|
|
|
gtk_widget_set_sensitive(gtkMenu, enabled);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setMenuFont(const string& font) -> void {
|
|
|
|
pFont::setFont(gtkMenu, font);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setMenuVisible(bool visible) -> void {
|
|
|
|
gtk_widget_set_visible(gtkMenu, visible);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setStatusEnabled(bool enabled) -> void {
|
|
|
|
gtk_widget_set_sensitive(gtkStatus, enabled);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setStatusFont(const string& font) -> void {
|
|
|
|
pFont::setFont(gtkStatus, font);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setStatusText(const string& text) -> void {
|
|
|
|
gtk_statusbar_pop(GTK_STATUSBAR(gtkStatus), 1);
|
|
|
|
gtk_statusbar_push(GTK_STATUSBAR(gtkStatus), 1, text);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_setStatusVisible(bool visible) -> void {
|
|
|
|
gtk_widget_set_visible(gtkStatus, visible);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_statusHeight() const -> signed {
|
|
|
|
return gtk_widget_get_visible(gtkStatus) ? settings->geometry.statusHeight : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
Update to v094r20 release.
byuu says:
Main reason for this WIP was because of all the added lines to hiro for
selective component disabling. May as well get all the diff-noise apart
from code changes.
It also merges something I've been talking to Cydrak about ... making
nall::string::(integer,decimal) do built-in binary,octal,hex decoding
instead of just failing on those. This will have fun little side effects
all over the place, like being able to view a topic on my forum via
"forum.byuu.org/topic/0b10010110", heh.
There are two small changes to higan itself, though. First up, I fixed
the resampler ratio when loading non-SNES games. Tested and I can play
Game Boy games fine now. Second, I hooked up menu option hiding for
reset and controller selection. Right now, this works like higan v094,
but I'm thinking I might want to show the "Device -> Controller" even if
that's all that's there. It kind of jives nicer with the input settings
window to see the labels there, I think. And if we ever do add more
stuff, it'll be nice that people already always expect that menu there.
Remaining issues:
* add slotted cart loader (SGB, BSX, ST)
* add DIP switch selection window (NSS)
* add timing configuration (video/audio sync)
2015-05-23 05:37:08 +00:00
|
|
|
|
|
|
|
#endif
|