bsnes/higan/phoenix/qt/widget/progress-bar.cpp

31 lines
565 B
C++
Raw Normal View History

namespace phoenix {
Size pProgressBar::minimumSize() {
return {0, 25};
}
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 pProgressBar::setPosition(unsigned position) {
qtProgressBar->setValue(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
}
void pProgressBar::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
qtWidget = qtProgressBar = new QProgressBar;
qtProgressBar->setRange(0, 100);
qtProgressBar->setTextVisible(false);
Update to v082r18 release. byuu says: There we go, the GUI is nearly feature-complete once again. All cores now output their native video format (NES={emphasis}{palette}, SNES=BGR555, GameBoy={ bright, normal, darker, darkest }), and are transformed to RGB555 data that is passed to the video renderer. The video renderer then uses its internal palette to apply brightness/contrast/gamma/ramp adjustments and outputs in RGB888 color space. This does add in another rendering pass, unfortunately, but it's a necessary one for universal support. The plan is to adapt all filters to take RGB555 input, and output RGB555 data as well. By doing this, it will be possible to stack filters. However, it's a bit complicated: I need to plan how the stacking should occur (eg we never want to apply scanlines before HQ2x, etc.) Added input frequency adjustments for all three systems. I can easily get perfect video/audio sync on all three now, hooray. Long-term, it seems like we only really need one, and we can do a video/audio delta to get an adjusted value. But for now, this gets the job done. Added audio volume adjust. I left out the balance for now, since it's obviously impossible to balance the NES' single channel audio (I can duplicate the channel, and do twice the filtering work, but ... why?) I replaced NTSC/PAL TV mode selection with an "Enable Overscan" checkbox. On, you get 240 lines on NES+SNES. Off, you get 224 lines on NES+SNES. Also added aspect correction box back. I don't do that gross PAL distortion shit anymore, sorry PAL people. I just scale up the 54/47*(240/224) aspect correction for overscan off mode. All memory is loaded and saved now, for all three systems (hooray, now you can actually play Zelda 1&2.) Added all of the old bsnes hotkeys, with the exception of capture screenshot. May add again later. May come up with something a bit different for extra features. Re-added the NSS DIP switch setting window. Since geometry is saved, I didn't want to auto-hide rows, so now you'll see all eight possible DIPs, and the ones not used are grayed out. Ultimately, nobody will notice since we only have DIPs for ActRaiser NSS, and nobody's probably even using the XML file for that anyway. Whatever, it's nice to have anyway. Took FitzRoy's advice and single-item combo boxes on the input selection are disabled, so the user doesn't waste time checking them. I wanted to leave text so that you know there's not a problem. Qt disabled radio box items look almost exactly like enabled ones. Fixed lots of issues in phoenix and extended it a bit. But I was still having trouble with radio box grouping, so I said fuck it and made the panels show/hide based instead of append/remove based. That's all for stuff off the checklist, I did a bunch of other things I don't recall. So yeah, I'd say the GUI is 100% usable now. This is my opinion on how multi-platform GUIs should be done =) Oh, I figure I should mention, but the NES core is GPLv3, and all future SNES+GB releases will be as well. It's a move against Microsoft's Metro store.
2011-09-20 14:04:43 +00:00
pWidget::synchronizeState();
setPosition(progressBar.state.position);
}
void pProgressBar::destructor() {
delete qtProgressBar;
qtWidget = qtProgressBar = 0;
}
void pProgressBar::orphan() {
destructor();
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
}
}