Александр Семенов shiru8bit

Заглянуть ему в голову нельзя

Это точка зрения представителя современного человечества, который не представляет иных возможностей устройства мира. Но когда речь идёт о внеземных цивилизациях — не факт. Возможно, одни технологически развиты гораздо больше, и для них никаких секретов в головах других нет. Возможно, другие так устроены, что для них мысли других себе подобных, а может и не только, открыты как собственные. Даже в не самом отдалённом будущем человечества перспектива 'заглянуть в голову' себе подобных вполне обозначена. Опять же, не факт, что одни в принципе могут представлять угрозу для других, мыслить категориями сотрудничества или вражды, и так далее. То есть, все спекуляции в этой теме следуют из текущего устройства конкретно нашего вида, и валидны только для взаимодействия с очень похожими цивилизациями.

Лично мне кажется, что из основных возможностей — других нет, другие похожи, другие совершенно другие — третья наиболее вероятна, и тогда любой контакт (даже понимание факта контакта) очень существенно перевернёт представления обоих сторон об очень многом.

Повторяюсь более развёрнуто: научные публикации, заявляющие об успехах в деле обучения обезьян языку жестов, подвергают научной же критике со времён первых публикаций и до сих пор. Это более-менее проверяемое утверждение, в отличие 'ну как бы'.

Учили — факт, научили — не факт. Эту тему с давних пор сопровождает критика исследований и результатов, в которой успешность обучения подвергается сомнению.

Непреодолимой пропасти нет, за исключением той, что есть — это хороший уровень демагогии.

Цивилизацию формирует перечисленное.

Лучше бы определиться с тем, что конкретно вы пытаетесь доказать и в каком споре победить. Легко заболтать оппонента, уводя дискуссию в разные стороны, далёкие от изначальной темы. Как бы не были схожи и несхожи люди и обезьяны (самое близкое, что только можно придумать из разумной жизни), это совершенно никак и ничего не доказывает про жизнь вне Земли.

Спорность темы про язык жестов у обезьян широко известна, это не достоверный факт, на который можно опереться

И тем не менее. цивилизации людей и обезьян очень различны. Но, конечно можно назвать эту разницу шелухой, а удобное сходство возвести в абсолют. Не знаю только, что и как это доказывает.

Образ мышления, восприятие мира, система ценностей, мотивация и стремления у человекообразных обезьян и людей одинаковы?

Видов органической жизни на планете Земля. Это самоочевидно, все они развивались внутри единой системы, и у них много общего. Внеземная разумная жизнь может быть совершенно другой, она может не иметь видов, ей могут быть не нужны особые ресурсы, ей может быть не с кем и незачем бороться на протяжении всей своей истории. Самое простое, у другой формы жизни может быть совершенно другой темп существования, даже если он отличается всего лишь в разы — это ломает все наши стереотипы взаимодействия.

Даже если взять человека и немного изменить известные нам параметры — скорость мышления, устойчивость памяти, диапазон восприятия органов чувств, параметы метаболизма — это меняет всё.

Нет такого утверждения. Технологичность только один из возможных атрибутов, но не обязательный. У нас такой есть, у других может не быть, а быть совершенно другой, нам не знакомый. Жизнь не обязательно должна быть белковой и похожей на ту, что известна нам в пределах нашей планеты. Не обязательно, что извержение вулкана и прочие опасные для нас явления несут угрозу другим типам жизни, возможно даже наоборот. Выход за пределы собственной планеты не обязательно требует наличия кораблей.

Сначала речь идёт о более вероятной непохожести цивилизаций друг на друга, но дальше идёт рассуждение о столкновении цивилизации, сильно похожей на человеческую — технологического типа, со взрывом технологий, с кораблями, с самим понятием врага и его уничтожения (есть отдельные особи, у них есть проблемы с взаимопониманием, есть борьба за ресурсы), и так далее.

Спасибо за внимание! Да, конечно, опечатка, довольно частая у меня в подобных местах. Как раз подгонялись тайминги 'на живую', заменялись lda zp на nop и обратно, что поиграть ± такт, а комментарии после этого не поправил. К слову, в итоге этот код был переделан до неузнаваемости, теперь там табличка тактовой задержки для каждой отдельной строки.

Про это я упомянул в конце сообщения. Да, у ZX доступ к видеопамяти возможен всегда, что позволяет делать более детализированную, хотя и существенно медленную графику. Т.е. можно выводить сколько угодно спрайтов, делать 3D рендер, и так далее.

Но там своя интересная специфика: ОЗУ делится на два поля, 16 и 32 килобайта, физически находящиеся в двух разных банках DRAM (т.е. там аж 16 микросхем памяти). Первое общее с видеобуфером, процессор при выборке байта видеоконтроллером тормозится (причём непосредственно через тактовый вход, не WAIT), поэтому в нижней памяти возникает очень сложный паттерн тактов. Также есть аппаратный баг, это торможение не срабатывает при некоторых условиях, в частности при размещении таблицы векторов прерывания в нижней памяти — тогда на экране возникает так называемый 'снег'. Второе поле памяти без торможения, весь критичный к таймингам код (биперная музыка, бордюрные эффекты, мультиколор) может работать только там. В ZX Spectrum 16K второго поля просто нет (не установлены микросхемы ОЗУ), соответственно все перечисленные эффекты там невозможны.

В поздних советских клонах схемотехника и элементная база сильно отличаются от оригинала, конфликт доступа к ОЗУ решён иначе, и в них уже одно общее поле памяти без тормозов.

У меня тоже был такой, правда не в 90-х. Так и есть, у всех нечастых приставок-компьютеров с SECAM-кодером (всякие местные Спектрумо-клоны) изображение просто ужасное, потому что нормальный кодер сильно сложно-дорого сделать.

Увы, в базовой конфигурации такого нет. В ней есть три основных метода отлова нужной строки: точная задержка кодом, либо флаг пересечения пикселей нулевого спрайта с пикселями фона, либо флаг превышения кол-ва спрайтов на строку. Последние два позволяют не тратить время процессора совсем впустую, потратить кое-как часть на полезные действия.

Также есть особо чудной и самый козырный способ — прерывание по концу проигрывания DPCM сэмпла, можно сделать пустой сэмпл известной длины, запустить его в начале кадра, и получить прерывание близко к нужному месту, позволяя в это время работать основному потоку (соответственно звук лишается цифрового канала).

В любом случае после срабатывания флага или прерывания надо очень точным таймингом загнать нужную запись обновления регистров скролла в hblank, иначе будут артефакты. Регистры скролла только кажутся простыми (адрес и X/Y смещение), на самом деле там очень хитроумная логика, требующая планирования порядка записей — какая запись перезапишет какой внутренний счётчик, какие биты проигнорируются. И она была известна разработчикам ещё в 1985, используется в SMB, если эту логику не эмулировать, скролл не будет работать.

Прерывание по строке есть только в некоторых жирных мапперах, в частности MMC3. Но оно реализовано через аппаратный хак, с кучей ограничений. Нужно, чтобы был включён рендер. Нужно, чтобы тайлы спрайтов и фона были в разных банках PPU (включая режим 8x16). Нужно, что в конфигурации не было CHR RAM. Разные версии маппера имеют свои особенности, типа диапазона возможных строк. Прерывание приходит ближе к началу строки, когда записи уже делать поздно, и нужно программной задержкой ждать следующую строку — таким образом нельзя сделать обновление по прерыванию каждую строку, только через одну. Ну и другие приятные мелочи.

И не стоит забывать про джиттер. Во-первых, всегда есть джиттер на 4 такта, а процессор не отличается быстротой — легко промахнуться мимо hblank. Но есть хитрые способы отсинхронизироваться и удерживать стабильное смещение тактов от начала кадра. Также DPCM — если он используется в игре, каждый раз, когда происходит выборка байта, процессор тормозится, и вся синхронизация кадра уплывает. Типичное проявление — графические артефакты в такт ударным.

Идея в том, что вы просили пример точной потактовой синхронизации CPU/PPU, и вы его получили. Объяснить на пальцах, как работает? Услуга платная.

К вопросу об усложнении жизни, написано на днях. У вас было столько приставок и компьютеров, я думаю, вы разберётесь, что это такое, зачем оно нужно, и как работает без подсказок.

Это такой IT троллинг, я понял. Спасибо, прекращаю тратить время.

Усложняет сплит скролл, например. Он даже в первом SMB есть. Железо NES проектировалось ориентировочно в 1981 году и не предполагало никаких сложных игр. То, для чего оно делалось — простые одноэкранные аркады типа Donkey Kong. Все более сложные игры, пошедшие с 1985 года, результат выжимания всех соков и использования множество трюков, и всё это завязано на точное знание устройства CPU/PPU и их точной потактовой синхронизации.

Привязываются к тактам всюду и ещё как. Без точнейшей привязки к тактам нельзя написать ни одной игры на 2600, и едва ли получится сделать что-то на NES.

На этих приставках в основных режимах черезстрочная развёртка не используется, каждый полукадр идёт как самостоятельный кадр половинного разрешения. Содержание каждого полукадра отличается, оно не одинаковое. Т.е. приставки показывают 50/60 разных картинок в секунду.

То, что не используется сдвиг полукадра (т.е. честная черезстрочность, полукадр не на том же месте геометрически) — отчасти правда. Т.е. если пытаться взять и вывести картинку полного разрешения, выводя её в соседних полукадрах, она на многих подобных системах будет смотреться неправильно, как простое мерцание — если, конечно, не используется режим высокого разрешения (при наличии).

Самая большая проблема с поддержкой PAL/NTSC в том, что это в принципе не решаемо без значительных компромиссов. Допустим, мы задизайнили игру, где персонажи бегают с кратными частоте развёртке пиксельными скоростями — в простейшем случае каждое обновление герой или экран смещается на один пиксель (или раз в два кадра, или в три). Всё выглядит довольно плавно и красиво. Не важно, для какой из систем это было сделано изначально.

Теперь нам нужна поддержка другой системы, и нужно сохранить те же скорости движения, то есть откорректировать их на 17%. Мало того, что для одного варианта было достаточно целых чисел, а теперь нужна fixed point арифметика, что сильно медленнее (на старых приставках даже сдвиги дорогие), но мы никак не сможем сохранить плавность — появятся либо пропущенные перемещения за обновления, либо двойные, идущие определённым паттерном. И неважно, делать ли такую коррекцию на уровне отдельных объектов, или на уровне обновления всего экрана (т.е. дублировать каждый 6-ой кадр изначально-PAL игры на NTSC, или наоборот, делать два обновления каждый 5-ый кадр изначально-NTSC игры на PAL), плавность при прежних таймингах уже никак не получить.

По совокупности этих причин — сложно сделать, результат всегда плохой — в большей части случаев разработчики забивали на сохранение абсолютных таймингов, сохраняя относительные, т.е. не делали ничего, и игра просто шла на 17% медленнее/быстрее, но так же плавно и с точно таким же геймплеем.

В PAL/NTSC версиях приставок часто помимо кварца отличается много чего ещё. В той же NES делители другие, и в итоге на такт пиксельклока в NTSC приходится нецелое количество тактов процессора (ужасно усложняет жизнь, озвереть можно как), а в PAL целое. В PAL также сделали период обратного хода луча аж втрое дольше, что конечно очень хорошо, но если это применить, адаптация такой игры PAL>NTSC сильно усложняется.

Чтобы наглядно увидеть, что вы заблуждаетесь.

Все консоли и почти все домашние компьютеры тех лет выдают только полукадры (отсюда разрешение 240/224 по высоте), и никакие кадры не дублируются. Все игры на консолях тех лет и большая часть игр на компьютерах типа ZX Spectrum привязываются к началу кадра. Почти на всех консолях до 32-битной эры доступ к видеопамяти возможен только во время обратного хода луча или принудительного гашения экрана (иначе либо сбои картинки при изменении видеопамяти, или — редко — задержка обращения до конца кадра), а попасть в обратный ход без привязки к началу экрана никак нельзя. Как правило в начале кадра всюду генерируется прерывание. А других таймеров в тех системах как правило нет, поэтому все действия привязаны именно к частоте кадров, и как правило с самых первых приставок до 32-битного поколения старались обеспечить полную полукадровую частоту обновления, 50/60 герц. Игры с медленной перерисовкой в основном встречались на компьютерах, где не было железа, чтобы обеспечить такую скорость, зато был более свободный доступ к видеопамяти (ZX-подобные).

Почему же не было, было, но редко, в основном на самых ранних приставках в версии для Франции. Их делали по самому остаточному принципу, это как PAL, но с совершенно кривой палитрой. И была даже версия Dendy Classic SECAM, самые первые поставки. Потом пошли PAL.

Я говорю совершенно конкретно про чиптюн и звуковые чипы в старых приставках и компьютерах, а не про ЭМИ и не про СССР. Никаких дробных делителей там нет.

В чиповой музыке есть свой вопрос строя, даже наверное более актуальный, чем на пианинах и гитарах. Это даже одна из ключевых характеристик чиповой музыки (элемент её узнаваемости), хотя и не такая заметная, как примитивные тембры и использование арпеджио.

Принцип работы звуковых чипов в делении входной тактовой частоты на целый делитель, разрядность которого ограничена (бывало 5, 8, 10, 11, 12, 16 бит), а это даёт очень ограниченный набор возможных частот, каждая из которых толком не попадает ни в одну ноту ни в одном строе, причём чем выше частота, тем меньше точность. И нужно придумать, как получить такую таблицу приближённых частот нот, чтобы на ней прилично звучало хоть что-то. Основные подходы — сгенерировать таблицу чисто математически под равномерно темперированный строй с округлением, и игнорировать нестрой (либо специально сочинять вокруг него так, чтобы звучало приятно), либо подбирать каждую частоту каждой ноты индивидуально на слух или из иных соображений.

Я намекаю на не самую удачную аналогию. На самом деле есть множество сильно разных устройств, называемых автоматической коробкой передач, и значительное их количество либо не даёт ручного контроля вовсе, либо он очень условен (носит рекомендательный характер) — поэтому и есть недовольство. И с программированием тоже примерно так, из массово популярных Python, JS или C# на уровень ниже особо не спустишься.

Например, есть ряд людей, которые ездят исключительно на механической коробке передач, крайне негативно относясь к автоматической. Они считают, что автомат переключает передачи не эффективно, и вручную они могут лучше

Стоит правда отметить, что у водителя с автоматической коробкой передач есть возможность переключиться на ручной режим.

А чего же крайний негатив, если якобы есть возможность переключиться и не страдать?

Я говорю про собственный опыт (40 игр на дисках), и почему-то он не совпадает с вашим.

Кстати, не расскажете, почему Evil Within, чисто сингловая игра без онлайна, не даёт мне начать игру при плохой связи, или почему NFS в сингле регулярно загружается раза с 3-4 даже при хорошей связи, теряя связь с серверами при загрузке сохранения?

Если выехать в ближний пригород, можно увидеть там множество 2105 07 08 09, купленные за 20-40 тысяч, которые не то, что заводятся, но и ежедневно ездят по далеко не лучшим дорогам на протяжении многих дачных сезонов, без особых ремонтов.

На текущем поколении без интернета уже не особо-то поиграешь. 50-гигабайтные патчи, без которых глюк на глюке, некоторые игры совсем не запускаются или быстро выходят в меню при плохой связи.

Спасибо за информацию, не знал. На CD дублирование было значительно меньше, порядка 3-5 копий. Вероятно при сотнях дублей чисто статистически часть из них окажется ближе других, независимо от того, как их разбросает физически при установке. Но тогда список быстрых связей нужно строить во время установки. Интересно было бы узнать, как на самом деле это работает.

Да изобретали уже, Steam Controller. Много шуму было, ныне благополучно забыт.

Именно. Особенно смешно, что про это написано не в разных местах статьи, а в одном абзаце.

Такая практика была действительно распространена на первых приставках с CD-приводами (3DO, PS1), приводы были очень медленными, и данные дублировались в разных местах диска, чтобы сократить время доступа. А вот про применение такой техники к жёстким дискам я слышу впервые, и звучит странно. На CD точно известно, где физически располагаются конкретные блоки данных, а на жёстком диске же фрагментация, игры ставят-удаляют, качают обновления, и т.д.

полностью неизвестной архитектуры ЦП без какой-либо документации

Утверждается, что машина имеет 4 регистра общего назначения, 1 кибибайт памяти данных и 32 кибибайта памяти команд

На ранних мерцающих ЭЛТ дисплеях с развёрткой 50-60 Гц глаза вытекали от светлых тем, особенно если это был монохромный зелёный или жёлтый монитор (см. IBM 5150 или 5155, например). Потом мониторы стали лучше и цветнее, частота развёртки стала выше, а потом и вовсе пошли жК экраны, где вместо мерцания смазывание, и стало комфортно использовать светлые темы.

Не надо превратно понимать бумажный код. Его писали не от делать нечего, а тогда, когда просто не было доступа к компьютерам, в надежде, что однажды он появится, и можно будет сразу попробовать придуманную программу. Либо когда время доступа было крайне ограничено, это вообще классика вычислительной техники, разделяемое машинное время и всё такое. Либо когда его не было иной возможности сохранить. Либо когда его иначе и не напишешь (ПМК). Иначе говоря, компьютеры не всегда были такими доступными и такими как сейчас, и в нашей стране это было не так уж давно.

Математика и физика совершенно другая тема и совершенно точно не альтернатива. Люди, тогда ещё подростки, жаждали приобщиться к компьютерной технике, новой технической диковине с прикладным значением (в виде игр, например), а не к школьной программе.

Самый бюджетный способ сделать реалистичную анимацию — как раз снять видео, и построить ключевые кадры анимации, ориентируясь по нему.