ZXNet эхоконференция «code.zx»
тема: 16 colors - roxxx!
от: Oleg Golenkoff
кому: All
дата: 18 Jan 2006
Hello, All
прочитал в IG8 про режим 16 colors, посмотрел игрушку (PANG) - заинтересовало
:rolleyes: хотел разобратся и... :mad:
мдя... AlCo конечно рулит :rolleyes: но нет ли у кого-нибудь нормального
примера как вывести простой спрайт (сконверченный из той-же долбанной bmp-шки
?) а то как я ни тужился :D разобратся в сорцах его, но не осилил... :sleep:
от: Andreas Kaiser
кому: All
дата: 18 Jan 2006
Hello, captain cobalt
cap> Лучше бы память имела более линейное строение.
Что значит "более линейной строение"?
от: Alexandr Sinyakov
кому: All
дата: 18 Jan 2006
Hello, breeze
bre> мдяяяяяя................ :o память транжирится не по детски :( если
bre> я правильно понял то I это интенсивность ? то есть яркость ? отсюда и
bre> 16 цветов. и атрибуты у нас теперь не 768 байт, а 768 * 8 = 6144
bre> (#1800) ?
bre> #4000 - 5800 - 1я часть
bre> #5800 - #7000 - атрибуты ? или как ? что т тут неувязочка ?
bre> поскольку с #6000 уже экран 2й ... :rolleyes:
Атрибутами там не пахнет. Для каждой пары точек в байте записаны их цвета. Т.е
если у тебя (#4000)=%10111111, то в самом верху слева у тебя будут светиться
два пиксела - один белый, другой ярко-белый.
(блин, кривое представление цвета в байте - сразу и не скажешь, какой байт за
какие цвета отвечает. Куда удобнее #7F - сразу видно, что один цвет 7 - белый,
а другой F - ярко белый).
Память жрется - это еще ладно, а вот то, что на реале эта схема отнимает
процессора его кровное время - это пипец. AlCo говорил, что процесс тормозится
на треть.
PS [самореклама]: если разочаруешься в этом режиме, переходи на мой. Те же 16
цветов на точку, проц не тормозится, а память вообще внешняя. (кто б мне его в
железе помог реализовать)
от: Andreas Kaiser
кому: All
дата: 18 Jan 2006
Hello, lvd
lvd> Hу например, поскольку в таком режиме выходит 128 байт на строчку
lvd> (просто сумма битов), то можно было бы сделать так: первая строчка по
lvd> адресам $4000-$407f, вторая - по $4100-417f$ и так до 96ой, а с 97ой
lvd> - строчки по адресам $4080-$40FF, $4180-$41FF и так далее. Hу это
lvd> конечно грубо (24кило ибо на 1 экран), но идея примерно такая если бы
lvd> была - было бы здорово.
Я правильно понимаю, что таким способом достигается линейность в смысле
расположения в памяти (нет деления на куски с "провалами"), но не линейность
пикселей (или строк пикселей)? Такой способ удобнее действительно линейного
расположения пикселей в памяти и если да, то чем?
от: Andreas Kaiser
кому: All
дата: 18 Jan 2006
Hello, lvd
lvd> Почему не достигается линейность строк? Каждая строка - это 128 байт
lvd> подряд (а не как у АлКо).
Hу как, по адресу #4000-#407F стоит строка номер 0, по адресу #4080-#40FF cтоит
строка номер 97 (согласно твоему описанию). Потом идёт строка номер 1 и строка
номер 98 и т.д. Какая же это линейность? По-сравненю с предложением AlCo - да,
отдельные пиксели находятся "рядом".
lvd> Преимущества: переход на следующие 2 пиксела - inc l, на следующую
lvd> строку - inc h.
До определённого момента. Что будет, если в HL будет скажем #407F и ты сделаешь
INC L? Куда попадёшь? Я так думаю на новую строку, только вот не следующую "по
списку".
от: Oleg Golenkoff
кому: All
дата: 18 Jan 2006
Hello, SAM style
SAM> Каждый байт в каждой из областей - цвет тех точек, за которые он
SAM> отвечает. Цвет представлен в формате IiRGBrgb. IRGB - цвет левой
SAM> точки в этой паре, irgb - правой
мдяяяяяя................ :o память транжирится не по детски :( если я
правильно понял то I это интенсивность ? то есть яркость ? отсюда и 16 цветов.
и атрибуты у нас теперь не 768 байт, а 768 * 8 = 6144 (#1800) ?
#4000 - 5800 - 1я часть
#5800 - #7000 - атрибуты ? или как ? что т тут неувязочка ?
поскольку с #6000 уже экран 2й ... :rolleyes:
от: lvd
кому: All
дата: 18 Jan 2006
Hello, icebear
ice> Что значит "более линейной строение"?
Hу например, поскольку в таком режиме выходит 128 байт на строчку (просто сумма
битов), то можно было бы сделать так: первая строчка по адресам $4000-$407f,
вторая - по $4100-417f$ и так до 96ой, а с 97ой - строчки по адресам
$4080-$40FF, $4180-$41FF и так далее. Hу это конечно грубо (24кило ибо на 1
экран), но идея примерно такая если бы была - было бы здорово.
от: lvd
кому: All
дата: 18 Jan 2006
Hello, icebear
ice> Я правильно понимаю, что таким способом достигается линейность в
ice> смысле расположения в памяти (нет деления на куски с "провалами"), но
ice> не линейность пикселей (или строк пикселей)? Такой способ удобнее
ice> действительно линейного расположения пикселей в памяти и если да, то
ice> чем?
Почему не достигается линейность строк? Каждая строка - это 128 байт подряд (а
не как у АлКо). В байте пиксели можно расположить как угодно (IRGB.IRGB), всё
равно такая раскладка потребует полного переделывания спека =))
Преимущества: переход на следующие 2 пиксела - inc l, на следующую строку - inc
h.
от: Oleg Golenkoff
кому: All
дата: 18 Jan 2006
Hello, SAM style
SAM> Память жрется - это еще ладно, а вот то, что на реале эта схема
SAM> отнимает процессора его кровное время - это пипец. AlCo говорил, что
SAM> процесс тормозится на треть.
да вот не скажи :mad: то что проц сжирается эт конечно плохо, но вот памяти не
остается вообще, заколупаешся банками щёлкать :confused:
SAM> PS [самореклама]: если разочаруешься в этом режиме, переходи на мой.
SAM> Те же 16 цветов на точку, проц не тормозится, а память вообще
SAM> внешняя. (кто б мне его в железе помог реализовать)
ну вот эт другое дело, я тож подумал что лучше б была внешняя (видео) память, а
кромсать и без того малую часть 48к имхо изврат :sleep:
ps. так а в чём загвозка-то ? неужто здесь нету ассов хардварестроения ?
от: Alexandr Sinyakov
кому: All
дата: 18 Jan 2006
Hello, breeze
bre> ну вот эт другое дело, я тож подумал что лучше б была внешняя (видео)
bre> память, а кромсать и без того малую часть 48к имхо изврат :sleep:
Моя режимина есть в unreal0.32b5 (0.33 надо перекомпилять чтоб была), если есть
желание ознакомиться - вышлю доку и программу для конвертилки bmp. Пока руки
доходят - делаю редактор спрайтов для него.
> ps. так а в чём загвозка-то ? неужто здесь нету ассов
> хардварестроения ?
Асы быстро охладели. Хотя, если мне память не отморозило, CHRV кажется говорил,
что подумает над его реализацией в ATM3 если будет софт.
от: lvd
кому: All
дата: 18 Jan 2006
Hello, icebear
ice> Hу как, по адресу #4000-#407F стоит строка номер 0, по адресу
ice> #4080-#40FF cтоит строка номер 97 (согласно твоему описанию). Потом
ice> идёт строка номер 1 и строка номер 98 и т.д. Какая же это линейность?
ice> По-сравненю с предложением AlCo - да, отдельные пиксели находятся
ice> "рядом".
ice>
Очень даже линейность, сравни с родным режимом.
> До определённого момента. Что будет, если в HL будет скажем #407F и
> ты сделаешь INC L? Куда попадёшь? Я так думаю на новую строку, только
> вот не следующую "по списку".
А ты что же предлагаешь, делать строки по 128 байт друг за другом? И как ты
будешь на следующую строку переходить (код)? Хуже только у АлКо получилось...
=)
от: Andreas Kaiser
кому: All
дата: 19 Jan 2006
Hello, lvd
lvd> Очень даже линейность, сравни с родным режимом.
Определение твоей линейности в студию.
lvd> А ты что же предлагаешь, делать строки по 128 байт друг за другом? И
lvd> как ты будешь на следующую строку переходить (код)? Хуже только у
lvd> АлКо получилось... =)
Я ничего не предлагаю, я хочу понять, какого типа линейность ты нашёл в
предложеном варианте. Мало того, надо будет каждый раз проверять выход за
границы строки (LD HL,#407F; INC L). То, что это лучше предложения AlCo я
согласен был с самого начала.
от: SMT
кому: All
дата: 19 Jan 2006
Hello, breeze
> а чего в 0.33 убрали ?
поигрались, и хватит. всё равно софт никто не пишет
от: Andreas Kaiser
кому: All
дата: 19 Jan 2006
Hello, lvd
lvd> Hу и вот, прежде чем обсуждать строение экрана, хорошо бы себе
lvd> представлять, как пишется код под дефолтный экран.
Я не обсуждаю, я спрашиваю. Знаки вопроса ни о чём не говорят?
lvd> Итак - ЗАЧЕМ проверять выход за границу строки?
Hезачем, ты прав :)
от: Andreas Kaiser
кому: All
дата: 19 Jan 2006
Hello, lvd
lvd> Вот ещё =)
Hу значит нелинейна :)
lvd> Сразу видно, что ты на спек ничего никогда не писал.
Я последний раз на Спектрум писал 12 лет назад :)
lvd> Да будет тебе известно, что выход за границы строки никто никогда не
lvd> проверяет!А если и проверяет, то делает это далеко не с адресами!
Это был простой пример, что бы не писать много. А как понять игру слов "никто
не проверяет... а если и проверяет...". Так проверяют или нет? И что будет,
если не проверять выход за границу строки в описаном тобою режиме (только об
этом режиме речь идёт).
от: Oleg Golenkoff
кому: All
дата: 19 Jan 2006
Hello, SMT
SMT> поигрались, и хватит. всё равно софт никто не пишет
мдя... :o весомый аргумент, хорошо! а где тогда взять версию что поддерживает
:confused:
от: lvd
кому: All
дата: 19 Jan 2006
Hello, icebear
ice> Определение твоей линейности в студию.
ice>
Вот ещё =)
> Я ничего не предлагаю, я хочу понять, какого типа линейность ты нашёл
> в предложеном варианте. Мало того, надо будет каждый раз проверять
> выход за границы строки (LD HL,#407F; INC L). То, что это лучше
> предложения AlCo я согласен был с самого начала.
Сразу видно, что ты на спек ничего никогда не писал. Да будет тебе известно,
что выход за границы строки никто никогда не проверяет! А если и проверяет, то
делает это далеко не с адресами!
Hа спеке основную проблему при рендеринге в экран составляет шаг на следующую
строку, и выполняется следующим кодом:
┌─- code ───
inc h
ld a,h
and 7
ret z
ld a,l
add a,32
ld l,a
ret c
ld a,h
sub 8
ld h,a
ret
└── code ───
В предложенном мною варианте останется только inc h, с проверкой на достижение
середины экрана, которая будет проскакивать куда как реже. Hу или не середины
экрана, а трети (чтоб по маскам проверять).
ЗЫ: объяснять очевидные вещи завязываю...
от: lvd
кому: All
дата: 19 Jan 2006
Hello, icebear
ice> Я последний раз на Спектрум писал 12 лет назад :)
ice>
Hу и вот, прежде чем обсуждать строение экрана, хорошо бы себе представлять,
как пишется код под дефолтный экран.
> Это был простой пример, что бы не писать много. А как понять игру
> слов "никто не проверяет... а если и проверяет...". Так проверяют или
> нет? И что будет, если не проверять выход за границу строки в
> описаном тобою режиме (только об этом режиме речь идёт).
Итак - ЗАЧЕМ проверять выход за границу строки?
от: Alexandr Sinyakov
кому: All
дата: 19 Jan 2006
Hello, SMT
SMT> ну, или у дядюшки Сэма попросить из старых запасов ;-)
Зачем из запасов? Она же тут на форуме лежит:
http://zx.pk.ru/attachment.php?attachmentid=1852
> пока работает только в filter=double, driver=ddraw/gdi
от: SMT
кому: All
дата: 19 Jan 2006
Hello, breeze
bre> хорошо! а где тогда взять версию что поддерживает
ручками откомпилировать. ну, или у дядюшки Сэма попросить из старых запасов ;-)
от: Oleg Golenkoff
кому: All
дата: 25 Jan 2006
Hello, SAM style
SAM> Зачем из запасов? Она же тут на форуме лежит:
ну что я могу сказать? посмотрел! интересно! круто! HО! всё-таки хотелось бы
иметь хардварную версию, поскольку эмуль, это конечно гуд... но... :sleep:
от: Alexandr Sinyakov
кому: All
дата: 25 Jan 2006
Hello, breeze
bre> всё-таки хотелось бы иметь хардварную версию, поскольку эмуль, это
bre> конечно гуд... но...
Всю логику моей схемы могу на пальцах об'яснить - какие сигналы с чем
AND-OR-XOR'ить и для чего что нужно. Вероятно, какой - нить хардварщик покруче
меня и вделает ее себе в комп.
от: Oleg Golenkoff
кому: All
дата: 26 Jan 2006
Hello, SAM style
SAM> Всю логику моей схемы могу на пальцах об'яснить - какие сигналы с чем
SAM> AND-OR-XOR'ить и для чего что нужно. Вероятно, какой - нить
SAM> хардварщик покруче меня и вделает ее себе в комп.
мдя :) но я бы предпочёл писать на реалке а не на емуле :(
от: Александр Солодков
кому: All
дата: 24 May 2006
Hello, breeze
А вот если бы хардварщики на пару с программерами работали, то можно былобы
получить что-то стоящее! Как-то давно пытался я придумать графический режим,
чтоб z80 смог его РЕАЛЬHО осилить. Экран был в формате 3color - т.е 6144-RED +
6144-GREEN + 6144-BLUE
Вот например:
Вывод байта по маске на стандартный экран
LD A,(DE)
INC DE
AND (HL)
LD A,(DE)
INC DE
OR (HL)
LD (HL),A
INC L
Вывод на 3color экран
LD A,(DE)
LD (HL),A *
LD A,(DE)
LD (HL),A *
LD A,(DE)
LD (HL),A *
LD A,(DE)
LD (HL),A *
INC E
INC L
А дело тут в организации видеопамяти и видеоустройства!!!!!!!!!!!!!!!!!!!!
Видеостраницы размером 16Кб располагаются вместо ПЗУ (всего их минимум 6 - для
двух экранов):
RedPage0,GreenPage0,BluePage0
RedPage1,GreenPage1,BluePage1
В приведенном примере используется так называемый MaskReg, при помощи которого
задаётся
маска!
Сначала в управляющем видеопорту включаем бит "дополнительного управления
командами z80"
Изначально вместо памяти по всем адресам 0..16384 подключен регистр маски
MaskReg
Видеоустройство после команд отмеченных звёздочкой переключает страницы!
LD A,(DE) - из той-же видеопамяти (выше 6144 Кб) берем предварительно
записанные по страницам данные
LD (HL),A * - Записали в MaskReg, сработала логика видеоконтроллера,
переключились на страницу RegPage0 (или RedPage1 - в зависимости от текущего
экрана 0 или 1 :-)
LD A,(DE) - Считали часть спрайта из RegPage0
LD (HL),A *- Записали в RegPage0, сработала логика видеоконтроллера,
переключились на страницу GreenPage0
LD A,(DE) и так далее...
LD (HL),A *
LD A,(DE)
LD (HL),A *
INC E
INC L
Hа самом деле получая в руки только простейшие команды от Z80, надо
использовать их со стороны железа по своему.
|