Вы не пробовали использовать другие стратегии сборки мусора?
Мне кажется, необязательно останавливать весь мир каждый кадр — с помощью подсчёта ссылок можно удалять большинство объектов. Для оставшихся циклических использовать алгоритмы типа инкрементальной сборки мусора, которые позволяют делать сборку за несколько вызовов. (хотя, наверно, тогда уж проще взять язык со встроенным сборщиком мусора и не писать велосипеды)
К астероиду надо ещё прилететь, а потом вернуть груз обратно. Думаю, производство на астероидах будет ещё очень долго зависеть от Земли — нужны ракетные двигатели, топливо для них, не говоря уж о куче необходимых вещей типа солнечных батарей, аккумуляторов, процессоров, разных датчиков, производство которых требует много разных веществ и технологий. Так что скорее земляне будут контролировать всё, по крайней мере вначале.
Кстати, чтобы играть на компьютере, управлять именно рукой не обязательно. Есть же связь мозга прямо с компьютером! Не, я понимаю, что для этого человека крайне важно двигать рукой, но эта технология вдобавок может позволить здоровому человеку управлять чем угодно в дополнение к рукам и ногам.
Причём не обязательно вживлять что-нибудь в мозг, в идеале должен быть какой-нибудь шлем или ободок, который считывает активность мозга.
Если ранец с человеком за счёт реактивной силы висит в воздухе 33 секунды, то в невесомости он сможет давать ускорение g=10м/с на продолжении того же времени. За 15 секунд разгона можно достичь скорости 150 м/с — это по 7 секунд на километр пути.
Поигрался с быстрым перематыванием карты туда-сюда, сделал скриншоты.
Карта разбита на квадратные куски, грузится целый кусок целиком, но эти куски, похоже, всегда рисуются как векторные. На первом скриншоте после сильного увеличения на непрогрузившихся частях карты главные дороги есть, но они неправильной ширины.
А ещё довольно коварно сделано: грузящиеся кусочки карты добавляются с плавным изменением прозрачности — на втором скриншоте удалось поймать "полупрозрачное" состояние.
Скриншоты спрятал под спойлер, там разрешение здоровенное.
Мне кажется, там из вектора генерируется обычный тайл, и он рисуется как текстура до тех пор, пока в нём не пропадёт надобность: изменится масштаб или область видимости.
Возможно, останется только одно число. Но это уже не страшно, можно ещё при проходе по массиву поксорить всё, и тогда второе число будет легко получить.
P.S> Не обновил комментарии перед отправкой(
Есть идея, но до решения не получилось довести (а может, и нельзя так).
Скрытый текст
Сделать xor всех элементов массива друг с другом, получим xor различающихся чисел. Я пытался придумать ещё одну операцию, чтобы получить больше информации, и её основе восстановить эти два числа, но в голову ничего не пришло.
Вполне предсказуемо, что кому-нибудь будет наплевать на частную жизнь других людей. Такие люди всегда найдутся, но меня печалит, что даже конституция не является сдерживающим фактором, хотя закон явно ей противоречит.
Статья 23
Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.
У меня зимой при температуре ниже -5 почему-то начинают сильно мёрзнуть нос и щёки. Обычно заматываюсь шарфом, закрывая нос и рот (практически всё лицо), повышенного внимания со стороны окружающих вроде бы нет.
fun test(){ println("it works") }
fun test2() = println("it works too")
fun test3() = {println("surprise!")}
Чтобы вывести "surprise", придётся написать test3()(). Вариант вызова test3() тоже нормально компилируется, только сработает не так, как ожидалось — добавление "лишних" скобочек кардинально меняет логику программы.
Из-за этих граблей переход со скалы на котлин оказался немного болезненным — иногда "по привычке" в объявлении какого-нибудь метода пишу знак равенства, а потом приходится искать ошибки.
Как на уровне байткода будут выглядеть геттеры и сеттеры в Kotlin?
Можно написать пару маленьких программок и декомпилировать.
геттеры и сеттеры будут реализованы как методы getVarName() и setVarName(...)
Но мне синтаксис Scala кажется более простым. В kotlin больше сущностей и ключевых слов.
Например, для переопределения += в scala достаточно создать метод с очевидным названием "+=", причём нет никаких ограничений на тип и количество аргументов — это самый обычный метод, а не какая-то дополнительная сущность.
В kotlin придётся написать в стиле operator fun plusAssign , что не совсем интуитивно (приходится вспоминать, что и как называется), и есть ограничения — метод не может возвращать значение.
Причём в kotlin можно переопределить только небольшой список операторов, а в scala свободы побольше (например, можно определить := или ++=).
На самом деле, scala-метод типа += будет создан с именем "$plus$eq", которое не очень удобно вызывать из java. Было бы идеально, если бы в kotlin стало можно давать методам имена типа "+", которые на самом деле отображались бы в "plus" и.т.п.
Или, например, синтаксис объявления метода:
В scala: def methodName(...) = {...}
В kotlin возможны два варианта — как в scala (со знаком =) и как в java (без него), но эти два способа объявления неэквивалентны друг другу и работают немного по-разному, я однажды кучу времени потратил на поиск такой "особенности" в коде.
Null-safety: интересная штука, но на практике во все публичные методы добавляются проверки для каждого аргумента на null. Мне кажется несколько избыточным — и есть подозрение, что это негативно влияет на производительность. (Там не просто проверка, а вызов статического метода с передачей объекта-параметра и его имени как строки, чтобы можно было кинуть понятное исключение)
Что понравилось в kotlin:
1) inline. Никаких созданий объектов, просто подстановка тела функции.
2) extensions. Тоже удобная штука — и никаких потерь производительности.
В Scala похожая функциональность сделана через implicit-преобразования, из-за чего при вызове создаётся ещё один объект.
У меня нетбук asus 1215n (был куплен около пяти лет назад). Экран 1366*768, тоже 2гб оперативной памяти, внутри нормальный жёсткий диск вместо жалких 32гб. Когда-то прошёл на нём gta san andreas и call of duty. Единственное явное преимущество этого планшета перед нетбуком пятилетней давности — небольшой вес.
Автор очень оптимистичен в подведении итогов. Как на замену ноутбуку на планшет смотреть нельзя:
1) мелкий экран
2) 2 гигабайта памяти это браузер+среда разработки, и среда разработки может тормозить.
3) Про игры лучше вообще не вспоминать. Gta III и call of duty — не то, во что хочется поиграть в 2016 году.
Странная статья. Из описанных двух оптимизаций — отключить смешивание и поменять порядок рисования — ни одна не является чем-то экстраординарным, они никак не связаны с x86 и должны работать везде.
Возможности Graphics Frame Analyzer тоже не раскрыты. Судя по всему, с его помощью многое можно измерить — но в статье даже картинки интерфейса уменьшенные и некликабельные, об особенностях его работы остаётся только догадываться.
Для почты я могу выбрать любой сервис (в том числе тот, который находится в адекватной юрисдикции). С симкой всё сложнее.
Например, Home Premium не поддерживает больше 16gb ram.
Мне кажется, необязательно останавливать весь мир каждый кадр — с помощью подсчёта ссылок можно удалять большинство объектов. Для оставшихся циклических использовать алгоритмы типа инкрементальной сборки мусора, которые позволяют делать сборку за несколько вызовов. (хотя, наверно, тогда уж проще взять язык со встроенным сборщиком мусора и не писать велосипеды)
Причём не обязательно вживлять что-нибудь в мозг, в идеале должен быть какой-нибудь шлем или ободок, который считывает активность мозга.
Карта разбита на квадратные куски, грузится целый кусок целиком, но эти куски, похоже, всегда рисуются как векторные. На первом скриншоте после сильного увеличения на непрогрузившихся частях карты главные дороги есть, но они неправильной ширины.
А ещё довольно коварно сделано: грузящиеся кусочки карты добавляются с плавным изменением прозрачности — на втором скриншоте удалось поймать "полупрозрачное" состояние.
Скриншоты спрятал под спойлер, там разрешение здоровенное.
P.S> Не обновил комментарии перед отправкой(
Статья 23
Чтобы вывести "surprise", придётся написать test3()(). Вариант вызова test3() тоже нормально компилируется, только сработает не так, как ожидалось — добавление "лишних" скобочек кардинально меняет логику программы.
Из-за этих граблей переход со скалы на котлин оказался немного болезненным — иногда "по привычке" в объявлении какого-нибудь метода пишу знак равенства, а потом приходится искать ошибки.
Можно написать пару маленьких программок и декомпилировать.
геттеры и сеттеры будут реализованы как методы
getVarName()иsetVarName(...)Но мне синтаксис Scala кажется более простым. В kotlin больше сущностей и ключевых слов.
Например, для переопределения
+=в scala достаточно создать метод с очевидным названием "+=", причём нет никаких ограничений на тип и количество аргументов — это самый обычный метод, а не какая-то дополнительная сущность.В kotlin придётся написать в стиле
operator fun plusAssign, что не совсем интуитивно (приходится вспоминать, что и как называется), и есть ограничения — метод не может возвращать значение.Причём в kotlin можно переопределить только небольшой список операторов, а в scala свободы побольше (например, можно определить := или ++=).
На самом деле, scala-метод типа += будет создан с именем "$plus$eq", которое не очень удобно вызывать из java. Было бы идеально, если бы в kotlin стало можно давать методам имена типа "+", которые на самом деле отображались бы в "plus" и.т.п.
Или, например, синтаксис объявления метода:
В scala:
def methodName(...) = {...}В kotlin возможны два варианта — как в scala (со знаком =) и как в java (без него), но эти два способа объявления неэквивалентны друг другу и работают немного по-разному, я однажды кучу времени потратил на поиск такой "особенности" в коде.
Null-safety: интересная штука, но на практике во все публичные методы добавляются проверки для каждого аргумента на null. Мне кажется несколько избыточным — и есть подозрение, что это негативно влияет на производительность. (Там не просто проверка, а вызов статического метода с передачей объекта-параметра и его имени как строки, чтобы можно было кинуть понятное исключение)
Что понравилось в kotlin:
1) inline. Никаких созданий объектов, просто подстановка тела функции.
2) extensions. Тоже удобная штука — и никаких потерь производительности.
В Scala похожая функциональность сделана через implicit-преобразования, из-за чего при вызове создаётся ещё один объект.
В win7 можно в проводнике в address-bar ввести «cmd», нажать enter и консолька откроется из текущей папки. Или Вы что-то другое имели ввиду?
Автор очень оптимистичен в подведении итогов. Как на замену ноутбуку на планшет смотреть нельзя:
1) мелкий экран
2) 2 гигабайта памяти это браузер+среда разработки, и среда разработки может тормозить.
3) Про игры лучше вообще не вспоминать. Gta III и call of duty — не то, во что хочется поиграть в 2016 году.
Возможности Graphics Frame Analyzer тоже не раскрыты. Судя по всему, с его помощью многое можно измерить — но в статье даже картинки интерфейса уменьшенные и некликабельные, об особенностях его работы остаётся только догадываться.