CRUSIS 9000
Модератор: Модераторы
Re: CRUSIS 9000
Прикольно. Пили! Нравица!!!!! 
Re: CRUSIS 9000
Скомпилировал под FPC 3.0
О, о, о страшно то как
Окей, мой мир разрушен.
Я ищо когда ковырял paszlib, делая поддерживающую потоки версию, обратил внимание как ураганно быстро она распаковывает.
Код: Выделить всё
(поток №1) got a task: TFileLoadTask
actualizing #4/13, TTextureFromImage
..asset refused, rescheduling.
(поток №1) TFileLoadTask.Perform (*M/env/mc-oa-dm02/mc-oa-dm02_ft.png)...
actualizing #5/13, TTextureFromImage
(поток №1) TZipFile.ReadFile(*M/env/mc-oa-dm02/mc-oa-dm02_ft.png)...
..asset refused, rescheduling.
TLogic.ActualizeAssets end.
[кадр №65, 12:51:44.786, Пт, 01.07.2016]
(поток №1) ..unpacked 269114 bytes in 5330 μs
(поток №1) TFileLoadTask.Perform end(269114 bytes from *M/env/mc-oa-dm02/mc-oa-dm02_ft.png)...
(поток №1) completed TFileLoadTask
Но, как никто не использует сжатие NTFS,
Я использую!
Re: CRUSIS 9000
Когда прочитал про ReadDirectoryChanges.


Последний раз редактировалось runewalsh 01.04.2018 18:21:15, всего редактировалось 1 раз.
Re: CRUSIS 9000
https://github.com/runewalsh/rox-loh/re ... .0/rox.rar
Сделал двухминутное кинцо.

В целом, конечно, зря потратил время, но, по крайней мере, понял, как НУЖНО БЫЛО работать с окном в основном движке. Когда я там писал работу с окном (основной цикл, официальный финт с двойным контекстом OGL, ввод, вот это всё), я считал, что кукарекнуть в лог, а дальше будь что будет — допустимая обработка ошибки, а здесь вроде по уму получилось. Попробую как-нибудь потом дописать всякие фуллскрины и перенести реализацию. Это позволит, например, выбросить часть самопального GUI в OpenGL-вьюпорте, отвечающую за самопальную же мышку, воспользовавшись тем, что система уже сообщает. Один из сопутствующих бонусов — синхронность мышки в системе и в «своём» UI.
Бонусом же всего подхода с нормальной обработкой оконных ошибок является то, что всю эту OpenGL-кухню становится возможным встроить в другое приложение (как просмотрщик и т. п.), а не только саму делать приложением, но до этого, боюсь, не дойдёт.
Сделал двухминутное кинцо.

В целом, конечно, зря потратил время, но, по крайней мере, понял, как НУЖНО БЫЛО работать с окном в основном движке. Когда я там писал работу с окном (основной цикл, официальный финт с двойным контекстом OGL, ввод, вот это всё), я считал, что кукарекнуть в лог, а дальше будь что будет — допустимая обработка ошибки, а здесь вроде по уму получилось. Попробую как-нибудь потом дописать всякие фуллскрины и перенести реализацию. Это позволит, например, выбросить часть самопального GUI в OpenGL-вьюпорте, отвечающую за самопальную же мышку, воспользовавшись тем, что система уже сообщает. Один из сопутствующих бонусов — синхронность мышки в системе и в «своём» UI.
Бонусом же всего подхода с нормальной обработкой оконных ошибок является то, что всю эту OpenGL-кухню становится возможным встроить в другое приложение (как просмотрщик и т. п.), а не только саму делать приложением, но до этого, боюсь, не дойдёт.
Re: CRUSIS 9000
аааааа! как V-sync отключить или в полноэкранный режим войти?
(у мну железка/дровишки глючные, в оконном режиме с включённым V-sync, почему-то жуткие тормоза!)
Погуглил - проблема с Nvidia панелью управления. Просто отключил принудительный Vsync.
Добавлено спустя 20 минут 3 секунды:
окончание классное xD стильно чо!
(у мну железка/дровишки глючные, в оконном режиме с включённым V-sync, почему-то жуткие тормоза!)
Погуглил - проблема с Nvidia панелью управления. Просто отключил принудительный Vsync.
Добавлено спустя 20 минут 3 секунды:
окончание классное xD стильно чо!
Re: CRUSIS 9000
Когда прочитал про ReadDirectoryChanges.
Круто! Надо себе такую фичу сделать.

Re: CRUSIS 9000
Попробовал переписать пространственные деревья: моя реализация от 2k11 слегка глючила и требовала вызывать перестроение явно, а теперь решил для каждого узла вести учёт ИСКАЖЕНИЙ (красные прогрессбары толщиной в пиксель), и по превышении порога искажённости перестраивать узел без участия пользователя. По части глюков получилось ещё хуже прежних, вплоть до неработоспособности. На гифке-то всё в порядке, но вот на реальной сцене... Нужно ковырять. Например, записать последовательности операций с деревом, приводящие к «невозможным» результатам, и плясать от них. Эх, вот я криворучка.


Последний раз редактировалось runewalsh 01.04.2018 18:21:43, всего редактировалось 1 раз.
Re: CRUSIS 9000
Уй ё, брутально то как 
Но вот без такой "подводной части айсберга" как раз получаются говнодвижки, вроде TES где ИИ тупит как пробка пока не запустишь на супер-пупер мощном процессоре.
Спасибо за идею, увидев это у меня расклинило мыслительный затык. До меня дошло, что объекты совершенно не обязательно хранить в той же структуре, что и мини-октри блоков чанка (в терминах майнкрафта). Можно же что-то совершенно не зависящее, типа BVH на сферах.
Но вот без такой "подводной части айсберга" как раз получаются говнодвижки, вроде TES где ИИ тупит как пробка пока не запустишь на супер-пупер мощном процессоре.
Спасибо за идею, увидев это у меня расклинило мыслительный затык. До меня дошло, что объекты совершенно не обязательно хранить в той же структуре, что и мини-октри блоков чанка (в терминах майнкрафта). Можно же что-то совершенно не зависящее, типа BVH на сферах.
Re: CRUSIS 9000
В «говнодвижках» это реализовано.
Только между нами, но на разумных количествах объектов без дерева быстрее, а неразумным дерево не поможет.
Например, у меня строится граф из 10000 путевых точек (само по себе глупость, ну да ладно) группами по 100, и каждая группа, присоединяясь, ищет ближайшие к каждой из своих, чтобы ими «склеиться».
Получается 16 мс с новым деревом (ну это ладно, предположим, я слишком агрессивную логику автоперестроения задал), 9 мс со старым... и 3 мс простым перебором вообще всех.
Я уже сталкивался с этим, когда решил проверить, на сколько же A* «быстрее» поиска в ширину — получился тот же самый, обратный ожидаемому результат. Нет, возможно, возмооожно, на миллионах точек, построенных специальным образом, поиск в ширину будет работать две секунды, а а-стар — всего лишь полторы...
Только между нами, но на разумных количествах объектов без дерева быстрее, а неразумным дерево не поможет.
Например, у меня строится граф из 10000 путевых точек (само по себе глупость, ну да ладно) группами по 100, и каждая группа, присоединяясь, ищет ближайшие к каждой из своих, чтобы ими «склеиться».
Получается 16 мс с новым деревом (ну это ладно, предположим, я слишком агрессивную логику автоперестроения задал), 9 мс со старым... и 3 мс простым перебором вообще всех.
Я уже сталкивался с этим, когда решил проверить, на сколько же A* «быстрее» поиска в ширину — получился тот же самый, обратный ожидаемому результат. Нет, возможно, возмооожно, на миллионах точек, построенных специальным образом, поиск в ширину будет работать две секунды, а а-стар — всего лишь полторы...
Re: CRUSIS 9000
Только между нами, но на разумных количествах объектов
Ёлки

Так ведь можно в преждевременную оптимизацию вляпаться.
Хмм... Прикинем: мир 80 мегабайт, память 8 Гб/с, за секунду можно перебаламутить 100 раз с полным загрязнением кеша, то есть модифицировать *все* объекты - и то всё упрётся в расчётные алгоритмы, которые по времени не уложатся.
Так, решено: *прежде* чем разводить супер-пупер менеджеры памяти - взять и померить. И на i5 с ddr3 и на ARM с DDR2.
И измерить, сколько будет это "разумное количество". Может, 50..100.
Во, ещё идея возникла: гибрид ужа и ежа, octree и bvh. У каждого листа центр фиксированный а ещё радиус в который полностью влезают все объекты. Радиус ствршего листа такой, что влезают все дочерние листы.
-
Mirage
- энтузиаст
- Сообщения: 881
- Зарегистрирован: 06.05.2005 20:29:07
- Откуда: Russia
- Контактная информация:
Re: CRUSIS 9000
Да обычный grid решает проблему, что вы мучаетесь. Деревья если и нужны, то в очень специфических случаях.
Re: CRUSIS 9000
Стиль написания кода очень оригинальный)) использую для тестов fpc-passrc - на багтрекере матерятся, но правят))
Re: CRUSIS 9000
Оффтоп, т. к. в движок пока встраивать не буду, просто всегда хотел это проверить.
TL;DR: можно попытаться восстановиться после переполнения стека, вызвав _resetstkoflw из Visual C++ Runtime.
TL;DR: можно попытаться восстановиться после переполнения стека, вызвав _resetstkoflw из Visual C++ Runtime.
Re: CRUSIS 9000
Я не окончательно сдох, так вышло, всё будет, спокойно, ещё немного.
Сделал себе лог в несколько колонок для разных потоков. На такой лог удобно медитировать со стаканом чая, анализируя post mortem ход работы вашего многопоточного приложения. (⋈◍>◡<◍)。✧♡
Сделал себе лог в несколько колонок для разных потоков. На такой лог удобно медитировать со стаканом чая, анализируя post mortem ход работы вашего многопоточного приложения. (⋈◍>◡<◍)。✧♡
Re: CRUSIS 9000
Ух ты "а все таки она вертится !"
Поддерживаю ! (А то живых проектов на форуме как-то маловато,что пытаются делать Cheb да Зуб... ну и я что-то пишу под девизом "попытка не пытка" ...
)
Теперь по сути :
1 Что насчет "третьего измерения" или все "сугубо в 2д"?
2 Даже проект "2Д онли" можно успешно вытащить в ВиАр . (На Стиме полно визуальных навел под ВиАр )
Отсюда мысля ... А почему бы не сделать "ВиАр сцену" и в этом проекте ?
Теперь по сути :
1 Что насчет "третьего измерения" или все "сугубо в 2д"?
2 Даже проект "2Д онли" можно успешно вытащить в ВиАр . (На Стиме полно визуальных навел под ВиАр )
Отсюда мысля ... А почему бы не сделать "ВиАр сцену" и в этом проекте ?
