Я, в целях экономии ресурса ssd, сделал хардлинк папки с кэшами gradle на рам-диск. На рам-диске, естественно, fat32. Но в один прекрасный момент, после очередного обновления системы сборки, собственно сборка стала завершаться с непонятной ошибкой. В поисках решения, после долгого копания по форумам, кто-то где-то вскользь упомянул, что такая ошибка возникает, если студия стоит не на ntfs разделе (дело под виндой, да). Это оно, подумал я и, скрепя сердце, отказался от линка на рам-диск и fat32 для кэшей gradle. Прошел год или что-то около, и Android Studio, после очередного обновления, стала наглухо зависать при сборке с вероятностью >50%. Я думаю, это из-за того, что intermediates проекта я таки держал на рам-диске с fat32. Я даже багрепорт накатал, ответили, что проблема известная. Где-то месяц промучался и, о чудо, в очередном обновлении (bumblebee) всё починили, даже сборку с кэшем gradle на fat32. Ума не приложу, как можно умудриться сделать так хреново работу с файлами в кроссплатформенном (на минуточку) проекте, что всё висло на "неправильной" файловой системе.
Если перенести brave в папку не по умолчанию, то автообновление сразу ломается. Замена путей в реестре не помогает (да, речь о windows). Уж не знаю, зачем так жестко brave прибит гвоздями к program files.
А не говорят ли фейлы (о чем, собственно, статья) в попытке его измерить, что способ(ы) ошибочны? Я вообще сомневаюсь, что крутильные весы измеряют G. Просто все крутильные весы для измерения G плюс/минус показывают G, потому что те, что показывают что-то другое, просто отбраковываются. Эксперементаторы делают сотню опытов чтобы получить на 101-м наконец G хотя бы приблизительно. А если громко скажут, что G нихрена не получается, в научном обществе их заминусуют. Например, как этот коммент.
Значение G ни на что не влияет. Погодите минусовать, сейчас поясню.
Взгляните на формулу: F=G(m1*m2)/(r^2)
Предположим, что G на 10% больше (или меньше, не важно — просто другое), чем принято считать. Как это проверить? Никак. В пределах гравитационного колодца Земли проверить не выйдет — тут вторую массу всегда полагают нулевой и оперируют т.н. напряженностью гравитационного поля (то, которое у поверхности = 9.8mc^2), по умолчанию и без какого либо объяснения считая, что пробное тело никак на него не влияет и является точечным. Если проверять через небесную механику, то просто на соответствующую величину измените массу тел и формула сойдется с новой G. Никто ведь точно не знает массы звезд, планет и их спутников. Остается вариант с проверкой траекторий посылаемых аппаратов. Но опять же, масса аппарата известна, а масса планеты, вблизи которой наблюдается искривление траектории — нет. Напомню — мы выводим G из формулы и в такой ситуации масса планеты нам неизвестна. Текущее официальное значение G — просто выглядит правдоподобным, не более.
Сделаю осторожный вывод: гравитация вовсе не то чем кажется.
Ну да, в лоб без нужных знаний не выйдет. У меня была чудо-книжка, я ее где-то по почте заказывал и мне прислали, ныне утеряна, к сожалению. Так вот в той книжке были расписаны все команды Z80, включая недокументированные, и то, сколько они тактов выполняются. Вот я и высчитал такты, требуемые для записи/чтения на ленту. Нужо было с точностью до такта всё аккуратно сделать, иначе не заработает.
Ясно, издержки несоврешенства технологии на этапе проектирования. Немного выиграли в аппаратной части, но проиграли на круг в общей производительности в играх.
если делать таблицу Y -> Addr, то это целых 384 байта. Это охренеть как много для спектрума, но, видимо многие так делали. А куда деваться.
К примеру, для кода и данных игры максимум доступной памяти — 42240 байт. Ну экзотику, когда код в видеопамяти и закрыт аттрибутами, я не рассматриваю. Так делали редко. Если использовать backbuffer, да потратиться на такие вот таблицы (например, еще обязательно нужна была таблица переходов с прерывания по таймеру 50 раз в секунду — 256 байт, ну или там, таблица синусов, таблица умножений, таблица квадратных корней, много всяких таблиц), то на графику и код оставалось с гулькин нос. Впрочем, было интересно.
Так устроена видеопамять у спектрума. Чем руководствовался ее разработчик, сказать сложно. Но вряд ли это были соображения производительности.
Устроена так: 32 байта на горизонтальную линию — 256 бит. Каждые следующие 32 байта на экране отображались ниже на 8 пикселей. И так восмь раз. Затем вторая скан линия и снова 8 раз через 8 пикселей вниз. Ровно 2kb на блок, занимающий ровно одну треть экрана. И таких блоков 3 штуки. Итого 6144 байта. Это была битовая матрица. Далее идут 768 байт аттрибутов, каждый байт отвечал за матрицу 8x8 пикселей, указывая, в какой цвет красить нули, а в какой единицы на битовом поле.
Очень заморочено. В ПЗУ есть кусок кода, который вычисляет в этой схеме адрес следующего байта относительно произвольного, который на экране расположен на один пиксель ниже. Как сейчас помню, эта операция занимала 191 такт. Сделать это быстрее мне тогда не удалось. Между тем такая операция очень важна при рисовании спрайтов в произвольной Y координате в играх. Вобщем, мы крутились как могли.
Из моего коммента ниже видно, что между полупериодами сигнала логического нуля 855 тактов. Я щас не помню кнкретных цифр, но на саму загрузку требуется порядка 50 тактов на каждом полупериоде. Остальные 800 процессор просто впустую ожидает изменения бита сигнала с ленты на порту. Т.е. есть где развернуться. Я в своё время сделал загрузчик, который картинку в процессе загрузки выдвигал с правого края экрана. Т.е. скролинг экрана во время загрузки. TF-COPY (если я правильно помню название) — программа для копирования, могла загружать в среднем до 60kb в память 48k байтового спектрума. Т.е. в процессе загрузки в реальном времени эта программа осуществляла сжатие. Вобщем, многие разработчики создавали свои загрузчики.
В те древние времена я про интернет даже и не слышал еще, поэтому инфу часто приходилось добывать реверс-инженерингом ПЗУ и тщательно всё записывать. На бумагу. Недавно обнаружил в закромах старую тетрадку с такими записями. Вот, например, формат записи на ленту.
Длительности полупериодов сигнала указаны в тактах 3.5 Mhz-вого Z80. Эта инфа позволяла писать кастомные загрузчики с ленты, которые в процессе загрузки успевали делать что-то еще, помимо самой загрузки. Ну типа загрузчика титульного скрина в krackout из видео, что в статье.
То что этот постулат не работает, можно легко убедиться, если взглянуть на пару Земля-Луна в момент, когда линия Земля-Луна перпендикулярна направлению движения Земли вокруг солнца. Лазерный луч, отправленый на Луну и вернувшийся на Землю, отразившись от уголкового отражателя, возвращается в точку на Земле на расстоянии более 70 км от точки излучения (учитываем время «пинга» и орбитальную скорость Земли)… Да, так было бы, если бы второй постулат работал. Но нет, луч возвращается срого к источнику.
Те же, для кого «с СТО всё хорошо» т.к. «GPS», просто допустите на минуту, что там не время по другому идет, а частота квантовых осциляторов, на основе которых работают часы GPS отличается. Не спишите приравнивать скорость хода времени и частоты колебаний квантовых осциляторов. Это явления очень разного порядка и пока нет доказательств, что это одно и тоже.
«барионное число и лептонное число»
эти числа совсем не объясняют, почему в наблюдаемой вселенной в наличии только материя, не так ли? Следовательно, это просто какие-то «красивые» названия непойми чего, как впрочем почти всё в стандартной модели.
Я всего лишь предлагал взлянуть на проблему шире. Беда всех, кто изучает микромир — святая вера в непогрешимость стандартной модели. Да, я знаю, что это лучшее, что смогло изобрести человечество. Но может быть проблема вообще в выбраном направлении мысли. Ведь стандартная модель — всего лишь попытка посфактум объяснить наблюдаемое.
Возможно, что антиматерия — это просто обычная материя но в ней временно изменен какой-то внутрениий параметр. Т.е. то, что ученые принимают за антиматерию, как самостоятельную сущность, на самом деле таковой не является. Позитрон — это электрон, в котором что-то изменено и он временно приобрел положительный заряд. Т.е. заряд — это следствие чего-то более фундоментального, что изменено в том же антинейтроне относительно нейтрона. И это некий параметр материи, а не ее неизменный структурный элемент. И изменяем его мы в своих ускорителях, а в естественной среде космоса этот параметр возвращается к своему нормальному состоянию.
По сути верно.
Более того, есть один исследователь, который эту идею вывел на уровень формул. Этого исследователя сильно не любят ортодоксы, да и я рискую отхватить минусов, за то пишу про него. Однако, если внимаетльно и без предвзятости ознакомиться с его работами, можно найти много интересного и пищу для размышлений. Я говорю о А. Гришаеве и его «Новой Физике». newfiz.info
Очень рекомендую прочесть его книгу «Этот цифровой физический мир» (есть на сайте)
В Apple всё продумали. Это ни разу не косяк. Куча телефонов выводится из употребления, а все претензии разбиваются о железный аргумент, мол, забота о безопасности. Прекрасно!
Сначала подумал, что плохой кабель может замкнуться, но в статье про замыкание кабеля ничего не сказано. Тогда что? У него слишком маленькая/большая емкость/индуктивность? Чем же эти несколько медных жил могут убить железо? Большой ток? А при чем тут кабель? Ограничитель тока теперь в кабель встраивают? Я так отстал от прогресса?
Это бизнес. Ничего личного. Apple прекрасно все расчитала. Из употребления выведена куча телефонов + люди будут опасаться чинить свои телефоны у неофициалов + в неокрепших умах осядет очередная установка «Apple забоится о нашей безопасности».
Я проработал в геймдеве больше 10 лет. Мне повезло работать в небольшой команде. Это действительно круто, когда вся команда, как семья. В тоже время — это довольно нервная работа, особенно, если ты программист.
Согласен с автором оригинального текста — инди разработка лучше крупной компании. В большой компании ты маленький винтик. Это ощущение губительно для творчества. А разработка игр — это больше творчество, чем просто работа.
Я, в целях экономии ресурса ssd, сделал хардлинк папки с кэшами gradle на рам-диск. На рам-диске, естественно, fat32. Но в один прекрасный момент, после очередного обновления системы сборки, собственно сборка стала завершаться с непонятной ошибкой. В поисках решения, после долгого копания по форумам, кто-то где-то вскользь упомянул, что такая ошибка возникает, если студия стоит не на ntfs разделе (дело под виндой, да). Это оно, подумал я и, скрепя сердце, отказался от линка на рам-диск и fat32 для кэшей gradle. Прошел год или что-то около, и Android Studio, после очередного обновления, стала наглухо зависать при сборке с вероятностью >50%. Я думаю, это из-за того, что intermediates проекта я таки держал на рам-диске с fat32. Я даже багрепорт накатал, ответили, что проблема известная. Где-то месяц промучался и, о чудо, в очередном обновлении (bumblebee) всё починили, даже сборку с кэшем gradle на fat32. Ума не приложу, как можно умудриться сделать так хреново работу с файлами в кроссплатформенном (на минуточку) проекте, что всё висло на "неправильной" файловой системе.
Если перенести brave в папку не по умолчанию, то автообновление сразу ломается. Замена путей в реестре не помогает (да, речь о windows). Уж не знаю, зачем так жестко brave прибит гвоздями к program files.
Взгляните на формулу: F=G(m1*m2)/(r^2)
Предположим, что G на 10% больше (или меньше, не важно — просто другое), чем принято считать. Как это проверить? Никак. В пределах гравитационного колодца Земли проверить не выйдет — тут вторую массу всегда полагают нулевой и оперируют т.н. напряженностью гравитационного поля (то, которое у поверхности = 9.8mc^2), по умолчанию и без какого либо объяснения считая, что пробное тело никак на него не влияет и является точечным. Если проверять через небесную механику, то просто на соответствующую величину измените массу тел и формула сойдется с новой G. Никто ведь точно не знает массы звезд, планет и их спутников. Остается вариант с проверкой траекторий посылаемых аппаратов. Но опять же, масса аппарата известна, а масса планеты, вблизи которой наблюдается искривление траектории — нет. Напомню — мы выводим G из формулы и в такой ситуации масса планеты нам неизвестна. Текущее официальное значение G — просто выглядит правдоподобным, не более.
Сделаю осторожный вывод: гравитация вовсе не то чем кажется.
К примеру, для кода и данных игры максимум доступной памяти — 42240 байт. Ну экзотику, когда код в видеопамяти и закрыт аттрибутами, я не рассматриваю. Так делали редко. Если использовать backbuffer, да потратиться на такие вот таблицы (например, еще обязательно нужна была таблица переходов с прерывания по таймеру 50 раз в секунду — 256 байт, ну или там, таблица синусов, таблица умножений, таблица квадратных корней, много всяких таблиц), то на графику и код оставалось с гулькин нос. Впрочем, было интересно.
Устроена так: 32 байта на горизонтальную линию — 256 бит. Каждые следующие 32 байта на экране отображались ниже на 8 пикселей. И так восмь раз. Затем вторая скан линия и снова 8 раз через 8 пикселей вниз. Ровно 2kb на блок, занимающий ровно одну треть экрана. И таких блоков 3 штуки. Итого 6144 байта. Это была битовая матрица. Далее идут 768 байт аттрибутов, каждый байт отвечал за матрицу 8x8 пикселей, указывая, в какой цвет красить нули, а в какой единицы на битовом поле.
Очень заморочено. В ПЗУ есть кусок кода, который вычисляет в этой схеме адрес следующего байта относительно произвольного, который на экране расположен на один пиксель ниже. Как сейчас помню, эта операция занимала 191 такт. Сделать это быстрее мне тогда не удалось. Между тем такая операция очень важна при рисовании спрайтов в произвольной Y координате в играх. Вобщем, мы крутились как могли.
Длительности полупериодов сигнала указаны в тактах 3.5 Mhz-вого Z80. Эта инфа позволяла писать кастомные загрузчики с ленты, которые в процессе загрузки успевали делать что-то еще, помимо самой загрузки. Ну типа загрузчика титульного скрина в krackout из видео, что в статье.
Те же, для кого «с СТО всё хорошо» т.к. «GPS», просто допустите на минуту, что там не время по другому идет, а частота квантовых осциляторов, на основе которых работают часы GPS отличается. Не спишите приравнивать скорость хода времени и частоты колебаний квантовых осциляторов. Это явления очень разного порядка и пока нет доказательств, что это одно и тоже.
эти числа совсем не объясняют, почему в наблюдаемой вселенной в наличии только материя, не так ли? Следовательно, это просто какие-то «красивые» названия непойми чего, как впрочем почти всё в стандартной модели.
Я всего лишь предлагал взлянуть на проблему шире. Беда всех, кто изучает микромир — святая вера в непогрешимость стандартной модели. Да, я знаю, что это лучшее, что смогло изобрести человечество. Но может быть проблема вообще в выбраном направлении мысли. Ведь стандартная модель — всего лишь попытка посфактум объяснить наблюдаемое.
Более того, есть один исследователь, который эту идею вывел на уровень формул. Этого исследователя сильно не любят ортодоксы, да и я рискую отхватить минусов, за то пишу про него. Однако, если внимаетльно и без предвзятости ознакомиться с его работами, можно найти много интересного и пищу для размышлений. Я говорю о А. Гришаеве и его «Новой Физике». newfiz.info
Очень рекомендую прочесть его книгу «Этот цифровой физический мир» (есть на сайте)
Согласен с автором оригинального текста — инди разработка лучше крупной компании. В большой компании ты маленький винтик. Это ощущение губительно для творчества. А разработка игр — это больше творчество, чем просто работа.