bsnes/bsnes/phoenix/qt/qt.moc.hpp

453 lines
10 KiB
C++
Raw Normal View History

Update to v075r11 release. byuu says: Rewrote the way menus are attached, they act like layouts/widgets now. All three phoenix targets once again work with both radio menu items and radio widgets. Both GTK+ and Qt have built-in group controls right inside the widgets, so I don't have to keep my own groups around anymore. They do act screwy at widget creation though, have to jump through some hoops to get it to work right. All I can say is, definitely set all child widgets to the parent before trying to check any of them. My long-term goal for the main window is to honor the fullscreen video setting as a generic setting, and let the window scale auto-fit the best possible size that matches your scale preference into the output window, centered just like fullscreen. For now, I've just set it to a fixed window size until I finish working on phoenix. The scale X settings will just be to snap the window to an exact size in case you don't want any black borders, they won't be radio items and the bsnes-geometry.cfg file will save width/height information as well. Simplified the sizing requirements for creating layouts and updated all bsnes windows to support the new system. Layouts also expose their minimum width/height values, which I use to create perfectly sized windows on all three platforms. This will fix cut-off heights on the last Windows WIP. Qt is being annoying though and forcing a minimum window size of 300,100 despite me telling it to use a smaller window size. Always have to fight with Qt, I swear to god.
2011-02-10 10:08:12 +00:00
struct Settings : public configuration {
unsigned frameGeometryX;
unsigned frameGeometryY;
unsigned frameGeometryWidth;
unsigned frameGeometryHeight;
void load();
void save();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
Settings();
Update to v075r11 release. byuu says: Rewrote the way menus are attached, they act like layouts/widgets now. All three phoenix targets once again work with both radio menu items and radio widgets. Both GTK+ and Qt have built-in group controls right inside the widgets, so I don't have to keep my own groups around anymore. They do act screwy at widget creation though, have to jump through some hoops to get it to work right. All I can say is, definitely set all child widgets to the parent before trying to check any of them. My long-term goal for the main window is to honor the fullscreen video setting as a generic setting, and let the window scale auto-fit the best possible size that matches your scale preference into the output window, centered just like fullscreen. For now, I've just set it to a fixed window size until I finish working on phoenix. The scale X settings will just be to snap the window to an exact size in case you don't want any black borders, they won't be radio items and the bsnes-geometry.cfg file will save width/height information as well. Simplified the sizing requirements for creating layouts and updated all bsnes windows to support the new system. Layouts also expose their minimum width/height values, which I use to create perfectly sized windows on all three platforms. This will fix cut-off heights on the last Windows WIP. Qt is being annoying though and forcing a minimum window size of 300,100 despite me telling it to use a smaller window size. Always have to fight with Qt, I swear to god.
2011-02-10 10:08:12 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pFont;
struct pWindow;
struct pMenu;
struct pLayout;
struct pWidget;
struct pObject {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
bool locked;
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
pObject() {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
locked = false;
}
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pOS : public pObject {
static QApplication *application;
static Font defaultFont;
static Geometry availableGeometry();
static Geometry desktopGeometry();
static string fileLoad(Window &parent, const string &path, const lstring &filter);
static string fileSave(Window &parent, const string &path, const lstring &filter);
static string folderSelect(Window &parent, const string &path);
static void main();
static bool pendingEvents();
static void processEvents();
static void quit();
static void initialize();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pFont : public pObject {
Font &font;
QFont *qtFont;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry geometry(const string &text);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setBold(bool bold);
void setFamily(const string &family);
void setItalic(bool italic);
void setSize(unsigned size);
void setUnderline(bool underline);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pFont(Font &font) : font(font) {}
void constructor();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void update();
};
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pMessageWindow : public pObject {
static MessageWindow::Response information(Window &parent, const string &text, MessageWindow::Buttons buttons);
static MessageWindow::Response question(Window &parent, const string &text, MessageWindow::Buttons buttons);
static MessageWindow::Response warning(Window &parent, const string &text, MessageWindow::Buttons buttons);
static MessageWindow::Response critical(Window &parent, const string &text, MessageWindow::Buttons buttons);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pWindow : public QObject, public pObject {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
Window &window;
struct QtWindow : public QWidget {
pWindow &self;
void closeEvent(QCloseEvent*);
void moveEvent(QMoveEvent*);
void resizeEvent(QResizeEvent*);
QSize sizeHint() const;
QtWindow(pWindow &self) : self(self) {}
} *qtWindow;
QVBoxLayout *qtLayout;
QMenuBar *qtMenu;
QStatusBar *qtStatus;
QWidget *qtContainer;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
void append(Layout &layout);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void append(Menu &menu);
void append(Widget &widget);
Geometry frameMargin();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
bool focused();
Geometry geometry();
void setBackgroundColor(uint8_t red, uint8_t green, uint8_t blue);
void setFocused();
void setFullScreen(bool fullScreen);
void setGeometry(const Geometry &geometry);
void setMenuFont(Font &font);
void setMenuVisible(bool visible);
void setResizable(bool resizable);
void setStatusFont(Font &font);
void setStatusText(const string &text);
void setStatusVisible(bool visible);
void setTitle(const string &text);
void setVisible(bool visible);
void setWidgetFont(Font &font);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
pWindow(Window &window) : window(window) {}
void constructor();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void updateFrameGeometry();
};
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pAction : public pObject {
Action &action;
void setEnabled(bool enabled);
void setFont(Font &font);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setVisible(bool visible);
pAction(Action &action) : action(action) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pMenu : public pAction {
Menu &menu;
QMenu *qtMenu;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void append(Action &action);
void setFont(Font &font);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setText(const string &text);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pMenu(Menu &menu) : pAction(menu), menu(menu) {}
void constructor();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
};
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
struct pSeparator : public pAction {
Separator &separator;
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
QAction *qtAction;
pSeparator(Separator &separator) : pAction(separator), separator(separator) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
struct pItem : public QObject, public pAction {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Item &item;
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
QAction *qtAction;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setText(const string &text);
pItem(Item &item) : pAction(item), item(item) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onTick();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
struct pCheckItem : public QObject, public pAction {
Update to v075r08 release. byuu says: Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.) Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate. Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that. All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like. This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-07 09:15:43 +00:00
Q_OBJECT
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public:
CheckItem &checkItem;
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
QAction *qtAction;
Update to v075r08 release. byuu says: Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.) Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate. Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that. All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like. This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-07 09:15:43 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
bool checked();
void setChecked(bool checked);
void setText(const string &text);
Update to v075r08 release. byuu says: Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.) Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate. Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that. All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like. This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-07 09:15:43 +00:00
pCheckItem(CheckItem &checkItem) : pAction(checkItem), checkItem(checkItem) {}
void constructor();
Update to v075r08 release. byuu says: Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.) Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate. Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that. All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like. This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-07 09:15:43 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public slots:
void onTick();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
struct pRadioItem : public QObject, public pAction {
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
Q_OBJECT
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public:
RadioItem &radioItem;
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
QAction *qtAction;
QActionGroup *qtGroup;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
bool checked();
void setChecked();
void setGroup(const reference_array<RadioItem&> &group);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setText(const string &text);
Update to v075r08 release. byuu says: Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.) Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate. Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that. All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like. This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-07 09:15:43 +00:00
pRadioItem(RadioItem &radioItem) : pAction(radioItem), radioItem(radioItem) {}
void constructor();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public slots:
void onTick();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pWidget : public pObject {
Widget &widget;
QWidget *qtWidget;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Font& font();
virtual Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setEnabled(bool enabled);
void setFocused();
void setFont(Font &font);
void setGeometry(const Geometry &geometry);
void setVisible(bool visible);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pWidget(Widget &widget) : widget(widget) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pButton : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
Button &button;
QPushButton *qtButton;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setText(const string &text);
pButton(Button &button) : pWidget(button), button(button) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onTick();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pCheckBox : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
CheckBox &checkBox;
QCheckBox *qtCheckBox;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
bool checked();
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setChecked(bool checked);
void setText(const string &text);
pCheckBox(CheckBox &checkBox) : pWidget(checkBox), checkBox(checkBox) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onTick();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pComboBox : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
ComboBox &comboBox;
QComboBox *qtComboBox;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void append(const string &text);
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void reset();
unsigned selection();
void setSelection(unsigned row);
pComboBox(ComboBox &comboBox) : pWidget(comboBox), comboBox(comboBox) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onChange();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pHexEdit : public QObject, public pWidget {
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
HexEdit &hexEdit;
struct QtHexEdit : public QTextEdit {
pHexEdit &self;
void keyPressEvent(QKeyEvent*);
void keyPressEventAcknowledge(QKeyEvent*);
QtHexEdit(pHexEdit &self) : self(self) {}
} *qtHexEdit;
QHBoxLayout *qtLayout;
QScrollBar *qtScroll;
void setColumns(unsigned columns);
void setLength(unsigned length);
void setOffset(unsigned offset);
void setRows(unsigned rows);
void update();
pHexEdit(HexEdit &hexEdit) : pWidget(hexEdit), hexEdit(hexEdit) {}
void constructor();
void keyPressEvent(QKeyEvent*);
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onScroll();
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pHorizontalSlider : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
HorizontalSlider &horizontalSlider;
QSlider *qtSlider;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
unsigned position();
void setLength(unsigned length);
void setPosition(unsigned position);
pHorizontalSlider(HorizontalSlider &horizontalSlider) : pWidget(horizontalSlider), horizontalSlider(horizontalSlider) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onChange();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pLabel : public pWidget {
Label &label;
QLabel *qtLabel;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setText(const string &text);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pLabel(Label &label) : pWidget(label), label(label) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pLineEdit : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
LineEdit &lineEdit;
QLineEdit *qtLineEdit;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setEditable(bool editable);
void setText(const string &text);
string text();
pLineEdit(LineEdit &lineEdit) : pWidget(lineEdit), lineEdit(lineEdit) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onActivate();
void onChange();
};
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
struct pListView : public QObject, public pWidget {
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
Q_OBJECT
Update to v070r08 release. byuu says: - all three ports of phoenix gain the ability to use ListBox::setCheckable(), checked(row), setChecked(row, checked = true); - cheat editor updated to take advantage of this Some fun differences between the implementations. Windows was the least flexible, it only lets you have a check at the start of each item. Luckily that's all I need for my purposes so it'll work. It's also a lot easier, as now I don't need a ton of extra code to try and set per-column checkboxes. Now both Windows and Qt can put text into the first item with the checkbox, but GTK+ cannot. Further, Qt needs this because even if you hide the checkbox column, it still tries to search for typed text from the checkbox column. GTK+ does this too, but unlike GTK+, Qt lacks an API call to set the search column. Since my code basically has to change this in real-time since you have to call the setProperty functions after create(), this means I always set up the checkbox columns regardless of whether or not they are used. For Qt, I had to work around this and it'll be an annoying edge case if you try and use setCheckable(true) and then setCheckable(false), because Qt has no way to clear the checkboxes from an item once you've enabled them for the first time. But without doing it this way, there's no way for eg the ROM file loader to allow type-searching, so that's the way I do it. Windows works the same, and GTK+ has a separate column (hidden from the phoenix API standpoint) for the checkboxes, with no column header label text. All in all, a major hassle, but it was the only really major GUI hit from leaving Qt, aside from the horror that's going to be the debugger, which needs all kinds of highly specialized controls.
2010-10-04 05:33:49 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public:
ListView &listView;
QTreeWidget *qtListView;
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void append(const lstring &text);
void autoSizeColumns();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
bool checked(unsigned row);
void modify(unsigned row, const lstring &text);
void reset();
bool selected();
unsigned selection();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setCheckable(bool checkable);
void setChecked(unsigned row, bool checked);
void setHeaderText(const lstring &text);
void setHeaderVisible(bool visible);
void setSelected(bool selected);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setSelection(unsigned row);
pListView(ListView &listView) : pWidget(listView), listView(listView) {}
void constructor();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public slots:
void onActivate();
void onChange();
void onTick(QTreeWidgetItem *item);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pProgressBar : public pWidget {
ProgressBar &progressBar;
QProgressBar *qtProgressBar;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setPosition(unsigned position);
pProgressBar(ProgressBar &progressBar) : pWidget(progressBar), progressBar(progressBar) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pRadioBox : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
RadioBox &radioBox;
QRadioButton *qtRadioBox;
QButtonGroup *qtGroup;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
bool checked();
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setChecked();
void setGroup(const reference_array<RadioBox&> &group);
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setText(const string &text);
pRadioBox(RadioBox &radioBox) : pWidget(radioBox), radioBox(radioBox) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
public slots:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void onTick();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pTextEdit : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
TextEdit &textEdit;
QTextEdit *qtTextEdit;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
void setCursorPosition(unsigned position);
void setEditable(bool editable);
void setText(const string &text);
void setWordWrap(bool wordWrap);
string text();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pTextEdit(TextEdit &textEdit) : pWidget(textEdit), textEdit(textEdit) {}
void constructor();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public slots:
void onChange();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pVerticalSlider : public QObject, public pWidget {
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Q_OBJECT
public:
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
VerticalSlider &verticalSlider;
QSlider *qtSlider;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Geometry minimumGeometry();
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
unsigned position();
void setLength(unsigned length);
void setPosition(unsigned position);
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pVerticalSlider(VerticalSlider &verticalSlider) : pWidget(verticalSlider), verticalSlider(verticalSlider) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
public slots:
void onChange();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
struct pViewport : public pWidget {
Viewport &viewport;
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
Update to v075r12 release. byuu says: phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: HorizontalSlider::HorizontalSlider() : state(*new State), base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-15 12:22:37 +00:00
uintptr_t handle();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
pViewport(Viewport &viewport) : pWidget(viewport), viewport(viewport) {}
void constructor();
Update to v068r18 release. byuu says: This WIP fixes the Mode7 repeat issue in the accuracy core. More importantly, it's the first build to include phoenix. There is a stub GUI that does basically nothing right now. It will give you a window, a command to close the emulator, and an FPS meter so you can tell how fast it is. To load a ROM, you have to drag the ROM on top of the binary. I don't know if it will work if the filename+path has spaces in it or not, so avoid that to be safe. [...] For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6 times. So just keep trying. I don't know what's up with that, I'd appreciate if someone here wanted to debug that for me though :D One really good bit of news, there was that old hiro bug where keyboard input would cause the main window to beep. I spied on the main event loop and, as suspected, the status bar was getting focus and rejecting key presses. What. The. Fuck. Why would a status bar ever need focus? So I set WM_DISABLED on it, which luckily leaves the font color alone. I also had to use WM_DISABLED on the Viewport widget that I use for video output. These two combined let me have my main window with no keyboard beeping AND allow tab+shift-tab to work as you'd expect on other windows, so hooray. Now, at the moment there's no Manifest included, because Microsoft for some reason includes the processorArcitecture in the file. So I can't use the same manifest for 32-bit and 64-bit mode, or the binary will crash on one or the other. Fuck. So the status bar may look old-school or something, whatever, it's only temporary. Next up, my goal is to avoid the hiro icon corruption bullshit by making phoenix itself try and use an internal resource icon. So just compile your app with that resource icon and voila, perfect icon. Not in there yet so you get the white box. Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return. Lastly, compilation is ... in a serious state of flux. The code is set to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me a few WIPs to get everything nice and refined. Ubuntu users will need gcc-4.5, which you can get by adding the Maverick Meerkat repository, updating apt, installing the gcc-4.5 + g++-4.5 packages, and then removing and re-updating your apt/sources.list file so you don't end up fucking your whole system when you run apt again in the future. For anyone who can work with all of that, great! Please post a framerate comparison between 32-bit and 64-bit builds. Any game, any screen, so long as the FPS is not fluctuating when you measure it (eg don't do it during an attract sequence.) If anyone complains about the 64-bit binary not working and it turns out they are on 32-bit Windows, they are going to be removed from this WIP forum :P
2010-10-20 11:47:14 +00:00
};