Посмотрим.
Локально (если не через интернет) в потоке видео будут передаваться указатели на объект "кадр потока видео". Само-по-себе-изображение будет представлено массивом 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.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Думаю, это справедливо и для более общего случая, когда суммируются видеосигналы не 100% яркости. Т.е. 25%+25% = 50% ; 50%+50% = 100% ; 70% + 70% = 100% и т.п.
---------- Post added at 18:57 ---------- Previous post was at 18:25 ----------
Хотя, не исключаю, что "видеосумматор" может быть сделан и так, чтобы в каждый момент (т.е. для каждой точки) пропускать на выход более сильный из сигналов. В результате - яркость "суммы" двух точек будет равна яркости более яркой из них.
В принципе - в дальнейших версиях API (скорее всего) будет предусмотрена возможность интерактивной 3D симуляции любого из эмулируемых устройств. И, например, при симуляции мониторного зала - текстура поверхности каждого экрана в сцене будет изменяться до 60 раз в секунду :)
Поэтому, вряд ли быстродействие API абстрактной эмуляции потока видео - это то, о чём предстоит серьёзно беспокоиться :)))
Любопытная вещь ))) Сталкер для бк0011 в эмуляторе ДВК )))
Скрытый текст
[свернуть]
К слову, он и в UKNCBTL отлично работает )))
Последний раз редактировалось hobot; 11.02.2012 в 02:21.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)