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 байт друг за другом? И как ты будешь на следующую строку переходить (код)? Хуже только у АлКо получилось... =)

от: SMT
кому: All
дата: 19 Jan 2006
Hello, breeze > а чего в 0.33 убрали ? поигрались, и хватит. всё равно софт никто не пишет

от: Andreas Kaiser
кому: All
дата: 19 Jan 2006
Hello, lvd lvd> Очень даже линейность, сравни с родным режимом. Определение твоей линейности в студию. lvd> А ты что же предлагаешь, делать строки по 128 байт друг за другом? И lvd> как ты будешь на следующую строку переходить (код)? Хуже только у lvd> АлКо получилось... =) Я ничего не предлагаю, я хочу понять, какого типа линейность ты нашёл в предложеном варианте. Мало того, надо будет каждый раз проверять выход за границы строки (LD HL,#407F; INC L). То, что это лучше предложения AlCo я согласен был с самого начала.

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




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

Похожие статьи:
Вступление - Редакция газеты "NICRON"приносит свои извинения за запоздалый выпуск газеты.
О дураках - наблюдения, сделанные на улице, в транспорте, в иных местах.
События - demoparty Millennium и Paradox. Краткий отчет.
The Art of Spectrum Coding - Chapter I
Список BBS - Список работающий BBS.

В этот день...   8 мая