При закрытой "монолитной" эмуляции проблем вообще не слишком много.Сообщение от Titus
Но если речь заходит про модульную эмуляцию с обменом потоками данных через открытые интерфейсы, когда модуль эмуляции КГД принимает "поток видео" от другого модуля ( например, от эмулятора КСМ ), добавляет туда свою картинку и передаёт по "потоку видео" на эмулятор устройства отображения - то нужно для начала хотя бы написать API потока видео :)))
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Не тормознуто ли получится?когда модуль эмуляции КГД принимает "поток видео" от другого модуля ( например, от эмулятора КСМ ), добавляет туда свою картинку и передаёт по "потоку видео" на эмулятор устройства отображения - то нужно для начала хотя бы написать API потока видео))
Посмотрим.
Локально (если не через интернет) в потоке видео будут передаваться указатели на объект "кадр потока видео". Само-по-себе-изображение будет представлено массивом 8-битных значений RGB (для чёрно-белых кадров все три значения будут одинаковы).
Таким образом, типичный эмулятор "видеоустройства" будет несколько (до 60) раз в секунду получать ссылку на кадр, модифицировать изображение и передавать ссылку дальше в поток.
Сколько сложений матриц RGB в секунду сможет выполнять типичный сегодняшний комп для размерностей порядка 800х400..
Мне кажется, что где-то 1000 в секунду ( или 10'000 ? ).
Последний раз редактировалось Patron; 10.02.2012 в 19:27.
Экран 800x400 - это милион байт примерно. Значит миллион байт КСМ сложить со сдвигом с миллионом байт КГД, 60 раз в секунду. Т.е. не менее 200мипсов одну математику, если влоб, побайтно. Но, учитывая, что написано будет на Си. В общем, на 2ГГц'овом проце больше, чем 250 фпс рассчитывать наверное не стоит. Но это если писать на Си, не на асме.
Кстати, мне кажется, что смешивать яркости пикселей КСМ и КГД 50/50 не стоит. Скорее лучше складывать их по OR'у. Т.к. в реальных программах текст не печатается поверх графики, а печатается на пустых от графики местах.
Хотя у КГД изображение 400x286, а у КСМ - 800х286, но поскольку они используют "общий" видеосигнал, то очевидно, что формат массива изображения у них одинаковый, но КГД "заполняет" только каждую вторую ячейку.
Ограничения API распространяются только на интерфейсы. Все интерфейсные объекты должны быть написаны на С++ в Visual Studio. Но к интерфейсному коду на C++ авторы эмуляторов могут линковать в Visual Studio что угодно. Хотя, на мой взгляд - ассемблерные вставки и специализированные библиотеки - самое оно.учитывая, что написано будет на Си
Вообще-то, при сложении двух кадров умножение требуется только для моделирования "притухания" исходного кадра при прохождении через смеситель. Для простого объединения двух изображений (на мой взгляд) достаточно обычного сложения с ограничением максимального значения ( т.е. когда 100% + 100% = 100% ).Кстати, мне кажется, что смешивать яркости пикселей КСМ и КГД 50/50 не стоит. Скорее лучше складывать их по OR'у. Т.к. в реальных программах текст не печатается поверх графики, а печатается на пустых от графики местах.
Последний раз редактировалось Patron; 10.02.2012 в 19:06.
Это и есть обычное сложение по OR для двухцветного изображения.
Думаю, это справедливо и для более общего случая, когда суммируются видеосигналы не 100% яркости. Т.е. 25%+25% = 50% ; 50%+50% = 100% ; 70% + 70% = 100% и т.п.
---------- Post added at 18:57 ---------- Previous post was at 18:25 ----------
Хотя, не исключаю, что "видеосумматор" может быть сделан и так, чтобы в каждый момент (т.е. для каждой точки) пропускать на выход более сильный из сигналов. В результате - яркость "суммы" двух точек будет равна яркости более яркой из них.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
