Споры о "плавности" идут давно - ещё до появления 3D сторонники приставок убеждали хозяев ПК, что благодаря FPS>>24 обеспечивается "невиданная плавность" и т.п. Но это скорее философская сторона вопроса: смотреть надо на уже готовое приложение. Возможность будет как "работать во фрейм" (непонятная для меня терминология), так и выдавать 30FPS.Была бы _возможность_ делать one frame
Абсолютно согласен. Но тут - либо автор спрайтов уменьшает в них количество дыр ;-), либо копируем программно. При этом не стоит забывать, что копирование фона всё равно производится DMA. Всё будет зависеть от общего количества и размера спрайтов.Дело в том, что может-же быть такой вариант, когда
пиксели чередуются в спрайте - прозрачный/не_прозрачный.
Согласен, но для режима 640х480 8bpp@75 скопировать можно ;-).Большие спрайты не скопируешь с учётом альфа-канала.
А вообще - проблема альфа-канала решается аналогично проблеме дырчатости: делаем меньше дырок/убираем альфаканал и все счастливы ;-)Хотя, в принципе, без альфы жить можно.
А если серьёзно, то дырчатость - свойство хорошее, позволяет в том числе "альфа-канал" реализовать. Например, сделать тень с помощью маски "шахматная доска". Однако для начала надо сделать прототип, в будущем можно будет добавить в ПЛИС какой-нибудь хитрый DMA (в том числе с учётом альфа-канала). Но по-моему всё решиться программно - см ниже.
Задача. Есть источник 16 бит шириной w выстотой h, есть альфа-маска источника 8 бит, есть приёмник 16 бит. Необходимо скопировать источник в приёмник с учётом альфы.
Решение. Алгоритм основан на последовательном доступе к SDRAM. Источник, альфа-маска - в основной памяти, приёмник - видеопамять. Координаты не учитываются. Считается, что за один такт SDRAM контроллера CPU успевает сделать 2 такта. Выполнение любой команды CPU - 1 такт, все регистры - 32 бит.
Формула альфы:
результат = (1-альфа/255)*результат + альфа/255*источник = результат-альфа*(результат+источник)/255
1. Считать строку альфы в кеш (w байт) [SDRAM w/2 тактов | CPU 2*w тактов - чтение, addr++] - для CPU это последовательное чтение w байт памяти, с командой залочивания кеша.
2. Читать очередную точку источника в R1 [SDRAM 1 такт | CPU 2 такта - чтение, addr++]
3. Читать очередную точку приёмника в R2 [SDRAM 1 такт | CPU 2 такта - чтение, addr++]
4. Читать очередную точку альфа в R3 [SDRAM 1 такт | CPU 2 такта - чтение, addr++]
5. R1 = R1+R2 [CPU 1 такт]
6. R1 = R1*R3 [CPU 1 такт]
7. R1 = R1/255 [CPU 1 такт] - возможно реализовать сдвигом
8. R2 = R2-R1 [CPU 1 такт]
9. Записать очередную точку приёмника из R2 [SDRAM 1 такт | CPU 2 такта - запись, addr++]
10. Если ещё не вся строка, то перейти на 2 [CPU 2 такта]
11. Вычислить новые адреса [CPU~4 такта]
12. Если ещё не все линии, то перейти на 1 [CPU 2 такта]
Итого имеем 8hw 133МГц-тактов.
То есть если просто для пересылки память-видео 16-битного растра мы тратим порядка 2hw тактов шины (по сути, неважно, DMA или процессор), то с альфа-каналом - в 4 раза медленнее. Однако, для 640х480х16бит имеем время наложения 18.4мс, что неплохо.
Практически же, если имеем постоянно сдвигающийся экран и общую площадь спрайтов порядка 25% - или 75000 точек, то время на копирование экрана (307200 точек) плюс копирование спрайтов с альфой составит (в тактах SDRAM) порядка 8*75000+2*307200 = 914400 тактов или около 7мс. Замечу, что 75Гц - это периоды в 13мс. То есть минимум 40% процессорного времени у нас в распоряжении.
Так что программный альфа-канал не так уж и плох. Для 8 бит на точку вычисления будут сложнее, зато можно будет удвоить скорость перекачки точек ;-)
На сегодняшний момент оценена себестоимость, которая составляет сумму около 100$ ;-) ( 62$ стоит набор микросхем оптом ). Это для 64Мб ОЗУ и 1Гб флеш. Думаю, через полгода-год, когда начнётся серийный выпуск, можно будет за те же деньги ставить 128Мб/8Гб ;-) По крайней мере, плату исходя из этого развожу ;-)Какая планируется стоимость готового компа?
P.S. Все вычисления и алгоритм даны в первом приближении!
newart,
- Вероятно, тоже имеешь в виду "работу в фрейм"? Откуда такая терминология? ;-)то в текстовой читалке я бы тоже хотел иметь фрейм
Кстати, разница между кино (почему там хватает 24кадра) и анимациями в компе (почему не хватает) - была установлена довольно давно - нет размытия при движении, которое наблюдал бы глаз в случае реального движения. В кино размытие есть (время экспозиции кадра), а в играх - нет. Поэтому FPS поднимают заоблачно, чтобы глаз не заметил отсутствие разымытия. Если в набор 2D спрайтов добавить переходные картинки (с размытием), то 30FPS - предел мечтаний. Жаль, что разработчики игр плохо знакомы с подобными эффектами. С другой стороны, порой проще поднять FPS, чем дорисовывать спрайты (хотя при подготовке спрайтов из 3D моделей в той же 3DSMAX проблем не возникает).
В 3D движки (OpenGL, DirectX) добавили размытие при движении не так давно, и редко кто его использовал...
Расчёты я привёл. Вывод - альфа-канал использовать реально для 640х480 16bpp@75Hz до 50% спрайтов + скроллинг фона.Ну вот теперь прикинь сколько ресурсов сьест этот альфаканал.
В своё время (года 4 назад) тестировал GeForce MX400. Вывод - на 40% быстрее, чем Riva TNT2 Vanta 8Mb (урезанная TNT2!!!, AGP1x!!!). Тест брал 3D Mark 2000, процессор был Celeron 566, Celeron 733, Pentium III не помню сколько, 700 вроде. Тест мне запомнился, т.к. показал, что карта стоитмостью 200 рублей не много хуже карты за 2000 рублей. Брал другие карты (MX200, какую-то попродвинутей MX400) - результат различался только когда размеры выходили за область видеоозу. Риторический вопрос - кто виноват и что делать?это дело на 1.4гг не тянет фрейм. Возможно тут дело в связке windows->dx->кривые дрова и т.д?
1.4ГГц - вероятно, шина к памяти у тебя DDR400, то есть 64бит 800МГц = 6.4 Гб/сек пропускает. AGP 4x даст 66*4*32бит = 1 Гб/сек. Процессор может выполнять команду за такт (учтём кеш и т.п.) - 1400MIPS имеем (не RISC команд!). Вроде всё круто... И снова риторический вопрос - кто виноват и что делать?
Возможно, программист отключил аппаратные возможности видеокарты в своём приложении (использовал неверные флаги/не ту функцию). Возможно, программист не скопировал спрайты в видеопамять. А ещё, возможно, установленные дрова для DirectX 9.0c мешают жить плате, которая аппаратно девятый DX не тянет ;-) Уверен, что можно добиться небывалых высот в DX (благо, сам добивался) - но надо разбираться во всех тонкостях и не только софта. Если программист вырос на Яве/Питоне/С# - то не стоит ожидать быстродействующей программы. И вовсе не потому, что Ява этого не позволяет. А потому, что там будут настолько страшные места (в виде строк через list ;-) ), что об оптимизации говорить не приходится.
К сожалению, производителям ПК выгодно, если железо будет подтормаживать - это заставит пользователей покупать новое железо. Что мешает в Windows вставить код задержки CPU? ;-)))
Идея платформы в том числе и показать, что использование железа на 100% позволяет многого добиться. Жаль только, что унификация не позволяет это сделать. А ведь абстракции, порождённые интерфейсами, зачастую дырявы.
Да, и если говорить о "рывках" в Windows - так это нормально: режим soft time ;-) На приставках-то real time юзается.
