[ d ] [ b / cu / dev ] [ r ] [ a / ts ] [ ci ] [ gnx / int ] [ misc ] [ dev / stat ]
[Burichan] [Futaba] [Gurochan] [Tomorrow] [Архив-Каталог] [Главная]

Файл: 7118cd632eddd22b7a4b6559bff5e2fa.jpg -(251 KB, 810x810, 7118cd632eddd22b7a4b6559bff5e2fa.jpg)
251 No.9999  
http://sourceforge.net/projects/rr-rr/
Предыдущий тред: >>4274
>> No.10000  
Файл: 85e4d1365ae50ddd90683713ce50e5c8.jpg -(94 KB, 600x600, 85e4d1365ae50ddd90683713ce50e5c8.jpg)
94
ЗАПИЛИЛ
    СЕРИАЛИЗАЦИЮ
             СКРИПТА
                  ^_____^

Жмём F2/F3 (с эстетичностью не заморачивался, сам принцип), внимание на консоль и test/campfire.sav (в режиме отладки кое-где вставляется текст — можно представить, что вообще происходит и кто сколько занимает... ~some~ — луашные объекты, <<some>> — нативные). Конкретно в кострах скрипт отвечает за генерацию частиц (в общем случае сохраняются непосредственно частицы, но локальным системам достаточно функции-генератора, не ради профита — он призрачен ввиду внушительного размера дампов Lua-функций, а just cause I can) и мерцание света.

(Да, есть небольшой баг со скриптовыми колбэками, из-за которого с момента загрузки изредка может происходить всё, что угодно — автоматически исправится, если сериализовывать ВЕСЬ стейт, а не выдирать кусок, хотя можно и полностью исправить... в любом случае, не обращайте внимания).

Фичи:

— скриптовые объекты хранятся по значению или по ссылке на выбор (например, короткие строки — по значению, длинные — по ссылке);

— дампы одинаковых Луа-функций, но с разными замыканиями, записываются лишь однажды (я не нашёл штатного средства установить их идентичность);

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

Фундаментальные недостатки всей системы:

— крайне хрупкая совместимость между версиями (вообще забил на неё, ага);

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

Т. о. save/load готов процентов на 50, на что я неделю назад и не надеялся. ^_^
To-do: сериализация всего остального (куклы, вейпоинты, сцена, GUI), ну и меню.
>> No.10030  
Файл: 26_06_2013 22:52:52_145.png -(684 KB, 1153x626, 26_06_2013 22:52:52_145.png)
684
Запили~л сериализацию вейпоинтов короч. Не обычных, списком точек и рёбер — она-то давно была, а рантаймовых, тех, что получаются склеиванием фрагментов (в свою очередь вейпоинтов, но их уже по-другому и не сохранишь). В том же формате, что и фрагменты, это детище Франкенштейна занимало 150 Кб — может быть, и допустимо, но однозначно не круто.

Идея очевидная: для вейпоинтов, хоть раз приклеивших фрагмент из внешнего файла, вести вместе и сериализовывать вместо них РЕПЛИКУ (пожертвовал точностью мысли ради такого-то красивого слова :3) — действия, которые привели к текущей конфигурации. Получились 11 Кб (>100 фрагментов 12 разновидностей), из которых 10 приходятся на соединительные рёбра — для сравнения, файлы самих фрагментов в сумме дают 60. Такое уже и в сейв положить не зазорно.

На скрине вейпоинты, загруженные из явно другой сцены.
>> No.10043  
ОП ты молодец, скажи может тебе нужна какая то помощь. У меня есть опыт работы на паскале, хотя в последние годы использовал PHP.
>> No.10046  
Файл: 1363599946554.gif -(1689 KB, 200x150, 1363599946554.gif)
1689
>>10043
>какая то помощь.
>использовал PHP.
>> No.10050  
Файл: 23576682.jpg -(640 KB, 850x850, 23576682.jpg)
640
>>10043
Помощь по коду не нужна. Вот порисовать можешь.
>> No.10054  
>>10050

Подскажи как и из какого пакета 3D моделирования можно с наименьшими затратами импортировать 3D модели в FPC, какие библиотеки нужны и из какого формата? Blender подойдёт?
>> No.10060  
Файл: 92590bcba01baf1574798a01ae625a6d.jpg -(121 KB, 800x600, 92590bcba01baf1574798a01ae625a6d.jpg)
121
>>10054
Я использую OpenCOLLADA. Но фактически можешь экспортировать в любой формат, который прочитается максом.
>> No.10067  
>>10060

1.Расскажи что из SDL, GLUT, GLScene актуально и годно для 3D программирования в Delphi/FPC сейчас? Ты пробовал прикрутить к FPC SDL?
2.Говорят GLUT не торт, что ты об этом думаешь?
>> No.10086  
Файл: 27631678.jpg -(256 KB, 641x800, 27631678.jpg)
256
>>10067
Из всего, что ты назвал, графическим движком является только GLScene. Особо не ковырял его (несовместимость с религией), но вроде прикольный, много чего реализовано.

>Ты пробовал прикрутить к FPC SDL?
Когда-то прикручивал, потом открутил (хм, всего полгода назад — http://410chan.org/dev/res/4274.html#8358 — а будто вечность прошла... странно): для меня ни разу не проще работы с API системы, зато некоторых фич нет/не было в 1.2 (а реализации SDL_WM_ToggleFullScreen подвендой, по-видимому, не будет никогда).

>Говорят GLUT не торт
Он умер в прошлом веке, freeglut просто не развивается.
>> No.10105  
Файл: Untitled-2.png -(56 KB, 835x1650, Untitled-2.png)
56
Ф-фух. Процентов 80.
Это начинает надоедать.
>> No.10148  
Файл: 05_07_2013 17:07:32_464.png -(2252 KB, 1153x2504, 05_07_2013 17:07:32_464.png)
2252
Переделал прежнюю систему "действий" узлов сцены под анимацию чего угодно (как-нибудь прикручу и GL-параметры) сферическими многомерными сплайнами в вакууме. Как следствие, двери могут открываться менее красиво: движение по схеме "равноускоренно за t1 + равномерно за tU + равноускоренно за t2, да так, чтобы пройти за T = t1 + tU + t2 путь S, а начальная и конечная скорости равнялись v1 и v2" теперь лишь эмулируется. Но это скромная плата за такую-то вкусняшку.

И я всё ещё пилю сериализацию. Собственно, ради неё и переделывал.
>> No.10191  
Файл: 1373381927336.png -(20 KB, 611x355, 1373381927336.png)
20
Жирная!!
На самом деле она потянула за собой весь стейт, неожиданно для меня не ругнувшись за весь обход на неизвестный тип. Видимо, таки допилил. :3 Завтра попробую загрузить.
>> No.10194  
Файл: SaLo.png -(2600 KB, 1161x1959, SaLo.png)
2600
Ну вы поняли.

Релиз без меню с ЭФФЕКТАМИ ни за что не выложу. Неверующие — можете пожмякать F5/F6 в версии с SVN, но о багах докладывать пока не нужно, они и так видны невооружённым взглядом: вам сильно повезёт, если на выходе или после нескольких итераций сохранения/загрузки не словите AV, удвоение (но не более и обычной утечки нет; по-видимому, утечка в терминах управляемых языков) памяти, занятой Lua — и вовсе норма, я пожадничал с 3 байтами на кватернион, ну и так далее.

НО ОНО ВООБЩЕ РАБОТАЕТ!!! ヽ(゚∀゚)ノ

Ну что, долавливаю баги и рисую меню. Или ты нарисуешь, Стив? ^_^
>> No.10208  
>>10191
А зачем ты сериализуешь все? Сериализуй только изменения.
>> No.10222  
Файл: 50c57d40c61a7d779694117ac1f3dacc.jpg -(307 KB, 681x1024, 50c57d40c61a7d779694117ac1f3dacc.jpg)
307
>>10208
Не с чем сравнивать, все объекты создаются в рантайме. А если бы и было с чем, я бы забил. А если бы и не забил, 3/4 занимает стейт Lua — опять же, рантайм.

Ну то есть как забил... Почти любой объект и так предваряет битовая маска про включённые поля, но это немного не то, слишком низкий уровень. Отслеживание изменений возможно только на уровне объекта (не топологии) и при условии, что на его составные части не может быть ссылок извне — собственно, с вейпоинтами и сделал нечто похожее.

>долавливаю баги
done
>> No.10260  
А сколько тебе лет и когда примерно заинтересовался разработкой игор?
>> No.10278  
Файл: c60f32e005d3df061e443d29630222e6.jpg -(58 KB, 500x650, c60f32e005d3df061e443d29630222e6.jpg)
58
>>10260
<20, когда увидел Morrowind (~2003).

Запилил >>10148 для GL-параметров. Просто сравните реализацию смерти:

this:AddTimer
{
   single = true, period = 1.5,
   onTimer = function()
      (...)
      local burn = 0

      this.onUpdate.burn = function(_, dt)
         burn = burn + 0.1*dt
         ro:GL{ burnOverK = burn }
         if (burn >= 1) and (this.mp.value == 0) then this:Detach() end
      end
   end
}


-и-

(...)
ro:SlideGL
{
   what = 'burnOverK',
   path = { [0.0] = 0, [1.5] = 0, [11.5] = 1 },

   onDone = function()
      this.onUpdate.post_mortem = function()
         if this.mp.value == 0 then this:Detach() end
      end
   end
}


До эффектов GUI, для которых это и задумывалось, у меня руки до сих пор не дошли, и вообще последние пару недель я не притрагивался к коду, извините уж. ^^"

Ещё одна безумная идея насчёт сериализации состояния Lua. В таблицах, выполняющих роль структур или классов в статических языках — а таких большинство, если не почти все — повторяется набор ключей. Его можно описать однажды и ссылаться индексом. Всё равно больше всего занимают дампы функций, ну его.
>> No.10336  
>>10278
Я после Морровинда заинтересовался только тем, как не играть в него.
>> No.10368  
>>9999
>9999
ахуеть гет же
Анон как сделать в твоей параше больше двух сырн?
>> No.10438  
Файл: youmad.jpg -(14 KB, 319x243, youmad.jpg)
14
>Pascal
>> No.10448  
Файл: bg1.png -(1034 KB, 1600x1000, bg1.png)
1034
Long time no see, Steve!

>>10368
У меня довольно дорогие источники света, поэтому больше двух не делал. Я прикручу оптимизацию, когда реальные источники, находящиеся достаточно близко, "склеиваются", но позже.

↑ У меня есть шансы? ;_;
Завтра меню сделаю.
>> No.10455  
Оп, какие у тебя планы на игру?
>> No.10465  
>>10448
>У меня есть шансы?
Разумеется нету
> дорогие источники света
убери эту ебаную графику с крузиса и поставь графон уровня моровинда и норма будет
>> No.10471  
Файл: 12829789.png -(380 KB, 800x800, 12829789.png)
380
ПРИКРУТИЛ МЕНЮ!!! ^_^

Чуть было не застрял навечно. Либо стоило сначала посмотреть, как в других движках делают (хотя не уверен, что будет иначе), либо я растерял всю квалификацию за лето, либо анимированный GUI — это ад, либо всё сразу. Эффекты достались мне дорогой ценой: все эти цепочки AddAction(..., onDone = AddAction(..., onDone = AddAction(..., drink_poison() )...) так и норовят рассыпаться. Есть другие варианты? Пилите багрепорты.

To-do: превьюшки сейвов, Binary Shaders и, наверное, оптимизация из >>10448.

>>10455
Нинаю
>>10465
Ну ты и сам должен понимать: графон определяется скорее качеством контента, нежели технологиями, так что--
>> No.10472  
Файл: ACK.rar -(4 KB, x, ACK.rar)
4
>>10471
Что же мне делать?
Дрова новее не поставить: все установщики говорят, что "у вас самые новые дрова".
>> No.10473  
Файл: 21329070.jpg -(352 KB, 830x600, 21329070.jpg)
352
>>10472
Спасибо, не подумал сразу, теперь буду выжимать информацию об ускорителе и т. п. даже их полудохлого OpenGL'я. Но пока я вынужден, даже располагая логом, задать этот вопрос: какая у тебя вообще видеокарта? Если интел — ну, интел так интел, если нет — установщики врут, попробуй удалить старый драйвер.
>> No.10475  
Файл: a53e42ee16b58130e3c8ec57afe8f791.jpg -(226 KB, 755x535, a53e42ee16b58130e3c8ec57afe8f791.jpg)
226
>>10471
>Binary Shaders
done

Рванулся было заюзать SQLite, но здесь и сама файловая система отлично подходит.
Я должен зачем-нибудь воткнуть SQLite!!! Она классная.
У меня загрузка бинарника быстрее одной лишь линковки раз в 5, и это без учёта загрузки и компиляции самих шейдеров.
>> No.10478  
Файл: 20_09_2013 13:01:11_636.png -(516 KB, 1153x626, 20_09_2013 13:01:11_636.png)
516
Превьюшкииииииииии :3
Внезапный to-do: TrueType-шрифты.
>> No.10480  
>>10473
Карточка - ATI Radeon HD 4600.
Дрова стандарто-незаменяемые WDDM v1.1
Я имею в виду, что совсем заменяться не хотят.
ATI Vision процессор видит, но на карточку ругается. Говорит, что дрова свои у него не активны. И активировать их тоже не может.
>> No.10481  
>>10480
Последняя версия говорит
"EAssertionFailed" raised: "Assertion failed (DLLoader.pas, line 200)"
>> No.10485  
Файл: atlas.png -(846 KB, 1034x768, atlas.png)
846
http://clb.demon.fi/files/RectangleBinPack.pdf
Научился паковать атласы. Завтра встрою их в движок по-нормальному и посмотрю libfreetype.
>> No.10489  
Файл: 6843796.jpg -(343 KB, 750x795, 6843796.jpg)
343
Прикрутил шрифты за 2300.

Перестройка атласа может быть медленной и это исключительно моя вина, послезавтра оптимизирую всякие там блиты изображений, [исразуденормализация]SetPixel(Combine([нормализация]GetPixel())) — это несерьёзно.
>> No.10492  
Файл: 11109925.jpg -(589 KB, 700x839, 11109925.jpg)
589
>>10489
>оптимизирую всякие там блиты изображений
done
также добавил поддержку кернинговых пар, теперь и придраться-то не к чему.

Алсо.
(Сейчас покажусь наивным...)
Еду сегодня в метро. Рядом сидит дедок и что-то читает.
Наклоняюсь ближе и вижу, что читает он ВНЕЗАПНО пейпер по CUDA, на английском, конечно.
Это разрушило все мои стереотипы о дедках.

Но вот незадача — следующая станция была его, а я выйти за ним взять контакты не сообразил, хотя не так уж торопился. Успел только перекинуться парой слов — "кудой занимаетесь? — крууть, я тоже GPU мучаю, но до куды не дошёл ещё". Ищи теперь ветра в поле.

Дедок, если читаешь это (ну вдруг)назови свою станцию и отпишись, есть вопросы.
>> No.10495  
Файл: 75cb9492e751c789410d3b35ffe2c1ca.gif -(1126 KB, 642x482, 75cb9492e751c789410d3b35ffe2c1ca.gif)
1126
>>10492
Я не дедок, но на некоторые вопросы по CUDA ответить, думаю, смогу.
>> No.10500  
Файл: 19d392bfe2bb020209ce61e579bc00c4.jpg -(191 KB, 810x630, 19d392bfe2bb020209ce61e579bc00c4.jpg)
191
Вынес оконный цикл в отдельный поток.

Может быть нестабильным. Даже так: НЕСТАБИЛЬНЫМ. Особенно на XP. Если есть под рукой XP, докладывайте о результатах с window.allowMT = true — у меня всё мерцает, и если не только у меня, то дело в этой их "новой модели драйвера" начиная с висты.
>> No.10515  
Файл: 9773304.jpg -(1566 KB, 1239x1535, 9773304.jpg)
1566
Переписал события на Condition Variables, ну, кроме тех, что задействованы в WaitForMultipleObjects (реализовать можно, но придётся сильно усложнить структуру события: http://stackoverflow.com/questions/2719580/waitforsingleobject-and-waitformultipleobjects-equivalent-in-linux/7782618#7782618) и MsgWait* (а здесь, я так понимаю, без вариантов). У меня работают раза в 2 быстрее.

И всё же, какую семантику выбрать — Event или CV, и почему? И предоставляют ли CV вменяемый аналог WFMO в значении WaitForAny?
>> No.10521  
Файл: 12919037.jpg -(376 KB, 902x1100, 12919037.jpg)
376
Добавил в движок сущность CV наравне с Event. И переписал почти всё на CV. CV — классные. Мне понравилась идея, что если из кода убрать CV, он останется корректным, просто неэффективным.

Под XP реализовал через ивенты вторым вариантом (SetEvent solution) отсюда: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html . Не знаю чё там про некорректность, у меня всё работает)) а если серьёзно, то
>slip through even though it was not waiting on condition variable (...) when a broadcast occurred
прекрасно списывается на spurious wakeup, ничего страшного.

CV на XP эмулируются ивентами, ивенты на Vista+ эмулируются CV. ^^"
>> No.10588  
Файл: 1ea14459ae5caaeca1e29b11b342dbae.jpg -(104 KB, 750x750, 1ea14459ae5caaeca1e29b11b342dbae.jpg)
104
Запилил:
Поддержку геймпада (USB HID API). Наверняка рассыплется на моделях с количеством кнопок, отличным от моего (16). Коль скоро кнопки, в отличие от аналоговых стиков, свой Usage не говорят, я вижу единственное решение — предлагать калибровку пользователю. Кто как делает? Есть другие способы?

СЛИЯНИЕ источников света — сомнительная оптимизация, призванная смягчить отсутствие DS. Постепенно доведу до ума.

— Вроде работает на Intel HD 4000.

Ладно, хватит ерундой заниматься.
>> No.10589  
>>10588
>Ладно, хватит ерундой заниматься.
Действительно.
>> No.10592  
Файл: 109040.jpg -(88 KB, 649x750, 109040.jpg)
88
>>10589
Эй!
>> No.10603  
>>10592
Да просто обидно, что автор растрачивает талант на всякую ерунду.
>> No.10605  
>>10603
Какие глупости ты пишешь.
>> No.10606  
>>10605
Просто ты не можешь в иронию.
>> No.10669  
Файл: 31_10_2013 05:12:25_497.png -(586 KB, 1161x653, 31_10_2013 05:12:25_497.png)
586
Чуть позже выложу.
>> No.10679  
Файл: 31883777.png -(206 KB, 750x900, 31883777.png)
206
Прикрутил асинхронный I/O. Reason: компиляция шейдеров в рантайме и так тормознутая, только синхронного кэширования и не хватало. Плюс, для стриминга пригодится, если руки дойдут.

Про ерунду уже сказал, так что понапридумывайте мне ваултов aka кусков уровня.
>> No.10729  
>>9999
Анон, тебе приходилось перелопачивать значительную часть кода, когда надо было внести изменения в одно место или когда новую фичу добавлял?
Ты пользуешься какими-нибудь диаграммами классов, схемами, рисунками или все в голове держишь?
>> No.10733  
Файл: 11_11_2013 10:56:14_000.png -(552 KB, 1161x653, 11_11_2013 10:56:14_000.png)
552
>>10729
В отдельных фичах не замечал, но того, что в целом я уже переписал весь движок несколько раз, это не отменяет.
>Ты пользуешься какими-нибудь диаграммами классов
Пользовался бы, если бы такие средства существовали для FPC. ha-ha.
>схемами, рисунками
Конечно. Грех, располагая столь слабым CPU, не юзать столь мощную видеокарту, евпочя.

Реализовал какую-никакую ВОДУ:
— Плавучесть — вообще-то громко сказано, т. к. она не то сломана в Newton, не то я с масштабами не рассчитал.... позже доразберусь или реализую реалистичную, т. е. с точным учётом вытесненного объёма, на том, что есть.

— Точная (до погрешности ^^) граница между водой и воздухом — я не знаю, почему та же Беседка до этого не додумалась (или уже додумалась? Исправьте меня, в Скайриме баг всё ещё был). Просто выразил пересечение плоскости воды и ближней плоскости фрустума в экранных координатах и проверил в шейдере Ax + By + C.

А ещё прикрутил выравнивание (без него иногда просто некорректно работают, да) атрибутов, interleaved вершины, объединение совпадающих VAO и шейдеров (с последними оно того не стоило, но пусть остаётся), ну и по мелочи.
>> No.10740  
Файл: cirno.png -(1382 KB, 1648x956, cirno.png)
1382
Эффект преломления воды шикарный, а вот отражение не очень. Сделай, чтобы было как в крузисе - линейная интерполяция между отраженной и преломленной картинкой в зависимости от дотпродукта нормали в текущей точке на воде и вектора из камеры в эту точку.
В очередной раз говорю, что ты няша! Это очень круто!
>> No.10744  
Файл: 33061861.jpg -(344 KB, 583x1198, 33061861.jpg)
344
>>10740
Н-но я изначально так и сделал... T_T

Мне только не нравится отсутствие бликов. А с ними не знаю, как размыть яркие источники света по вертикали, ну, вроде IRL дорожек от Солнца и Луны. Или они должны сами вытянуться, если прикрутить блики, хм?..

Алсо.
Добавил поддержку автоматически построенных атласов всему GUI (не только шрифтам) — раз.
Запилил СПЕШОЛЫ шейдеров наравне с флагами — два.
Что за.
По сути те же флаги, но с отличной семантикой.

Флаги — битовая маска. Следовательно, их пространство ограничено (размер битовой маски), зато сущность легко может "включить" произвольный набор.

СПЕШОЛ — число. Поэтому вариантов СПЕШОЛОВ может быть сколько угодно, но использовать за раз можно лишь 1... ну или позже может пригодиться задание отдельного СПЕШОЛА каждой засветившейся в батче сущностью — материалом, объектом, чем там ещё; в любом случае, жёстко заданный максимум, не сильно превышающий 1.

Пример.
Флаги — "бамп", "свечение", "скелетка".
СПЕШОЛЫ — "объект является качающимися мухоморами", "у объекта плавятся крылышки". То есть нечто такое, что может превысить разумные ограничения на количество флагов, а комбинировать особого смысла нет.

To-do: Lua-консоль.
>> No.10745  
>>10744
http://goo.gl/NVUvyX - iLua
http://goo.gl/9bCWdR - lua-rlcompleter
Держи готовую консоль с ридлайном. Ее только обернуть в виджет надо.
>> No.10746  
Файл: nasu_kumiromi.gif -(10 KB, 220x300, nasu_kumiromi.gif)
10
>>10745
Не-не-не, я нативную сделаю.

Глядя на stand-alone интерпретатор луы, подумал, что там есть незамеченный мной красивый способ узнать, что чанк синтаксически верен, просто не завершён, посмотрел исходник — incomplete = error && !strcmp(errmsg + errmsglen - 5, "<eof>"). :\
>> No.10747  
>>10746
iLua - это рекомендуемая штука с луасайта. У меня там просто пара патчей на нее, которые какие-то дырки фиксили. А ридлайн-связка - разделяемая библиотека. Оно грузится из луы и не имеет контакта с твоим кодом.
>> No.10755  
>>10744
вообще дорожки бликов получаюстя на волнующейся воде, потому что у каждой волны на прямой солнце-зритель в силу её формы есть кусок, который наклонен так, что от наблюдателя в нем отражается именно солнце. Аналогично и с любым другим объектом. В программной имитации тебе сответственно нужна такая формула искажения "прямого" отражения, при которой точки позжим образом перераспределяются по всей вертикали с уплотнением и многократным повторением.

Извиняюсь за бесполезный комментарий :3
>> No.10756  
Файл: AB.png -(1146 KB, 1161x1306, AB.png)
1146
>>10747
Нннеееееет, хочу велосипед.

>>10755
Так и думал, просто у кого-то блик от солнца выглядит дорожкой, а у кого-то кругом — должно быть, от модели освещения зависит. Всё равно позже посмотрю, уста~л.

Итак. Прикрутил Луа-консоль (РЕДАКТОРА-ТО НЕТ). Поддерживает IME и вообще вместо какой бы то ни было самодеятельности спрашивает символы у системы (WM_CHAR), так что по идее должно печататься всё то же, что в блокноте (с точностью до шрифтов).

Каждая строка немедленно выполняется в окружении трёх переменных:
game; game.scene.phys.gravity = Vec3(0)
con; con:Write(), con:Clear(), псевдонимы — print, cls
mm; mm:Pause(), mm:BGM_switch()
Окружение поддерживается между вызовами (ara на пикрелейтеде).

To-do: выбирать объекты / координаты мышкой?
P.S. С этим надо что-то делать. Около часа выяснял, почему консоль пытается сериализоваться.
>> No.10767  
Файл: 27939665.jpg -(662 KB, 1129x1596, 27939665.jpg)
662
Придя в ужас от того, сколько всего мне предполагалось скопипастить, чтобы добавить воде блики, переделал работу с источниками света в шейдере. Теперь, несмотря на то, что типов источников несколько — (позиционные, направленные) × (с тенями, без), "цикл" по ним в шейдере — единственный. Профит в том, что общий код и пачки параметров дублировать не нужно. Так, массив цветов теперь относится ко всем источникам, массив радиусов — ко всем позиционным, etc., вместо отдельных массивов для каждого типа.

Проиллюстрирую страшненьким кодом:
http://pastebin.com/vszB06u2
http://pastebin.com/nj4V0Jzq

При выполнении ряда условий части такого "цикла" преобразуются в честный for по юниформу.
>> No.10774  
Файл: 23_11_2013 00:43:09_249.png -(546 KB, 1161x653, 23_11_2013 00:43:09_249.png)
546
^_^
Самая корректная модель бликового освещения из известных мне на данный момент, учитывает кривизну поверхности, коэффициент Френеля и взаимозатенение "микрограней".

Надо будет все более-менее известные перепробовать, и не только на воде, интересно же.
>> No.10783  
Файл: 24_11_2013 07:39:29_631.png -(847 KB, 1161x653, 24_11_2013 07:39:29_631.png)
847
>>10774
+сплаттинг, +плавная граница с берегом, +"пена".
Время допилить предметы, инвентари и контейнеры! :3
>> No.10847  
Файл: AB.png -(381 KB, 604x520, AB.png)
381
>>10783
Не успею к НГ >_>
Пока сделал раздельные инвентари (press X) и подсветку, завтра добавлю контейнеры.
>> No.10897  
Файл: 1.gif -(14 KB, 400x300, 1.gif)
14
Сделал автоподбор позиции в лейауте GUI. Идея: перебрать все пустые прямоугольники, упирающиеся во что-нибудь (пикрелейтед, КАК МОЖНО ПОТРАТИТЬ ДВА ДНЯ И 400 СТРОК НА ТАКУЮ МЕЛОЧЬ!!! https://sourceforge.net/p/rr-rr/code/527/tree/framework/UMath.pas#l3111 + https://sourceforge.net/p/rr-rr/code/527/tree/framework/Algo.pas#l560), и в самом подходящем по какой-нибудь эвристике как-нибудь разместить окно. Можно было проще? Как?

В итоге и к Рождеству не успею. :(
>> No.10901  
>>10897
1) В игре ты как правило не хочешь, чтобы гуй заполонял весь экран. Для разных типов окон определяешь, с какой стороны они хотят появиться, и когда собственно уже вот-вот надо прочесываешь этот край экрана на предмет свободного места, если его нет - смотри п.2 только с поправкой на то что ты хочешь в нужный бок.

2) Чисто теоретически если ты хочешь, чтобы окно ничего не перекрывало и оставило место другим окнам - ты должен поставить его впритык к существующему окну (если оно одно), или двум (если их несколько и к одному не прицепиться). То есть при большом числе окон тебя интересуют угловые пересечения продолжений торон имеющихся окон и максимальные размеры прямоугольника, доступного из этого угла. И потом втыкаешься либо в наименьший подходящий тебе прямоугольник, либо в наиболее подходящий тебе геометрически (ближайший к центру / к нужному краю).
>> No.10921  
Файл: 12_01_2014 09:36:42_694.png -(1013 KB, 1161x653, 12_01_2014 09:36:42_694.png)
1013
Ничего не сделал, зато сделал ПЕРЕНОСЫ.
Добавлять заодно с экипировкой и юзабельностью фехтование мороженкой или?.. --"
>> No.10961  
Файл: 27006426.png -(326 KB, 900x805, 27006426.png)
326
Разобрался с потоками сжатия и mmap. Файлы теперь не читаются в память не по делу — так, запрос файла в архиве возвращает поток непосредственно на данных архива.

На какое-то время займусь рефакторингом, перепишу каскадные тени на Texture Arrays (на дворе 2014, а я их не поддерживаю (・_・ヾ), "глобальные" юниформы на общий UBO вместе с более декларативным подходом к описанию юниформов, чтобы отвязать их объявление от реализации (дефолтный блок / GL3.1-UBO / GL4.3-SSBO; надо было сделать это сразу ;_;), координаты в шейдере на short3 + AABB вместо float3, возможно, объединение статических мешей с одинаковыми структурами вершин в большие VBO, и так далее.

Фехтование правда запилю, подсмотрел идею в игре Gun-Katana (http://www.erogereview.com/2009/02/11/gun-katana/). Потом.
>> No.11073  
Файл: cd52dab91fe3dff5f9b1a4e1055b0e76.jpg -(387 KB, 938x849, cd52dab91fe3dff5f9b1a4e1055b0e76.jpg)
387
Что хотел выделить:

— Теперь скелеты не создают узлов сцены (с сопутствующим оверхедом) для каждой кости, при этом возможность цеплять узлы к отдельной кости осталась. Это не только оптимизация, но и должно упростить обрезание костей в зависимости от LOD. Мечты, мечты.

— Добавил методы сжатия: Bzip2 — ничем не примечателен; LZHAM (Lempel-Ziv, Huffman, Arithmetic, Markov; http://code.google.com/p/lzham/) — сугубо оффлайновый, зато степень сжатия сравнима с LZMA, а скорость распаковки — с LZO. А ещё BitStream и вспомогательный адаптер за потоками сжатия, главная и единственная функция которого — запоминать / сообщать конец «адаптируемого» потока, не используя позиционирование. (Хотя везде так делают, наверное). Иначе возможен такой сценарий: читаем сжатый файл блоками произвольного размера, декомпрессор ВНЕЗАПНО рапортует конец данных посередине блока, а при попытке сдвинуть позицию назад выясняется, что «адаптируемый» поток не умеет Seek.

— Зависшие скрипты убиваются по таймауту (LUA_HOOKCOUNT).

Это я от UBO отлыниваю, ага.
>> No.11251  
Хде мои апдейты блжать?!
>> No.11252  
>>11251
Будут.
>> No.11255  
>>11252
Слава богу.
>> No.11261  
>>11255
Или не будут. Не знаю.
>> No.11273  
>>11261
А что такое? У тебя все хорошо, надеюсь?
>> No.11544  
Файл: 08_07_2014 17:31:54_261.png -(1044 KB, 1161x653, 08_07_2014 17:31:54_261.png)
1044
Прикрутил локализацию. В обычные строки вставляются необычные фрагменты, сущности обязуются помнить об этом и получать настоящий текст как localizedText = locale.localize(text). (Сущность может установить обработчик смены локали, чтобы не дёргать это лишний раз, а также оптимизировать случай, когда никаких необычностей в строке всё-таки нет). На данный момент функциональность необычных фрагментов исчерпывается лукапом в свалку луа-скриптов вида

misc =
{
    months =
    {
        jul =
        {
            ru = "Июль",
            be = "Ліпень",
            ...
        },
        ...
    }
}

"8 " .. Localized "misc.month.jul" .. " 2014". Позже добавлю падежи, числительные и т. п., правда, для этого, видимо, необычному фрагменту придётся заниматься детективным расследованием окрестностей строки... а, ну или просто просить все нужные данные на месте Localized и запоминать где-нибудь внутри себя.
>> No.11548  
>>11544
Я делал так (быдлокод, яваскрипт): массив английских строк, массив русских строк, "текущий язык" = ссылка на один из этих массивов. Соответственно из текущего языка вставляется нужный элемент массива.

http://www.everfall.com/paste/id.php?06il598zoedx
>> No.11552  
Файл: fb1cab6a01cc08cc7e123c020382721d.jpg -(144 KB, 735x1000, fb1cab6a01cc08cc7e123c020382721d.jpg)
144
>>11548
Разумеется, в реальности твоего способа достаточно. Я ориентировался на «автоматическое» разруливание локализации, т. е. внешне для текста или идентификаторов картинок задаются те же строки, что и раньше, просто слегка магические, возможность изменить язык на лету и подобные, может быть, крутые, но явно спорной полезности вещи.

Также не уверен, логичнее языки как «корни» или «листья» «дерева переводов». Похоже, обычно используют первый вариант, но мне второй показался более симпатичным, хотя бы потому, что не рассинхронизируется каждым чихом.
>> No.11601  
Файл: pushka.png -(38 KB, 1224x677, pushka.png)
38
Nu eto voobsche pushka!
>> No.11603  
>>11552
Посмотри, как делаются локализации общепринятыми методами (gettext с кучей оберток на него в разных языках и разных форматах, от гнушного и всяких явастрингов до простого key:value жсона).
Ты придумал очень неудобную и трудноподдерживаемую систему, у тебя какая-то логика в этой штуке, ее там быть точно не должно.
>> No.11628  
Файл: 33038196.jpg -(460 KB, 829x1000, 33038196.jpg)
460
>>11603
Я почитал про gettext и мне она не очень понравилась, неуклюжая какая-то, и вообще подходы, основанные на разборе исходников, выглядят кричащей кустарностью. Какая ещё логика? По сути это идентификаторы строк. Нет, то есть была мысль сделать передачу произвольных параметров, типа

local count = 500
gui.control.text = Localized "you_killed" .. Localized("how_much", count) .. Localized "epilogue"

you_killed = { ru = "Ты убил" }

how_much = { ru = function(n) if n < 500 then return n elseif n == 500 then return "пятьсот" else return "больше пятиста" end end }

epilogue = { ru = "наших людей в одиночку. Мы называли тебя человеком-армией. Но я и не думал, что ты настолько молод." }


но это уже извращение. Хотя, если положить функции встроенными и специально предназначенными для разруливания подобных моментов в языке, почему нет:

local count = 500
gui.control.text = "Ты убил " .. count .. Localized("of_our_people", count)

of_our_people = { ru = "наш{его/их/их} {человека/человек/людей}" }


***

Переписал паки. Теперь они умеют непрерывное сжатие, с оглядкой на то, что приоритетом всё же является скорость распаковки. Собственно, непрерывно сжались только шейдеры, скрипты и подобная мелочёвка, так что это было не слишком необходимо.

***

И насчёт Луа. Вообще-то сборка мусора для тех модулей с переводами была слишком агрессивной, подумал уж было выделить им отдельный луа-стейт, но в итоге просто реализовал ссылки, удерживаемые в течение некоторого времени (системными таймерами). В связи с этим, а также учитывая, что в моей архитектуре основной цикл выполняется не внутри скрипта, а просто дёргает иногда скриптовые обработчики, захотелось разрешить выполнять скриптовые функции из разных потоков. Не знаю только, как это по-красивому обставить, явные локи вокруг Push / Call / Pop как-то совсем неок. Call(getArgs, recvResults), что ли.
>> No.11635  
>>11628
Мне последнее время приходится много работать с разными локализациями, и кустарным мне кажется именно твой вариант. А геттекст, он немного не так работает, а скорее
gettext("Я хочу здесь этот текст")
В .po что-то вроде
id "Я хочу здесь этот текст"
el "κακή μετάφραση"
Т.е. обычный кей-валью, просто с кучей всяких тулз для автогенерации всего этот локализациомусора, и тысяча оберток еще. И ты совсем даже не паришься о том, что у тебя где-то миллион строк в одном файле, потому что этот файл автогенерируемый, а так же отлично скармливается всяким автопереводчикам.
У тебя я вижу логику из-за вложенных контейнеров, это само по себе несет в себе какую-то логическую связь между внешним контейнером и внутренним. Обычно такие конструкции влекут за собой много изменений, когда ты меняешь какие-то коренные элементы логики.
Про функции в этой штуке забудь, не на пхп же пишешь, в самом деле.
>> No.11669  
А какую именно часть движка ты пишешь на паскале, а какую на Луа?
Чистый паскаль, дельфипаскаль (Д1-Д14) или чистый Дельфи (15+)?
Сильно ли любишь Элону?

Если что я тоже очень давно пишу на Паскале, начал на чистом, быстро перешёл на дельфипаскаль, после 4 года на чистом дельфи.
>> No.11670  
>>11669
> после
Последние
>> No.11800  
Бампну тогда СыОПа на ичаневе.
>> No.11815  
Я надеюсь, проект не заброшен?
Мечтаю, что когда-нибудь я скачаю готовую версию и ммм....
Меня охватит единый организм самописного движка.
>> No.11907  
Файл: 36657218_p12.jpg -(182 KB, 640x640, 36657218_p12.jpg)
182
>>11669
Ответ со скоростью молнии. Движок на FPC, игра на Lua. Что такое движок, а что — игра? А хрен его знает! Движок предоставляет примитивы вроде звука-в-сцене, таймера-привязанного-к-объекту-сцены, ригид-боди или GUI-окна, которые скрипт собирает во что-нибудь осмысленное, как-то так. В Элоне, да, влюбился в атмосферу приключения, хотя дальше убийства короля даже не проходил: пусть и проникнувшись философией DCSS, ничего не имею против гриндинга, по крайней мере, в таком-то мире, но вот кое-откуда она позаимствовала худшее, что вообще можно было позаимствовать — отвратительные боёвку и особенно магию. Музыка местами хорошая. А впрочем, пойду пройду.

Я рипнул перо ಥ_ಥ Посему говнорисунков не будет, просто расскажу, что сделал:

ГПСЧ с сохраняемыми состояниями. Случайность в макромире подразумевает не Ъ-недетерминированность, а набор факторов, которые ты не смог или не захотел учитывать. Связываем с каждым объектом, использующим RNG, отдельный генератор, и последовательности «случайных» событий повторяются после сохранения/загрузки. PROFIT!

Сопрограммы a.k.a. волокна a.k.a. невытесняющая многопоточность. В луа поддерживаются из коробки, для нативного кода WinAPI предоставляет SwitchToFiber, а POSIX — setcontext, но последний меня пугает. В смысле соотношения пользы и сложности реализации оно того не стоило и у меня иногда падает обработка исключений в волокнах (может, проблема в RTL? ещё проверю), так или иначе, теперь можно в скрипте вместо

Scene:Query(center, radius,
  function(obj)
    print("Объект в радиусе: " .. obj)
  end)


делать

for obj in Scene:ObjectsInRadius(center, radius) do
  print("Объект в радиусе: " .. obj)
end
,

где очередной объект возвращается в недрах поставленного на паузу рекурсивного обхода дерева, т. е. технически это прежний вариант с yield(obj) вместо вызова функции. В пределе на синтетическом тесте вообще без работы по получению следующего значения, т. е. for i := 1 to N do Yield(i), волокна до 5 раз медленнее формирования списка результатов, которое, в свою очередь, до 3 раз медленнее варианта с пользовательской функцией, однако разница быстро нивелируется, если между вызовами итератора или в них самих выполняется хоть какая-то работа. К примеру, взвешенно-случайный выбор элемента алгоритмом, который здесь: http://eli.thegreenplace.net/2010/01/22/weighted-random-generation-in-python/ — назван «king of the hill», с волокном в качестве источника весов медленнее всего в 1.5 раза.
>> No.12012  
Файл: 1016122.jpg -(671 KB, 1023x723, 1016122.jpg)
671
Прикрутил https://code.google.com/p/crunch/.
>> No.12081  
Файл: 0e5a3fd858cf31e84ce509109406a914.jpg -(127 KB, 600x600, 0e5a3fd858cf31e84ce509109406a914.jpg)
127
Сравнительный тест производительности куч от 1337_POCAN.

- Входные данные и примечания -
На графе с 12K точек и 88K рёбер выбраны 2000 пар точек (начало, конец), для каждой из которых существует путь длиной 200–272 (в среднем 228).
Все поиски покрывают 99,25% точек, все пути — 42,4%.

Для алгоритмов Дейкстры и A★ применяются различные реализации очереди с приоритетами.

RMHhttp://en.wikipedia.org/wiki/Randomized_meldable_heap. Используется ГПСЧ https://gitorious.org/crawl/crawl/source/83560a2567f7eacda5d71d64f4a813efe1c88c2f:crawl-ref/source/asg.cc с фиксированным начальным состоянием, причём выжимаются ВСЕ биты (это быстрее).
Наивная куча — подразумевает хранение узлов в неупорядоченном списке и поиск за O(N), но зато Put и Decrease за O(1).

- Статистика по алгоритмам -
A★ в среднем вызвал 6600 Put, 6500 Get и 3400 Decrease, максимальный размер очереди — 310.
Дейкстра в среднем вызвал 10800 Put/Get и 2450 Decrease, максимальный размер очереди — 262.
Поиск в ширину: максимальный размер очереди — 398.

- РЕЗУЛЬТАТЫ -
Двоичная куча: A★ 17,4 с, Дейкстра 22,4 с.
Троичная куча: A★ 15 с, Дейкстра 20 с.
Четверичная куча: A★ 13,8 с, Дейкстра 18 с.
Восьмеричная куча: A★ 13,1 с, Дейкстра 17,2 с.
Шестнадцатеричная куча: A★ 13,2 с, Дейкстра 18,1 с.
Фибоначчиева куча: A★ 17,8 с, Дейкстра 24,2 с.
Двоичная RMH: A★ 12,6 с, Дейкстра 18,6 с.
Троичная RMH: A★ 14.7 с, Дейкстра 18,5 с.
Четверичная RMH: A★ 13,6 с, Дейкстра 17,1 с.
Восьмеричная RMH: A★ 15,6, Дейкстра 19,9 с.

Наивная куча: A★ 10,6 с, Дейкстра 13.3 с.
Поиск в ширину: 6,2 с. лол
>> No.12089  
>>12081
Автор Braid об этом весело рассказывал. Про Doom особенно смешно.

https://www.youtube.com/watch?v=JjDsP5n2kSM#t=554
>> No.12539  
>>10050
Как хорошо быть программистом, эх
>> No.12843  
Файл: 28_04_2015 14:13:50_133.png -(12 KB, 270x105, 28_04_2015 14:13:50_133.png)
12
Перекатился на Lua 5.3. Настоящие целые на уровне VM — это хорошо.
>> No.12855  
Простите, а что это такое? Ни на сайте, ни в обоих тредах внятно и четко не сказано, что являет собой эта rr-rr.
Ну разве так можно?
>> No.12858  
Файл: f72f5c09bf5ffa8ff2aa43a7e6988172.jpg -(233 KB, 528x800, f72f5c09bf5ffa8ff2aa43a7e6988172.jpg)
233
>>12855
Во-первых, мне лень и писатель из меня так себе.
Во-вторых, это уберёт элемент загадочности, при условии, что он вообще существует.
В-третьих, до «3D-бродилка про Сырну» можно и догадаться (я делал концепт подетальнее, которого один хрен не придерживаюсь).
В-четвёртых, считаю невозможным мейнстримом навязываться аудитории «смарити какой у нас клёвый праэкт можно делать так и вот так» каким бы то ни было образом и не очень люблю, когда так делают (а коль скоро так почти все делают... ну ты понял).
В-пятых и подытоживая — да, можно, мне норм.
>> No.12866  
Файл: 28_05_2015 21:59:43_994.png -(952 KB, 1050x700, 28_05_2015 21:59:43_994.png)
952
С мылом и подправленным глазом, хоть проблемы им далеко не исчерпываются.
>> No.12932  
Файл: контуры-а.png -(347 KB, 1200x800, контуры-а.png)
347
Thy soul shall be my breakfast!
>> No.12933  
So sexy~
>> No.13006  
Файл: log-Shu [debug].zip -(24 KB, x, log-Shu [debug].zip)
24
Падает при старте
>> No.13014  
Файл: 30957620.png -(786 KB, 768x768, 30957620.png)
786
>>13006
Спасибо, обновил драйвер, словил то же, исправил. Narkomani. Вот была функция glGenBuffers(..., &id), «старая» модель glBindBuffer(id) + работа с прибинденным буфером без указания id и «новая» glNamedBuffer...(id, ...), так нужно было её сломать до несовместимости, «кароч glGenBuffers на самом деле не создаёт буфер до первого Bind'а, бинди сразу или используй glCreateBuffers, введенную в OpenGL 4.5 не пойми зачем)))». Это могло было быть сделано, чтобы заставить меня как программиста указывать конкретную версию API, чтобы ломающие изменения в дальнейшем обходили меня стороной, но я это и так делаю, лол.
>> No.13015  
>>13014
Fixed pipeline api давно depricated, чего ты хотел?
>> No.13018  
Файл: 22934769.jpg -(240 KB, 680x771, 22934769.jpg)
240
>>13015
-_-" То API не имеет никакого отношения к FFP (ты бы ещё DOS вспомнил), я назвал модель

bind(A)
foo(...)
bar(...)
bind(B)
foo(...)


исторически более старой против

foo(A, ...)
bar(A, ...)
foo(B, ...)

(ARB_direct_state_access)

но принципиального преимущества нет ни у одной. Первая менее удобна и с ней теоретически больше заморочек при работе из нескольких потоков, т. к. «текущий объект» должен быть thread-local, зато она и более расширяема, тогда как попытка расширить вторую приведёт к объединению недостатков обеих. Мне просто непонятен смысл вводить функции вроде glCreateFramebuffers с чуть другой семантикой, когда уже есть glGenFramebuffers. При том что семантика glCreate*, по-видимому, обратно совместима с glGen*. Нонсенс.
>> No.13229  
Файл: b5ffb94b33bd494380072e8b439b4348.jpg -(297 KB, 567x800, b5ffb94b33bd494380072e8b439b4348.jpg)
297
Сделал интерполяцию строк в скриптах, т. е.
> format "цепочка длины {n} (R = {dist})"
вместо
> format("цепочка длины {0} (R = {1})", n, dist)
или
> "цепочка длины " .. n .. " (R = " .. dist .. ")".
>> No.13243  
>>13229
>интерполяцию
значение знаешь?
>> No.13244  
Алсо, это твой рисунок последний? Ты нехило так продвинулся, мож ну его этот кодинг, иди лучше хентай рисуй.
>> No.13251  
>>13243
https://en.wikipedia.org/wiki/String_interpolation же.
>> No.13252  
>>13251
А, спасибо, не знал что это так называется. Термин дурацкий все-таки, при чем тут интерполяция?
>> No.13253  
>>13252
Не термин дурацкий, а восприятие у тебя дурацкое. Весь мир несколько десятков лет использует это слово и всем норм.
>> No.13254  
>>13253
Извини, что задел твои чувства, братан, но я программирую десятилетиями и слышу это словосочетание впервые. И оно не имеет ни малейшего отношения к интерполяции, поэтому оно дурацкое. Там же в вики приведены нормальные аналоги - подстановка переменных и раскрытие переменных. Сразу понятно, о чем идет речь.
>> No.13256  
Удваиваю, это всегда называлось шаблонированием, а интерполяция - это вычисление промежуточных значений между известными.
>> No.13259  
>>13252
Интерполяция означает, что в рантайме вычисляется "содержимое" строковой переменной.
http://perlmeme.org/howtos/using_perl/interpolation.html
Во всяком случае, это то, про что статья >>13251. К обработке строк это никакой причастности не имеет, поскольку идет речь именно про распихивание байтов внутри кода во время выполнения программы.
>> No.14172  
> Last Update: 20 hours ago
Сидит в крысу пилит, а тред забросил, гад.
>> No.15149  
Файл: ReadDirectoryChanges.gif -(6850 KB, 640x376, ReadDirectoryChanges.gif)
6850
Когда прочитал про ReadDirectoryChanges.
>> No.15181  
Файл: 1342459081764.jpg -(160 KB, 664x768, 1342459081764.jpg)
160
Анон, я уже довольно долго наблюдаю за твоим проектом, с периодичностью в 3-4 месяца забывая про него, и вспоминая снова.

Расскажи, пожалуйста, вот что. Откуда ты черпаешь информацию по правильному применению OpenGL? Я сам разработчик, немного пытающийся в игродев. Вот только с гл, по всей видимости, без бутылки не разберешься. То-есть, я знаю всю базовую функциональность: шейдеры/вершинные массивы/индексы/состояния, но нету абсолютно представления, как рендерить сложные сцены, а все попытки попробовать кончаются как гроб, кладбище, лаги, ноль кадров в секунду. Мне кажется я упускаю что-то. Может, посоветуешь что-то почитать из книг, или подскажешь правильный вектор гуглинга?
>> No.15188  
Файл: 6a9f80e2550288b094a14ef14be8b053.jpg -(1474 KB, 1181x1748, 6a9f80e2550288b094a14ef14be8b053.jpg)
1474
>>15181
Оно не «правильное», я до сих пор не могу UBO и окклюжн запилить :(

Очень сильно не должно тормозить, если только ты какую-нибудь глупость не делаешь, типа пересоздания/перезаливки ресурсов каждый кадр, или Get*/Finish. Посмотри в профилировщике, откуда именно лаги. Если действительно OGL, отсечения должны помочь. По фрустуму легко отсекается под 3/4 (в предположении, что вид от первого лица, угол обзора 90°, а сверху-снизу ничего нет), окклюжн в закрытых пространствах должен отсекать вообще почти всё, но он сложнее.
>> No.15189  
>>9999
А с чего ты вообще начинал, Стив?
>> No.15190  
>>9999
То есть, ты студент? Чем по жизни занимаешься? Как у тебя вообще ЧТО-ТО выходит? Если не затруднят вопросы, ответь, пожалуйста.
>> No.15191  
Файл: efc185a092d69e0dc67ecf84ef087bd9.png -(560 KB, 750x750, efc185a092d69e0dc67ecf84ef087bd9.png)
560
>>15190
Я крутой хикки! (Поэтому делать нечего.)
И у меня не выходит...

И я бы к этому ТАК не относился. Я с ужасом осознаю, что отношусь к некой немногочисленной, но прослеживающейся категории людей (специально не искал: раз http://freepascal.ru/forum/viewtopic.php?t=10058, два http://spaceway.1gb.ru/, три http://www.gamedev.ru/projects/forum/?id=140784), которые, значит, решают запилить некий «сложный» (нет) проект на Паскале, но при этом:

а) не имеют представления о базовых вещах. Первый в конце треда на полном серьёзе говорит о формировании финальной картинки из нескольких не как о чём-то самом собой разумеющемся, у третьего вообще какая-то непортируемая жесть, которая сегфолтится при любых сценариях использования, отличных от тривиальных, и куда «Lua-ссылки» добавлены автор сам не понимает зачем (в доке так и сказал... «я не так часто пользуюсь Lua», ну просто лол, оно и видно). Да достаточно на исходники взглянуть. Второй их закрыл, но там было хуже первого и третьего вместе взятых, что-то уровня глБегин с шейдерами. (Некрасиво с моей стороны, да, пацаны в лицо говорят. Пофиг.)

б) ввиду (а), а также сломанности самого языка (отчасти — RTL), у них получается многословная и неповоротливая система, нет, груда плоти, которая кровоточит и кричит «убей меня» (aka «перепиши на C#», как Game Maker). Иногда её тянут и иногда она всё же выезжает, чисто экстенсивно, как Castle Engine. Но, как по мне, в проектах на других языках относительная доля треша всё же поменьше 100%.

Вооот. Не то чтобы я собирался свой проект переписывать, но как-то это всё неправильно. :(
>> No.15207  
>>15191
>Я крутой хикки! (Поэтому делать нечего.)
Но образование есть какое-нибудь?
>> No.15211  
>>15188
А чем можно профилировать эффективно? Вот есть стрейтфорвард вей, установить swap-интервал в 0 и засечь количество кадров в секунду, например. Но это измерение в попугаях. Прочитав твое сообщение, погуглил и наткнулся на apitrace. Весьма неплохо, показывает состояния, полный трейс вызовов gl*, но это все равно не дает понятия о том, где происходит потеря производительности. Такое ощущение, что где-то провал в софтварный режим. У меня Intel HD4000, но что меня смущает, это то, что даже ААА-игры более-менее сносно работают, не проваливаясь никуда.

Что имею конкретно: пытался прикрутить к контексту рендеринг текста. Был взял FT2, и для каждого требуемого символа загружена текстура и создан дисплейный лист (glNewList) с прямоугольником. Далее происходит биндинг требуемой текстуры, вызов нужного листа, перенос матрицы отображения, всё. На мой взгляд, простейшие операции, но стоит выйти за сотню рендеримых прямоугольников, так количество попугаев падает до нуля. Я даже выкинул другие изменения состояний из цикла вывода, но это не изменило ничего. Неужели это так и должно происходить? Что тогда делают в топовых игорях, чтобы держать частоту кадров на уровне, не понимаю?
>> No.15214  
Файл: trebuc.gif -(80 KB, 384x256, trebuc.gif)
80
>>15211
Склей все буквы в один текстурный атлас (у меня прям весь из себя динамический ←>>10485, но если не выделываться, то проще и надёжнее единожды сгенерировать и забыть) и рисуй текст моделью из N квадратиков, вырезающих нужные буквы текстурными координатами. Оптом дешевле, это очень общий принцип. Не используй glNewList, он мог бы быть полезной штукой (коль скоро что-то похожее, буферы команд, есть на низком уровне), но на деле давно убран из спецификации. Листы < ничего (glDraw*) < VBO (glDraw* под glBindBuffer).

>>15207
https://vk.cc/5WSQTW

Раз уж такое дело, я хотел за начало декабря запилить
1) нескучные MIDI-с-изменяемыми-параметрами (т. е. каждый раз у конкретной песенки подкручивается скорость или октава, что как бы превращает её в несколько) — в принципе, это должно свестись к (BASS_MIDI_)StreamGetEvents + <шаманство над MIDI-дорожкой> + StreamSetEvents

2) сделать нормальный парсер шейдеров (очень бы пригодился для человеческого синтаксиса всего, что я там нагородил, и вытаскивания метаинформации вроде используемых юниформов, например, чтобы автоматически подставить вместо них layout(shared) UBO) — можно слизать у https://github.com/graphitemaster/glsl-parser

3) переделать пространственные деревья (а они просто глючат) — этих ребят хочу заставить самих переразбивать себя, когда посчитают нужными

но сделал только, э, подзадачу (1) остальное как-нибудь в январе, ладно?)): теперь, короче, музыка (и звуки) работают в отдельном потоке, вернее, на таймерах, подсел на это дерьмо (ранее я и освобождение ресурсов по таймауту на них переписал). Зачем: чтобы не требовать дёргать BGM.Process(DeltaTime) в «основном цикле», которого может вообще не быть. Что именно происходит: во-первых, с началом воспроизведения песенки плеер взводит на оставшееся время таймер поставить новую, во-вторых, можно начать воспроизводить звук (или сказать ему фейдаутнуться) и забыть о нём, освободив все ссылки — на время воспроизведения звук доверит одну таймеру и тот освободит её, когда звук довоспроизводится/дофейдаутится (избегая немедленной остановки в деструкторе).
>> No.15215  
>>15214
Это получается, что на каждый текстовый объект проще сгенерировать массив вершин? Что делать, если текст динамический? При изменении перезагружать вершины? Звучит сомнительно, но я попробую.
Что до текстурного атласа - получается, что набор символов должен быть известен заранее. А если это нет возможности узнать, то как быть?
Ну и возвращаясь к идее более сложных сцен. Допустим, что текст можно попытаться уложить в один-два объекта. Но если, не дай боже, нужно будет рендерить различные модельки с различными текстурами? Их же не склеишь в одну большую модель и текстуру.
>> No.15216  
Файл: 24577265.jpg -(81 KB, 480x640, 24577265.jpg)
81
>>15215
В варианте с матрицами ты, заливая по 16 чисел на символ, косвенно делаешь то же самое, а ведь они на такое даже не рассчитаны! (против потока вершин, даже usage-подсказки в glBufferData завезли).
Чисто ради самоуспокоения спроси у своего шрифта количество символов и нарисуй их все =3.

Один дип на модельку — нормально, их ведь так и делают, с развёртками, вот этим всем. Одномоментно видимых вблизи много не будет. Невидимые рисовать не нужно. Вдали можно рисовать спустя рукава (импостером etc.).
>> No.15347  
>>9999
Уважаемый, ты там с голоду умер?
>> No.15388  
Файл: QUALITY_7.jpg -(137 KB, 1188x791, QUALITY_7.jpg)
137
>>9999
Ответь же!
>> No.15465  
Где предыдущий тред? Совус, заяем удалил?
Объясните же уже, что это такое-то, блдажд, о чём тред!
>> No.15472  
>>15465
http://410chan.org/dev/arch/res/4274.html
http://410chan.org/dev/arch/src/135204332896.txt
>> No.15493  
Файл: ship.gif -(32 KB, 330x194, ship.gif)
32
>>15347
Нормалфаги под кроватью пытаются отбирать еду, но они тупые, легко обхитрить. Сделал двухминутное кинцо, зацени: https://github.com/runewalsh/rox-loh/releases/download/v1.0/rox.rar. Это было в меру бесполезно, но по крайней мере понял, как нужно было работать с окном и GL-контекстом — потом как-нибудь перенесу реализацию в основной движок.
>> No.15574  
>>15493
Целый месяц еду отбивал?
>> No.15616  
Файл: 26152978_p0.jpg -(293 KB, 744x908, 26152978_p0.jpg)
293
Ой дебил, навелосипедил тогда слежение за звуками, которые закончили воспроизведение, закончили фейдаутиться, etc., а мог бы просто дочитать документацию до возможности установить коллбэки на эти события. То же касается и MIDI: можно, конечно, патчить треки при загрузке, но официально одобренный способ >«подкрутить скорость или высоту» — хукнуть и перекрывать на лету соответствующие MIDI-события (TEMPO/PITCH/etc.). Завтра переделаю (от велосипеда останется одна блокировка).
>> No.16218  
Файл: qwe.gif -(816 KB, 700x500, qwe.gif)
816
Попробовал переписать пространственные деревья: моя реализация от 2k11 слегка глючила и требовала вызывать перестроение явно, а теперь решил для каждого узла вести учёт ИСКАЖЕНИЙ (красные прогрессбары толщиной в пиксель), и по превышении порога искажённости перестраивать автоматически. По части глюков получилось ещё хуже прежних, вплоть до неработоспособности. На гифке-то всё в порядке, но вот на реальной сцене... Нужно ковырять. Например, записать последовательности операций с деревом, приводящие к «невозможным» результатам, и плясать от них. Эх, вот я криворучка.

С этим условный фейл, а вот MIDI доделал.
>> No.16286  
>>16218
Красивая гифка.
>> No.16349  
>>16218
Я не понял, математические деревья ты имеешь в виду или реальные, потому что на гифке как будто программа для моделирования сада. Сам хотел такую написать.
>> No.17390  
Бамп, хотелось бы апдейтов. Продолжай пилить, ну.
>> No.19389  
Что-то застряла разработка. А сф теперь при скачке говорит: malware detected, download at your own risk. Это что же получается?
>> No.19390  
>>19389
ОП взял твои деньги и свалил в Мексику.
>> No.19393  
Файл: 67132246_p0.png -(475 KB, 800x1067, 67132246_p0.png)
475
>>19389
Всё не могу себя заставить ту Сырну дорисовать. Ничего, уже вот-вот, сейчас всё будет, ещё немного, ух. шёл 2018

Мальварь, по-видимому, детектится из-за того, что скомпилированный FPC бинарник зачем-то импортирует ReadProcessMemory. Возможно, стоило бы посмотреть, зачем именно, и репортнуть на багтрекер, но вот, скажем, у меня похожая проблема с PyInstaller, и их позиция — не подстраиваться под антивирусы (https://github.com/pyinstaller/pyinstaller/issues/680), что в идеологическом смысле правильно:
>The only correct way to deal with antivirus is to report them that they are wrong. If we are working around them, we simply start a cat-and-mouse game that never ends.
Если убрать из таблицы импорта ReadProcessMemory (в качестве незаконного решения, не требующего перелопачивания структуры EXE, а только HEX-редактора, можно затереть названием какой-нибудь другой 17-буквенной функции kernel32, например, GetCurrentProcess), бинарник продолжает работать, но уже не даёт ни одного срабатывания на VirusTotal. Подозреваю, что там в каком-нибудь недостижимом пути исполнения какая-нибудь ерунда уровня ReadProcessMemory(GetCurrentProcess(), ...), т. к. если такое нужно сделать один раз, это может быть проще SEH или VirtualQuery.

Кстати, упоминавшийся в >>16218 баг был из-за того, что объекты сцены сдвигались, соответственно, и дерево апдейтилось в Newton-коллбэке http://newtondynamics.com/wiki/index.php5?title=NewtonSetTransform, который вызывается в ходе NewtonUpdate в потоках физики, а не потоке, дёрнувшем саму NewtonUpdate. Когда я делал физику, я ввиду своей наивности проигнорировал параметр с недвусмысленным названием threadIndex, а старое дерево не меняло топологию на лету (требуя явно вызывать Rebuild) и поэтому слабо портилось при гонке.

>>16349
Зелёным цветом показаны объекты, серо-синим вокруг них — узлы пространственного дерева (BVH), жёлтым — запрашиваемый объём, объекты внутри которого нужно вернуть. Обойдённые для этого узлы подсвечиваются красным. Если узел оказался полностью вне объёма, значит, все объекты внутри него можно сразу отбросить, не проверяя дальше (в этом весь смысл такой структуры). Если узел подсвечен сиреневым, то с точностью до наоборот: он полностью попал внутрь объёма и объекты внутри него можно сразу вернуть, не проверяя по отдельности. Выигрыш демонстрируется тем, что число проверок < числа объектов. Красная полоска над узлом эмпирически учитывает внесённые в него изменения, узел автоматически перестраивается, когда она переполнилась. По бенчмаркам всё плохо (но я пока не сделал нормальный бенчмарк, учитывающий разные сценарии, и не откалибровал логику автоперестроений), зато использовать проще, чем прежнюю реализацию, т. к. не нужно перестраивать руками.
>> No.19685  
Файл: _resetstkoflw.png -(19 KB, 689x824, _resetstkoflw.png)
19
Всегда хотел это проверить =3.
>> No.20299  
Жив еще, значит. Я спокоен.
>> No.21263  
Неужели этот уютный проект мертв? Не могу в это поверить. Я думал, вернее надеялся, что ты, подобно разработчику Dwarf Fortress, будешь пилить вечно.
>> No.21321  
Там всякую древность пробампили. А предыдущий тред по этому движку настолько стар, что он уже утонул. Утонул здесь.
Старость - это когда твой тред утонул на чиочане.
>> No.21335  
Файл: 71879815_p0.png -(368 KB, 600x500, 71879815_p0.png)
368
Я написал пост с планами, нытьём и одой одной транковой фиче Free Pascal, но там нужна Сырна для чуть большей убедительности. Мне очень стыдно, но подождите ещё немного, я больше не буду раскрашивать рисунки 4 года ><". Настолько не хотел этим заниматься, что N5→N1 выучил.
>> No.21341  
>>21335
Не стыдись, няша, это же твой проект. Ты делаешь его так, как хочешь. Я буду ждать апдейтов. На мой взгляд, у тебя интересный, самобытный проект.
>> No.21361  
>>21335
>N5→N1 выучил
Посоветуешь литературы?
>> No.21444  
>>21361
...
>> No.21738  
Не утонуть
>> No.24723  
Файл: Untitled-2.png -(125 KB, 1165x1322, Untitled-2.png)
125
Совершенно случайно обнаружил во Free Pascal’е SSE-интринсики! «А что, так можно было?»

Похоже, фича в разработке (гуглятся анонсы и обсуждения в fpc-devel за начало этого года): соответствующий инклюд должен был бы попадать в модуль System, но на данный момент всегда закомментирован. Если проигнорировать это и без задней мысли скопипастить internproc-объявления из compiler/rtl/i386/cpummprocs.inc себе — на скриншоте переобъявлены интринсики для movups(регистр ← память), movups(память ← регистр) и maxps(регистр ← регистр, регистр), то вроде как всё работает и компилятор берёт на себя распределение и спиллинг регистров, как и должно быть. Очешуеть просто, ускорение векторных расчётов — а это обработка картиночек и моделечек — в 10 раз, ценой специальных, условно компилируемых реализаций примитивных операций, таких как operator +(vec4, vec4) или function max(vec4, vec4), притом эти варианты даже проще оригинала: max(A, B) → R реализуется, как видно, как
movups(R, maxps(movups(A), movups(B)));

против
R.x := max(A.x, B.x);

R.y := max(A.y, B.y);
R.z := max(A.z, B.z);
R.w := max(A.w, B.w);

Ща дорисую, ща-ща, сек.

>>21361
Вряд ли смогу что-то конкретное посоветовать, т. к. по сути я, прочитав Нечаеву («Ты теперь свободен от текстов про Путятина?»), пошёл ковырять с блокнотиком неадаптированный контент (книги и ВН, невыносимо сложно только первую тысячу часов[/unironically]; кстати, если есть 2 часа, глянь десантниц https://vk.cc/8sWwSL) — где Нечаеву можно заменить произвольным учебником по БАЗЕ, а уж контент сугубо дело вкуса (https://vk.com/topic-57363092_29501407?post=7). Единственное что, для начала просто необходимо взять что-то с существующим переводом, т. к. есть тысячи способов ничего не понять или понять неправильно, которые нейтрализуются только опытом.
>> No.24724  
Файл: max.png -(2 KB, 469x88, max.png)
2
>>24723
>в 10 раз
У тебя там четыре непредсказуемых перехода в одной функции - конечно оно тормозить будет. Не знаю, может ли паскаль записать флоат в инт не перекодируя битики, но если может, то попробуй высчитать маску по условию и записать в результат без условия. Будет всё ещё медленно, но не настолько.

А вообще, я бы на твоём месте давно бы написал компилятор паскаля в сишку, и там бы сишный компилятор полуавтоматически это всё делал.
>> No.24733  
Файл: max [mask].png -(33 KB, 802x356, max [mask].png)
33
>>24724
Да, не подумал, у меня исходные данные триггерят худший случай с полностью непредсказуемыми ветками. Для сравнения проверил на полностью предсказуемых (pred) и сделал безбранчевый вариант (mask).
Относительно друг друга они работают за время, относящееся как
(vector) 1 : (scalar-pred) 2,1 : (scalar-unpred) 10 : (mask-pred) 3 : (mask-unpred) 3 (неудивительно).

Ранее я считал, что переносы между флоатовыми и целочисленными регистрами жутко дорогие: так, в Java при домножении 8-битного цвета на альфу у меня получался выигрыш в 7–13 раз (https://ideone.com/vj13We), если делать это не прямым
float alpha;

for (each pixel) pixel8 = round(pixel8 * alpha);
а, скажем,
int alpha10 = round(alpha * 1024); // 10 бит точности — эмпирическая цифра

for (each pixel) pixel8 = (pixel8 * alpha10 + 512) >> 10;
— в целых числах.

У @oldnewthing были статьи про SSE-трюки, где он прожужжал все уши domain crossing penalty:
>There are a few ways to load constants into SSE registers.
> • Load them from memory.
> • Load them from general purpose registers via movd.
> • Insert selected bits from general purpose registers via pinsr[b|w|d|q].
> • Try to calculate them in clever ways.
>Loading constants from memory incurs memory access penalties. Loading or inserting them from general purpose registers incurs cross-domain penalties. So let’s see what we can do with clever calculations.

Я даже думаю (так, примерно почувствовал), что в случае с альфой это связано не столько с domain crossing, сколько с латентностями флоатовых вычислений, которые вылезают при попытке сделать с результатом что-то интересное, вроде пересылки в целочисленный регистр. С бранчами вместо арифметики это не проявилось, но в целом касты, в т. ч. реинтерпрет_касты, между интами и флоатами без явной необходимости мне видятся такой себе идеей.

Кроме того.

Хотя для замера я расписал максимумы упрощённо, моя настоящая реализация соответствует определённой в IEEE 754 функции maxNum: если один из аргументов — NaN, она возвращает другой. Не так страшно, как звучит: если наивный максимум — это
if a > b then result := a else result := b;
то IEEE-комплиантный — его небольшая модификация:
if (a > b) or (b <> b) then result := a else result := b;
SSE этого, может быть, ради экономии транзисторов в 2000 году, не предусматривает (или же она детерминированно, если один из аргументов — NaN, возвращает не другой, а строго b), и я не уверен, можно ли полагаться на это в шейдерах, но это очень удобное свойство, и вот почему.

Мы постоянно работаем с величинами, которые можно рассматривать как веса эффектов. Тот же вклад диффузного освещения выражается косинусом угла между нормалью и направлением на источник света, иными словами, их скалярным произведением. Но в неосвещённом полупространстве косинус становится отрицательным, а вклад должен быть нулевым, поэтому окончательная формула принимает вид
diffuse = max(0.0, dot(normal, vec_to_light));
В более сложных случаях, той же модели Кука-Торренса, у нас появляется целая пачка таких промежуточных коэффициентов, отрицательность которых нам в этот раз даже и не страшна сама по себе, но они возводятся в степени, и принципиальное отличие между нулевым и отрицательным флоатами в том, что ряд функций, в первую очередь собственно pow(x, p), определены как возвращающие NaN для отрицательного x. По этой причине автор статьи https://habr.com/ru/post/424453/ (оригинал: https://learnopengl.com/PBR/Lighting) постоянно параноит отрицательность через max(0.0, value), тогда как с IEEE-комплиантным max() этого не нужно делать (по крайней мере в данном случае) — достаточно оставить финальный max(0.0, specular), который сделает из пропагейтнувшегося NaN’а тот же 0. В другой раз у нас может быть перемножение отрицательных чисел, которое вернёт не NaN, а неверный положительный результат, но в целом ряде случаев этого нет и можно спокойно убрать кучу паранойи.

Так вот, скалярный IEEE-комплиантный вариант, дописанный в ряд выше, показывает себя следующим образом:
(scalar-precise-pred) 2,2 : (scalar-precise-unpred) 11
то есть почти идентично наивным 2,1 : 10.

Таким же приёмом (добавлением b <> b) этого можно добиться и на SSE (https://stackoverflow.com/a/32332219). На FPC-интринсиках это выглядит как
function max(const a, b: Vec4f32): Vec4f32;

var
ma, mb: __m128;
begin
ma := _movups(@a);
mb := _movups(@b);
_movups(@result, _blendvps(_maxps(ma, mb), ma, _cmpps(mb, mb, {UNORD} 3)));
end;
и даёт практически идентичную чистому maxps, взятому за 1, скорость
(vector-precise) 1,05.

Аналогично — uint32((a.x > b.x) or (b.x <> b.x)) и т. д. — можно добавить поддержку NaN и маскам, но они начинают совсем явно проигрывать UPD: а нет, гениальный компилятор вычисляет это выражение через джампы, так что я переделал на форсированно побитовое uint32(a.x > b.x) or uint32(b.x <> b.x) и получился как бы не такой уж плохой результат:
(mask-precise) 6,
но меня всё ещё настораживает двукратная разница относительно этого же способа без NaN.
>> No.24736  
Файл: 70468793_p0.png -(198 KB, 3190x3366, 70468793_p0.png)
198
>>24734
UPD2: возможно, компилятор даже прав, вычисляя (a.x > b.x) or (b.x <> b.x) через джампы. Форсированно безджамповый вариант не взаимодействует с предсказателем и выдаёт 6 в любую погоду, а джампы выдают
(mask-precise-pred) 3,5 : (mask-precise-unpred) 11.
В предположении, что предсказатель работает (иначе зачем он нужен), реальные результаты будут гораздо ближе к 3,5, чем к 11, то есть лучше 6, и, надо заметить, однозначно (и ожидаемо) хуже исходных (scalar-precise). В частности, если мы вычисляем значение чего-то пикселеподобного и у нас вылезает конкретный результат a≷b или NaN, то у соседей, которых мы вскоре будем считать, с высокой вероятностью вылезет то же самое, поэтому предсказатель сработает лучше, чем его отсутствие.
>> No.24739  
Файл: Clipboard01.png -(71 KB, 1280x800, Clipboard01.png)
71
Почему исчезла собранная версия?Несколько лет назад была, с радостью играл.А что делать вот с этим безобразием, ума не приложу.
>> No.24768  
https://web.archive.org/web/20151021190423/http://410chan.org/dev/res/4274.html

просто чтобы проще было не терять
>> No.25030  
10 лет прошло с начала разработки. Технологии рендера изменились до неузнаваемости. Уже делают рилтайм рейтрейсинг с постобработкой нейроночками, и все это с аппаратной поддержкой.
...
А ты копаешь ассемблерный код сравнения чисел.
>> No.25117  
>>25030
Я конечно понимаю, что бесконечное копание ассемблерного кода это самоцель проекта, но почему бы по-быстрому не набросать то же самое на юнити. Мне кажется концепт сам по себе вполне играбелен, и достоин того, чтобы принять более-менее оконченный вид.
>> No.25121  
Файл: eb0aaea675a596d1f4a1b92f688a39ae.jpg -(57 KB, 599x479, eb0aaea675a596d1f4a1b92f688a39ae.jpg)
57
>>24739
Я удалил старые билды, а из исходников скомпилировать нельзя (на самом деле можно, но, пожалуйста, просто не пытайся). Всё будет, главное сейчас сидеть тихо и не бухтеть.

>>25117
Я не буквально «бесконечно копаюсь в ассемблерном коде» (хотя и занимаюсь чем-то близким по осмысленности), я и ассемблер-то почти не знаю. Просто написал под впечатлением, что вот, смотрите, интринсики завезли. BTW:
>>25030
>10 лет прошло ... Технологии рендера изменились до неузнаваемости.
Всё ясно, автору 10 лет.
Да нет, почти всё придумано в прошлом веке. ЭВМ Наири-3 поддерживала разделение времени и эмуляцию других ЭВМ. Рейтрейсинг и нейросети использовали ещё раньше.

>занимаюсь чем-то близким по осмысленности
Например, я буквально пару дней назад догадался сделать хранение базиса касательного пространства в вершине не обычными 2 векторами (нормаль + касательная, 3-й восстанавливается в шейдере через их cross), а кватернионом, т. к. этот базис, в предположении, что не может быть разортонормализован или отражён, представляет собой поворот некоторого исходного базиса — скажем, X = (1, 0, 0), Y = (0, 1, 0), Z = (0, 0, 1).

Ну, это старая идея и я давно читал про неё, но мне не хватало точности при хранении кватерниона как непосредственных X, Y, Z в 10-10-10 битах с восстановлением в шейдере W через √(1−x²−y²−z²), а хранить с лучшей точностью смысла нет (не будет выигрыша относительно 2 векторов). Теперь же я прочитал про идею (вот здесь в конце: https://archive.org/stream/GDC2015McAuley/GDC2015-McAuley_djvu.txt) отбрасывать не W, а максимальный по модулю компонент, и в 2-битовом W сохранить индекс отброшенного компонента. То есть кватернион (X, Y, Z, W) пакуется в один из вариантов:
(Y, Z, W, 0/3)

(X, Z, W, 1/3)
(X, Y, W, 2/3)
(X, Y, Z, 3/3)
Это выглядит страшно (распаковка предполагает 4 if'а), но, как я думал, даёт дополнительные полбита точности: поскольку мы отбросили максимальный компонент, ни один из оставшихся не превышает 1/√2, иначе он был бы максимальным сам. Поэтому мы можем домножить их на √2, выиграв log₂√2 = 0,5 бита точности при сохранении в нормализованный (U)INT_10_10_10_2.

На самом деле, во-первых, это работает более чем пристойно (более сложная распаковка компенсируется вдвое меньшим размером исходных данных), во-вторых, даёт точность, близкую к точности float32: во всяком случае, у меня кватернион, упакованный в 10-10-10-2 описанным методом и распакованный назад, в худшем случае составляет с исходным угол чуть больше 1/1000 радиана — и это всего на 20% хуже результата распаковки упакованного кватерниона сразу из 4×float32, без преобразования в 10-10-10-2. Для сравнения, кватернион, сохранённый в 10-10-10 просто как XYZ, в худшем случае отклоняется от оригинала на 1/10 радиана — это очень заметно в сингулярностях вроде верхушки сферы. То есть мы получили как бы не полбита точности, а все 6 ≈ log₂ ((1/10) / (1/1000)).

Целый мир (базис касательного пространства) умещается в 4 байтах, удивительно...
>> No.26014  
Тред умер?
>> No.26015  
>>26014
А ты думал, аффтору потребовалось если ответить 4 месяца на вопрос о пропаже билдов, и так их и не залить.
Но вроде что-то пилит.
>> No.26016  
Файл: eab5aeaf7edde6e28fc2a660c3d0cb3a.png -(3256 KB, 1200x1800, eab5aeaf7edde6e28fc2a660c3d0cb3a.png)
3256
>>26014 >>26015
Сказал же буквально на днях, всё будет, хорош шуметь.
>Третий тролль сказал: «Прощайте! Ненавижу болтунов».

За прошлый год я, хотя ничего не делал, стал парадоксальным образом в промышленных масштабах натыкаться на баги Free Pascal, отчего потерял терпение и повадился громко плакать о них на багтрекере в противоположность тому, как ранее натыкался на них раз в год и обходил переформулированием кода. Последние две недели плотно занимался https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/179, а вообще из всего, в чём засветился, мне больше всего нравится https://gitlab.com/freepascal.org/fpc/source/-/issues/39360 («копание в ассемблерном коде», да). Не подумайте, мне были жесть как нужны, соответственно, карманная база Юникода и ускорение генерации шума Перлина до уровня, когда текстуру с ним можно генерировать на месте, а не таскать с собой, здесь нет никаких проблем с приоритетами. Ну или, может, и есть самая малость, но кто сказал, что я прямо сейчас не возьму и не пойду дорисовывать Сырну?!
>> No.26018  
>>26016
>Сказал же буквально на днях
Где??
Но вообще, контрибы в язык - это ты малаца, завидно даже.
>> No.27280  
Гиде билды?
>> No.27282  
Файл: e2d39d729650d44e2f68be3d6fafde8b.jpg -(190 KB, 1684x2048, e2d39d729650d44e2f68be3d6fafde8b.jpg)
190
Хорош бампать, я сам бампну, когда придёт время.

Недавно гулял с сестрой в лесу. Она при всём уважении к моим хикки-привилегиям выразила заинтересованность в доступном объяснении, чем я занимаюсь целыми днями. Я сказал, что если честно, то делаю скорее не непосредственно свои проекты, а разные штуки для Паскаля (до этого сам похвастался, как сделал по просьбе человека с жёлтой аватаркой https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/446 за 1 день и €250; у человека свои причины улучшать совместимость с Delphi: https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg41878.html, но конкретно эти классы — очевидный бред и полная чушь и совершенная мерзость, решающая несуществующую проблему и не имеющая отношения к маршалингу, и мне стыдно за это; ковыряние с ассемблерным кодом в миллион раз лучше, одно моё творчество над стандартной функцией CompareByte ускоряет абьюзящие её программы на 10~20% в целом). Она спросила, зачем мне Паскаль, я сказал, что для той игры, которую показывал 10 лет назад. Она сделала сочувственное лицо и спросила, неужели я её до сих пор не доделал. Кажется, мой ответ заключался в том, что я ничего не делал всё это время, потому что мне было грустно, что у меня нет друзей. Этот ответ вроде как верен, и если не уточнять, что причина что-то делать у меня была точно такая же, даже удовлетворителен. *вздох*

Потом я рассказал, как один человек (вот он же это прочитает и поймёт, насколько скучно я живу...) принёс на свидание со мной планшет и заставил зарисовать некоторые идеи под дулом пистолета, и она сказала, что со мной только так и надо. *вздох*
>> No.27283  
>>27282
>Хорош бампать
Раз в полтора года слишком часто, нужно было хотя бы до круглой даты дотянуть? xP

Гиде можно добавиться к тебе во френды? Спрашиваю исключительно из личного интереса, может хочу поиграть в это поделие, а еще втереться к тебе в доверие и украсть всю интеллектуальную собственность, ха-ха-ха. В любом случае, добавление меня ни к чему не обязывает, мне комфортно сидеть и ничего не писать и ничего не получать. Но может мы что-то напишем, возможно даже по этой игре. Да!
>> No.27824  
Файл: 1710219386854.jpg -(44 KB, 1024x576, 1710219386854.jpg)
44
>>27282
О как, как увидел ник твой в fpc gitlab, так сразу подумал, о чем-то связанным с аиб, а сегодня и на этот тред наткнулся.
Спасибо за то, что делаешь в fpc dev.



[ d ] [ b / cu / dev ] [ r ] [ a / ts ] [ ci ] [ gnx / int ] [ misc ] [ dev / stat ]
[Burichan] [Futaba] [Gurochan] [Tomorrow] [Архив-Каталог] [Главная]