Если что обращайтесь. Имею художественное образование)
Здесь помогал кирпичи рисовать) https://zx-pk.ru/threads/32119-batty...=1#post1085282
Вид для печати
Если что обращайтесь. Имею художественное образование)
Здесь помогал кирпичи рисовать) https://zx-pk.ru/threads/32119-batty...=1#post1085282
Отлично! Нужно найти общий стиль рисовки. Я очень сейчас стараюсь сделать очередную версию демки, нужно будет её посмотреть и скорректировать направление моего вялого художественного вектора.
Очень много времени уходит на рисование спрайтов. В основном из-за того, что после переноса в демку они смотрятся либо слишком "тяжело", либо чужеродно. Спрайт отправляется в корзину.
Похоже уже на игру? Пробел включает беготню!
Вложение 80051
На телевизоре выглядит отлично:
Вложение 80053
Ну и бегает довольно шустро )))
Вложение 80055
1) Сначала следует очистить память, и только потом включать туда экран.
2) Бывают РК-шки с другой клавиатурой (Электроника КР-02/-03) ;) https://zx-pk.ru/threads/9653-radio-...po-klonam.html
В ПЗУ у них изменённая процедура опроса клавиатуры.
https://disk.yandex.ru/d/yXYBW39y3Lj...2%D1%81%D0%BA) <== внимание, на схеме клавиатуры перепутаны XP1-XP2. Ориентироваться на количество линий: 8+1 и 11+1.
Спасибо, исправлю!
Тьма модификаций, за всеми не угонишься, поэтому за основу взял Радио 86РК, портировать в последующем можно, но портировать пока нечего. Только-только скелет гомункула формируется в жутких муках.
- - - Добавлено - - -
Интересно... Тут картинка растянулась вширь, и пиксели стали такими, как надо:
https://zx-pk.ru/attachment.php?atta...3&d=1704733026
А здесь наоборот, не смотря на то, что в строке 7 линий, пиксели еще сильнее растянуло:
https://zx-pk.ru/attachment.php?atta...5&d=1704735689
Пытался найти инфу на форуме, но потонул во флэйме. Можно в двух словах, как это работает, и видно ли сие в эмуляторах?
Назревают два события:
1. Неожиданно просто и быстро получилось прикрутить карту уровня, поэтому скоро я окунусь в рисование спрайтов с головой. Заодно, хотелось бы изучить эти эффекты.
2. Очень надеюсь, что через пару недель (не сглазить бы) решится вопрос с платой, и я начну собирать железку. А значит тоже в какой-то степени смогу потестировать цвет.
Hammer, если что, я делал какие-то наброски для конвертирования графических файлов в псевдографику РК и Апогея. Если актуально - найду.
Не, не надо, тут подбор и перерисовка спрайтов занимает гораздо больше времени, чем конвертирование. Пока бессмысленно.
Получилось, и очень хорошо выглядит в эмуляторе тоже. Появляется глубина даже у совсем маленьких спрайтов. Но нужно отрисовывать спрайты сразу на двух экранах, и с минимальной задержкой, иначе появляется эффект размытия. Вообще практически параллельно надо спрайты рисовать.
скролл для бега гуглозаврика. Скорость на всю. https://cloud.mail.ru/public/PqL6/8i1S5L45h
Если успею, сделаю для сравнения с двойным буфером экрана чтобы минимизировать рывки и дерготню.
https://cloud.mail.ru/public/Ytbe/senN2PrQ7 А вот с привязкой по началу кадра (пока что без второго экрана). Можно заметить забавные артефакты с кактусом )))
к слову о написании игр. Как по мне, было бы весьма неплохо создать (хоть какую-нибудь) базу спрайтов, а до кучи и разных подпрограмм для работы с изображениями, клавиатурой и т.п. BASIC ведь почему прост? Там каждая команда, это, по сути, функция. Хотя ладно, на счет функций я загнул, это уже готовый графический язык получится. Но библиотку спрайтов и вправду было бы неплохо сделать, чтобы тем, кто в художествах вообще ни ногой, было хоть что-то перед глазами. Ну и наверное отдельную тему для этого, если идея найдет откликнувшихся... А то я замаялся искать приемлемый спрайт персонажа для экрана РК. Пока в одной игре на tandy 200 не увидел. Ну и все равно подгонять пришлось...
Ну это должен родиться некий движок с хорошим описанием. А пока его нет, очень помогает книга "Программирование на языке ассемблера для микропроцессоров 8080 и 8085, Л. Левенталь". И все равно, даже готовые решения/подпрограммы всегда спорны, всегда требуют адаптации в конкретный код.
Добро пожаловать в мой мир )))
Я про это сразу упомянул, как только влился в процесс. Делать это надо не совсем так. Надо нанять художника, который нарисует стартовый ассет. Но это позже. Сначала нужно пощупать спрайты за вымя, погонять их, понять наиболее выгодную разметку для экранного пространства.
Вот очередная порция рассуждений на эту тему )
Как показать больше движения, используя меньше графики? Единственный способ, использовать параллакс - объекты движущиеся в одном направлении должны иметь разную скорость. Те, что дальше от зрителя, должны двигаться медленнее.
А какие это должны быть объекты?
Пара разных облаков, звёзды, кроны деревьев уходящие в дизеринг к стволу, очертания гор, город и т.д.
Пикселей мало, значит основные спрайты не должны быть огромными. А какого размера? А хрен его знает...
И вот только через тесты можно подобраться к этим величинам.
Это скроллерки, а ведь по программированию гораздо проще сделать графическую новеллу! Но тут придётся отталкиваться от мастерства художника и сценариста.
Вобщем я считаю, что первым делом нужно создавать базу идей к играм. Не портов с других платформ, а именно самобытных сценариев.
Вот я писал для 3Д сценарий, но пне кажется, его можно и на РК реализовать в повествовательном стиле.
3022 год, инженер на небольшом ремонтном корабле был отправлен к астероиду, для приведения в порядок систем ретрансляции видеосигнала.
Астероид диаметром 138 метров, покрыт кратерами, скалистыми образованиями, наблюдается периодическая активность гейзера, где-то здесь находится погибший астронавт. На орбите астероида летает небольшой спутник-наблюдатель. Спутник имеет интеллект, есть отчёт о потере управления спутником.
Вскоре после того, как ретранслирующее оборудование было установлено и успешно запущено, астероид посетил неизвестный корабль, начались аномалии в работе оборудования.
Задача инженера - восстановить работу ретрансляторов. Для этого нужно выявить причины аномалий и отремонтировать спутник.
По мере восстановления систем ретрансляции с ним на связь в режиме видеоконференции выходят отдельные персонажи, которые помогают инженеру решать головоломки и снабжают его необходимой информацией.
* Спутник - это живой мозг извращенца и матершинника, заключённый в стеклянную капсулу, жизнь поддерживается за счёт энергии двух солнечных батарей, спутник имеет один вялый манипулятор. Органически мозг цел, но от одиночества имеет проблемы социального характера
** Про пилота мало что известно, он в самом расцвете сил, когда-то имел военный статус "Архангел", в настоящее время соглашается на контракты гражданских организаций, предпочитает работать один и в отдалённых регионах космоса.
Самый важный вопрос - нафига это надо, если распоследняя ардуина мощнее по всем характеристикам? Ну... Это мостик, по которому артобъекты субкультуры могут переходить в сознания других людей. Заражение рационально производить посредством геймплейных видеороликов. Это весело и интересно!
У меня это почти готово и меня это полностью удовлетворяет. Хотя да, многим хотелось бы целиком на асме, многим целиком на си... Я для себя сделал симбиоз ассемблера и си.
Тут очень интересный и философский вопрос. Многие на протяжении всего времени (более 40 лет) поносили бедный рк86 и вдоль и поперек, мол самая ущербная платформа каких видывал свет.... Но я как то наблюдал и за остальным.....Специалист, Орион... Много ли программных шедевров в виде красочных игр легенд? А вот именно, или нет или на пальцах посчитать.
А вот здесь в точку! Вжись не возьму ардуйню и не стану в нее играть, почему? Любой дурак напишет на нее игру.... Это же крайне неинтересно!! Берешь любой esp32 и творишь на нем любой эмуль видеоигры.... Ну неинтересно же!! А вот берем вм80 с частотой до 3х МГц и пишем интереснейшую игру. И мозг разминаешь и понимаешь что пишешь самую интересную игру в мире, так как лишь немногим удается реализовать на этом что то играбельное.
Тут как посмотреть. Вот появились мелкие и очень удобные I2C экраны, сразу же появился Ардубой, появились клавиатуры на тактовых кнопках... Сейчас адрубои расхватывают модуль, который эмулирует I2C экран с выводом на телевизор/монитор, мелкий экран, говорят, неудобно, говорят... Ничего не напоминает? Иногда кажется, что они скоро дискеты и картриджи изобретут. И интерес ведь не снижается, а только растёт! Очень прикольное явление само по себе.
Появляется в итоге одноплатный компьютер с клавиатурой и выходом на монитор. Ну есть у нас такой уже))) Можно даже ESP воткнуть вместо ВВ55 для математики и общения с внешним миром, или вместо ПЗУ при желании.
Я тем временем сделал таки второй экран, он пока правда безбожно глючит. Думаю, как теперь делать анимацию самого спрайта, а не его графики. Например, прыжок игрока. Видимо придётся доступ к массивам и таблицам придумывать.
NEO SPECTRUMAN, интересная идея :)
Не знаю только, насколько быстро получится на лету конвертить, но думаю, что вывод буфера фиксированного размера должно получиться неплохо оптимизировать.
Не понял только, откуда цифры 10*32 байт? Псевдографика на РК - 128*50... Неполный экран?
Да вообще фиксированный размер очень удобен. Сначала я написал умный вывод спрайта, с циклами и подсчётом разной фигни, потом всё переделал в пользу скорости. У меня получился вывод спрайта 8х4 вот таким:
В HL кладём адрес знакоместа на экране, откуда начнётся прорисовка спрайта, в DE кладём адрес спрайта в памяти. После вывода спрайта вызываем подпрограмму ещё раз, и она заполняет следующий кусок экрана по горизонтали этим же спрайтом. Так можно шлёпать текстуры.Код:SPRITE_8X4_T:
PUSH H
PUSH D
LXI B, line - 7
CALL SPRITE_ROW_8
DAD B
CALL SPRITE_ROW_8
DAD B
CALL SPRITE_ROW_8
DAD B
CALL SPRITE_ROW_8
POP D
POP H
LXI B, 8
DAD B
RET
SPRITE_ROW_8:
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX H
INX D
LDAX D
MOV M, A
INX D
RET
Код выглядит большим и колхозным, но работает быстрее. Видимо всю графику сведу к спрайтам 4х2, 4х4, 6х6 и 8х4.
Мало того, до меня тут немного дошло, что по идее, в нормальных играх нужно использовать (хоть немного) физику прыжка. Объясню что я имею ввиду. Нажали пробел - главный герой должен отреагировать прыжком. Как мы будем это делать? Первое на ум приходит приращивать координату Y до определенного значения а потом ее минусовать. Вот здесь и вылазит главная ошибка. Если обработка героя синхронизирована с выводом спрайтов врагов и фона - получится робот автомат, скорость подъема а затем спуска будет фиксированной что некрасиво и неинтересно. А вспомните супермарио? резкий скачек, ближе к пику прыжка замедление, и спуск, тем быстрее чем ближе к земле.
Сейчас покажу как я реализовал это программно и соответственно примерчик запускаемый.
Ну, может использовать тот же счетчик? В момент прыжка вычисляем смещение в одно знакоместо, на счет 3 смещение на 0,5 знакоместа, такты 6,7 - зависает персонаж, и потом меняем вектор движения и также обратно, сначала на 0,5 знакоместа, потом на 1, пока не встретится препятствие. Я когда питоном баловался, так примерно делал. Но то там...
Надо какую-то функцию к счетчику прикручивать, либо синус, либо параболу, либо сплайн. Так в современных игровых движках анимация устроена, линейное перемещение можно заменить. Но все равно не очень понятно, как себя должен вести спрайт при двойном прыжке. Попробую с импульсом подружиться.
По поводу еще одной идеи для игры. Баскетбол в одну корзину. Но мяч можно держать в воздухе нажимая пробел - мяч получит дополнительный импульс при нажатии. На яндекс играх увидел)
не забывай, что у тебя крайне неторопливый процессор, а потому высчитывать движение по формуле может быть не так практично, чем если заложить готовый алгоритм движения. В качестве примера можно рассмотреть Super Mario для nes - там у процессора всего три регистра (правда два из них индексные), но прыжок выглядит довольно плавно и, как мне думается никаких сложных вычислений там не сделать. Хотя, конечно, видеочип там тоже многое сглаживает. А частота то с РК вроде как одна.
Значения синуса с удобным шагом можно в таблицу записать, и брать оттуда готовое значение, чтобы не считать. Я так на ардуине синусоиду и другие формы сигнала генерил через PWM.
ну в общем, несколько спрайтов. Правда выглядят грубовато в стандартном режиме РК, а вот в 44*7 может и ничего будет. Надо еще учитывать что спрайты в формате РК будут несколько худее, чем на рисунке. Формат изображения 90*50 пикселей. Мне в gimp нормально работать, так что масштабированием я не занимался. В фотошопе тож нормально будет видно при увеличении, или в paint.net. Содрано с "CRACKY mini" (TANDY200)
https://disk.yandex.ru/i/mZzUkrh5zQANVA
Если мелковато - извините. Но суть все равно ясна.
Вот таблица для синуса, которую я использовал для генерации 8-ми битного звука:
Смысл такой, линейная позиция - это индекс для таблицы. Например, если у нас весь прыжок описывается значением от 0 до 7, то значение нужно отмасштабировать до диапазона таблицы. Значит делаем побитовый сдвиг линейного значения влево 5 раз. А полученную из таблицы цифру наоборот сдвигаем вправо. Сдвиг влево - это умножение на два, сдвиг вправо - деление на два. Таким образом подбираем нужные коэффициенты. Работает быстро, без шума и пыли )Код:sine:
db $00, $00, $00, $00, $01, $01, $01, $02,
db $02, $03, $04, $05, $05, $06, $07, $09,
db $0A, $0B, $0C, $0E, $0F, $11, $12, $14,
db $15, $17, $19, $1B, $1D, $1F, $21, $23,
db $25, $28, $2A, $2C, $2F, $31, $34, $36,
db $39, $3B, $3E, $41, $43, $46, $49, $4C,
db $4F, $52, $55, $58, $5A, $5D, $61, $64,
db $67, $6A, $6D, $70, $73, $76, $79, $7C,
db $80, $83, $86, $89, $8C, $8F, $92, $95,
db $98, $9B, $9E, $A2, $A5, $A7, $AA, $AD,
db $B0, $B3, $B6, $B9, $BC, $BE, $C1, $C4,
db $C6, $C9, $CB, $CE, $D0, $D3, $D5, $D7,
db $DA, $DC, $DE, $E0, $E2, $E4, $E6, $E8,
db $EA, $EB, $ED, $EE, $F0, $F1, $F3, $F4,
db $F5, $F6, $F8, $F9, $FA, $FA, $FB, $FC,
db $FD, $FD, $FE, $FE, $FE, $FF, $FF, $FF,
db $FF, $FF, $FF, $FF, $FE, $FE, $FE, $FD,
db $FD, $FC, $FB, $FA, $FA, $F9, $F8, $F6,
db $F5, $F4, $F3, $F1, $F0, $EE, $ED, $EB,
db $EA, $E8, $E6, $E4, $E2, $E0, $DE, $DC,
db $DA, $D7, $D5, $D3, $D0, $CE, $CB, $C9,
db $C6, $C4, $C1, $BE, $BC, $B9, $B6, $B3,
db $B0, $AD, $AA, $A7, $A5, $A2, $9E, $9B,
db $98, $95, $92, $8F, $8C, $89, $86, $83,
db $80, $7C, $79, $76, $73, $70, $6D, $6A,
db $67, $64, $61, $5D, $5A, $58, $55, $52,
db $4F, $4C, $49, $46, $43, $41, $3E, $3B,
db $39, $36, $34, $31, $2F, $2C, $2A, $28,
db $25, $23, $21, $1F, $1D, $1B, $19, $17,
db $15, $14, $12, $11, $0F, $0E, $0C, $0B,
db $0A, $09, $07, $06, $05, $05, $04, $03,
db $02, $02, $01, $01, $01, $00, $00, $00
Ну так вот... Немного распишу как делать задержки в общем цикле.
До этого создаем 2 массива, первый - координаты прыжка, второй задержка между итерациями.Код:void dino_core(void)
{
if (dino.jump !=1) // если не прыгаем
{
put_sprite_3 = dino.dino_ptr[dino.AnimFrame]; // отрисуем текущий спрайт
put_sprite(dino.x,dino.y); // выведем по координатам
if (dino.AnimFrame==0) dino.AnimFrame = 1; else dino.AnimFrame = 0; // шевелим ногами (меняем спрайты)
}
else
{
jump_delay--; // уменьшаем задержку прыжка
if (jump_delay == 0) {// достигла 0
jump_delay = di_jmp_dl[dino_jump_pointer];// обновим задержку с нового места массива
put_sprite_3 = dino_empty;// пустой спрайт
put_sprite(dino.x,dino.y);// затрем предыдущее состояние
dino.y = dino_jump[dino_jump_pointer];// обновим новую координату по y
put_sprite_3 = dino.dino_ptr[dino.AnimFrame];// обновим спрайт
put_sprite(dino.x,dino.y); // отрисуем в экран
if (dino_jump_pointer!=8){ // достигли конца координат прыжка и его задержки?
dino_jump_pointer++;// если нет то следующий
}
else
{
dino.jump =0; //если да то снимаем флаг прыжка
dino.busy =0;// снимаем флаг запрета опроса кнопок
}
}
}
}
unsigned char dino_jump[9] = {16,12,11,8,8,8,14,16,18};
unsigned char di_jmp_dl[9] = { 1, 2, 2,3,7,5, 3, 2, 1};
Как видно, координата 8 (что посерединке, 4 элемент массива) самая затяжная (задержка 7 циклов) ибо является переломной в физике .. типа дальше падаем вниз.
Да, координаты по у в рк чем выше экран тем ближе к 0, и еще... запустив пример, вы увидите почему задержка в циклах такая маленькая. Игровой процесс оброс кактусами скроллом прыжками и прочим... задержки минимальны... увы проц совсем слаб.
что такое 1 цикл? а вот...
сие есть один цикл. Еще добавится птеродактиль и опрос на коллизии с птеродактилем и кактусами. Задержку придется еще больше занизить. Помимо всего еще будет отрисовка очков и может быть смена дня ночи.... Вот поэтому я и сделал пальмиру. Там хотя бы можно выпаять кварц штатный 16 мгц и впаять хотя бы 18, и можно спокойно играть в новые игры.Код:while(1)
{
check_player();
cactus_check();
waitHorzSync();
scroll();
cactus_core();
dino_core();
}
https://cloud.mail.ru/public/PqL6/8i1S5L45h Загружайте смотрите, принимаются замечания. По сути основная часть игры готова - осталась ерунда.
Кстати да, о чем писалось выше, обратите внимание - кактус асинхронен скролу земли... Все просто. Кому интересно - выложу движок сюда . Вместе обмусолим , вместе допилим, вместе продвинем в массовость.
- - - Добавлено - - -
Раз уж добрался до компа распишу немного больше полностью по динозаврику моменты.
самое интересное - наверное структура самого динозаврикаКод:void check_player(void)
{
uint8_t kb=255;
if (dino.busy==1) return; // ядро занято отрисовкой и нет смысла жать кнопки и их отрабатывать
kb=0xff;
kb=key_scan(0xfd);// опросим клавиатуру
if (kb==223) //жмем прыжок
{
dino.dino_ptr = Dino[0]; // набор спрайтов для летящего динозаврика (тут статика)
dino.AnimFrame=0;// но начнем с начального тайла
dino.jump = 1; // сообщение ядру что мы прыгаем
dino.busy = 1; // сообщение этой функции в дальнейшем что мы заняты
jump_delay = 1; // костыль (как же без него)
dino_jump_pointer = 0;// указатель на массивы координат Y и задержки
}
if (kb==127)// жмем вниз
{
put_sprite_3 = dino_empty; // todo в разработке
put_sprite(dino.x,dino.y);
dino.dino_ptr = Dino[2];
}
if (kb==239)//run left // немного от оригинала отошел - бежим влево
{
dino.x-=1;
if (dino.x<left_x) dino.x=left_x; // ограничение
}
if (kb==191) // бежим вправо
{
dino.x+=1;
if (dino.x>right_x) dino.x=right_x;
}
//Мы ничего не делаем. Будем просто бежать
if (kb==255) // нет действий от пользователя
{
if (dino.dino_ptr != Dino[1])dino.dino_ptr = Dino[1]; // сменим набор спрайтов на бег
}
}
typedef struct
{
unsigned char busy;
unsigned char jump; //
unsigned char y; //
unsigned char x;
unsigned char **dino_ptr; // выбор спрайтов
unsigned char AnimFrame; // номер выводимого спрайта
}dino_t;
предпоследний указатель немного сложен...да, потому что указатель на массивы
unsigned char **Dino[] = {Dino_stay , Dino_run, Dino_duck,};
а в свою очередь содержимое массива выше это....
unsigned char *Dino_stay[] =
{
dino1,
dino1,
};
unsigned char *Dino_run[] =
{
dino2,
dino3,
};
... где например...
Это уже массив самого спрайта.Код:unsigned char dino1[122] = {
10,12,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x16, 0x07, 0x17, 0x17, 0x15, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x17, 0x17, 0x17, 0x17, 0x17, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x17, 0x17,
0x13, 0x03, 0x03, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x04, 0x17, 0x17, 0x03, 0x03, 0x00, 0x00,
0x00, 0x15, 0x00, 0x00, 0x16, 0x17, 0x17, 0x17, 0x14, 0x00, 0x00, 0x00, 0x00, 0x17, 0x15, 0x16,
0x17, 0x17, 0x17, 0x17, 0x02, 0x00, 0x00, 0x00, 0x00, 0x02, 0x17, 0x17, 0x17, 0x17, 0x17, 0x13,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x17, 0x17, 0x17, 0x13, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x06, 0x13, 0x02, 0x11, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06,
0x10, 0x00, 0x15, 0x00, 0x00, 0x00, 0x00, 0x00
};
Стоит отметить, что такая реализация указателей массивов и структур очень неплохо переваривается самим z88dk. Исполняемый код в таком стиле создается максимально быстрым.
У меня и оба экрана заработали, и функция синуса. Всё быстро бегает, я вполне доволен. Ещё несколько косяков уберу и будет новая демка.
Но! С двойным экраном есть две фичи:
1. Пока мы отображаем один экран, а рисуем на втором, спрайт может поменять свою позицию. Если под спрайтом фон не перерисовывать, то стирать спрайт тоже придется сначала на старом экране, потом на новом. Иначе будет мерцание.
2. Я отрисовываю звезды не каждый цикл, а через раз. И от этого они попадают всегда на чётный экран. Из-за этого звёзды мерцают. Не хочется их в общий цикл ставить, но наверное придётся.
Теперь надо придумывать, как быстро коллизии считать.
Вот ещё интересная графика:
https://www.youtube.com/watch?v=zTH8kSlWJHU
@DDp
@SegaBoy
@Pyk
нашел у себя такое видео
ЧТО ЭТО ЗА МАШИНА?
ничего в упор не помню
https://i.postimg.cc/mkhc72bc/ch0001safe-MOV.jpg
вместо дополнительных 2-х каналов цвета
тут почему то модифицированное подчеркивание с обрезкой шрифта о_О
какойто фпга недоклон?
- - - Добавлено - - -
да и инвертирующего атрибута не видно
- - - Добавлено - - -
или наверрно это те character attribute codes?
которыее 11ссссBH
эти la0 la1 разведены на апогее?
если до тогда это можот расширть возможностти чисто атрибутного режима
(в 3 раза больше цветов)
или наверное хватает одних vsp и lten
почему я только щас обратил на это внимание? о_О
да и блджд из этих la1 la0
можно было сделать еще дополнительную градацию яркости для 2-х каналов
и получить еще 7 цветов
хотя la1 действует только на линии подчеркивания
тобешь только 3 цвета
ну или дополнительное разноцветное подчеркиваание
я тоже думааю что это твоё :)
я ужо скачал схему и глянул Ж)
- - - Добавлено - - -
ну значет зашибись
щас че нить скнонвертирую
с "новыми" возможностями :v2_dizzy_step:
- - - Добавлено - - -
нет я немножкоо общеталсо
для атрибутного режима
это всего лишь 8 дополнительных знакомесст
с character атрибутами
https://i.postimg.cc/L84FVHhD/VW-468...ed-c-codes.png
без
https://i.postimg.cc/vHtd918D/VW-468-dithered.png
и судя из названия
можнно предположить что оно действует только для 1-го символа
с дополнительными не сделанными цветами я тоже общеталсо
ну тогда можно было бы повесить оно на переключение на другой шрифт например
- - - Добавлено - - -
6х4
как раз по максимально возможноой высоте экрана
https://i.postimg.cc/MZDnZGkb/VW-468-dithered-0004.png
2,5 экранов в высоту :)
https://i.postimg.cc/mrBDGxd6/yuubar...hered-0001.png
- - - Добавлено - - -
3.7 экранов в высоту :v2_lol:
https://i.postimg.cc/0251xkxS/mayano...hered-0000.png
чаго нет комодурщики так делают сорокалетиями
https://i.postimg.cc/FFVX2dtm/0002-4...hered-0002.png
- - - Добавлено - - -
https://i.postimg.cc/3RH2VrV4/0002-3...hered-0000.png https://i.postimg.cc/XJc9bS62/0003-3...hered-0000.png
https://i.postimg.cc/cCFYvRHw/0004-3...hered-0000.png https://i.postimg.cc/xj5Lp2R8/0006-3...hered-0000.png
https://i.postimg.cc/hPGTH5yr/0007-3...hered-0000.png https://i.postimg.cc/d0Gy2P3q/0010-3...hered-0000.png
https://i.postimg.cc/XYGFvy0B/0012-3...hered-0000.png https://i.postimg.cc/m26CRyKG/0008-3...hered-0000.png
https://i.postimg.cc/MpCBfKWP/0013-3...hered-0000.png
- - - Добавлено - - -
@SegaBoy, @DDp, @Pyk а кто нить проверял line counter mode на реале?
ато там какаята ахенея в доке
и щас я понимаю вообще как последняя строка знакоместа выплевываетсо первой? о_О
или последняя строка беретсо из 0-й строки?
чо за муть?
кому и нахрена был нужен режим пережевывания шрифта?
- - - Добавлено - - -
картинки из доки
https://i.postimg.cc/qvWC9BSc/07.png https://i.postimg.cc/QM5WsGZ2/09.png
https://i.postimg.cc/DZT4wj28/11.png https://i.postimg.cc/mDyzzYDV/15.png
Проверял. Всё работает как описано. Line Counter Mode 1 сдвигает знакоместо вниз и первой сверху выводится последняя строка. Именно этот режим и выставлен в РК по-умолчанию, как на Figure 13. Первой идёт строка 9, но она гасится режимом подчёркивания. Затем идут видимые строки с 0 по 7 и последняя строка 8, которая тоже гасится. (Если б они не гасились, то вместо строк 8 и 9 выводились бы строки 0 и 1, так как старшая линия LC3 никуда не подключена).
- - - Добавлено - - -
В некоторых программах реализованы символы высотой 9 строк, где первые две строки дублируются. Как раз за счёт сдвига вниз. Первой идёт последняя строка 8, а за ней уже строка 0. Но так как LC3 не задействована то и 0 и 8 это одна и та же строка в знакогенераторе.
каким еще? о_О
- - - Добавлено - - -
наверно
этож надо было так резместить эту строкуЦитата:
uuuu MSB determines blanking of top and bottom lines
(я ее за 10 лез ни разу осознанно не прочитал (хотя мусолил эту доку вдоль и поперек))
че получаетсо если поместить underline на 9...16 строку
автоматом те обнулит 1-ю? о_О
во рукожопы
а mode1 смещение видимо для шрифта
у которого нет горизонтальных зазоров
и чтоб зазоры делать чисто хардварно
- - - Добавлено - - -
вот кстате 6х4
mode 0
https://i.postimg.cc/Y2xq12xn/0002-3...hered-0001.png
mode 1
https://i.postimg.cc/Yqq28cnp/0002-3...0002-mode1.png
- - - Добавлено - - -
это какие?
- - - Добавлено - - -
интересно
а если в 6х4
ждать конца строки а потом вообще тушить видео
делать паузу
а потом включать
может получитсо растянуть КСИ еще на 40 строк и выдать 50Гц?
за это время можно выпоолнять какуюнить процедуру со статическим временем
- - - Добавлено - - -
SegaBoy, а еще не помню
для чисто атрибутного режима (когда мы забиваем на fifo)
для каждого field атрибута все равно нужно ложить баласт в виде обычного символа?
нельзя 2 подряд?
получаетсо чисто атрибутный 6х4 для РК будет тяжеловат по памяти
ДМА вообще вытянит перегон 10К за такой "уменьшенный" фрейм?
- - - Добавлено - - -
а еще когда нету времени между IR и началом отрисовки
для синхронизации с фреймами можно юзать переполнение fifo буфера
сделать например в последних строках переполнениё
а потом ловить FO
чета там делать
а после него ловить IR
Да, проверял, конечно. Именно так и работает, так и в emu80 раелизовано.
Что-то не понял идею? Ждать конца какой строки? Или конца кадра?
Вряд ли, в этом режиме вообще минимальный запас по скорости. Можно посчитать или в emu80 смоделировать и проверить.
Опять не понял идею, если честно, пояснишь чуть подробней?
Если в этом режиме идут два подряд атрибута, то первый запишется в обычный буфер на 80 символов по 8 бит, а второй в фифо на 16 символов по 7 бит. Таким образом при выводе на экран первый атрибут останется атрибутом (старший бит 1), а второй превратится в символ (старший бит 0). Стало быть да, для чисто атрибутного режима нужен баласт.
да именно кадра
(у меня часто не те слова проскакивают)
- - - Добавлено - - -
у тебя будет 2 точки для синхронизации
1-я строка в которой сделали переполнениие fifo (и это вроде должно поставить соответствующий флаг)
2-я это конец фрейма
поставив между ними какой нить счетчик
возможно ты сможешь с большей точностьью находить текущее положение в фрейме (номер такта)
ну и так больше вероятность не пропустить начало фрейма
но нужно будет пожертвовать одной строкой (ну или не одной)
ну и есное дело это не для атрибутного режима
или это может быть рамка между игровым экраном и панелькой
- - - Добавлено - - -
пока я еще тут
подкину еще идею
если для атрибутного режима баласт нужен все равно
можно попробовать хранить столбцы каждого фрейма через 1
а в конце иметь 16 столбцев с символами и атрибутами и перерисовывать только их
сдивагя на 1 байт начала видео рамы туда сюда
A1 A2 A1 A2 A1 C1 A1 C1 - A1 A2 A1 A2 A1 C1 A1 C1
A2 A1 A2 A1 A2 A1 C1 A1 - C1 A1 A2 A1 A2 A1 C1 A1 - C1 - сдвинули начало
A2 A1 A2 A1 A2 C2 A2 C2 - A2 A1 A2 A1 A2 C2 A2 C2 - C1 - поправили последние 16 столбцев и начало 1-го