Вектор-06Ц: Эмуляция

[b2m]

А возможно-ли в следующих версиях EMU сделать управление сглаживанием

Не знаю, я не пробовал. Использую настройки directx по-умолчанию. Я, правда, не совсем понимаю, как выводить точки без сглаживания? Какие дублировать? Выглядеть это будет странновато.

Да, вот ещё странность. У меня есть дисковая версия редактора Карандаш, так вот она в VV работает как на реале, а в EMU почему-то меню начинает мельтешить пиктограммами. Странно.

Кинь ссылку на диск, посмотрю на досуге.

[Advertiser]

[svofski]

У меня в VirtualBox-е EMU не особенно-то сглаживает точки, выглядит как будто бы просто линейное масштабирование -- пиксели при этом выглядят не равномерно мутными, а резкими, но разных размеров.

А VV сглаживает ровно при прочих равных, хотя и съедает при этом некисло процессорного времени -- не знаю, связанные ли это явления.

[PPC]

Не знаю, я не пробовал. Использую настройки directx по-умолчанию. Я, правда, не совсем понимаю, как выводить точки без сглаживания? Какие дублировать? Выглядеть это будет странновато.

Ясно. Я поэтому спрашивал какбе, через GDI-ли выводится. Там это было-бы просто, хоть может и не так быстро.

Что-то типа
CreateCompatibleDC(), StretchBltMode(COLORONCOLOR или HALFTONE), BitBlt(BLACKNESS), потом - рендеринг в память compatible битмапа,и в конце BitBlt(SRCCOPY) в контекст.

Про DirectX не знаю, но думаю тоже можно как-то сглаживанием играться.

Кинь ссылку на диск, посмотрю на досуге.

Оk, пришлю образ с диском личкой.

---------- Post added at 05:45 ---------- Previous post was at 05:38 ----------

А VV сглаживает ровно при прочих равных, хотя и съедает при этом некисло процессорного времени -- не знаю, связанные ли это явления.

Да, в VV сглаживание отменное. А про процессорное время, возможно что там thread не отпускается в цикле ожидания синхры, и возможно, sleep(0) это может проправить. Хотя, может я и ошибаюсь.
Невероятно же чтобы Паскаль генерил НУ НАСТОЛЬКО более медленный код чем С. Обычно раза в 2-4, а тут - на порядки проц загружен

[svofski]

Невероятно же чтобы Паскаль генерил НУ НАСТОЛЬКО более медленный код чем С. Обычно раза в 2-4, а тут - на порядки проц загружен

Не, там 100% что-то в цикле приложения не так.

[PPC]

Чёт я не разобрался, как в личку файлы зааттачивать, посему кину сюда.
Вот, собственно в аттаче образ диска с дисковым Карандашём, картинкой и операционкой под которой это всё работает в VV как надо, а в EMU сразу после запуска у Карандаша начинает глючить меню.

[b2m]

Про DirectX не знаю, но думаю тоже можно как-то сглаживанием играться.

А в полноэкранном режиме тоже сглаживание есть? Там, по идее, масштабирование у меня программное и сглаживания быть не должно...

---------- Post added at 16:55 ---------- Previous post was at 16:45 ----------

в EMU сразу после запуска у Карандаша начинает глючить меню.

Если выбрать джойстик, то да (не поддерживается). А если выбрать клавиатуру - то всё нормально (клавиатура выбирается нажатием на РУС, у меня правый Ctrl).

[PPC]

А в полноэкранном режиме тоже сглаживание есть? Там, по идее, масштабирование у меня программное и сглаживания быть не должно...

В полноэкранном нету, но там мой видеоадаптер сходит с ума, показывая всё в фиолетовой палитре. У лэптопа нативное разрешение 1600x900. Попробовал в конфиге поиграться вот этой строкой:
main.fullscreen=1280x1024x16

Менял и разрешение и BPP на 32. Бесполезно, всё равно загрузочный экран, например, жёлтый на фиолетовом.
Могу только внешний монитор попробовать к лэптопу прикрутить. Правда, не сейчас.

Если выбрать джойстик, то да (не поддерживается). А если выбрать клавиатуру - то всё нормально (клавиатура выбирается нажатием на РУС, у меня правый Ctrl).

Спасибо! Попробовал, и правда, правый Ctrl, а я левый давил, ха проблема в юзере. :-)
Интересно, что я в VV тоже использовал левый Ctrl, всё время выбирая джойстик П, но работая с клавиатурой.

[b2m]

Попробовал в конфиге поиграться вот этой строкой:
main.fullscreen=1280x1024x16

Менял и разрешение и BPP на 32. Бесполезно, всё равно загрузочный экран, например, жёлтый на фиолетовом.

Проблема не в видеоадаптере. Но пока я даже не знаю, на что грешить.

32 бита при удвоенном разрешении по Х не предусмотрено. Можно попробовать наоборот - 8 бит. В этом случае палитру я задаю сам.

Можно ещё поиграться со строками main.fullscreen.scale, подобрав разрешение и масштабирование (в надежде получить правильные цвета и пропорции), но учти, что по Х это может быть только 1 или 2, а если 2, то нельзя 32 бит.

Могу только внешний монитор попробовать к лэптопу прикрутить.

Думаю - не поможет.

Интересно, что я в VV тоже использовал левый Ctrl, всё время выбирая джойстик П, но работая с клавиатурой.

Да, в VV джойстик поддерживается автоматом. Тут я спасовал

[Error404]

Невероятно же чтобы Паскаль генерил НУ НАСТОЛЬКО более медленный код чем С. Обычно раза в 2-4, а тут - на порядки проц загружен

PurePascal вообщето быстрее PureC. Все прочее - это уже тормоза от программистов. Конечно, зависит от реализации компилятора, но если говорить за одного производителя производящего и то и то (например борландовские TP/BC и более поздние Delphi/CBuilder), то это так (хотя и на скорость их С никто не жаловался, просто Паскаль быстрее).

[PPC]

PurePascal вообщето быстрее PureC.

Это-только если С использует __stdc calling convention, то таки да, у Паскаля возврат из процедур будет побыстрее. Но Паскаль очень заботится о приведении типов, выравнивании данных и многой прочей ерунде. Доводилось видеть имплементации Паскаля, где приведение типов делалось explicitly через function calls. А в C explicit и implicit casts зачастую кода вообще не генерят. Привели к char*, побежали по памяти (сделали dereferencing и рухнули на какой-нибудь архитектуре - bus alignment). Borland - не Metrowerks и не Comeau, у них и паскальный и сишный код - сплошной доступ к памяти на всю ширину регистра и прологи-эпилоги у функций. Тут calling convention рулит.