Cheb's Game Engine

[скалогрыз]

только png и tga

а чем .tga лучше .png?

[Cheb]

Теоретически, быстрее распаковка но хуже сжатие (несжатые тга в pk3 файле со сжатием). В принципе, что совой об пень, что пнём об сову.

[runewalsh]

скалогрыз
>(эстетическая) ну сам же ты так - с приведением к поинтерому - писать не станешь?!
Я так пишу (ну, обычно предпочитаю for, но когда не предпочитаю...), потому что сам по себе Move кладёт на типобезопасность и явно используемый pointer ничего не меняет, лишь делает вытекающие из низкоуровневой работы с памятью риски бросающимися в глаза.

>(техническая) а я не зря написал const s: array of byte; намекая на то, что "s" может быть и открытым, а не динамическним массивом. С ним такое приведение типов просто не прокатит
Ой, то есть да, общий случай — указатель на базовый тип, каким они на самом деле и являются: pByte(s)^. Для ссылок вроде s[length(s) - count], которые валидны всегда, кроме count = 0 — а этот случай и так особенный, потому что только в нём полученный указатель никто не имеет права трогать, — можно использовать (pByte(s) + length(s) - count)^ (твой персонаж-перфекционист допишет скобки вокруг length-count). Хотя согласно общепринятому определению опускание тривиальных проверок и является преждевременной оптимизацией, я предпочту считать здравым смыслом того же уровня, что передача больших или автоматических объектов по const.

Cheb
>быстрее распаковка но хуже сжатие
Используй GL_COMPRESSED_RGB_S3TC_DXT1/5 лол. Есть NVIDIA Texture Tools, в т. ч. плагин для фотошопа. Сам dds очень простой и, главное, задуман, чтобы загружать данные текстуры как есть, вообще без преобразований.

[Cheb]

, в т. ч. плагин для фотошопа.

Вы смеётесь? Последний раз как я проверял, фотошоп стоил мою месячную зарплату. Теперь, небось, уже три.

Используй GL_COMPRESSED_RGB_S3TC_DXT1/5 лол.

Перпендикулярна, увы.
В готовой игре 90% текстур будут динамическими атласами, обновляемыми на лету рендером в текстуру (см. про сурфейсные кеши в http://downloads.gamedev.net/pdf/gpbb/gpbb68.pdf). Меньшее, что возможно подцепить к FBO - это RGBA8.

Пока, устав от давли багов, теоретизирую на формат чанка.
- элемент данных - bitpacked записи с вариантами. Подавляющее большинство - 16-битные. Индексы - *тоже* 16-битные кагбе-указатели на потроха этого пула.
- у каждого чанка встроенный менеджер памяти на основе дин. массива, выделяющий её 16-битными кусочками, список свободных блоков - битовая маска.
- каждый блок хранится как последовательность свойств, где один бит означает "этот последний". Количество свойств - произвольное, т.е. чтобы обратиться к свойству A блока Б, этот блок придётся парсить, проходя по нему.
- сами блоки внутри чанка организованы как октри. Причём, каждый 16-битный элемент октри может:
-- содержать непосредственно блок из 1 свойства
-- быть ссылкою на блок в пуле
-- быть узлом октри нижнего уровня (что просто один из типов блоков, занимающий 9 ячеек последовательно).

То есть, блок может объединять 8 - 64 - и т.д. блоков с идентичными свойствами, серьёзно экономя память. В частности, блоки воздуха, не соприкасающиеся ни с чем, могут становиться всё крупнее. Крайний случай - весь чанк считается одним блоком.

А если нужен проход по всем блокам (напр., пересчёт освещения) - чанк распаковывается в массив, просчитывается, потом запаковывается обратно в октри.

В отдельных случаях может быть целесообразно вынести определённое свойство в отдельный октри. Например, тип породы для толщи камня - который вообще пустой и неинициализированный, пока какая-нибудь сволочь не полезет его читать. Или вектор течения для жидкостей.

Свойства это: тип материала, процент заполнения, яркость дневного света, яркости r, g и b, давление, насыщенность водой, трещиноватость, количество морковок в грядке - да дофигища всего, и большинству блоков большинство свойств строго перпендикулярны (как свет внутри непрозрачных).

З.Ы. Про насыщенность водой: а вы думали? Я хочу нормальную грязь, наконец, в которой вязнут трактора. Чавк, чавк, и игровая аватара медленно погружается в блок земли, а часть грязи выдавливается в соседние.

З.З.Ы. На работе загрузили по самое не балуйся, выпадаю в атсрал

[runewalsh]

Cheb
>Вы смеётесь?
Нет. Там тебе и утилита командной строки, и DLL, и что-нибудь ещё.

>Перпендикулярна, увы. В готовой игре 90% текстур будут динамическими атласами, обновляемыми на лету рендером в текстуру
Вот не уходи от темы, ага:
>сам в игре планирую использовать только png и tga.
Эти форматы сильно замедляют загрузку и ничего не дают взамен, поэтому для дистрибутива текстуры практически всегда преобразуют в GPU-формат.

[скалогрыз]

Эти форматы сильно замедляют загрузку и ничего не дают взамен, поэтому для дистрибутива текстуры практически всегда преобразуют в GPU-формат.

соглашусь с Cheb-ом, что
1) фотошоп есть далеко не у всех (часто использует разновидность "Paint-а со слоями" по-вкусу)
2) в тех случаях, когда нужно получить какой-нибудь RGB битмап... для каких-либо дополнительных преобразований.

3) да и для 2d игр, сжатие с потерями не годится.
А ещё мне лично нравится PNG, что он расширяемый. Например на данный момент информацию по спрайту (н.р. центр спрайта, размер тайла.. и вообще тайлы) хранить отдельно, но реально её вшить в PNG и уменьшить количество файлов. А ещё смотрю в сторону APNG, вроде как анимация должна хранится компактнее, но кого в наши дни волнует размер!


и кстати, GPU меняются... сегодня один формат в фаворе, а завтра другой.

[Cheb]

Нет. Там тебе и утилита командной строки, и DLL, и что-нибудь ещё.

Ага. Это при том, что стоит эта радость где-то 27-28 тысяч рублей, а я который месяц не могу наскрести на новый холодильник, который стоит дешевле. Не говоря уже от GTX960, которую вообще пришлось отложить на 2017-й.

Эти форматы сильно замедляют загрузку и ничего не дают взамен,

Эти форматы поддерживаются большинством утилит рисования, например, GIMP. Я не собираюсь разводить мазохизм когда для экспорта изменённого контента в движок надо выполнять танцы с бубном или запускать несколько утилит подряд.
Для скорости уже есть фоновая подгрузка, как в Unreal Engine. Когда доделаю её - игра сама будет создавать и кешировать в DXT, причём уже готовые атласы собранные из довига PNG, и проблема вообще отпадёт.
TL;DR: png и tga - это инструменты совместимости и лёгкости модификации. Что важнее.

Добавлено спустя 3 минуты 59 секунд:
З.З.Ы В дистрибутиве - PNG и TGA, из которых при первом запуске генерируются атласы, заточенные под конкретную видеокарту. Иными словами, игра доустанавливает себя в фоновом режиме.

Добавлено спустя 1 час 18 минут 10 секунд:
З.З.З.Ы
Ищо привлекательная идея - *нормализовать* текстуру по каждому компоненту перед сжатием в DXT. Ну и, соответственно, в пиксельном шейдере восстанавливать.
...бля, это ж лишние 6 чисел на вершину

Тогда, можно расклать текстуру на компоненты, и в DXT хранить только высокочастотную составляющую. Получаем три текстуры: например, первая - 256х256 RGBA8 базовое значение, вторая - 256х256 RGBA8 множитель, третья - 2048x2048 DXT5 хай-рес, помножаемый на вторую и прибавляемый к первой.

[hinst]

копи лючше на RX 400 серии

[Cheb]

Чем дальше, тем жить грустнее. Решил закуклиться и ничего не покупать -- может быть, тогда, наконец, хоть какого-нибудь реального прогресса добьюсь!

Серьёзно, у меня ещё кроссовер Ранмы и Сэйлор Мун с Фолаутом стоит, в начале года опубликовал тизер и подвесил читателей. Чувствую себя скотиною

По ходу, тихо и без фанфар пошла Win64 версия.
Сессия пока получается не совместимой: слишком много параноидальных проверок на размер типов, и не поотключаешь все, для статических массивов она реально важная потому что конверсия не поддерживается. А тут напоролся на факт, что у меня в одном месте статические массивы объектов. И опаньки: 3 указателя по 4 байта <> 3 указателям по 8 байт. Надо городить очередные городушки на проверку типа элементов массива.

Кроме того, встречаются всякие странности. Например:
1. скопированная во временную папку а потом выгруженная DLL игрового модуля залипает блокированной, файл не удаётся удалить пока не закроешь приложение. Причём, не всегда.
Отключать режим разработчика для Win64?
Копировать с изменённым именем а потом следить за папкой и пытаться удалять все с совпадающим базовым именем?
Х/з.

2. Выполов последний каст pointer к dword, напоролся яна странный глюк:

Код: Выделить всё

  var gsb_p: pointer;
...
        Asm
          mov qword[gsb_p], rsp
        End

бомбит насмерть, а

Код: Выделить всё

        Asm
          mov rax, rsp
          mov qword[gsb_p], rax
        End['rax']; 

работает нормально, как и

Код: Выделить всё

        Asm
          mov [gsb_p], esp
        End

в 32-битной версии.
Вот и что это было, Пух?

Полностью:

Код: Выделить всё

  var gsb_p: pointer;
  function GetStackLimit(): pointer; inline;
  {$ifdef windows}
  var
    Tmm: TMemoryBasicInformation;
  {$else}

  {$endif}
  begin
    {$ifdef windows}
      {$ifdef cpu64}
        //WhyTF mov qword[gsb_p], rsp causes a HARD crash-to-desktop ?
        Asm
          mov rax, rsp
          mov qword[gsb_p], rax
        End['rax'];
      {$else}
        Asm
          mov [gsb_p], esp
        End;
      {$endif}
      if VirtualQuery(gsb_p, @Tmm, SizeOf(Tmm)) <> sizeof(Tmm)
        then Die(RuEn(
          'Не удалось получить информацию о блоке памяти стека',
          'Failed to get info for the stack memory block'));
      Result:= Tmm.AllocationBase;
      if Mother^.Debug.Verbose
        then AddLog('  Stack limit is %0 (%3 = %1, reserve %2 Mb)'
          , [Result, gsb_p, (ptruint(gsb_p) - ptruint(Result)) div (1024 * 1024)
            , {$ifdef cpu64}'RSP'{$else}'ESP'{$endif}]);
      {$else}
Result:= nil;
//***TODO: find the way. There should be a way. As it is now,
// custom stack checking only works in Windows
    {$endif}
  end;

[скалогрыз]

может тебе от ассебмлеров-то отходить и использовать их только в надёжных случаях.
И писать всё в pure-pascal?
и потом, тебе же на ARM это всё портировать предстоит... без поддержки ARM в наше время никак.

[Cheb]

Дык {$ifdef windows} жеж.
Спасибо, функция помогла избавиться от асм вставки.

На ARM уже почти портировано, падает из-за общего линуксового бага (я что-то X серверу шлю не то, он шлёт меня лесом. Понять, что именно - без бубна не разберёшься). Низкий приоритет до тех пор когда можно будет побегать пострелять. Также потребуется портировать на OpenGL ES 2, а для этого желательно сначала увести рендер от состояния "сраная помойка", да и чтобы тестировать уже на примере побегать пострелять.

[runewalsh]

А зачем тебе вообще этот указатель?

[скалогрыз]

Дык {$ifdef windows} жеж.

ну и что. Винды на Арм-ах не работают что ли?
где то-то тут в архивах новостных было... а! ну вот!

Добавлено спустя 3 минуты 42 секунды:

А зачем тебе вообще этот указатель?

уверен на 99% что это не единственное место использования

[Cheb]

Там где-то в потрохах Чеперси ручная проверка стека, чтобы при исчерпании не умирать молча, а отправлять внятный отчёт об ошибке, прерывая веселье когда там ещй остаётся мегабайт-другой резерва.
Рекурсия - это такая рекурсия.
Не придумал, как на Линуксе найти начало остека, там же нет VirtualQuery. Может быть, попробовать в цикле пройтись вдоль него, пока не словишь AV?
Вот теперь гложет меня сомненье, не отрубил ли я эту проверку нафиг, а инициализацию просто забыл.

Винды на Арм-ах не работают что ли?

Я уже *достаточно* натрахался с установкой на Raspberry PI 2 хотя бы распбиана. Винда пролетает, винду буду поддерживать только x86 и x86_64.

Добавлено спустя 1 минуту 53 секунды:
З.Ы. Новость - что *может быть* разрабатывают, а пока для той же raspberry сужествует лишь консольная винда, без гуя.

[скалогрыз]

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

а если средствами RTL?