Новые возможности Unreal

[SMT]

вот еще почему не стоит переделывать у меня гигаскрин: такой "правильный" способ означает, что на каждом кадре придется перерисовывать весь экран. Для меня это неприемлемо, т.к. основной режим у меня оконный. Только на очень быстрых машинах удается полное окно перерисовывать каждый кадр, с учетом всякого рода масштабирований.

оверлей или аппаратное масштабирование?

А так мне удается выходить из этой ситуации перерисовывая только те части "экрана" спека, которые изменились. Потому и быстрый

определение прямоугольников для обновлений тоже не быстрое дело...

А на LCD-мониторах вообще интересно будет глянуть, что получится у SMT в US

тогда ищи старые мониторы. на 12ms очень заметно даже при 60hz int и синхронизации по vsync. только gigascreen не мерцает, а как бы дёргается вверх-вниз

[Vladimir Kladov]

оверлей или аппаратное масштабирование?

у меня нет аппаратного вообще, все сам

определение прямоугольников для обновлений тоже не быстрое дело...

а вот и неправдушки. Если сравнивать предыдущий экран спектрума со следующим, 6192 байта всего. С учетом гигаскрина х 2. С учетом мультиколора еще х 2. Для ПЦ - семечки

[SMT]

у меня нет аппаратного вообще, все сам

тогда процессор видеокарты простаивает. а кстати, smooth scale уже не требует SSE2 и я его заценил. похоже на то, как LCD мониторы интерполируют не родные им режимы

а вот и неправдушки. Если сравнивать предыдущий экран спектрума со следующим, 6192 байта всего. С учетом гигаскрина х 2. С учетом мультиколора еще х 2. Для ПЦ - семечки

у меня тоже была идея сравнивать каждый "мультиколорный" байт с предыдущим и не писать в видеопамять при совпадении. но сейчас обычная конфигурация пц - от двух гигагерц, так что уже не актуально. сейчас подумываю о полумере - обновлять изменившиеся строки, а не произвольные области

[Vladimir Kladov]

а кстати, smooth scale уже не требует SSE2 и я его заценил. но сейчас обычная конфигурация пц - от двух гигагерц,

стоп! обычно там где от 2ГГц, там и SSE2 есть

Видал, поди: народ в буржуинском царстве требует, чтобы шло на пне-75 под вынь-95 (ноутбук), да еще чтобы со скоростью 100% С пропуском кадров (так 35fps примерно) вроде идет...

В direct-x только проблема была с гигаскрином серьезная, сегодня только нашел причину. Так что в следующем релизе будет. Как раз не то не с тем сравнивалось... У меня директ-Х используется только для свопа буферов, рисую все равно сам. Так надо и сравнивать было каждый экран со своим выходом, да еще и пара основной/лополнительный экран доджна была быть подвязана к своему выходному буферу. Т.е. цифры как раз такие: 6К х 4 байт, при сравнении словами всего 6К сравнений, строится матрица 10х10 флажков, вывод по прямоугольникам существенно снижает нагрузку. А проц видюхи - он не у всех есть, и всегда какой-нибудь разный. Я смотрел, что от него можно получить. Ну максимум масштабирование. И то опять же не всегда. Да ну его, у меня быстрее получается. Гораздо сложнее проблема получить плавный скроллинг, а в этом видюха/директ-Х помочь вообще не может. И ОС тоже себе на уме.

Кстати, могу подбросить сигнатур для загрузки ленты, и одну маленькую идейку как радикально ускорить ее еще раза в 2-3-5. Идейку - сразу, она простая: практически все эти загрузчики заканчивают наборку битов командой RL L. Так что условие L = 1, выполняется RL L, идет загрузка с ленты, еще кое-что - дальше берем с ленты сами очередные 7 бит, вдвигаем их, после RL L состояние такое же как после последнего 8-го сдвига. У себя я уже сделал.

[SMT]

стоп! обычно там где от 2ГГц, там и SSE2 есть

ну, пускай не совсем 2 немного меньше

А проц видюхи - он не у всех есть, и всегда какой-нибудь разный. Я смотрел, что от него можно получить. Ну максимум масштабирование. И то опять же не всегда. Да ну его, у меня быстрее получается.

оверлей интерполирует во время выдачи изображения. его ждать не надо. пытался сделать масштабирование через directDraw BitBlt - карта делает билинейную интерполяцию, чего мне не надо, хотя я точно знаю, что можно и без неё (трассировал древний эмулятор zx32 - там именно dx bitblt)

Гораздо сложнее проблема получить плавный скроллинг, а в этом видюха/директ-Х помочь вообще не может. И ОС тоже себе на уме.

да, тут только частоту развёртки подгонять...

Кстати, могу подбросить сигнатур для загрузки ленты, и одну маленькую идейку как радикально ускорить ее еще раза в 2-3-5. Идейку - сразу, она простая: практически все эти загрузчики заканчивают наборку битов командой RL L. Так что условие L = 1, выполняется RL L, идет загрузка с ленты, еще кое-что - дальше берем с ленты сами очередные 7 бит, вдвигаем их, после RL L состояние такое же как после последнего 8-го сдвига. У себя я уже сделал.

почти идеально, но не известно, какие команды вокруг RL L, значит, не известно, сколько тактов пройдёт в цикле загрузки байта. то есть, эмуляция не точная

[BlastOff]

А можно сделать ручную смену разрешения и частоты экрана? А то что-то напрягает работать в 640х480х60, когда можно 1024х768х100.

[Vladimir Kladov]

А можно сделать ручную смену разрешения и частоты экрана? А то что-то напрягает работать в 640х480х60, когда можно 1024х768х100.

Это в US? Тады ой - в emuzwin просто используется та же что на десктопе. Переключение быстрее происходит, и в большинстве дисплеев даже без щелчков (на работе однако со щелчком - там iiyama 2048x1600 (вроде не соврал), хотя и разрешение остается то же, но щелчок все равно почему-то есть). Все равно непонятно что такое x60 - такого не бывает

[Vladimir Kladov]

оверлей интерполирует во время выдачи изображения. его ждать не надо.

а торопиться некуда особо. Эмуляция отнимает гораздо меньше времени, чем вывод графики. Даже 256 цветов легко вписывает от пня450 по карйней мере.

да, тут только частоту развёртки подгонять...

все мечтаю когда-нибудь выбрать время попробовать сделать что-то вроде blur motion. Хотя не совсем. В общем суть такая, что есть 2 кадра, известно время экспонирования первого, известно время экспонирования следующего при частоте 50 Гц. И известна частота дисплея. Задача: "смешать" эти кадры в нужной пропорции, чтобы кажущееся время экспонирования как раз составляло 1/50 секунды.

почти идеально, но не известно, какие команды вокруг RL L, значит, не известно, сколько тактов пройдёт в цикле загрузки байта. то есть, эмуляция не точная

А я привязываюсь к сигнатуре. Только одна сигнатура не смогла работать в этом режиме - la abadia del crimen. Там похоже не просто сдвигаются 8 бит и засовываются, а делается что-то более сложное, вроде побитовой декодировки на лету. А так вроде проблем не заметил. Замечу если - сделаю опцию для отрубания этой фичи. Неточность эмуляции по тактам тоже не помеха. На всех загрузчиках, которыя я испробовал, важно только сколько тактов на ленте прошло, а в машине сколько - не важно, даже R не нужен. Тем более что там все равно идут циклы ожидания следующего фронта на ленте, их же не обязано быть равное количество.

[PheeL]

Это в US? Тады ой - в emuzwin просто используется та же что на десктопе. Переключение быстрее происходит

Я не знаю какие у вас настройки, но у меня разрешение не пререключается при fullscreen по Atl+Enter. Просто стреч с соблюдением аспекта.

, и в большинстве дисплеев даже без щелчков (на работе однако со щелчком - там iiyama 2048x1600 (вроде не соврал), хотя и разрешение остается то же, но щелчок все равно почему-то есть). Все равно непонятно что такое x60 - такого не бывает

Щелчок видимо получается потому что герцовка меняется.

[SMT]

А можно сделать ручную смену разрешения и частоты экрана? А то что-то напрягает работать в 640х480х60, когда можно 1024х768х100.

для us частота полноэкранного режима задаётся настройкой refresh в ini, а разрешение настройкой minres, если поставить minres=768, то будет 1024x768, только изображение всё равно будет в центре. если использовать режимы blitter или overlay, его можно растянуть на весь экран