Initial release; fork of **higan** v110.
- the project and core library is now called **ares**
- the simplified user interface is now called **lucia**
- the advanced user interface is now called **luna**
- the game analyzer is now called **mia**
- removed the database editor **genius** from the project
- PC Engine: adjusted rendering viewport for the scanline renderer
from Y=18 to Y=21
byuu says:
Another eleven hours in ... I think we're finally starting to see some
hope.
Unserialization of the tree works now. An absolutely heroic effort. The
design challenges were thus:
- given a text document, reproduce a tree of shared pointer objects
- the text document may have extra or bad node names (perhaps it's
from an older version) -- ignore these so they don't appear in the
actual tree
- the text document may be missing some node names (again, maybe an
older version) -- populate the actual tree nodes with default values
in this case
- any peripherals connected in text document nodes won't be in the
actual tree, so we have to connect them
- upon the creation of a new actual tree peripheral, we must populate
it with the metadata from the text document recursively, with the
above rules in effect
- we also need to allow the GUI to attach new peripherals, where it
would not know about the child nodes each peripheral contains (eg
the buttons on a gamepad)
- lastly, even though the tree is small, try not to take an absolute
eternity to import a document into the tree
There's a hell of a lot of restructuring that needs doing, in the SNES
core far more than anywhere else. We have to split bus mapping to occur
at power-on time, and manifest generation + slot attachments to happen
during load / system configuration. GBA also should move to detecting
save types at run-time. And honestly, that scan is pretty painfully slow
... it may make sense to suffix array it ... 13*4MiB isn't that much
memory. That or just write a smarter substring scanner. Sigh.
So now that things can be serialized, the next step is going to be
writing an input manager. It's going to be a radical departure from the
old way of doing things. Now, when the core wants input state, it'll
call inputPoll with a Node::Input object that we can directly write the
value to (well, after we `dynamic_cast` it to its specialized type. It'd
sure be nice if there were a `dynamic_multicast` switch construct, so we
didn't have to keep doing repeated `dynamic_cast` calls for each input
type. I digress.) I guess we can cache things ...
Thus, input polling will be more like this:
- produce a map of Node::Input to
`shared_pointer<InputManager::Binding>` objects
- maybe even do a multitap as a lazier way of handling multiple
input bindings
- have the InputManager::Binding hold a `shared_pointer<nall::HID>`
object, the group ID, and the input ID
- polling will thus be a map (or multitap) lookup; copying the
nall::HID value over to the Node::Input value
- it should be fine to just store `shared_pointers` here, to save
the overhead of constantly converting `weak_pointers`
And of course, we have to write a GUI for this. Oh, and before I can
even do the above ... I have to implement template importing, and
implement serialization support when attaching / detaching peripherals.
Hmm, what else ... I got rid of the Port specializations, as Port ends
up needing a lot of glue code and any special handling can be done
inside the emulation cores anyway. So now, a Port is a Port. It's just a
Node with the special property that it may contain either zero or one
Peripheral nodes. In addition to nodes of other types, of course.
I'm thinking we should probably also enforce a tree rule that no parent
node shall have two child nodes that have both the same type and the
same name. If we stick to that rule, we can simplify path traversal, and
allow the append function to be used as a "create if not exists"
function.
Also, we're really going to need a system to pick sensible default
peripheral and template paths for ports, including for dynamic ports.
Having to manually assign these, and having the values on dynamically
generated ports lost easily, is very annoying.
byuu says:
Changelog:
- fixed nall/path.hpp compilation issue
- fixed ruby/audio/xaudio header declaration compilation issue (again)
- cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the
file was whitespace overkill)
- added null terminator entry to nall/windows/utf8.hpp argc[] array
- nall/windows/guid.hpp uses the Windows API for generating the GUID
- this should stop all the bug reports where two nall users were
generating GUIDs at the exact same second
- fixed hiro/cocoa compilation issue with uint# types
- fixed major higan/sfc Super Game Boy audio latency issue
- fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions
- major cleanups to higan/processor/r65816 core
- merged emulation/native-mode opcodes
- use camel-case naming on memory.hpp functions
- simplify address masking code for memory.hpp functions
- simplify a few opcodes themselves (avoid redundant copies, etc)
- rename regs.* to r.* to match modern convention of other CPU cores
- removed device.order<> concept from Emulator::Interface
- cores will now do the translation to make the job of the UI easier
- fixed plurality naming of arrays in Emulator::Interface
- example: emulator.ports[p].devices[d].inputs[i]
- example: vector<Medium> media
- probably more surprises
Major show-stoppers to the next official release:
- we need to work on GB core improvements: LY=153/0 case, multiple STAT
IRQs case, GBC audio output regs, etc.
- we need to re-add software cursors for light guns (Super Scope,
Justifier)
- after the above, we need to fix the turbo button for the Super Scope
I really have no idea how I want to implement the light guns. Ideally,
we'd want it in higan/video, so we can support the NES Zapper with the
same code. But this isn't going to be easy, because only the SNES knows
when its output is interlaced, and its resolutions can vary as
{256,512}x{224,240,448,480} which requires pixel doubling that was
hard-coded to the SNES-specific behavior, but isn't appropriate to be
exposed in higan/video.
byuu says:
New update. Most of the work today went into eliminating hiro::Image
from all objects in all ports, replacing with nall::image. That took an
eternity.
Changelog:
- fixed crashing bug when loading games [thanks endrift!!]
- toggling "show status bar" option adjusts window geometry (not
supposed to recenter the window, though)
- button sizes improved; icon-only button icons no longer being cut off
byuu says:
I'll post more detailed changes later, but basically:
- fixed Baldur's Gate bug
- guess if no flash ROM ID present (fixes Magical Vacation, many many
others)
- nall cleanups
- sfc/cartridge major cleanups
- bsxcartridge/"bsx" renamed to mcc/"mcc" after the logic chip it uses
(consistency with SGB/ICD2)
- ... and more!
byuu says:
Changelog:
- synchronizes lots of nall changes
- changes displayed program title from tomoko to higan(*)
- browser dialog sort is case-insensitive
- .sys folders look at user-selected library path; no longer hard-coded
Tried to get rid of the file modes from the Windows browser dialog, but
it was being a bitch so I left it on for now.
- The storage locations and binary still use tomoko. I'm not really sure
what to do here. The idea is there may be more than one "higan" UI in
the future, but I don't want people to go around calling the entire
program by the UI name. For official Windows releases, I can rename
the binaries to "higan-{profile}.exe", and by putting the config files
with the binary, they won't ever see the tomoko folder. Linux is of
course trickier.
Note: Windows users will need to edit hiro/components.hpp and comment
out these lines:
#define Hiro_Console
#define Hiro_IconView
#define Hiro_SourceView
#define Hiro_TreeView
I forgot to do that, and too lazy to upload another WIP.
byuu says:
New terminal is in. Much nicer to use now. Command history makes a major
difference in usability.
The SMP is now fully traceable and debuggable. Basically they act as
separate entities, you can trace both at the same time, but for the most
part running and stepping is performed on the chip you select.
I'm going to put off CPU+SMP interleave support for a while. I don't
actually think it'll be too hard. Will get trickier if/when we support
coprocessor debugging.
Remaining tasks:
- aliases
- hotkeys
- save states
- window geometry
Basically, the debugger's done. Just have to add the UI fluff.
I also removed tracing/memory export from higan. It was always meant to
be temporary until the debugger was remade.
byuu says:
Changelog:
- added Cocoa target: higan can now be compiled for OS X Lion
[Cydrak, byuu]
- SNES/accuracy profile hires color blending improvements - fixes
Marvelous text [AWJ]
- fixed a slight bug in SNES/SA-1 VBR support caused by a typo
- added support for multi-pass shaders that can load external textures
(requires OpenGL 3.2+)
- added game library path (used by ananke->Import Game) to
Settings->Advanced
- system profiles, shaders and cheats database can be stored in "all
users" shared folders now (eg /usr/share on Linux)
- all configuration files are in BML format now, instead of XML (much
easier to read and edit this way)
- main window supports drag-and-drop of game folders (but not game files
/ ZIP archives)
- audio buffer clears when entering a modal loop on Windows (prevents
audio repetition with DirectSound driver)
- a substantial amount of code clean-up (probably the biggest
refactoring to date)
One highly desired target for this release was to default to the optimal
drivers instead of the safest drivers, but because AMD drivers don't
seem to like my OpenGL 3.2 driver, I've decided to postpone that. AMD
has too big a market share. Hopefully with v093 officially released, we
can get some public input on what AMD doesn't like.
invertego