Repository

https://github.com/spiiin/cadeditor

CadEditor is the universal level editor for NES/SMD/SNES games, I described the project on steemit here.

What feature(s) did you add?

Several previous editor updates were aimed at adding new features and fixing bugs. This update will be focused on improving and adding configs of games supported by the editor.

CadEditor allows you to display the levels of games in the form of pre-prepared block images or build ROM file data blocks.

The first method (with the preparation of pictures) is used when the set of blocks is unknown or it is impossible to build blocks. The developer of the config should prepare screenshots of EACH block used in the game, merge them into one file (strip), and specify a link to this file in the config using the getPicturesFilename function (all functions available to overload in configs described here in Russian now).

The image file might look like this (I cut first a part from a long strip image) :

I wrote several scripts to automate the process of creating screenshots, but some configs developers who are unfamiliar with Python or other scripting languages used Photoshop to glue the blocks manually. Of course, this method requires a lot of effort to prepare block pictures(each level can contain up to 256 blocks!).

However, the other users and I have created configs for more than fifty games in this way.

This method has other disadvantages – the pictures require a lot of space, the users of the editor are limited in the opportunity to change the structure of the blocks and their properties, as well as to work with modified block graphics (the graphics can be redrawn using tile editors such as TLP or YY-CHR).

The CadEditor makes it easy to describe blocks for NES games without using pictures. In the config, developers can describe the functions getBlocksFunc/ setBlocksFunc, which will indicate how exactly the blocks will be read from the ROM file.

I was gradually rebuilding the pictures, and now I have a few steps left to finish this work - there are only 3 games remained, and 187 have already been rebuilt!

It's like you have a 5000 piece puzzle to solve, and there are just a few pieces left.

(Image from wikipedia)

It should be mentioned that I started working on the most simple configs (where the blocks were built in standard ways) then the complex ones were used, so the last stages of the work are more difficult.

I’ve rebuilt almost all the blocks in already created configs, and I also added several configs needed to be fixed which were suggested by the users.

The resulting commits are added to the CadEditor repository in this pull-request .

Rebuild blocks from ROM data instead of using prepared images (CadEditor supports many options and has the library for building blocks, so it is possible to do so). Also, added config for missed games from series Mega Man and Castlevania (1 level for each) and last configs added by _lancuster_ (fixed hard cases by me).

Game list:
  Addams Family, The - Pugsley's Scavenger Hunt (level tree)
  SD Hero Soukessen - Taose! Aku no Gundan (all levels)
  Young Indiana Jones Chronicles (all levels)
  Predator (1 level, without pal layer)
  Super Robin Hood (all levels)
  Mega Man 1 (1 level)
  Mega Man 2 (1 level)
  Mega Man 6 (1 level)
  Castlevania 2 (1 level)
  Castlevania 3 (1 level)
  Kabuki - Quantum Fighter (all level, without pal layer)
  Metal Mech - Man and Machine (all levels)
  Bananan Ouji no Daibouken (Banana Prince) (all levels)
  Youkai Club (1 level, no pal layer)
  Vice: Project Doom (2 levels, different blocks format for each)
  Snake's Revenge (1 level, data is RLE encoded, so save not possible yet)

All the block formats in all the games are listed in a large table (article in Russian), that shows which games are similar in format and which are not (some games of the same series or developers may sometimes differ in format!).

How did you implement it/them?

I will tell you about the various formats of game blocks that I’ve added during the development.

Mega Man 1-2, Banana Prince

I'm using a special script for block search. It reads the content of the video memory and assumes different versions of the block sizes and the method of storage in the ROM file.

I did it for testing purposes, and was a little surprised that it detects blocks in almost all games. I’ve checked about 300 games, and only 23 of them did not show up blocks. One of such games is Mega Man. So I decided to look at it more carefully.

If you open the PPU content in the emulator, you can see that the tiles are in such an order that they form blocks automatically!

Block indexes are not stored in ROM - it not needed.

A game also uses macroblocks, i.e. structures of 4 block indices (and one additional byte of the palette describing the color of each of the 4 blocks.

Interestingly, the same block format is used in the Mega Man 2 game (I've also added it), and in the Banana Prince game.

Commits related to this games:
Mega Man
Mega Man 2
Banana Prince

Mega Man 6

Now I have investigated the Mega Man 1-2 games, and the Mega Man 3-5 games as well (they use a different block format). Naturally, I decided to also check out the latest game of the series on NES - Mega Man 6.

It uses the same block format as 3,4 and 5 parts - the block is described by 2x2 + 1 byte color tiles (2 bits encode color and 6 block type), and the macroblock - 4 block indexes.

However, the format of the levels of this game is still slightly different. If in the previous parts the level was described by screens of 8x8 macroblocks, now the whole level is described by whole lines of 256 macroblocks.

In this format, it is easier to describe the level “layers” that are used to create a parallax effect - a separate movement of the back and front layers, which was not used in the previous parts:

(green lines indicate layers' borders)

Mega Man 6

Addams Family, The - Pugsley's Scavenger Hunt

The game also uses a system of blocks (2x2 tiles) and macroblocks (2x2 blocks). But the color of blocks is stored in a special way. A separate byte is allocated for it, in which 2 bits encode color if the block is in an even position in the game, and 2 bits of color in case the block is in an odd position. This is a special case that is not found in other games.

CadEditor does not yet support the option of setting up separate settings for several colors of blocks for such specific cases, but the game almost does not use this feature - the color of the blocks for even and odd positions are the same. Perhaps this option will be added in the new version (an arbitrary number of block properties).

An example of different color blocks in even and odd positions (flower in the editor and game):

Addams Family, The - Pugsley's Scavenger Hunt

Metal Mech - Man and Machine

Previously, the user named Lancuster added configs for 100 games. He also sent me unfinished configs, which I set aside in a separate folder for studying. This is one of these games.

Standard blocks of 2x2 + 1 bytes for color coding are used in it. However, the color was coded in 3 and 4 bits, which is why Lancuster could not deal with them.

Functions that read and change 3-4 bits of color look like this:

public class MMUtils 
{ 
  public static ObjRec[] getBlocksLinear2x2MaskPal(int tileId)
  {
      int count = ConfigScript.getBlocksCount(tileId);
      var bb = Utils.readBlocksLinear(Globals.romdata, ConfigScript.getTilesAddr(tileId), 2, 2, count, false, false);
      var palAddr = ConfigScript.getPalBytesAddr(tileId);
      for (int i = 0; i < count; i++)
      {
          bb[i].palBytes[0] = (Globals.romdata[palAddr + i]>>2) & 0x3; //read 3-4 bit from byte
      }
      return bb;
  }
  
  public static void setBlocksLinear2x2MaskPal(int tileId, ObjRec[] blocksData)
  {
    int addr = ConfigScript.getTilesAddr(tileId);
    int count = ConfigScript.getBlocksCount(tileId);
    var palAddr = ConfigScript.getPalBytesAddr(tileId);
    Utils.writeBlocksLinear(blocksData, Globals.romdata, addr, count, false, false);
    for (int i = 0; i < count; i++)
    {
        int t = blocksData[i].palBytes[0];
        Globals.romdata[palAddr + i] = (byte)((Globals.romdata[palAddr + i] & 0xF3)|(t<<2)); /store color bits at position 3-4 in byte
    }
  }
}

Screenshot:

Metal Mech

Vice Project Doom

This game is interesting because it contains 2 completely different engines (and two different systems of blocks).
Level 1 uses macroblocks:

The following levels use 2x2 blocks:

Vice Project Doom

Snake’s Revenge

The game uses 4x4 blocks and 8x8 block screens, however it is non-standard in that the screen description is compressed using the RLE algorithm. This is a very simple compression algorithm, and I implemented decompression directly using the getBigTileNoFromScreen function.

  public static int getBigTileNoFromScreen(int[] screenData, int index)
  {
    //hack for unpacking RLE on the fly
    try
    {
        int curScreenIndex = 0;
        do
        {
          if ((screenData[curScreenIndex] & 0x80) == 0x80)
          {
            index -= ((screenData[curScreenIndex] & 0x7F)-2);
          }
          curScreenIndex++;
        } while (curScreenIndex < index);
        if ((screenData[curScreenIndex] & 0x80) == 0x80)
        {
          curScreenIndex++;
        }
        return screenData[curScreenIndex];
    }
    catch (IndexOutOfRangeException e)
    {
        return 0xFF;
    }
  }

This function was used for games where, in addition to the block number, additional information was stored in the byte, and it is not well suited for data decompression, but this is enough to correctly display the level in the editor:

However, for correct saving with compression, I will need to make a separate plugin that implements RLE compression. This format is also used in the Contra game.
Snake's Revenge

Castlevania 2-3

These games also use one of the standard 4x4 block format, it is not complicated to add it. It was just checking out the all parts of the cult series (**Castlevania 1 **has already been added).

Castlevania 2
Castlevania 3

The format of the blocks and screens of each game can be viewed in the table.

The work on block building for the NES games is almost complete, which will allow me to return to adding new features to the editor.

Series backlinks

• CadEditor - Universal level editor for NES/SMD/SNES games
• CadEditor. Support levels with mixed screens
• CadEditor. Release 5.1
• CadEditor - Two new plugins
• CadEditor. Release 5.2
• CadEditor. History of the project
• CadEditor - Animation Editor updates ad Sprites
• CadEditor. Chip & Dale: Tale Spin Levels game
• CadEditor. Release 5.3

GitHub Account

https://github.com/spiiin