We run into a bit of trouble though for palettes with 8, 32, 64, or 128 colors, which require 3, 5, 6, and 7 bits per pixel respectively. The 16 color palette of the Apple II, with each pixel now encoding four bits of data Using four shades of green to simulate the palette of the original gameboy The same memory snapshot rendered using all three standard CGA graphics palettes, along with their high intensity variants We can use the same techniques for other color palettes: Here’s what it looks like if encode each pixel from a byte, using a mask to discard all but the lowest two bits:ĭata has been lost here it is no longer possible to recover the memory snapshot from the image. The data now fits into a 64 x 128 image:ĭifferent lossless encoding techniques are also possible, along with lossy encoding. Each CGA palette has four colors, so each pixel can now losslessly encode two bits of memory. Let’s start simple by using one of the CGA standard graphics palettes. Less normal sizes can also be interesting however: Power of two image widths generally show more regular patterns. Returning to Super Mario 3, adjust the image size and different patterns appear: 3:ĭifferent games, and even different sections of the same game, produce vastly different images: This memory was taken from the starting position in world 1.1 of Super Mario Bros. The NES’ 16384 bits of internal memory fit nicely in to a 128x128 image: I started by visualizing bits, with 0 as black and 1 as white. (I have run into the same problem in a number of my projects and am unsure if it can be avoided.) For example: in a 64 pixel wide image where each pixel represents a single byte of memory, two pixels vertically adjacent to one another are actually 64 bytes apart in memory. This unavoidably creates some false impressions. I projected the one dimensional memory data into reasonably sized two dimensional images using the same algorithm as reflow, filling in the image data in english reading order: top to bottom, left to right. The second step is necessary because memory addresses are one dimensional, but images that are 1 pixel high and 2048 or even 16384 pixels wide are not the most practical. To turn memory snapshots into images, I first encoded the memory values using colors and then arranged these colors into a 2D image. Sampling these other resources may make for an interesting future project. Cartridges may include additional RAM, and system’s picture processing unit has its own memory as well. The system has a 16bit address space, with the first 2KB for the internal RAM and higher addresses mapping to various other system resources. Now, the NES’ internal RAM is far from the whole story. This script captures the system’s 2KB of internal memory and a screenshot at the end of each frame, writing the whole mess to sequentially numbered files. registerafter ( after_frame ) while true do emu. print ( string.format ( "frame %d", count )) local out = assert ( io.open ( string.format ( "%s\\%d.data", outDir, count ), "wb" )) out : write ( data ) assert ( out : close ()) count = count + 1 end os.execute ( "mkdir ". savescreenshotas ( string.format ( "%s\\%d.png", outDir, count )) local data = memory. OutDir = ".\\output_test\\" count = 0 function after_frame () gui. Here’s the simple Lua script used to collect the data: This emulator offers a variety of debugging and reverse engineering tools, along with Lua scripting support. On a NTSC NES, this works out to just over 60 memory samples and screenshots every second.Īs doing all this on actual hardware would be exceedingly difficult, I opted to use the FCEUX emulator.
I also thought it would be a good idea to capture screenshots of the game to go along with these memory snapshots. To keep things simple, I decided to sample the RAM once for each rendered frame of the game, and focus on the NES’ 2KB of internal RAM. The goal of this initial experiment was to visualize an NES as it runs a game. There’s plenty to explore so let’s dive right in. This process offers a lot of room for creativity, and some of the resulting images and videos are intriguing. My idea was to capture a snapshot of the system’s RAM for every frame of a game, and then translate these memory snapshots back into images. I recently began to explore this with the NES. But what if we could peek behind the curtain? What if we could see the machine in action, see its internal states and how it generates those images and sounds? What would games look like from this perspective? Those images on the screen and those sounds from the speaker are but the most familiar outputs of an incredibly complex machine. Be it Mario or Minecraft, Spelunky or Snake, it strikes me that the video output of a video game is far from the only way of looking at things.
0 kommentar(er)
