Самодельный 3D движок с открытыми исходниками

[Shaos]

А вообще надо возрождать коммьюнити - сделать к примеру на virtburg.com сайт-лицо для простых юзеров (кстати это доменное имя я получил совсем недавно - в июле этого года), а vburg.com будет техническим сервером для архитекторов и программистов (а этим доменом я владею уже четвёртый год), у меня был ещё virtburg.net, но я его отпустил какое-то время назад - он вроде ещё свободен...

В начале июня 2009 решил было отпустить домен virtburg com и сконцентрироваться на оставшемся vburg.com, а щас вот думаю может продлить таки virtburg com и возможно даже прикупить обратно virtburg net?...

Прикупил обратно virtburg.net т.к. он до сих пор был свободен (правда пока не до конца понимаю для чего), а вот vburg.com (c 2012) и virtburg.com (с 2014) принадлежат каким-то жуликам-перепродавцам...

virtburg.com освободился и мне прислали какие-то левые ребята письмо:

We are happy to inform you that virtburg.com is now available for purchase.

It is currently available at the affordable price of only 39.90.

We encourage you to secure it before it's taken by clicking here.

To no longer receive future emails from us, please click here.

"There is not much less vexation in the government of a private family than in the managing of an entire state." -Michel de Montaigne

Я просто пошёл и купил этот домен напрямую (через gandi.net) за $14.50 и послал ребятам благодарственное письмо за наводку
Не понимаю честно на что они рассчитывают когда такие письма посылают ДО того как они собственно перехватили домен?
Я уже второй раз таких "дельцов" обвожу вокруг пальца...

Наверное надо отпустить virtburg.net и оставить только virtburg.com как главный сайт проекта Virtburg, который я рано или поздно реанимирую...

В данный момент я владею ТРЕМЯ виртбуржскими доменами:

Code: Select all

> whois virtburg.com
   Domain Name: VIRTBURG.COM
   Registry Domain ID: 2046746624_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.gandi.net
   Registrar URL: http://www.gandi.net
   Updated Date: 2024-07-02T06:58:24Z
   Creation Date: 2016-07-27T11:51:27Z
   Registry Expiry Date: 2025-07-27T11:51:27Z
   Registrar: Gandi SAS
   Registrar IANA ID: 81
   Registrar Abuse Contact Email: abuse@support.gandi.net
   Registrar Abuse Contact Phone: +33.170377661
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: NS-144-B.GANDI.NET
   Name Server: NS-222-C.GANDI.NET
   Name Server: NS-68-A.GANDI.NET
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2024-11-28T06:14:20Z <<<

Code: Select all

>  whois virtburg.net
   Domain Name: VIRTBURG.NET
   Registry Domain ID: 2331805904_DOMAIN_NET-VRSN
   Registrar WHOIS Server: whois.gandi.net
   Registrar URL: http://www.gandi.net
   Updated Date: 2024-11-16T19:25:33Z
   Creation Date: 2018-11-12T02:11:49Z
   Registry Expiry Date: 2025-11-12T02:11:49Z
   Registrar: Gandi SAS
   Registrar IANA ID: 81
   Registrar Abuse Contact Email: abuse@support.gandi.net
   Registrar Abuse Contact Phone: +33.170377661
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: NS-145-A.GANDI.NET
   Name Server: NS-189-C.GANDI.NET
   Name Server: NS-47-B.GANDI.NET
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2024-11-28T06:16:20Z <<<

Code: Select all

> whois virtburg.org
Domain Name: virtburg.org
Registry Domain ID: 43e4e504bf5e4819bd9541d16b21c058-LROR
Registrar WHOIS Server: http://whois.gandi.net
Registrar URL: http://www.gandi.net
Updated Date: 2024-11-16T19:25:33Z
Creation Date: 2020-10-30T05:27:40Z
Registry Expiry Date: 2025-10-30T05:27:40Z
Registrar: Gandi SAS
Registrar IANA ID: 81
Registrar Abuse Contact Email: abuse@support.gandi.net
Registrar Abuse Contact Phone: +33.170377661
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod

Ну и плюс старый сайт на народе http://vburg.narod.ru перекидывает на http://virtburg.com

А на днях ещё завёл страничку на itch.io: https://virtburg.itch.io/

P.S. и аккаунт в социальной сети Bluesky с аналогичным именем virtburg.itch.io

https://bsky.app/profile/virtburg.itch.io

[Shaos]

Решил снова сесть с секундомером и перемерять - от стенки до стенки сектора (62 куба или 186 метров если считать 3 метра на куб):
обычным шагом персонаж проходит за 24.9 секунд, что есть 7.47 метров в секунду или 26.9 км/ч,
а с нажатым шифтом - за 8.3 секунды, что есть 22.41 метров в секунду или 80.7 км/ч.

Один коэффициент у меня был изменён какое-то время назад - вернул как было раньше (все подпрыгивания, пробегания и углы рассчитаны для 55 мс или 18.2 раза в секунду типа для совместимости с досом) и перемерял:
обычным шагом получилось 27.3 секунды или 24.53 км/ч,
а бегом - примерно 9.2 секунды или 72.78 км/ч,
ну т.е. грубо говоря 24 км/ч и 72 км/ч

P.S. Ещё померял у себя повороты - с нормальной скоростью полный поворот на 360 градусов осуществляется за 7 секунд, а с шифтом - за 3.5 секунды

P.P.S. Померял в думе - там 3 секунды на полный поворот независимо от того был нажат шифт или нет, так что я наверное тоже сделаю одинаково...

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

Дети просят поддержать W, A, S и D наряду со стрелками для движений - как в майнкрафте или роблоксе по умолчанию...

Это у меня оказывается уже сделано наряду со стрелками - видимо как дети в 2020 году попросили, так сразу и сделал...

P.S. Посмотрел по архивам - 27 октября 2020 года я поддержал WASD т.е. ровно в тот же день, в который я об этой просьбе своих детей тут написал

[Shaos]

P.P.P.S. Не - логику анимации я уже предполагал тогда же т.е. анимацию можно сделать прямо сейчас. Ещё прям сразу можно поддержать "карты спрайтов", когда разные итерации персонажа (и даже разных персонажей) навтыканы в одну картинку с фиксированным шагом, например такой объект можно описывать так:

Code: Select all

o0001 6.2 5.7 0 1.3 swin_2x3:5

что может означать, что мы берём TXR-файл swin_2x3.txr и предполагаем, что там сетка 2х3 из которой мы берём 5-ую по счёту картинку (если считать слева-направо-сверху-вниз начиная с нуля), а если там анимация 2 Гц, то так:

Code: Select all

o0001 6.2 5.7 0 1.3 swin_2x3:5,swin_2x3:4

(т.е. 2 картинки через запятую дают анимацию 2 Гц, а 3 картинки - 3 Гц и т.д. что даёт цикл анимации всегда ровно в 1 секунду).

Чтобы это всё поддержать надо добавить ещё один уровень абстракции:

- ObjLib это динамический массив объектов shObject;
- shObject это объект, который может ссылаться на разные либо один и тот же спрайт shSprite (+несколько спрайтов?);
- shSprite это абстрактный спрайт - сейчас один TXR-файл/картинка, но в будущем должен иметь возможность ссылаться на несколько картинок либо на разные части одной и той же картинки (чтобы поддерживать анимацию и вырезку кусочками);
- shImage это будет НОВЫЙ объект, обозначающий картинку, загруженную в память из TXR-файла (TXR формат это 2D картинка в 256-цветной палитре GamePal размером до 256х256 пикселов без сжатия).

P.S. Только надо будет переименовать эти штуки так, чтобы префикс был Virt, а не sh.

P.P.S. В будущем надо будет ещё и мой графический формат 1995 года MYG поддержать - там есть прозрачность и RLE сжатие...

[Shaos]

Экспериментирую с разными человечками из наборов спрайтов с itch.io:

Screenshot from 2024-11-30 20-18-26.png (436.33 KiB) Viewed 415 times

P.S. Что-то наверное надобно текст векторный делать, чтобы поверх экрана писать т.к. рендеринг картинки может делаться в окошки/экраны разного размера (от 640x480 вплоть до 1920x1080) поэтому текст должен масштабироваться, чтобы в пределах экрана всегда было скажем 80x30 букв - ниже пример окна 640x480:

Screenshot from 2024-11-30 23-00-16.png (101.94 KiB) Viewed 409 times

P.P.S. Либо масштабировать этот шрифт 8х8 в нецелое количество раз чтобы на экране всегда было 80x60 квадратных букв, причём шрифт будет оставаться растровым - так пожалуй будет проще всего...

[Shaos]

Теперь надо панорамы с GIF на JPG перевести (потребуется задействовать jpeglib для этого - причём он уже есть в линухе), попутно переделав фотканье экрана по кнопке F2 с TGA тоже на JPG (может быть JPG-текстуры тоже поддержать наряду с TXR?), а также прибить последнюю пару C++ классов и выложить наконец virtburg.c
...
Попутно проверил работу движка в полном HD-разрешении 1920x1080 - выдает 30 с небольшим FPS на моём AMD64 компе. Наверное надо принять это разрешение как максимально возможное - тогда максимальный горизонтальный размер панорамы будет 1920*8=15360 пикселов (8 потому что горизонтальный угол обзора у меня сейчас установлен в 45 градусов, соответственно все 360 это 8 раз по столько). Если панорама меньше, то она будет растягиваться линейной интерполяцией прежде чем будет преобразована в мою игровую палитру. Высота панорамы не должна превышать тройной высоты экрана (выше просто не удасться задрать голову в текущей версии движка) или максимум 1080*3=3240 пикселов. Если панорама ниже по высоте, то верхняя и нижняя строчки просто будут копироваться выше и ниже доступной картинки, причём середина панорамы всегда будет считаться линией горизонта.

Ну что - через 4 года возвращаюсь к недопиленному движку

Первым делом надо поддержать JPG-панораму - причём при загрузке её надо будет переводить в игровую 256-цветную палитру, делая аппроксимацию цветов с точностью до пикселов экрана. Заодно можно поддержать сдвиг линии горизонта, если она вдруг была не точно по середине высоты панорамы.

Посмотрел в коде - у меня выделяется 4 раза высоты экрана, т.е. по вертикали буфер 1080*4=4320 пикселов (хоть голова и опускается-задирается только на полторы высоты, т.к. буфер по вертикали всё таки должен быть 4 экрана иначе будут глюки). Размер такой панорамы в памяти составит 63 мегабайта при разрешении экрана 1920x1080 - надо прикинуть как долго оно будет генерить попиксельный дизеринг из RGB (мне надо это делать при каждом переходе из сектора в сектор) - если слишком долго, то тогда надо делать панораму меньшего разрешения...

P.S. В такую панораму можно ведь программно рисовать по ходу пьесы!
Надо будет когда Robby скрипты подтяну пробросить рисование туда скажем через PLANE -1 и затем COLOR C и PIXEL X Y

[Shaos]

7) возможно потребуется директива include (я пока не сильно уверен в её необходимости) и наверное макросы (у которых имена будут начинаться например с символа $).

Можно наряду с include поддержать условную интерпретацию 3dm-файла - скажем добавить директивы препроцессора, которые начинались бы с %

Code: Select all

%include filename
%define name something
%if name=something
... 
%elseif name=somethingelse
...
%else
...
%endif

и по ходу пьесы макросы можно использовать в виде $name (чтобы легко можно было их выделить в тексте при парсинге).

Кроме того переменные можно разрешить задавать извне, как параметры урла - например http://virtburg.com/50_50/room.3dm?level=10&floor=green

Ну и разрешить файлы внутри 3dm-файла тоже через тот же препроцессор заводить:

Code: Select all

%file filename
....
%endfile

Но это конечно всё сильно потом - сначала надо заопенсорсить с теми фичами, что есть...

О - можно ещё интеллектуальный импорт 3DM-файлов поддержать со смещением
Типа
import 50_50/main.3dm 0 0
import 50_51/main.3dm 0 64
и т.д. причём в подключаемых файлах будут игнорироваться команды back, border, hall и start (если есть).

Это чтобы панораму генерировать из окружающих секторов - сейчас для этого у меня некая внешняя программа используется, а так всё будет в самом движке. Ну и в будущем может пригодиться скажем для подключения в сектор домов описанных в отдельных файлах...

[Shaos]

Теперь надо панорамы с GIF на JPG перевести (потребуется задействовать jpeglib для этого - причём он уже есть в линухе), попутно переделав фотканье экрана по кнопке F2 с TGA тоже на JPG (может быть JPG-текстуры тоже поддержать наряду с TXR?), а также прибить последнюю пару C++ классов и выложить наконец virtburg.c
...
Попутно проверил работу движка в полном HD-разрешении 1920x1080 - выдает 30 с небольшим FPS на моём AMD64 компе. Наверное надо принять это разрешение как максимально возможное - тогда максимальный горизонтальный размер панорамы будет 1920*8=15360 пикселов (8 потому что горизонтальный угол обзора у меня сейчас установлен в 45 градусов, соответственно все 360 это 8 раз по столько). Если панорама меньше, то она будет растягиваться линейной интерполяцией прежде чем будет преобразована в мою игровую палитру. Высота панорамы не должна превышать тройной высоты экрана (выше просто не удасться задрать голову в текущей версии движка) или максимум 1080*3=3240 пикселов. Если панорама ниже по высоте, то верхняя и нижняя строчки просто будут копироваться выше и ниже доступной картинки, причём середина панорамы всегда будет считаться линией горизонта.

Ну что - через 4 года возвращаюсь к недопиленному движку

Первым делом надо поддержать JPG-панораму - причём при загрузке её надо будет переводить в игровую 256-цветную палитру, делая аппроксимацию цветов с точностью до пикселов экрана. Заодно можно поддержать сдвиг линии горизонта, если она вдруг была не точно по середине высоты панорамы.

Посмотрел в коде - у меня выделяется 4 раза высоты экрана, т.е. по вертикали буфер 1080*4=4320 пикселов (хоть голова и опускается-задирается только на полторы высоты, т.к. буфер по вертикали всё таки должен быть 4 экрана иначе будут глюки). Размер такой панорамы в памяти составит 63 мегабайта при разрешении экрана 1920x1080 - надо прикинуть как долго оно будет генерить попиксельный дизеринг из RGB (мне надо это делать при каждом переходе из сектора в сектор) - если слишком долго, то тогда надо делать панораму меньшего разрешения...

P.S. В такую панораму можно ведь программно рисовать по ходу пьесы!
Надо будет когда Robby скрипты подтяну пробросить рисование туда скажем через PLANE -1 и затем COLOR C и PIXEL X Y

Вобщем сделал чтение панорамы JPEG (пока в чёрно-белом варианте без привязки к игровой палитре) и сохранение в JPEG снимков экрана по кнопке F5 - вот результат:

vburg0001.jpg (214.44 KiB) Viewed 382 times

vburg0002.jpg (231.43 KiB) Viewed 379 times

(красная горизонтальная полоса посередине экрана это просто для отладки линия горизонта показана)

Панорама может быть размером вплоть до озвученных выше 15360x3240 пикселов, что есть 8 экранов по ширине и 3 экрана по высоте для разрешения 1920x1080 - если загруженная картинка меньше размером (например старые панорамы секторов Виртбурга имеют разрешение 2880x400), то по ширине она будет растягиваться чтобы заполнить все 360 градусов в текущем разрешении экрана, а по высоте будет добиваться последней строкой (например в панорамах Виртбурга вверху идёт синяя полоса, которая копируется выше до конца буфера).

P.S. Текущий размер исходника - 3924 строки:

Screenshot from 2024-12-01 20-51-02.png (162.1 KiB) Viewed 374 times

(файл сам по себе всё ещё называется 3dm_view.cpp так как не все хвосты C++ ещё вычищены - как вычищу так переименую в virtburg.c и опубликую на гитлабе)

[Shaos]

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

Вот что я имею ввиду под просвечиванием внешней панорамы через точки нулевого цвета на текстурах внутренних кубиков:

[Shaos]

Жаль нельзя связаться с автором парка:

vburg0002.jpg (230.03 KiB) Viewed 341 times

т.к. домен e-mail.ru вроде как продаётся, к тому же бесплатным почтовым сервером он перестал быть где-то после 2007

P.S. Попробую хотя бы с автором Козлино связаться...

[Shaos]

Реализовал алгоритм дизеринга панорамы с распространением ошибки вниз и вправо с постепенным "растворением" (colorerror /= 1.03):

[Shaos]

P.P.P.S. Не - логику анимации я уже предполагал тогда же т.е. анимацию можно сделать прямо сейчас. Ещё прям сразу можно поддержать "карты спрайтов", когда разные итерации персонажа (и даже разных персонажей) навтыканы в одну картинку с фиксированным шагом, например такой объект можно описывать так:

Code: Select all

o0001 6.2 5.7 0 1.3 swin_2x3:5

что может означать, что мы берём TXR-файл swin_2x3.txr и предполагаем, что там сетка 2х3 из которой мы берём 5-ую по счёту картинку (если считать слева-направо-сверху-вниз начиная с нуля), а если там анимация 2 Гц, то так:

Code: Select all

o0001 6.2 5.7 0 1.3 swin_2x3:5,swin_2x3:4

(т.е. 2 картинки через запятую дают анимацию 2 Гц, а 3 картинки - 3 Гц и т.д. что даёт цикл анимации всегда ровно в 1 секунду).

P.P.P.P.S. Наверное должна быть возможность запустить/остановить анимацию из скрипта либо по триггеру...

Всё-таки резать надо не по цифрам из имени, а по цифрам идущими следом:
o0001 6.2 5.7 0 1.3 swin:2x3:5
Можно также ещё спрайт зеркалировать по горизонтали указав например тильду после имени спрайта:
o0001 6.2 5.7 0 1.3 swin:2x3:5~
Анимацию которая крутится всегда можно обозначать специальным значком, например @
o0001 6.2 5.7 0 1.3 swin:2x3:5,swin:2x3:4@
Если значка нет, то надо показать первый спрайт и ждать команды от скрипта (либо от сишного кода, который будет дёргать некий API)

P.S. Наверное можно запрограммировать поворачивание спрайта (путём выбирания следующего спрайта при обходе) в зависимости от того с какой стороны на него смотрят:
o0001 6.2 5.7 0 1.3 swin:2x3:5,swin:2x3:4,swin:2x3:3,swin:2x3:2&
( в данном случае можно ограничиться только 4 сторонами т.к. мы всё-таки не дум тут делаем, где было 8 )

[Shaos]

Вот нашёл на старых дисках оригинал панорамы сгенерированной мною в какой-то ландшафтной программе 20 лет назад, который впоследствии после ручной подгонки под мою игровую палитру превратился в задний фон Виртбурга (ниже уменьшенная картинка с оригинальных 2880 до 1000 пикселов по горизонтали):

Хочу более чёткие панорамы сгенерировать шириной 5760 пикселов, пользуясь тем старым оригиналом (т.к. всё это время панорамы Виртбурга были ужаты до 1440x100, что при больших разрешениях выглядит ужасно) - причём подгоняю так, чтобы горы сзади выглядели по высоте плюс-минус как в 2000 году:

vburg0001.jpg (433.32 KiB) Viewed 250 times

vburg0002.jpg (445.97 KiB) Viewed 250 times

vburg0003.jpg (453.07 KiB) Viewed 247 times

Причём горы более сине-зелёные теперь получаются и всё выглядит как-то более по киношному

[Shaos]

Складывается такое ощущение, что раньше панорама была какая-то несколько приплюснутая:

[Shaos]

По сравнению с поздним Виртбургом (2002), когда я здания в панораме "крупными мазками" представлял, совсем сильно лучше стало

vburg0005.jpg (428.72 KiB) Viewed 247 times

vburg0008.jpg (471.18 KiB) Viewed 245 times

P.S. В "позднем" Виртбурге горы чуток пониже были я гляжу...

[Shaos]

P.S. В "позднем" Виртбурге горы чуток пониже были я гляжу...

Хотя в-принципе наверное норм: