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

22 lines
329 B
C++
Raw Normal View History

Update to v082r21 release. byuu says: 2-6% speed hit in SNES core for outputting 19-bit (rounded to 32-bit ... sigh) video, so that luma non-linearity can eventually be emulated properly. Now using sinc audio resampler, massive speed hit of course to NES+GB only, but it's required to get rid of aliasing (buzzing) present in many, many games otherwise. Fixed fast forward and none/blur select. Finally fixed texture clearing for changing pixel shaders and video filters. Some realllly basic NES MMC3, extremely broken so don't bug me about it. Other stuff, probably.
2011-09-24 09:51:08 +00:00
struct Video {
Update to v083r06 release. byuu says: All cores: Video classes have internal->{RGB30,24,16,15} palette generation support All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard) NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak] NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak] Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.) Game Boy Color: fixed freezing bug with Zelda: LA opening (SVBK is readable.) Game Boy Color: more accurate colors (better than GiiBii, probably worse than KiGB) SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now. The current major problems I'd like to solve: - Zelda: Link's Awakening music when Link first wakes up in the house is atrociously bad - Shin Megami Tensei: Devil Children - White Book (Shiro no Sho) plays music at 50% speed; yet Black Book (Kuro no Sho) does not ... one of my favorite games, so it'd be great to fix it
2011-10-27 13:30:19 +00:00
unsigned *palette;
Update to v088r03 release. byuu says: static vector<uint8_t> file::read(const string &filename); replaces: static bool file::read(const string &filename, uint8_t *&data, unsigned &size); This allows automatic deletion of the underlying data. Added vectorstream, which is obviously a vector<uint8_t> wrapper for a data stream. Plan is for all data accesses inside my emulation cores to take stream objects, especially MSU1. This lets you feed the core anything: memorystream, filestream, zipstream, gzipstream, httpstream, etc. There will still be exceptions for link and serial, those need actual library files on disk. But those aren't official hardware devices anyway. So to help with speed a bit, I'm rethinking the video rendering path. Previous system: - core outputs system-native samples (SNES = 19-bit LRGB, NES = 9-bit emphasis+palette, DMG = 2-bit grayscale, etc.) - interfaceSystem transforms samples to 30-bit via lookup table inside the emulation core - interfaceSystem masks off overscan areas, if enabled - interfaceUI runs filter to produce new target buffer, if enabled - interfaceUI transforms 30-bit video to native display depth (24-bit or 30-bit), and applies color-adjustments (gamma, etc) at the same time New system: - all cores now generate an internal palette, and call Interface::videoColor(uint32_t source, uint16_t red, uint16_t green, uint16_t blue) to get native display color post-adjusted (gamma, etc applied already.) - all cores output to uint32_t* buffer now (output video.palette[color] instead of just color) - interfaceUI runs filter to produce new target buffer, if enabled - interfaceUI memcpy()'s buffer to the video card videoColor() is pretty neat. source is the raw pixel (as per the old-format, 19-bit SNES, 9-bit NES, etc), and you can create a color from that if you really want to. Or return that value to get a buffer just like v088 and below. red, green, blue are 16-bits per channel, because why the hell not, right? Just lop off all the bits you don't want. If you have more bits on your display than that, fuck you :P The last step is extremely difficult to avoid. Video cards can and do have pitches that differ from the width of the texture. Trying to make the core account for this would be really awful. And even if we did that, the emulation routine would need to write directly to a video card RAM buffer. Some APIs require you to lock the video buffer while writing, so this would leave the video buffer locked for a long time. Probably not catastrophic, but still awful. And lastly, if the emulation core tried writing directly to the display texture, software filters would no longer be possible (unless you -really- jump through hooks and divert to a memory buffer when a filter is enabled, but ... fuck.) Anyway, the point of all that work was to eliminate an extra video copy, and the need for a really painful 30-bit to 24-bit conversion (three shifts, three masks, three array indexes.) So this basically reverts us, performance-wise, to where we were pre-30 bit support. [...] The downside to this is that we're going to need a filter for each output depth. Since the array type is uint32_t*, and I don't intend to support higher or lower depths, we really only need 24+30-bit versions of each filter. Kinda shitty, but oh well.
2012-04-27 12:12:53 +00:00
void generate_palette();
Update to v083r06 release. byuu says: All cores: Video classes have internal->{RGB30,24,16,15} palette generation support All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard) NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak] NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak] Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.) Game Boy Color: fixed freezing bug with Zelda: LA opening (SVBK is readable.) Game Boy Color: more accurate colors (better than GiiBii, probably worse than KiGB) SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now. The current major problems I'd like to solve: - Zelda: Link's Awakening music when Link first wakes up in the house is atrociously bad - Shin Megami Tensei: Devil Children - White Book (Shiro no Sho) plays music at 50% speed; yet Black Book (Kuro no Sho) does not ... one of my favorite games, so it'd be great to fix it
2011-10-27 13:30:19 +00:00
Video();
~Video();
Update to 20100809 release. byuu says: This adds some sync.sh improvements to make it handle errors more gracefully. It also updates asnes a good bit. All of the four base processors now have all publicly accessible functions right at the top of the main headers, and everything else is private. This is to allow these headers to essentially take the place of the previous base classes in the old bsnes-merged format. So if there's something public there, you need to implement that exact function to make your own module. I removed the frame counter from the PPU, as it has nothing to do with emulation. That now resides inside the Qt -> SNES interface code. Quite amazing, I was actually saving the frame counter into the save state files before, yuck. Removed some baggage in the System class: it was friending a bunch of long-dead functions and classes. Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put back.
2010-08-09 13:33:44 +00:00
private:
Update to v078 release. byuu says: Finally, a new release. I have been very busy finishing up SNES box, cartridge and PCB scanning plus cataloguing the data, however this release still has some significant improvements. Most notably would be randomization on startup. This will help match the behavior of real hardware and uninitialized memory + registers. It should help catch homebrew software that forgets to initialize things properly. Of course, I was not able to test the complete library, so it is possible that if I've randomized anything that should be constant, that this could cause a regression. You can disable this randomization for netplay or to work around any incompatibilities by editing bsnes.cfg and setting snes.random to false. The GUI also received some updates. Widget sizes are now computed based on font sizes, giving it a perfectly native look (because it is native.) I've also added a hotkey remapping screen to the input settings. Not only can you remap inputs to controllers now, but those who did not know the hotkey bindings can now quickly see which ones exist and what they are mapped to. Changelog (since v077): - memory and most registers are now randomly initialized on power-up - fixed auto joypad polling issue in Super Star Wars - fixed .nec and .rtc file extensions (they were missing the dot) [krom] - PPU/accuracy now clears overscan region on any frame when it is disabled - PPU/compatibility no longer auto-blends hires pixels (use NTSC filter for this) - added hotkey remapping dialog to input settings window - added a few new hotkeys, including quick-reset - phoenix API now auto-sizes widgets based on font sizes - file dialog once again remembers previously selected file when possible
2011-04-30 13:12:15 +00:00
bool hires;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
unsigned line_width[240];
void update();
void scanline();
void init();
static const uint8_t cursor[15 * 15];
void draw_cursor(uint16_t color, int x, int y);
friend class System;
};
extern Video video;