t1ok, не умеет программировать и хочет делать игры... Пусть учится =) Это как хотеть быть писателем, но не уметь сложить три слова в предложение, но есть же куча сторов с готовыми главами!
alexprey, главное, чтоб был счастлив мэйн тред. =) Треды с отложенным исполнением в любом случае будут ждать. К тому же ждут они только в случае именно этого самого отложенного исполнения.
alexprey, в данной задаче это и нужно. Очистка листа проводится между кадрами, то есть нужно быть уверенным в том, что за это время лист не разрастется. Я его для этого и блокирую, треды ждут очистки, все счастливы. =)
alexprey, ты не понял видимо для чего я блокирую все чтение листа, это раз, ты не понял что я имел ввиду под скоростью (не путать со сложностью алгоритма, что ты и привел), это два.
UPD: По результатам теста, заполнение LinkedList в два раза медленнее, чем обычного листа.
alexprey, рекомендую почитать о потокобезопасности в c#. Лок с листами - дело нужное, иногда даже очень. Обычно только удаление и добавление локируют, но в моем случае, мне нужно чтоб очередь была гарантировано уменьшаема за кадр, мало ли кто и с какой очередностью там будет писать в очередь? По хорошему, объект sync еще и приватным надо сделать, чтоб никто иной до него не достукивался. Насчет вариаций листа: первое, это дело вкуса, второе, это производительность. Лучше всего юзать вообще массивы и выигрывать миллисекунды (именно из них складывается FPS), чем обеспечивать себе удобный кодинг. Так как тут мы имеем дело с постоянно динамическими вещами, то лист, причем дженерик, дабы не тратить время на кастование. Doc, нет, треды в юнити вообще не юзались до пятой версии. Все однопоточно. Идеалогия движка такая. Сейчас они узкие места распаралелили, получили прирост, но для нас это все равно однопоточный пайплайн. У них есть варианты как исполнять тяжелый код - коротины. Некое распределенное между кадрами исполнение, посредством yeld return и управляющих инструкций к нему, все при этом остается в главном потоке. Это совсем не то же самое, что треды, думаю пояснять не надо. Насчет вызова и изменений... там все странно. Стандартные методы залочены почти все. НО! Никто не мешает делать свои поля и свои методы компонентам. Их можно юзать, если они не юзают внутренние. Пример: вам нужно, чтоб объект менял свои координаты. По сути вам не важно, что это произойдет реально только перед отрисовкой кадра, или перед обсчетом физики, правда? Вы делаете некое расширение стандартного класа, в котором делаете свои координаты. Их вы менять можете из тредов хоть заменятся, а уже в апдейте каком-либо эти координаты сравнивать с трансформом и накатывать их в случае необходимости. Используя этот подход и идеи изложенные выше, параллельность исполнения кода можно сделать достаточно гибкой и устойчивой к падениям. В любом случае - это вопрос целеполагания.
alexprey, синхронность. Ты в один поток слипишь. В мэйн потоке его будишь. Интеррапт не прерывает поток, если он не ожидает чего-то (WaitSleepJoin состояние), если же чего-то ждет, то будет эксепшн, насколько я понимаю, и поток пойдет дальше, если эксепшн обработать. Так по сути ты обеспечиваешь не просто вызов функции в другом потоке, но и гарантируешь, что поток твой не пойдет дальше, пока функция не будет выполнена.
upd: такая концепция самая верная в том плане, что система не обрабатывает потоки, которые чего-то ждут. По сути у меня в итоговой реализации в очередь складывается не экшн, а кастомный класс, в котором хранится само действие, колбэк, поток, который вызвал все это великолепие, и функционал для вызова действия и колбэка. Так вот все слипы и интерапты у меня спрятаны и не торчат из щелей. Тут же я просто рассказывал саму концецию =)
alexprey, идея была взята со стандартного C#. Там есть такая штука, как Dispatcher. У каждого треда свой, и мы собственно нужному диспатчеру выдаем задание и ждем пока он его выполнит. Внутри все сделано было через очередь эвентов, насколько я понял. Да и подобные реализации на сторе уже есть, просто денег стоит, а формально там работы на три скрипта.
alexprey, до сетей я не добрался, но думаю там все можно делать по тому же принципу. Главное отдать что-то исполнять мэйн треду в нужном месте и дождаться исполнения (получить результат) или шпарить дальше, если результат не важен, а важен сам факт, что когда-то это исполнится.
Нот бэд! На этом реально будет замутить систему диалогов как в морровинде, насколько я понимаю? Вот там была реально шикарная система развития диалогов.
Mihahail, я извиняюсь за свою привычку работать с пнг файлами. В интернет что-то не выкладывал уже давно, а для моих нужд формат более чем удобный, вот и привык =). Теперь там jpg, но под каты прятать не стал.
prog, генератор выдаст одно и то же. Посмотри внимательно на функцию. Увидишь там хоть что-то вариативное от запуска к запуску... ну будешь большим молодцом. Что касается возможности принудительно сменить вариацию тайла... ну да, есть такое. Но как бы цель была сделать стандартный террайн чуть более красивым... если речь идет о такого рода модификациях, то скорее всего придется писать свой террайн энжин. Тут же есть ряд ограничений, хотя бы связанных с тем, что для каждого прохода шейдера все текстуры устанавливаются программно + шейдер как таковой не умеет сохранять данные на диск и брать их оттуда =)
» Construct 2 / Главная страница
» Unity / Многопоточность
» Unity / Многопоточность
Отредактирован MF
» Unity / Многопоточность
UPD: По результатам теста, заполнение LinkedList в два раза медленнее, чем обычного листа.
» Unity / Используем DLL в Unity
Сканает ли для билда в линуксе (родные юнити длл так и остаются длл)?
Есть способ для моно?
Отредактирован MF
» Unity / Многопоточность
Doc, нет, треды в юнити вообще не юзались до пятой версии. Все однопоточно. Идеалогия движка такая. Сейчас они узкие места распаралелили, получили прирост, но для нас это все равно однопоточный пайплайн. У них есть варианты как исполнять тяжелый код - коротины. Некое распределенное между кадрами исполнение, посредством yeld return и управляющих инструкций к нему, все при этом остается в главном потоке. Это совсем не то же самое, что треды, думаю пояснять не надо. Насчет вызова и изменений... там все странно. Стандартные методы залочены почти все. НО! Никто не мешает делать свои поля и свои методы компонентам. Их можно юзать, если они не юзают внутренние. Пример: вам нужно, чтоб объект менял свои координаты. По сути вам не важно, что это произойдет реально только перед отрисовкой кадра, или перед обсчетом физики, правда? Вы делаете некое расширение стандартного класа, в котором делаете свои координаты. Их вы менять можете из тредов хоть заменятся, а уже в апдейте каком-либо эти координаты сравнивать с трансформом и накатывать их в случае необходимости. Используя этот подход и идеи изложенные выше, параллельность исполнения кода можно сделать достаточно гибкой и устойчивой к падениям. В любом случае - это вопрос целеполагания.
» Unity / Многопоточность
» Unity / WIP - Warcraft 3 To Unity Converter
Отредактирован MF
» Unity / Многопоточность
upd: такая концепция самая верная в том плане, что система не обрабатывает потоки, которые чего-то ждут. По сути у меня в итоговой реализации в очередь складывается не экшн, а кастомный класс, в котором хранится само действие, колбэк, поток, который вызвал все это великолепие, и функционал для вызова действия и колбэка. Так вот все слипы и интерапты у меня спрятаны и не торчат из щелей. Тут же я просто рассказывал саму концецию =)
» Unity / Многопоточность
» Unity / Многопоточность
» Unity / WIP - Warcraft 3 To Unity Converter
» Unity / WIP - Warcraft 3 To Unity Converter
Рад был помочь, самому было интересно.
» Color Escape 2 / Главная страница
» Unity / Гипертекст
Отредактирован MF
» Unity / Гипертекст
» Unity / Unity
» Unity / Как мы шейдер писали
» Unity / Как мы шейдер писали
» Unity / Как мы шейдер писали
» Tiodor's Art / Текстура всякие
» Tiodor's Art / XGM-логово
» Wulfrein's Intellectual Posts © / Протоссианский глайдер
» MF и его невидимые друзья / Несколько любопытных законов жизни.