Scorched Earth - редактор

День добрый. Занялся я редактором ландшафтов для игры Scorched Earth. Практически полностью разобрал формат файла MTN. Сделал 16 (обновлено 28 июня 2014 г.) новых пейзажей для игры в дополнение к существующим. Ссылка. Надо просто распаковать в папку с игрой. Старые горы остаются, новые добавляются в набор.

Если есть интерес, то могу поделиться форматом файла.



Дополнение.
Как показали опыты данные ландшафты работают только на зарегистрированной версии. Подмена файлов в shareware версии не проходит: у программы примитивная проверка на изменения в файлах. Если у вас оригинальная shareware версия, EXE - файл которой не испорчен упаковщиками (UPX, PKLITE), а также вирусами и антивирусами, то можете в моём самодельном редакторе ландшафтов (см. ниже) преобразовать из демо в полную версию (преобразование производится только, если проходит проверка контрольной суммы файла). В полной версии ограничения на использование самодельных ландшафтов нет.

 

Я всё планирую сделать когда-нибудь SE+TW на современной графике. Поделок такого рода полно, но из достойных я знаю только Worms.

 

Дополнил первое сообщение. Загвоздка в Shareware версии (в ней почему-то не работает всё это, даже подменой оригинального MTN файла файлом, мною созданным). Дал ссылку на EXE файл регистрированной (ломаной) версии, в ней работает, если распаковать *.MTN без замены существующих (то есть, с именами такими, какие они есть в прилагаемом архиве). Все ландшафты, как вы, наверное, уже поняли, хранятся в MTN файлах.

Так вот, как устроен этот MTN файл. Вычислял в HEX - редакторе, так что на 100% не ручаюсь.

Формат состоит из 3х основных частей:

1. заголовок - 24 байта,
2. блок палитры 48 байт и
3. блока BITMAP (собственный вариант автора) - переменной длинны.

Теперь по порядку. Пишу в С++ (GCC, MinGW, 32 бит). Заголовок:

Код:

const unsigned char file_signature[6] = {0x4D, 0x54, 0xBE, 0xEF, 0x00, 0x01};
struct Header
        {
          unsigned char           mtn_file_signature[0x6];
          unsigned short int     width;
          unsigned short int     min_height;
          unsigned short int     max_height;
          unsigned short int     colors_used; // always 16
          unsigned long int       pal_and_data_block_size; 
          unsigned short int     dirt_bitmask;
          unsigned long int       unknown; // 0x1F3129FC ???
        } __attribute__ ( (packed));

      struct Palette
        {
          unsigned char r, g, b;
          Palette() {zerobuffer (this, sizeof (*this));}
        };

mtn_file_signature здесь у всех файлов оригинальной игры одинаково, значение из константы file_signature;
width - ширина картинки в пикселях;
min_height & max_height - минимальная и максимальная высота столбца пикселей в картинке (считается от самого низа);
colors_used - всегда 16;
pal_and_data_block_size - размер в байтах данных, идущих после заголовка (для выделения буфера в игре?)
dirt_bitmask - расскажу позже;
unknown - пока не выяснил, что это.

Далее идёт блок палитры - всё просто:

Код:

struct Palette pal[16];

Блок данных. Состоит из нескольких фрагментов, их количество совпадает с width в заголовке. Каждый фрагмент описывает столбец пикселей картинки. Фрагмент начинается с unsigned short int pixels (2 байта), который описывает кол-во пикселей в столбце. Далее идут байты, в каждом байте кодируется по 2 пикселя. Прорисовка в фрагменте начинается снизу вверх. Самый нижний пиксель - это младшая часть 1го байта во фрагменте после его размера (pixels). Соответственно 1й фрагмент кодирует самый левый столбец пикселей, прорисовка по фрагментам происходит слева направо, пока не упрётся в конец, далее рисует зеркально.

Таким образом кодирование возможно только 16ти цветов с VGA палитрой, без учёта прозрачного цвета (структура кодирования изображения исключает надобность в его использовании).

Теперь dirt_bitmask. Насколько я понял, этот параметр задаёт набор используемых цветов из палитры для генерации узора, когда надо нарисовать, скажем, тонну песка. Если хотите, чтобы цвет был однотонный (без узора, одним цветом, например, белым в снежном пейзаже), то здесь надо задать число, равное 2 в степени N.

---------- Сообщение добавлено в 23:54 ---------- Предыдущее сообщение размещено в 23:00 ----------

В Shareware версии имена MTN файлов с размерами зашиты в EXE. Скорее всего, возможность использования своих файлов заблокирована. Пробовал увеличивать размер на 1, можно в EXE поправить, тогда берёт модифицированный файл. Но кол-во файлов, увы, ограничено.

ИТОГ: проще взять EXE от регистрированной версии и не париться.

 

Может CRC32?
У тебя, кстати, __attribute__ ( (packed)); везде работает или ты только на MinGW пробовал?

 

Да не очень-то похоже. Я посмотрел те файлы, что с игрой идут (у них должен CRC отличаться):

Код:

ICE001, ICE002, ROCK001, ROCK002  - 0x38FB29FC
ICE003                            - 0x1F3129FC
ROCK003, ROCK004, ROCK005, SNOW001  - 0x1F3129FC
ROCK006                             - 0x47990C90

Файлы разные, битмап - разный, палитра - разная, размер - разный.
У меня есть 2 предположения, что это может быть.
1) Это просто дыра, заполненная случайными байтами. В игре не используется. Это может быть зарезервированная область или что-то вроде выравнивания.
2) Это какие-то тонкие настройки ландшафта, например:
а) для параметризации выбора начального смещения картинки (выбирается случайным образом), т.к. картинка может быть в ширину очень большая.
б) Может здесь указывается, с каким небом этот фон лучше выводить. Но это маловероятно, т.к. я пробовал забивать это пространство нулями и 0xFF.
в) На палитру не похоже, на точки - да, их тут можно 8 шт влепить, похоже на размер чего-то либо смещение в файле.

Я с Borland C++ под дос очень мало общался, довольно быстро перешёл на DjGPP (DOS), а с него на MinGW. В обоих случаях это GCC компилятор (насколько я понял). У них должно быть всё похоже. С атрибутами начал работать (по-моему) на MinGW.

С другими компиляторами я не работал, поскольку это моё увлечение, с работой никак не связано. Говорят, что только с GCC, кроме того, на некоторых системах (отличных от x86) могут быть проблемы. Так что пользоваться надо с осторожностью.

 

Ну, я в последнее время, отказался от прямой зарузки структур. Именно потому, что где-то может нормально работать, а где-то непредсказуемо. Я в таких случаях делаю структуру, которая сама себя загружает из файла (или потока), каждый элемент в отдельности, используя кроссплатформенные библиотеки, где определены типы. Например wxWidgets или GLM. Ну и сохраняет таким же образом.
Т.е. выглядит примерно так:

Код:

   bool success = read(&size_variable, 1, sizeof(glm::Uint32), file) == sizeof(glm::Uint32) &&
         read(&char_num, 1, sizeof(glm::Uint8), file) == sizeof(glm::Uint8);

Естественно, это всё можно привести к более приятному виду добавив макросы или шаблоны. Проблем со скоростью не замечено, обычно такие структуры довольно короткие.

 

Элементарно, надо проверить sizeof(structure). Offtop

Если совпадает - прямое чтение, если нет, то читать каждый элемент индивидуально. Всё это, конечно, хорошо, пока не сталкиваешься с библиотечным вызовом, где без вариантов надо структуру целиком считать.
Надо было из Excel для офиса связаться со спектрофотометром. Эта сволочь, т.е. vba, делает выравнивание и отключить в этов версии бейсика никак нельзя. Но нашёл выход, пришлось заниматься чем-то вроде memcpy()

 

Всем привет. Программу не забросил, был загруз на работе, плюс - разбирался капитально с графическим интерфейсом Allegro. Привожу скрин альфа-версии.

​

Todo:
1.Сделать возможность выбора цветов для узора грунта (пока только выводит используемые цвета, выбрать нельзя).
2. Интегрировать патч для shareware версии, т.к. она не работает с изменёнными ландшафтами.

P.S. Думаю, что в течение недели выложу тестовую версию.

 

Итак, долгожданный релиз редактора ландшафтных файлов к игре, то есть бетта. Коротко, как работает (читать обязательно).
Сначала про ограничения.
1. Программа является конвектором, то есть не занимается обработкой и подготовкой изображения. Программа ожидает на входе файл, формата BMP, PNG или PCX. Допускается использование режима с палитрой (256 цветов) или без неё, главное, чтобы было не более 17ти уникальных цветов (процедуру по подготовке изображения я опишу в следующем сообщении).
2. Вполне возможно, что программа не будет корректно работать, если полный путь к рабочей папке содержит символы, отличные от латинских.
3. Я не прописывал действия при смене видеорежима и при переходе в ждущий (спящий) режим. Что будет - не знаю.
4. Написана под WinXP, требует DirectX и msvcrt.dll (должна работать и на других системах).

Возможности:
1. Создаёт MTN файлы из специально подготовленных файлов формата BMP, PNG или PCX;
2. Создаёт MTN файлы из картинки, находящейся в буфере обмена системы (ограничения на цвета те же);
3. Открывает существующие MTN файлы, позволяет их сохранять в файлы формата BMP, PNG или PCX. Позволяет задавать цвета, необходимые для прорисовки грунта игрой;
4. Бонус: Создаёт из шароварной зарегистрированную версию.

Тестируйте, сильно не ругайте, опыта в программировании у меня мало. Если будет глючить или вылетать - дам DEBUG версию.

---------- Сообщение добавлено в 21:55 ---------- Предыдущее сообщение размещено в 21:28 ----------

Теперь про процедуру подготовки изображения. Я буду рассматривать на примере программы Photoshop 7.0.
1. Открываем исходное изображение в вашей любимой программе (формат исходного файла не важен), сразу сохраняем в формат, который не портит качество (BMP, PNG), только не JPEG или те форматы, которые не поддерживают более 256 цветов (испортим цветопередачу). Картинки выбирайте большие.
2. Делаем прямоугольную обрезку (выкидываем лишнее). В конце мы должны получить файл, состоящий из (максимум) 17ти оттенков, один из которых - цвет фона (будет выкинут игрой). Поэтому следует выбирать по возможности изображения, не отличающиеся большим разнообразием цветовой гаммы. Я также рекомендую поднять уровни. Это даст 3 положительных эффекта: сделает изображение более сочным, уменьшит количество оттенков, сделает переход между горами и небом более контрастным.
3. Избавляемся от фона (неба). В Photoshop есть замечательный инструмент - фильтр Extract, я им пользуюсь. Extract позволяет избавиться от краевых эффектов, когда цвет неба смешивается с цветом горы. В итоге получается изображение, где вместо неба один сплошной цвет (прозрачный в случае Photoshop).
4. Если у нас где-то скала, нависающая над пустотой, то надо избавиться от пустоты: либо её замазать, либо убрать нависающую скалу. Грунт от низа картинки до границы с небом не должен прерываться пустотами (прозрачным цветом, т.е. небом). Также в случае отсутствия палитры цвет фона не должен совпадать с цветом элементов внутри горы, а в случае палитры атрибут цвета фона не должен встречаться внутри горы. Иначе всё, что будет выше этого вкрапления будет выкинуто и гора получится рваной.
5. Картинка может быть очень большой в ширину, игра будет выбирать случайное начальное смещение, показывая каждый раз (в идеале) "новую" область. А в высоту лучше не переборщить: 400-500 пикселей (при разрешении в игре 800*600) будет оптимальным. И не забудьте оставить пространство над горами: танки надо же где-то ставить. Хотя игра, если надо, сама обрежет низ картинки, если разница между Min height и Max height невелика. В противном случае получим равномерно размазанный слой дёрна по низу уровня.
6. Уменьшаем кол-во цветов до 17ти, включая прозрачность. (Image->Mode->Indexed color), Palette->Perceptular, ставим галку около прозрачности, Forced можно ставить None или выбирать те цвета, которые не трогать. Dither - diffusion, 75%.
7. Сохраняем в BMP или PNG.

P.S. Примеры обработанных картинок я приложил к редактору. Просьба проверить, хватает ли для запуска редактора тех DLL, что я скопировал в дистрибутив.

 

Так можно этот момент в программе обработать:

Код:

int i, j, c;
  <...>
  // по умолчанию - нет ошибки
  errid = ERROR_NO_ERROR;
  // идём по столбцам слева направо
  for (i = 0; i < image.width; i++) {
    // по умолчанию последний используемый цвет прозрачный
    c = TRANSPARENT_COLOR;
    // идём по строкам сверху вниз
    for (j = 0; j < image.height; j++) {
      // если цвет не прозрачный, то сохраним его как последний используемый
      if (image.bitmap[j, i] != TRANSPARENT_COLOR) {
        c = image.bitmap[j, i];
      } else {
        // если же цвет прозрачный, то будем заполнять пиксели последним используемым цветом
        // таким образом, будем заполнять пустоты под горами до нижнего края экрана;
        image.bitmap[j, i] = c;
      }
    }
    // если "c" всё ещё равно прозрачному цвету,
    // значит весь столбец состоит из прозрачных пикселей;
    // заворачиваем такие изображения
    if (c == TRANSPARENT_COLOR) {
      errid = ERROR_EMPTY_COLUMN_FOUND;
      break;
    }
  }
  <...>

Всё запускается, dll-файлов хватает.

 

iunnamed,
Можно, я и сам думал. Если дырки маленькие, то легко заделать. А если нет (10 и более), то лучше заделывать вручную в полноценном редакторе. Там и цветовую гамму лучше подберёшь, чем автоматом.

Игра (в-принципе) поддерживает столбцы, в которых все точки состоят из прозрачных пикселей (ошибки не будет), но может на своё усмотрение добавить пару пикселей снизу в виде грунтового узора (dirt_bitmask).

Пожалуй сделаю коррекцию дырок, но чуть позже. Тут ещё один вопрос: если попадёт один непрозрачный пиксель в область над горой. Получится столбик. Надо и такой вариант обработать. Думаю, что надо выкидывать одинокие 1-2 пикселя, если они вокруг окружены прозрачными.

Я нашёл ещё одну проблему: сделанные мною фоны были протестированы на разрешении игры 800*600. Есть вероятность, что некоторые из них не будут работать на меньшем разрешении (640*480, 320*200). Как мне кажется, дело в разнице между Min height и Max height (выше в инструкции писал об этом).

 

Сделал фильтр изображения для устранения пустот. Немного усложнил алгоритм по сравнению с тем, что предложил уважаемый iunnamed.
Детали

Что даёт: 1) выбирает, чем заполнять: цветом или прозрачностью в зависимости от количества тех или иных точек; 2) выбирает цвет не последний, а наиболее используемый в блоке, где чередуются прозрачные и непрозрачные пиксели. Если замазываем прозрачные, то непрозрачные в этом диапазоне не трогаем.

Код:

enum Return_status Scorch_mountains::create_from_bitmap (BITMAP*bitmap,
    const PALETTE &bitmap_pal, PALETTE &user_pal)
{
 ...
  unsigned char transparent_color_index = 0;
  {
    // Detecting transparent color
    const size_t used_colors_size = 256;
    DWORD used_colors[used_colors_size];
    zerobuffer (used_colors, used_colors_size*sizeof (DWORD));

    for (int x = 0; x < bitmap->w;x++)
      {
        const int color = getpixel (bitmap, x, 0);
        const unsigned char c = color & 0xFF;
        used_colors[c]++;
      }

    unsigned int current_max_colors = 0;
    for (unsigned int i = 0; i < used_colors_size; i++)
      if (used_colors[i] > current_max_colors)
        {current_max_colors = used_colors[i];transparent_color_index = i;}


    //  Detecting and removing "floating" pixels above mountain and "holes" inside ground.
    for (int x = 0; x < bitmap->w; x++)
      {
        int first_opaque_y = -1, last_transparent_y = -1;
        for (int y = 0; y < bitmap->h; y++)
          {
            const bool opaque_color = transparent_color_index != (getpixel (bitmap, x, y) & 0xFF);
            if (first_opaque_y == -1)
              {if (opaque_color)    first_opaque_y = y;}
            else if (!opaque_color) last_transparent_y = y;
          }
        if ( (first_opaque_y == -1) || (first_opaque_y >= last_transparent_y)) continue;

        int transparent_count = 0, opaque_count = 0;
        zerobuffer (used_colors, used_colors_size*sizeof (DWORD));
        for (int y = first_opaque_y; y <= last_transparent_y; y++)
          {
            const unsigned char color = (getpixel (bitmap, x, y) & 0xFF);
            register const bool opaque_color = transparent_color_index != color;
            if (opaque_color) opaque_count++;
            else transparent_count++;
            used_colors[color]++;
            if (y == last_transparent_y)
              {
                register const int pixels_in_block = abs (last_transparent_y - first_opaque_y) + 1;
                register const int yy2 = y - pixels_in_block + 1;
                register const bool fill_with_transparency = transparent_count >= opaque_count;
                if (fill_with_transparency)
                  vline (bitmap, x, y, yy2, transparent_color_index);
                else
                  {
                    int fill_color = 0;
                    current_max_colors = 0;
                    for (unsigned int i = 0; i < used_colors_size; i++)
                      if ( (used_colors[i] > current_max_colors) && (i != transparent_color_index))
                        {current_max_colors = used_colors[i]; fill_color = i;}

                    if (fill_color == transparent_color_index)
                      {
                        fill_color = color;
#ifdef DEBUG
                        NOTIFY_problem_in_log
#endif
                      }
                    vline_special_pixels (bitmap, x, y , yy2, transparent_color_index, fill_color);
                  }
              }
          }
      }
  }
 ...
}

static void vline_special_pixels (BITMAP *where, const int x, int y1, int y2,
                          const int color_to_change, const int color)
{
  if (!where) return;
  if (y1 > y2) swap (y1, y2);
  for (int y = y1; y <= y2;y++)
    {
      register const int c = getpixel (where, x, y);
      if (c == color_to_change) putpixel (where, x, y, color);
    }
  return;
}

. Пример до (in.png) и после (out.png) внизу сообщения.

P.S. Надо ли выводить предупреждение об очень высоком изображении, когда (Max height-Min height)>450 ? Хорошо бы потестировать, какая разница влезает в разные разрешения игры: 320*200; 640*480; 800*600 и т.д.
P.P.S. Если картинка по высоте большая, но разница указанных параметров - маленькая, то игра обрежет лишнее, здесь проблемы нет.

 

Сделал пожертвование автору игры на днях, скачал оригинальный редактор ландшафтов (MOUNTAIN.EXE). Редактор ужасен, без интерфейса, в консоли спрашивает имя BMP файла, требует точно 16ти цветовой BMP и палитру в определённом формате (пришлось помучиться, чтобы он не браковал файл). Из примеров, что идут с редактором, работает только один - двухцветный (нарисован в Paint'е). Остальные - ужасного качества, конвертор не смог их преобразовать: ошибка нехватки памяти. Небо, как и в моём случае, надо замазывать сплошным цветом. В MOUNTAIN.EXE нельзя указать палитру для генерации дёрна (у меня - можно).
С цветам не понял: исходный файл может в принципе содержать 17 цветов, один из которых (цвет неба) в итоге выкидывается.

Так что по-любому мой конвертор превосходит оригинал и по возможностям (можно играться с палитрой для получения узора для дёрна, 1 дополнительный цвет палитры по сравнению с оригинальным), и по удобству (работает с разными BMP и PNG), есть интерфейс, режим чтения-записи в формат MTN и растровых изображений, работа с буфером обмена системы (изображение можно вставлять из внешней программы по предварительной обработке изображений).

P.S. Для чего это затеял. Думал узнать, что делают те мистические 4 байта, назначение которых мне так и не удалось понять.

P.P.S. В регистрированной версии игры дополнительные ландшафты неважного качества (даже хуже, чем те, что идут в shareware версии). Мои - на порядок лучше). От патченной версии, что была в этой теме (по функционалу) по-моему ничем не отличается. Всё то же самое, кроме надписи при выходе.

--- добавлено 3 мар 2018, предыдущее сообщение размещено: 3 мар 2018 ---

Заметил, что в стандартных ландшафтах автор настроил цвета, используемые для генерации дёрна. Или я что-то пропустил, или автор использует другой конвектор, у которого точно больше функционал.

--- добавлено 3 мар 2018 ---

Насчёт этих проклятых 4х байтов:
unsigned long int unknown;

Пробовал конвертировать группу файлов утилитой от автора.
Файлы разные, значение unknown получалось одно и то же.

Обновлено 8го марта 2018 г.​

Выявил закономерность в 2х младших байтах в unknown: они чётко зависят от кол-ва свободной конверционной памяти при запуске программы-преобразователя (MOUNTAIN.EXE). В DosBox загружал её через LOADFIX, который уменьшает кол-во свободной конверционной памяти для указанного приложения на указанной кол-во килобайт. Полученные значения занёс в Excel. Получил абсолютно линейную зависимость, ур-е Y=64X+508. За X брал кол-во памяти (в килобайтах) для FOADFIX Зачем это нужно сохранять в файле - не знаю.

Значение оставшихся старших 2х байтов в unknown пока неясно.

Для SCORCH.EXE контрольные суммы:

Код:

const char *shareware_md5  = "C0F5571AFEABACD770E5669B52F05548";
const char *cracked_md5    = "2B5CCD4DE2C2BDAB7F1A5256FFC5DBA7";
const char *registered_md5 = "19FF909A1D0DC93CB0301F4D14193730";