bsnes/phoenix/qt/platform.cpp

48 lines
1.2 KiB
C++
Raw Normal View History

#include "platform.moc.hpp"
#include "platform.moc"
#include "utility.cpp"
#include "settings.cpp"
#include "desktop.cpp"
#include "monitor.cpp"
#include "keyboard.cpp"
#include "mouse.cpp"
#include "browser-window.cpp"
#include "message-window.cpp"
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
#include "font.cpp"
Update to v079 release. byuu says: This release includes Nintendo Super System DIP switch emulation and improved PPU rendering accuracy, among other things. Changelog: - added Nintendo Super System DIP switch emulation [requires XML setting maps] - emulated Super Game Boy $6001 VRAM offset selection port [ikari_01] - fixed randomness initialization of S-SMP port registers [fixes DBZ:Hyper Dimension and Ninja Warriors] - mosaic V-countdown caches BGOFS registers (fixes Super Turrican 2 effect) [reported by zal16] - non-mosaic BGOFS registers are always cached at H=60 (fixes NHL '94 and Super Mario World flickering) - fixed 2xSaI family of renderers on 64-bit systems - cleaned up SMP source code - phoenix: fixed a bug when closing bsnes while minimized Please note that the mosaic BGOFS fix is only for the accuracy profile. Unfortunately the older scanline-based compatibility renderer's code is nearly unmaintainable at this point, so I haven't yet been able to backport the fixes. Also, I have written a new cycle-accurate SMP core that does not use libco. The aim is to implement it into Snes9X v1.54. But it would of course be prudent to test the new core first. [...then in the next post...] Decided to keep that Super Mario World part a surprise, so ... surprise! Realized while working on the Super Turrican 2 mosaic fix, and from looking at NHL '94 and Dai Kaijuu Monogatari 2's behavior, that BGOFS registers must be cached between H=0 and H=88 for the entire scanline ... they can't work otherwise, and it'd be stupid for the PPU to re-add the offset to the position on every pixel anyway. I chose H=60 for now. Once I am set up with the RGB monitor and the North American cartridge dumping is completed, I'll set it on getting exact timings for all these things. It'll probably require a smallish speed hit to allow exact-cycle timing events for everything in the PPU.
2011-06-05 03:45:04 +00:00
#include "timer.cpp"
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
#include "window.cpp"
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
#include "action/action.cpp"
#include "action/menu.cpp"
#include "action/separator.cpp"
#include "action/item.cpp"
#include "action/check-item.cpp"
#include "action/radio-item.cpp"
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
#include "widget/widget.cpp"
#include "widget/button.cpp"
#include "widget/canvas.cpp"
#include "widget/check-button.cpp"
#include "widget/check-label.cpp"
#include "widget/combo-button.cpp"
#include "widget/console.cpp"
#include "widget/frame.cpp"
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
#include "widget/hex-edit.cpp"
#include "widget/horizontal-scroller.cpp"
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
#include "widget/horizontal-slider.cpp"
#include "widget/label.cpp"
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
#include "widget/line-edit.cpp"
#include "widget/list-view.cpp"
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
#include "widget/progress-bar.cpp"
#include "widget/radio-button.cpp"
#include "widget/radio-label.cpp"
#include "widget/tab-frame.cpp"
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
#include "widget/text-edit.cpp"
#include "widget/vertical-scroller.cpp"
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
#include "widget/vertical-slider.cpp"
#include "widget/viewport.cpp"
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
#include "application.cpp"