Оберон-клуб «ВЄДАsoft»
https://zx.oberon.org/forum/

ZXDev + спрайты
https://zx.oberon.org/forum/viewtopic.php?f=10&t=198		 Страница 1 из 1
Автор:  Zorko [ 23 май 2014, 14:40 ]
Заголовок сообщения:  ZXDev + спрайты
Адаптировал для ZXDev библиотеку libspr, выложенную SfS в теме "Спрайты, ps/2 и куча утилит".
Код: "OBERON"
Expand Code | Выделить всё
  1. MODULE DemoSpr; (*$MAIN*)
  2. IMPORT B := Basic, Spr := GrSpr;
  3.  
  4. VAR
  5.   spr0, spr1, spr2, spr3: Spr.Sprite; i: SHORTINT;
  6.   coords: ARRAY 4 OF RECORD x, y: Spr.Coords END;
  7.  
  8. BEGIN
  9.   B.DEFDATA(spr0, 157*11 + 5);
  10.   ...
  11.  
  12.   coords[0].x :=  0; coords[0].y :=  0;
  13.   coords[1].x := 16; coords[1].y :=  0;
  14.   coords[2].x :=  0; coords[2].y := 12;
  15.   coords[3].x := 16; coords[3].y := 12;
  16.  
  17.   coords[0].x :=  0; coords[0].y :=  0;
  18.   coords[1].x := 16; coords[1].y :=  0;
  19.   coords[2].x :=  0; coords[2].y := 12;
  20.   coords[3].x := 16; coords[3].y := 12;
  21.  
  22.   B.BORDER(B.Black); i := 0;
  23.   LOOP
  24.     Spr.DrawSprite(coords[(i  ) MOD 4].x, coords[(i  ) MOD 4].y, spr0);
  25.     Spr.DrawSprite(coords[(i+1) MOD 4].x, coords[(i+1) MOD 4].y, spr1);
  26.     Spr.DrawSprite(coords[(i+2) MOD 4].x, coords[(i+2) MOD 4].y, spr2);
  27.     Spr.DrawSprite(coords[(i+3) MOD 4].x, coords[(i+3) MOD 4].y, spr3);
  28.     INC(i); B.PAUSE(50);
  29.   END;
  30.  
  31. END DemoSpr.


Вложения:
DemoSpr.zip [3.91 КБ]
Скачиваний: 958
Автор:  Reobne [ 18 июн 2014, 05:07 ]
Заголовок сообщения:  Разработка игр и программ для ZX Spectrum на языке Оберон-2
Как связать вместе мультиплатформенность, модульность и ресурсы?

Вот например спрайты. Нужен спрайтовый редактор, с полным качеством: высокое разрешение и 24бита на точку.
Нужны конкретные спрайтовые движки на конкретные платформы, но с единым интерфейсом. Они должны (кроме основной функции вывода спрайта) предоставлять базовому редактору плагины конвертации базовых спрайтов в их формат, и функционал ручного дотыкивания пикселей после этой конвертации.

Я себе это так представляю. Базовый спрайт это вьюшка на КПаскале. Потом есть редактор конвертеров, например как в звуковых редакторах, окно, на которое можно накидать конвертеры, исходные ресурсы, конечные ресурсы в виде блоков со входами и выходами, потом соединить нужные входы с выходами, зайти в настройки конвертеров, настроить их. Этот граф можно сохранить. Можно прогнать, получится файл ресурсов для конкретного спрайтового движка.


Да, размечтался... В общем первый вопрос, есть-ли стандартизированный интерфейс спрайтового движка. (Наподобии Дубовых интерфейсов ввода-вывода.)
Автор:  Zorko [ 20 июн 2014, 23:44 ]
Заголовок сообщения:  Re: Разработка игр и программ для ZX Spectrum на языке Оберон-2
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
Страница 1 из 1 Часовой пояс: UTC + 2 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/