ЗАПИЛИЛ
　　　　СЕРИАЛИЗАЦИЮ
　　　　　　　　　　　　　СКРИПТА
　　　　　　　　　　　　　　　　　　^_____^

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

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

Фичи:

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

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

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

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

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

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

Т. о. save/load готов процентов на 50, на что я неделю назад и не надеялся. ^_^
To-do: сериализация всего остального (куклы, вейпоинты, сцена, GUI), ну и меню.

Запили~л сериализацию вейпоинтов короч. Не обычных, списком точек и рёбер — она-то давно была, а рантаймовых, тех, что получаются склеиванием фрагментов (в свою очередь вейпоинтов, но их уже по-другому и не сохранишь). В том же формате, что и фрагменты, это детище Франкенштейна занимало 150 Кб — может быть, и допустимо, но однозначно не круто.

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

На скрине вейпоинты, загруженные из явно другой сцены.

ОП ты молодец, скажи может тебе нужна какая то помощь. У меня есть опыт работы на паскале, хотя в последние годы использовал PHP.

>>10043
>какая то помощь.
>использовал PHP.

>>10043
Помощь по коду не нужна. Вот порисовать можешь.

>>10050

Подскажи как и из какого пакета 3D моделирования можно с наименьшими затратами импортировать 3D модели в FPC, какие библиотеки нужны и из какого формата? Blender подойдёт?

>>10054
Я использую OpenCOLLADA. Но фактически можешь экспортировать в любой формат, который прочитается максом.

>>10060

1.Расскажи что из SDL, GLUT, GLScene актуально и годно для 3D программирования в Delphi/FPC сейчас? Ты пробовал прикрутить к FPC SDL?
2.Говорят GLUT не торт, что ты об этом думаешь?

>>10067
Из всего, что ты назвал, графическим движком является только GLScene. Особо не ковырял его (несовместимость с религией), но вроде прикольный, много чего реализовано.

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

>Говорят GLUT не торт
Он умер в прошлом веке, freeglut просто не развивается.

Ф-фух. Процентов 80.
Это начинает надоедать.

Переделал прежнюю систему "действий" узлов сцены под анимацию чего угодно (как-нибудь прикручу и GL-параметры) сферическими многомерными сплайнами в вакууме. Как следствие, двери могут открываться менее красиво: движение по схеме "равноускоренно за t1 + равномерно за tU + равноускоренно за t2, да так, чтобы пройти за T = t1 + tU + t2 путь S, а начальная и конечная скорости равнялись v1 и v2" теперь лишь эмулируется. Но это скромная плата за такую-то вкусняшку.

И я всё ещё пилю сериализацию. Собственно, ради неё и переделывал.

Жирная!!
На самом деле она потянула за собой весь стейт, неожиданно для меня не ругнувшись за весь обход на неизвестный тип. Видимо, таки допилил. :3 Завтра попробую загрузить.

Ну вы поняли.

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

НО ОНО ВООБЩЕ РАБОТАЕТ!!! ヽ(ﾟ∀ﾟ)ﾉ

Ну что, долавливаю баги и рисую меню. Или ты нарисуешь, Стив? ^_^

>>10191
А зачем ты сериализуешь все? Сериализуй только изменения.

>>10208
Не с чем сравнивать, все объекты создаются в рантайме. А если бы и было с чем, я бы забил. А если бы и не забил, 3/4 занимает стейт Lua — опять же, рантайм.

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

>долавливаю баги
done

А сколько тебе лет и когда примерно заинтересовался разработкой игор?

>>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. В таблицах, выполняющих роль структур или классов в статических языках — а таких большинство, если не почти все — повторяется набор ключей. Его можно описать однажды и ссылаться индексом. Всё равно больше всего занимают дампы функций, ну его.

>>10278
Я после Морровинда заинтересовался только тем, как не играть в него.

>>9999
>9999
ахуеть гет же
Анон как сделать в твоей параше больше двух сырн?

>Pascal

Long time no see, Steve!

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

↑ У меня есть шансы? ;_;
Завтра меню сделаю.

Оп, какие у тебя планы на игру?

>>10448
>У меня есть шансы?
Разумеется нету
> дорогие источники света
убери эту ебаную графику с крузиса и поставь графон уровня моровинда и норма будет

ПРИКРУТИЛ МЕНЮ!!! ^_^

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

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

>>10455
Нинаю
>>10465
Ну ты и сам должен понимать: графон определяется скорее качеством контента, нежели технологиями, так что--

>>10471
Что же мне делать?
Дрова новее не поставить: все установщики говорят, что "у вас самые новые дрова".

>>10472
Спасибо, не подумал сразу, теперь буду выжимать информацию об ускорителе и т. п. даже их полудохлого OpenGL'я. Но пока я вынужден, даже располагая логом, задать этот вопрос: какая у тебя вообще видеокарта? Если интел — ну, интел так интел, если нет — установщики врут, попробуй удалить старый драйвер.

>>10471
>Binary Shaders
done

Рванулся было заюзать SQLite, но здесь и сама файловая система отлично подходит.
Я должен зачем-нибудь воткнуть SQLite!!! Она классная.
У меня загрузка бинарника быстрее одной лишь линковки раз в 5, и это без учёта загрузки и компиляции самих шейдеров.

Превьюшкииииииииии :3
Внезапный to-do: TrueType-шрифты.

>>10473
Карточка - ATI Radeon HD 4600.
Дрова стандарто-незаменяемые WDDM v1.1
Я имею в виду, что совсем заменяться не хотят.
ATI Vision процессор видит, но на карточку ругается. Говорит, что дрова свои у него не активны. И активировать их тоже не может.

>>10480
Последняя версия говорит
"EAssertionFailed" raised: "Assertion failed (DLLoader.pas, line 200)"

http://clb.demon.fi/files/RectangleBinPack.pdf
Научился паковать атласы. Завтра встрою их в движок по-нормальному и посмотрю libfreetype.

Прикрутил шрифты за 2300.

Перестройка атласа может быть медленной и это исключительно моя вина, послезавтра оптимизирую всякие там блиты изображений, [исразуденормализация]SetPixel(Combine([нормализация]GetPixel())) — это несерьёзно.

>>10489
>оптимизирую всякие там блиты изображений
done
также добавил поддержку кернинговых пар, теперь и придраться-то не к чему.

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

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

Дедок, если читаешь это (ну вдруг) — назови свою станцию и отпишись, есть вопросы.

>>10492
Я не дедок, но на некоторые вопросы по CUDA ответить, думаю, смогу.

Вынес оконный цикл в отдельный поток.

Может быть нестабильным. Даже так: НЕСТАБИЛЬНЫМ. Особенно на XP. Если есть под рукой XP, докладывайте о результатах с window.allowMT = true — у меня всё мерцает, и если не только у меня, то дело в этой их "новой модели драйвера" начиная с висты.

Переписал события на Condition Variables, ну, кроме тех, что задействованы в WaitForMultipleObjects (реализовать можно, но придётся сильно усложнить структуру события: http://stackoverflow.com/questions/2719580/waitforsingleobject-and-waitformultipleobjects-equivalent-in-linux/7782618#7782618) и MsgWait＊ (а здесь, я так понимаю, без вариантов). У меня работают раза в 2 быстрее.

И всё же, какую семантику выбрать — Event или CV, и почему? И предоставляют ли CV вменяемый аналог WFMO в значении WaitForAny?

Добавил в движок сущность 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. ^^"

Запилил:
— Поддержку геймпада (USB HID API). Наверняка рассыплется на моделях с количеством кнопок, отличным от моего (16). Коль скоро кнопки, в отличие от аналоговых стиков, свой Usage не говорят, я вижу единственное решение — предлагать калибровку пользователю. Кто как делает? Есть другие способы?

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

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

Ладно, хватит ерундой заниматься.

>>10588
>Ладно, хватит ерундой заниматься.
Действительно.

>>10589
Эй!

>>10592
Да просто обидно, что автор растрачивает талант на всякую ерунду.

>>10603
Какие глупости ты пишешь.

>>10605
Просто ты не можешь в иронию.

Чуть позже выложу.

Прикрутил асинхронный I/O. Reason: компиляция шейдеров в рантайме и так тормознутая, только синхронного кэширования и не хватало. Плюс, для стриминга пригодится, если руки дойдут.

Про ерунду уже сказал, так что понапридумывайте мне ваултов aka кусков уровня.

>>9999
Анон, тебе приходилось перелопачивать значительную часть кода, когда надо было внести изменения в одно место или когда новую фичу добавлял?
Ты пользуешься какими-нибудь диаграммами классов, схемами, рисунками или все в голове держишь?

>>10729
В отдельных фичах не замечал, но того, что в целом я уже переписал весь движок несколько раз, это не отменяет.
>Ты пользуешься какими-нибудь диаграммами классов
Пользовался бы, если бы такие средства существовали для FPC. ha-ha.
>схемами, рисунками
Конечно. Грех, располагая столь слабым CPU, не юзать столь мощную видеокарту, евпочя.

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

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

А ещё прикрутил выравнивание (без него иногда просто некорректно работают, да) атрибутов, interleaved вершины, объединение совпадающих VAO и шейдеров (с последними оно того не стоило, но пусть остаётся), ну и по мелочи.

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

>>10740
Н-но я изначально так и сделал... T_T

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

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

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

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

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

To-do: Lua-консоль.

>>10744
http://goo.gl/NVUvyX - iLua
http://goo.gl/9bCWdR - lua-rlcompleter
Держи готовую консоль с ридлайном. Ее только обернуть в виджет надо.

>>10745
Не-не-не, я нативную сделаю.

Глядя на stand-alone интерпретатор луы, подумал, что там есть незамеченный мной красивый способ узнать, что чанк синтаксически верен, просто не завершён, посмотрел исходник — incomplete = error && !strcmp(errmsg + errmsglen - 5, "<eof>"). :\

>>10746
iLua - это рекомендуемая штука с луасайта. У меня там просто пара патчей на нее, которые какие-то дырки фиксили. А ридлайн-связка - разделяемая библиотека. Оно грузится из луы и не имеет контакта с твоим кодом.

>>10744
вообще дорожки бликов получаюстя на волнующейся воде, потому что у каждой волны на прямой солнце-зритель в силу её формы есть кусок, который наклонен так, что от наблюдателя в нем отражается именно солнце. Аналогично и с любым другим объектом. В программной имитации тебе сответственно нужна такая формула искажения "прямого" отражения, при которой точки позжим образом перераспределяются по всей вертикали с уплотнением и многократным повторением.

Извиняюсь за бесполезный комментарий :3

>>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. С этим надо что-то делать. Около часа выяснял, почему консоль пытается сериализоваться.

Придя в ужас от того, сколько всего мне предполагалось скопипастить, чтобы добавить воде блики, переделал работу с источниками света в шейдере. Теперь, несмотря на то, что типов источников несколько — (позиционные, направленные) × (с тенями, без), "цикл" по ним в шейдере — единственный. Профит в том, что общий код и пачки параметров дублировать не нужно. Так, массив цветов теперь относится ко всем источникам, массив радиусов — ко всем позиционным, etc., вместо отдельных массивов для каждого типа.

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

При выполнении ряда условий части такого "цикла" преобразуются в честный for по юниформу.

^_^
Самая корректная модель бликового освещения из известных мне на данный момент, учитывает кривизну поверхности, коэффициент Френеля и взаимозатенение "микрограней".

Надо будет все более-менее известные перепробовать, и не только на воде, интересно же.

>>10774
+сплаттинг, +плавная граница с берегом, +"пена".
Время допилить предметы, инвентари и контейнеры! :3

>>10783
Не успею к НГ >_>
Пока сделал раздельные инвентари (press X) и подсветку, завтра добавлю контейнеры.

Сделал автоподбор позиции в лейауте 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), и в самом подходящем по какой-нибудь эвристике как-нибудь разместить окно. Можно было проще? Как?

В итоге и к Рождеству не успею. :(

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

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

Ничего не сделал, зато сделал ПЕРЕНОСЫ.
Добавлять заодно с экипировкой и юзабельностью фехтование мороженкой или?.. --"

Разобрался с потоками сжатия и 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/). Потом.

Что хотел выделить:

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

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

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

Это я от UBO отлыниваю, ага.

Хде мои апдейты блжать?!

>>11251
Будут.

>>11252
Слава богу.

>>11255
Или не будут. Не знаю.

>>11261
А что такое? У тебя все хорошо, надеюсь?

Прикрутил локализацию. В обычные строки вставляются необычные фрагменты, сущности обязуются помнить об этом и получать настоящий текст как localizedText = locale.localize(text). (Сущность может установить обработчик смены локали, чтобы не дёргать это лишний раз, а также оптимизировать случай, когда никаких необычностей в строке всё-таки нет). На данный момент функциональность необычных фрагментов исчерпывается лукапом в свалку луа-скриптов вида

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

"8 " .. Localized "misc.month.jul" .. " 2014". Позже добавлю падежи, числительные и т. п., правда, для этого, видимо, необычному фрагменту придётся заниматься детективным расследованием окрестностей строки... а, ну или просто просить все нужные данные на месте Localized и запоминать где-нибудь внутри себя.

>>11544
Я делал так (быдлокод, яваскрипт): массив английских строк, массив русских строк, "текущий язык" = ссылка на один из этих массивов. Соответственно из текущего языка вставляется нужный элемент массива.

http://www.everfall.com/paste/id.php?06il598zoedx

>>11548
Разумеется, в реальности твоего способа достаточно. Я ориентировался на «автоматическое» разруливание локализации, т. е. внешне для текста или идентификаторов картинок задаются те же строки, что и раньше, просто слегка магические, возможность изменить язык на лету и подобные, может быть, крутые, но явно спорной полезности вещи.

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

Nu eto voobsche pushka!

>>11552
Посмотри, как делаются локализации общепринятыми методами (gettext с кучей оберток на него в разных языках и разных форматах, от гнушного и всяких явастрингов до простого key:value жсона).
Ты придумал очень неудобную и трудноподдерживаемую систему, у тебя какая-то логика в этой штуке, ее там быть точно не должно.

>>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), что ли.

>>11628
Мне последнее время приходится много работать с разными локализациями, и кустарным мне кажется именно твой вариант. А геттекст, он немного не так работает, а скорее
gettext("Я хочу здесь этот текст")
В .po что-то вроде
id "Я хочу здесь этот текст"
el "κακή μετάφραση"
Т.е. обычный кей-валью, просто с кучей всяких тулз для автогенерации всего этот локализациомусора, и тысяча оберток еще. И ты совсем даже не паришься о том, что у тебя где-то миллион строк в одном файле, потому что этот файл автогенерируемый, а так же отлично скармливается всяким автопереводчикам.
У тебя я вижу логику из-за вложенных контейнеров, это само по себе несет в себе какую-то логическую связь между внешним контейнером и внутренним. Обычно такие конструкции влекут за собой много изменений, когда ты меняешь какие-то коренные элементы логики.
Про функции в этой штуке забудь, не на пхп же пишешь, в самом деле.

А какую именно часть движка ты пишешь на паскале, а какую на Луа?
Чистый паскаль, дельфипаскаль (Д1-Д14) или чистый Дельфи (15+)?
Сильно ли любишь Элону?

Если что я тоже очень давно пишу на Паскале, начал на чистом, быстро перешёл на дельфипаскаль, после 4 года на чистом дельфи.

>>11669
> после
Последние

Бампну тогда СыОПа на ичаневе.

Я надеюсь, проект не заброшен?
Мечтаю, что когда-нибудь я скачаю готовую версию и ммм....
Меня охватит единый организм самописного движка.

>>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 раза.

Прикрутил https://code.google.com/p/crunch/.

Сравнительный тест производительности куч от 1337_POCAN.

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

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

RMH — http://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 с. лол

>>12081
Автор Braid об этом весело рассказывал. Про Doom особенно смешно.

https://www.youtube.com/watch?v=JjDsP5n2kSM#t=554

>>10050
Как хорошо быть программистом, эх

Перекатился на Lua 5.3. Настоящие целые на уровне VM — это хорошо.

Простите, а что это такое? Ни на сайте, ни в обоих тредах внятно и четко не сказано, что являет собой эта rr-rr.
Ну разве так можно?

>>12855
Во-первых, мне лень и писатель из меня так себе.
Во-вторых, это уберёт элемент загадочности, при условии, что он вообще существует.
В-третьих, до «3D-бродилка про Сырну» можно и догадаться (я делал концепт подетальнее, которого один хрен не придерживаюсь).
В-четвёртых, считаю невозможным мейнстримом навязываться аудитории «смарити какой у нас клёвый праэкт можно делать так и вот так» каким бы то ни было образом и не очень люблю, когда так делают (а коль скоро так почти все делают... ну ты понял).
В-пятых и подытоживая — да, можно, мне норм.

С мылом и подправленным глазом, хоть проблемы им далеко не исчерпываются.

Thy soul shall be my breakfast!

So sexy~

Падает при старте

>>13006
Спасибо, обновил драйвер, словил то же, исправил. Narkomani. Вот была функция glGenBuffers(..., &id), «старая» модель glBindBuffer(id) + работа с прибинденным буфером без указания id и «новая» glNamedBuffer...(id, ...), так нужно было её сломать до несовместимости, «кароч glGenBuffers на самом деле не создаёт буфер до первого Bind'а, бинди сразу или используй glCreateBuffers, введенную в OpenGL 4.5 не пойми зачем)))». Это могло было быть сделано, чтобы заставить меня как программиста указывать конкретную версию API, чтобы ломающие изменения в дальнейшем обходили меня стороной, но я это и так делаю, лол.

>>13014
Fixed pipeline api давно depricated, чего ты хотел?

>>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＊. Нонсенс.

Сделал интерполяцию строк в скриптах, т. е.
> format "цепочка длины {n} (R = {dist})"
вместо
> format("цепочка длины {0} (R = {1})", n, dist)
или
> "цепочка длины " .. n .. " (R = " .. dist .. ")".

>>13229
>интерполяцию
значение знаешь?

Алсо, это твой рисунок последний? Ты нехило так продвинулся, мож ну его этот кодинг, иди лучше хентай рисуй.

>>13243
https://en.wikipedia.org/wiki/String_interpolation же.

>>13251
А, спасибо, не знал что это так называется. Термин дурацкий все-таки, при чем тут интерполяция?