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

20 lines
479 B
C++
Raw Normal View History

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
#include <nall/nall.hpp>
Update to v088r08 release. byuu says: From this WIP, I'm starting on the impossible task of a declarative-based GUI, which I'm calling Ethos. base/ becomes emulator/, and we add emulator/interface.hpp, which is a base API that all emulation cores must implement in full. (Right now, it's kind of a hybrid to work with the old GUI and the new GUI at the same time, of course.) Unlike the old interfaces, the new base class also provides all general usability hooks: loading and saving files and states, cheat codes, etc. The new interface also contains information and vector structs to describe all possible loading methods, controller bindings, etc; and gives names for them all. The actual GUI in fact should not include eg <gba/gba.hpp> anymore. Should speed up GUI compilation. So the idea going forward is that ethos will build a list of emulators right when the application starts up. Once you've appended an emulator to that list, you're done. No more GUI changes are needed to support that system. The GUI will have code to parse the emulator interfaces list, and build all the requisite GUI options dynamically, declarative style. Ultimately, once the project is finished, the new GUI should look ~99% identical to the current GUI. But it'll probably be a whole lot smaller.
2012-04-29 06:29:54 +00:00
#include <ruby/ruby.hpp>
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
#include <hiro/hiro.hpp>
using namespace nall;
Update to v088r08 release. byuu says: From this WIP, I'm starting on the impossible task of a declarative-based GUI, which I'm calling Ethos. base/ becomes emulator/, and we add emulator/interface.hpp, which is a base API that all emulation cores must implement in full. (Right now, it's kind of a hybrid to work with the old GUI and the new GUI at the same time, of course.) Unlike the old interfaces, the new base class also provides all general usability hooks: loading and saving files and states, cheat codes, etc. The new interface also contains information and vector structs to describe all possible loading methods, controller bindings, etc; and gives names for them all. The actual GUI in fact should not include eg <gba/gba.hpp> anymore. Should speed up GUI compilation. So the idea going forward is that ethos will build a list of emulators right when the application starts up. Once you've appended an emulator to that list, you're done. No more GUI changes are needed to support that system. The GUI will have code to parse the emulator interfaces list, and build all the requisite GUI options dynamically, declarative style. Ultimately, once the project is finished, the new GUI should look ~99% identical to the current GUI. But it'll probably be a whole lot smaller.
2012-04-29 06:29:54 +00:00
using namespace ruby;
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
using namespace hiro;
Update to v094r28 release. byuu says: This WIP substantially restructures the ruby API for the first time since that project started. It is my hope that with this restructuring, destruction of the ruby objects should now be deterministic, which should fix the crashing on closing the emulator on Linux. We'll see I guess ... either way, it removed two layers of wrappers from ruby, so it's a pretty nice code cleanup. It won't compile on Windows due to a few issues I didn't see until uploading the WIP, too lazy to upload another. But I fixed all the compilation issues locally, so it'll work on Windows again with the next WIP (unless I break something else.) (Kind of annoying that Linux defines glActiveTexture but Windows doesn't.)
2015-06-20 05:44:05 +00:00
extern Video* video;
extern Audio* audio;
extern Input* input;
#include <emulator/emulator.hpp>
extern Emulator::Interface* emulator;
Update to v094r10 release. byuu says: This starts the tomoko UI. So far I have basic library loading and video+audio output. Basically just enough to take the below screenshot. (aside from Library, the menus are empty stubs.) The .sys (system) game folders are now going under ~/Emulation/System, to avoid needing root privileges to stick them into /usr/share. The game library now shows all bootable media types, and the drop-down subtype is gone. I'm going to display a separate modal dialog for loading slotted games this time around. Much cleaner this way, less clutter. tomoko's starting off a lot cleaner than ethos was, and I'm scaling back the number of abstracted classes. What was Utility, Interface, etc are now being merged all into Program. Of course, the real hell is the input system. That has so many layers of bullshit that there's really no sane way to write it.
2015-02-28 01:51:53 +00:00
#include "program/program.hpp"
Update to v094r12 release. byuu says: Changelog: * added driver selection * added video scale + aspect correction settings * added A/V sync + audio mute settings * added configuration file * fixed compilation bugs under Windows and Linux * fixed window sizing * removed HSU1 * the system menu stays as "System", because "Game Boy Advance" was too long a string for the smallest scale size * some more stuff You guys probably won't be ecstatic about the video sizing options, but it's basically your choice of 1x, 2x or 4x scale with optional aspect correction. 3x was intentionally skipped because it looks horrible on hires SNES games. The window is resized and recentered upon loading games. The window doesn't resize otherwise. I never really liked the way v094 always left you with black screen areas and left you with off-centered window positions. I might go ahead and add the pseudo-fullscreen toggle that will jump into 4x mode (respecting your aspect setting.) Short-term: * add input port changing support * add other input types (mouse-based, etc) * add save states * add cheat codes * add timing configuration (video/audio sync) * add hotkeys (single state) We can probably do a new release once the short-term items are completed. Long-term: * add slotted cart loader (SGB, BSX, ST) * add DIP switch selection window (NSS) * add cheat code database * add state manager * add overscan masking Not planned: * video color adjustments (will allow emulated color vs raw color; but no more sliders) * pixel shaders * ananke integration (will need to make a command-line version to get my games in) * fancy audio adjustment controls (resampler, latency, volume) * input focus settings * relocating game library (not hard, just don't feel like it) * localization support (not enough users) * window geometry memory * anything else not in higan v094
2015-03-03 10:14:49 +00:00
#include "configuration/configuration.hpp"
Update to v094r11 release. byuu says: I've hooked up the input subsystem, and the input manager to assign hotkeys. So far I only have digital buttons working (keyboard only), and I'm not planning on supporting input groups again (mapping multiple physical buttons to one emulated button), but it's progress. As with the rest of tomoko, the code's a lot more compact. The nice thing about redoing code so many times is that each time you get a little bit better at it. The input configuration is saved to ~/.config/tomoko/settings.bml (just realized that I'm an idiot and need to rename it to input.bml) Also hooked up game saves and cartridge unloading. Active controller changing isn't hooked up yet, and I'll probably do it differently. Oh, and I declared the ruby lines for other platforms. Still need to add Cydrak's Windows compilation fixes. I am nothing if not lazy :P
2015-03-02 09:13:28 +00:00
#include "input/input.hpp"
#include "settings/settings.hpp"
Update to v094r15 release. byuu says: Implemented the cheat database dialog, and most of the cheat editor dialog. I still have to handle loading and saving the cheats.bml file for each game. I wanted to finish it today, but I burned out. It's a ton of really annoying work to support cheat codes. There's also some issue with the width calculation for the "code(s)" column in hiro/GTK. Short-term: - add input port changing support - add other input types (mouse-based, etc) - finish cheat codes Long-term: - add slotted cart loader (SGB, BSX, ST) - add DIP switch selection window (NSS) - add overscan masking - add timing configuration (video/audio sync) Not planned: - video color adjustments (will allow emulated color vs raw color; but no more sliders) - pixel shaders - ananke integration (will need to make a command-line version to get my games in) - fancy audio adjustment controls (resampler, latency, volume) - input focus settings - localization support (not enough users) - window geometry memory - anything else not in higan v094
2015-04-21 11:51:57 +00:00
#include "tools/tools.hpp"
Update to v094r10 release. byuu says: This starts the tomoko UI. So far I have basic library loading and video+audio output. Basically just enough to take the below screenshot. (aside from Library, the menus are empty stubs.) The .sys (system) game folders are now going under ~/Emulation/System, to avoid needing root privileges to stick them into /usr/share. The game library now shows all bootable media types, and the drop-down subtype is gone. I'm going to display a separate modal dialog for loading slotted games this time around. Much cleaner this way, less clutter. tomoko's starting off a lot cleaner than ethos was, and I'm scaling back the number of abstracted classes. What was Utility, Interface, etc are now being merged all into Program. Of course, the real hell is the input system. That has so many layers of bullshit that there's really no sane way to write it.
2015-02-28 01:51:53 +00:00
#include "presentation/presentation.hpp"