два года назад все было четко по прогнозу
в пятницу дождь
в субботу как выключили — все прошло на ура
в воскресенье чуть до прайзгивинга не дотянули — полил
Что, вот прям ни разу такого не было, что начинали глючить старые демки после добавления новых фич, если что-нибудь по таймингам не сошлось? Надо быть ну очень уж осторожным. С блиттером вообще об этом можно не думать. Как однопоточность против многопоточности.
А зачем мне фон читать при выводе спрайтов (если нет каких-нибудь эффектов полупрозрачности)? Фон я буду восстанавливать одним махом в начале цикла отрисовки нового кадра. Кэш тогда сработает эффективно.
Память блиттеру действительно желательна побыстрее, но вот размер не обязательно нужен больше. Можно ведь и распаковывать на лету (а скорость распаковки непостоянна, что для блиттера значения не имеет). Да и просто собирать из кусочков, особо спрайты, часть которых в разных фазах анимации совпадает.
По решениям имею твёрдое мнение, что сперва удобство, потом изящество. В современной обстановке, само собой, и при проектировании нового (втиснуться в старое железо — особый случай).
Ну вот тсконфа, я ее пилил 2 года, дорабатывал, вроде ниче катастрофически не ломалось.
Не вижу связи между развитием архитектуры и типом графпроца — блиттер или пиксельбуфер.
Опять же, тот же формат дисплей листа из фт812 можно запросто реализовать в блиттере. С т.з. программной модели не будет никакой разницы.
Чтение бэкграунда обязательно.
Вот ситуация: ты рисуешь 3 спрайта 32х32, один по координатам 0,0, второй по 200,200, третий по 16,16. Допустим тебе хватит кеша чтоб не читать фон для 3го спрайта. Усложни задачу — добавь еще 25 промежуточных спрайтов, которые гарантированно вытолкнут кеш.
Относительно блиттера мое мнение таково: он позволяет нарисовать больше объектов за фрейм при большем использовании памяти. Применим в системах, где памяти много и она быстрая.
Пиксельбуфер — более изящное решение.
Я позже покажу пример для фт812, в котором бы лучше справился блиттер — большое кол-во объектов дисплей листа на экране.
Обоснуй.
Если речь о таком развитии, как у «быстрой видеокарты метеора», то конечно ))
Нет, вообще. Чхать на тайминги развёртки и разрешение, на локальные заторы на шине данных. Не поломаешь совместимость с прошлыми фичами. Узлы разных стадий работы с блоком можно заменять и дорабатывать независимо. Добавлять новые форматы блоков, дисплей-листа. Вся система в целом «свободнее»
Чтение бэкграунда обязательно.
При наложении — необязательно, если гранулярность доступа равна пикселю. При восстановлении — фон может оказаться сплошным/градиентом/закэшированным «тайлом» или текстурой. Схему кэша, кстати, тоже проще пилить отдельно и без особенной оглядки на старый софт. Впрочем, это отдалённая перспектива.
Основное преимущество блиттера как раз в том, что развивать его намного удобнее.
Обоснуй.
Если речь о таком развитии, как у «быстрой видеокарты метеора», то конечно ))
кстати, первые два вида чтений необязательны
Чтение бэкграунда обязательно.
Дальше будет больше матчасти и меньше богословия, я надеюсь.
Б-г-словия много, ибо смотри название статьи )
Дальше будет немного философии, потому что сабж для людей незнакомый, непонятный и пугающий.
Однако статьи будут относительно четко разделены на философские и технические.
Блиттер. Вторая стадия болезни. Изобретатель уже осознает, что сил Z80 на новый режим не хватит. Предлагается концепт «видеокарты» на бюджетной FPGA с максимальным количеством SRAM (потому что работать с дешевой и большой SDRAM автор не умеет). «Видеокарта» должна аппаратно двигать тонны пикселей по командам Z80. На этом мысль автора обычно тоже обрывается.
Kek. На этом обычно обрывается (если вообще не проходит мимо) мысль религиозно верующих во спрайты. Основное преимущество блиттера как раз в том, что развивать его намного удобнее. И еще, если уж для спрайтера всё свалено в одну кучу, то и список операций для блиттера также можно сократить до двух пунктов «чтение и запись видеопамяти» (кстати, первые два вида чтений необязательны).
Дальше будет больше матчасти и меньше богословия, я надеюсь. Железяка интересна, хоть и неспектрум :p
Обратите внимание, что некоторые конкурсы реального времени начинаются уже в пятницу 30 июня.
в пятницу дождь
в субботу как выключили — все прошло на ура
в воскресенье чуть до прайзгивинга не дотянули — полил
Чо добавить?.. Да, ты прав во всём.
А зачем мне фон читать при выводе спрайтов (если нет каких-нибудь эффектов полупрозрачности)? Фон я буду восстанавливать одним махом в начале цикла отрисовки нового кадра. Кэш тогда сработает эффективно.
Память блиттеру действительно желательна побыстрее, но вот размер не обязательно нужен больше. Можно ведь и распаковывать на лету (а скорость распаковки непостоянна, что для блиттера значения не имеет). Да и просто собирать из кусочков, особо спрайты, часть которых в разных фазах анимации совпадает.
По решениям имею твёрдое мнение, что сперва удобство, потом изящество. В современной обстановке, само собой, и при проектировании нового (втиснуться в старое железо — особый случай).
Мокнуть! Проходили уже )
Не вижу связи между развитием архитектуры и типом графпроца — блиттер или пиксельбуфер.
Опять же, тот же формат дисплей листа из фт812 можно запросто реализовать в блиттере. С т.з. программной модели не будет никакой разницы.
Чтение бэкграунда обязательно.
Вот ситуация: ты рисуешь 3 спрайта 32х32, один по координатам 0,0, второй по 200,200, третий по 16,16. Допустим тебе хватит кеша чтоб не читать фон для 3го спрайта. Усложни задачу — добавь еще 25 промежуточных спрайтов, которые гарантированно вытолкнут кеш.
Относительно блиттера мое мнение таково: он позволяет нарисовать больше объектов за фрейм при большем использовании памяти. Применим в системах, где памяти много и она быстрая.
Пиксельбуфер — более изящное решение.
Я позже покажу пример для фт812, в котором бы лучше справился блиттер — большое кол-во объектов дисплей листа на экране.
При наложении — необязательно, если гранулярность доступа равна пикселю. При восстановлении — фон может оказаться сплошным/градиентом/закэшированным «тайлом» или текстурой. Схему кэша, кстати, тоже проще пилить отдельно и без особенной оглядки на старый софт. Впрочем, это отдалённая перспектива.
Если речь о таком развитии, как у «быстрой видеокарты метеора», то конечно ))
Чтение бэкграунда обязательно.
Б-г-словия много, ибо смотри название статьи )
Дальше будет немного философии, потому что сабж для людей незнакомый, непонятный и пугающий.
Однако статьи будут относительно четко разделены на философские и технические.
Kek. На этом обычно обрывается (если вообще не проходит мимо) мысль религиозно верующих во спрайты. Основное преимущество блиттера как раз в том, что развивать его намного удобнее. И еще, если уж для спрайтера всё свалено в одну кучу, то и список операций для блиттера также можно сократить до двух пунктов «чтение и запись видеопамяти» (кстати, первые два вида чтений необязательны).
Дальше будет больше матчасти и меньше богословия, я надеюсь. Железяка интересна, хоть и неспектрум :p
в пятницу по всем прогнозам погода отличная