В данном случае нужно просто не покупать подобные видео игры, либо подавать в суд если игра перестала работать и вам при покупке в явной форме не объяснили, что она имеет ограниченный срок действия.
Тоже пробовал bun и сравнивал с nodejs, после того как увидел рекламу, что bun якобы быстрее. Собственно, runtime bun может работать и быстрее старых версий ноды, но с версии nodejs@12-14 все преимущество сходит на нет, последние версии ноды уже работают быстрее bun. Поискав по форумам, нашел информацию, что якобы bun быстрее для server-side-rendering приложений, вообщем, какие-то оправдания, которые толком нельзя протестировать. Для себя я сделал вывод, что заявления о более высокой скорости bun, не соответствуют действительности.
Bun написан на языке Zig. Это альтернатива C++ и Rust. Zig предоставляет низкоуровневые возможности для ручной работы с памятью, за счет чего появляется возможность оптимизировать вообще все элементы платформы.
Если хотите увеличить производительность, можно использовать WebAssembly, прекомпиляция и низкоуровневая строгая типизация могут дать понятное преимущество при грамотном использовании, это не какой-то там Zig с помощью которого разработчики bun якобы творят чудеса оптимизации.
Почти любые профессиональные спортсмены имеют свои проблемы, но это не значит, что спорт в целом вреден и полезно лежать всю жизнь на диване. Нужно знать про эти проблемы и чем они конкретно могут быть вызваны, чтобы минимизировать негативный эффект. По велосипеду, если вы не занимаетесь этим профессионально, это, как правило, неправильно подобранные компоненты, неправильная настройка, неправильная посадка, езда итп.
30 января 2024 года Qiwi объявила о продаже своих российских активов гонконгской компании Fusion Factor Fintech Limited за 23,75 млрд рублей. Компания-покупатель принадлежит экс-CEO Qiwi Андрею Протопопову, который после сделки покинул свой пост и совет директоров, но продолжил руководить бизнесом АО «Киви», включающим российские активы компании.
Сделка состоялась в кредит – в первые четыре месяца необходимо было выплатить половину суммы (11+ млрд), а остаток за ближайшие 4 года.
Но как мы понимаем, сейчас активы банка уже не совсем активы банка.
Как мне кажется - это схема вывода российских активов Qiwi за рубеж, потихоньку бы все продали, что осталось в России, возможно, кого-нибудь бы кинули. ЦБ просто сработал на опережение, чтобы потом не пришлось расплачиваться с бывшими клиентами банка из своего кармана. А предлог - может и надуманный, потому что официально тут вроде как все чисто, не запрещено же законом самому себе зарубеж компанию продавать в долг.
Мечта состоит в том, что общество и правительства стран утвердят бесплатное ПО как общественное благо, которым оно определённо является, и будут финансировать его должным образом. А также исправят здравоохранение, обеспечат доступное жильё, общественный транспорт, государственную социальную поддержку и прочее, и прочее…
Автор какбы намекает, что гос. система должна быть выстроена таким образом, чтобы этот труд оплачивался, т.е. регулятор должен направлять часть средств на OpenSource проекты, как, например, сейчас делается с автодорогами, или городскими службами.
Мы должны принять мир как есть – даже если он не соответствует нашим желаниям. Это означает, что нам следует поддержать идею оплаты труда мейнтейнеров. Слишком уж часто я встречаю аргументы вроде: «Частные компании не должны оплачивать труд мейнтейнеров, так как это дело правительства». Звучит, безусловно, прекрасно – но правительства этого не делают! В итоге весь аргумент сводится к форме «Труд мейнтейнеров опенсорсных проектов оплачиваться не должен». С этим я не могу согласиться.
Государство показывает на частный бизнес, частный бизнес показывает на государство, в итоге разработчики OpenSource вынуждены крутится как-то сами.
Лично мое мнение, возможно мы и придем к этому со временем. Мне кажется тут больше вопрос в полезности, не любой opensource одинаково полезен и нужен обществу. А те, что полезны, становятся популярны и находят финансирование, иначе уходят в лету, это нормальный процесс.
В мире WebGL есть ограничения на максимальный размер текстур. Зависят от устройств. Текстуры в 2048px сейчас поддерживают 100% устройств и браузеров. Бывают и больше, хотя я бы считал 2048px за безопасный в коммерции предел, где не будет сюрпризов на телефонах. Но даже не беря в расчет теоретические пределы - не обязательно же идти в крайности и все в одну текстуру собирать. Можно найти баланс и собирать кусками по 256x256px например.
Верно, еще есть ограничение на количество одновременно используемых текстур в webgl, у меня это 16, а бывает и 8. Так что хранить нарезанные текстуры в webgl не получится вообще. Можно, наверное, держать их в памяти js и на каждый цикл передавать их в webgl, дробя вызовы отрисовки по достижении лимита. Фактический, все это будет попросту программным укрупнением ячеек, с нагрузкой в ввиде большого количества изображений в памяти и доп. вызовов отрисовки.
Сразу возникает вопрос: вы же не делаете это каждый кадр?
Да, именно так, каждый кадр идет перерисовка всего.
Файл не меняется. Все, что на карте зафиксировано на одном месте, может быть собрано в текстуры больше, чем 16x16 пикселей. И переиспользовано. Для игровой логики там могут быть и земля, и стены, и десятки тысяч формально разных областей пространства. А картинка для фона - это картинка для фона. Она своей жизнью может жить. Ее даже собрать можно заранее. В реальном времени нужно что-то делать только с текстурами для меняющихся объектов, которых в зафиксированном файле по определению нет.
У меня есть тестовая карта с ячейками 32х32, при той же детализации, она работает намного быстрее, чем с меньшими ячейками, т.к. их банально меньше. Так что да - в укрупнении ячеек есть смысл. Если собрать заранее фон и как текстуру держать его в памяти, передавая на отрисовку только координаты смещения, работу в js можно сократить - это тоже верно. Но в обоих случаях, в памяти придется постоянно держать гораздо большее число графических объектов, что может сказаться на производительности не в лучшую сторону. Если взять из примера карту 200х200 ячеек по 16 пикселей, получится текстура 3200 х 3200 пикселей, не знаю как будет справляться webgl.
Но ведь у вас карта из квадратных ячеек, и детектор коллизий с самой простой логикой должен проверять столкновения только того, что подвигалось, и только с тем, что есть в соседних 8 ячейках. Даже не в 8, а только в тех, в сторону которых этот объект подвигался.
Да верно, но ячейки на экране, а программно объекты хранятся в виде массива, чтобы знать какие из ячеек находятся поблизости нужна другая структура данных, например, дерево или граф, а массив приходится перебирать полностью, или есть другой способ?
Call to power, тоже, кстати, очень интересная серия. Там есть несколько уникальных механик, помимо постройки городов и туннелей под водой. Во-первых - это бои, отряды дерутся не по одному, а пачками отрядов и чем-то напоминают бои в Heroes, или даже в Disciples, т.к. они не перемещаются во время боя. Во вторых - торговля, прокладывается торговый маршрут на карте, который приносит прибыль. Будучи в войне, маршруты врагов можно уничтожать, или грабить. И еще одна интересная механика - это улучшения местности. Вместо отдельного отряда - рабочий, как во всех остальных частях, тут есть отчисления с производства на общественные нужды, чем больше отчисления, тем медленнее возводятся постройки и отряды в городах. Накопленные очки можно потом потратить на улучшение местности, намного удобней чем управлять армией рабочих.
Прежде чем начнем, не забудьте уволить вашего CTO/Тимлида, если вы до сих пор не используете Flutter.
Без сомнения flutter/dart - замечательные инструменты. Но основная причина использования/неиспользования того или иного инструмента в организации, является экономическая целесообразность. Следом пойдут, распространенность инструмента, количество сторонних пакетов и количество специалистов в данном сегменте, т.е. кадровый вопрос. Конечно замечательно, что можно переучить, к примеру, nodejs специалиста на flutter/dart за полгода/год, но зачем компания будет за это платить?
В частном секторе тянуть оптоволокно к каждому дому - невыгодно в любом случае. Я пользуюсь беспроводным с антенной - вполне хватает, даже для видео связи. И цена как в городе.
Верно. За городом проблем меньше, снизу/сверху никого нет, парковочного места - сколько угодно, шумность решается утолщением стен и окон, это же и уменьшение платежа по отоплению зимой.
Все сразу. И не растерять навыки и научится чем-нибудь, и написать, что-нибудь интересное.
Не хотелось противопоставлять свой проект другим js-движкам, внешне(с точки зрения пользователя) все очень похоже. Производительность также, наверняка, похожая. Я делал эксперименты со слоями, web assembly, ООП и приватности, про это писал.
Ожидал увидеть минусы языка, а тут "питонистам мало платят". Если вы хотите побольше денег, лучше изучать, что-то с финансами, хорошо зарабатывают банковские служащие - кредитные специалисты, брокеры, можно просто зарабатывать на бирже торгуя акциями и учится много не нужно и делать тоже - следите за новостями, покупайте подешевле, продавайте подороже, зачем страдать изучая то, что вам не интересно и не по душе.
Врятли вы будете знать причину по которым женатый человек не носит кольцо. Тут нужно проводить дополнительное исследование и найти коррелирующие признаки женатости/неженатости помимо кольца, тогда вы сможете улучшить первоначальную оценку.
В данном случае нужно просто не покупать подобные видео игры, либо подавать в суд если игра перестала работать и вам при покупке в явной форме не объяснили, что она имеет ограниченный срок действия.
Тоже пробовал bun и сравнивал с nodejs, после того как увидел рекламу, что bun якобы быстрее. Собственно, runtime bun может работать и быстрее старых версий ноды, но с версии nodejs@12-14 все преимущество сходит на нет, последние версии ноды уже работают быстрее bun. Поискав по форумам, нашел информацию, что якобы bun быстрее для server-side-rendering приложений, вообщем, какие-то оправдания, которые толком нельзя протестировать. Для себя я сделал вывод, что заявления о более высокой скорости bun, не соответствуют действительности.
Если хотите увеличить производительность, можно использовать WebAssembly, прекомпиляция и низкоуровневая строгая типизация могут дать понятное преимущество при грамотном использовании, это не какой-то там Zig с помощью которого разработчики bun якобы творят чудеса оптимизации.
Почти любые профессиональные спортсмены имеют свои проблемы, но это не значит, что спорт в целом вреден и полезно лежать всю жизнь на диване. Нужно знать про эти проблемы и чем они конкретно могут быть вызваны, чтобы минимизировать негативный эффект. По велосипеду, если вы не занимаетесь этим профессионально, это, как правило, неправильно подобранные компоненты, неправильная настройка, неправильная посадка, езда итп.
Стоит учесть, что когда коммунальщики узнают, что вы используйте электричество для майнинга, вам поменяют тариф.
HyperLoop Илона Маска забыли упомянуть.
При неизменном техпроцессе такое врятли возможно. Чип либо мощный, либо энергоэффективный, для этого и линейки разные выпускают i3, i5, i7, i9.
Верно, это как с криптой говорят: "деньги ваши, пока ключи у вас".
Как мне кажется - это схема вывода российских активов Qiwi за рубеж, потихоньку бы все продали, что осталось в России, возможно, кого-нибудь бы кинули. ЦБ просто сработал на опережение, чтобы потом не пришлось расплачиваться с бывшими клиентами банка из своего кармана. А предлог - может и надуманный, потому что официально тут вроде как все чисто, не запрещено же законом самому себе зарубеж компанию продавать в долг.
Автор какбы намекает, что гос. система должна быть выстроена таким образом, чтобы этот труд оплачивался, т.е. регулятор должен направлять часть средств на OpenSource проекты, как, например, сейчас делается с автодорогами, или городскими службами.
Государство показывает на частный бизнес, частный бизнес показывает на государство, в итоге разработчики OpenSource вынуждены крутится как-то сами.
Лично мое мнение, возможно мы и придем к этому со временем. Мне кажется тут больше вопрос в полезности, не любой opensource одинаково полезен и нужен обществу. А те, что полезны, становятся популярны и находят финансирование, иначе уходят в лету, это нормальный процесс.
Верно, еще есть ограничение на количество одновременно используемых текстур в webgl, у меня это 16, а бывает и 8. Так что хранить нарезанные текстуры в webgl не получится вообще. Можно, наверное, держать их в памяти js и на каждый цикл передавать их в webgl, дробя вызовы отрисовки по достижении лимита. Фактический, все это будет попросту программным укрупнением ячеек, с нагрузкой в ввиде большого количества изображений в памяти и доп. вызовов отрисовки.
Да, именно так, каждый кадр идет перерисовка всего.
У меня есть тестовая карта с ячейками 32х32, при той же детализации, она работает намного быстрее, чем с меньшими ячейками, т.к. их банально меньше. Так что да - в укрупнении ячеек есть смысл. Если собрать заранее фон и как текстуру держать его в памяти, передавая на отрисовку только координаты смещения, работу в js можно сократить - это тоже верно. Но в обоих случаях, в памяти придется постоянно держать гораздо большее число графических объектов, что может сказаться на производительности не в лучшую сторону. Если взять из примера карту 200х200 ячеек по 16 пикселей, получится текстура 3200 х 3200 пикселей, не знаю как будет справляться webgl.
Да верно, но ячейки на экране, а программно объекты хранятся в виде массива, чтобы знать какие из ячеек находятся поблизости нужна другая структура данных, например, дерево или граф, а массив приходится перебирать полностью, или есть другой способ?
Call to power, тоже, кстати, очень интересная серия. Там есть несколько уникальных механик, помимо постройки городов и туннелей под водой. Во-первых - это бои, отряды дерутся не по одному, а пачками отрядов и чем-то напоминают бои в Heroes, или даже в Disciples, т.к. они не перемещаются во время боя. Во вторых - торговля, прокладывается торговый маршрут на карте, который приносит прибыль. Будучи в войне, маршруты врагов можно уничтожать, или грабить. И еще одна интересная механика - это улучшения местности. Вместо отдельного отряда - рабочий, как во всех остальных частях, тут есть отчисления с производства на общественные нужды, чем больше отчисления, тем медленнее возводятся постройки и отряды в городах. Накопленные очки можно потом потратить на улучшение местности, намного удобней чем управлять армией рабочих.
Без сомнения flutter/dart - замечательные инструменты. Но основная причина использования/неиспользования того или иного инструмента в организации, является экономическая целесообразность. Следом пойдут, распространенность инструмента, количество сторонних пакетов и количество специалистов в данном сегменте, т.е. кадровый вопрос. Конечно замечательно, что можно переучить, к примеру, nodejs специалиста на flutter/dart за полгода/год, но зачем компания будет за это платить?
В частном секторе тянуть оптоволокно к каждому дому - невыгодно в любом случае. Я пользуюсь беспроводным с антенной - вполне хватает, даже для видео связи. И цена как в городе.
Верно. За городом проблем меньше, снизу/сверху никого нет, парковочного места - сколько угодно, шумность решается утолщением стен и окон, это же и уменьшение платежа по отоплению зимой.
Да. 4х-ядерный Xeon, 4ГБ оп, Ubuntu, 27 дюймовый экран.
В карте 800х800 не пустых ячеек, это 640 000 объектов для перебора, плюс для стен(я думаю их больше 10 000) считаются колизии.
Все сразу. И не растерять навыки и научится чем-нибудь, и написать, что-нибудь интересное.
Не хотелось противопоставлять свой проект другим js-движкам, внешне(с точки зрения пользователя) все очень похоже. Производительность также, наверняка, похожая. Я делал эксперименты со слоями, web assembly, ООП и приватности, про это писал.
Ожидал увидеть минусы языка, а тут "питонистам мало платят". Если вы хотите побольше денег, лучше изучать, что-то с финансами, хорошо зарабатывают банковские служащие - кредитные специалисты, брокеры, можно просто зарабатывать на бирже торгуя акциями и учится много не нужно и делать тоже - следите за новостями, покупайте подешевле, продавайте подороже, зачем страдать изучая то, что вам не интересно и не по душе.
Врятли вы будете знать причину по которым женатый человек не носит кольцо. Тут нужно проводить дополнительное исследование и найти коррелирующие признаки женатости/неженатости помимо кольца, тогда вы сможете улучшить первоначальную оценку.