User Tag List

Показано с 1 по 10 из 526

Тема: Новый принцип устранения клешинга

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #10

    Регистрация
    22.05.2011
    Адрес
    г. Дзержинск, Украина
    Сообщений
    6,829
    Спасибо Благодарностей отдано 
    483
    Спасибо Благодарностей получено 
    663
    Поблагодарили
    513 сообщений
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от inozemcew Посмотреть сообщение
    Вот примерно так это должно работать. Для наглядности накидал небольшую схемку.
    Нажмите на изображение для увеличения. Название: sloi2.jpg Просмотров: 33 Размер: 21.4 Кб ID: 57889
    Почитал повнимательней(бегло пробежался глазами).
    Способ конечно интересный.
    Хотя как задается цвет для спрайтов я не увидел (не дочитал)
    но предположу что или для каждого слоя своя палитра из 2-х цветов
    или что палитра задается как то перед отрисовкой спрайта

    тогда для простоты адаптации нужно
    дополнительный порт для конфигурации
    - выбор типа маски 00111100 и инверсная 11000011.
    - выбор обнулять регистр маски после записи или нет (не всегда же нужно и быстрее)
    - как\чем "обнулять" регистр маски 00000000 или 11111111 или это должно определятся на основе выбора инверсная\не инверсная маска

    дешифрация порта маски должна быть по младшим 8 битам
    для быстрого засылания туда значений при помощи out ($**),a
    так как занимать BC для дополнительного out-а сильно жирно

    и все вроде бы хорошо

    а теперь вопрос как теперь стирать и перемещать то что нарисовано где то там в слое который отображается поверх?
    или нули маски будут и стирать содержимое слоя при повторной записи?

    а еще нужно чтоб спрайты не мигали поверх фона

    и тут вся эта конструкция начинает внезапно увеличиваться в размерах
    уже нужен как минимум 2-й экранный буфер
    и больший разбор и изменение кода

    и в конечном итоге под этот новый видеорежим
    придется переписывать весь вывод графики

    хотя вот какая нибудь automainia переделается на ура
    но оно того стоит??
    и есче

    что делать с играми которые сначала рисуют в бекбуфер?
    а потом быстро перекидывают экран
    сам буфер может быть и вверх ногами))

    есть игры которые рисуют в бекбуфер
    несколько слоев графики
    а потом сверху игрока
    а потом переносят на экран только несколько знакомест с изображением игрока
    и все в буфере вверх ногами при этом)))

    это сколько нужно будет найти и переписать...

    и кто это будет делать?

    это только на первый взгляд кажется что там подменить процедуру вывода и все
    на практике вылезет столько подводных камней...

    с таким же успехом все это проще переписать под тсконфу
    но под неё что то особо никто ничего и не адаптирует

    и сколько будет этих девайсов 10? 15?

    3Ы: а тем временем spec256 конфа пилиться, вроде как, для ReVerSE-U16
    а разукрашивать игры под неё...
    Последний раз редактировалось NEO SPECTRUMAN; 21.08.2016 в 00:25.

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ответов: 43
    Последнее: 03.10.2015, 07:09
  2. принцип переключения адресных страниц в ПЗУ
    от Руслан в разделе Несортированное железо
    Ответов: 11
    Последнее: 10.04.2013, 16:50
  3. AY принцип формирования сигнала.
    от Руслан в разделе Звук
    Ответов: 5
    Последнее: 29.03.2013, 17:08
  4. Принцип работы M1 на Scorpion
    от TmK в разделе Программирование
    Ответов: 8
    Последнее: 17.08.2009, 15:40

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •