Pull to refresh

Comments 17

Решение заключается в том, чтобы повторять исходные биты, чтобы они заполнили все выходные биты.

uint8 red = r << 5 | r << 2 | r >> 1

Как-то заумно для r*255/7
Возможно, но не факт.
LUT, как написал DimPal ниже — может оказаться ещё быстрее.
Тем более что 3 бита*3 канала — это всего 512 записей и не нужно возиться с каналами отдельно.
Это может показаться странным, но даже такую функцию на современных процессорах может оказаться быстрее посчитать.

Не забывайте, что задержка даже в L1 на современных процессорах — это 3-4 такта. А вычисления описанные можно сразу для трёх каналов делать.

Если же вы сделаете одну таблицу сразу на три канала — то сожрёте сразу изрядный кусок L1.
Так то да… Но и вы не забывайте что эта LUT нужна для перелопачивания экранного буфера, вероятность что кэш будет прогреваться по максимуму более чем высока.
Зависит от того, как эмулятор устроен. Если хранить картинку в пересчитанном виде (чтобы её было удобнее выводить), то на одну операцию с цветом будет приходиться масса других операций.
Конечно можно :), преобразования цветов прекрасно работают на GPU (во фрагментном шейдере OpenGL например).

Но для современных устройств эмуляция 5 МГц процессора с выводом даже 320х240 пикселей 30 кадров в секунду не особо проблема производительности.

Более накладные в вычислительном плане и лучше подходящие для GPU операции, на мой взгляд, в статье не описаны:
В этой статье мы не будем рассматривать артефакты экранов, такие как кривизна экрана, строки развёртки, хроматическая аберрация, межкадровое смешение, апертурные решётки и т.д.
30 кадров в секунду
Это на современных консолях 30, а раньше было 60.

Также, если мы делаем не просто эмуляцию, а _точную_ эмуляцию, требования к производительности вырастают на порядок.
Увы, статья не относится к _точной_ эмуляции, поскольку на выходе консолей не было пикселей, а был ТВ сигнал.

Старые консоли подключались к телевизорам через PAL или NTSC, и частота кадров также телевизионная. Честных 60 кадров там точно не было :).
Речь не о точной эмуляции вывода картинки, а об эмуляции всего железа, так называемой cycle accurate.
Ну я так понял что статья о «точной» эмуляции вывода картинки только.

По сути эмуляция приставки на ТВ сигнале и заканчивается, дальше уже идёт эмуляция дисплея/телевизора, что вообще отдельная тема.

Эмуляция всего железа cycle accurate для игрушек с приставки на мой взгляд особо и не нужна, те же эмуляторы PS1 заметно лучше оригинала в плане графики.

Я не имел ввиду "только ТВ сигнал", эмулятор не ограничен одной графикой и состоит из множества систем, точная симуляция которых довольно сложная. Точность эмуляции зависит от системы, не везде на практике нужно cycle accurate. ТВ сигнал является выходом для приставки и само отображение его на экране не является частью приставки как таковой. Я имел ввиду что ответственность эмулятора приставки за вывод графики на этом заканчивается.

«Это оказывает потрясающее воздействие на изображение при эмуляции: сверху показан оригинал, снизу — изображение с применённой гамма-коррекцией:» — тут или текст подправить. Или картинки переставить. Маленькая ошибка. Но поскольку это в первой паре картинок, то только из дальнейшего текста становится ясно что имелось в виду.
«Это оказывает потрясающее воздействие на изображение при эмуляции: сверху показан оригинал, снизу — изображение с применённой гамма-коррекцией»

Картинки с различиями отображаются слева-справа, не верх-низ.
Sign up to leave a comment.

Articles