mirror of https://github.com/bsnes-emu/bsnes.git
4 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
bd628de3cf |
Update to higan and icarus v095r15 release.
r13 and r14 weren't posted as individual releases, but their changelogs
were posted.
byuu says about r13:
I'm not going to be posting WIPs for r13 and above for a while.
The reason is that I'm working on the major manifest overhaul I've
discussed previously on the icarus subforum.
I'm recreating my boards database from scratch using the map files
and the new map analyzer. The only games that will load are ones
I've created board definitions for, and updated
sfc/cartridge/markup.cpp to parse. Once I've finished all the
boards, then I'll update the heuristics.
Then finally, I'll sync the syntax changes over to the fc, gb, gba
cores.
Once that's done, I'll start posting WIPs again, along with a new
build of icarus.
But I'll still post changelogs as I work through things.
Changelog (r13):
- preservation: created new database-builder tool (merges
region-specific databases with boards)
- icarus: support new, external database format
(~/.config/icarus/Database/(Super Famicom.bml, ...)
- added 1A3B-(10,11,12); 1A3B-20
byuu says about r14:
r14 work:
I successfully created mappings for every board used in the US set.
I also updated icarus' heuristics to use the new mappings, and
created ones there for the boards that are only in the JP set.
Then I patched icarus to support pulling games out of the database
when it's used on a game folder to generate a manifest file.
Then I updated a lot of code in higan/sfc to support the new mapping
syntax. sfc/cartridge/markup.cpp is about half the size it used to
be with the new mappings, and I was able to kill off both map/id and
map/select entirely.
Then I updated all four emulated systems (and both subsystems) to
use "board" as the root node, and harmonized their syntax (made them
all more consistent with each other.)
Then I added a manifest viewer to the tools window+menu. It's kind
of an advanced user feature, but oh well. No reason to coddle people
when the feature is very useful for developers. The viewer will show
all manifests in order when you load multi-cart games as well.
Still not going to call any syntax 100% done right now, but
thankfully with the new manifest-free folders, nobody will have to
do anything to use the new format. Just download the new version and
go.
The Super Famicom Event stuff is currently broken (CC92/PF94
boards). That's gonna be fun to support.
byuu says about r15:
EDIT: small bug in icarus with heuristics. Edit
core/super-famicom.cpp line 27:
if(/*auto*/ markup = cartridge.markup) {
Gotta remove that "auto" so that it returns valid markup.
Resolved the final concerns I had with the new manifest format.
Right now there are two things that are definitely broken: MCC (BS-X
Town cart) and Event (CC '92 and PF'94).
And there are a few things that are untested: SPC7110, EpsonRTC,
SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
|
|
|
Tim Allen
|
bb3c69a30d |
Update to v094r25 release.
byuu says: Windows port should run mostly well now, although exiting fullscreen breaks the application in a really bizarre way. (clicking on the window makes it sink to background rather than come to the foreground o_O) I also need to add the doModalChange => audio.clear() thing for the accursed menu stuttering with DirectSound. I also finished porting all of the ruby drivers over to the newer API changes from nall. Since I can't compile the Linux or OS X drivers, I have no idea if there are any typos that will result in compilation errors. If so, please let me know where they're at and I'll try and fix them. If they're simple, please try and fix them on your end to test further if you can. I'm hopeful the udev crash will be gone now that nall::string checks for null char* values passed to its stringify function. Of course, it's a problem it's getting a null value in the first place, so it may not work at all. If you can compile on Linux (or by some miracle, OS X), please test each video/audio/input driver if you don't mind, to make sure there's no "compiles okay but still typos exist" bugs. |
|
|
Tim Allen
|
4e0223d590 |
Update to v094r20 release.
byuu says: Main reason for this WIP was because of all the added lines to hiro for selective component disabling. May as well get all the diff-noise apart from code changes. It also merges something I've been talking to Cydrak about ... making nall::string::(integer,decimal) do built-in binary,octal,hex decoding instead of just failing on those. This will have fun little side effects all over the place, like being able to view a topic on my forum via "forum.byuu.org/topic/0b10010110", heh. There are two small changes to higan itself, though. First up, I fixed the resampler ratio when loading non-SNES games. Tested and I can play Game Boy games fine now. Second, I hooked up menu option hiding for reset and controller selection. Right now, this works like higan v094, but I'm thinking I might want to show the "Device -> Controller" even if that's all that's there. It kind of jives nicer with the input settings window to see the labels there, I think. And if we ever do add more stuff, it'll be nice that people already always expect that menu there. Remaining issues: * add slotted cart loader (SGB, BSX, ST) * add DIP switch selection window (NSS) * add timing configuration (video/audio sync) |
|
|
Tim Allen
|
a512d14628 |
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. |