Эмуляторы отечественных компьютеров

[hobot]

то нужно для начала хотя бы написать API потока видео ))

Это означает - не спешите всё будет, работа кипит в нужной последовательности и (см. пост Patrona про тетрис) - там явно указано, что эмулятор "не доделан", однако
символьная ДВК уже есть, а значит и есть во что поиграть на ней )))

[Titus]

символьная ДВК уже есть, а значит и есть во что поиграть на ней )))

Меня символьные игрушки не впечатляют (
Видимо, сказалось RK-шное детство, когда всей душой тянулся к графике)

[Patron]

Не тормознуто ли получится?

Посмотрим.

Локально (если не через интернет) в потоке видео будут передаваться указатели на объект "кадр потока видео". Само-по-себе-изображение будет представлено массивом 8-битных значений RGB (для чёрно-белых кадров все три значения будут одинаковы).

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

Сколько сложений матриц RGB в секунду сможет выполнять типичный сегодняшний комп для размерностей порядка 800х400..

Мне кажется, что где-то 1000 в секунду ( или 10'000 ? ).

[Titus]

Сколько умножений на константу (в типичном случае "равновесного" сложения двух кадров - на 0.5) и сложений матриц RGB в секунду сможет выполнять типичный сегодняшний комп для размерностей порядка 800х400..

Мне кажется, что где-то 1000 в секунду ( или 10'000 ? ).

Экран 800x400 - это милион байт примерно. Значит миллион байт КСМ сложить со сдвигом с миллионом байт КГД, 60 раз в секунду. Т.е. не менее 200мипсов одну математику, если влоб, побайтно. Но, учитывая, что написано будет на Си. В общем, на 2ГГц'овом проце больше, чем 250 фпс рассчитывать наверное не стоит. Но это если писать на Си, не на асме.

Кстати, мне кажется, что смешивать яркости пикселей КСМ и КГД 50/50 не стоит. Скорее лучше складывать их по OR'у. Т.к. в реальных программах текст не печатается поверх графики, а печатается на пустых от графики местах.

[Patron]

Экран 800x400 - это милион байт примерно. Значит миллион байт КСМ сложить со сдвигом с миллионом байт КГД

Хотя у КГД изображение 400x286, а у КСМ - 800х286, но поскольку они используют "общий" видеосигнал, то очевидно, что формат массива изображения у них одинаковый, но КГД "заполняет" только каждую вторую ячейку.

учитывая, что написано будет на Си

Ограничения API распространяются только на интерфейсы. Все интерфейсные объекты должны быть написаны на С++ в Visual Studio. Но к интерфейсному коду на C++ авторы эмуляторов могут линковать в Visual Studio что угодно. Хотя, на мой взгляд - ассемблерные вставки и специализированные библиотеки - самое оно.

Кстати, мне кажется, что смешивать яркости пикселей КСМ и КГД 50/50 не стоит. Скорее лучше складывать их по OR'у. Т.к. в реальных программах текст не печатается поверх графики, а печатается на пустых от графики местах.

Вообще-то, при сложении двух кадров умножение требуется только для моделирования "притухания" исходного кадра при прохождении через смеситель. Для простого объединения двух изображений (на мой взгляд) достаточно обычного сложения с ограничением максимального значения ( т.е. когда 100% + 100% = 100% ).

[Titus]

Для простого объединения двух изображений (на мой взгляд) достаточно обычного сложения с ограничением максимального значения ( т.е. когда 100% + 100% = 100% ).

Это и есть обычное сложение по OR для двухцветного изображения.

[Advertiser]

[Patron]

Это и есть обычное сложение по OR для двухцветного изображения.

Думаю, это справедливо и для более общего случая, когда суммируются видеосигналы не 100% яркости. Т.е. 25%+25% = 50% ; 50%+50% = 100% ; 70% + 70% = 100% и т.п.

---------- Post added at 18:57 ---------- Previous post was at 18:25 ----------

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

[Titus]

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

Да не, аналоговый сумматор конечно смешивает обычным сложением, если там именно аналоговый сумматор. Я схему не смотрел. Но в эмуляторе было бы наверное логичным смешивать с насыщением (100 + 100 = 100), чтобы не терять половину яркости.

[Patron]

В принципе - в дальнейших версиях API (скорее всего) будет предусмотрена возможность интерактивной 3D симуляции любого из эмулируемых устройств. И, например, при симуляции мониторного зала - текстура поверхности каждого экрана в сцене будет изменяться до 60 раз в секунду :)

Поэтому, вряд ли быстродействие API абстрактной эмуляции потока видео - это то, о чём предстоит серьёзно беспокоиться :)))

[hobot]

Любопытная вещь ))) Сталкер для бк0011 в эмуляторе ДВК )))

Скрытый текст

[свернуть]

К слову, он и в UKNCBTL отлично работает )))