Quote:
Я сомневаюсь, что Вам удасться без аппаратной доработки заставить "Львов" выводить 16 цветов в режиме 256х128.
уф, в такой схеме 16 цветов действительно невозможны.
00 0R RR 0B BB 0G GG RB RG BG - всего 10
на самом деле ещё меньше, т.к. надо учесть границы (переход с суперпиксела на суперпиксел), кроме того, желательно пикселы делать 2х2 или даже больше.... в общем, как я и говорил - экспериментировать надо. аппаратная доработка помогла бы "мультиколору", но это уже
за гранью добра (программных методов),
Quote:
Вобщем-то да. Но я тоже поправку добавлю. Начиная с Win 95 (хотя, может и с Win 3.x) дизеринг Винды поменялся. Свои "нативные виндовозные" элементы Виндовс отрисовывал как дизеринг, а вот софт уже строго следил за графическим режимом.
софт вполне мог упрощённо отслеживать видеорежимы и полагаться на упрощённую отрисовку, работа с DC устройства была "ещё тем секасом", так что, если надо было выводить много графики, делали битмапку и пытались вывести уже её, игнорируя остальные функции GDI.
В общем - то - это скорее "веяние времени", чем технические ограничения.
Quote:
В то время, как для первой-второй винды, можно было писать прогу, как бы под true color. Вот есть очень характерный пример
ммм, это (картинка) могут быть особенности драйвера - то, как он стыкуется с GDI. в целом все цвета внутри системы "устройство-независимые" (RGBQUAD).
в семёрке GDI уже нет (там какая-то хрень на основе DirectX).
GDI - чрезвычайно сложный кусок кода, в частности, там процедуры BitBlt генерируются для конкретных устройств и разрешений (компилируются на ходу). и всё равно - его всегда критиковали за то, что он тормозной (сейчас всё работает быстро потому, что делается железом видеокарты - даже самой дрянной - иначе будет тормозить так-же сильно, как и раньше).