Comments 24
Поздравляю, вы только что повесили себе ружье на стену.
Unity позволяет писать на JS, C# и Boo на выбор и прочитав эту статью хотелось бы задать вопрос — существует ли существенная разница в плане возможностей на чем писать? Может ли оказаться что есть вещи какие в Unity можно сделать только на одном из этих языков (к примеру C#) и в принципе невозможно сделать на другом (JS к примеру)? Или любую проблему можно решить на любом из языков, просто немного по разному? Ведь API Unity как я понимаю для всех языков одинаков (в плане возможностей)?
К сожалению я не знаю всех возможностей JavaScript, т.к. ничего серьезного на нем не писал.
На JS можно задать значение для координат трансформа (transform.position.x ,y, z) напрямую (transform.position.x = 50.0f), в C# же придется задавать через Vector3.
Это из известной мне разницы :)
Это из известной мне разницы :)
Лучше использовать C#. JavaScript тут — это JScript от Microsoft, урезанный и стремный.
Для начала ссылка на официальную вики об особенностях местного JS.
Из того с чем я сталкивался:
— геттеры и сеттеры в UnityScript (будем его так называть) есть, но их использование иногда не удобно;
— невозможно передавать в UnityScript объекты в параметрах (в отличии от классического JS).
Из того с чем я сталкивался:
— геттеры и сеттеры в UnityScript (будем его так называть) есть, но их использование иногда не удобно;
— невозможно передавать в UnityScript объекты в параметрах (в отличии от классического JS).
Если это синглтон, то почему бы вам не сохранить куда-нибудь при старте ссылку на инстанс? Тогда и не нужно будет каждый раз рефлекшн дергать.
Еще вариант… отслеживать интеракции с окнами и хранить стэк окон.
П.С.: Ей Богу! Зря вы с рефлекшном завязываетесь! Лучше зайдите с другого бока к проблеме — наверняка есть решение много безопаснее.
Еще вариант… отслеживать интеракции с окнами и хранить стэк окон.
П.С.: Ей Богу! Зря вы с рефлекшном завязываетесь! Лучше зайдите с другого бока к проблеме — наверняка есть решение много безопаснее.
почему бы вам не сохранить куда-нибудь при старте ссылку на инстанс? Тогда и не нужно будет каждый раз рефлекшн дергать.
Я об этом написал в примечании, сама функция это пример.
Еще вариант… отслеживать интеракции с окнами и хранить стэк окон.
Это решение не подходит, ввиду того, что мы не знаем на каком слое окно после вызова. К тому же отследить все варианты изменения глубины окна не представляется возможным.
Лучше зайдите с другого бока к проблеме — наверняка есть решение много безопаснее.
Нету. Либо гугль, форум юнити, и их документация о нем не знают.
Это решение не показало уменьшения производительности или стабильности клиента.
Небезопасность тут потоньше. Реализация может измениться и код вдруг начнет падать или работать не так.
> Это решение не показало уменьшения производительности или стабильности клиента.
До поры… до времени… Так всегда вначале кажется, что производительность не аффектается. А потом постепенно такие же костыли появляются в других местах либо на этот кастыль наложится другой, который сам по себе ничего не рушит. А вместе полная задница.
П.С.: еще вариант — докинг без перекрытия. Уж выстроить то окна рядом друг с другом можно?
См. тайловые менеджеры окон
До поры… до времени… Так всегда вначале кажется, что производительность не аффектается. А потом постепенно такие же костыли появляются в других местах либо на этот кастыль наложится другой, который сам по себе ничего не рушит. А вместе полная задница.
П.С.: еще вариант — докинг без перекрытия. Уж выстроить то окна рядом друг с другом можно?
См. тайловые менеджеры окон
А сделать классы обертки для окон с уникальным ID нельзя?
Есть еще одна проблема — рефлекшн выпилен в мобильных платформах и, потенциально, в вебплеере (надо проверять). Т.е. получается непереносимость проекта, что ломает одну из основных «фич» юнити — сборка одного проекта под несколько платформ.
Не придираюсь к конкретному проекту, просто хотел бы обсудить конепцию данного интерфейса.
Придерживаюсь мнения, что перетаскиваемые окна не так удобны, как может показаться. Из примеров игр, в которых были реализованы «плавучий» оконный интерфейс вспоминаются Морровинд, ЕВЕ онлайн, Рагнарок онлайн. Из моих наблюдений во всех случаях игрок приходил к тому, что однажды распологал окна, а потом не менял эту схему на протяжении всей игровой «карьеры». Схема обычно придераживалась некоторых правил: окна не наслаивались друг на друга; схожие по функциональности окна (например, сундук и рюкзак) ставились рядом и подгонялись под одну высоту или ширину; чем больше информации в окне, тем больше окно. Словом, я считаю, что если бы за игрока все это сделал (конечно, с крайней вдумчивостью и отсветсвенностью) разработчик или дизайнер интерфейсов, то и игрок бы оказался в плюсе, и от многой лишней функциональности (перетаскивание окон) можно было бы отказаться.
Придерживаюсь мнения, что перетаскиваемые окна не так удобны, как может показаться. Из примеров игр, в которых были реализованы «плавучий» оконный интерфейс вспоминаются Морровинд, ЕВЕ онлайн, Рагнарок онлайн. Из моих наблюдений во всех случаях игрок приходил к тому, что однажды распологал окна, а потом не менял эту схему на протяжении всей игровой «карьеры». Схема обычно придераживалась некоторых правил: окна не наслаивались друг на друга; схожие по функциональности окна (например, сундук и рюкзак) ставились рядом и подгонялись под одну высоту или ширину; чем больше информации в окне, тем больше окно. Словом, я считаю, что если бы за игрока все это сделал (конечно, с крайней вдумчивостью и отсветсвенностью) разработчик или дизайнер интерфейсов, то и игрок бы оказался в плюсе, и от многой лишней функциональности (перетаскивание окон) можно было бы отказаться.
Sign up to leave a comment.
Unity3D 3.x Получение текущего активного окна