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, надо
использовать их со стороны железа по своему.




Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Интервью - FATALITY.
О дураках - наблюдения, сделанные на улице, в транспорте, в иных местах.
Программинг - дизайн исходных кодов: основные требования к листинг программы, ориентированной на широкую публику.

В этот день...   7 декабря