Reobne писал(а):
Как связать вместе мультиплатформенность, модульность и ресурсы?
Ресурсы у нас конечно платформо-зависимые, но зато методы работы с ними можно попробовать унифицировать в какой-то единый интерфейс. И посмотреть насколько мы далеко зайдём. Я себе это представляю так: в отдельном модуле, скрывающем внутреннее устройство ресурсов (либо массив данных, заданный прямо в коде, либо подгружаемый файл (или несколько) ресурсов) описываем и экспортируем наружу тип ресурса и идентификаторы, соответствующие ресурсам. Это могут быть порядковые номера, адреса в памяти, а в случае 128кб-Спектрума — страница+смещение. И даже наверное строковые сигнатуры типа имён файлов, хотя последнее наверно уже перебор.
Конечно нужны воспомогательные средства для автоматизации подготовки ресурсов, и мне очень нравится способ, с помощью которого вы это предлагаете достичь, потому что я мечтаю о чём-то подобном.
О встроенных в XDev редакторах тайловых карт и анимированных спрайтов, автоматизированных средств для подготовки ресурсов в различных форматах и т.п. Но это уже далёкая перспектива, пока же остановимся на готовом инструментарии.
Есть несколько проблем в выработке взгляда на кроссплатформенные интерфейсы для работы со спрайтами. Например, в отдельных случаях могут отличаться возможности платформ даже по взгляду на то, что такое спрайт. У ретро-платформ есть особенности, связанные с цветностью (двухцветные атрибуты как у Спектрума), с системой координат (может случиться так, что оптимальнее выводить с выравниванием по сетке 8x8 точек) и т.д. Для ретро-платформ активно используются логические операции AND, OR и XOR, вывод с маской и с прозрачностью, палитры. Для более мощных платформ – альфа-канал или даже аппаратное управление фазами анимации. Вобщем, совместить действительно трудно, — не исключено, что вообще невозможно: придётся всё затачивать под “ретро-платформы”, но тогда за бортом останутся мощные возможности, либо же забыть про ретро. Но можно и так, и так, почему нет.
Вариант № раз — “Мы дружим с ретро”:
Такое впечатление, что наиболее близко к варианту кроссплатформенной графической библиотеки для ретро-платформ подходит
SPLIB1. Вот интересная игра:
Phantomas Saga Infinity (CEZ GS 2006) — SPECTRUM, AMSTRAD, MSX. Очень показательный пример. Написана на Си в среде z88dk, инклюдит заголовок spritepack.h, и, как я понимаю, это и есть включение SPLIB1. Я нашёл только исходник для Спектрума, но он сильно заточен под Спектрум. Поэтому выдвигаю предположение, что игра содержит 3 различных исходника для SPECTRUM, AMSTRAD и MSX. Но все они написаны на Си, собираются z88dk и используют SPLIB1. Так что надо присмотреться к SPLIB1.
Вариант № два — “Мы не дружим с ретро”: GDI, DirectX, SDL(1 и 2), OpenGL. Если нам нужна кроссплатформенность, а, уверен, что не помешает, то мне очень импонируют средства разработки для различных платформ с единого исходника от Марка Сибли:
Blitz3D и
Monkey:
Цитата:
Для разработки игр используется модуль mojo, который поставляется вместе с Monkey. Этот модуль предоставляет разработчику кроссплатформенный API для работы с 2D-графикой, звуком и устройствами ввода. Возможности фреймворка несколько ограничены и связано это, в первую очередь, с необходимостью поддержки множества платформ. Не все возможности доступные на одной платформе доступны на другой. Если какая-то «фишка» недоступна хотя бы на одной из платформ, то она не будет включена в mojo. Конечно, это несколько радикально. Но в тоже время, вы сможете быть уверены, что ваше приложение будет одинаково работать на всех платформах.
Вторая причина столь скромного функционала — простота добавления новых платформ. Технологии меняются с невероятной скоростью. То тут, то там появляются новые устройства и операционные системы. Именно поэтому, возможность оперативного добавления поддержки новой платформы, дает неоспоримое преимущество перед другими подобными инструментами.
Игровые фреймворки
Конечно, функционала mojo недостаточно для написания полноценной игры. Ведь игра — это не только работа с графикой, звуком и устройствами ввода, но и пользовательский интерфейс, различные состояния, тайлы, анимация, физика и прочее. Всего этого в mojo, к сожалению, нет. Но на помощь приходят игровые фреймворки, и другие модули, созданные сообществом Monkey.
Я не очень большой специалист по графике и спрайтам, сам учусь, поэтому это не более чем направления для исследований, которые мне кажутся интересными.
Reobne писал(а):
Да, размечтался... В общем первый вопрос, есть-ли стандартизированный интерфейс спрайтового движка. (Наподобии Дубовых интерфейсов ввода-вывода.)
Наверное в Оберон-мире такого нет, мне ничего подобного не попадалось. Но я бы изучил что сделано в этом смысле для Амиги (
исходники клуба AMOK), хотя бы на уровне интерфейсов. Впрочем, на Модуле и Обероне традиционно игры не пишут, ну разве что
Arkeroid. Так что придётся что-то из готовых спрайтовых движков позаимствовать.
Вот кое-что нашёл интересненькое, но совсем простая штучка. Можно использовать в качестве базы для выработки собственного движка. Насколько он будет сложный — зависит от того, насколько далеко мы захотим углубляться в это направление. Можно и фазы анимации автоматизировать, и поддержку кучи форматов внедрить, и 3D-модели с текстурами, камерами и источниками освещения. Мне бы очень хотелось векторные спрайты. Но начинать надо конечно с чего-то попроще.
Прошу прощения за плохое качество, в лучшем просто нет — материал очень раритетный:
•
Modula-2 в производстве компьютерных игр.pdf
Вход
FAQ
Поиск
