Comments 19
Disp.pBitMap[( (x + line)<<2 )+2] = (SinT[ px1&255 ]+SinT[ py1&255 ])>>1;//R
Disp.pBitMap[( (x + line)<<2 )+1] = (SinT[ px2&255 ]+SinT[ py2&255 ])>>1;//G
Disp.pBitMap[( (x + line)<<2 )+0] = (SinT[ px3&255 ]+SinT[ (py3+63)&255 ])>>1;
Тут прям напрашивается какой-то reinterpret_cast, чтобы сразу 4 байта записывать.
Качество анимации в такой демке будет неважным из-за отсутствия синхронизации с вертикальной разверткой монитора. Вам бы, автор, почитать, как делались демки на старых компьютерах, вроде ZX Spectrum, C64, Amiga или Atari. Везде использовалась синхронизация с вертикальной разверткой, обеспечивая плавность анимации. А у вас будут дергания и/или Tearing artifacts — «разрезание надвое» изображения, когда кусок предыдущего кадра виден на экране одновременно с куском следующего кадра, разделенные друг от друга горизонтальной полосой, каждый раз в разном месте.
Проблема синхронизации с вертикальной разверткой до недавних пор очень сложно решалась в Windows из-за того, что разработчики ОС тоже не понимали важность этой задачи. В результате компьютеры от Apple, где разработчики позаботились о синхронизации, сразу покорили пользователей плавностью и красотой анимации.
В Direct3D9Ex есть функция WaitForVBlank — рекомендую пользоваться. Без нее будут большие потери процессорного времени по циклам опроса положения луча и т.д.
Проблема синхронизации с вертикальной разверткой до недавних пор очень сложно решалась в Windows из-за того, что разработчики ОС тоже не понимали важность этой задачи. В результате компьютеры от Apple, где разработчики позаботились о синхронизации, сразу покорили пользователей плавностью и красотой анимации.
В Direct3D9Ex есть функция WaitForVBlank — рекомендую пользоваться. Без нее будут большие потери процессорного времени по циклам опроса положения луча и т.д.
о какой еще вертикальной развертке вы говорите в современных мониторах?
Если вы не в курсе — даже в современных мониторах изображение передается с видеокарты на монитор с постоянной скоростью по последовательному интерфейсу. Для такой передачи изображение подвергается развертке — кадровой и строчной, потому что в каждый момент времени по интерфейсу передаются данные не более, чем небольшого числа пикселов. С точки зрения искажений при анимации ничего не меняется по сравнению со случаем старых ЭЛТ-мониторов с их сканирующим лучом.
И если не заботиться о синхронизации — то кадры, передаваемые видеокартой, будут содержать желаемое изображение с вышеописанными искажениями (Tearing). Даже если Tearing не будет проявляться вследствие того, что ОС его подавляет, принудительно используя BackBuffer, все равно анимация не будет плавной. Потому что некоторые желаемые кадры окажутся пропущены, а другие — отображены дважды.
И если не заботиться о синхронизации — то кадры, передаваемые видеокартой, будут содержать желаемое изображение с вышеописанными искажениями (Tearing). Даже если Tearing не будет проявляться вследствие того, что ОС его подавляет, принудительно используя BackBuffer, все равно анимация не будет плавной. Потому что некоторые желаемые кадры окажутся пропущены, а другие — отображены дважды.
Вы правы, но статья не об этом, попробуйте в игре отключить вертикальную синхронизацию, разницы почти не заметете.
А на ZX-Spectrum 48 разработчики умудрялись прорисовать всю графику во время обратного хода луча :)
А на ZX-Spectrum 48 разработчики умудрялись прорисовать всю графику во время обратного хода луча :)
>Если обновление экрана, например, отрисовка какого-либо графического эффекта, происходит за один фрейм — такой эффект называют фреймовым (one-frame). Например, фреймовый скролл — прокрутка экрана со сдвигом изображения каждые 1/50 секунды (для отсутствия искажений картинки при этом требуется учёт временны́х параметров развёртки). Так как ZX Spectrum не имеет аппаратных средств для быстрой обработки графики при относительно невысокой производительность процессора, фреймовые эффекты считаются показателем высокого уровня программирования и качества кода.
speccy.info/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC
speccy.info/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC
За время обратного хода луча много не прорисуешь. В играх и демках высшего класса все делалось еще хитрее. Рисование графики организовывалось таким образом, чтобы оно не прыгало по разным местам экрана, а шло сверху вниз. В результате можно рисовать графику «под лучом» так, чтобы текущее положение луча всегда было выше, чем рисуемый в данный момент участок экрана. Таким образом все время кадра можно безопасно использовать для рисования.
Или, при обновлении изображения один раз в 2 кадра, можно еще было рисовать «над лучом», вдогонку ему.
Недавно для Спектрума вышла игра «Sea Dragon», автор — Андрей Жиглов. Тип — горизонтальный скроллер. Я участвовал в разработке в качестве тестера. В игре была применена технология рисования «под лучом», обеспечивая плавную анимацию с обновлением изображения каждый кадр почти по всему экрану.
Или, при обновлении изображения один раз в 2 кадра, можно еще было рисовать «над лучом», вдогонку ему.
Недавно для Спектрума вышла игра «Sea Dragon», автор — Андрей Жиглов. Тип — горизонтальный скроллер. Я участвовал в разработке в качестве тестера. В игре была применена технология рисования «под лучом», обеспечивая плавную анимацию с обновлением изображения каждый кадр почти по всему экрану.
> Недавно для Спектрума вышла игра…
Еще есть спрос????
Еще есть спрос????
Так это же не ради спроса делается, а просто нравится людям. Некоторые вон до сих пор под DOS на asm'е пишут всякие прикольные вещи, вроде проигрывания мелодий на двигателе флоппика.
А вот так если подумать, для демомейкеров довольно интересной платформой может стать GBA. Всё-таки относительно мощное устройство, возможностей прилично, и при этом GBA-демки могут быть запущены на абсолютно любом устройстве, где есть 200МГц+ процессор. GBA-эмуляторы успешно работают на ПК (все популярные ОС включая DOS), PSP, Android-смартфонах, iPhone/iPad, NDS, 3DS, PS2, PS3, и конечно же на самих GBA без изменения даже единого байта кода! Вот уж поистине идеальная платформонезависимость, write once — use everywhere. Никакой Java даже не снилась такая универсальность и такое количество платформ.
Опять же, SDK есть, даже ещё и с отладчиком-эмулятором, есть кое-какие библиотеки.
А вот так если подумать, для демомейкеров довольно интересной платформой может стать GBA. Всё-таки относительно мощное устройство, возможностей прилично, и при этом GBA-демки могут быть запущены на абсолютно любом устройстве, где есть 200МГц+ процессор. GBA-эмуляторы успешно работают на ПК (все популярные ОС включая DOS), PSP, Android-смартфонах, iPhone/iPad, NDS, 3DS, PS2, PS3, и конечно же на самих GBA без изменения даже единого байта кода! Вот уж поистине идеальная платформонезависимость, write once — use everywhere. Никакой Java даже не снилась такая универсальность и такое количество платформ.
Опять же, SDK есть, даже ещё и с отладчиком-эмулятором, есть кое-какие библиотеки.
Круто, хорошая пища для ума. Сегодня просто не укладывается в голову, как можно создавать игры с 16K оперативки!!!
Там не 16К, а 48К минимум, а максимум — около мегабайта. Но на самом деле много и не нужно. У Z80 высокая плотность кода. При скудном разрешении графики для ее хранения тоже не нужно много памяти. Слишком много памяти — это даже вредно, потому что медленный процессор просто не успеет обрабатывать всю информацию, если ее так много, что она не влезает в стандартную память (48К или 128К).
UFO just landed and posted this here
Какой-то ну совсем уж не оптимальный код в примерах.
Давайте лучше про эффекты интересные :)
Давайте лучше про эффекты интересные :)
Я ожидал увидеть самое мясо — избавляемся от црт, ужимаем все по максимуму и т.д. А тут даже разрешение картинки в int :( Т.е. это не демо
P.S. Кажется, мясо уже было на хабре…
P.S. Кажется, мясо уже было на хабре…
Sign up to leave a comment.
Немного о создании демок, часть 1