Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
оператор goto, который в Java управляет переходами во вложенных циклах, а в C# сохраняет свое древнее предназначение.goto? Суровые вы программисты.))
в джаве goto используется ТОЛЬКО для перехода во вложенных циклах
Думаю, IgorFedorchuk имел ввиду, что использование goto в принципе моветон.
Суровое наследие алгоритма на дельфе, наверное. Меня другое интересует, почему рожи на картинках такие страшные? :)
Не стоит относиться к этому правилу, как к заповеди. В C goto очень полезен для освобождения ресурсов перед return, а в Java — для выхода из вложенного цикла (заводить для этого переменную и писать условие — вот уж точно моветон).
Оценка без комментария — это как заключение в тюрьму без выдвигания обвинений и объявления приговора. В чём я неправ? Таки goto — абсолютное зло?
Можете попробовать доказать свою правоту, приведя пример кода, когда goto действительно оправдан. И помним, что мы говорим про Java/C#.
Фишка в том, шо можно все переписать без goto, но код получится не в пример кривее и длиннее. Это же авторская логика поведения ботов, ее надо портировать очень аккуратно, а то боты соберут скайнет и паработят всех :)
C#
Как выяснилось, в Java goto не используется, хотя и является зарезервированным словом, а для выхода из внешнего цикла делается так:
Каюсь, не знал. Пишу на Java всего несколько месяцев, вложенных циклов стараюсь избегать (не в ущерб читабельности, разумеется) — вот и не понадобилось пока.
for (int i = 0; i < 4; ++i)
{
for (int j = 0; j < 4; ++j)
{
Console.WriteLine("i = {0}, j = {1}", i, j);
if (j == 2 && i == j)
goto EXIT_OUTER_LOOP;
}
}
EXIT_OUTER_LOOP:
Console.WriteLine("After the outer loop");
Как выяснилось, в Java goto не используется, хотя и является зарезервированным словом, а для выхода из внешнего цикла делается так:
OUTER_LOOP:
for (int i = 0; i < 4; ++i)
{
for (int j = 0; j < 4; ++j)
{
System.out.println(String.format("i = %s, j = %s", i, j));
if (j == 2 && i == j)
break OUTER_LOOP;
}
}
System.out.println("After the outer loop");
Каюсь, не знал. Пишу на Java всего несколько месяцев, вложенных циклов стараюсь избегать (не в ущерб читабельности, разумеется) — вот и не понадобилось пока.
Вот у нас есть код на джаве и на шарпе:
Просьба учесть, что этот метод вызывается 100500 раз на каждом ходу.
protected final int processSuitMax(final int[] ranks, final int size, final int initialValue) {
final int[] Z0 = this.Z0;
int result = initialValue;
int resultSuit = result << 3; // * 8
Next:
for (;;) {
for (int j = 0; j < size; j++) {
if (ranks[j] > Z0[resultSuit + j]) {
result++;
resultSuit = result << 3; // * 8
continue Next;
}
}
break;
}
return result;
}
protected int processSuitMax(int[] ranks, int size, int initialValue)
{
int[] Z0 = this.Z0;
int result = initialValue;
int resultSuit = result << 3; // * 8
for (; ; )
{
Next:
for (int j = 0; j < size; j++)
{
if (ranks[j] > Z0[resultSuit + j])
{
result++;
resultSuit = result << 3; // * 8
goto Next;
}
}
break;
}
Просьба учесть, что этот метод вызывается 100500 раз на каждом ходу.
О море надо спрашивать у рыбака ;)
Вам написать обзор? Я в преферанс играть люблю.
Вам написать обзор? Я в преферанс играть люблю.
Ваш преферанс на Android, пожалуй, лучший из реализаций под мобильные платформы. А вот ссылку на него для iOs мне не удалось отыскать. Даже на горе-обзор.Не подскажете?
Не было альтернатив NGUI? Например, Daikon GUI. Отличная альтернатива. А так в атласы паковать и прочее умеют дофига фреймоворков и часть из них это умеет делать лучше чем NGUI(я про удобство использования например), Daikon в том числе. Да и ИМХО зря разработчик NGUI сейчас пилит GUI для юньки, потому что NGUI не самый удобный фреймворк.
PS игра хорошая кстати.
PS игра хорошая кстати.
Подтверждаю, альтернативы нет и в ближайшем будущем вообще не потребуется, ибо весь функционал станет штатным, а новые версии нгуя можно будет рассматривать как обкатку будущего функционала. К тому же когда был выпущен «Daikon GUI»? В статье есть указание, что они пилили его полгода, думаю, тогда еще дела обстояли не так хорошо у Daikon. Если не секрет, в чем заключается неудобство? Все поставляется в сорцах, можно расширять своими контролами, патчить базовые, если сильно потребуется.
Я ничего не имею против NGUI. Но мне не нравятся следующие вещи.
Он плохо оптимизирован. Это незаметно на десктопах, но на мобилах мне его производительность не нравится.
Не удобный интерфейс. Слишком много телодвежений нужно делать, что бы сделать простые вещи.
Не удобная архитектура. Опять же это на фоне других, что работа с их камерой, что панели, что виджеты.
Проблемы со слоями. Вот это самый большой минус этого фреймворка, настроить нормально глубину. когда много панелей и пару анхоров — очень геморно. Всегда что-то перекроет кого-то непонятным образом.
Может быть ему не было альтернатив год назад, сейчас же их хватает. К примеру я использовал и 2D Toolkit, он умеет сейчас столько же и лишен тех недостатков(ну и плюс у них очень удобная система Layout, а не простые анхоры, а так же скейл под разные разрешения сделан удобней). Но есть еще лучше чем 2D Toolkit — это, как я писал уже выше Daikon GUI, он чисто заточен под GUI в отличии от 2D Toolkit.
Он плохо оптимизирован. Это незаметно на десктопах, но на мобилах мне его производительность не нравится.
Не удобный интерфейс. Слишком много телодвежений нужно делать, что бы сделать простые вещи.
Не удобная архитектура. Опять же это на фоне других, что работа с их камерой, что панели, что виджеты.
Проблемы со слоями. Вот это самый большой минус этого фреймворка, настроить нормально глубину. когда много панелей и пару анхоров — очень геморно. Всегда что-то перекроет кого-то непонятным образом.
Может быть ему не было альтернатив год назад, сейчас же их хватает. К примеру я использовал и 2D Toolkit, он умеет сейчас столько же и лишен тех недостатков(ну и плюс у них очень удобная система Layout, а не простые анхоры, а так же скейл под разные разрешения сделан удобней). Но есть еще лучше чем 2D Toolkit — это, как я писал уже выше Daikon GUI, он чисто заточен под GUI в отличии от 2D Toolkit.
>> Он плохо оптимизирован. Это незаметно на десктопах, но на мобилах мне его производительность не нравится.
>> Но есть еще лучше чем 2D Toolkit
Он прекрасно оптимизирован и прекрасно работает на мобилках. Просто используйте его по назначению, а не как 2d фреймворк для спрайтов, он заточен под работу с гуй-виджетами, которые не часто двигаются. Разумеется, если вы будете двигать все виджеты для симуляции 2д-спрайтовой игрушки, то это будет фейл и нгуй будет перестраивать резульирующий меш геометрии каждый фрейм. Т.е. у 2д-тулкита и нгуя абсолютно разное назначение — первый расчитан на спрайтовые динамически 2д-штуки, второй — под статичный сложный гуи с эффектами и развесистой системой сообщений.
>> Не удобный интерфейс. Слишком много телодвежений нужно делать, что бы сделать простые вещи.
Прекрасный интерфейс. Какие простые вещи показались вам сложными?
>> Не удобная архитектура. Опять же это на фоне других, что работа с их камерой, что панели, что виджеты.
С 3.х ветки ведется унификация и виджет становится независимым базовым невизуальным контролом. Смысл панелей только в одном — создание изолированных скроллящихся блоков с отсечением по области. Так же панели служили во второй ветке для изолирования контента (содержимое рендерилось за отдельный drawcall) — полезно для всяких всплывающих окон.
>> Проблемы со слоями. Вот это самый большой минус этого фреймворка, настроить нормально глубину. когда много панелей и пару анхоров — очень геморно.
Тут согласен, хотя объяснение разраба тоже логично — zfighting и сортировка по глубине уходят в прошлое с учетом правильно настроенной глубины. С какой-то 3.х версии появилась возможность указания глубины у панели целиком, т.е. сортировка внутри панели становится локальной.
По поводу UIAnchor-ов. Они в преферансе не используются в принципе, там своя система пропорционального позиционирования. Во всех фреймворках почему-то упорно цепляются к сторонам экрана, тут по требованиям была нужна «резинка».
>> Но есть еще лучше чем 2D Toolkit
Он прекрасно оптимизирован и прекрасно работает на мобилках. Просто используйте его по назначению, а не как 2d фреймворк для спрайтов, он заточен под работу с гуй-виджетами, которые не часто двигаются. Разумеется, если вы будете двигать все виджеты для симуляции 2д-спрайтовой игрушки, то это будет фейл и нгуй будет перестраивать резульирующий меш геометрии каждый фрейм. Т.е. у 2д-тулкита и нгуя абсолютно разное назначение — первый расчитан на спрайтовые динамически 2д-штуки, второй — под статичный сложный гуи с эффектами и развесистой системой сообщений.
>> Не удобный интерфейс. Слишком много телодвежений нужно делать, что бы сделать простые вещи.
Прекрасный интерфейс. Какие простые вещи показались вам сложными?
>> Не удобная архитектура. Опять же это на фоне других, что работа с их камерой, что панели, что виджеты.
С 3.х ветки ведется унификация и виджет становится независимым базовым невизуальным контролом. Смысл панелей только в одном — создание изолированных скроллящихся блоков с отсечением по области. Так же панели служили во второй ветке для изолирования контента (содержимое рендерилось за отдельный drawcall) — полезно для всяких всплывающих окон.
>> Проблемы со слоями. Вот это самый большой минус этого фреймворка, настроить нормально глубину. когда много панелей и пару анхоров — очень геморно.
Тут согласен, хотя объяснение разраба тоже логично — zfighting и сортировка по глубине уходят в прошлое с учетом правильно настроенной глубины. С какой-то 3.х версии появилась возможность указания глубины у панели целиком, т.е. сортировка внутри панели становится локальной.
По поводу UIAnchor-ов. Они в преферансе не используются в принципе, там своя система пропорционального позиционирования. Во всех фреймворках почему-то упорно цепляются к сторонам экрана, тут по требованиям была нужна «резинка».
Например, очень не удобно работать с атласами. У 2д тулкит есть возможность вставлять GUI контролы, эта новая часть фреймворка и она не сильно развита, но она уже как минимум не хуже NGUI. А вот насчет оптимизации, вы конечно имеете право на свое мнение, но чисто объективно он оптимизирован плохо. Я не хочу сейчас вдаватся в детали и вас переубеждать, ваше право. :)
Кстати в него уже добавили обновление атласов после того, как ты редактируешь отдельно текстуру, которая входит в атлас?
Кстати в него уже добавили обновление атласов после того, как ты редактируешь отдельно текстуру, которая входит в атлас?
Подскажите, а почему было принято решение мигрировать на Unity3d, если весь код уже был написан на java? Не проще ли было использовать какой-то java-фреймворк вроде libgdx, который замечательно справляется с 2d и работает на мобильных платформах и через gwt может быть в javascript скомпилирован (при очень большом желании использования этого же кода в онлайне)?
Во-первых онлайн это главная цель разработки. Очень надеемся, что сможем поддерживать только одну версию игры. По поводу libgdx — мы попробовали его, даже сделали демку. Скорее всего, мы не умеем его готовить, поэтому эксперимент оказался не удачным. Кроме того, в нашей игре есть плагины (покупки, реклама и т д) которые оказалось довольно сложно подобрать.
Портирование кода — это шарп затянуло достаточно долго потому что мы переписали структуру движка, чтобы он был готов к онлайну. На Android версии сейчас тоже используем его.
Портирование кода — это шарп затянуло достаточно долго потому что мы переписали структуру движка, чтобы он был готов к онлайну. На Android версии сейчас тоже используем его.
Хотел бы заменить, что по моему ощущению игры на Unity гораздо прожорливее в плане батареи. Я подозреваю, что многим пользователем все равно, но было бы здорово если бы разработчики уделяли хоть немного времени оптимизации энергопотребления. Я например люблю играть в дороге, и я просто не могу играть в игры которые быстро сажают батарею.
Тут нужно понимать, что юнити — это полноценный realtime движок, где экран очищается, перерисовывается полностью каждый кадр с достаточно высокой скоростью. Т.е. принцип работы отличается от рендера, допустим, вебстраницы. Скорость обновления в секунду обычно 30-60фпс. Тут тоже нужно думать о том, что лучше — плавная анимация (высокий фпс) с различными эффектами или максимальная энергоэффективность (низкий фпс).
Да я понимаю, но вот вопрос то как раз в эффектах. Например говоря о карточной игре — эффекты меня интересуют в последнюю очередь.
Так ведь все зависит от задачи. Если в постановке есть «сделать максимально энергоэффективным любыми способами», то это одно, а когда есть задача выйти на гламурный апстор, то появляются совершенно другие требования.
Мы сегодня уже получили запросы на тему «хочу такой же преферанс, но розовенький, так как мой айфон 5s беленький». Наша сила — в алгоритмах, но внешний вид так же немаловажен.
Т.е. фактически при запуске на реальном железе — никакой отладки проекта, только на ощупь по логам и колстеку.
это не совсем так, там есть возможность отладчиком приатачится к приложению запущенном на девайсе если собрать билд с парой дополнительных галочек
На реальном девайсе всегда нейтив + вкрапления комментов из вызовов методов после трансляции АОТ-ом. Вы говорите про подключение профайлера к девайсу в юнити, или подключение реальной отладки (пусть даже в штатном monodevelop-е) на шарпе? Нужна отладка именно шарпа.
да я про отладку на устройстве вот:
отсюда Manual/Debugger
т.е это удаленная сетевая отладка шарп кода по сети
вот как это выглядит из monodevelop:
но это все мягко говоря работает не очень стабильно, в последней юнити 4.3 даже с отладкой в редакторе куча проблем
iOS remote debugging instructions
In addition to the instructions described above, Unity iOS applications require some additional steps for successful debugging:
Attach your iDevice to your WiFi network (the same requirement as for remote profiling).
Hit build & run in the Unity editor.
When the application builds, installs & launches via Xcode, click Stop in Xcode.
Manually find & launch your application on your iDevice. (Note: if the application is launched via Xcode you won't be able to resume after reaching a breakpoint).
When the app is running on the device, switch to MonoDevelop and click on the attach icon in the debugging toolbar. Select your device from the available instances list (if there are several instances shown, then select the bottom one).
отсюда Manual/Debugger
т.е это удаленная сетевая отладка шарп кода по сети
вот как это выглядит из monodevelop:
но это все мягко говоря работает не очень стабильно, в последней юнити 4.3 даже с отладкой в редакторе куча проблем
Будет ли версия под Windows Store и Windows Phone?
Cкажите, я туплю или почему в таблице результатов не видно сколько вистов записано у компьютерных противников друг на друга? В обеих — в той, которая появляется после каждой сыгранной раздачи, и которая появляется по вызову во время игры, сверху плашка закрывает часть результатов. Версия под iOs.
Пришлите, пожалуйста, нам скриншот на brainfitnessltd@gmail.com
отправил. кстати, еще один вопрос — в купленной игре все равно отображается контекстная реклама (см. приложенный скриншот) — это так нужно или забыли поправить?
С рекламой — это наша бага. Нам стыдно, но мы исправим.
Спасибо, прекрасный продукт. Начал играть на iOS.
Интерфейс немного удивляет:
* снос и ход делаются двумя тапами, вместо естественного на тачскрине drag-n-drop;
* иногда нет паузы там, где она необходима — например, при вскрытии прикупа.
* прочее: синхронизация путешествия на планшете с iCloud не сработала, на телефоне я в самом начале 8(
В остальном — всё супер!
Интерфейс немного удивляет:
* снос и ход делаются двумя тапами, вместо естественного на тачскрине drag-n-drop;
* иногда нет паузы там, где она необходима — например, при вскрытии прикупа.
* прочее: синхронизация путешествия на планшете с iCloud не сработала, на телефоне я в самом начале 8(
В остальном — всё супер!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кроссплатформенный канделябр