Именно поэтому и предложил глянуть на апи огла. Там ситуация куда как хуже чем на винапи, при этом, строение программы неотличимо, от винапишного. В общем, как обычно на Хабре. Увидел блестящую цацку и понёс в массы, ну и просто понёс. Ладно уж, оставайся в плену своих иллюзий.
Фишка в том, что вот эта обвязка в коде, даже не всегда обязательна. В том смысле, что это можно вполне зашаблонить и туда заглядывать "только по праздникам", а остальная часть работы с WinAPI, куда как более изящна и проста (как минимум для меня) чем в твоих примерах.
В целом, ты высказал хорошую мысль по поводу корпоративной побрякушки, и тут ты оказался прав. Я точно так же думал, думаю и буду думать. Ну, в отличии от тебя. К слову, ради интереса, глянь как устроен GLEW. Ну, тупо хидер глянь, как он цепляется к OpenGL и ведет обмен с апишкой. Тебе достаточно скачать два файлика под пару метров и у тебя актуальная версия огла. Да, внутри там трэш и угар, но ты этого не видишь, и на результате это не сказывается.
В общем, восторги неофита понимаю, но ты меня не убедил. Но всё равно спасибо, статья презабавная и реально полезная, если игнорировать твои выводы. Без обид.
По поводу качества, ну, вы сами подумайте, кто и с каких "примеров" писали код. То есть, конечно, массивное выделение массивов (прасити) это долгая и нудная работа, которую мы, геймдевы подобрали, отряхнули, чутка приспособили под себя - и "шоу начинается". Но это уже отработанные, отполированные куски, или это было бы изрядной авантюрой, вы должны это сами понимать.
Конечно, убрать лишние проверки, которые ВОЗМОЖНО сработают один раз на миллион запусков программы, это обязательно, и только это даёт порядка 5% прироста производительности. Только вот убирание ассертов и прочего. На ровном месте, без алгоритмов и так далее. Так что да. Не только утверждаю, но и уверен в этом. Сам видел.
Нет, я пояснил, что в таких (!!!) масштабах, разницы почти нету, лаги будут и там и там, разница только в длительности. Но не это важно. Пример к тому, что если мы уменьшим проблемы с экстремальных до нормальных, то получим то, что вдруг внезапно, контейнера начинают подтупливать. С чего бы это. Вроде бы чуть, но, всё равно странно. Причем на простейших операциях (типа добавления).
К тому и был пример, что некоторые вещи ты должен контролировать сам, ибо кто контролирует Дюну, контролирует... Стоп, не отсюда, ибо все кто контролирует выделение памяти, контролирует и быстродействие программы (особенно, сложной). Впрочем, буду откровенен, за деньги, я бы написал бы код для этой программы, используя контейнера. Это быстрее и надежнее. А так как мне платят за результат, а не за как оно работает... Ну, очевидно что выйдет.
Это в EMUI (Хуавей) - там тупо есть список прожек которым разрешен (или не разрешен) выход в нет. Так вот, когда у тебя инет есть, но у проги его нету, он сразу алармит гуглосервисам, а те уже алармят тебе, что всё, капец, нужен интернет, а вы его отключили и прочая. На работоспособность прожек, где это "сбоку с припёку" инет, не влияет никак, только что надо постоянно от этих ворнингов отмахиваться.
И нет, от кого прилетел, тут есть тонкость. Прилетает именно что от гуглсервисов, а не от активной проги, хотя и по запросу оной (точнее, кода гугла в ней).
Так что, читать тоже надо, мало ли там что и как и откуда захотело из фона в этот момент затребовать себе ))) Поэтому и смешно, что инета нет у одной прожки, а требует включить оный - совсем другая. Что выглядит как минимум некрасиво, о чем и было выше сказано )
О, стринг, да. Вот, к слову, довольно хорошо подмечено. Проблема вообще Сишных строк (н-т) это то, что там устроить вылет за границы массива, это вот как два пальца. Или постоянно считать длинну. Что к слову, не мешает иногда сделать опять же вылет за границу, просто надо гораздо больше изобретательности в создании ошибки проявить )
В целом, это годный пример.
Но есть и контр-пример.Давным давно, писал свой создатель словаря. (файл разбивается на идентичные участки, которые потом кодируются. Простенький и эффективный архиватор для огромного количества текста (уточню, писал я на 486ом, на ТС2.0, так что должны понимать, что хранить пару десятков тысяч книг было далеко не самым простым занятием в те веселые времена). Так вот, даже сейчас используя совсем другие инструменты, с совершенно другим же быстродействием, и прочее, и прочее, я бы всё равно вернулся бы к варианту с нуль-терминированными строками. Потому как одно дело, когда у тебя пропадает 2-10% в "ворде" скажем так, и абсолютно другое дело, когда у тебя пропадают эти же проценты, в тот момент когда система лопатит гигабайты данных. Это крупно две разные вещи.
Ну и конечно же... Самое главное. Оптимизировать только то, что надо оптимизировать. (Иначе нету смысла в любых ЯВУ. Только асм, только хардкор.) Зачем оптимизировать скорость работы текстового редактора, который по умолчанию будет работать быстрее пользователя, который, даже самый шустрый, будет "тупить"? :) Поэтому, при всей моей не великой любви к Шарпу, считаю, что для определённого круга задач, это прекрасный язык. За пару часов накидать какой нибудь лончер для обновлений игры? Что может быть проще. А проверните эту же хохму через WinAPI, ну вы понимаете, да? )))
Если "округлить", то могу по поводу этого "заранее оплачено" ответить так, что в случае, когда можно заранее предсказать количество юнитов которые будут храниться в контейнерах, это действительно почти не даёт накладных расходов (почти, но там реально уже мизер, смысла нет из за этого бодаться, код действительно более надёжный, за такую, небольшую цену). Но есть нюанс. Вы должны полностью и целиком знать сколько и чего у вас будет (либо, платить овером по памяти, что к слову, может оказаться и хужее) в сцене. Если сцена динамична, то тут всё, приплыли. А ведь, большая часть современных игр, увы, не статические сцены с заранее просчитанными количеством объектов, вершин и тому подобное. На лету ситуация может меняться от 200 тыс до 300 миллионов вершин в моменте. Всё держать в памяти - ну такое себе, выделять ондеманд ? Так в глухой лаг уйдет проц. Причём ощутимый. Впрочем, при таких скачках, буду откровенен, лагать будет в любом случае, хоть всё на чистом ассемблере напиши. Тут мало что поможет в плане памяти. Так то, для графики проблем нету, что не надо - выкинет из обсчёта и отрисовки, а вот память, только заранее если с хитромудрыми алгоритмами "на опережение". Что требует совсем иных решений, не трогая уже контейнера.
Да блин, посмотрите любые потроха контейнерных классов. Или там просто так, пару сотен тысяч строк кода ?
Эта "безопасность", проверяется там всегда, при каждом добавлении, удалении и так далее. Плюс ресайз, плюс дофига чего. Это всё динамически. Как это вы оплатите на момент компиляции? Если сами не знаете, к примеру, будет обращение к массиву контейнеров или не будет такого вовсе? Как можно "оплатить" при компиляции? Нет, это всё оплачивается во время работы.
Вы вообще знаете, что к примеру, для игр, используют не просто "сырые" указатели, а вообще, самопальные версии "new/malloc" (ну, понятное дело, с нужной обвязкой)? Так как стандартный - слишком медленно, а упарываться выделением памяти через ассемблер - тут выгода слишком мала. Поэтому выделяется сразу здоровенный кусок памяти, куда уже свой собственный менеджер памяти распихивает ресурсы как ему будет надо и как удобно. Не знали про это? Ну вот. Поэтому использование контейнеров, которые надёжно, дубово и при каждом обращении проверяют "всё ли на месте? Всё ли правильно" при просчете сцены с несколькими миллионами вершин - сделают вас седым раньше срока. Если знаете хозяина gamedev.ru Сержа "wat" то может вспомните, как он пытался воткнуть сцену на тех еще компах (ну как 900 мгц Атлон, зверь на то время был) через контейнеры. Де, это мол, стильно, модно, молодёжно. В итоге сцена которая грузится менее секунды, грузилась более пяти минут. Ну, на отрисовку почти, не влияла, это да. Если только незначительно крайне, порядка сотых, тысячных дельты. Ну это и очевидно, она целиком уже в видеопамяти была в нужном виде. После издевательских шуток на форуме, с контейнерами он для графики, завязал. Как сейчас, не знаю )
Если очень интересно, почешите исходники (они есть) контейнеров. Поучительно. Как и внезапное осознание того, что это шаблоны классов. В которых дофига различных и очень непростых функций, даже в самых примитивных казалось бы, контейнерах, не говоря уже про более сложные виды.
Было бы чудесно, если бы так (приходится ведь списки делать, которые ну нифига не безопасные, и не всегда можешь оптимизировать и так далее). Но нет. Как показывает практика, а она, как известно, критерий истины, работа с контейнерами с большим количеством постоянно "перемешиваемых" данных, знатно уступает "самопальным" вариантам по скорости. Вплоть до двух порядков. Контейнеры, они, ведь разные бывают, ага. И когда начинаешь работать с массивами оных, особенно динамических, то что ты платишь за безопасность и простоту - просто замечательно видно. На глаз, не какие профайлеры не нужны.
Такова грустная селяви использования контейнеров и иже в геймдеве. Во всех остальных направлениях, это чудесный и удобный вариант. Для геймдева, увы, нет. Впрочем, можно наплевать на ЦА (как впрочем, большинство и делает), и перекинуть заботу об этом - на конечного пользователя. Если де игра не запускается, значит, компостер слабоват, и иди его грейди. Де, твои проблемы. Собсно, нынешние проблемы с процессорами вызваны как раз такой практикой, и таким отношением прогеров к ЦА. То, что они сужают круг своих же собственных покупателей, к слову, доходит далеко не до всех. Что очень забавно было бы, если бы не печально (геймдевелопер должен учитывать такие вещи, а не игнорировать, абы было удобнее). Потому как говорит о том, что "набирают по объявлению". И игровой индустрии еще не один год приходить в себя после завала 08 года.
Аллё. Вот тут ты по моему, не по адресу вот вообще. По поводу бута, надо серьезный подход, но не "заплатите нам 101 зелёную бумажку, после чего получите код на разлок. А и да, ваша гарантия превращается в тыкву". Нет. Но всё равно, достаточно серьёзный, что бы вирусняками и эксплойтами не пробить.
Рут же - должен включатся простым переключателем в настройках (да, после 10 окошек с предупреждениями и уточнениями что не передумал). И никак иначе.
Так что нет, не скажу, если только под пытками. Ну или музыку Киркорова, но это относится к видам пыток, так что несчитово.
Про Эпик, если честно, когда Вентиль придумал Стим, и начал превращать это в реальность, я был просто в шоке от радости (тогда и ценник был очень и очень либеральный) и все дела. Ну представь, на одной из моих работ, мы получали чуть менее 7% прибыли на всех. 93% уходило издателю. Да, издатель нёс издержки, риски и прочее (включая даже технику иногда). Да и зарплату платил. Но простите, ладно бы, бедные да сирые (хотя на схожем проекте, мы 10 лет сидели и плюя в потолок тихенько полировали игру, за те же деньги что получили от издателя на круг). А что с проектами класса ААА? Сколько они в карманчик то положили? Я то теперь понимаю, с чего Кармак, всё бабло спустил на создание id Software и плевал на лысины издателей. Особо если вспомнить "чудесные" вещи как с Йоквудом и Пираньями за Готику. В общем, для разработчика стим это на те времена - очередное чудо света. Но, бабло как говорится... Мнда. Поэтому, скажем так, я исходя из революционной справедливости считаю, что чума на все их три дома )))
А, да... Есть такая "забавная фича". Нужные разрешения, прога запрашивает у ведроида, ведроид перенаправляет на гугл сервисы, де, разберись чо за фигня? А тот, почесав тымковку, и сравнив с теми, которые установлены у него по дефолту - пересылает их уже тебе, но не от имени программы, а от имени себя, что логично, он то как прокладка используется. Ну вот и выходит такой казус. Хотя по идее, даже если на фоне запущенного процесса запрос идёт, всё равно должен спросить с ЧЁТКИМ указанием проги, ее версии и так далее. Желательно со ссылками на "что, почему и кто виноват".
У меня схожая картинка, когда лишаю прожек массово доступа в инет (особливо тем, которым он вообще в фиг не впёрся в принципе). Но там сидит гугловская заплатка-баннер, которая сразу начинает вопить "ой-ой-ой, приложение не может работать без доступа к сети". Ага, счаз.
Слушай, ведроид стараниями гугла уже помойку напоминает. А они всё не успокаиваются. Оно тебе надо? Если последний вменяемый был седьмым, а за окном призывно машет крылом еще более долбанутый 15ый? Может, лучше, энтузиасты?
Будем честными. Все эти "подвязки" и есть огромное, корявое шапито с пьяными клоунами. И чем раньше их уберут, тем лучше будет. Нам. Не гуглу, конечно же. Так как это гнилое корыто и придумано, что бы пользователи не соскочили. У меня сервисы под гиг озу занимают, из шести. В фоне, тля, в фоне! Как такое можно понять?
зевает не бегут, а их выдавливают во всякие вьетнамы, индии, африки. Оставляя у себя только самый топ. И дофига прибыли, и никакой головной боли с карбоновым следом и прочей чушью. Я не говорю, что они поступают правильно, я говорю, что вы неверно понимаете причину происходящего, поэтому то ошибаетесь и в следствиях происходящего, неся ересь про бегут, стагнация и прочее. Наоборот всё. В ресторане высокой кухни, брюкву варенную, не подают, это воон там, за углом в конце города.
Вот за такое, руки об батарею отбивать и надро. Контейнеры не просто так в геймдеве не любят использовать, предпочитая рисковать ручным управлением памятью. Накладные расходы просто гигантские. А надёжность, при норм программисте - минимальна.
Грубо говоря, вы в своём примере "облегчили" код на 10%, устранили баг с шансом на миллион, и после утяжелили его в 30 раз на ровном месте. Офигеть оптимизация, никакого проца не хватит.
Геймдев это не ваше. Примеры пишите на офисных прожках. Ну, не на СУБД же, да? xD
Автор "мило" забыл про то, что встроенные шрифты были только под винду и Дайрикс. Остальные, все, даже сейчас, представляют собой банальные спрайты. Что драматично сказывается на скорости вывода на компе. Так как альфу и блендинг никто не отменял порой (для кроссплатформ особенно).
Ну а вращение спрайта, это настолько ходовое, что говорить не обо что. К слову, опять же, до сих пор. Выгодно. Места много, памяти тоже, зачем грузить гпу (в худших случаях цпу)?
Лучше, уж скриптер для писюка, навроде, Луа, сделай. Много кто спасибо скажет. И для дела пригодиться. А то времени тупо на них, не хватает, а они уже до 50% кода занимают + почти всё процессорное время программы. Ну нафиг такие скрипты.
Да, да, да... Обиделся.
Именно поэтому и предложил глянуть на апи огла. Там ситуация куда как хуже чем на винапи, при этом, строение программы неотличимо, от винапишного. В общем, как обычно на Хабре. Увидел блестящую цацку и понёс в массы, ну и просто понёс. Ладно уж, оставайся в плену своих иллюзий.
Смертный, успокойся...
Фишка в том, что вот эта обвязка в коде, даже не всегда обязательна. В том смысле, что это можно вполне зашаблонить и туда заглядывать "только по праздникам", а остальная часть работы с WinAPI, куда как более изящна и проста (как минимум для меня) чем в твоих примерах.
В целом, ты высказал хорошую мысль по поводу корпоративной побрякушки, и тут ты оказался прав. Я точно так же думал, думаю и буду думать. Ну, в отличии от тебя. К слову, ради интереса, глянь как устроен GLEW. Ну, тупо хидер глянь, как он цепляется к OpenGL и ведет обмен с апишкой. Тебе достаточно скачать два файлика под пару метров и у тебя актуальная версия огла. Да, внутри там трэш и угар, но ты этого не видишь, и на результате это не сказывается.
В общем, восторги неофита понимаю, но ты меня не убедил. Но всё равно спасибо, статья презабавная и реально полезная, если игнорировать твои выводы. Без обид.
По поводу качества, ну, вы сами подумайте, кто и с каких "примеров" писали код. То есть, конечно, массивное выделение массивов (прасити) это долгая и нудная работа, которую мы, геймдевы подобрали, отряхнули, чутка приспособили под себя - и "шоу начинается". Но это уже отработанные, отполированные куски, или это было бы изрядной авантюрой, вы должны это сами понимать.
Конечно, убрать лишние проверки, которые ВОЗМОЖНО сработают один раз на миллион запусков программы, это обязательно, и только это даёт порядка 5% прироста производительности. Только вот убирание ассертов и прочего. На ровном месте, без алгоритмов и так далее. Так что да. Не только утверждаю, но и уверен в этом. Сам видел.
Нет, я пояснил, что в таких (!!!) масштабах, разницы почти нету, лаги будут и там и там, разница только в длительности. Но не это важно. Пример к тому, что если мы уменьшим проблемы с экстремальных до нормальных, то получим то, что вдруг внезапно, контейнера начинают подтупливать. С чего бы это. Вроде бы чуть, но, всё равно странно. Причем на простейших операциях (типа добавления).
К тому и был пример, что некоторые вещи ты должен контролировать сам, ибо кто контролирует Дюну, контролирует... Стоп, не отсюда, ибо все кто контролирует выделение памяти, контролирует и быстродействие программы (особенно, сложной). Впрочем, буду откровенен, за деньги, я бы написал бы код для этой программы, используя контейнера. Это быстрее и надежнее. А так как мне платят за результат, а не за как оно работает... Ну, очевидно что выйдет.
Это в EMUI (Хуавей) - там тупо есть список прожек которым разрешен (или не разрешен) выход в нет. Так вот, когда у тебя инет есть, но у проги его нету, он сразу алармит гуглосервисам, а те уже алармят тебе, что всё, капец, нужен интернет, а вы его отключили и прочая. На работоспособность прожек, где это "сбоку с припёку" инет, не влияет никак, только что надо постоянно от этих ворнингов отмахиваться.
И нет, от кого прилетел, тут есть тонкость. Прилетает именно что от гуглсервисов, а не от активной проги, хотя и по запросу оной (точнее, кода гугла в ней).
Так что, читать тоже надо, мало ли там что и как и откуда захотело из фона в этот момент затребовать себе ))) Поэтому и смешно, что инета нет у одной прожки, а требует включить оный - совсем другая. Что выглядит как минимум некрасиво, о чем и было выше сказано )
О, стринг, да. Вот, к слову, довольно хорошо подмечено. Проблема вообще Сишных строк (н-т) это то, что там устроить вылет за границы массива, это вот как два пальца. Или постоянно считать длинну. Что к слову, не мешает иногда сделать опять же вылет за границу, просто надо гораздо больше изобретательности в создании ошибки проявить )
В целом, это годный пример.
Но есть и контр-пример.Давным давно, писал свой создатель словаря. (файл разбивается на идентичные участки, которые потом кодируются. Простенький и эффективный архиватор для огромного количества текста (уточню, писал я на 486ом, на ТС2.0, так что должны понимать, что хранить пару десятков тысяч книг было далеко не самым простым занятием в те веселые времена). Так вот, даже сейчас используя совсем другие инструменты, с совершенно другим же быстродействием, и прочее, и прочее, я бы всё равно вернулся бы к варианту с нуль-терминированными строками. Потому как одно дело, когда у тебя пропадает 2-10% в "ворде" скажем так, и абсолютно другое дело, когда у тебя пропадают эти же проценты, в тот момент когда система лопатит гигабайты данных. Это крупно две разные вещи.
Ну и конечно же... Самое главное. Оптимизировать только то, что надо оптимизировать. (Иначе нету смысла в любых ЯВУ. Только асм, только хардкор.) Зачем оптимизировать скорость работы текстового редактора, который по умолчанию будет работать быстрее пользователя, который, даже самый шустрый, будет "тупить"? :) Поэтому, при всей моей не великой любви к Шарпу, считаю, что для определённого круга задач, это прекрасный язык. За пару часов накидать какой нибудь лончер для обновлений игры? Что может быть проще. А проверните эту же хохму через WinAPI, ну вы понимаете, да? )))
Если "округлить", то могу по поводу этого "заранее оплачено" ответить так, что в случае, когда можно заранее предсказать количество юнитов которые будут храниться в контейнерах, это действительно почти не даёт накладных расходов (почти, но там реально уже мизер, смысла нет из за этого бодаться, код действительно более надёжный, за такую, небольшую цену). Но есть нюанс. Вы должны полностью и целиком знать сколько и чего у вас будет (либо, платить овером по памяти, что к слову, может оказаться и хужее) в сцене. Если сцена динамична, то тут всё, приплыли. А ведь, большая часть современных игр, увы, не статические сцены с заранее просчитанными количеством объектов, вершин и тому подобное. На лету ситуация может меняться от 200 тыс до 300 миллионов вершин в моменте. Всё держать в памяти - ну такое себе, выделять ондеманд ? Так в глухой лаг уйдет проц. Причём ощутимый. Впрочем, при таких скачках, буду откровенен, лагать будет в любом случае, хоть всё на чистом ассемблере напиши. Тут мало что поможет в плане памяти. Так то, для графики проблем нету, что не надо - выкинет из обсчёта и отрисовки, а вот память, только заранее если с хитромудрыми алгоритмами "на опережение". Что требует совсем иных решений, не трогая уже контейнера.
Да блин, посмотрите любые потроха контейнерных классов. Или там просто так, пару сотен тысяч строк кода ?
Эта "безопасность", проверяется там всегда, при каждом добавлении, удалении и так далее. Плюс ресайз, плюс дофига чего. Это всё динамически. Как это вы оплатите на момент компиляции? Если сами не знаете, к примеру, будет обращение к массиву контейнеров или не будет такого вовсе? Как можно "оплатить" при компиляции? Нет, это всё оплачивается во время работы.
Вы вообще знаете, что к примеру, для игр, используют не просто "сырые" указатели, а вообще, самопальные версии "new/malloc" (ну, понятное дело, с нужной обвязкой)? Так как стандартный - слишком медленно, а упарываться выделением памяти через ассемблер - тут выгода слишком мала. Поэтому выделяется сразу здоровенный кусок памяти, куда уже свой собственный менеджер памяти распихивает ресурсы как ему будет надо и как удобно. Не знали про это? Ну вот. Поэтому использование контейнеров, которые надёжно, дубово и при каждом обращении проверяют "всё ли на месте? Всё ли правильно" при просчете сцены с несколькими миллионами вершин - сделают вас седым раньше срока. Если знаете хозяина gamedev.ru Сержа "wat" то может вспомните, как он пытался воткнуть сцену на тех еще компах (ну как 900 мгц Атлон, зверь на то время был) через контейнеры. Де, это мол, стильно, модно, молодёжно. В итоге сцена которая грузится менее секунды, грузилась более пяти минут. Ну, на отрисовку почти, не влияла, это да. Если только незначительно крайне, порядка сотых, тысячных дельты. Ну это и очевидно, она целиком уже в видеопамяти была в нужном виде. После издевательских шуток на форуме, с контейнерами он для графики, завязал. Как сейчас, не знаю )
Если очень интересно, почешите исходники (они есть) контейнеров. Поучительно. Как и внезапное осознание того, что это шаблоны классов. В которых дофига различных и очень непростых функций, даже в самых примитивных казалось бы, контейнерах, не говоря уже про более сложные виды.
Было бы чудесно, если бы так (приходится ведь списки делать, которые ну нифига не безопасные, и не всегда можешь оптимизировать и так далее). Но нет. Как показывает практика, а она, как известно, критерий истины, работа с контейнерами с большим количеством постоянно "перемешиваемых" данных, знатно уступает "самопальным" вариантам по скорости. Вплоть до двух порядков. Контейнеры, они, ведь разные бывают, ага. И когда начинаешь работать с массивами оных, особенно динамических, то что ты платишь за безопасность и простоту - просто замечательно видно. На глаз, не какие профайлеры не нужны.
Такова грустная селяви использования контейнеров и иже в геймдеве. Во всех остальных направлениях, это чудесный и удобный вариант. Для геймдева, увы, нет. Впрочем, можно наплевать на ЦА (как впрочем, большинство и делает), и перекинуть заботу об этом - на конечного пользователя. Если де игра не запускается, значит, компостер слабоват, и иди его грейди. Де, твои проблемы. Собсно, нынешние проблемы с процессорами вызваны как раз такой практикой, и таким отношением прогеров к ЦА. То, что они сужают круг своих же собственных покупателей, к слову, доходит далеко не до всех. Что очень забавно было бы, если бы не печально (геймдевелопер должен учитывать такие вещи, а не игнорировать, абы было удобнее). Потому как говорит о том, что "набирают по объявлению". И игровой индустрии еще не один год приходить в себя после завала 08 года.
Аллё. Вот тут ты по моему, не по адресу вот вообще. По поводу бута, надо серьезный подход, но не "заплатите нам 101 зелёную бумажку, после чего получите код на разлок. А и да, ваша гарантия превращается в тыкву". Нет. Но всё равно, достаточно серьёзный, что бы вирусняками и эксплойтами не пробить.
Рут же - должен включатся простым переключателем в настройках (да, после 10 окошек с предупреждениями и уточнениями что не передумал). И никак иначе.
Так что нет, не скажу, если только под пытками. Ну или музыку Киркорова, но это относится к видам пыток, так что несчитово.
Про Эпик, если честно, когда Вентиль придумал Стим, и начал превращать это в реальность, я был просто в шоке от радости (тогда и ценник был очень и очень либеральный) и все дела. Ну представь, на одной из моих работ, мы получали чуть менее 7% прибыли на всех. 93% уходило издателю. Да, издатель нёс издержки, риски и прочее (включая даже технику иногда). Да и зарплату платил. Но простите, ладно бы, бедные да сирые (хотя на схожем проекте, мы 10 лет сидели и плюя в потолок тихенько полировали игру, за те же деньги что получили от издателя на круг). А что с проектами класса ААА? Сколько они в карманчик то положили? Я то теперь понимаю, с чего Кармак, всё бабло спустил на создание id Software и плевал на лысины издателей. Особо если вспомнить "чудесные" вещи как с Йоквудом и Пираньями за Готику. В общем, для разработчика стим это на те времена - очередное чудо света. Но, бабло как говорится... Мнда. Поэтому, скажем так, я исходя из революционной справедливости считаю, что чума на все их три дома )))
А, да... Есть такая "забавная фича". Нужные разрешения, прога запрашивает у ведроида, ведроид перенаправляет на гугл сервисы, де, разберись чо за фигня? А тот, почесав тымковку, и сравнив с теми, которые установлены у него по дефолту - пересылает их уже тебе, но не от имени программы, а от имени себя, что логично, он то как прокладка используется. Ну вот и выходит такой казус. Хотя по идее, даже если на фоне запущенного процесса запрос идёт, всё равно должен спросить с ЧЁТКИМ указанием проги, ее версии и так далее. Желательно со ссылками на "что, почему и кто виноват".
У меня схожая картинка, когда лишаю прожек массово доступа в инет (особливо тем, которым он вообще в фиг не впёрся в принципе). Но там сидит гугловская заплатка-баннер, которая сразу начинает вопить "ой-ой-ой, приложение не может работать без доступа к сети". Ага, счаз.
Пока разрешают, очень пока. Так что звучит неплохо, если не брать в расчет это "пока".
Слушай, ведроид стараниями гугла уже помойку напоминает. А они всё не успокаиваются. Оно тебе надо? Если последний вменяемый был седьмым, а за окном призывно машет крылом еще более долбанутый 15ый? Может, лучше, энтузиасты?
Будем честными. Все эти "подвязки" и есть огромное, корявое шапито с пьяными клоунами. И чем раньше их уберут, тем лучше будет. Нам. Не гуглу, конечно же. Так как это гнилое корыто и придумано, что бы пользователи не соскочили. У меня сервисы под гиг озу занимают, из шести. В фоне, тля, в фоне! Как такое можно понять?
Шииикарно. В точечку.
зевает не бегут, а их выдавливают во всякие вьетнамы, индии, африки. Оставляя у себя только самый топ. И дофига прибыли, и никакой головной боли с карбоновым следом и прочей чушью. Я не говорю, что они поступают правильно, я говорю, что вы неверно понимаете причину происходящего, поэтому то ошибаетесь и в следствиях происходящего, неся ересь про бегут, стагнация и прочее. Наоборот всё. В ресторане высокой кухни, брюкву варенную, не подают, это воон там, за углом в конце города.
Вот за такое, руки об батарею отбивать и надро. Контейнеры не просто так в геймдеве не любят использовать, предпочитая рисковать ручным управлением памятью. Накладные расходы просто гигантские. А надёжность, при норм программисте - минимальна.
Грубо говоря, вы в своём примере "облегчили" код на 10%, устранили баг с шансом на миллион, и после утяжелили его в 30 раз на ровном месте. Офигеть оптимизация, никакого проца не хватит.
Геймдев это не ваше. Примеры пишите на офисных прожках. Ну, не на СУБД же, да? xD
Автор "мило" забыл про то, что встроенные шрифты были только под винду и Дайрикс. Остальные, все, даже сейчас, представляют собой банальные спрайты. Что драматично сказывается на скорости вывода на компе. Так как альфу и блендинг никто не отменял порой (для кроссплатформ особенно).
Ну а вращение спрайта, это настолько ходовое, что говорить не обо что. К слову, опять же, до сих пор. Выгодно. Места много, памяти тоже, зачем грузить гпу (в худших случаях цпу)?
Лучше, уж скриптер для писюка, навроде, Луа, сделай. Много кто спасибо скажет. И для дела пригодиться. А то времени тупо на них, не хватает, а они уже до 50% кода занимают + почти всё процессорное время программы. Ну нафиг такие скрипты.
Как по мне, плохой костыль. Так фиг научишься ориентироваться в звездах.
Но если один раз, вот в таких событиях, то сойдёт.
По моему, вот это совсем плохая идея для тех кто не умеет в астрономию. Мицары эти ваши, с денебами, и алькорми наперевес :)