Здравствуйте.
Тема не то что невозможная, она скорее крайне геморная. Вряд ли сильно ошибусь в предположении, что работа с каждым ресурсом захардкожена, и все основновные параметры определены прямо в экзешнике.
В отличие от логичной упаковки группы файлов в единый ресурс с возможностью обращения к нужному файлу по имени, в Князе данные располагаются последовательно, один за другим. Но это было бы полбеды.
В NEWHERO.RES файлы хранятся в одном формате, в SOUNDS.RES - в другом. И этих форматов более двух, из-за чего нужно описывать отдельную логику под каждый ресурс (да, некоторые повторяются, но сильно легче от этого не становится). Кроме того, из-за отсутствия «имён файлов» внутри ресурса, что обращение к конкретному файлу происходит по порядковому номеру, что-что вроде: возьми файл № 3 из NEWHERO.RES и выведи его на экран в позицию [X, Y].
Чтобы подготовить Вас к ужасу, могу рассказать про формат ресурса NEWHERO.RES
В нём содержится 11 изображений, которые игрок видит на странице новой игры (выбор персонажа). Порядок файлов внутри строго задан, обозначение веду с нуля ибо у прогов так принято:
0 - общий фон
1 - Ратибор (портрет при выборе героя, чуть ярче картинка)
2 - Велиславна
3 - Эйнар
4 - Хельга
5 - Александр
6 - Анастасия
7 - кнопка Отмена
8 - кнопка Отмена при клике на неё
9 - кнопка ОК
10 - кнопка ОК при клике на неё
Файлы следуют друг за дружкой. Формат такой:
4 байт - размер «файла» в ресурсе - SIZE.
Далее в буфер считывается полученное число байт, которые тоже нужно парсить. Формат следующий:
Widht - 2 байта - ширина_картинки
Height - 2 байта - высота_картинки
LENGHTS[] - (2 * Height) байт - последовательно: длина каждой строки в упакованном виде
DATA - строки изображения в упакованном виде - до конца буфера.
Как работать со строками. Читаем из DATA количество байт, полученных в LENGHTS[0]. Строка представляет собой вариацию RLE, для распаковки данных:
1) Читаем 1 байт - BYTE. Формируем строку изображения - LINE.
2) Если BYTE равен нулю - конец данных
3) Если он больше 127, записать (BYTE - 127) прозрачных символов в LINE. Прозрачный символ - строка из 2 байтов: 0x1F и 0x7C.
4) Если BYTE < 128 - прочитать (BYTE * 2) следующих символов в в LINE.
5) Читаем следующий байт. Переходим на 2)
С первой строкой закончили. Переходим ко второй: читаем из DATA следую порцию данных, количество байт из LENGHTS[1].
Парсим строку.
И т. д., пока не закончится это изображение.
Дальше переходим ко второму изображению: снова читаем 4 байта размера (SIZE), после этого закачиваем в буфер SIZE байт. Опять парсим размеры изображения, размеры каждой строки, после парсим каждую строку.
Продолжаем пока файл не закончится. На выходе будем иметь распакованные данные изображения.
Несколько моментов.
a) Байты в файле пишутся в машинном виде (обратный порядок).
b) Изображения (именно в этом ресурсе, в других может быть не так) в формате hi-color, т. е. 2 байта на пиксель. В двоичном виде это выглядит как: 0rrrrrgg gggbbbbb. В true-color на каждый пиксель приходится по 3 байта, это уже знакомые нам компоненты красного, зелёного, синего.
Перевод к hi-color довольно тривиальная операция: сначала нужно уменьшит количество битов с 8 до 5 (сдвигом вправо на 3: R >> 3 = rrrrr, G >> 3 = ggggg, B >> 3 = bbbbb), а потом разбросать их по компьютерному слову (word), что делается легко через те же сдвиги, но уже влево: (rrrrr << 10) + (ggggg << 5) + bbbbb
Эти рассуждения пригодятся, если захочется написать сборщик ресурсов. Подготавливаете группу файлов (полноцветные png или bmp или ещё что) последовательной нумерации, после чего поочерёдно упаковываете и размещаете друг за дружкой в ресурсе.
В итоге может получиться что-то вроде этого:

