bsnes/higan/resource/GNUmakefile

all:
	sourcery resource.bml resource.cpp resource.hpp

clean:
	rm resource.cpp
	rm resource.hpp
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. 2016-05-26 11:20:15 +00:00			`all:`
			`sourcery resource.bml resource.cpp resource.hpp`
Update to v104r10 release. byuu says: Changelog: - processor/upd96050: per manual errata note, SGN always uses SA1; never SB1 [fixes v104r09 regression] - processor/upd96050: new OV1/S1 calculation that doesn't require OV0 history buffer [AWJ] - processor/upd96050: do not update DP in OP if DST=4 [Jonas Quinn] - processor/upd96050: do not update RP in OP if DST=5 [Jonas Quinn] - resource: recreated higan+icarus icons, higan logo as 32-bit PNGs So higan v104r08 and earlier were 930KiB for the source tarball. After creating new higan and icarus icons, the size jumped to 1090KiB, which was insane for only adding one additional icon. After digging into why, I discovered that ImageMagick defaults to 64-bit!! (16-bits per channel) PNG images when converting from SVG. You know, for all those 16-bit per channel monitors that don't exist. Sigh. Amazingly, nobody ever noticed this. The logo went from 78.8KiB to 24.5KiB, which in turn also means the generated resource.cpp shrank dramatically. The old higan icon was 32-bit PNG, because it was created before I installed FreeBSD and switched to ImageMagick. But the new higan icon, plus the new icarus icon, were both 64-bit as well. And they're now 32-bit. So the new tarball size, thanks to the logo optimization, dropped to 830KiB. Cydrak had some really interesting results in converting higan's resources to 8-bit palletized PNGs with the tRNS extension for alpha transparency. It reduces the file sizes even more without much visual fidelity loss. Eg the higan logo uses 778 colors currently, and 256 represents nearly all of it very well to the human eye. It's based off of only two colors, the rest are all anti-aliasing. Unfortunately, nall/image doesn't support this yet, and I didn't want to flatten the higan logo to not have transparency, in case I ever want to change the about screen background color. 2017-09-01 11:21:06 +00:00
			`clean:`
			`rm resource.cpp`
			`rm resource.hpp`