ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Unity -- учим вместе | страница 11 |
|
|
|
|
Канал Игры Мечты: «Unity -- учим вместе» |
|
|
|
Guest
 2075 EGP
           
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
   |
|
Да Шилдта оптимально, даже может быть чересчур немного по объёму.
А в применении к Юнити - отдельные фичи C# могут не играть на мобильных устройствах, в остальном можно извращаться почти как угодно... Только файлы именовать в соответствии с классами.
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Shirson
1605 EGP
   
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
|
|
| Guest : |
|
Только файлы именовать в соответствии с классами.
|
Отсюда по-подробнее, я записываю 
(У Шилдта как раз прочитал, что файлы принято обзывають по имени главного класса. Непривычно)
_________________
У меня бисера не доxеpа.
Последний раз редактировалось: Shirson (06:59 25-09-2013), всего редактировалось 1 раз |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Shirson : |
|
(У Шилдта как раз прочитал, что файлы принято обзывають по имени главного класса. Непривычно)
|
Честно не стал лезть в дебри причин такого поведения, возможно руки растут из жопы платформы mono, а возможно из философии инкапсуляции в префабы, но если у тебя имя файла и имя главного класса в нём не совпадают - в Unity он откажется компилироваться.
На других языках может быть по-другому, но я только C# знаю
Сохранение значений в префаб производится только для сериализуемых полей (пофигу, паблик или прайват, главное - чтобы [SerializeField] перед полем). Это же может относиться и к набросанным в сцену ссылкам на префабы.
Префабы сами не сохраняются. Если надо залить куда-то в SVN - обязательно перед процiдуркой нужно сохранить сцену. Даже если в сцене этих префабов нет и не было никогда...
Очистка памяти. Это вообще адЪ. Впрочем, если не надо позарез поместиться в память мобильника - можно на это забить...
Там с версии 4.х какой-то свой, кастомный Garbage Collector с блекджеком и шлюхами, не C#. Он типа более быстрый. Но при этом чистит как-то уж очень выборочно и обожает оставлять вместо null всякие "призраки оперы". Поэтому после использования и перед ликвидацией ресурс лучше заменить на null, чем понадеяться на то, что его корректно убьёт.
Принудительно выгрузить неиспользуемый ассет из памяти в теории можно (UnloadUnusedAssets), а на практике - зависит от положения Сатурна в созвездии Весов. Чаще всего нихрена не очищается 
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (00:00 26-09-2013), всего редактировалось 1 раз |
|
|
|
Olorin
70 EGP
Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
|
|
| Sh.Tac. : |
|
в общем C# кажется несложным, достаточно MSDN, особенно если есть опыт в другом ЯП, но там столько нюансов умудрились зарыть, что возможно книжкой не отделаешься
|
Синтаксис изучается за неделю, это да. А вот как оно работает.. это уже CLR - среда исполнения. Тонкости в основном продиктованы вполне четкими мотивами дизайна.
| Sh.Tac. : |
|
а когда ярые исследователи начинают смотреть перформанс, вылезают всякие вещи, вроде того, что в словаре не стоит делать ключ перечислением, потому что при этом происходит бестолковый "коробкинг-анкоробкинг" (boxing-unboxing)
|
Я даже специально полез рефлектором проверять, не пугайте так)
Это только в первом фреймворке такая бяка была (ну и в старых коллекциях тех времён найти можно), а начиная с 2.0 есть generic'и, нивелирующие основные причины, приводящие к боксингу.
Где-то даже была статейка про сравнение эффективности от человеков, транслировавших джавовский код андройда в C# и запустивших его под моно. Так вот, там едва ли не основной выигрыш был именно из-за того, что джавовский код generic'и через object реализует (что и влечет боксинг-анбоксинг), а дотнетный код - юзает обобщения на уровне среды исполнения.
| Sh.Tac. : |
на практике отличительными от других ЯП являются:
- class (aka reference type) vs struct (aka value type)
- сборки против dll, хотя это не про unity
- атрибуты и свойства (properties)
- делегаты и async "искаропки", последний развивался эволюционно
- анонимные делегаты (замыкания), но это и в яве есть и пхп даже
|
Широко распространённая мешанина понятий CLI и самого C#. Лучшеб таки котлеты таки отдельно, а мухи - отдельно.
И да, сборки в 95+% случаев для невооруженного взгляда выглядят именно как традиционные PE-образы (т.е. либо exe либо dll).
И, ****ть-колотить, они называются анонимные методы. Делегат - это вид типов в рамках CLI, а то о чем речь - методы. Анонимные типы тоже есть, но это совсем другая песня, и делегаты с ними связаны весьма косвенно.
| Shirson : |
| Guest : |
|
Только файлы именовать в соответствии с классами.
|
Отсюда по-подробнее, я записываю
(У Шилдта как раз прочитал, что файлы принято обзывають по имени главного класса. Непривычно)
|
Это широко распространённая практика - разносить модули программной архитектуры по отдельным файлам. Апогей сего действа - джава, где это требование буквально: один тип - один класс-файл. Когда-то к файлам с джавовскими исходняками это тоже относилось, но потом в джаве появились анонимные классы, и с этого момента из одного '.java' может получаеться несколько '.class', каждый из которых содержит метаинформацию об одном типе с соответствующим именем.
В таком строгом порядке обычно это правило мало кто соблюдает, но разносить функциональные единицы по одноимённым файлам всё же стараются - навигацию упрощает.
Ну и в IDE поддержка рефакторингов типа автоматического переименования обычно тоже есть для сабжа. И есть такой момент, в VS во всяком случае, что для элементов проекта, связанных с кодогенерацией (типа визуального редактора WinForms например), первый сверху описанный в файле тип должен быть именно тем же, который подчинён этому плагину-редактору. Иначе его жосска плющит. Я Unity не знаю, не юзал, но возможно следствие аналогичных причин.
| Guest : |
Там с версии 4.х какой-то свой, кастомный Garbage Collector с блекджеком и шлюхами, не C#. Он типа более быстрый. Но при этом чистит как-то уж очень выборочно и обожает оставлять вместо null всякие "призраки оперы". Поэтому после использования и перед ликвидацией ресурс лучше заменить на null, чем понадеяться на то, что его корректно убьёт.
Принудительно выгрузить неиспользуемый ассет из памяти в теории можно (UnloadUnusedAssets), а на практике - зависит от положения Сатурна в созвездии Весов. Чаще всего нихрена не очищается
|
Таки. Управление памятью и управление ресурсами - хотя исторически и пользуются похожими паттернами, и часто увязываются вместе - всё же суть разные вещи.
Что касается управления памятью, C# тут вообще не при чем - это исключительно дело CLR (среды исполнения). А для некоторых кейсов управления ресурсами в C# есть встроенный паттерн using на основе интерфейса IDisposable - и всё. Остальное уже ручками, с учетом архитектурных нюансов приложения.
Практика же "зануления" ссылок связана с тем, что иногда, когда какой-то ссылочный объект нам уже не нужен, ссылку на него может держать другой объект, который нам еще нужен. GC, анализируя граф объектов, добирается до всего, на что ссылки есть, и нам вроде бы не нужный объект сборку переживёт. Потому, если мы знаем, что нам в каком-то месте объект уже не нужен, а ссылка на него может храниться значительное время (в поле другого долгоживущего объекта например) - принято её сбрасывать, явным образом присваивая null.
Что касается изменений в 4 фреймворке: там проимпрувили поддержку многопоточности в GC. Во всяких статьях/на конференциях даже графики показывали, что мол теперь почти весь процесс сборки мусора может работать в фоновой нитке параллельно нитками приложения. Не вдаваясь в детали, раньше оно было несколько "менее параллельно".
Управление ресурсами Юнити - целиком и полностью на совести Юнити.
PS Крайне рекомендую раздел со статьями по C# на rsdn.ru.
Посмотрев фичелист по версиям в вики, упорядочить по возрастанию (ибо многие штуки построены на базе предыдущих) и изучать последовательно.
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший
Последний раз редактировалось: Olorin (05:38 26-09-2013), всего редактировалось 2 раз(а) |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Olorin : |
|
Что касается изменений в 4 фреймворке
|
note: речь шла про Unity 4.x, а не .NET Framework. Но в целом - да.
Спасибо за разъяснения.
А, да, ещё одно: документацию по Unity и по скриптам Unity смотреть только на сайте, локальной не пользоваться! Разница между ними очень велика, т.к. большое количество изменений производится постоянно.
Также, до некоторых интересных статей невозможно добраться по оглавлению, только через поиск... В общем, там интересных хинтов много в документации. По любым вопросам - имеет смысл пинать поиск в доках. Даже если думаешь, что знаешь...
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Olorin : |
|
Я даже специально полез рефлектором проверять
|
ну да, материал не первой свежести, просто всплыл недавно на канале юнити, а mono вполне может продолжать так делать
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Olorin
70 EGP
Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
|
|
| Sh.Tac. : |
| Olorin : |
|
Я даже специально полез рефлектором проверять
|
ну да, материал не первой свежести, просто всплыл недавно на канале юнити, а mono вполне может продолжать так делать
|
Более пристальный взгляд показал, что ветка
| Код: |
if (c.IsEnum && (Enum.GetUnderlyingType(c) == typeof(int)))
{
return (EqualityComparer<T>) RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter((RuntimeType) typeof(EnumEqualityComparer<int>), c);
}
|
появилась в дотнетной mscorlib'е версии 4.0
В текущей моно 3.2.3 код несколько иной, но по смыслу аналогичный 2.0-ному фреймворку.
|
Немного кóры (кликните здесь для просмотра)
Еще есть такая бага с забавным обсуждением.
Строго говоря, всякий енам наследует от типа Enum, при этом:
public abstract class Enum : ValueType, IComparable, IFormattable, IConvertible { ... }
и
public abstract class ValueType { ... }
, но, к примеру:
public struct Int32 : IComparable, IFormattable, IConvertible, IComparable<int>, IEquatable<int>.
Хотя и ValueType и Enum имеют кастомные реализации public override bool Equals(object obj), они никак не пересекаются ни с IComparable<T> ни с IEquatable<T>, в отличии от примитивов и String, в которых реализации этих интерфейсов есть.
csc или пост-процессинг сборки мог бы дописывать их реализации в конкретные типы енамов, но...
| ECMA-335 §II.14.3 : |
Enums obey additional restrictions beyond those on other value types. Enums shall contain only fields
as members (they shall not even define type initializers or instance constructors); they shall not
implement any interfaces; they shall have auto field layout (§II.10.1.2); they shall have exactly one
instance field and it shall be of the underlying type of the enum; all other fields shall be static and
literal (§II.16.1); and they shall not be initialized with the initobj instruction.
|
|
Так или иначе, если активно использовать словари с енамами в качестве ключей, вместо предлагаемого ручного подсовывания кастомного компарера, яб рекомендовал сделать несколько иной финт ушами.
Причем именно в том случае, если на реальном сценарии работы приложения профайлинг покажет, что на дефолтном компарере словаря прогиб.
Сделать враппер словаря с таким же публичным интерфейсом и логику подстановки компарера поместить туда. Юзать этот враппер.
А если побыть фанатиком производительности, то, в зависимости от сценария использования, если наш енам, по которому словарь, не флаговый, и набор значений небольшой (а он скорее всего небольшой):
- явно зафиксировать значения констант енама
- завернув эту логику в кастомную коллекцию, юзать значение енама в качестве индекса масива.
- тщательно всё это прокомментировать, чтоб не забыть, почему оно так.
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Olorin : |
|
Широко распространённая мешанина понятий CLI и самого C#
|
дополню эту мешанину, дженерики и рефлекшн
в дженериках компилятору нередко приходится подсказывать с чем он имеет дело при помощи clause 'where T : blah-blah-blah'
оно и в плюсах конечно всякие typename в шаблонах надо расставлять, так что это скорее придирки
по поводу мешанины C# является флагманом .NET, изучать другие дотнетнутые увольте, а C# сам по себе не живёт, поэтому трудно отделять мух от котлет
хотя в майкрософт придумали много аббревиатур, да
добавлено спустя 10 минут:
З.Ы. а вообще мож я зря наезжаю, в той же юньке поддерживается куча странных языков, там даже javascript не такой как везде, ибо CLI (терь правильно?) 
_________________
This is what you get ...
(c) Radiohead
Последний раз редактировалось: Sh.Tac. (05:05 27-09-2013), всего редактировалось 1 раз |
|
|
|
Olorin
70 EGP
Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
|
|
| Sh.Tac. : |
| Olorin : |
|
Широко распространённая мешанина понятий CLI и самого C#
|
дополню эту мешанину, дженерики и рефлекшн
в дженериках компилятору нередко приходится подсказывать с чем он имеет дело при помощи clause 'where T : blah-blah-blah'
оно и в плюсах конечно всякие typename в шаблонах надо расставлять, так что это скорее придирки
|
Перечисленные штуки частично относятся к природе среды исполнения, частично - синтаксический сахар языка вокруг более простых приемов:
Буду префекционистом до конца))
| .. | Среда исполнения | Язык | class (aka reference type) vs struct (aka value type)
4+1 вида типов | заложено изначально для глубокого явного разделения семантики | следствие | | сборки против dll | У сборок и dll различное, хотя и пересекающееся, назначение.
Потому dll всегда файл, сборка - нет.Но когда файл - то тоже PE (exe/dll) | следствие
Язык как таковой никакого отношения к форме выхлопа компилятора не имеет по определению. | | атрибуты и свойства (properties) | И то и другое суть особые конструкции на уровне метаданных. | Свойства не более чем синтаксический сахар вокруг методов.
(приводящий к помечанию специальным образом аксессоров в метаданных) | | делегаты | тот самый +1 вид типов, разновидность классов особого назначения | следствие | | анонимные методы и замыкания | никак не касается
у всех типов и методов есть имена, всякая переменная имеет фиксированное место хранения значения | синтаксический сахар вокруг методов и классов only | | async | то же | async - синтаксический сахар only, вдобавок завязанный компиляторгом C# на спец. расширение стандартных библиотек | | дженерики | поддержка с версии 2.0 на уровне метаданных | следствие | | рефлексия | считается частью профиля библиотек, но для рантайма таки поддержка здесь | некоторый спецсинтаксис её использует в силу динамизма, но не более |
Собсно, потому я сцылк на rsdn и добавил)
| Sh.Tac. : |
по поводу мешанины C# является флагманом .NET, изучать другие дотнетнутые увольте, а C# сам по себе не живёт, поэтому трудно отделять мух от котлет
хотя в майкрософт придумали много аббревиатур, да
добавлено спустя 10 минут:
З.Ы. а вообще мож я зря наезжаю, в той же юньке поддерживается куча странных языков, там даже javascript не такой как везде, ибо CLI (терь правильно?)
|
Как язык наиболее близкий к инфраструктуре - да (потому многое, что можно представить метаданными, на нём записываемо, но всё). Поведение кода складывается из двух факторов: во что этот код превращается при компиляции (csc), и как то что получилось исполняется (clr).
Для управляемого кода и то и другое вытекает из реализаций соответствующих стандартов - Mono, .Net Framework, etc.
.cs скомпиленный csc и запущенный на mono может работать не так как .cs скомпиленный gmcs и запущенный на фреймворке. Другие два случая так же возможны.
Этот же кейс со словарями: код скомпиленный не важно gmcs и csc на 4.0 фреймворке будет работать одним способом, на моно - другим. Сам C# тут не при чем.
Если полку не прибить, надо все же понимать, гвоздь мы кривой взяли, или внутри доски в сучóк попали))
Standard ECMA-335 Common Language Infrastructure (CLI) - определяет как и почему работает среда исполнения.
Екму по шарпу что-то давно не обновляли, но всегда есть %VSINSTALLDIR%\VC#\Specifications\1033\CSharp Language Specification.docx - как устроен язык.
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
|
Ayawaska
101 EGP
Репутация: 8
Сообщения: 306
Откуда: Ржев
Зарегистрирован: 04.05.2013
|
|
Извиняюсь может я не по теме, но вроде тут знающие люди.
Есть тут тот, кто знает как на Unity реализовать цепляние к объектам чем то вроде тарзанки, и передвижение таким способом по инерции в пространстве?
Последний раз редактировалось: Ayawaska (16:00 02-10-2013), всего редактировалось 1 раз |
|
|
|
Shirson
1605 EGP
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
|
|
Вышел Unity 4.3
http://unity3d.com/unity/whats-new/unity-4.3
_________________
У меня бисера не доxеpа. |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
Вот уже четыре апдейта подряд Unity упорно двигается в сторону 2D Mobile Graphics, причём каждый раз ломая больше, чем починяя  Их 2d toolset по-прежнему проигрывает 2DTK, по сути являясь продолжением NGUI (наняли они его автора).
Убрали поддержку pre-DX9, т.е. больше ничего работать на старых видяхах не будет. Возможно оно и к лучшему... Но для простых проектов это плохо.
А я пытаюсь придумать простую вещь: как загонять в савку (и в частном случае - как передавать по сети) такую штуку, как провод. В трёхмерной сцене.
Провод пока что представляет собой physical-driven змейку из костей (IK раскатывает воздействие на предыдущие элементы цепи, цепляться мы можем только за первую и последнюю кость. Было бы неплохо придумать что-то без IK, т.к. он требует Unity Pro, а аренду лицензии я откладываю до последнего, ибо денег нет). Фокус в том, что на проводах этих держится бОльшая часть геймплея, и они ОБЯЗАНЫ сохраняться так, как легли, и ложиться у всех клиентов примерно одинаково.
Тут сразу же хочется обрабатывать физику на сервере, но сила действия приходит с клиента, и может из-за лага нефигово накопиться... Даже если тупо последняя кость пытается на "резинке" добраться до руки персонажа, её "держащей" (что будет в мультике выглядеть просто феерически, как резинка от трусов).
Ну и сохранять хочется тоже брутальным образом сейвя координаты каждой кости (json нашевсё) - но файл сейва пухнет совершенно ниипически...
Есть какие-нибудь мысли по поводу или окололо?
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (02:52 15-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
а много костей? не пойму почему
| Guest : |
|
файл сейва пухнет совершенно ниипически
|
_________________
MOV topka, C++ |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
Много. От 100 на каждый провод. Иначе он начинает вести себя как цепь со звеньями. Точность координат - float.
Пухлость сейва из-за структуры сохранения - там XML, надо какую-то попроще сериализацию, но с возможностью достраивать структуру сейва новыми полями, чтобы сейвы между апдейтами игры не херились.
Но сейв ещё не так страшно, а вот какой траффик будет по сети генериться? По сути же надо чуть ли не целиком сцену передавать, это не шутер с сотней векторов...
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (03:06 17-11-2013), всего редактировалось 1 раз |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
Много змеек может быть?
Сохранять надо в что-то бинарное и потом жать. Может кол-во костей можно уменьшить?
_________________
MOV topka, C++ |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Jurec : |
|
Много змеек может быть?
|
Сотни. Это сети из кабелей и шлангов, их может быть очень много.
| Jurec : |
|
Сохранять надо в что-то бинарное и потом жать. Может кол-во костей можно уменьшить?
|
Хм, интересная идея, надо подумать, во что бинарное можно складывать так, чтобы дополнять можно было без особых головных болей.
Кол-во костей сократить в текущем варианте не получится - шланги реально превращаются в квадратно-гнездовые цепи. Там очень слабое взаимодействие между костями в цепи, нет имитации упругости.
Есть несколько мыслей, как это переделать в нечто типа сплайнов, чтобы хранить только опорные точки (которых очевидно будет гораздо меньше, чем костей), но тут возможны кучи разных визуальных багов, т.к. коллайдеры могут иметь только эти самые точки, так что шланг может частично во что-нибудь провалиться. Хотя я смотрю видео, как народ разные верёвки делает, и, похоже, это самый вменяемый путь.
Ещё можно пройти простым путём и поюзать встроенную в физику Юнити симуляцию ткани (Cloth). Но она настолько пипец избыточно сложная, что сотни шлангов и кабелей завесят комп не хуже какого-нибудь мегалёта из KSP. Такая точность имитации не нужна - шланги не сжимаемы, только изгибаемы до определённого предела. Представьте толстую, но гибкую трубу, типа тех, что в Moonbase Alpha.
Алсо, ещё пытаются делать цепочки из объектов, соединённых hinge joints, но это полезно только если цепь можно/нужно рвать в произвольных местах, а так - лишняя нагрузка.
Шланг не должен растягиваться и (пока) рваться, а также не должен сворачиваться в комочек...
добавлено спустя 54 минуты:
С учётом того, что их было бы неплохо ещё и вменяемо добавлять в сцену в чём-то типа контейнеров, свёрнутыми ещё в префабе, я начинаю думать, что на фиг эксперименты и проще купить готовое решение.
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (10:08 18-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
А оно вообще работает? Дело в том что это должно быть довольно большая нагрузка на CPU
_________________
MOV topka, C++ |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Jurec : |
|
А оно вообще работает? Дело в том что это должно быть довольно большая нагрузка на CPU
|
Вообще - да. Дело в том, что есть такая штука, как freezing (Sleep в терминах Юнити) - когда скорость элемента физики становится ниже определённого порога, эта скорость зануляется и он перестаёт считаться по полной модели. Остаётся только проверка на коллижены, а она недорогая.
Наверное, всё-таки оставлю кости + IK + коллижены для взаимодействия. Попробую уменьшить их количество и поиграть с ограничениями. Пока это один из самых лёгких вариантов в плане нагрузки.
добавлено спустя 21 минуту:
Можно, правда, и процедурную оболочку на пружинках сделать, один добрый товарищ даже написал скрипт на кастомной физике, и оно весьма похоже на верёвку. Только с настройкой его внешнего вида проблем существенно больше. А нагрузка примерно та же, меняем IK на физику...
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (13:38 18-11-2013), всего редактировалось 3 раз(а) |
|
|
|
Jurec
348 EGP
Рейтинг канала: 4(76)
Репутация: 102
Сообщения: 1441 Заблокирован
Откуда: Seattle
Зарегистрирован: 25.02.2006
|
|
а, я думал они все постоянно в движении
_________________
MOV topka, C++ |
|
|
|
Olorin
70 EGP
Рейтинг канала: 1(6)
Репутация: 12
Сообщения: 97
Откуда: Хьёрвард
Зарегистрирован: 27.02.2006
|
|
| Guest : |
Много. От 100 на каждый провод. Иначе он начинает вести себя как цепь со звеньями. Точность координат - float.
Пухлость сейва из-за структуры сохранения - там XML, надо какую-то попроще сериализацию, но с возможностью достраивать структуру сейва новыми полями, чтобы сейвы между апдейтами игры не херились.
Но сейв ещё не так страшно, а вот какой траффик будет по сети генериться? По сути же надо чуть ли не целиком сцену передавать, это не шутер с сотней векторов...
|
Чем BinarySerializer плох?..
Чтоб проблем с типами разных версий не было - соблюдать простые правила расширения: новые поля дописывать в конец.
Впрочем, я плохо помню его алгоритм, может оно и не принципиально, достаточно какой-нить флаг выставить. Но поддержка разноверсионных на сериализации/десериализации типов в нем точно есть. В крайнем случае - прошерстить рефлектором, возможно скопипастить и поправить как надо.
Выхлоп должен быть компактнее xml-я, но он пишет полные имена типов, ибо универсальный. При желании, на них можно бы сэкономить.
Еще компактнее - написать алгоритм сериализации/десериализации вручную через BinaryWriter/BinaryReader.
_________________
Мы на многое не отваживаемся не потому что оно трудно; оно трудно именно потому, что мы на него не отваживаемся.
Сенека Старший |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Unity -- учим вместе» |
|
|
| К списку каналов | Наверх страницы |
Цитата не в тему: Мне не нравится, что в игре нельзя почесать хоботом спинной плавник. (недоволен Zloy)
|
| » Unity -- учим вместе | страница 11 |
|
