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) {
|
2015-08-24 09:42:11 +00:00
|
|
|
p->state().geometry.setPosition({geometry.x(), geometry.y()});
|
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(!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);
|
2016-05-02 09:57:04 +00:00
|
|
|
if(!paths) return;
|
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
|
|
|
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;
|
|
|
|
|
2015-08-24 09:42:11 +00:00
|
|
|
if(!p->state().fullScreen) {
|
|
|
|
p->state().geometry.setSize({allocation->width, allocation->height});
|
|
|
|
}
|
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& 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);
|
2016-05-16 09:51:12 +00:00
|
|
|
else if(_setIcon({Path::user(), ".local/share/icons/"}));
|
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 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) {
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
if(auto self = menuBar->self()) self->setEnabled(menuBar->enabled(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) {
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
if(auto self = statusBar->self()) self->setEnabled(statusBar->enabled(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& layout = state().layout) {
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
if(auto self = layout->self()) self->setEnabled(layout->enabled(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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setFocused() -> void {
|
|
|
|
gtk_window_present(GTK_WINDOW(widget));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setFullScreen(bool fullScreen) -> void {
|
2015-08-24 09:42:11 +00:00
|
|
|
if(fullScreen) {
|
|
|
|
windowedGeometry = state().geometry;
|
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_fullscreen(GTK_WINDOW(widget));
|
2015-08-24 09:42:11 +00:00
|
|
|
state().geometry = Monitor::geometry(Monitor::primary());
|
|
|
|
} else {
|
|
|
|
gtk_window_unfullscreen(GTK_WINDOW(widget));
|
|
|
|
state().geometry = windowedGeometry;
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
Update to v094r43 release.
byuu says:
Updated to compile with all of the new hiro changes. My next step is to
write up hiro API documentation, and move the API from alpha (constantly
changing) to beta (rarely changing), in preparation for the first stable
release (backward-compatible changes only.)
Added "--fullscreen" command-line option. I like this over
a configuration file option. Lets you use the emulator in both modes
without having to modify the config file each time.
Also enhanced the command-line game loading. You can now use any of
these methods:
higan /path/to/game-folder.sfc
higan /path/to/game-folder.sfc/
higan /path/to/game-folder.sfc/program.rom
The idea is to support launchers that insist on loading files only.
Technically, the file can be any name (manifest.bml also works); the
only criteria is that the file actually exists and is a file, and not
a directory. This is a requirement to support the first version (a
directory lacking the trailing / identifier), because I don't want my
nall::string class to query the file system to determine if the string
is an actual existing file or directory for its pathname() / dirname()
functions.
Anyway, every game folder I've made so far has program.rom, and that's
very unlikely to change, so this should be fine.
Now, of course, if you drop a regular "game.sfc" file on the emulator,
it won't even try to load it, unless it's in a folder that ends in .fc,
.sfc, etc. In which case, it'll bail out immediately by being unable to
produce a manifest for what is obviously not really a game folder.
2015-08-30 02:08:26 +00:00
|
|
|
auto pWindow::_setMenuFont(const Font& font) -> 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
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
Update to v094r43 release.
byuu says:
Updated to compile with all of the new hiro changes. My next step is to
write up hiro API documentation, and move the API from alpha (constantly
changing) to beta (rarely changing), in preparation for the first stable
release (backward-compatible changes only.)
Added "--fullscreen" command-line option. I like this over
a configuration file option. Lets you use the emulator in both modes
without having to modify the config file each time.
Also enhanced the command-line game loading. You can now use any of
these methods:
higan /path/to/game-folder.sfc
higan /path/to/game-folder.sfc/
higan /path/to/game-folder.sfc/program.rom
The idea is to support launchers that insist on loading files only.
Technically, the file can be any name (manifest.bml also works); the
only criteria is that the file actually exists and is a file, and not
a directory. This is a requirement to support the first version (a
directory lacking the trailing / identifier), because I don't want my
nall::string class to query the file system to determine if the string
is an actual existing file or directory for its pathname() / dirname()
functions.
Anyway, every game folder I've made so far has program.rom, and that's
very unlikely to change, so this should be fine.
Now, of course, if you drop a regular "game.sfc" file on the emulator,
it won't even try to load it, unless it's in a folder that ends in .fc,
.sfc, etc. In which case, it'll bail out immediately by being unable to
produce a manifest for what is obviously not really a game folder.
2015-08-30 02:08:26 +00:00
|
|
|
auto pWindow::_setStatusFont(const Font& font) -> 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
|
|
|
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
|