On the Tiles

 

When designing art for the Sega Megadrive, it's important to understand how the console handles graphics. The Megadrive uses a custom graphics chip called the Visual Display Processor or VDP. The VDP is tile-based - graphics are stored in tiles that are 8x8 pixels big. Sprites are split into tiles which are then read in sequence to display them. Each of the tiles references one of the 4 colour palettes available. The above image shows how the VDP has stored the graphics from the main window and the 4 colour palettes being used. (The 5th line of colours is not in the data, but used by the Gens emulator for testing).

8x8 tiles are the basis for all the graphics. So all sprites and game tiles have to conform or fit into multiples of 8, e.g.: 16x16, 32x32, 16x48, 8x24, etc.

The VDP stores all this information in it's VRAM, which is limited to 64K. One of the tricks the Megadrive can use is to use DMA (Direct Memory Access) to copy data from the game ROM to the VDP. This takes some processing time, but used wisely it can allow graphics to be animated using data stored in ROM rather than it all being stored in VRAM. The sprite tiles are placed in a VDP location, but the actual data is copied across from ROM into that space every frame (or every few frames depending on the frame rate you want the animation to play at). This saves space in the VRAM and allows more frames of animation.

Large sprites can be animated by changing just a few of their tiles. This means that you need to be careful of how the animated sections fit into their 8x8 boundaries. Another advantage of this is that sprites can be compressed more easily if more less tiles are animated. For example this toast only animates the center tiles where the face is.

 
 
Another example is this cheese. The image can be compressed by only storing the tiles that are different. Tiles that are the same can just be stored once and then re-used to rebuild the original image. Here the red outline shows identical "hole" graphics, and the white outline shows tiles that can be flipped to create the other side of the cheese. The graphics need to be processed accordingly developer-side, the Megadrive won't do it for free!


So, being careful to use the 8x8 grid when designing the graphics is important! Another thing to consider is how the collision will apply. Box collision is fastest, so making sprites that fill those boxes helps. You can read more in-depth about the VDP over at Raster Scroll

Comments

Post a Comment

Popular posts from this blog

Converting Gunslugs to Megadrive / Genesis

Image
Overview This is all about porting Gunslugs, a PC game written in Java (by OrangePixel  ) to SEGA Genesis / Megadrive, written in 68000 assembler. Original Game (PC) Genesis Conversion Code Objects / Entities There are quite a lot of active objects at once in the original game- something lke 100-200 plus bullets and effects. This would not be doable on the Genesis, so instead I generate a list of spawn points for level objects. These are sorted horizontally so that I only need to check one at a time as the screen scrolls. Once a spawnpoint is determined to be just off the right edge of the screen, it is promoted to being an active GameObject, and the spawer code continues looking for the next object in the spawner list. Early on I knew there would be a problem with this, due to objects disappearing off the left of the screen. In the original these continue to be active. But at the start I didn't know enough about the game to determine what to do about it. In other games I'd uns
Read more
Image
 Heroes Of Loot Java to Genesis conversion. Day 0 Looked at the original dungeon generation source code and decided to move from Java to c# so I could add it in to my tooling.For now I'll be creating the dungeons on PC side, and perhaps move this over to 68000 later.  It's going  to be a tricky conversion. I am thinking of refactoring all the Java code first, to make it more data-driven, so that when this works on PC , I can convert it to Genesis much more easily, using the same data. The main advantage of this is to be sure there are no bugs in the conversion, which will be hard to spot later. Day 1 Started a new code project by copying GunSlugs codebase. Converted the Java dungeon code over, in part, and got that working in the tool, complete with being able to display the results. Then got this exporting to 68k data tables and importing on to Genesis. I added a handful of sprites, and also exported a background tile set. This is all using the new Winforms Snake Editor, which
Read more

Mega Palettes

Image
  Ah, the Sega Megadrive, halcyon days. I remember pre-ordering mine from Special Reserve and eagerly awaiting the launch date. They sent me a copy of Super Monaco GP and a second control pad, which I got to stare at for a week before the console itself finally arrived. It was worth the wait. I still own one today. If you're going to make graphics for a Megadrive game, then you're going to be spending a lot of time with palettes! Aside from the pixel art program Aseprite, the most useful graphics tool I have is a post-it note stuck to the monitor with the numbers 0, 52, 87, 116, 144, 172, 206, 255 written on it. I am almost exclusively using Aseprite to produce the graphics for Rocket Panda, and occasionally Cinema4D to render any 3d animated objects which then need to be processed through Aseprite. The end result is a series of sprite and tile sheets which are mapped to particular palettes. Creating these palettes is the crux of the operation and has to be nailed down fairly e
Read more