Keeping tabs on platform-specific tips and information, with links to helpful emulators or tools that I may or may not have actual hands-on experience with.

| GitHub |
Shinobi III: Return of the Ninja Master (SEGA Mega Drive)

I'm generally not a fan of "all-in-one" emulators like RetroArch as they're typically not equipped for tinkering with games, and are usually a dickens to set up. However, BizHawk is lauded for its features specific to tool-assisted speed-running, so it comes with a reliable RAM Editor, a LUA Console, and a bevy of other tools I haven't got acquainted with yet, but might come in handy!

It supports a wide range of platforms, including fare like Nintendo 64, PlayStation, SEGA Saturn, Atari Jaguar, Nintendo DS, even arcade games through MAME -- though its SEGA Mega Drive and PC Engine/TurboGrafx emulation are standout for including VRAM viewers and map viewers.

Its RAM Search is handy, it has some good speed options and a frame step (by pressing F), and by making its savestates uncompressed, you can extract them and chuck the "Core" file into a tile viewer -- go to Tools > Rewind & Savestate Configuration, set "compression level" to 0, and "type" to "Text", and away you go!

You may need to perform an extra step with savestates before they're properly readable within a tile viewer, though. That "Text" setting is literal, as it literally prints the hex data into text, meaning a hex viewer will read those text characters as different hex entries -- it's all a bit of a mess...!

To fix this, copy the text from the "CoreText" file and paste it into a hex editor (the hexadecimal column, not the output text!), and save. This'll produce a file that's drastically lower in file size, and will also be read properly in a tile viewer.

Choosing the "Binary" type setting seems to still be compressed in my experience, hence why we choose "Text", but either it's not a consistent problem across all cores, or it was introduced in a newer version of BizHawk. In any case, be aware if things seem a little off!

Some console compatibility is better than others; its MAME core doesn't have that emulator's access to cheats or its tile viewer, and opening its RAM Editor will almost assuredly crash the emulator... but it still plays nicely with Cheat Engine, and its clickable buttons for loading savestates make it a lot more compatible with Macro Recorder. For that reason, it's much easier to do screenshot rips and set up macros in BizHawk than in MAME.

Not every emulator core has the same fun extras like VRAM displays and whatnot, but by virtue of having a consistent set of tools across so many consoles, it makes working with them all that much easier. Although Atari Jaguar is arguably best supported by BigPEmu, that emulator doesn't have a RAM editor or access to VRAM through its savestates, so BizHawk wins out...!

| official site | old site |
Quiz Nanairo Dreams (arcade)

Almost assuredly outdated and overshadowed by now, but still my go-to emulator for Neo Geo, CPS1 and CPS2 arcade games -- its tools are just too handy!

Capcom and SNK's arcade boards handle their graphics differently; the CPS2 has 3 background layers (8x8, 16x16, and 32x32) in addition to 7 sprite layers, and they can all be toggled or disabled under Video > Disable. The Neo Geo, however, classifies everything except its 8x8 layer as sprites, meaning either you disable the HUD or you disable everything else...! (you can at least change the background colour under Video > Set background colour, so you've got a distinct colour to rip against)

Under Tools you'll find its Shots Factory, which allows you to disable each sprite, represented by a tick. CPS games typically represent an entire sprite with a tick, but on Neo Geo each tick correlates to a tile, or a vertical strip of background. Graphics may flicker since they tend to shuffle themselves around during gameplay, so you may have to babysit the process...!

Capcom Sports Club (arcade)

Also under the Tools menu is the Tile Viewer! This replaces the game window with a tile display, and a new window with three sliders and three display options.

The top slider chooses how many rows/columns of tiles to be displayed on-screen. CPS games present their tiles horizontally and usually have a fixed width of 16, while Neo Geo presents theirs vertically, though be aware that because of the Neo Geo's resolution, setting the slider to higher than 14 will actually scroll some off-screen.

The middle slider scrolls through tiles. In Capcom games the display options simply toggle how the tiles are arranged, while Neo Geo games have separate graphics banks for 8x8 tiles and 16x16 tiles.

The final slider is palettes, though it can only display colours that are currently loaded in-game, so you'll want to have that sprite on-screen before you rip its tiles. There's sadly no way to see the colours in each palette, so if you intend to recolour them later, make sure there's 16 distinct colours!

The Neo Geo's tile layout seems ideal for fighting games, allowing for tall sprites to be displayed quite nicely if arranged properly. Some games, however, format their tiles to be displayed horizontally, and thus look like a mess if viewed at anything higher than 1; Neo Bomberman's tiles are optimised for 128x128 display, for instance.

You can still rip them from Kawaks, but it entails a lot more effort just to piece them back together again...! For this I recommend the Neo Geo Graphic Tile Suite, to convert them into a format readable by YY-CHR or Tile Molester.

| official site | GitHub |

The Multiple Arcade Machine Emulator, one of the longest running emulators still in active development; what began focusing purely on arcade hardware has since broadened its scope to all manner of platforms, thanks in part to the libretro project. This means it can run games on Phillips CD-i and 3DO, even plug-and-plays, Game & Watch or Tiger LCDs!

It should be noted that MAME is a beast unto itself, and has gone through many changes throughout the years, not to mention the deluge of niche off-shoots supporting increasingly esoteric games not supported by the main branch.

What this means is compatibility is a dickens, finding ROMs that work in each version is a nightmare, and functionality tends to pinball a bit between versions. A game might play perfectly in one version, but refuse to boot its tile viewer. In another it'll barely work, but the tile viewer can be accessed, though it seems the tile viewer won't function on some platforms like CD-i as of this writing.

What I'm saying is I'm a fool who's held onto versions that are years out of date solely because they're what I know, and they do what I want them to do...! The newer versions of MAME are kind of gargantuan, but if all you want is basic arcade stuff, version 0.142 should be all you need.

TH Strikes Back (arcade)

Anyway: the tile viewer! Pressing F4 in most games will display palettes, tiles and tilemaps -- you can toggle with Enter, scroll with the arrow keys or PageUp/PageDown, and use the square bracket keys ([ and ]) to change the canvas dimensions. You can resize the window to make room for more tiles on-screen as well.

The screenshot key is disabled in these menus, so you'll need to PrintScreen the results or use a screenshot tool to grab them, and probably find a way to snip the pixel border on all the tiles too...!

Franck Charlet's MAME v0.129 + Tiles saving is a branch that incorporates some time-saving hotkeys that allow you to export the palette into a .PAL file, and export all the tiles in each possible palette into separate sheets.

These tile sheets will export as .BMPs and can eat up a shocking amount of space, so make sure you've the room before you dump everything! That, and being based on an archaic version of MAME means you'll need the appropriate outdated ROMsets for games to be recognised and loaded properly.

MAME does have debug functions under Options > Default Game Options > Debug, though it's a more complex feature than your casual RAM viewers. Some versions of MAME allow you to search memory under the in-game Cheats menu, but it seems to exist only in specific versions or specific games as far as I can tell...!

Cheat Engine is a more digestible alternative, and its speed throttle option works well for the most part, though you'll want to have an address that's easy to find again when you boot up the game. If you're going to use a macro, I recommend using MAME to scout for addresses ahead of time, and then converting your cheat table to work with BizHawk when it's time to rip, as it's a more cooperative emulator with those sorts of tools.

It's important to be aware that the MAME tile viewer is not perfect, and might be limited in what it can detect, or even hampered by its palettes, unable to choose one without duplicate colours. In that situation you'll either need to get screwing around with Cheat Engine, or try to make sense of the ROM's raw files; hit up the arcade section for what I know, though don't expect guaranteed results...!

| VBA-M (GitHub) | official website (Archive.org) | VBALink |
Aleck Bordon Adventure : Tower & Shaft Advance (Game Boy Advance)

VisualBoyAdvance (or VBA-M) has perhaps been supplanted by mGBA or other alternatives when it comes to accuracy and compatibility, but in my opinion, this is perhaps the most accessible emulator to get to grips with the tools you want from an emulator!

First of all, a pet peeve: Go to Emulator > Gameboy, and select "Real colors". I'll rant about that on another page.

Under Tools you'll find the good stuff: a tile viewer! A map viewer! A palette viewer! Even an OAM viewer for viewing all sprites on-screen, even stuff that might be obscured or partially off-screen! All have toggles to update live to gameplay changes, and can export their findings to PNG or as functioning palette files. If the built-in tile viewer isn't working out, you can always make a savestate and extract its contents into your tile viewer of choice.

The memory viewer is a point of contention for some, as there's no actual search functions in it; if you want to find addresses that have changed, you have to use the "Search for cheats" window and take a note of its coordinates, an extra superfluous step compared to the all-in-one window of other emulators.

However, all the aforementioned viewers display their memory addresses on their windows, which you can copy straight into the memory viewer and edit directly. Palette not being cooperative? Change it! Sprite or background just being a nuisance? Blank it with zeroes! You have much more direct control over the screen with VBA's tools, making screenshot rips so much easier, on top of the usual conveniences like frame step (Ctrl + N), disabling layers, and even a lossless video recorder.

Under "Options > Gameboy > Colors" you can set up a custom palette for monochrome Game Boy games, saving you the trouble of figuring out which colours belong to the sprite or the backdrop. Classic VBA's frame step function doesn't work in Game Boy or Game Boy Color games, for some reason, though VBA-M seems to have finally fixed that.

I've yet to get it running in VBA-M, but VBALink was a branch that could emulate GBA multi-cart play by simply opening extra instances of the emulator. Naturally ripping sprites from these modes is a bit of a dickens without causing the connection to timeout, so making savestates is recommended. NO$GBA is perhaps easier to set up by comparison; see Game Boy for its own link-up emulation.

Trog (NES)

The emulator with the most features relevant to sprite ripping is probably Mesen, boasting a tile viewer and palette viewer. NES games don't typically compress their graphics, but when they do, finding them in VRAM with this tool is the ideal way to do it.

It even has a "nametable viewer", showing what tiles the background is made out of: ideal for piecing together a table to edit a game's text. Its memory viewer is a bit heady for my liking, in which case I prefer to use BizHawk for RAM manipulation.

An important thing to remember with the NES is that it has no 'concrete' palette for its 64 possible colours. There's no internal RGB value to identify them, how they are perceived is entirely up to the emulator or video output; see the Emulation General Wiki for details. What this means is you're gonna get different results from emulator to emulator, sprite sheet to sprite sheet -- that's normal, and whether you correct it to be consistent or not is up to you. Don't sweat the small stuff!

The PC Engine's graphics format has been a bit of a nuisance for the longest time...! Almost all of its games use compression on its ROMs, but not that you'd have much luck finding anything anyway, as its format isn't covered by YY-CHR, Tile Molester, or any of the common tile viewers: they're kind of identifiable with 2BPP Planar, but that's missing three-quarters of its colours!

Bomberman '93 (PC Engine)

Dave Shadoff made a plugin for DOS-based tile viewer TMOD2 which allows you to view its sprite and background formats; you'll probably want to run it in DOSBox, and you might need CSDPMI*B.zip for it to work. After that, the 7 and 8 keys should allow you to set the appropriate graphics display modes.

Savestates made in emulator Magic Engine (which appears to be defunct, but can be found on Archive.org) would work in TMOD2, though only after renaming them to .PCE, and with no ability to look for palettes; you'll have to apply them yourself after the fact.

Since BizHawk has VRAM, palette and map viewers built-in, this method is kind of superfluous, though it's still worthwhile for exploring CD-ROM games, which usually lack compression (though it may need cut into chunks, since DOSBox only has so much memory for these large files).

I'm told the graphics compression for this platform isn't that complex, but as someone with zero coding know-how, the lack of convenient decompressor tool is enough to make it appear daunting! For now, BizHawk is the most accessible means of sprite ripping from gameplay.

Gonna shill BizHawk again, sorry -- having a built-in tile viewer, map viewer and RAM editor is just too handy. DebuGens and other branches of Gens were popular back in the day for their various memory dumping options, not sure how relevant they are nowadays.

Most tile viewers should support its graphics format, though its palettes are stored differently than the norm; Tile Molester seems to be the one best suited for reading them, though there might be more specialised software out there I'm unaware of.

Mesen, bsnes-plus and no$sns all have decent features, including a tile viewer, a map viewer, palette viewer, and sprite/OAM viewer. Their debug tools are all a bit heady for my liking, in which case I prefer to use Bizhawk for RAM manipulation.

SNES9x remains my old standby because I'm an old fogey, though aside from its convenient hotkeys to toggle sprite layers, it's kind of useless at tinkering.

SNES graphics are stored in "4bpp planar composite", a unique format that overlays tiles to get the appropriate appearance, and thus causes funky effects when you offset it. TiledGGD cannot recognise these to my knowledge, so you'll have to stick with YY-CHR or Tile Molester.

The Simpsons: Bart's Nightmare (SNES)

The emulators above no doubt supplant it, but vSNES is a tool that opens up SNES9x and ZSNES savestates, giving full GUI access to tiles, palettes, background maps, and other technical gubbins.

Naturally it's pretty ancient, and I can't even tell what versions of the emulators it even supports any more -- I've confirmed it can identify savestates from SNES9x v1.51, but not v1.53, and I can't tell which ZSNES savestates it even recognises at all. I'm still partial to its presentation, but it's become more hassle than it's worth to use in this day and age.

Other useful and possibly archaic tools include SNES Palette Editor, for when you prefer to know what colours you're changing instead of fiddling with hex; and SNESSOR 95, a tool that can extract sampled sound effects from games into WAV files.

BigPEmu appears to be the best emulator available in terms of game compatibility and quality-of-life features, though it sadly lacks any meaningful sprite-ripping options -- no access to VRAM, no RAM editor, save states are compressed... at least BizHawk has those last two covered!

Jag Viewer claims to specialise in viewing graphics from Jaguar ROMs, though I've only had success in viewing BizHawk savestates, I've had no luck scouring through ROMs.

The games clearly have a file structure, evidenced by poking about in them with a hex editor, but I'm not aware of any way of extracting them, if they need decompressed or what.

The Nintendo 64 is a bit of nightmare to sprite rip from, not just because its games are already compressing most of their data, but also because it deals in just about every graphic format that was available at the time -- anywhere from 4-bit to 32-bit colour depth, and usually in tiny little chunks that get assembled into a bigger picture, making them tricky to find at a glance...!

As such, trying to find anything while exploring ROMs is like finding a needle in a haystack. I'm told Texture64 is better equipped for this task, but I think I've thrown up my hands at this point.

Texture dumping seems to be how most folks get stuff from this era of consoles onward, so you want an emulator for that! Gonna point you towards BizHawk yet again, as it uses Mupen64Plus as its N64 core, getting the perks of that emulator without its dodgy interface, and comes with ideal graphics plugins already installed. I am still partial to Project64, though I'm told it's a bit old-hat by now.

For the closest thing to accuracy, I suggest either "Angrylion" graphic plugin paired with the "Static Interpreter" RSP plugin (and "Graphics HLE" disabled), or emulator Ares, though both methods are pretty resource intensive. Be aware that "accuracy" for Nintendo 64 hardware means "fuzzy and blurry," so sticking with GlideN64 as your graphic plugin should get prettier results; you probably want to avoid screenshot rips anyway, the N64's got too much scaling and filters to make it reliable.

Under the "N64 > Plugins" menu in BizHawk you should be able to find a "Texture Dump" option under your plugin of choice. Ticking that and rebooting the core will dump loaded textures in "C:\Users\[username]\AppData\Roaming\Mupen64Plus\texture_dump\". Plugins in other emulators might have different locations; I know Jabo Direct3D8 would dump them in the "textures\saves" directory of Project64.

The Rice Video plugin is seemingly what folks recommend, and it does have a robust debugger window when used in Project64, though it's a bit much for my blood. Glide64 has the cute feature of displaying all the textures on-screen by pressing Scroll Lock... but they aren't at their actual sizes, so it's functionally useless for ripping purposes.

Dr. Mario 64 (Nintendo 64)

Texture dumping's a bit unreliable for me, personally, especially when stuff is more visible in VRAM. Savestates made in Project64 or BizHawk can be opened in a tile viewer, though the graphics are in a bit of a state: they're stored in 2D/Linear format, but are presented like columns of tiles in reverse order.

When ripping from Dr. Mario 64, I had to mirror each column in Tile Molester to view them properly, but due to that program's limited canvas options, I was unable to rip all the characters; TiledGGD would be able to step in for that now. Above shows Wario's sprites in their default state, then mirrored, before finally adjusted to the proper width.

I couldn't find the palette, natch, but you'll also notice the sprites are still a little funky, as if they're set in the wrong Endian; I probably just fixed this manually back in the day. This might have something to do with the .N64 and .Z64 ROM formats, which supposedly store their bytes in opposite Endians, or even a quirk of BizHawk's savestates, but it's something I'd have to look into more.

This is the era where hardware shifts away from being built for 2D, so there's not the same ease of access to sprite and background layers like on previous platform's emulators. On the upside, CD-based games now let you have access to their file structures!

You'll want something that can explore disc images, natch (7Zip should suffice), or you can just pop that sucker in your CD drive and read it that way. Do be aware that on rare occasions there is information baked directly into the CD data, not represented by a file or a folder; usually a deep-dive tool like ISOBuster should be able to find it, but if not, time to scrounge through raw CD data...!

BizHawk can handle PS1, surprise. DuckStation seems to be the hip new emulator nowadays, though ePSXe is my old standby; it's more awkward to set up but seems to have slightly better compatibility than DuckStation, though accuracy is questionable. I'm told Beetle PSX has a texture dump feature, I'll have to look into that!

Crash Bandicoot (PlayStation)

PsxVram can open savestates made in ePSXe and other emulators, and shows everything the game has in VRAM, navigable with Left Click to choose what graphics to spotlight in the Mode window, and Right Click to select a palette (if CLUT has been ticked; you can also use the coordinates to fine-tune the selection).

ePSXe can only support five savestates per game, and also refuses to make them in certain games for whatever reason, but it's not a bad tool and a darn sight easier than trying to trawl VRAM with an ordinary tile viewer.

One of the more common filetypes on PlayStation is .TIM, which can house multiple images and palettes, and are easily readable with tools like PSicture or just about any tile viewer. It's an adequate place to start, but you're really gonna want to get creative when exploring PlayStation games, because with great technology comes greater compression methods and ways to keep folks out of its data.

For sheer compatibility, I'd have to recommend SSF (SEGA Retro | GitHub) -- it's a bit tricky to set up, but it's a robust emulator that gives you the least guff, plays nicely with Cheat Engine, and allows you to disable sprite layers under Options.

On the downside, its debug stuff is limited to non-existent, and its savestates are compressed, meaning they're no good for trawling VRAM. It's got other quirks, like needing to 'mount' the ISO in a virtual CD drive for it to be recognised, and a bad habit of corrupting its config file and refusing to boot -- keep a spare on hand and delete or replace it if it ever acts up! Despite this list of quirks, it's definitely the one worth keeping around for actually playing the games.

Much like PlayStation, this is the era when games start housing visible file systems, but also play with increasingly funky compression or organisation, so ripping from VRAM via savestates or editing RAM is a must. Gonna recommend BizHawk again for its uncompressed save states and RAM editor.

I lost my notes on where graphic and palettes are typically stored in savestates, though. Graphics typically come in 4BPP to 16BPP format, and usually start at address 240000, I think?

I previously used YabaSanshiro (formerly Yabause) for this purpose thanks to its uncompressed savestates. For the hardware-savvy, it's got a RAM viewer and an in-depth debug function that shows what each component of the Saturn is up to. Otherwise I wouldn't recommend it for playing games; it's resource-intensive, has video errors, and is prone to hanging whenever there's a loading screen.

The VDP1 function has an OAM viewer that lets you dump bitmaps of on-screen sprites... though it leaves a lot to be desired, exporting them with a pure black backdrop that likely collides with its own palette, and viewer stretches them to fit the square display window, so that's a bloody nuisance. It's neat it exists, but only to be used for solitary rips or if you positively cannot find it in VRAM.

Putting an Xbox 360 disc in a PC's disc drive will result in it being read like a DVD, which is no use to looking at its files. I won't get into the legit method of ripping discs (largely because I haven't a clue), but you can access a game's files without any cheatsy methods -- just install the game from disc to hard drive, then copy it to an external drive like a USB stick! This applies even to Xbox Live Arcade games, Xbox Live Indie Games, save files, the works.

After that, use wxPirs (official site) to extract their contents. You can read and extract this data by cropping bits from them using a hex editor (hex address 410 will show the title of the game the file belongs to, and C000 will show the file directory), but they're prone to glitches and errors (the same way loading an ISO straight into a tile viewer will have garbage data interrupting its graphics); just save yourself the trouble and use this tool!

As mentioned in the tile ripping briefing, Game Boy games employ a lot more compression than the likes of NES stuff, so you might have to rip from VRAM a lot -- VisualBoyAdvance is my personal recommendation, though there's no shortage of options.

TGB-Dual is my choice for emulating link-up play, while hhugboy is worth having around for more esoteric games and peripherals, mostly pirate and homebrew games.

Virtual Boy uses a unique compression system on its graphics; just like PC Engine, you can roughly tell what you're looking at in a tile viewer, but they're in no state for ripping!

Red Dragon used to be the only emulator with halfway decent compatibility, and its savestates were uncompressed, making them ideal for chucking into YY-CHR, though its forced fullscreen DOS presentation was a nightmare to work with. I assume BizHawk is probably easier to work with by comparison...?

Because of its 3D display, games would often utilise multi-segmented sprites to simulate depth by positioning pieces differently on both lenses -- Panic Bomber, Teleroboxer, and so on. Though I've attempted rips of those sprites just by getting their pieces, I'm not sure what would be the 'accurate' way to show them assembled -- different versions for each lens? I'll cross that bridge when I come to it...!

VisualBoyAdvance should have all the tools you need for ripping from gameplay, it's a good all-in-one kit.

I'm told NO$GBA is worth a goosey for its advanced debugging options, though its technical gubbins flies right over my head. I mostly use it for its multi-player emulation, allowing up to 4 simulated GBAs and the choice of single-pak or multi-pak play. It's an emulator I only use in niche situations though, for this and for DSi emulation.

Last I checked it's got no convenient sprite-ripping tools, though, and you have to edit its .INI file and set "SAV/SNA File Format" to "Raw" for its savestates to be readable in tile viewers. From my experience the emulator tends to crash if you attempt to load these raw savestates, so maybe make "Compressed" ones first as a failsafe, then reload them later after editing the .INI file...?

The GBA is no stranger to compression, though it has a slightly more common standardised one in the form of LZ77. unLZ-GBA can automatically detect these compressed chunks and attempt to decompress them, though it's not a sure thing, and it might not always be graphics it finds. The tool does work on a few Nintendo DS games as well, notably Sonic Rush.

DeSmuME (official site | GitHub) is my preferred emulator; it's got a similar toolkit to VisualBoyAdvance, plus a more robust RAM viewer, though its map and tile viewers are perhaps a bit fiddly on the sheer size of their windows and how many options there are. It's perhaps easier to just make savestates and explore them in a tile viewer.

The DS finally introduces an accessible file structure for its games, which you can explore using Tinke (Tahaxan used to be the hot tool of choice, but Tinke has supplanted it in functionality and accessibility features). You can explore directories, extract individual files or the entire file system, and even replace files if you fancy a cheeky bit of ROM hacking.

Like PS1 games, do be aware that on rare occasions data may baked into the ROM itself, and not represented by a file in its internal directories. Tinke can also decompress archive types it's got the know-how for, but some files are beyond its knowledge.

DSiWare isn't playable in DeSmuME to my knowledge, for that you'll need a specific branch of No$GBA. You'll need to suffer through setting up a virtual MMC cart, something I have no idea how to do, I just found one with the games I needed pre-installed...!

As mentioned under Game Boy Advance, this emulator doesn't have the same convenient tools for sprite-ripping, so you'll probably just want to be working with its savestates. Opening NO$GBA.ini and setting "SAV/SNA File Format" to "Raw" will make them readable in tile viewers; DSi savestates tend to be quite large, around 17MB, with graphics seemingly stored around addresses 300000 and 1000000.

Also as aforementioned, the emulator doesn't actually like reading raw savestates and tends to crash when loading them, so try and work around that hurdle if possible...!

Once a PSP UMD disc image is ripped, it should be able to be opened like any other ISO file. Get exploring! For sheer playability, PPSSPP comes recommended, though it's not 100% accurate and lacks good tools for sprite ripping last time I checked.

JPCSP is worth checking out if just for its "Export 3D scene function; just like it says on the tin, this dumps all presently-loaded graphics into a folder, allowing you to shift through the textures manually, or even import it into 3D software like Blender to see the game environment! This isn't just adorable, it's a good way of getting your paws on VRAM.

I've still yet to dip my toes into this realm, but Citra seems the emulator of choice for being able to dump the "ROMfs" of games, letting you poke around in their file directories. Not sure if it's any good at viewing VRAM, though.

A bit of a wild-land, this! There's so many possible hardwares to be working with, so many developers with their own organisation or compression tools...! For emulation, typically MAME should be your first go-to, though there's a number of specialised emulators tailor-made for specific hardware, like Kawaks for Neo Geo, CPS1 and CPS2.

If MAME's tile viewers isn't quite cutting it, then you'll want to unzip the ROM and start poking about its files. As aforementioned, these come in all shapes, sizes and formats, so it might take some doing to make sense of them...! A common trait is the contents of arcade ROMs being split across multiple files, and often need merged together and interleaved to present them as they're supposed to look.

TheInterleaver will take two files and merges them together, splicing their bytes after one another: byte 1 of file 2 comes after byte 1 of file 1, and byte 2 of file 1 comes after that... That means if there's 4 files that need interleaved, you'll need to interleave files 1 & 3, then 2 & 4, and then both merged results. Things get hairy if 3 files need interleaved or they require a different arrangement of bytes, though.

You'll typically want to get creative when sussing out arcade file systems though, experimenting with formats, display types... or just resorting to screwing about with RAM if the raw graphics are too much trouble.

This old thread from Mugen Fighters Guild has cheats for manipulating sprites or backdrops in certain games in MAME and Kawaks. Not just ideal for making ripping from them easier, but possibly a chance to figure out how such cheats are made...?

SEGA's arcade games are unique in that they dedicate 2 colours of their 16-colour palette to background transparency, appearing as striped lines. This makes a handy-dandy built-in way of determining the width of each sprite, as when there's two lines of the same color, that means the end of a line, since their sprite widths are always in multiples of 2.

The System 16 Sprite Viewer (official site | GitHub) is specifically designed to automate this process; you'll need to extract the ROM contents to a directory, and cook up a new XML file based on the "altbeast.xml" template, linking to the graphics files and telling them the right way to interleave.

SEGA System 24 graphics files are 2-byte interleaved, which the tool does not yet support.

Kawaks already has a good built-in tile viewer, but sometimes you prefer to view them in your preferred tile viewer. The Neo-Geo Graphic Tile Suite will convert the graphics files ("C1.bin", etc) into one core file that you can open in YY-CHR or other tile viewers, so long as they can support SNES graphic format. To use it...

● Extract the files suffixed "C1", "c2", etc. from a Neo Geo ROM and place them in the tool's folder.
● Don't open through the "Command Prompt". Simply double-click the executable, otherwise it won't actually produce its output.
● Type in the full name of the file, with the extension.
● "out.bin" should appear in the same directory as the executable. You're done! Open the file in your tile viewer of choice, so long as it supports SNES graphics format (4bpp planar, composite 2x2bpp).

(although it functions similarly, using TheInterleaver will balls up the tile arrangements, don't use that!)

Like several other arcade games, Neo Geo ROMs are composed of multiple files, with data split and interleaved between two files; files suffixed "C#" are for 16x16 graphics, with two files per graphics bank. "S#" is for 8x8 graphics, "V#" is for sampled audio, and "M#" and "P#" are typically for code or music sequencing. Hit up the Neo Geo Development Wiki for more technical information that flies over my head.

Getting access to palettes in Neo Geo games is evidently a bit of a pickle, and you're often expected to just dump them from gameplay; Kawaks and MAME will only display palettes that are currently loaded in-game. I have found palettes in the "-P1" file of a couple games, namely Neo Bomberman and Cyber-Lip, though they need a new palette registered added to Tile Molester to be viewed correctly. Open its "tmspec.xml" file in a text editor, and add:

You may need to change the "id" if there are conflicts. The findings in those two games might just be leftover code from development, as I've had no luck finding similar results in the likes of Metal Slug. If there are answers and I'm just clueless to them, point me to them, why doncha!

The banner name for all of their game creation tools -- Klik & Play, Click & Create, The Games Factory, Multimedia Fusion, Clickteam Fusion...!

Source Explorer is capable of opening .EXE files for Multimedia Fusion and Clickteam Fusion games and extracting their graphics and sound files. Every "room" will be extracted as its own folder, and each object in their own sub-folder, so between that and the duplicated sprites for facing each direction, you may want a tool like AntiDupl to filter through all the repeats...!

ValleyBell's Clickteam Data Extractor (Sonic Retro | Kippykip | local backup) is capable of ripping the maps from games with an accessible data file (.GAM, .CCA, .TGF, .MMF, etc.), though their sprites and objects will be baked in.

CExtract can also remove the protection from games, allowing you to edit them in the appropriate program, though not with 100% success, some games it'll simply choke on. If the game is only an .EXE with no data file, it can't do anything with it. The tool hasn't been updated in forever, so although it proposes the ability to view animations or code, those functions are not implemented yet.

Source Explorer cannot open games made in The Games Factory, Click & Create or Klik 'n' Play, but if you can convert it using Clickteam Fusion, it'll pass muster, so try running it through CExtract. As far as I'm aware, if Source Explorer can't extract it, the only means of ripping a game's graphics is manually screenshotting them from within the game, or the Clickteam software's animation viewer.

GameMaker's been around the block, and has come in a variety of forms over the years! Games made in the newer edition of GameMaker typically come with a "data.win" file, which contains all the major assets: sprites, strings, rooms, audio, etc.

UndertaleModTool will work on such games -- just open up the data.win file with the tool and you can poke about as you please. It has macros to dump all individual sprites, texture sheets, maps, the works.

If it doesn't have an external data.win file...

● open the .EXE in an archive extraction tool like 7Zip

● extract the ".data" file

● open the ".data" file in a hex editor

● find hex string "46 4F 52 4D" (or "FORM"), then delete everything before it

● find hex string "41 55 44 4F" (or "AUDO"), then delete everything after it

● save as "data.win"

That should allow it to be opened in UndertaleModTool, though it's not guaranteed results.

It's notable that you can find the raw files inside "data.win" if you search for the appropriate headers -- "%PNG" and "IEND" and whatnot -- but this'll get you the raw assets GameMaker auto-generates from imported files, which can be more than a little unwieldy if you want to organise it.

Be aware that if you're looking to mod or edit games, newer versions of GMS2 use a unique compression algorithm called QOZ2, that UndertaleModTool still hasn't fully emulated as of this writing. Inserted sprites may have a slight loss in quality, most evident when trying to insert sprites with customisable palettes.

As far as I'm aware, ripping sprites from games made in Game Maker 8 or earlier entails decompiling it into an editable format (you'll want either GMDecompiler v2.1 or GM8Decompiler), and then manually exporting all the sprites using the appropriate version of Game Maker itself -- going to Edit Sprite, and then Save As Strip. If there's a way of automating this process without the need for the original software, I haven't heard of it...!

Also as far as I know, there's no tool to decompile games made in GameMaker versions earlier than 5; if it's in GameMaker 4, you're out of luck! You can use the Windows Task Manager to create a dump file, which should have all the graphics and other assets stored within.

Graphics will then be visible in TiledGGD under 32BPP format, palette order RGB for GameMaker 7+, palette order BGR for GameMaker 4. Though each sprite frame has a hex header saying what its canvas size should be, I can't find a reliable string for finding every sprite, so you'd have to go hunting...!

These should include a ".PCK" file among their data; use godotdec to extract and convert its contents.

That funny old Japanese computer. YY-CHR has a 2BPP MSX mode that seems to get the sprites from low-colour games like Bomberman Special just fine, and its 1BPP mode can view the background tiles, though I seem to recall it might've had trouble viewing all the colours properly. I could be wrong, it's been a hot minute!

Some versions of RPG Maker simply have all the tilesets and sprite sheets in folders sitting out in the open. Just gank away!

Maps made in RPG Maker 2000 can be converted to PNG using lmu2png (official site | GitHub). For later versions, you might want to look into RPG Maker Decrypter and RPG Maker MV Decrypter (official site | GitHub).

Extracting stuff from PC games is its own kettle of fish, and far too broad for me to cover! By virtue of having direct access to their files, this makes it easier to figure out what's where and how to get your paws on it -- tools like QuickBMS and Noesis are better equipped for that -- but it's not without its own hurdles of esoteric file types, compression, all that stuff I respect and detest.

When a file is compressed, you'd think accessing VRAM would be a good way to get at it... if I knew how, hurf. Windows 10's Task Manager does have a delightful feature where, after right-clicking an App under Processes, you can Create dump file, which creates a file you can root through in your graphic viewer of choice. How delightful!

Old DOS games can be a pickle, just on account of how old they are -- they might not be complex, but good luck finding modern tools that can recognise what formats they're in...!

For running older games, you'll want to explore options like DOSBox, VirtualBox, and PCem; DOS games have variable compatibility between all of them, so if one doesn't work, try another...!

DOSBox-X is a branch with easier access to savestates and debug options -- by default, savestates are stored in "C:\Users\[username]\AppData\Local\DOSBox-X\save\", and can be opened and extracted like zip files, with the "Memory" file probably where you'll find the graphics you want. It's not guaranteed results, especially in games with EGA graphics, but it'll do in a pinch.

The old phone games folks in the western hemisphere knew most were Java J2ME games. Like most Java applications, these .JAR files are essentially zip archives with all their guts on the inside, which you can just extract without much bother. Some files are hidden from view, requiring a tool like RippyK to take a deeper dive, though it's prone to errors or simply not digging up decent results.

KEmulator Lite is my choice for emulating J2ME games, though it may be archaic by now; I'm told Android has better apps for emulating Java stuff, but my patience for emulating Android has waned thin. Its accuracy and compatibility is shaky, but it's got some funky tools to play with, like the ability to view 3D assets that've been loaded in-game.

A lot of Java games rely on assembling sprites from lots of teeny little pieces; my only expertise with this has been using Cheat Engine to swap animations in-game and rip those, but I'd like to explore the ".class" file types to see if any of them store instructions on how these things are put together.

Smartphone games are similar, in that an Apple IPA or Android APK file is also a glorified archive file, just a smidge more complex. You'll probably want to defer to a specialised exploration tool like UnityUnpacker for that one.

It's important to be aware that not all of the game's data is stored on its app file, but may be downloaded or streamed in during gameplay. Metal Slug Attack would download all these files every time the game was launched, and you'd need to use a phone app to find those files and export them somewhere while the game was running.

Games with an always-online connection are likely to skimp out on that, and just download new files as they're required. If you want to get all the sprites from one of those gacha games, you might have to earn them all legit first...! This also means that once the game goes offline, there's little to no chance of ripping that stuff, and the APK is close to useless.

There's a few programs for emulating Android on a PC, including BlueStacks and AndyRoid. I've only had experience with the former, and though it worked for my needs, it's too darn bloated for my poor little computer to keep up with, and also kind of crap at running old apps. I'm too old for this shit!