mirror of https://github.com/bsnes-emu/bsnes.git
18 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
Tim Allen | 8bbbc5e737 |
Update to v106r21 release.
byuu says: Changelog: - higan: target-tomoko has been renamed to target-higan - Super Famicom: event has been renamed to processor(architecture=uPD78214) - Super Famicom: SNES-EVENT supported once more; under board IDs EVENT-CC92 and EVENT-PF94 - Super Famicom: SNES-EVENT preliminarily set up to use DIP switch settings ala the Nintendo Super System (incomplete) - Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable - Super Famicom: MCC emulation rewritten from scratch; it is now vastly more accurate than before - Super Famicom: added BSC-1A5B9P-01 board definition to database; corrected BS-MCC-RAM board definition - Super Famicom: moved SHVC-LN3B-01 RAM outside of processor(identifier=SDD1) - higan: when selecting a default game to load for a new system entry, it will change the system option to match the media type - higan: the load text box on the system entry window is now editable; can be used to erase entries - icarus: fixed bug in Famicom importing - icarus: importing unappended SNES coprocessor firmware will now rename the firmware properly - hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so applications should show “higan”, “icarus” instead of “hiro” now Note: if you wish to run the BS-X town cartridge, the database currently lists the download RAM as type “PSRAM”. This needs to be changed to “RAM” in order to load properly. Otherwise, the emulator will bomb out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be present, but it won't find it with the wrong memory type. I'll correct this in the database in a later release. For now, you can copy the game portion of the manifest to a new manifest.bml file and drop it into the gamepak folder until I fix the database. |
|
Tim Allen | 2f81b5a3e7 |
Update to v106r2 release.
byuu says: Changelog: - Super Famicom: added support for loading manifests without embedded mapping information¹ - genius: initial commit - various Makefile cleanups ¹: so the idea here is to try and aim for a stable manifest format, and to allow direct transposition of icarus/genius database entries into manifest files. The exact mechanics of how this is going to work is currently in flux, but we'll get there. For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw database from my board-editor tool, and higan itself tries to load `boards.bml`, match an entry to game/board from the game's `manifest.bml` file, and then transform it into the format currently used by higan. It does this only when the game's `manifest.bml` file lacks a board node. When such a board node exists, it works as previous versions of higan did. The only incompatible change right now is information/title is now located at game/label. I may transition window title display to just use the filenames instead. Longer term, some thought is going to need to go into the format of the `boards.bml` database itself, and at which point in the process I should be transforming things. Give it time, we'll refine this into something nicer. |
|
Tim Allen | f8e71b50d0 |
Update to v105 release.
byuu says: This release provides several major improvements to Mega Drive emulation which enhances compatibility a good deal. It also includes important Super Famicom mosaic emulation improvements, plus a much-needed SuperFX save state issue fix. Changelog (since v104): - higan: many improvements to Emulator::Interface to support forks/frontends - higan: refreshed program icon - icarus: new program icon - Game Boy Advance: slight emulation speedup over v104 - Game Boy Advance: synchronize APU FIFO updates better - Mega Drive: added automatic region detection [hex_usr] - Mega Drive: support 8-bit SRAM - Game Boy Advance: fixed bug when changing to THUMB mode via MSR [MerryMage] - Master System: fix bug in backdrop color and background 0 priority [hex_usr] - Mega Drive: backgrounds always update output priority bit [Cydrak] - Mega Drive: emulated interlaced video output - Mega Drive: emulated shadow/highlight mode [Cydrak] - Super Famicom: auto joypad polling clears the shift register when starting - Super Famicom: added new low-entropy RAM initialization mode to more closely match hardware - Game Boy Advance: rumble will now time out after being left on for 500ms - ruby: improved rumble support in udev input driver [ma_rysia] - M68K: `move.b (a7)[+/-]` adjust a7 by two - M68K: illegal/lineA/lineF opcodes do not modify the stack register - Mega Drive: emulate VIP status bit - uPD7725: improved emulation of OV1/S1 flags [byuu, AWJ, Lord Nightmare] - uPD7725: improved handling of DP, RP updates [Jonas Quinn] - Super Famicom: improved emulation of mosaic effects in hires, interlace, and offset-per-tile modes [byuu, Cydrak] - ruby: improved Direct3D exclusive mode monitor selection [Cydrak] - Super Famicom: fixed save state bug affecting SuperFX games [Cydrak] - Mega Drive: added workaround for Clang compiler bug; allowing this core to work on macOS [Cydrak, Sintendo] - higan: hotkeys now also trigger when the main window lacks focus yet higan is set to allow input on focus loss - higan: fixed an edge case where `int16_t` ↔ `double` audio conversion could possibly result in overflows - higan: fixed a crash on macOS when choosing quit from the application menu [ncbncb] Changelog (since the previous WIP): - higan: restored `make console=true` - tomoko: if you allow input when main window focus is lost, hotkeys can now be triggered without focus as well - hiro/cocoa: fix crash on exit from menu [ncbncb] - ruby: smarter `double` → `int16_t` conversion to prevent underflow/overflow |
|
Tim Allen | fbc58c70ae |
Update to v104r14 release.
byuu says: Changelog: - Emulator::Interface::videoResolution() -\> VideoResolution renamed to videoInformation() -\> VideoInformation - added double VideoInformation::refreshRate - higan: added `binary := (application|library)` — set this to `library` to produce a dynamic link library - higan: removed `-march=native` for macOS application builds; and for all library builds - higan: removed `console` build flag; uncomment `link += -mwindows` instead - nall/GNUmakefile: `macosx` platform renamed `macos` - still need to do this for nall/intrinsics.hpp - Game Gear: return region=NTSC as the only option, so that the system frequency is always set correctly - hiro/cocoa: fixed typo [Sintendo] - hiro/Windows: removed GetDpiForMonitor, as it's Windows 8+ only; DPI is no longer per-monitor aware - icarus: core Icarus class now has virtual functions for directory::create, <file::exists>, <file::copy>, <file::write> - icarus: Sufami Turbo can import save RAM files now - icarus: setting `ICARUS_LIBRARY` define will compile icarus without main(), GUI components - ruby/video/Direct3D: choose the current monitor instead of top-left monitor for fullscreen exclusive [Cydrak] - ruby/video/Direct3D: do not set `WS_EX_TOPMOST` on fullscreen exclusive window [Cydrak] - this isn't necessary for exclusive mode, and it just makes getting out of the application more difficult |
|
Tim Allen | 1ff315838e |
Update to v104r13 release.
byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start. |
|
Tim Allen | fa6cbac251 |
Update to v102r06 release.
byuu says: Changelog: - added higan/emulator/platform.hpp (moved out Emulator::Platform from emulator/interface.hpp) - moved gmake build paramter to nall/GNUmakefile; both higan and icarus use it now - added build=profile mode - MD: added the region select I/O register - MD: started to add region selection support internally (still no external select or PAL support) - PCE: added cycle stealing when reading/writing to the VDC or VCE; and when using ST# instructions - PCE: cleaned up PSG to match the behavior of Mednafen (doesn't improve sound at all ;_;) - note: need to remove loadWaveSample, loadWavePeriod - HuC6280: ADC/SBC decimal mode consumes an extra cycle; does not set V flag - HuC6280: block transfer instructions were taking one cycle too many - icarus: added code to strip out PC Engine ROM headers - hiro: added options support to BrowserDialog The last one sure ended in failure. The plan was to put a region dropdown directly onto hiro::BrowserDialog, and I had all the code for it working. But I forgot one important detail: the system loads cartridges AFTER powering on, so even though I could technically change the system region post-boot, I'd rather not do so. So that means we have to know what region we want before we even select a game. Shit. |
|
Tim Allen | bf70044edc |
Update to v102r05 release.
byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun. |
|
Tim Allen | bf90bdfcc8 |
Update to v101r31 release.
byuu says: Changelog: - converted Emulator::Interface::Bind to Emulator::Platform - temporarily disabled SGB hooks - SMS: emulated Game Gear palette (latching word-write behavior not implemented yet) - SMS: emulated Master System 'Reset' button, Game Gear 'Start' button - SMS: removed reset() functionality, driven by the mappable input now instead - SMS: split interface class in two: one for Master System, one for Game Gear - SMS: emulated Game Gear video cropping to 160x144 - PCE: started on HuC6280 CPU core—so far only registers, NOP instruction has been implemented Errata: - Super Game Boy support is broken and thus disabled - if you switch between Master System and Game Gear without restarting, bad things happen: - SMS→GG, no video output on the GG - GG→SMS, no input on the SMS I'm not sure what's causing the SMS\<-\>GG switch bug, having a hard time debugging it. Help would be very much appreciated, if anyone's up for it. Otherwise I'll keep trying to track it down on my end. |
|
Tim Allen | e30780bb72 |
Update to v101r25 release.
byuu says: Changelog: - Makefile: added $(windres), -lpthread to Windows port - GBA: WAITCNT.prefetch is not writable (should fix Donkey Kong: King of Swing) \[endrift\] - SMS: fixed hcounter shift value \[hex\_usr\] - SMS: emulated interrupts (reset button isn't hooked up anywhere, not sure where to put it yet) This WIP actually took a really long time because the documentation on SMS interrupts was all over the place. I'm hoping I've emulated them correctly, but I honestly have no idea. It's based off my best understanding from four or five different sources. So it's probably quite buggy. However, a few interrupts fire in Sonic the Hedgehog, so that's something to start with. Now I just have to hope I've gotten some games far enough in that I can start seeing some data in the VDP VRAM. I need that before I can start emulating graphics mode 4 to get some actual screen output. Or I can just say to hell with it and use a "Hello World" test ROM. That'd probably be smarter. |
|
Tim Allen | f48b332c83 |
Update to v099r08 release.
byuu says: Changelog: - nall/vfs work 100% completed; even SGB games load now - emulation cores now call load() for the base cartridges as well - updated port/device handling; portmask is gone; device ID bug should be resolved now - SNES controller port 1 multitap option was removed - added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp VRAM::size=0x10000; to enable) Overall, nall/vfs was a huge success!! We've substantially reduced the amount of boilerplate code everywhere, while still allowing (even easier than before) support for RAM-based game loading/saving. All of nall/stream is dead and buried. I am considering removing Emulator::Interface::Medium::id and/or bootable flag. Or at least, doing something different with it. The values for the non-bootable GB/BS/ST entries duplicate the ID that is supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use this as the hardware revision selection ID, and then gut non-bootable options. There's really no reason for that to be there. I think at one point I was using it to generate library tabs for non-bootable systems, but we don't do that anymore anyway. Emulator::Interface::load() may not need the required flag anymore ... it doesn't really do anything right now anyway. I have a few reasons for having the cores load the base cartridge. Most importantly, it is going to enable a special mode for the WonderSwan / WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's possible to boot these systems with no games inserted to set user profile information and such. There are also other systems that may accept being booted without a cartridge. To reach this state, you would load a game and then cancel the load dialog. Right now, this results in games not loading. The second reason is this prevents nasty crashes when loading fails. So if you're missing a required manifest, the emulator won't die a violent death anymore. It's able to back out at any point. The third reason is consistency: loading the base cartridge works the same as the slot cartridges. The fourth reason is Emulator::Interface::open(uint pathID) values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This complicated things because you had to pass the correct ID. But now instead, Emulator::Interface::load() returns maybe<uint> that is nothing when no game is selected, and a pathID for a valid game. And now open() can take this ID to access this game's folder contents. The downside, which is temporary, is that command-line loading is currently broken. But I do intend on restoring it. In fact, I want to do better than before and allow multi-cart booting from the command-line by specifying the base cartridge and then slot cartridges. The idea should be pretty simple: keep a queue of pending filenames that we fill from the command-line and/or drag-and-drop operations on the main window, and then empty out the queue or prompt for load dialogs from the UI when booting a system. This also might be a bit more unorthodox compared to the traditional emulator design of "loadGame(filename)", but ... oh well. It's easy enough still. The port/device changes are fun. We simplified things quite a bit. The portmask stuff is gone entirely. While ports and devices keep IDs, this is really just sugar-coating so UIs can use for(auto& port : emulator->ports) and access port.id; rather than having to use for(auto n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... }; but they should otherwise generally be identical to the order they appear in their respective ranges. Still, don't rely on that. Input::id is gone. There was no point since we also got rid of the nasty Input::order vector. Since I was in here, I went ahead and caved on the pedantics and renamed Input::guid to Input::userData. I removed the SNES controller port 1 multitap option. Basically, the only game that uses this is N-warp Daisakusen and, no offense to d4s, it's not really a good game anyway. It's just a quick demo to show 8-players on the SNES. But in the UI, all it does is confuse people into wasting time mapping a controller they're never going to use, and they're going to wonder which port to use. If more compelling use cases for 8-players comes about, we can reconsider this. I left all the code to support this in place, so all you have to do is uncomment one line to enable it again. We now have dsnes emulation! :D If you change PPU::VRAM::size to 0x10000 (words), then you should now have 128KiB of VRAM. Even better, it serializes the used-VRAM size, so your save states shouldn't crash on you if you swap between the two (though if you try this, you're nuts.) Note that this option does break commercial software. Yoshi's Island in particular. This game is setting A15 on some PPU register writes, but not on others. The end result of this is things break horribly in-game. Also, this option is causing a very tiny speed hit for obvious reasons with the variable masking value (I'm even using size-1 for now.) Given how niche this is, I may just leave it a compile-time constant to avoid the overhead cost. Otherwise, if we keep the option, then it'll go into Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future. ---- Finally, some fun for my OCD ... my monitor suddenly cut out on me in the middle of working on this WIP, about six hours in of non-stop work. Had to hit a bunch of ctrl+alt+fN commands (among other things) and trying to log in headless on another TTY to do issue commands, trying to recover the display. Finally power cycled the monitor and it came back up. So all my typing ended up going to who knows where. Usually this sort of thing terrifies me enough that I scrap a WIP and start over to ensure I didn't screw anything up during the crashed screen when hitting keys randomly. Obviously, everything compiles and appears to work fine. And I know it's extremely paranoid, but OCD isn't logical, so ... I'm going to go over every line of the 100KiB r07->r08 diff looking for any corruption/errors/whatever. ---- Review finished. r08 diff review notes: - fc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - gb/cartridge/cartridge.hpp: remove redundant uint _pathID; (in Information::pathID already) - gb/cartridge/cartridge.hpp: pull sha256 inside Information - sfc/cartridge/load/cpp: add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more descriptive - sfc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - sfc/interface/interface.cpp: remove n variable from the Multitap device input generation loop (now unused) - sfc/interface/interface.hpp: put struct Port above struct Device like the other classes - ui-tomoko: cheats.bml is reading from/writing to mediumPaths(0) [system folder instead of game folder] - ui-tomoko: instead of mediumPaths(1) - call emulator->metadataPathID() or something like that |
|
Tim Allen | 7f3cfa17b9 |
Update to v098r12 release.
byuu says: Changelog: - higan/video: added support for Emulator::Sprite - higan/resource: a new system for accessing embedded binary files inside the emulation cores; holds the sprites - higan/sfc/superscope,justifier: re-enabled display of crosshairs - higan/sfc/superscope: fixed turbo toggle (also shows different crosshair color when in turbo mode) - higan/sfc/ppu: always outputs at 512x480 resolution now - causes a slight speed-hit from ~127fps to ~125fps; - but allows high-resolution 32x32 cursors that look way better; - also avoids the need to implement sprite scaling logic Right now, the PPU code to always output at 480-height is a really gross hack. Don't worry, I'll make that nicer before release. Also, superscope.cpp and justifier.cpp are built around a 256x240 screen. But since we now have 512x480, we can make the cursor's movement much smoother by doubling the resolution on both axes. The actual games won't see any accuracy improvements when firing the light guns, but the cursors will animate nicer so I think it's still worth it. I'll work on that before the next release as well. The current 32x32 cursors are nicer, but we can do better now with full 24-bit color. So feel free to submit alternatives. I'll probably reject them, but you can always try :D The sprites don't support alpha blending, just color keying (0x00000000 = transparent; anything else is 0xff......). We can revisit that later if necessary. The way I have it designed, the only files that do anything with Emulator::Sprite at all are the superscope and justifier folders. I didn't have to add any hooks anywhere else. Rendering the sprite is a lot cleaner than the old code, too. |
|
Tim Allen | e2ee6689a0 |
Update to v098r06 release.
byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad. |
|
Tim Allen | 19e1d89f00 |
Update to v098r01 release.
byuu says: Changelog: - SFC: balanced profile removed - SFC: performance profile removed - SFC: code for handling non-threaded CPU, SMP, DSP, PPU removed - SFC: Coprocessor, Controller (and expansion port) shared Thread code merged to SFC::Cothread - Cothread here just means "Thread with CPU affinity" (couldn't think of a better name, sorry) - SFC: CPU now has vector<Thread*> coprocessors, peripherals; - this is the beginning of work to allow expansion port devices to be dynamically changed at run-time - ruby: all audio drivers default to 48000hz instead of 22050hz now if no frequency is assigned - note: the WASAPI driver can default to whatever the native frequency is; doesn't have to be 48000hz - tomoko: removed the ability to change the frequency from the UI (but it will display the frequency used) - tomoko: removed the timing settings panel - the goal is to work toward smooth video via adaptive sync - the model is broken by not being in control of the audio frequency anyway - it's further broken by PAL running at 50hz and WSC running at 75hz - it was always broken anyway by SNES interlace timing varying from progressive timing - higan: audio/ stub created (for now, it's just nall/dsp/ moved here and included as a header) - higan: video/ stub created - higan/GNUmakefile: now includes build rules for essential components (libco, emulator, audio, video) The audio changes are in preparation to merge wareya's awesome WASAPI work without the need for the nall/dsp resampler. |
|
Tim Allen | 7dc62e3a69 |
Update to v097r19 release.
byuu says: Changelog: - fixed nall/windows/guard.hpp - fixed hiro/(windows,gtk)/header.hpp - fixed Famicom PPU OAM reads (mask the correct bits when writing) [hex_usr] - removed the need for (system := system) lines from higan/GNUmakefile - added "All" option to filetype dropdown for ROM loading - allows loading GBC games in SGB mode (and technically non-GB(C) games, which will obviously fail to do anything) - loki can load and play game folders now (command-line only) (extremely unimpressive; don't waste your time :P) - the input is extremely hacked in as a quick placeholder; not sure how I'm going to do mapping yet for it |
|
Tim Allen | fc7d5991ce |
Update to v097r18 release.
byuu says: Changelog: - fixed SNES sprite priority regression from r17 - added nall/windows/guard.hpp to guard against global namespace pollution (similar to nall/xorg/guard.hpp) - almost fixed Windows compilation (still accuracy profile only, sorry) - finished porting all of gba/ppu's registers over to the new .bit,.bits format ... all GBA registers.cpp files gone now - the "processors :=" line in the target-$(ui)/GNUmakefile is no longer required - processors += added to each emulator core - duplicates are removed using the new nall/GNUmakefile's $(unique) function - SFC core can be compiled without the GB core now - "-DSFC_SUPERGAMEBOY" is required to build in SGB support now (it's set in target-tomoko/GNUmakefile) - started once again on loki (higan/target-loki/) [as before, loki is Linux/BSD only on account of needing hiro::Console] loki shouldn't be too horrendous ... I hope. I just have the base skeleton ready for now. But the code from v094r08 should be mostly copyable over to it. It's just that it's about 50KiB of incredibly tricky code that has to be just perfect, so it's not going to be quick. But at least with the skeleton, it'll be a lot easier to pick away at it as I want. Windows compilation fix: move hiro/windows/header.hpp line 18 (header guard) to line 16 instead. |
|
Tim Allen | d7998b23ef |
Update to v097r03 release.
byuu says: So, this WIP starts work on something new for higan. Obviously, I can't keep it a secret until it's ready, because I want to continue daily WIP releases, and of course, solicit feedback as I go along. |
|
Tim Allen | cec33c1d0f |
Update to v096r07 release.
byuu says: Changelog: - configuration files are now stored in localpath() instead of configpath() - Video gamma/saturation/luminance sliders are gone now, sorry - added Video Filter->Blur Emulation [1] - added Video Filter->Scanline Emulation [2] - improvements to GBA audio emulation (fixes Minish Cap) [Jonas Quinn] [1] For the Famicom, this does nothing. For the Super Famicom, this performs horizontal blending for proper pseudo-hires translucency. For the Game Boy, Game Boy Color, and Game Boy Advance, this performs interframe blending (each frame is the average of the current and previous frame), which is important for things like the GBVideoPlayer. [2] Right now, this only applies to the Super Famicom, but it'll come to the Famicom in the future. For the Super Famicom, this option doesn't just add scanlines, it simulates the phosphor decay that's visible in interlace mode. If you observe an interlaced game like RPM Racing on a real SNES, you'll notice that even on perfectly still screens, the image appears to shake. This option emulates that effect. Note 1: the buffering right now is a little sub-optimal, so there will be a slight speed hit with this new support. Since the core is now generating native ARGB8888 colors, it might as well call out to the interface to lock/unlock/refresh the video, that way it can render directly to the screen. Although ... that might not be such a hot idea, since the GBx interframe blending reads from the target buffer, and that tends to be a catastrophic option for performance. Note 2: the balanced and performance profiles for the SNES are completely busted again. This WIP took 6 1/2 hours, and I'm exhausted. Very much not looking forward to working on those, since those two have all kinds of fucked up speedup tricks for non-interlaced and/or non-hires video modes. Note 3: if you're on Windows and you saved your system folders somewhere else, now'd be a good time to move them to %localappdata%/higan |
|
Tim Allen | 47d4bd4d81 |
Update to v096r01 release.
byuu says: Changelog: - restructured the project and removed a whole bunch of old/dead directives from higan/GNUmakefile - huge amounts of work on hiro/cocoa (compiles but ~70% of the functionality is commented out) - fixed a masking error in my ARM CPU disassembler [Lioncash] - SFC: decided to change board cic=(411,413) back to board region=(ntsc,pal) ... the former was too obtuse If you rename Boolean (it's a problem with an include from ruby, not from hiro) and disable all the ruby drivers, you can compile an OS X binary, but obviously it's not going to do anything. It's a boring WIP, I just wanted to push out the project structure change now at the start of this WIP cycle. |