Wiimm had been analysing the Mario Kart Wii network traffic since November 2012 and had already written a helper tool named MKW-ANA. And so he decided to get together with Leseratte and other people to create the Wii-Server Project, known as "Wiimmfi" to replace Nintendo's servers for Mario Kart Wii and for other games if they were to have been shutdown.
Mednafen (an acronym for "My Emulator Doesn't Need A Frickin' Excellent Name") is a portable, utilizing OpenGL and SDL, argument(command-line)-driven multi-system emulator with support for following systems: Atari Lynx, Neo Geo Pocket (Color), WonderSwan, GameBoy (Color), GameBoy Advance, Nintendo Entertainment System, Super Nintendo Entertainment System/Super Famicom, Virtual Boy, PC Engine/TurboGrafx 16 (CD), SuperGrafx, PC-FX, Sega Game Gear, Sega Genesis/Megadrive, Sega Master System, Sony PlayStation. The emulator runs under Microsoft Windows, Linux, PlayStation 3, RISC OS, and Wii.
Here's changelog from latest build:
SNES:
+ Save extra input device state in save states that the bsnes core fails to save.
+ Removed computationally-expensive and unnecessary (it's already done in the state load code path) duplicate-variable check debug code in the save state saving code.
+ Hooked up Super Scope emulation.
PCE_FAST:
+ Removed debug puts() in VPC mixing inner loop, and added compiler hints to some of the rendering and mixing loops.
+ Fixed an ancient regression introduced around version 0.9.16-WIP. Said regression caused the file extension of the save state used by the auto save state save/load feature(setting "autosave") to be the same as the extension used for the currently selected save state slot, effectively overwriting that save state slot on exit.
+ Added setting "video.disable_composition", to allow the user to override Mednafen's default behavior of disabling desktop composition on Windows Vista and Windows 7.
MD:
+ Fixed a 68K emulation regression introduced in 0.9.34, that broke save game loading in "Sonic the Hedgehog 3", and possibly broke other games in subtle ways.
+ Fixed prototype for cart mapper 16-bit write function.
+ Cleaned up debug printf()s.
PSX, PCE, MD, CDPLAY:
+ Resolved a few compiler warnings.
PC-FX:
+ Fixed an old bug that, when coupled with changes made in 0.9.35, caused low-volume crackling in the CD-DA sound output.
Check out Projects website for further information and latest files.
Hoxs64 is a Commodore 64 emulator for Microsoft Windows XP / 7. The emulator substantially reproduces this legacy machine in minute detail. Emulator features: a cycle based CPU, VIC, CIA and SID; suport for 1541 Disk drive and Tape deck; proper emulation of all screen effects; support for .TAP, .PRG, P00, D64 files... and bulid-in disassembler.
Here's changelog for 1.0.8.7 releases:
1) Resizable main window for windowed mode.
2) Fix Ultimax VIC fetch.
Check out official homepage for further information and latest files.
ePSXe for Android is a Playstation emulator (PSX and PSOne). It is a port from the famous ePSXe for PC. ePSXe provides high compatibility and good speed. It is designed for smartphones and tablets, including a fun 2 players option for tablets using split screen mode. Games must be provided by user. Include virtual touchscreen pad support, and hardware buttons mapping (Xperia Play, Phones with keyboard, and external pads like WiiMote or Sixaxis).
Here`s list of changes for latest version:
* Updated OpenGL plugin - better Adreno 320+ support and faster (http://epsxe.com/files/libopenglpluginv2.so)
* Added a new video renderer with FXAA filter (prefs>video renderer=fxaa)
* Added a flag in prefs to enable more accurate graphics
* Added DualShock vibration support (enable on prefs)
* Mapped left stick to dpad in digital mode
* Fixed a crash when scanning games
* Fixed Digimon 3 freeze during battle
* Fixed open menu in Android 3.2
Mario Maker.
Nintendo has decided to release their own user-end version of the Reggie tool!
Mario Maker (working title) offers up a Super Mario Bros. dream: the ability for players to use the Wii U GamePad to design levels from scratch. Place blocks and enemies anywhere and play through the level. With the tap of an icon, users can even switch the visual style between a classic 8-bit Super Mario Bros. look and the world of New Super Mario Bros. U in the E3 version. The game is scheduled for the first half of 2015.
-mynintendonews.com
EMU7800 is an Atari 7800 emulator implemented using Microsoft's .NET platform. Most VCS (2600) and ProSystem (7800) titles work well, with 2600 support featuring authentic HMOVE emulation. EMU7800 runs on Windows XP SP3 and higher systems. Performance is excellent on current hardware.
Changelog for v1.7:
+ Increased joystick deadzone to make Xbox 360 wireless controllers usable under Windows 8.1
+ Added the ability to swap input jacks via the W key
+ No changes to the core emulation library
+ No changes to EMU7800 Classic
puNES (ex Fnes) is an emulator under development that works on Linux32/64 and Windows32. It needs of SDL library to run.
Here's relase info for latest version:
I continued to work hard on the synchronization between CPU/PPU and CPU/APU to make it more accurate. Now "Micro Machines (Camerica) [!]. nes" works without any graphical glitches also "Huge Insect (Sachen) [!].nes" finally works perfectly (viewtopic.php?f=3&t=465). Considering that the changes affecting the core of the emulator, I have tested many roms (tests and games) and it seems that everything is running smoothly, but if someone were to find some roms that gives problems with this release, please contact me. Thanks to x0000 for the help on the front of the CPU/APU.
Fixed some bugs in the handling of compressed files with the game genie active (thx Chad).
FPse for Android is a program designed to run PlayStation One games on devices running Android Operating System 2.1 to 4.x and up.
FPse For Android contains many features included : Real-time save/load state, Force Feedback emulation (vibration) and True overlay pad widgets that emulate Digital Pads as well as Analog Pads.
Chere's changelog for latest build:
- Added new shaders 5xbR and 4XHQ
- Shaders can now be changed while playing games
- Fixed L2 and R2 mapping on shield
- New OpenGL plugin, much more optimized, faster and more compatible
Visit Google Play app page for further information and latest version of emulator.
Wine enables Linux, Mac, FreeBSD, and Solaris users to run Windows applications without a copy of Microsoft Windows. Wine features: support for running Win64, Win32, Win16 and DOS programs, optional use of external vendor DLL files, X11-based graphics display and X terminal remote display, DirectX support for games, good support for various sound drivers, support for alternative input devices, PostScript printing, modem, serial device and winsock TCP/IP networking support, full-featured debugger and configurable trace logging messages.
Heres's condensed changelog for latest development build:
- New JSProxy DLL for automatic proxy configuration.
- More OLE Accessible Object support.
- Improvements to the XML writer.
- Fixes for various memory issues found by Valgrind.
- Initial headers for Direct2D support.
- Various bug fixes.
Visit official website for further information and latest files.
Mednafen (an acronym for "My Emulator Doesn't Need A Frickin' Excellent Name") is a portable, utilizing OpenGL and SDL, argument(command-line)-driven multi-system emulator with support for following systems: Atari Lynx, Neo Geo Pocket (Color), WonderSwan, GameBoy (Color), GameBoy Advance, Nintendo Entertainment System, Super Nintendo Entertainment System/Super Famicom, Virtual Boy, PC Engine/TurboGrafx 16 (CD), SuperGrafx, PC-FX, Sega Game Gear, Sega Genesis/Megadrive, Sega Master System, Sony PlayStation. The emulator runs under Microsoft Windows, Linux, PlayStation 3, RISC OS, and Wii.
Here's changelog from latest build:
+ Reworked the FPS calculation algorithm to produce more accurate FPS values.
+ Added a manifest file that's embedded into the Windows executable, to ensure that noxious DPI virtualization and scaling available on Windows Vista and newer will not be used with Mednafen.
+ Added code to disable DWM composition when running on pre-Windows 8 systems, to ensure better performance and lessvideo juddering. (Sadly, it's not possible to disable desktop composition in this manner on Windows 8 and later)
+ PCE, PCE_FAST: Added a missing ADPCM playback variable to save states; fixes the problem of severe ADPCM sound distortion when loading save states that are saved during ADPCM playback(especially noticeable with the state rewinding feature).
Check out Projects website for further information and latest files.
DeSmuME X432R (2014/05/10) is compiled.
DeSmuME X432R is a modified version of DeSmuME. DeSmuME is an open source Nintendo DS(NDS) emulator for Linux, Mac OS and Windows. DeSmuME supports save states, the ability to increase the size of the screen and it supports filters to improve image quality.
DeSmuME also supports microphone use on Windows and Linux ports, as well as
direct video and audio recording. The emulator also features a built-in movie recorder.
DeSmuME X432R (2014/05/10) Changelog:
The created based on the official SVN r5038
High resolution 3D rendering (experimental)
Improved internal processing.
Fidelity of the display is improved.
Fixed a bug of the HUD display.
Add Config menu → High-Resolution 3D Renderer → Async Mode
This function is separated from the main thread the part of the drawing process will be executed asynchronously.
There is a screen update is not successful in use.
SuperN64 is a very fast N64 emulator for Android phones.
Play your favorite N64 games on your phone or tablet!
You need to place your own game files onto the SD card before running this N64 Emulator.
SuperN64 is a modified version of the Open Source project Mupen64+, which is licensed by GNU GPL v3. Modifications include performance enhancements for specific Phone Models such as the Nexus 4 and the Galaxy S4 and small UI improvements.
PCSX2 is a PlayStation 2 emulator for Windows and Linux. Project attempts to allow PS2 code to be executed on your computer, thus meaning you can put a PS2 DVD or CD into your computers drive, and boot it up!
Here's relevant changes from latest builds:
pcsx2: improve the GS read fifo API
1/ initReadFifo will be first called on the GS thread (openGL can only be done on the GS thread)
2/ readFifo will be called on the EE thread. It is not safe too access eeMem from GS
because of memory is virtual
Fix "recent" regression (crash) on Kingdom heart and others game too.
pcsx2: try to ensure better sync with FIFO read call
First wait will ensure correctness of GS register.
2nd wait will ensure that the GS fifo read call is finished
gzip-iso: Speedup some cases by using more memory. Significant speedup on some cases by using roughly another index size in ram. The ram usage is now up to roughly cache size plus 2x index size.
This patch adds another index-like direct access point for each span we've visited. This replaces the single z-state which was used for sequential extraction, and does the same, but now it can continue sequentially on most previously visited spans instead of only from the last read.
Visit project homepage for further information and grab the latest build (until the buildbot starts working again) from official thread at PCSX2 forums.
WinUAE is a desinged for Windows program, which emulates the hardware of the Commodore Amiga range of computers. It emulates most of its functions: Original Chip Set (OCS), Enhanced Chip Set (ECS) and Advanced Graphics Architecture (AGA), Motorola 68000/010/020/040 CPU, optionally a 68881 FPU, 2 MB Chip RAM and 8 MB Fast RAM, or 8 MB Chip RAM without Fast RAM. 64 MB Zorro III Fast RAM, independent of Chip RAM setting (68020+ only). 1 MB Slow RAM, for compatibility, Picasso 96 graphics with 8 MB of memory, Serial port, and Simple parallel port is only sufficient for printing. Networking via bsdsocket.library. WinUAE has reasonable compatibility for most software but, just like a "real" Amiga, for some old games it requires careful configuration in order to match the originally-supported hardware.
Here's changelog for latest version:
New features:
- Full A4000T and A4091 NCR53C710 SCSI emulation.
- A590/A2091 and A4091 boot ROM GUI selection.
- Separate graphics filter settings for native and RTG modes.
- 256k ROM image inserted in floppy drive emulates A1000 KICK disk.
- Super Card Pro image file support (.scp).
- SLIRP network inbound port support (default: 21, 22, 23 and 80, others
can be added by editing configuration file)
- Input panel previously toggle-only events can be optionally set to on
and off state, audio/video recording input event added.
- Joystick/joypad can be used to control light pen cursor.
Updates:
- Remaining 68000 cycle-exact mode timing fixes.
- 68000 reading from write-only or non-existing custom register
compatibility improved.
- Big chipset edge case compatibility update, for example demos with
vertical "copper" bars work perfectly, real hardware glitches in
horizontal scaling are now accurately emulated and much more.
- 68040/68060 without emulating unimplemented FPU instructions is now
fully compatible with Motorola FPU emulation library, FSAVE special
FPU exception stack frames implemented.
- Programmed modes (Super72 etc) now automatically select best fit horizontal
resolution and is more compatible with different filter modes, also display
positioning is improved.
- Recently dumped Arcadia arcade system ROM images supported.
- Debugger full FPU and 68020+ bitfield, and other previously missing
68020+ only instructions supported in disassembler.
- Magic mouse + mousehack mode now always stops keyboard input when mouse
is outside of emulation window, even if window still has focus.
Bug fixes:
- Keyboard led indicator state syncronization problems fixed.
- Fixed very rare JIT FPU bug introduced in 1.2.
- Vertical centering works again, improved horizontal centering.
- Full tablet emulation boot guru fixed.
- Graphics glitches in some borderblank and border sprite modes.
- Master floppy write protection setting was not loaded from config file.
- Some narrow AGA modes clipped some pixels from right edge of display.
- A590/A2091 didn't work in all supported CPU modes.
- CPU polled disk reading was unreliable in some situations.
openMSX is an emulator for the MSX home computer system. openMSX is confirmed to run on the following operating systems: Linux, Windows, Mac OS X, FreeBSD, OpenBSD and NetBSD; on x86, x86-64, PPC, ARM, MIPS and Sparc CPU's. Its goal is to emulate all aspects of the MSX with 100% accuracy: perfection in emulation. openMSX has also a built-in command interface called the console, which allows you to control almost all aspects of openMSX while it is running.
Here's list of new or improved emulator features:
MSX device support:
- fixed bug in YM2413 (FMPAC), that was audible in BPS Tetris
- added Sharp/Epcom HB-4000 80 column cartridge extension
New or improved emulator features:
- extended save_msx_screen script to take VDP(24) into acount
- fixed crash on Visual Studio build when using wav files (e.g. in the cassetteplayer)
- fixed crash on 32-bit Visual Studio build when recording videos without the -doublesize option
- fixed crash on 32-bit Visual Studio build when using scale_factor 3 and SDL renderer
- fixed waves shown upside-down in the SCC Viewer OSD widget
- fixed crash when loading a savestate that has JoyTap plugged in
- performance improvements:
+ several improvements that result in shorter start up time
+ fixed reverse-performance when using hard disks
- fixed handling of corrupt hardware configuration XML file
- fixed crash when MSX with TC8566AF FDC (e.g. turboR) crashed
- fixed possible hang up when reversing with harddisks
- fixed Tcl error when changing horizontal stretch in OSD menu
- fixed displaying of error messages on OSD
- Mac OS X MIDI support:
+ fixed MIDI output on Mac OS X (was not working for some applications)
+ added support for running status
+ added support for system realtime messages
+ added support for MIDI in
- fixed issues with on-screen-keyboard on Android 4.4
- added default keybindings for controllers targeted at gaming
- added mapping of B-control button to press CTRL or SHIFT in OSD keyboard
- added fine grained control in which slots carts and extensions will end up
- added support for single sided disk drives for dir-as-disk
- added support for hard disk images to the OSD menu
- added warning if ROM images with larger size than supported on real Konami and Konami SCC mappers are used
Visit official homepage for further information and latest version of emulator.
Wine enables Linux, Mac, FreeBSD, and Solaris users to run Windows applications without a copy of Microsoft Windows. Wine features: support for running Win64, Win32, Win16 and DOS programs, optional use of external vendor DLL files, X11-based graphics display and X terminal remote display, DirectX support for games, good support for various sound drivers, support for alternative input devices, PostScript printing, modem, serial device and winsock TCP/IP networking support, full-featured debugger and configurable trace logging messages.
Heres's condensed changelog for latest development build:
- More implementations for the Task Scheduler.
- C runtime made more compatible by sharing source files.
- Fixes in the Mac OS X joystick support.
- Various bug fixes.
Visit official website for further information and latest files.
Ootake [pronounced oh - ta - ke] is great PC Engine/TurboGrafx16 emulator, with high compatibility, nice GUI and a lot of settings.
- "Power-On Black Screen Effect" menu was added to CPU menu. When this menu is checked, the state of a television at power-on (the screen display passes about one second) is simulated. (default)
- "Configure Sprite&BG Buttons" menu was added to CPU menu. This is a function for the developer. The button (keyboard is also available) that switches non-display of sprite and BG is set.
- With Windows8, the bug that the file dialog occasionally stopped was corrected.
As for the Windows8 environment, the delay of the display (two extra frames with Win7/Vista invalidated Aero case) happens. because the drawing buffer(Aero with win7/vista) was not voidable. If possible, please play with Windows7/Vista/XP when you enjoy an action or a shooting game.
For Windows8.1, I schedule "Direct3D low-latencypresentation API function" of DirectX11.2 to be used in the far future. I want to cancel Input Lag.
- The speed and timing were brought close to the movement of a real machine. In the start demo of "Asuka 120% Maxima", the problem that one frame screen falls into disorder was solved. In the demo of "The Kung-Fu", the problem that the upper part of the screen flickers was solved(reduced. with even real machine it sometimes has the flicker).
- Additionally, a detailed part has been improved and corrected.
+ I began Twitter. (Japanese language) http://twitter.com/kitao_n * The happiness of the game is the world human race commonness. It longs for peace.
* I think that it cannot do improvement & correction of the above-mentioned if there are many neither operation report nor defect report. Thank you really for you who reported.
Check out official website for further information and latest files.
HalfNES is an open-source emulator for the Nintendo Entertainment System, written in Java. Currently, it only runs as a standalone Java SE application and supports: joystick through DirectInput and xInput, SRAM save, accurate sound core, full screen display and cross-platform portability.
Chere's changelog for latest builds:
055
-Added support for NSF music files.
-Added mapper for Super Spike V'Ball/Nintendo World Cup combo cartridge
-Changed sprite DMA timings (fixes Battle Chess again)
054
-Changed NES color palette to match NTSC filter colors
-Fixed VRC 7 Vibrato, no longer crackles
-Improved speed of NTSC filter some more
-General code cleanups (more are still necessary)
-Provided a more helpful error on stdout when the jInput lirary is missing
Visit project homepage for further information and latest version of emulator.
PPSSPP can run your PSP games on your PC in full HD resolution, and play them on Android too. It can even upscale textures that would otherwise be too blurry as they were made for the small screen of the original PSP.
Here's changelog for 0.9.8 release:
+ OpenGL ES 3 detection bug on Xperia devices fixed, graphics work again.
+ More accurate audio mixing and emulation
+ Software rendering and display list performance improvements
+ Workaround for timing issue hanging Crash Tag Team Racing
+ Galician language
+ Built-in ARM disassembler improvements (dev feature)
+ Fix for immersive mode volume key issue on Android Kitkat
+ And more minor tweaks and fixes as always.
Visit Official homepage for for further information and latest build of emulator
Emulating Game Boy Games With Custom/Colorized Sprites
When it comes to emulation, one could certainly think that we’ve explored just about every aspect of the Game Boy so far. From multiplayer over the serial port, the Game Boy Printer, the Super Game Boy, the Game Boy Color Infrared Port, Rumble Carts, to even the accelerometers in Kirby’s Tilt ‘n’ Tumble: there isn’t much emulators can’t handle. However, there will always be new territory to uncover and explore, especially for those with creative minds. In the form of an enhancement or modification, custom sprites is one such example. An emulator with custom sprites has the ability to replace a game’s native graphics with data selected by the user. To my knowledge, no one has ever implemented such a feature into a Game Boy emulator. Until now that is.
Art History 101:
The original Game Boy, Game Boy Pocket, and the Japanese-only Game Boy Light were only capable of displaying graphics using four different shades of gray (this applies only to background tiles, sprites were restricted to 3 shades with one shade reserved for transparency). Each pixel was either completely on, 2/3 on, 1/3 on, or completely off. The monochrome palette lasted until the Super Game Boy came out, allowing games to be played with 32 (sometimes garrish) colored palettes, as well as custom ones. I never owned one, but I do remember having quite a few “Play It Loud” poster sheets that came with my Game Boy games advertising the Super Game Boy. Eventually the Game Boy Color came out allowing games to be played with colored palettes as well. Still, games that were not Game Boy Color only or backwards compatible games that did not fully utilize the Game Boy Color never really achieved significant colorizations, at least nothing that made them on par with native Game Boy Color games. There is a Game Boy Colorizer ROM hacking tool that aims to help hackers convert old DMG ROMs into fully capable GBC ROMs, but from what I have heard, it can be finnicky at best.
Currently, I am working on my own Game Boy emulator that I plan to call Game Boy Enhanced. It isn’t a very original or clever name, but this is my first emulator, so I can afford to be simple and straightforward. Since the project will introduce me to emulator programming, I do want it to be as accurate as I can make it, however, I don’t shy away from graphical enhancements when it comes to emulation. This is the future after all, so we might as well be able to make things shiny if we want to. At first, I was planning to have the usual assortment of enhancements that nearly every other emulator has: 2x-3x-4x nearest neighbor scaling, various scaling filters (the HQ family, SuperEagle, 2XSai), save states, and maybe built-in sound-ripping. However, one of the regulars on the Dolphin emulator forums suggested that it would be nice to allow custom sprites as a feature, and this got me thinking.
Dolphin is a pretty advanced emulator; it allows users to dump textures for games, edit them, and then load them into the game. This activity is quite popular in sprucing up old N64 games in the N64 emulation community, and the practice has extended to Gamecube and Wii games now too. I figured it would be possible to do the same with Game Boy Enhanced (GBE for short). Although there are a number of more pressing things to program for GBE, I decided to see if I could implement it anyway. The general theory is similar to how Dolphin operates. Based on the sprite’s raw pixel data, GBE generates a unique hash to represent it. GBE stores every hash in a list. When drawing a sprite, GBE compares the current hash against the list. If the hash is in the list, rather than drawing the pixel data obtained from Video RAM (VRAM), GBE will load the custom sprite data from a file. I will go in-depth more about that, but first GBE needs to allow users to get the sprites to modify in the first place.
Taking a dump:
GBE needs to dump the sprites as the game generates them. The general idea is to get the hash and compare it to what we already have in the list. If the hash is already in the list, there’s no need to dump the sprite again, so GBE ignores it. When it’s a brand new hash, GBE pulls the pixel data from VRAM and then saves that data to a BMP. The trick here is to make sure that the file is going to be as unique as the sprite itself, so GBE names it after the hash. This will help when loading the modified sprite as well. Since this work was fairly experimental, the hashes were simply 128-bit numbers converted to hexadecimal. That’s enough to create a unique hash for every possible 8×8 sprite possible as it takes 32 bytes (128-bits) for the Game Boy to represent an 8×8 sprite. 8×16 sprites have yet to be implemented in GBE, so I’m not worrying about that just yet.
Now here comes the fun part: editing tiny 8×8 bitmaps. Obviously there are a couple of challenges. The first is in determining what you’re looking at exactly. If you don’t have a discerning eye, it can be quite difficult to see the sprites you’re after. Of course enlarging the dumps in an image viewer helps, but most larger sprites are a combination of the 8×8 sprites. Visualizing which ones match together is not unlike a puzzle game in and of itself. The next thing to consider is how you want to edit these sprites. Since whatever data entered here supercedes the Game Boy’s color choice, custom sprites are not concerned with things like the palette. The colors in the BMP file are the final colors that will be output to the screen. If the custom sprites decide not to add color, they need only determine what shade of gray each pixel should be, irrespective of any programmed palette.
It takes a keen eye to edit 8×8 sprites like this. Here we have Mario, obviously.
Once the sprites have been dumped and edited, the next step is to load them back into the emulator. It’s pretty much the reverse of what GBE does when dumping them. Whenever new sprite data is generated, GBE generates a hash for that and tries to load a BMP file named after that hash. Once the BMP file is loaded, it gets stored into a cache. GBE then updates a list of which hashes have already been used to get custom sprite data. The list ensures that the same hash isn’t used again to load the BMP file since the cache already contains the custom sprite data. Whenever GBE draws a sprite whose hash matches an entry on the list, GBE draws the custom sprite data pulled from the BMP instead of VRAM. With this, GBE effectively replaces the original pixel data without affecting the rest of the game.
The whole process of custom sprites:
Look at all the colors
The custom pixel data can be anything we choose; it can even exceed the color limits of the Game Boy Color. The limitations enforced on the original system need not apply to GBE, since the emulator has the final say over graphical output, not the original hardware. It’s easy to have a sprite use 10, 20, or even 30 different colors. Although it takes a bit of creativity, there’s nothing stopping sprites from taking on a 16-bit look and feel. The only issue is the screen size (160 x 144 pixels) which makes for relatively small sprites.
However, the possibilities don’t just end there. We can completely mod Game Boy games with this method to create custom pixel data for anything. Background tiles are stored and processed in the almost exact same manner as sprites. The method of generating hashes for background tiles and replacing background tiles with custom pixel data is identical, so it wasn’t hard to program GBE to manipulate the background as well. Now it’s possible to fully colorize original DMG games in a reliable manner. And yet there’s more; consider that this isn’t just a method a colorizing sprites, it’s a way to make the sprites look like whatever one wants them to look like. How about Tetris with Poke Balls? Super Daisy Land wherein Daisy saves Mario? Master Chief as Mega Man? Anyone with enough time and effort could alter or create just about anything.
If GBE ever catches on, I would hope this to be a defining feature, as it could prove popular within the ROM hacking community (even though, technically, the ROM data is not touched with this process). GBE isn’t quite ready for its public release as an open-source project however, as I’m reworking LCD emulation and increasing game compatibility at this moment, and most of the custom sprite code needs to be rewritten as well. It should up on Google Code within a month however, so anyone wanting to play around with this neat feature can have a go.
Other emulators are quite capable of adding this functionality themselves if so desired. The method described here is not specific to Game Boy Enhanced at all nor the original Game Boy games it emulates. GBC, GBA, NES, SNES, Genesis: basically any system that uses sprites can also use custom sprite data. As long as the emulator has some way to view the sprite data (which an emulator needs to, if it ever wants to draw that data onscreen), it can generate a hash and replace the necessary data. That’s not to say it would be easy to implement in every emulator, only that such possibilities do exist. Personally, I think this is an exciting opportunity for people and communities that want to see new life breathed into games that are now getting to be decades old. It could add interesting twists to games that we’ve already been playing for years. I very much look forward to seeing how people apply this technique in the future.
A video of custom sprites in action can be found on my YouTube channel. It’s only Tetris (and not my best game, mind you), and not everything is fully colorized. This is just a proof-of-concept demonstration until the underlying implementation is perfected. Still, it works, and that’s half the battle :)
