ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/hiro/GNUmakefile

82 lines
2.6 KiB
Makefile
Raw Normal View History

Update to v096r02 (OS X Preview for Developers) release. byuu says: Warning: this is not for the faint of heart. This is a very early, unpolished, buggy release. But help testing/fixing bugs would be greatly appreciated for anyone willing. Requirements: - Mac OS X 10.7+ - Xcode 7.2+ Installation Commands: cd higan gmake -j 4 gmake install cd ../icarus gmake -j 4 gmake install (gmake install is absolutely required, sorry. You'll be missing key files in key places if you don't run it, and nothing will work.) (gmake uninstall also exists, or you can just delete the .app bundles from your Applications folder, and the Dev folder on your desktop.) If you want to use the GBA emulation, then you need to drop the GBA BIOS into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom Usage: You'll now find higan.app and icarus.app in your Applications folders. First, run icarus.app, navigate to where you keep your game ROMs. Now click the settings button at the bottom right, and check "Create Manifests", and click OK. (You'll need to do this every time you run icarus because there's some sort of bug on OSX saving the settings.) Now click "Import", and let it bring in your games into ~/Emulation. Note: "Create Manifests" is required. I don't yet have a pipe implementation on OS X for higan to invoke icarus yet. If you don't check this box, it won't create manifest.bml files, and your games won't run at all. Now you can run higan.app. The first thing you'll want to do is go to higan->Preferences... and assign inputs for your gamepads. At the very least, do it for the default controller for all the systems you want to emulate. Now this is very important ... close the application at this point so that it writes your config file to disk. There's a serious crashing bug, and if you trigger it, you'll lose your input bindings. Now the really annoying part ... go to Library->{System} and pick the game you want to play. Right now, there's a ~50% chance the application will bomb. It seems the hiro::pListView object is getting destroyed, yet somehow the internal Cocoa callbacks are being triggered anyway. I don't know how this is possible, and my attempts to debug with lldb have been a failure :( If you're unlucky, the application will crash. Restart and try again. If it crashes every single time, then you can try launching your game from the command-line instead. Example: open /Applications/higan.app \ --args ~/Emulation/Super\ Famicom/Zelda3.sfc/ Help wanted: I could really, really, really use some help with that crashing on game loading. There's a lot of rough edges, but they're all cosmetic. This one thing is pretty much the only major show-stopping issue at the moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
ifeq ($(platform),windows)
Update to v094r13 release. byuu says: This version polishes up the input dialogue (reset, erase, disable button when item not focused, split device ID from mapping name), adds color emulation toggle, and add dummy menu items for remaining features (to be filled in later.) Also, it now compiles cleanly on Windows with GTK. I didn't test with TDM-GCC-32, because for god knows what reason, the 32-bit version ships with headers from Windows 95 OSR2 only. So I built with TDM-GCC-64 with arch=x86. And uh, apparently, moving or resizing a window causes a Visual C++ runtime exception in the GTK+ DLLs. This doesn't happen with trance or renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
2015-03-07 10:21:47 +00:00
ifeq ($(hiro),)
hiro := windows
endif
ifeq ($(hiro),windows)
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.flags = $(flags.cpp) -DHIRO_WINDOWS
Update to bsnes v107.1 release. byuu says: Don't let the point release fool you, there are many significant changes in this release. I will be keeping bsnes releases using a point system until the new higan release is ready. Changelog: - GUI: added high DPI support - GUI: fixed the state manager image preview - Windows: added a new waveOut driver with support for dynamic rate control - Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso] - Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering - Windows: fixed XInput controller support on Windows 10 - SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4 coprocessors - SFC: fixed a slight rendering glitch in the intro to Megalomania If the coprocessor firmware is missing, bsnes will fallback on HLE where it is supported, which is everything other than SD Gundam GX and the two Hayazashi Nidan Morita Shougi games. The Windows dynamic rate control works best with Direct3D in fullscreen exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it is not possible to target a single XAudio2 version on all Windows OS releases. The waveOut driver should work everywhere out of the box. Note that with DRC, the synchronization source is your monitor, so you will want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
hiro.options = -lkernel32 -luser32 -lgdi32 -ladvapi32 -lole32 -lcomctl32 -lcomdlg32 -luxtheme -lmsimg32 -lshlwapi -ldwmapi
Update to v094r13 release. byuu says: This version polishes up the input dialogue (reset, erase, disable button when item not focused, split device ID from mapping name), adds color emulation toggle, and add dummy menu items for remaining features (to be filled in later.) Also, it now compiles cleanly on Windows with GTK. I didn't test with TDM-GCC-32, because for god knows what reason, the 32-bit version ships with headers from Windows 95 OSR2 only. So I built with TDM-GCC-64 with arch=x86. And uh, apparently, moving or resizing a window causes a Visual C++ runtime exception in the GTK+ DLLs. This doesn't happen with trance or renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
2015-03-07 10:21:47 +00:00
endif
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
ifeq ($(hiro),gtk2)
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.flags = $(flags.cpp) -DHIRO_GTK=2 $(shell pkg-config --cflags gtk+-2.0 gtksourceview-2.0)
hiro.options = $(shell pkg-config --libs gtk+-2.0 gtksourceview-2.0)
Update to v094r13 release. byuu says: This version polishes up the input dialogue (reset, erase, disable button when item not focused, split device ID from mapping name), adds color emulation toggle, and add dummy menu items for remaining features (to be filled in later.) Also, it now compiles cleanly on Windows with GTK. I didn't test with TDM-GCC-32, because for god knows what reason, the 32-bit version ships with headers from Windows 95 OSR2 only. So I built with TDM-GCC-64 with arch=x86. And uh, apparently, moving or resizing a window causes a Visual C++ runtime exception in the GTK+ DLLs. This doesn't happen with trance or renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
2015-03-07 10:21:47 +00:00
endif
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
ifeq ($(hiro),gtk3)
Update to bsnes v107.1 release. byuu says: Don't let the point release fool you, there are many significant changes in this release. I will be keeping bsnes releases using a point system until the new higan release is ready. Changelog: - GUI: added high DPI support - GUI: fixed the state manager image preview - Windows: added a new waveOut driver with support for dynamic rate control - Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso] - Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering - Windows: fixed XInput controller support on Windows 10 - SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4 coprocessors - SFC: fixed a slight rendering glitch in the intro to Megalomania If the coprocessor firmware is missing, bsnes will fallback on HLE where it is supported, which is everything other than SD Gundam GX and the two Hayazashi Nidan Morita Shougi games. The Windows dynamic rate control works best with Direct3D in fullscreen exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it is not possible to target a single XAudio2 version on all Windows OS releases. The waveOut driver should work everywhere out of the box. Note that with DRC, the synchronization source is your monitor, so you will want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
hiro.flags = $(flags.cpp) -DHIRO_GTK=3 $(shell pkg-config --cflags gtk+-3.0 gtksourceview-3.0) -Wno-deprecated-declarations
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.options = $(shell pkg-config --libs gtk+-3.0 gtksourceview-3.0)
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
endif
Update to v096r02 (OS X Preview for Developers) release. byuu says: Warning: this is not for the faint of heart. This is a very early, unpolished, buggy release. But help testing/fixing bugs would be greatly appreciated for anyone willing. Requirements: - Mac OS X 10.7+ - Xcode 7.2+ Installation Commands: cd higan gmake -j 4 gmake install cd ../icarus gmake -j 4 gmake install (gmake install is absolutely required, sorry. You'll be missing key files in key places if you don't run it, and nothing will work.) (gmake uninstall also exists, or you can just delete the .app bundles from your Applications folder, and the Dev folder on your desktop.) If you want to use the GBA emulation, then you need to drop the GBA BIOS into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom Usage: You'll now find higan.app and icarus.app in your Applications folders. First, run icarus.app, navigate to where you keep your game ROMs. Now click the settings button at the bottom right, and check "Create Manifests", and click OK. (You'll need to do this every time you run icarus because there's some sort of bug on OSX saving the settings.) Now click "Import", and let it bring in your games into ~/Emulation. Note: "Create Manifests" is required. I don't yet have a pipe implementation on OS X for higan to invoke icarus yet. If you don't check this box, it won't create manifest.bml files, and your games won't run at all. Now you can run higan.app. The first thing you'll want to do is go to higan->Preferences... and assign inputs for your gamepads. At the very least, do it for the default controller for all the systems you want to emulate. Now this is very important ... close the application at this point so that it writes your config file to disk. There's a serious crashing bug, and if you trigger it, you'll lose your input bindings. Now the really annoying part ... go to Library->{System} and pick the game you want to play. Right now, there's a ~50% chance the application will bomb. It seems the hiro::pListView object is getting destroyed, yet somehow the internal Cocoa callbacks are being triggered anyway. I don't know how this is possible, and my attempts to debug with lldb have been a failure :( If you're unlucky, the application will crash. Restart and try again. If it crashes every single time, then you can try launching your game from the command-line instead. Example: open /Applications/higan.app \ --args ~/Emulation/Super\ Famicom/Zelda3.sfc/ Help wanted: I could really, really, really use some help with that crashing on game loading. There's a lot of rough edges, but they're all cosmetic. This one thing is pretty much the only major show-stopping issue at the moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
endif
Update to v104r15 release. byuu says: Changelog: - processor/huc6280,mos6502,wdc65816: replaced abbreviated opcode names with descriptive names - nall: replaced `PLATFORM_MACOSX` define with `PLATFORM_MACOS` - icarus: added `Icarus::missing() -> string_vector` to list missing appended firmware files by name - ruby, hiro: fix macosx→macos references The processor instruction renaming was really about consistency with the other processor cores. I may still need to do this for one or two more processors. The icarus change should allow a future release of the icarus application to import games with external SNES coprocessor firmware once again. It will also allow this to be possible when used in library mode.
2017-09-29 10:36:35 +00:00
ifeq ($(platform),macos)
Update to v094r13 release. byuu says: This version polishes up the input dialogue (reset, erase, disable button when item not focused, split device ID from mapping name), adds color emulation toggle, and add dummy menu items for remaining features (to be filled in later.) Also, it now compiles cleanly on Windows with GTK. I didn't test with TDM-GCC-32, because for god knows what reason, the 32-bit version ships with headers from Windows 95 OSR2 only. So I built with TDM-GCC-64 with arch=x86. And uh, apparently, moving or resizing a window causes a Visual C++ runtime exception in the GTK+ DLLs. This doesn't happen with trance or renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
2015-03-07 10:21:47 +00:00
ifeq ($(hiro),)
hiro := cocoa
endif
ifeq ($(hiro),cocoa)
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.flags = $(flags.objcpp) -w -DHIRO_COCOA
hiro.options = -framework Cocoa -framework Carbon -framework Security
Update to v094r13 release. byuu says: This version polishes up the input dialogue (reset, erase, disable button when item not focused, split device ID from mapping name), adds color emulation toggle, and add dummy menu items for remaining features (to be filled in later.) Also, it now compiles cleanly on Windows with GTK. I didn't test with TDM-GCC-32, because for god knows what reason, the 32-bit version ships with headers from Windows 95 OSR2 only. So I built with TDM-GCC-64 with arch=x86. And uh, apparently, moving or resizing a window causes a Visual C++ runtime exception in the GTK+ DLLs. This doesn't happen with trance or renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
2015-03-07 10:21:47 +00:00
endif
Update to v096r02 (OS X Preview for Developers) release. byuu says: Warning: this is not for the faint of heart. This is a very early, unpolished, buggy release. But help testing/fixing bugs would be greatly appreciated for anyone willing. Requirements: - Mac OS X 10.7+ - Xcode 7.2+ Installation Commands: cd higan gmake -j 4 gmake install cd ../icarus gmake -j 4 gmake install (gmake install is absolutely required, sorry. You'll be missing key files in key places if you don't run it, and nothing will work.) (gmake uninstall also exists, or you can just delete the .app bundles from your Applications folder, and the Dev folder on your desktop.) If you want to use the GBA emulation, then you need to drop the GBA BIOS into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom Usage: You'll now find higan.app and icarus.app in your Applications folders. First, run icarus.app, navigate to where you keep your game ROMs. Now click the settings button at the bottom right, and check "Create Manifests", and click OK. (You'll need to do this every time you run icarus because there's some sort of bug on OSX saving the settings.) Now click "Import", and let it bring in your games into ~/Emulation. Note: "Create Manifests" is required. I don't yet have a pipe implementation on OS X for higan to invoke icarus yet. If you don't check this box, it won't create manifest.bml files, and your games won't run at all. Now you can run higan.app. The first thing you'll want to do is go to higan->Preferences... and assign inputs for your gamepads. At the very least, do it for the default controller for all the systems you want to emulate. Now this is very important ... close the application at this point so that it writes your config file to disk. There's a serious crashing bug, and if you trigger it, you'll lose your input bindings. Now the really annoying part ... go to Library->{System} and pick the game you want to play. Right now, there's a ~50% chance the application will bomb. It seems the hiro::pListView object is getting destroyed, yet somehow the internal Cocoa callbacks are being triggered anyway. I don't know how this is possible, and my attempts to debug with lldb have been a failure :( If you're unlucky, the application will crash. Restart and try again. If it crashes every single time, then you can try launching your game from the command-line instead. Example: open /Applications/higan.app \ --args ~/Emulation/Super\ Famicom/Zelda3.sfc/ Help wanted: I could really, really, really use some help with that crashing on game loading. There's a lot of rough edges, but they're all cosmetic. This one thing is pretty much the only major show-stopping issue at the moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
endif
ifneq ($(filter $(platform),linux bsd),)
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
ifeq ($(hiro),)
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
hiro := gtk2
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
endif
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
ifeq ($(hiro),gtk2)
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.flags = $(flags.cpp) -DHIRO_GTK=2 $(shell pkg-config --cflags gtk+-2.0 gtksourceview-2.0)
hiro.options = -lX11 $(shell pkg-config --libs gtk+-2.0 gtksourceview-2.0)
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
endif
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
ifeq ($(hiro),gtk3)
Update to bsnes v107.1 release. byuu says: Don't let the point release fool you, there are many significant changes in this release. I will be keeping bsnes releases using a point system until the new higan release is ready. Changelog: - GUI: added high DPI support - GUI: fixed the state manager image preview - Windows: added a new waveOut driver with support for dynamic rate control - Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso] - Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering - Windows: fixed XInput controller support on Windows 10 - SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4 coprocessors - SFC: fixed a slight rendering glitch in the intro to Megalomania If the coprocessor firmware is missing, bsnes will fallback on HLE where it is supported, which is everything other than SD Gundam GX and the two Hayazashi Nidan Morita Shougi games. The Windows dynamic rate control works best with Direct3D in fullscreen exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it is not possible to target a single XAudio2 version on all Windows OS releases. The waveOut driver should work everywhere out of the box. Note that with DRC, the synchronization source is your monitor, so you will want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
hiro.flags = $(flags.cpp) -DHIRO_GTK=3 $(shell pkg-config --cflags gtk+-3.0 gtksourceview-3.0) -Wno-deprecated-declarations
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.options = -lX11 $(shell pkg-config --libs gtk+-3.0 gtksourceview-3.0)
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
endif
ifeq ($(hiro),qt4)
Update to bsnes v107.1 release. byuu says: Don't let the point release fool you, there are many significant changes in this release. I will be keeping bsnes releases using a point system until the new higan release is ready. Changelog: - GUI: added high DPI support - GUI: fixed the state manager image preview - Windows: added a new waveOut driver with support for dynamic rate control - Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso] - Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering - Windows: fixed XInput controller support on Windows 10 - SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4 coprocessors - SFC: fixed a slight rendering glitch in the intro to Megalomania If the coprocessor firmware is missing, bsnes will fallback on HLE where it is supported, which is everything other than SD Gundam GX and the two Hayazashi Nidan Morita Shougi games. The Windows dynamic rate control works best with Direct3D in fullscreen exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it is not possible to target a single XAudio2 version on all Windows OS releases. The waveOut driver should work everywhere out of the box. Note that with DRC, the synchronization source is your monitor, so you will want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
moc = /usr/local/lib/qt4/bin/moc
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.flags = $(flags.cpp) -DHIRO_QT=4 $(shell pkg-config --cflags QtCore QtGui)
hiro.options = -lX11 $(shell pkg-config --libs QtCore QtGui)
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
endif
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
ifeq ($(hiro),qt5)
moc = /usr/local/lib/qt5/bin/moc
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
hiro.flags = $(flags.cpp) -DHIRO_QT=5 -fPIC $(shell pkg-config --cflags Qt5Core Qt5Gui Qt5Widgets)
hiro.options = -lX11 $(shell pkg-config --libs Qt5Core Qt5Gui Qt5Widgets)
Update to v106r38 release. byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ...
2018-06-10 08:06:02 +00:00
endif
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
endif
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
ifeq ($(hiro.resource),)
hiro.resource := $(hiro.path)/windows/hiro.rc
endif
Update to v106r48 release. byuu says: The problems with the Windows and Qt4 ports have all been resolved, although there's a fairly gross hack on a few Qt widgets to not destruct once Application::quit() is called to avoid a double free crash (I'm unsure where Qt is destructing the widgets internally.) The Cocoa port compiles again at least, though it's bound to have endless problems. I improved the Label painting in the GTK ports, which fixes the background color on labels inside TabFrame widgets. I've optimized the Makefile system even further. I added a "redo state" command to bsnes, which is created whenever you load the undo state. There are also hotkeys for both now, although I don't think they're really something you want to map hotkeys to. I moved the nall::Locale object inside hiro::Application, so that it can be used to translate the BrowserDialog and MessageDialog window strings. I improved the Super Game Boy emulation of `MLT_REQ`, fixing Pokemon Yellow's custom border and probably more stuff. Lots of other small fixes and improvements. Things are finally stable once again after the harrowing layout redesign catastrophe. Errata: - ICD::joypID should be set to 3 on reset(). joypWrite() may as well take uint1 instead of bool. - hiro/Qt: remove pWindow::setMaximumSize() comment; found a workaround for it - nall/GNUmakefile: don't set object.path if it's already set (allow overrides before including the file)
2018-07-16 06:16:26 +00:00
hiro.objects := \
$(object.path)/hiro-$(hiro).o \
$(if $(filter windows,$(hiro)),$(object.path)/hiro-resource.o)
$(object.path)/hiro-$(hiro).o: $(hiro.path)/hiro.cpp
$(if $(filter qt%,$(hiro)),$(info Compiling $(hiro.path)/qt/qt.moc ...))
$(if $(filter qt%,$(hiro)),@$(moc) -i -o $(hiro.path)/qt/qt.moc $(hiro.path)/qt/qt.hpp)
$(info Compiling $< ...)
@$(compiler) $(hiro.flags) $(flags) $(flags.deps) -c $< -o $@
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
$(object.path)/hiro-resource.o: $(hiro.resource)
Update to v106r48 release. byuu says: The problems with the Windows and Qt4 ports have all been resolved, although there's a fairly gross hack on a few Qt widgets to not destruct once Application::quit() is called to avoid a double free crash (I'm unsure where Qt is destructing the widgets internally.) The Cocoa port compiles again at least, though it's bound to have endless problems. I improved the Label painting in the GTK ports, which fixes the background color on labels inside TabFrame widgets. I've optimized the Makefile system even further. I added a "redo state" command to bsnes, which is created whenever you load the undo state. There are also hotkeys for both now, although I don't think they're really something you want to map hotkeys to. I moved the nall::Locale object inside hiro::Application, so that it can be used to translate the BrowserDialog and MessageDialog window strings. I improved the Super Game Boy emulation of `MLT_REQ`, fixing Pokemon Yellow's custom border and probably more stuff. Lots of other small fixes and improvements. Things are finally stable once again after the harrowing layout redesign catastrophe. Errata: - ICD::joypID should be set to 3 on reset(). joypWrite() may as well take uint1 instead of bool. - hiro/Qt: remove pWindow::setMaximumSize() comment; found a workaround for it - nall/GNUmakefile: don't set object.path if it's already set (allow overrides before including the file)
2018-07-16 06:16:26 +00:00
$(info Compiling $< ...)
@$(windres) $< $@
hiro.verbose:
$(info hiro Target:)
$(info $([space]) $(hiro))