Спасибо за ответ. Поищу чуть больше информации про mode 5, пока не очень понятно как именно фиолетовый цвет превращался в красный.
На самом деле, без этой третей палитры всё было бы на своих местах и экономия была бы понятна. Но она выбивается из всего остального. Почему 2 бита управляют зелёным+синим и красным каналами, а не, например, зелёным и красным+синим каналами?
Мне, на самом деле, сложно представить насколько сложно было добавить "ещё 3 костыля" в 1981. Но один костыль есть и его сделали именно выбором любого цвета из 16. Если бы, например, нулевой цвет был всегда чёрным, то я бы с лёгкостью поверил бы в упрощение схемы. Или, например, насколько сложно было сделать выбор из 4х вариантов для каждого из RGBI каналов: брать из бита 0, брать из бита 1, всегда 0, всегда 1? Тогда можно было бы собрать палитры вида синий, жёлтый, белый (привет пакмену :)) или, например, 4 градации серого.
Великолепная статья. Есть некоторая недосказанность про палитры Vic-20, C64 и Apple II. Надеюсь будет раскрыто в следующей статье.
А ещё хотелось бы, наконец, узнать почему у CGA такие странные палитры. Вопрос уже лет 30 мучает. Должны быть какие-то технические причины для этого. Я вижу, что 4 палитры из 6 имеют фиксированные яркость и синий цвет (одинаковые для цветов 1-3), а 2 бита управляют зелёным и красным каналами. Кроме цвета 0, он может быть любым из 16 и обычно черный. Оставшие 2 палиты так же имеют фиксированный бит яркости, но 2 бита управляют зелёным+синим и красным каналами. Почему так? Один костыль для нулевого цвета запилили, а ещё 3 костыля для остальных цветов пожалели?
В первой половине девяностых существовала достаточно редкая модификация тетриса. Корпус выглядел как обычный Brick Game, но экран был сильно другим.
Вместо кубиков "квадрат в квадрате" были кубики "квадрат, внутри круг, внутри точка", которые могли включаться независимо. Таким образом кубики могли иметь аналог цвета (например, квадрат+круг+точка, квадрат+точка, только круг), игры вроде как это использовали, было что-то типа аналога игры Columns.
Точно помню, что квадрат и круг имели небольшие разрывы сверху и снизу скорее всего туда контакты выходили.
Видел эту модель всего несколько раз, поиграть не удавалось.
Мне по стилю больше всего врорая часть нравится. Но первая часть как-то особенно цепляет взгляд, как будто смотришь на какой-то старый механизм, очень узнаваемый и который до сих пор работает. Это не ностальгия, я сначала увидел и подсел на вторую часть, а потом увидел что-то более древнее, одновременно узнаваемое и неизведанное.
Но лично для меня, если картинка в первой части по-своему завораживающая, то анимация капитально сливает вторым героям.
Нужно менять плату с ПЗУ. Это маленькая платка снизу устройства, по размеру похожа на Compact Flash, но не она. Заменить ОС без новой платки скорее всего не выйдет.
В своё время можно было купить апгрейд, а более новые девайсы были уже с WinCE 2.0. Если захотите рискнуть, то можно поискать нерабочее устройство, если я правильно понял, то на тех, что с WinCE 2.0 из коробки не было жёлтой наклейки на клавиатуре как демо режим запустить. Но это, конечно, ничего не гарантирует.
Но, КМК, на 2.0 не намного больше софта, чем на 1.0. Поиграться и в коллекцию - прикольно, реально как-то использовать - не уверен.
В целом всё получилось, для ядра ОС было достаточно 32 Кб ОЗУ, а для системы с графическим интерфейсом — от 5 Мб и выше.
Вот прям упомянутый в статье HP 300LX имел 2мб ОЗУ. И был, как ни странно, с графическим интерфейсом :)
Но 2мб было минимум только для WinCE 1. Довольно быстро рынок отказался от таких моделей в пользу большего количества ОЗУ.
В отличие от Windows 95, Windows CE чаще всего переустановить было нельзя, она была зашита в носитель информации, доступа к компонентам ОС или всей системе не было.
Имею HP 320LX. ОС зашита в ПЗУ на отдельной платке, есть WinCE 1.0 и WinCE 2.0. На более поздних устройствах была флеш память и прошивку можно было менять, но она должна была быть собрана под конкретный девайс.
Как они DeskMate сделали? Не похоже на псевдографику, знакоместа вроде бы не укладываются в 2 цвета. Под бело-красным меню идут сине-желтые окна, расстояние по высоте меньше знакоместа. Закруглённые уголки на кнопках имеют 3 цвета. Мышь тоже 2 цвета добавляет. Да и вроде не умел CGA символы менять в знакогенераторе.
Про консоли не скажу, проще всего, наверно n-gage б/у взять из готового. Был когда-то проект запуска j2me на Android, но очень давно, ещё на втором андроиде запускал, а потом не следил.
Если коротко, то j2me очень разная, практически каждый телефон требовал свой билд, глючил по-своему и т.п. Консоль сделать, наверно, можно, но придётся делать её под эмуляцию конкретных телефонов и повторять все их глюки. Или, как минимум, дать возможность переключать профайлы с кодами кнопок, разрешением экрана, встроенными шрифтами, доступным апи и т.п.
Сейчас читаю The Game Engine Black Book: DOOM. И знаете что? Во время выхода первого DOOM на топовом по тем временам Intel 486DX2 66MHz игра выдавала 25 кадров в секунду. Для остальных же требовалось уменьшать размер экрана или уполовинивать разрешение по горизонтали с 320 до 160.
На моём 386SX 25MHz игра была относительно плавной при размере экрана размером со спичечный коробок. И это не метафора. Начинал игру с экрана побольше и вроде было приемлемо. Чем дольше играл, тем больше монстров и сложнее геометрия уровней, тем меньше приходилось делать размер экрана.
Это я к тому, что так было всегда, AAA проекты не выдавали хорошую плавную картинку даже на топовом железе ещё 30 лет назад. Правда, на коснолях тех времён (3-4 поколение) было не так, и почти все игры работали на стабильных 60 ФПС.
Раньше вроде как запрещали выкладывать эмуляторы в app store. Что-то поменялось? Или это касалось только программ с возможностью загружать код извне? Или как-то по-другому обошли ограничение (сами собрали порт под Айпад, например)?
Математические алгоритмы гегерации псевдослучайных чисел могут давать хорошее распределение. Дело в том, как алгоритм их использует, он изначально не рассчитан генерировать варианты с равной вероятностью.
Просчитайте вероятности для 2х2. Если я правильно понял, то алгоритм ставит стенку между двумя верхними квадратами с вероятностью 50% при первом вызове рандома. И на этом всё, псевдослучайных числа дальше не имеют значения.
Это точно хороший алгоритм? Похоже, что среди множества возможных лабиринтов генерация одних лабиринтов более вероятна, чем других.
Например я для поля 2х2 есть всего 4 варианта лабиринта, но вероятность стенки между верхними квадратами больше, чем остальные варианты.
Например, можно обнаружить неравномерность даже на анимации вначале статьи. Количество стенок в верхнем ряду больше, чем в нижнем или в боковых столбцах. Исходя из симметрии, я бы ожидал одинакового распределения. Есть вероятность, что можно проследить и другие паттерны, например неравномерность между вертикальными или горизонтальными стенками.
Так этот элемент был добавлен чтобы вибрацию поглощать от разбалансированного кулера. В стиральные машины давно бетонную плиту ставят для этих целей.
Теперь у того пользователя вибрация будет передаваться прямо на корпус, из-за чего жёсткие диски будут выходить из строя. Не надо так.
/s, если что :)
Спасибо за ответ. Поищу чуть больше информации про mode 5, пока не очень понятно как именно фиолетовый цвет превращался в красный.
На самом деле, без этой третей палитры всё было бы на своих местах и экономия была бы понятна. Но она выбивается из всего остального. Почему 2 бита управляют зелёным+синим и красным каналами, а не, например, зелёным и красным+синим каналами?
Мне, на самом деле, сложно представить насколько сложно было добавить "ещё 3 костыля" в 1981. Но один костыль есть и его сделали именно выбором любого цвета из 16. Если бы, например, нулевой цвет был всегда чёрным, то я бы с лёгкостью поверил бы в упрощение схемы. Или, например, насколько сложно было сделать выбор из 4х вариантов для каждого из RGBI каналов: брать из бита 0, брать из бита 1, всегда 0, всегда 1? Тогда можно было бы собрать палитры вида синий, жёлтый, белый (привет пакмену :)) или, например, 4 градации серого.
Великолепная статья. Есть некоторая недосказанность про палитры Vic-20, C64 и Apple II. Надеюсь будет раскрыто в следующей статье.
А ещё хотелось бы, наконец, узнать почему у CGA такие странные палитры. Вопрос уже лет 30 мучает. Должны быть какие-то технические причины для этого. Я вижу, что 4 палитры из 6 имеют фиксированные яркость и синий цвет (одинаковые для цветов 1-3), а 2 бита управляют зелёным и красным каналами. Кроме цвета 0, он может быть любым из 16 и обычно черный. Оставшие 2 палиты так же имеют фиксированный бит яркости, но 2 бита управляют зелёным+синим и красным каналами. Почему так? Один костыль для нулевого цвета запилили, а ещё 3 костыля для остальных цветов пожалели?
Нагуглил такую картинку https://www.vinted.co.uk/items/1318983524-tetris-column-brick-3-in-1-cb-615
В первой половине девяностых существовала достаточно редкая модификация тетриса. Корпус выглядел как обычный Brick Game, но экран был сильно другим.
Вместо кубиков "квадрат в квадрате" были кубики "квадрат, внутри круг, внутри точка", которые могли включаться независимо. Таким образом кубики могли иметь аналог цвета (например, квадрат+круг+точка, квадрат+точка, только круг), игры вроде как это использовали, было что-то типа аналога игры Columns.
Точно помню, что квадрат и круг имели небольшие разрывы сверху и снизу скорее всего туда контакты выходили.
Видел эту модель всего несколько раз, поиграть не удавалось.
Мне по стилю больше всего врорая часть нравится. Но первая часть как-то особенно цепляет взгляд, как будто смотришь на какой-то старый механизм, очень узнаваемый и который до сих пор работает. Это не ностальгия, я сначала увидел и подсел на вторую часть, а потом увидел что-то более древнее, одновременно узнаваемое и неизведанное.
Но лично для меня, если картинка в первой части по-своему завораживающая, то анимация капитально сливает вторым героям.
Нужно менять плату с ПЗУ. Это маленькая платка снизу устройства, по размеру похожа на Compact Flash, но не она. Заменить ОС без новой платки скорее всего не выйдет.
В своё время можно было купить апгрейд, а более новые девайсы были уже с WinCE 2.0. Если захотите рискнуть, то можно поискать нерабочее устройство, если я правильно понял, то на тех, что с WinCE 2.0 из коробки не было жёлтой наклейки на клавиатуре как демо режим запустить. Но это, конечно, ничего не гарантирует.
Но, КМК, на 2.0 не намного больше софта, чем на 1.0. Поиграться и в коллекцию - прикольно, реально как-то использовать - не уверен.
Вот прям упомянутый в статье HP 300LX имел 2мб ОЗУ. И был, как ни странно, с графическим интерфейсом :)
Но 2мб было минимум только для WinCE 1. Довольно быстро рынок отказался от таких моделей в пользу большего количества ОЗУ.
Имею HP 320LX. ОС зашита в ПЗУ на отдельной платке, есть WinCE 1.0 и WinCE 2.0. На более поздних устройствах была флеш память и прошивку можно было менять, но она должна была быть собрана под конкретный девайс.
Это я уже и сам посмотрел в Вики, но ответа я там не увидел.
Наиболее близким кажется графический 640х200, но там 4 цвета, а на скриншоте 5.
Про текстовый режим я пока не нашел информации можно ли там сделать больше двух цветов на знакоместо.
По сравнению с ChuckNorrisException это так, детские игрушки :)
Как они DeskMate сделали? Не похоже на псевдографику, знакоместа вроде бы не укладываются в 2 цвета. Под бело-красным меню идут сине-желтые окна, расстояние по высоте меньше знакоместа. Закруглённые уголки на кнопках имеют 3 цвета. Мышь тоже 2 цвета добавляет. Да и вроде не умел CGA символы менять в знакогенераторе.
Танди имел видеорежимы несовместимые с CGA?
Про консоли не скажу, проще всего, наверно n-gage б/у взять из готового. Был когда-то проект запуска j2me на Android, но очень давно, ещё на втором андроиде запускал, а потом не следил.
На вопрос какие сложности я, как разработчик j2me игр в прошлом, писал этот комментарий: https://habr.com/ru/articles/504682/comments/#comment_21686180
Если коротко, то j2me очень разная, практически каждый телефон требовал свой билд, глючил по-своему и т.п. Консоль сделать, наверно, можно, но придётся делать её под эмуляцию конкретных телефонов и повторять все их глюки. Или, как минимум, дать возможность переключать профайлы с кодами кнопок, разрешением экрана, встроенными шрифтами, доступным апи и т.п.
Сейчас читаю The Game Engine Black Book: DOOM. И знаете что? Во время выхода первого DOOM на топовом по тем временам Intel 486DX2 66MHz игра выдавала 25 кадров в секунду. Для остальных же требовалось уменьшать размер экрана или уполовинивать разрешение по горизонтали с 320 до 160.
На моём 386SX 25MHz игра была относительно плавной при размере экрана размером со спичечный коробок. И это не метафора. Начинал игру с экрана побольше и вроде было приемлемо. Чем дольше играл, тем больше монстров и сложнее геометрия уровней, тем меньше приходилось делать размер экрана.
Это я к тому, что так было всегда, AAA проекты не выдавали хорошую плавную картинку даже на топовом железе ещё 30 лет назад. Правда, на коснолях тех времён (3-4 поколение) было не так, и почти все игры работали на стабильных 60 ФПС.
Мне казалось, что это и про первый CnC и про Red Alert справедливо. Только, наверно, 320х200, а не 320х240. Поэтому я что-то не до конца понял про:
Может какое-то переиздание было под Винду, а до этого только под дос было? Или я что-то не так помню?
Раньше вроде как запрещали выкладывать эмуляторы в app store. Что-то поменялось? Или это касалось только программ с возможностью загружать код извне? Или как-то по-другому обошли ограничение (сами собрали порт под Айпад, например)?
Скриншот Digger'а не оригинальный, а какой-то из более поздних. Много цветов как для CGA.
Нижний ряд сильно бросается в глаза, но проблемы не только в нём. Например, вдоль левого и правого столбцов стенок меньше, чем в верхнем ряду.
Математические алгоритмы гегерации псевдослучайных чисел могут давать хорошее распределение. Дело в том, как алгоритм их использует, он изначально не рассчитан генерировать варианты с равной вероятностью.
Просчитайте вероятности для 2х2. Если я правильно понял, то алгоритм ставит стенку между двумя верхними квадратами с вероятностью 50% при первом вызове рандома. И на этом всё, псевдослучайных числа дальше не имеют значения.
Это точно хороший алгоритм? Похоже, что среди множества возможных лабиринтов генерация одних лабиринтов более вероятна, чем других.
Например я для поля 2х2 есть всего 4 варианта лабиринта, но вероятность стенки между верхними квадратами больше, чем остальные варианты.
Например, можно обнаружить неравномерность даже на анимации вначале статьи. Количество стенок в верхнем ряду больше, чем в нижнем или в боковых столбцах. Исходя из симметрии, я бы ожидал одинакового распределения. Есть вероятность, что можно проследить и другие паттерны, например неравномерность между вертикальными или горизонтальными стенками.
Интересно, это настоящий emergency restart или emergency restart и 20 минут обновлений?