Журналы

нулевой урок смотреть было нудно, ибо вода,
единственно, что полезно это узнать где находятся настройки юньки: в преференсе.
далее интуитивно:
1. создал пустой объект в иерархии объектов.
2. создал в инспекторе этого пустого объекта дефолтный скрипт.
3. в скрипте используя подсказку нашёл метод print
итого:

хм, это как высадка на Луну,
первый мой шаг - ничтожный для всего геймдева, но колоссальный рывок для моего проекта.
теперь я вижу, что этот родительский скрипт может стать главным узлом всего проекта.

переключил на VCode:
рез ужасный:

текущий рез:

c префабами:

дальше ...

Ссылка | Комментарии [2]
28 июня 2023

4.
Где рисовать
Количество выпущенного железа в разы больше, чем живущих на планете людей.
И ... я не хочу ничего знать про это железо!

Я буду рисовать в абстрактном двумерном(для удобства) массиве, аля, в матрице!
Вместо пикселей - символы ucs-2(внимание - шрифт консоли не все умеет):

вот моя доска матрица, где я и буду рисовать:

unsigned H = 20 ; /// Высота доски.
unsigned W = 30 ; /// Ширина доски.
wchar_t  C = '.'; /// Символ заполнения.

std::vector<std::wstring> scr(H, std::wstring(W, C));

И всё же нужно выбрать способ вывода на железку, которая мой монитор.
Так выбор сделан на консоль, то:

struct  Hard
{
    Hard& operator<<(const VScreen& scr)
    {   for(const auto& s : scr.mat)
        {   std::wcout << s << '\n';
        }   std::wcout      << '\n';
        return  *this;
    }
};

вот такая доска для рисования:

5.
Как писать код.
три способа на вскидку:
1. В один файл.
2. Много файлов *.h и один main.cpp
3. Много файлов *.h + *.cpp + main.cpp

выберу второй, хотя и проект мелковат, но и как бы будет "по взрослому".

Пишем код так, пишем логику, если логика похожа на олимпиадную задачу,
то убираем такой код в общий раздел.

7.
Из чего состоит игра.
Тут получится план на код:
1. Код общий - логически не связан с тетрисом.
2. Код логически связан с тетрисом.
- Падающая фигура.
- Корзина, сама корзина + её содержимое.
- Клавиатура.
- Банеры.
- Игра(главный игровой цикл).

8.
Тесты.
Тесты хороши не только ради тестов, но и автоматом склоняют к лучшему проектированию программы. Чтобы тесты не захламляли основной код, то для них я заведу второй проект.
Заключительный тест - это итоговый релиз.

9.
Релиз.
Это не первый мой тетрис.
По итогу релиз будет выглядеть примерно так:

На самом деле я полностью перепишу код демонстрируемый гифкой выше.

Это было вступление ...

(продолжение ...)

Ссылка | Комментарии [85]
10 июня 2023

В комплекте два рабочих стола (для отладки и без оного) которые повторяют расположение окон ide delphi последних версий.
Импортируем и наслаждаемся =)

https://github.com/FlKo/LazarusDockedDesktops

Ссылка
17 сен 2017

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

• Master Server
  Управляет другими серверами, его метод Update вызывает обновление всех остальных серверов (остальные сервера являются экземплярами этого сервера).
  Что тут говорить, если основной цикл игры выглядит примерно так:

  while(true) {
      g_pMasterServer->Update();
      g_pTimer->AdjustTime();
  }

• GameObject Server
  Хранит игровые объекты с ссылками на подчиненные партиклы/модели/коллайдеры.
  Группирует объекты в чанки карты (cxt).
• Animation Server
  Управляет анимацией, при этом оперирует малейшими примитивами (matrix4, vector2), умеет интерполировать между временными промежутками.
• Script Server
  Логика игры. Кстати, все игровое меню сделано через него и лежит в одном файлике.
• GFX_CLUT Server
  Управляет буферами, подготавливает пакеты для передачи их в графический процессор.
• Texture Server
  Инстансы этого сервера связывают буферы CLUT(Color lookup table или палитра) и GFX(индексы для палитры). Также экземпляры текстур могут "наследоваться" друг от друга, это, например, используется для "mip" текстур, в данном случае маленькая текстура наследует палитру большей.
• Material Server
  Очевидно что инстансы этого сервера содержат ссылки на разные текстуры (отражений/цвета), цвет, параметры освещения, тип смешивания.
• RenderMaster Server
  Сервер создает несколько подопечных серверов, вот некоторые из них:
  • Particle Render Server
  • Flash Render Server
  • Shadow Render Server
  • Static triangle strip Render Server
    Все они в сумме работают над одной задачей - подготовить в памяти один большой пакет, который в итоге отрисует один кадр. В нем будут все модели/матрицы/программы для векторного процессора/переключения контекста/текстуры. Это все делали для того чтобы dmac контроллер шины разбирая этот большой пакет занимался отрисовкой текущего кадра, когда мы сможем готовить новый пакет для следующего кадра. При этом получается максимальное распараллеливание, когда 4 устройства: центральный процессор, контроллер шины, векторный процессор и графический процессор работают параллельно. Ну не совсем прям параллельно, например локи синхронизации между векторным процессором и графическим, чтобы первый не начал рисовать модель, когда её текстура еще не загружена, и в таком роде. Но вот лучше не придумаешь. При этом картинка страдает в задержке (пакет текущего N кадра формируется в памяти, N-1 кадр рисуется в swap-buffer, N-2 кадр на экране) в сравнении с привычной нам схемой (N кадр рисуется в swap-buffer, N-1 на экране), но выигрывает в пропускной способности.
• Epilogue Server
  Prologue Server
  Пролог сервер отрабатывает свой Update раньше остальных, при этом создает разные буферы для "отрисовки" кадра.
  Эпилог сервер обновляется последним, при этом инициирует swap буферов и обработку пакета со следующим кадром dma контроллером.
• Collision Server
  Управляет физикой. Содержит глобальную переменную гравитации, что не раз помогало в исследовании работы движка.
  Так-же влияет на подгрузку чанков карты. Точнее каждый чанк карты содержит инстанс статичной коллизии, привязанный к этом чанку. И определение на принадлежность игрока к чанку как-раз определяется через коллизию.
  + Фотография рабочего места разработчика, с отображением статичной коллизии чанка уровня в редакторе

Итог

Благодарности

А так же в разборе наследования классов мне помогает компилятор, которым пользовались разработчики. Он вежливо переопределяет таблицу виртуальных методов класса в конструкторе и деструкторе этого экземляра класса, а так как деструкторы/конструкторы класса почти всегда вызывают соответствующие конструкторы/деструкторы своих родителей, тем самым можно извлечь древо наследования (часто мешает inline подстановка).
Кроме того компилятор очень аккуратно расставляет указатель на таблицу виртуальных методов сразу после полезных данных структуры экземпляра класса, из чего мы можем делать вывод о размере этой структуры данных (работает только для самых корневых (не детей, а от которых наследуются) классов).
Так же если он видит вложенную структуру, то перед там как поработать с ней, любезно высчитывает указатель на эту структуру, а потом уже начинает работать с ней (из этого можно судить о наличии этих вложенных структур и их смещение относительно основных).
Конечно у него есть и минусы, но я его прощаю, ведь они присущи всем компиляторам с флагом -O2, а именно сплошь и рядом подстановка функций (inline), что заставляет разбирать похожие места кода лишь чтобы убедиться что они делают то-же самое.

todo

Ссылка | Комментарии [4]
24 ноя 2016