Просмотр полной версии : Портирование игр с PC на БК
Разобрался в формате хранения лабиринта в игрушке LastMission.
Вопрос в следующем:
Как лучше масштабировать скрины лабиринрта под под разрешение БК? (320x200->256x256)
т.е. имеется скрин 40x17 тайлов (тайлы 8x8) соответсвенно 320x136.
если пропускать каждый 4й тайл может попортиться картинка, пропускать точки тоже не вариант в байте 4точки одну не выкинешь..
рисовать под это дело редактор лабиринта как-то не хочется..чтобы вручную компоновать похожую картинку (в лабиринте 91 скрин).
может nzeemin подскажет..
Как лучше масштабировать скрины лабиринрта под под разрешение БК? (320x200->256x256)
а не проще (если речь про это)
http://www.worldofspectrum.org/pub/sinclair/screens/in-game/l/LastMissionThe.gif
взять с такого же спека 256х192 ?
Я на PC расковырял, к сожалению в спектруме не силен и к тому же там однобитная картинка с атрибутами.. а на PC один в один 4я палитра БК11.
1. Что если высоту оставить как есть, а ширину пережать в масштабе 1.6 (было 320, станет 200) – каждые 8 пикселей исходного изображения переводим в 5 пикселей на БК, например по схеме 1,1,0,1,1,0,1,0 (единица – берём пиксель, ноль – пропускаем)? Правда, тогда на БК останутся пустые поля со всех сторон экрана, но это даже хорошо для быстродействия.
То что спрайты получатся 5x8 – не вижу особой проблемы. Мне удалось написать достаточно быстрый вывод пропорционального шрифта (каждая буква произвольной ширины). Со спрайтами можно ещё ускорить.
2. Второй вариант – обрезать исходную картинку слева и справа на 32 пикселя, а по высоте умножить на 1.6 (дублировать строки так, чтобы 5 строк превращалось в 8). Тогда высота лабиринта получится не 136, а 218 пикселей и останется 38 пикселей на отображение жизней и прочей информации.
3. И третий вариант – выбрать масштаб 1.25. Тогда по горизонтали 320 пикселей пережимаются в 256 по схеме 1,1,1,1,0 (выкидывается каждый пятый пиксель), а по вертикали масштаб 1.28 – строки дублируются так, чтобы 136 превратилось в 174.
Все три варианта показал на картинках:
1. горизонтальное сжатие 5:8
http://thesands.ru/bk0010/temp/the_last_mission_2a.png
2. по горизонтали обрезаем, по вертикали растягиваем 8:5
http://thesands.ru/bk0010/temp/the_last_mission_2b.png
3. по горизонтали сжимаем 4:5, по вертикали растягиваем 32:25
http://thesands.ru/bk0010/temp/the_last_mission_2c.png
По первому варианту: по краям комнаты встречаются подъемники- отрезать, танк не пролезет.
По второму: для экономии памяти лабиринт запакован и тайлы прорисовываются в нужных местах исключая пустоту.. тайлы 8x8 иногда причудливо стыкуются. просто так каждый четвертый пиксель не уберешь.. в одном байте 4 точки где занимать убранную?
По третьему, у БК не хватит ни памяти ни быстродействия масштабировать картинку на лету. На PC я так и сделал только в большую сторону..
В других палитрах (0 и 11) тоже прикольно:
6632366321
6632266320
1.
По второму: для экономии памяти лабиринт запакован и тайлы прорисовываются в нужных местах исключая пустоту.. тайлы 8x8 иногда причудливо стыкуются. просто так каждый четвертый пиксель не уберешь.. в одном байте 4 точки где занимать убранную?масштабирование – это первый вариант. Спрайты отмасштабированы заранее, вывод на экран делается тайлами 5x8. Да, это сложней и медленней, чем сразу 16-битные слова кидать на экран, но это возможно. В конце концов, отрисовка происходит один раз, лабиринт-то статичный. А анимированные объекты должны скакать не по тайлам, а двигаться плавно по одному пикселю. То есть вывод спрайта с произвольной точки всё равно придётся делать.
2.
По первому варианту: по краям комнаты встречаются подъемники- отрезать, танк не пролезет.с отрезанием – это второй вариант. Если разбить лабиринт на экраны с меньшим «окном», придётся чуть подправить топологию лабиринта, где надо. А можно даже замахнуться на скроллинг.
3.
По третьему, у БК не хватит ни памяти ни быстродействия масштабировать картинку на лету. На PC я так и сделал только в большую сторону..налету ничего не нужно, конечно! По вертикали заранее отмасштабировать все спрайты: было 8 пикселей, стало 10.
/*чуть подправить топологию лабиринта, если надо.*/
Редактор все таки придется делать..я пролистал все скрины в принципе сжимать не нужно, только нужно буквально в каждом скрине в повторяющихся местах убирать колонки.. места правда каждый раз разные.. нужно исключать проходы и всякие механизмы.. а потм запаковать все обратно.
Была мысль докручивать скролингом комнату когда танк к середине подъезжает, но прикинул сколько появится лишних наворотов и одумался.
Кстати можно поточнее по поводу вывода спрайта в произвольную точку..если есть исходник (пока в асм PDP и БК в частности не силен) мысли конечно есть но туманно: арифметическим сдвигом каждое слово в обе стороны хвосты отрезать, а потом кусок соседнего ORом накладывать?
P.S. /for Manwe/
GoodApple.EXE синий смайл в обоих случаях
Вот здесь исходник пропорционального шрифта: http://thesands.ru/bk0010/font-converter/
Идея в том, что каждое 16-битное слово спрайта хранит точки не слева направо, а сверху вниз.
В случае шрифта можно отрисовывать буквы сразу на экран, а в случае игры с лабиринтом лучше сперва нарисовать игровое поле в буфер памяти (он получится повёрнутым на 90 градусов, потому что хранение спрайтов такое). Когда кадр полностью подготовлен, выводить из буфера на экран только изменившиеся тайлы с поворотом на 90 градусов. Поворот – небольшая процедурка, её можно посмотреть в исходниках по ссылке.
т.е. у нас в памяти перевернутый буфер и в нем мы по Y как по X ориентируемся но по точкам.. x+100
Да. Если буфер размером не с целый экран, а поменьше, можно его поплотней уложить. Скажем, если игровая область 136 точек в высоту, то это соответствует 17-ти словам. Значит, в буфере каждый столбец пикселей будет занимать 17 слов и следующий столбец будет начинаться сразу за ним. А если ещё и в ширину игровое поле всего лишь 200 точек, то получаем 6800 байт (15220 в восьмиричной системе). Что очень даже приемлемо. Поэтому первый из предложенных мной вариантов кажется разумным. Надо лишь немного подрисовать спрайты после горизонтального ужатия 5:8
http://thesands.ru/bk0010/temp/the_last_mission_2a.png
P.S. в палитре 11 очень хорошо выглядит! (жёлтый, красный, голубой)
/* Поэтому первый из предложенных мной вариантов кажется разумным. */
Я думаю на этом пока и остановимся, переделывать 91 скрин лабиринта.. тяжко.
Можно сделать переключение палитр, потому что во многих прикольно смотрится.. например в 9й чем-то commodore 64 похоже.
накидал вьювер лабиринта.. чтобы осмотреться.. палкой не бить писал сейчас на коленке
https://yadi.sk/d/Ry7ye5_qW6dv0g
палкой не бить писал сейчас на коленке
Хорошо, тогда будем бить коленкой :)
EXE под БК или под Windows? Просто у меня под рукой сейчас только Мак.
А есть все спрайты выдранные?
под винду.. до бк еще далеко.
спрайтов там мало, гайки, шарики.. в основном тайлы но они особо не смотрибельны.
графику практически всю выдрал..
игрушка вместе с графикой меньше 64 к.. (COM файл) из них 16к заставка.. ничего не упаковано, так видно.
Заставка как все CGA черезстрочно двумя блоками.. сейчас графика куском писишного дампа. Нужно будет под БК переделать
фонты и др. мелочь пока не трогал.. в основном интересен был сам лабиринт.. с ним и разбирался
пока не нашел как хранится порядок следования скринов.. как выяснилось там еще и выход на поверхность есть :).. там они линейно идут не змейкой..
хотя может и не хранится.. 68-змейкой.. 2 вверх.. остальные вправо
Судя по скриншотам, спрайты врагов шириной 14 пикселей, а высота у всех разная, но не больше 16 пикселей.
Посчитал сколько слов надо изменить в буфере, чтобы каждый спрайт сдвинуть на 1 пиксель. Получилось 80 слов для трёх врагов + 30x2 летающая штука + 42x2 гусеничная платформа = 244 слова. Игровое поле состоит из 6800 слов, мы изменяем всего 3.6%.
Вывести 244 слова с поворотом на 90 градусов - это быстро, как напечатать одну строку текста моей процедурой пропорционального шрифта. 25 кадров в секунду сможем выжать, наверное. На IBM PC с CGA явно медленней.
В вьювере лабиринта есть кнопка "Сохранить PRJ".. сохраняет текущую картинку в формате моего конвертера:
https://yadi.sk/d/-lv2CImXGtnzlA
В нем можно отредактировать картинку и экспортировать в БК формат (хоть BIN хоть дамп)
Нужно будет доделать его чтобы дампы спрайтов конвертировать...
Мне бы для разминки какой-нибудь один навороченный игровой экран в формате 40x17 байтов, где каждый байт соответствует одному тайлу экрана и хранит номер спрайта (ноль - пустое место).
Ну и сами спрайты нужны, правильно пронумерованные. Спрайты можно в обычном PNG или GIF.
Тогда смогу написать процедуру отрисовки игрового экрана для тайлов 5x8.
Могу сделать, да хоть все... правда выходные на носу.. за компом не дадут посидеть. А сейчас у нас уже поздовато не успею..
Вьювер так и не запустил? А то бы выбрал экран на свой вкус.. :)
Не, пока не запустил. Сейчас вообще с iPad пишу. Я до Windows-машины редко добираюсь.
В общем, если удастся сделать массив 40x17 для одного экрана и собрать архив со спрайтами – я попробую.
Посмотрел спрайты - они хранятся последовательно (w,h,spr),(w,h,spr),(w,h,spr),(w,h,spr),(w,h,spr). ...
4x16,10x16,8x16.....
может я их сразу в БК формат переведу и в таком же виде дам, или ты их будешь масштабировать? тогда сделаю длинную png шириной 16пикс
выкидываю информацию о размере иначе перекосит:
https://yadi.sk/i/Z8B1Hr9Ja2vDwA
Буду масштабировать в Фотошопе. Если всё заработает и результат удовлетворит по скорости, то подкорректирую ещё спрайты вручную.
а вы в курсе что OperaSoft для написания игр использовала скриптовый движок ?
возможно всю логику работы удастся перенести практически в неизменном (правка координат) виде
а вы в курсе что OperaSoft для написания игр использовала скриптовый движок ?
возможно всю логику работы удастся перенести практически в неизменном (правка координат) видеНе в курсе. Как бы до него добраться? До самого скрипта-то.
заглянул в потроха игры на спеки .....
похоже что никак. у фирмы был автосборщик под разные платформы.
....................
на спеке карта экрана создаётся в буфере 32х17=544
потом оттуда берутся номера тайлов для вывода
Есть ремейк этой игры с исходниками, списывался когда то с автором, это больше реплика, но алгоритм разбора и формирования экранов идентичный насколько помню
http://lastmission.sourceforge.net/
я уже самостоятельно разобрался с форматом хранения карты для экрана.
компрессии нет. картинка составляется из блоков произвольного размера.
описание экрана Z+(x,y,#abcd)*Z
Z;кол-во блоков
x,y; координаты блока на экране
#abcd ; номер блока
вот например блок №#0001
http://b.radikal.ru/b09/1809/3f/6d61163c95f5.png (http://radikal.ru)
для создания такой картинки
http://b.radikal.ru/b27/1809/21/c1bacf1c5133.png (http://radikal.ru)
получается вот такое описание
4
00,15,#0001
08,15,#0001
16,15,#0001
24,15,#0001
я уже самостоятельно разобрался с форматом хранения карты для экрана.
компрессии нет. картинка составляется из блоков произвольного размера.
В livingstone и goody так же сделано, дизассемблировал их.
ну это лишний раз подверждает наличие одинакового набора инструментов
(при создании игр разными авторами)
интересней что в игре два буфера (для хранения номеров тайлов для экрана)
но похоже один не задействован (возможно он применяется в играх со скроллом)
(в LastMission он забит #FF)
при заполнении нового буфера данные сравниваются и пропускаются при совпадении со старым
IX=NEW SCREEN
IY=OLD SCREEN
LD A,(IY+0)
LD L,(IX+0)
CP L
JR Z,NEXTsprite
Тайлы в PNG, три варианта (0,4 и 11 палитры) 256 тайлов 8х8.
screen_40_17.dmp - комната 40х17.
https://yadi.sk/d/159v7ewcupYW1Q
- - - Добавлено - - -
/* картинка составляется из блоков произвольного размера. */
Картинка не-то что из блоков, прописаны координаты и номера тайлов куда их ставить в буфере, чтобы место сэкономить.
то что ты назвал тайлом я назвал блоком. вот и вся разница.
а как назвать кусочки 8х8 (из которых состоит тайл) ?
не спорю.. в принципе так во многих игрушках делали, поэтому так легко и раскопал..
кстати логику можно будет подсмотреть в исходниках порта который выше привели, хотя он под win да и на С написан по поводу памяти и быстродействия там наверно не шибко беспокоились. Чтобы на БК это перевести нужно будет крепко репу почесать.. :)
кстати там вся графика в виде массивов оформлена, ничего выдирать не нужно было.., хотя важен процесс :)
вот сделал понаглядней процесс создания экрана в буфере
http://b.radikal.ru/b25/1809/13/857f332a9291.gif (http://radikal.ru)
http://d.radikal.ru/d39/1809/9d/66fad87f1619.gif (http://radikal.ru)
Да с лабиринтом я уже разобрался, выше уже вьювер выкладывал, можно посмотреть все 92 скрина.
Проблема пока стоит с масштабированием..
В livingstone и goody так же сделано, дизассемблировал их.Вот бы и их портировать :) В детстве мне очень нравились они на IBM PC XT :)
Проблема пока стоит с масштабированием..Проблемы нет. Выложишь спрайты (каждый отдельной картинкой) - сделаю.
update: а, уже выложил? Не заметил сперва. Вечером посмотрю.
Да с лабиринтом я уже разобрался, выше уже вьювер выкладывал, можно посмотреть все 92 скрина.
Проблема пока стоит с масштабированием..
тебе же нужен экран 40 элементов?
а если 1 элемент сделать шириной 6 точек?
тогда получится 240, а нужно 256. (В идеале пропускать каждую 4ю точку). В простом варианте 6 точек на БК не очень удобно выводить, Manwe предложил алгоритм вывода по точкам. Все зависит от того как перекосится картинка и как быстро это будет работать.
Manwe предложил алгоритм вывода по точкам. Все зависит от того как перекосится картинкаНормально перекосится :) Я выкладывал скриншот преобразования 8x8 в 5x8. Вполне симпатично.
и как быстро это будет работать.Я посчитал, что примерно как вывод одной строки текста. Это довольно быстро. Для такой игры достаточно 25 fps, уложимся.
/* for Manwe */
Спрайты нужны? Или хватит лабиринта?
Сейчас изучаю порт для виндов, думаю оттуда графику вытаскивать даже проще будет. Лучше наверное логику по его мотивам писать, чем в ассемблере копаться.
тогда получится 240, а нужно 256. (В идеале пропускать каждую 4ю точку). В простом варианте 6 точек на БК не очень удобно выводить, Manwe предложил алгоритм вывода по точкам. Все зависит от того как перекосится картинка и как быстро это будет работать.
тебе жалко 16 точек? сделай рамку или оставь чорным
/* тебе жалко 16 точек*/
Жалко, их и так мало. Да и пропорции еще больше покосятся.. будет не танк, а головастик :) еще по Y растянуть с 200 до 256
Лучше наверное логику по его мотивам писать, чем в ассемблере копаться.
ну это уже будет игра по мотивам, а не порт.
хотя конечно хозяин - барин. делай как тебе удобней.
(у меня вообще какое-то отторжение к БК, никогда не понимал восхищение этой машиной)
Спрайты нужны? Или хватит лабиринта? Сейчас изучаю порт для виндов, думаю оттуда графику вытаскивать даже проще будет.Я уже начал эту длинную картинку нарезать на спрайты. Пока достаточно.
у меня вообще какое-то отторжение к БК, никогда не понимал восхищение этой машиной16-битный ассемблер с 8 видами адресации и 8 равноправными регистрами общего назначения - это достойно восхищения :) Ну а в прикладном смысле БК не особо блещет - софт обычный, периферия обычная, ничего такого.
толку от великолепного проца если на графику без слёз не взглянешь
толку от великолепного проца если на графику без слёз не взглянешьНеужели настолько плохо? ;)
http://zx-pk.ru/threads/19866-demki-dlya-bk.html?p=978812&viewfull=1#post978812
- - - Добавлено - - -
Тайлы в PNG, три варианта (0,4 и 11 палитры) 256 тайлов 8х8.
screen_40_17.dmp - комната 40х17.Пока вот так получается с ужиманием спрайтов до 5x8.
Не пойму, лабиринт у меня что ли перевёрнут вверх ногами? И по этой комнате непонятно не развернул ли я её зеркально.
Последствия пережимания спрайтов потом устраним (вручную надо будет править каждый спрайт). Пока общий принцип отработаем.
http://thesands.ru/bk0010/temp/screen2.png
Картинка не-то что из блоков, прописаны координаты и номера тайлов куда их ставить в буфере, чтобы место сэкономить.Сделаем так же, но попозже.
Хе, картинка точно вверх ногами :)
По низу болты идут, а возле черепушки зигзаг.. ну при определенной фантазии похоже :)
66358
Еще комнаты (for Manwe):
https://yadi.sk/d/giB2uMWTB0RHMg
Неужели настолько плохо?
очень красиво - да же не верится что это БК )
неужели так динамично и плавно на реальном БК0010-01? Хватает быстродействия?
Музыка видимо наличие звук.ген. необходимо - на моей машинке ничего такого конечно не было (и нет). )))
очень красиво - да же не верится что это БК )
неужели так динамично и плавно на реальном БК0010-01? Хватает быстродействия?С трудом :) Благодаря 4 MHz БК-0011м. В принципе, и под БК-0010 можно эту демку собрать – немного упадёт качество и не будет переключения палитр, всего 4 цвета останется.
Музыка видимо наличие звук.ген. необходимо - на моей машинке ничего такого конечно не было (и нет). ))Паяется из резисторов за один день. Главное, кроме звука нужен контроллер жёсткого диска. На дискету демка не умещается.
P.S. Вот здесь портированные с ДВК на БК игры, может быть и «Страна монстров» есть? http://bk.pictures2.com/gamezz.htm
Меня терзают смутные сомнения.. может нужно писать не для БК11, а для УКНЦ.. тогда ничего масштабировать не нужно,можно даже наоборот в два раза увеличить
У меня стоят аж две штуки, руки все не доходят.. стимула не было
Меня терзают смутные сомнения.. может нужно писать не для БК11, а для УКНЦ.. тогда ничего масштабировать не нужно,можно даже наоборот в два раза увеличить
У меня стоят аж две штуки, руки все не доходят.. стимула не былоIMHO на УКНЦ никто играть не будет, база пользователей маленькая.
Вот лучше посмотри как я сделал показ комнат: http://thesands.ru/bk0010/temp/lastmis1.zip
Это загрузочный БК-шный диск в формате bkd, можно подключить к эмулятору gid или к эмулятору на java (bk2010).
Там в папке ROOMS каждая комната отдельным файлом. Можно ещё добавить, и они тоже будут показываться (только имена нужно дать по тому же принципу, что у имеющихся файлов).
Программа грузит комнату и тут же её показывает, затем следующую. Если не на диске хранить, а сразу все комнаты в памяти, немного побыстрей будет.
Спрайты кривоваты, но можно потом их подправить и будет всё аккуратно.
Работает и на БК-0010 (только палитру не переключает). Скорость нормальная, мне кажется. 4,5 kb свободной памяти остаётся (на БК-0010).
Исходники там же.
/* IMHO на УКНЦ никто играть не будет, база пользователей маленькая.*/
Потому и маленькая, что играть не во что. УКНЦ сейчас на руках не меньше чем БК. Если напишем думаю многие порадуются.. Ну это так в планах.
В принципе с БК на УКНЦ перенести несложно будет. В двухплановом режиме вывод графики похожий будет.
/*посмотри как я сделал показ комнат*/
Выводит быстро, но спрайты смущают. Комнаты статичны их можно хоть с анимацией по блокам выводить, интересно как быстро будут выводиться 5-6 активных объектов по точкам.
В каком-нибудь трансляторе есть условная компиляция? В исходниках порта для виндов есть еще код для консоли DINGU.
Было бы прикольно в одном исходнике сделать код для УКНЦ и БК - наглядно и познавательно.
В 90-ые знал только одного человека с УКНЦ. Она же была дорогущая. Сейчас если у кого и есть, то это коллекционеры. А БК у обычных людей остались как минимум в чуланах.
На счёт условной компиляции не знаю. По-моему, проще потом портировать с БК на УКНЦ, заменив графику.
Вот ещё какая идея пришла:
Лабиринт рисовать спрайтами не 5x8, a 6x8. Получится немного растянуто по горизонтали, но это даже хорошо, потому что исходное изображение слишком вытянуто в высоту (кубики какие-то все с нарушенными пропорциями).
А спрайт пушки рисовать нерастянутым.
Я правильно понимаю, что в игре объекты не пересекаются и не накладываются, всё время летают только по чёрному пространству? Если да, то движущиеся объекты можно отвязать от тайлов и рисовать в любых пропорциях и размерах.
Manwe, а я между прочим сразу предложил такой масштаб.
можно еще по вертикали смасштабировать чтобы глаже было
Manwe, а я между прочим сразу предложил такой масштаб.Ну, отлично, мы пробуем разные варианты! ;)
можно еще по вертикали смасштабировать чтобы глаже былоБудет не глаже, а лишние ступеньки. Я тоже такое сперва предлагал, а потом подумал, что это ещё и в ущерб быстродействию.
Вот что получатся: квадраты, наконец, стали более квадратными :)
Пушка растянулась, но её как раз можно сплюснуть обратно.
66369663706637166372663736637466375663766637766378 6637966380
Если рисовать в таких пропорциях, то на БК-0010 уже не хватит памяти на внутренний буфер. Придётся выводить новую комнату сразу на экран, поверх старой. Это приводит к одной проблеме: сначала целую секунду рисуется лабиринт, а потом уже поверх него появятся враги и начнут двигаться. Видел такое во многих играх, но не знаю, приемлемо ли это. С другой стороны, на БК-0010 можно сделать так, а на БК-0011м по-нормальному.
P.S. зачем форум пережимает 9-килобайтные gif в 22-килобайтные jpg низкого качества - непонятно...
/* Я правильно понимаю, что в игре объекты не пересекаются и не накладываются, */
Да действительно и поэтому у меня в голове крутится назойливая мысль сделать другой алгоритм вывода.. без поворота.
Также прорисовывать каждый бит, при этом можно пропускать 7-8 бит.. потом проворачивать слово на нужное кол-во бит и накладывать ORом.. в теневой экран, потом переключать.
Не нужен будет буфер, нет лишних действий по повороту.. может и быстрее будет или хотя бы памяти больше останется.
/*Вот что получатся: квадраты, наконец, стали более квадратным*/
Картинка действительно лучше стала. Или это JPEG сгладил... :)
/*Видел такое во многих играх, но не знаю, приемлемо ли это. */
Когда я в нее играл на ЕС-1840 так и было и никто не возмущался :)
P.S.
Если танк не трогать он на лифт поместится?
Также прорисовывать каждый бит, при этом можно пропускать 7-8 бит.. подом проворачивать слово на нужное кол-во бит и накладывать ORом.. в теневой экран, потом переключать.
Не нужен будет буфер, нет лишних действий по повороту.. может и быстрее будет или хотя бы памяти больше останется.Теневой экран - это, по сути, и есть буфер. Действия по повороту и проворачивание слова - это примерно одно и то же. Если под спрайты шириной 6 точек отводить место в памяти как для 8 точек, памяти останется меньше.
Я почему предложил такой хитрый алгоритм-то? Потому что проверил все варианты когда работал над процедурами вывода шрифтов. Итог: хранение спрайтов повёрнутыми на 90 градусов - самый эффективный вариант (речь о спрайтах, ширина которых не кратна 8). По скорости проигрыш незначительный.
Ну значит так тому и быть :)
Интересно какая будет скорость с живыми спрайтами.. не у всех врагов поведение "пинг-понг" есть самонаводящиеся.. танк+башня, башня без танка, нужно что бы под математику место осталось.. и учитывать что она тоже будет тормозить.
Ну значит так тому и быть :)Готово, образ диска БК: http://thesands.ru/bk0010/temp/lastmis2.zip
Здесь комнаты перерисовываются без буфера, сразу на экран. Специально чтобы работало на БК-0010. В случае БК-0011м можно делать это во второй странице видеопамяти, как обсуждали выше.
С другой стороны, эффект прикольный. Можно сделать 4 разных процедуры, обновляющих экран в разные стороны, и использовать их в зависимости от того, с какой стороны игрок вошёл в комнату. Может быть так даже лучше, чем с буфером, а то игроку покажется, что всё подвисло на секунду.
Интересно какая будет скорость с живыми спрайтами.. не у всех врагов поведение "пинг-понг" есть самонаводящиеся.. танк+башня, башня без танка, нужно что бы под математику место осталось.. и учитывать что она тоже будет тормозить.Самонаведение - это, по сути, лиейная интерполяция координат с субпиксельной точностью. Не должно особо тормозить. Накидаю завтра пример, пока без проверки коллизий с содержимым комнаты.
P.S. ах, да - кажется, в образе диска не самый последний исходник. Поэтому приложу к сообщению. Расширение .asm лучше переименовать в .mac
Исходник: 66382
Расширение .asm лучше переименовать в .mac
я не знаю чем вы пользуетесь, сверх быстрая компиляция в родной среде ОС RT-11
Эмулятор RT-11 для консоли Windows (http://zx-pk.ru/threads/24755-emulyator-rt-11.html)
/* сверх быстрая компиляция в родной среде ОС RT-11 */
В MACRO-11 не оттранслируется, "гранаты не той системы" ;) Да и было бы что сверх быстро компилировать.
/* линейная интерполяция координат с субпиксельной точностью */
линейная интерполяция подразумевает деление и float, можно наверное просто определять знак приращения для вражины по x и y. Xврага-Xтанка= знак dx..
Xврага-Xтанка=0, а Y нет то dx=0 и наоборот.. так наверно в "КЛАД" сделано.
/* Здесь комнаты перерисовываются без буфера, сразу на экран. */
Для улучшения восприятия можно впереди полосу гнать ("а ля Бортник") чтобы не подумали что это косорукость, а так задумано - экраны перелистываются.
я не знаю чем вы пользуетесь, сверх быстрая компиляция в родной среде ОС RT-11
Эмулятор RT-11 для консоли Windows (http://zx-pk.ru/threads/24755-emulyator-rt-11.html)Компилируем своим компилятором PDPy11: https://github.com/imachug/PDPy11/
У него много хороших фишек:
- мультиплатформенный
- подсветка ошибок прямо в тексте программы (в редакторе Sublime Text)
- мощная арифметика с метками и константами
Manwe, я так понимаю что МАКРО-11 реализована и ещё в каких-то пакетах для разработчиков под современные ОС,
но как писали - нигде не было нормального линковщика. Эмулятор RT-11 работает с файловой системой хоста, вы можете где и как угодно обрабатывать исходник .MAC, затем кидаете его в расшаренную для RT-11 папку и вручную или через bat файл ... из тех кто пользуется (пользовался) недовольных нет )
из тех кто пользуется (пользовался) недовольных нет
Правильно, те, кто недоволен и не пользуется - использует свои собственные инструменты. В которых обычно реализует то, чем недоволен в МАКРО-11.
Manwe, я так понимаю что МАКРО-11 реализована и ещё в каких-то пакетах для разработчиков под современные ОС,
но как писали - нигде не было нормального линковщика. Эмулятор RT-11 работает с файловой системой хоста, вы можете где и как угодно обрабатывать исходник .MAC, затем кидаете его в расшаренную для RT-11 папку и вручную или через bat файл ... из тех кто пользуется (пользовался) недовольных нет )Но зачем? :) У нас просто в Sublime Text редактируешь исходник .mac, затем нажимаешь Ctrl+B и получаешь .bin файл в той же папке.
Самое главное, что указания на ошибки прямо в тексте возникают - нажатием F4 ходишь по ним и исправляешь:
http://thesands.ru/bk0010/temp/PDPy11.png
Правильно, те, кто недоволен и не пользуется - использует свои собственные инструменты.Точно :)
Посмотрел как в исходнике под винду как делается самонаведение, точно так же как я и предлагал, без интерполяций:
if(i->x > Ships[0].x)
{ i->dx = -1;}
else
{if(i->x < Ships[0].x) i->dx = 1;
else
i->dx = 0;}
За один кадр собъект сдвигается либо ровно на 1 пиксель, либо не сдвигается?
/* За один кадр собъект сдвигается либо ровно на 1 пиксель */
Нет, я выше писал к вопросу об интерполяции.. что не нужно никакой линейной интерполяции.. при самонаводящемся враге..
В порте под винду так же..
если враг слева приращение по Х положительное, справа - отрицательное, аналогично по У. Если на одной прямой идет прямо..
/* А приращение чему равно? */
1 пиксель.
Хотя тут возникает вопрос как регулировать скорость перемещения объектов, под виндой все привязано к системному таймеру и даже зная время основного цикла в конце выставляется задержка по разности с ним.. для быстрых машин. У нас быстрых машин нет и таймер можно для другого использовать. Нужно какой-то счетчик пропусков.. например бытрый объект перемещается на 1 пикс. каждый цикл.. который в два раза медленней пропускает 1 цикл и тоже передвигается на 1 пикс. итд. (в свойствах объекта эти счетчики проставить)
1 пиксель.А, ну вот. Я о том же.
Хотя тут возникает вопрос как регулировать скорость перемещения объектов, под виндой все привязано к системному таймеру и даже зная время основного цикла в конце выставляется задержка по разности с ним.. для быстрых машин. У нас быстрых машин нет и таймер можно для другого использовать. Нужно какой-то счетчик пропусков.. например бытрый объект перемещается на 1 пикс. каждый цикл.. который в два раза медленней пропускает 1 цикл и тоже передвигается на 1 пикс. итд. (в свойствах объекта эти счетчики проставить)Это как раз субпиксельная точность, о которой я писал выше. Делается просто, считается быстро. 20 тысяч вычислений в секунду, я полагаю. Типа такого:
ADD #скоростьX,#100000
ADC X
скоростьX от нуля до 177777 (от «стоим на месте» до «передвигаемся на одну точку каждый кадр).
#100000 - накопительная дробная часть, изначально указывает на середину пикселя.
Как это будет выглядеть в коде например для двух объектов с разной скоростью?
т.е. для каждого объекта нужно хранить скорость и накопитель?
Может все таки проще иметь один счетчик циклов, и сравнивать с кол-вом пропусков в объекте..
Как это будет выглядеть в коде например для двух объектов с разной скоростью?
т.е. для каждого объекта нужно хранить скорость и накопитель?Да. Я так делаю в проигрывателе трекерной музыки для каждого звукового канала.
Может все таки проще иметь один счетчик циклов, и сравнивать с кол-вом пропусков в объекте..Ой, не знаю - по мне так проще как я описал. Универсальней что ли.
Не могу допереть как с помощью алгоритма перевертывания вывести спрайт в произвольный X,Y.. если заполнять буфер последовательно то все более менее понятно, но если нужно вывести спрайт в произвольную точку как вычислить адрес и все равно нужно будет делать сдвиг?
Я немного выпал из процесса - другие дела были.
Попробую завтра написать процедуру вывода спрайта по произвольным координатам.
Кстати в порте для Win очень подходящая фоновая музычка:
https://yadi.sk/d/Vk0wZ7VkJ1a1RQ
только она ogg, для AY можно будет что-нибудь подобное сделать? Я слышал, что музыкой вы тоже увлекаетесь..:)
Уж больно по стилю подобная музыка подходит для такой игры.. обычно для AY делают забойные трели и бульканье, которое быстро напрягать начинает.
Кстати в порте для Win очень подходящая фоновая музычкаДа, симпатичная.
Я слышал, что музыкой вы тоже увлекаетесьДа, но под AY никогда ничего серьёзного не писал. Это лучше в спектрумовском разделе поспрашивать кто из музыкантов хочет поучаствовать. В каком-нибудь простом формате, который БК умеет играть.
Жаль, спектрумисты вряд ли заинтересуются.. почему-то у них стойкая неприязнь ко всему что связано с БК :)
Да и мотивации не будет..
Написал вывод спрайта с произвольными координатами.
Образ .bkd (http://thesands.ru/bk0010/temp/lastmis3.zip)
Платформу поджал в пропорциях 5:8 и подрисовал чтобы красиво было:
http://thesands.ru/bk0010/temp/lastmis3.png
Процедура XY - преобразование координат в адрес экрана и маску начального пикселя.
Процедура DRAWSPRITE16 - вывод спрайта 16 точек высотой. Ну или можно такие высокие спрайты разбивать на два (по 8 точек в высоту каждый), тогда процедура немного упростится.
SCREEN - начальный адрес игрового поля (у меня 47402). То бишь координаты не абсолютные для всего экрана, а относительные внутри игровой области.
MOV #45.,R1 ; x coord
MOV #19.,R2 ; y coord
CALL XY ; get screen address and pencil mask
MOV #PLATFORM,R1 ; sprite address
MOV #25.,R5 ; sprite width in pixels
CALL DRAWSPRITE16
HALT
; subroutine: calculate address from x (R1) and y (R2)
; returns screen addres in R2 and pencil mask in R0
XY: SWAB R2
MOV R1,R0
BIC #7,R0
BIS R0,R2
ASR R2
ASR R2
ADD #SCREEN,R2 ; screen address
BIC #177770,R1
ASL R1
MOV DOTS(R1),R0 ; pencil mask
RET
DOTS: .WORD 2,10,40,200,1000,4000,20000,100000
; subroutine: draw sprite 16 pixels high
; input:
; R0 - pencil mask, R1 - sprite address,
; R2 - screen address, R5 - sprite width in pixels
DRAWSPRITE16:
1: MOV R2,-(SP) ; save screen address
MOV #100,R4
2: MOV (R1)+,R3 ; word to rotate
CLC ; draw a column of points
3: ROL R3
BCC 31 ; if zero skip next command
BIS R0,(R2) ; draw 1st bit of dot
CLC
31: ROL R3
BCC 32
CLC
ROR R0
BIS R0,(R2) ; draw 2nd bit of dot
ASL R0
32: ADD R4,R2 ; next row of the screen
TST R3 ; no more dots?
BNE 3
MOV (SP),R2
ADD #1000,R2
INC PC ; repeat twice
BR 2
MOV (SP)+,R2 ; column is drawn, restore screen address
ASL R0 ; move pencil
ASL R0
BNE 4
MOV #2,R0 ; set pencil to the first point
ADD #2,R2 ; increase screen address
4: DEC R5 ; switch to the next column
BNE 1 ; all columns are drawn?
RET
PLATFORM:
insert_file "sprites/platform01.raw"
.EVEN
Ещё для оптимизации можно подумать вот над чем:
платформа состоит из верхней неизменной части и нижней анимированной. Действительно тогда стоит разбить платформу на 2 спрайта и выводить их разными процедурами. Если на каждом кадре объекты могут сдвигаться только на 1 пиксель, то неанимированные спрайты можно не перерисовывать целиком, а просто сдвигом на экране обновлять. А вот с анимированными сложней: придётся стирать старый спрайт и рисовать поверх новый. Благо, это можно делать поточечно, то есть мерцания из-за стирания старого спрайта не будет.
ксттати не заметил особо вывода поточечно
во всяком случае на спеке выглядит как вывод до 4 точек
ксттати не заметил особо вывода поточечноГусеничная платформа может двигаться на любое число точек, а не только ровно по границам тайлов. Да и тайлы здесь 6x8, что не соответствует границам байтов, так что спрайты лабиринта тоже выводятся поточечно.
/* ксттати не заметил особо вывода поточечно */
Потому что на спеке однобитная графика, а на БК двух.
- - - Добавлено - - -
/*Процедура XY - преобразование координат в адрес экрана и маску начального пикселя.*/
Класс, т.е. смысл выставить начальную позицию карандаша..
есть над чем подумать.. сделать базовую для всех процедуру и к ней уже.. вывод тайла, спрайта, символа и строки.
Теперь уже можно запаковать лабиринт. Пробовал сжимать спрайты - некрасиво получается. Сейчас доделаю перевод спрайтов в текст, чтобы вставлять их в исходник, так будет удобней с указателями работать.
/* ксттати не заметил особо вывода поточечно */
Потому что на спеке однобитная графика, а на БК двух.
чиво? я про освежение экрана под ДОСом
короче посмотрел как сделано на спеке
да сделано поточечно но сами спрайты выводятся просто бросаясь на экран
не знаю можно ли так на БК
выделяется место в памяти на спрайт в ширину на 1 байт больше
т.е если спрайт 8*4 = 32 байта
то выделяем 8*5 = 40 байт
копируем спрайт в новый буфер
и в нем выскраливаем на нужную позицию
потом этот модифицированный спрайт перемещаем на экран.
Вся заморока с поворотом спрайтов из за того, что БК работает со словами, а не байтами и блоки тайлов 6ти битные чтобы влезло в 256 точек БКшкиного экрана.
Вся заморока с поворотом спрайтов из за того, что БК работает со словами, а не байтами.
я тя умаляю
где в ластмиссион требуется разворот спрайтов?
спрайт летящей пушки? так там всего 7 спрайтов на всю пушку
и 2 спрайта на платформу
/* я тя умаляю
где в ластмиссион требуется разворот спрайтов? */
Не отзеркаливание спрайтов, а предварительный разворот на 90 градусов, чтобы по точкам выводить на БК, причины см. выше.
/* я тя умаляю
где в ластмиссион требуется разворот спрайтов? */
Не отзеркаливание спрайтов, а предварительный разворот на 90 градусов, чтобы по точкам выводить на БК, причины см. выше.
ну я тебе предлагаю другой вариант
скроллить в буфере и выводить на экран
а вот этот вот поворот я рекомендую оставить для тайлов
Я его тоже первоначально предлагал, но как выяснилось тратится гораздо больше памяти для хранения спрайтов особенно если они не кратные слову, а по скорости то на то и выходит.
S_V_B, размер спрайтов врагов 16х16
размер спрайта героя 32х16
платформа тоже что-то вроде.
но вывод по точкам никогда не был быстрым
это было просчитано еще в 80х
Если выводить словами на БК ,будет скакать по 4 точки, что некрасиво.
Размер экрана CGA 320x200, а БК 256х256 поэтому спрайты тоже придется сжимать чтобы они соответствовали окружению, что делает их не кратными слову.
Это мы уже обсуждали выше. Мы же фигней страдаем не от хорошей жизни :) Я тоже привык как минимум к 8bpp
Если выводить словами на БК ,будет скакать по 4 точки, что некрасиво.
Размер экрана CGA 320x200, а БК 256х256 поэтому спрайты тоже придется сжимать чтобы они соответствовали окружению, что делает их не кратными слову.
Это мы уже обсуждали выше. Мы же фигней страдаем не от хорошей жизни :) Я тоже привык как минимум к 8bpp
ты меня не понимаешь
прежде чем вывести байт с точностью в 4 точки
ты копируешь его в буфер спрайта и сдвигаешь в нужном тебе направлении
и спрайт размера 32 точки на 16 точек становится спрайтом 40 точек на 16 точек
я понятно объяснил?
сделать базовую для всех процедуру и к ней уже.. вывод тайла, спрайта, символа и строки.Универсальная процедура всегда медленней. Лучше лабиринт выводить одной процедурой, а подвижные спрайты другой.
Теперь уже можно запаковать лабиринт.Да, хранить лучше запакованным. Но текущую комнату придётся хранить в памяти в распакованном виде чтобы сверяться с расположением препятствий.
Пробовал сжимать спрайты - некрасиво получаетсяТак а я вроде сжал уже. Надо найти время и руками подправить.
Сейчас доделаю перевод спрайтов в текст, чтобы вставлять их в исходник, так будет удобней с указателями работать.Ничего не удобней! Только время компиляции зря вырастет.
Спрайты лабиринта (тайлы) все одинакового размера, их удобно хранить как у меня сделано. А спрайты врагов и пушки+платформы можно хранить отдельно. Для каждого сделать свою метку и прописать там insert_file (посмотри мои исходники).
- - - Добавлено - - -
выделяется место в памяти на спрайт в ширину на 1 байт больше
т.е если спрайт 8*4 = 32 байта
то выделяем 8*5 = 40 байт
копируем спрайт в новый буфер
и в нем выскраливаем на нужную позицию
потом этот модифицированный спрайт перемещаем на экран.Довольно очевидное решение, но неэффективное: требует промежуточной памяти, имеет сложности с наложением на фон и пересечением с другими объектами и т.п.
Моя процедура оптимизирована: рисует столбец точек и если в нём остались только чёрные точки, то не рисует их и переходит сразу к следующему столбцу.
ты меня не понимаешь
прежде чем вывести байт с точностью в 4 точки
ты копируешь его в буфер спрайта и сдвигаешь в нужном тебе направлении
и спрайт размера 32 точки на 16 точек становится спрайтом 40 точек на 16 точек
я понятно объяснил?Да все всё поняли, мы обсуждали это ещё в начале темы (но за неравнодушие спасибо!)
Во-первых, выводить байты долго. Быстрее слова. А это значит, что изображение кратно уже 8-ми точкам. То есть иногда придётся скроллить аж по 7 точек (14 команд ROR для одного регистра и столько же для второго, в который перетекают данные через бит C). Это медленно.
Во-вторых, спрайт платформы у нас 25 точек в ширину, потому что мы пережимаем спрайты с PC под пропорции экрана БК. Ради хранения такого спрайта из 25-ти точек придётся тратить не 50, а 64 бита в памяти. Которой мало. А спрайтов много.
Ну и в-третьих, описываемый тобой метод, действительно, можно применить, но сразу на экране, чтобы сдвигать спрайты (если они не анимированы) на 1 точку влево или вправо. Попробуем совместить эти два метода. У нас же цель - минимальный расход памяти + максимальная производительность + максимальная плавность.
/* Но текущую комнату придётся хранить в памяти в распакованном виде чтобы сверяться с расположением препятствий. */
Да, я так и хочу сделать.
/*Спрайты лабиринта (тайлы) все одинакового размера, их удобно хранить как у меня сделано. */
С этим согласен.
А насчет спрайтов, в принципе без разницы (время компиляции не критично), мне просто так привычней и можно подправить что-нибудь и сам спрайт оформить в виде структуры объекта..
/* Универсальная процедура всегда медленней. */
Я думал не совсем об универсальной процедуре, а о выделении той части которая будет общая для всех.
У меня возникла идея как выводить тайлы лабиринта ещё быстрее. Там будет очень мало общего кода с процедурой вывода единичного спрайта.
В архиве, что я выкладывал, пережатые и подправленные вручную спрайты пушки и платформы - пользуйся на здоровье! ;)
Довольно очевидное решение, но неэффективное: требует промежуточной памяти, имеет сложности с наложением на фон и пересечением с другими объектами и т.п.
Моя процедура оптимизирована: рисует столбец точек и если в нём остались только чёрные точки, то не рисует их и переходит сразу к следующему столбцу.
хмм насчет наложения - нифига подобного
в оригинале так и сделано - ни масок ни гладкого наложения
грубо бросаем на экран
если один спрайт цепляет другой значит есть пересечение.
Да все всё поняли, мы обсуждали это ещё в начале темы (но за неравнодушие спасибо!)
Во-первых, выводить байты долго. Быстрее слова. А это значит, что изображение кратно уже 8-ми точкам. То есть иногда придётся скроллить аж по 7 точек (14 команд ROR для одного регистра и столько же для второго, в который перетекают данные через бит C). Это медленно.
Во-вторых, спрайт платформы у нас 25 точек в ширину, потому что мы пережимаем спрайты с PC под пропорции экрана БК. Ради хранения такого спрайта из 25-ти точек придётся тратить не 50, а 64 бита в памяти. Которой мало.
Ну и в третьих, описываемый тобой метод, действительно, можно применить, но сразу на экране, чтобы сдвигать спрайты (если они не анимированы) на 1 точку влево или вправо. Попробуем совместить эти два метода. У нас же цель - минимальный расход памяти + максимальная производительность + максимальная плавность.
насчет конверсии
я когда на спек конвертил солдата с бк
я его какбы совсем переписал
все что осталось только оригинальные уровни
поэтому ИМХО вам уровни поменять надо а платформу с ГГ и лифтом трогать не нужно.
хмм насчет наложения - нифига подобного
в оригинале так и сделано - ни масок ни гладкого наложения
грубо бросаем на экран
если один спрайт цепляет другой значит есть пересечение.Мы сделаем лучше, чем в оригинале :)
Когда пересечение спрайтов определяется с точностью до слова, оно может сработать, но при этом визуально спрайты будут всё ещё далеко друг от друга. У нас как раз такая ситуация: спрайт занимает 25 точек, а при операциях со словами его ширина будет оцениваться в 32 точки. 7 точек пустого места будут вести себя так, будто они не пустые и с чем-то пересеклись. Даже если рисовать не словами, а байтами (что замедляет отрисовку в два раза), пустые 3 точки будут всё время выдавать ложное пересечение.
/* У меня возникла идея как выводить тайлы лабиринта ещё быстрее. */
Поскольку пока я себя чувствую как доктор Ватсон или капитан очевидность.. (хотя для себя много нового узнаю :)) я пока переделаю все спрайты.
В заголовке спрайта вставлять его размерность? (старший байт X мл. Y или двумя словами?)
Из 8 точек оставлять 6?
S_V_B, погоди, а много спрайтов-то там? Два для игрока я уже сделал. Врагов сколько? Они вообще бывают размером больше 8 точек в высоту? И что на счёт анимации спрайтов - враги статичные или несколько картинок крутится в цикле?
blackmirror
30.09.2018, 12:49
Если тайлы хранятся повёрнутыми на 90 градусов, то может на экран записывать их побайтно следующим образом:
в R0 будет буфер на 4 точки выводимые на экран
в R1-R4 загружаются 4 столбца одного тайла, либо хвост одного и начало соседнего
далее выводится 8 строк по 4 точки следующим кодом:
add r1,r1 rol r0,r0 add r1,r1 rol r0,r0
add r2,r2 rol r0,r0 add r2,r2 rol r0,r0
add r3,r3 rol r0,r0 add r3,r3 rol r0,r0
add r4,r4 rol r0,r0 add r4,r4 rol r0,r0
movb (r5),r0 add r5,256/4
либо movb меняется на манипуляции с маской, если нужно вывести не 4 столбца, а менее.
то есть вывод строки тайлов 5x8 будет выглядеть так:
читаем и выводим 4 столбца первого тайла
потом 1 столбец первого и 3 столбца второго
далее 2 столбца 2го и 2 столбца третьего
далее 3 столбца третьего и 1 четвёртого
далее 4 столбца четвёртого
и далее такой шаблон повторяется.
В общем так можно выводить и тайлы разной ширины, нужно только помнить оставшуюся длину хвоста и несколько вариантов кода для загрузки R1-R4 (хвоста и начала следующего тайла).
blackmirror, идея хорошая. Видимо, придётся держать 4 похожих процедуры, каждая из них выводит соответственно 4, 3, 2 и 1 столбец (не всегда ведь нужны все 4).
Если переписать на ассемблере БК, то получится примерно следующее:
; R0 указывает на адрес спрайта, забираем первые 4 столбца
MOV (R0)+,R1
MOV (R0)+,R2
MOV (R0)+,R3
MOV (R0)+,R4
MOV #8.,R6 ; будем выводить 8 точек в высоту
LOOP:
ROR R1 ; берём пиксель из первого столбца
ROR R0
ROR R1
ROR R0
ROR R2 ; берём пиксель из второго столбца
ROR R0
ROR R2
ROR R0
ROR R3 ; берём пиксель из третьего столбца
ROR R0
ROR R3
ROR R0
ROR R4 ; берём пиксель из четвёртого столбца
ROR R0
ROR R4
ROR R0
; выводим полученный набор пикселей на экран
MOVB R0,(R5)
ADD #100,R5 ; адрес экрана смещаем на 1 пиксель вниз
SOB R6,LOOP
После смотрим сколько столбцов осталось нарисовать.
Если 4 - повторяем ту же процедуру.
Если меньше - переходим к аналогичной процедуре для 3, 2 или 1 столбца.
Но надо обсчитать производительность.
И остаётся вопрос как начинать выводить спрайт если его начальная горизонтальная координата не кратна 4.
Для спрайтов лабиринта 6x8 можно написать что-то подобное. Объединить отрисовку двух соседних спрайтов (12 точек, 3 байта).
/* а много спрайтов-то там? */
Спрайтов 46 (у каждого фрэймы)
У башни 7 фрэймов, у танка 2 и.т.д
всего 139
в высоту 12-16 точек..
есть 18х12, много 4х16 есть 6х7
(может их и не уменьшать?)
может их и не уменьшать?Надо посмотреть. Можешь в каком-нибудь удобоваримом виде выложить, чтобы посмотреть на Win/Mac?
Все в кучу..
https://yadi.sk/i/3_Y1w0wAACEh0Q
Просто я хотел их все автоматом в БК формат переделать..
Вопрос для Гуру БКшных игр :
если в БК11М поднять быстродействие с 262 т.рег-рег до 1200 т.рег-рег и оснастить СОЗУ 2 метра 0 тактов, а так же аппаратными умножением и делением,
насколько улучшится привлекательность новодельных игр ?
Я не Гуру, я капитан очевидность :)
Для привлекательности нужно хотя бы 16 цветов, а так естественно можно более динамичное что-то сделать.
Все упирается в возможности видеоконтроллера и объемом его памяти, что как я понимаю на бк11 невыполнимо.
Визуальная привлекательность зависит в первую очередь от работы видео, для плавного скроллинга в любую сторону нужна большая видеопамять.. и изменяемый адрес окна просмотра..
Если памяти достаточно то можно и без умножения и деления (табличками).
Просто я хотел их все автоматом в БК формат переделать..Так рано! Надо сперва их руками подрисовывать.
Все в кучу.. https://yadi.sk/i/3_Y1w0wAACEh0QОтлично, то что нужно!
Вижу, многие спрайты зеркально отображены. Можно не хранить их, а просто использовать ещё одну процедуру отрисовки в обратную сторону. Надо посчитать сколько она занимает и сравнить что выгодней - держать в памяти эти спрайты или процедуру.
- - - Добавлено - - -
если в БК11М поднять быстродействие с 262 т.рег-рег до 1200 т.рег-рег и оснастить СОЗУ 2 метра 0 тактов, а так же аппаратными умножением и делением,
насколько улучшится привлекательность новодельных игр ?Есть же SMK-512 - контроллер HDD с дополнительной памятью 512 килобайт, производительность которой почти вдвое выше обычной. Этого уже достаточно, чтобы делать намного более крутые игры, чем обычные БК-шные (у меня есть задумка такой игры ещё с 90-ых, может быть даже начну делать). Тот факт, что никто ещё не использовал эти возможности в играх, настораживает...
Когда я в середине 90-ых писал для БК-0010 игру Fist II (https://r-games.net/772-fist.html), у меня получилось такое дикое быстродействие, что пришлось сильно замедлять. Думаю, проблема разработки игр сейчас даже не в быстродействии, а в организации процесса: собрать команду, наладить работу, соблюдать сроки, контроль качества и т.п. Посмотрим что у нас получится с "Last Mission" :)
Аппаратное умножение и деление - это очень круто, но сколько тактов оно выполняется? Если больше ста, то и правда можно по таблицам умножать/делить.
/* Так рано! Надо сперва их руками подрисовывать.*/
Ну не совсем автоматом, я все спрайты выгружу в формате своего конвертера, а в нем можно редактировать и потом сохранять.
Я так понимаю что все спрайты нужно будет сделать отдельными файлами, потом подключать.
Удобней редактировать в Фотошопе.
Все спрайты одной картинкой - тоже хорошо. Давай я в ней пережму и подрисую что надо, а потом уже решим как конвертировать.
/*Удобней редактировать в Фотошопе.*/
Как скажете.. по мне так в фотошопе больше телодвижений.
Проще же автоматом развернуть, сжать, убрать пару точек (которые не нравятся) и сохранить в БК формат..и все в одной программе
/*Удобней редактировать в Фотошопе.*/Проще же автоматом развернуть, сжать, поставить пару точек (которые не нравятся) и сохранить в БК формат..и все в одной программеТам парой точек не обойтись. Для пушки и платформы я большую часть спрайта перерисовывал.
В общем, сделал вывод лабиринта со сдвигами, как предлагал blackmirror и отчасти jerri.
Засёк секундомером. Получилось на 9% медленней чем моя процедура вывода по точкам.
Вот образ диска: http://thesands.ru/bk0010/temp/lastmis4.zip
"lastmis" - вывод по точкам, "lastmis2" - вывод сразу байтами.
Там же на диске исходники. Смотрите, проверяйте. Может, я где накосячил. Если придумаете как оптимизировать - отлично. Если нет - подтверждаются мои эксперименты с пропорциональными шрифтами, которые показали, что вывод по точкам в конечном итоге эффективней.
Есть довольно очевидные идеи по оптимизации: смотреть данные комнаты забегая вперёд, и если там подряд идёт несколько нулевых тайлов, то переставлять экранный указатель сразу подальше. Но такую оптимизацию можно применить и к моему алгоритму, так что в итоге соотношение производительности останется как и сейчас.
blackmirror
30.09.2018, 21:07
Вот образ диска: http://thesands.ru/bk0010/temp/lastmis4.zip
У меня по каким-то причинам эмулятор падает, можно еще исходник прицепить?
У меня по каким-то причинам эмулятор падает, можно еще исходник прицепить?Конечно. Вот исходник: 66433
blackmirror
01.10.2018, 19:22
Правильно ли я понимаю, что поточечное рисование осуществляется только по предварительно очищенной области?
CodeMaster
01.10.2018, 21:33
насколько улучшится привлекательность новодельных игр ?
ZX Spectrum Next покажет, но и без этого думаю количество заинтересовавшихся будет неотличимо от статистической погрешности. Ибо если разделить количество фанатов БК на кол-во фанатов ZX, то этот множитель загасит любой % при переводе в физические показатели.
Правильно ли я понимаю, что поточечное рисование осуществляется только по предварительно очищенной области?Да. При отрисовке лабиринта я сперва очищаю 8 строк экрана.
Если отрисовывать не по точкам, всё равно надо очищать экран, иначе сквозь пустые места останется проглядывать прошлая комната.
Полностью перерисовал анимацию пушки, переделал спрайты. Так красивей смотрится и лучше подходит под разрешение БК. Остальные пока не буду перерисовывать, а лучше сделаю вывод этих спрайтов с анимацией.
66513
Зачетно, много лучше чем автоматом. Кстати врагов можно и не масштабировать им же на лифте не ездить..
....
Я чтобы под ногами не мешаться попробую параллельно на УКНЦ делать. Я так понимаю ты под БК-0010 будешь делать или под 11ю?
Хочу переадресовать таблицу строк УКНЦ на 40000 ЦП, в доках довольно мутно по этому поводу написано и примеров нет.. все на ПП, а если получится то памяти тоже маловато останется..
Попробую всё уложить в возможности БК-0010, а в случае запуска на 11-ой использовать палитру.
Под УКНЦ - давай, отличная идея.
Попробую всё уложить в возможности БК-0010
Моя 0010 уже робко выглядывает из коробки на шкафу.
Правильно ли я понимаю, что поточечное рисование осуществляется только по предварительно очищенной области?Сделал вариант чтобы по ходу рисования заодно и очищались пиксели. Такая процедура исполняется дольше (она не перескакивает через чёрные точки), но пока что для кода так проще. А там посмотрим - нужно ли будет оптимизировать быстродействие.
blackmirror
08.10.2018, 21:20
Для данной игры это наверно не актуально(поскольку много пустых областей), но вообще при рисовании большого количества тайлов (прямоугольных, без прозрачных дыр), ширина которых не кратна 8 точкам, можно пытаться копировать уже выведенные на экран тайлы из позиции дающей такой же остаток при делении на 8. В этом случае сами точки тайла уже не придётся сдвигать, нужно будет только наложить правильную маску. Правда нужен еще дополнительный массив (по одному элементу на тайл), в котором будет сохраняться где он выводился и с каким сдвигом. Или вообще хранить уровень ввиде данных перемешанных с кодом, типа: переместиться в угол, нарисовать тайлы 1,3 и 7 смещаясь вправо, а потом 4 раза скопировать, далее рисовать тайлы смещаясь вниз ну и в том же духе.
Самое очевидное и выигрышное по скорости решение - хранить каждый спрайт 4 раза: оригинальный и заранее сдвинутый на 1, 2 и 3 точки. Да только вот памяти жалко. Хочется уложиться в возможности БК-0010.
Анимированная платформа у меня уже по экрану едет, надо только понять что с ней делать дальше. Может быть для движения влево и вправо использовать разные процедуры. Универсальная процедура даёт слабозаметный эффект растяжения спрайта при движении в одну сторону и сжатия при движении в другую. Если отслеживать луч, то этого видно не будет. Но на БК-0010 луч не отследишь (если только не грязными хаками), да и ограничивать fps не хочуется.
Самое очевидное и выигрышное по скорости решение - хранить каждый спрайт 4 раза: оригинальный и заранее сдвинутый на 1, 2 и 3 точки. Да только вот памяти жалко. Хочется уложиться в возможности БК-0010.
В исходниках Highway Encounter для УКНЦ есть процедуры вывода ч/б спрайтов 16x24 с маской, со сдвигом на -2/0/2/4 пикселов.
https://github.com/nzeemin/uknc-highwayencounter/blob/master/HWYENC.MAC, ищите по "Draw sprite with shift".
ищите по "Draw sprite with shift".Немного не наш случай, но команда SWAB навела меня на мысль, что можно в одном слове хранить и маску, и цвет, в разных байтах. Для маленьких спрайтов это даст ускорение.
а за счет изменения размера меню под экраном нельзя ли нормально оставить спрайты как есть, без ужиманий? Меню-то не критично - ужали/разжали - там одни тексты...
а за счет изменения размера меню под экраном нельзя ли нормально оставить спрайты как есть, без ужиманий? Меню-то не критично - ужали/разжали - там одни тексты...Мы ужимаем по горизонтали. В оригинале 320 точек в ширину. У нас экран шириной всего 256.
Измерил быстродействие: процедура рисования спрайта со стиранием точек в полтора раза медленней (11,7 мс ~ 85 раз в секунду) процедуры рисования по чёрному (8 мс ~ 124 раза в секунду).
Но самое интересное вот что: даже если рисовать тормознутой процедурой, платформа катается по экрану достаточно быстро. При этом анимация крутящихся гусениц сливается. Получается, эта анимация и не нужна вовсе. Чтобы разница между кадрами стала заметной, каждый кадр надо держать на экране раза в 3-4 дольше, а это уже слишком медленно для игрового процесса.
blackmirror
10.10.2018, 23:35
Пришла тут одна мысль как двигать спрайт при помощи CRC, на словах это объяснить сложно, попробую на примере.
Если бы в байте было 4 бита, можно было бы использовать полином x^4+x+1, который выдаёт последовательность:
111100010011010(1111...)
в ней отсутствует комбинация 0000, поэтому воткнём еще один 0 там где их 3 и получим:
1111000010011010(1111...)
если взять по 4 битика, получится 16 уникальных комбинаций:
1111 1110 1100 1000 0000 0001 0010 0100 1001 0011 0110 1101 1010 0101 1011 0111
(выделено некоторое значение и где его биты оказываются при сдвиге)
если их засунуть в таблицу, а в спрайте вместо комбинации из 4 бит разместить индекс элемента из таблицы, то прибавив к нему n>0 можно получить индекс элемента сдвинутого влево(с мусором в младших разрядах), а вычитая n>0 сдвинутого вправо(с мусором в старших разрядах).
Вытащив элементы с индексами отличающимся на 4, и используя маску можно получить циклический сдвиг одного из элементов находящихся между ними. чтобы можно было сдвигать любой элемент на n<4 и не прочитать мусор, три элемента из хвоста таблицы нужно приписать до начала, а три элемента из начала после хвоста.
Если вернуться к 16 разрядным словам, то нужно будет сделать табличку в 256+14(+14 если будем двигать и в другую сторону) элементов полученных при помощи полинома восьмой степени. Значения генерируемые полиномом копируются в чётные биты, а нечётные остаются нулевыми. Слово спрайта разделяется на чётные и нечётные биты, и заменяется двумя байтовыми индексами, показывающими где такие значения можно найти в таблице. То есть для сдвига 8 точек спрайта потребуется:
Прочитать два индекса i1 и i2 из спрайта.
Вычислить слово сдвинутое влево: table[i1+shift] +table[i2+shift]*2
Вычислить слово сдвинутое вправо: table[i1+8-shift] +table[i2+8-shift]*2
Наложить маски и вывести на экран.
Если править код чтения из таблиц(его можно будет использовать и для следующей строки), то для вывода 8 точек вроде как требуется 16 команд, а прочитанных или записанных слов примерно раза в два больше(организация цикла сюда не входит).
/*эта анимация и не нужна вовсе.*/
Это сейчас когда объектов на экране мало анимацию не видно, когда притормозит.. все будет ок. В оригинале ее тоже плохо заметно.. но все равно что-то мельтешит.. ощущается движение.. иначе будет совсем неживая аппликация двигаться. Кстати заметили в оригинале, что кроме гусениц по бокам платформы сверху типа "поршни" попеременно выскакивают.. то же оживляет..
Если править код чтения из таблиц...С таблицами идея хорошая - по таблицам можно делать и зеркальное отражение спрайта.
Я пробовал использовать таблицы сдвига для пропорциональных шрифтов (шрифты в памяти монохромные, а выводятся в цвете, поэтому один байт раскрывается в целое слово по табличкам). Но отказался из-за громоздкости и незначительного прирорста в производительности. Опять же, надо писать код, замерять быстродействие и решать стоит ли оно того (таблички всё же занимают память).
- - - Добавлено - - -
Это сейчас когда объектов на экране мало анимацию не видно, когда притормозит.. все будет ок.В том-то и дело, что тормозить не хочется. Сейчас платформа проезжает экран примерно за 3 секунды. Сильно замедлять не хочется. Не в три же раза.
Кстати заметили в оригинале, что кроме гусениц по бокам платформы сверху типа "поршни" попеременно выскакивают.. то же оживляет..Ого, надо будет посмотреть в DOSbox в замедленном режиме.
Первые успехи на УКНЦ, разобрался с прямым доступом к ВОЗУ (правда памяти сжирает.. но зато быстро) и есть косячек в виде мигающей строчки сверху.. буду думать кто туда чего пишет.
https://yadi.sk/i/fEaMpdl1ZibuVA
blackmirror
11.10.2018, 19:02
С таблицами идея хорошая - по таблицам можно делать и зеркальное отражение спрайта.
Конкретно эти таблицы для зеркального отражения не подойдут. Тут идея в том, чтобы вместо нескольких таблиц со сдвигом на 2,4,6 использовать одну таблицу (с небольшими хвостами). Минус только в том, что спрайты будут храниться в немного странном виде.
blackmirror, пытаюсь осмыслить как применить эту хитрую таблицу на практике.
Возьмём какой-нибудь байт из исходного спрайта, например такие 4 точки:
◼︎◼︎◼︎◼︎
В таблице ему должно соответствовать несколько слов:
◼︎◼︎◼︎◼︎◻︎◻︎◻︎◻︎
◻︎◼︎◼︎◼︎◼︎◻︎◻︎◻︎
◻︎◻︎◼︎◼︎◼︎◼︎◻︎◻︎
◻︎◻︎◻︎◼︎◼︎◼︎◼︎◻︎
Значком ◻︎ я обозначил точки произвольного цвета, конкретные значения нас не интересуют.
В исходном спрайте рассматриваемые 4 точки должны храниться не в виде цветов (11001001), а в виде порядкового номера в таблице.
Чтобы нарисовать наши 4 точки, мы достаём число из данных спрайта, умножаем его на 2 (потому что таблица состоит из слов, а не из байтов), берём значение из этой таблицы, сделав отступ в таблице, если надо. И ещё применяем маску.
MOVB (R1)+,R2 ; взяли данные из спрайта
BIC #177400,R2 ; сбросили старшие биты, можно маску сброса хранить в каком-нибудь регистре
ASL R2 ; умножили на два, получили индекс в таблице
Дальше если надо вывести точки без сдвига, делаем так:
MOV TABL(R2),R2 ; забрали 8 точек из таблицы
BIC #377,R2 ; сбросили ненужные 4 точки, маску опять же можно хранить в регистре
BIS R2,(R3) ; вывели оставшиеся 4 точки на экран
Если надо вывести точки со сдвигом на одну, делаем так:
MOV TABL+2(R2),R2 ; забрали 8 точек из таблицы
BIC #140077,R2 ; сбросили ненужные 4 точки по маске
BIS R2,(R3) ; вывели оставшиеся 4 точки на экран
Сдвиг на две точки:
MOV TABL+4(R2),R2 ; забрали 8 точек из таблицы
BIC #170017,R2 ; сбросили ненужные 4 точки по маске
BIS R2,(R3) ; вывели оставшиеся 4 точки на экран
Сдвиг на три точки:
MOV TABL+6(R2),R2 ; забрали 8 точек из таблицы
BIC #176003,R2 ; сбросили ненужные 4 точки по маске
BIS R2,(R3) ; вывели оставшиеся 4 точки на экран
Довольно изящно. Да ещё и организация таблицы умная: точки ◻︎ - не абы что, а цвета для других входных данных.
Но изящно оно пока мы выводим изображение в чётные адреса экрана.
Как только надо вывести 4 точки по нечётному адресу, появляются костыли:
MOVB (R1)+,R2 ; взяли данные из спрайта
BIC #177400,R2 ; сбросили старшие биты
ASL R2 ; умножили на два, получили индекс в таблице
MOV TABL+6(R2),R2 ; забрали 8 точек из таблицы
BIC #176003,R2 ; сбросили ненужные 4 точки по маске
BISB R2,(R3)+ ; вывели часть точек на экран
SWAB R2 ; переключились на оставшиеся точки
BISB R2,(R3) ; вывели оставшуюся часть точек на экранА это уже довольно долго.
P.S. На самом деле порядок точек на экране слева направо соответствует порядку битов справа налево, но это детали. Просто изображённые мной цветные квадратике будут выводиться на экран БК в обратном порядке.
blackmirror
14.10.2018, 14:20
Manwe, это в примере она по 4 точки, в реальности нужна таблица из 256 слов плюс небольшой хвост, которая будет работать для 8 точек. Только в таблице биты 0,2,4,6,8,10,12,14 будут хранить данные, а оставшиеся биты нули. Плюс по такому же принципу разделяются исходные 8 точек спрайта, и для них формируются два индекса(они будут разными), один показывает где в таблице можно найти такое сочетание чётных бит, а второй для нечётных(если их сдвинуть на место чётных). Два индекса хранить нужно сдвинутыми на 1 разряд, чтобы не умножать на 2, а использовать маску, в общем для 8 точек получается что-то типа такого:
;извлечение индексов
MOV (R1)+,R2 ; взяли из спрайта два индекса, для чётных и нечётных бит
;(они были циклически сдвинуты чтобы не умножать)
MOV R2,R3 ;скопировали индексы
BIC #177001,R2 ;извлекли индекс для чётных бит
XOR R2,R3 ;обнулили эти биты в копии
SWAB R3 ;извлекли индекс для нечётных бит
;вывод точек в текущее слово экрана
MOV TABLE+SHIFT(R3),R4 ;читаем нечётные биты(вернее пока они лежат в чётных)
ADD R4,R4 ;ставим на законное место
ADD TABLE+SHIFT(R2),R4 ;добавляем к ним чётные
BIC #MASK,R4 ;применяем маску
BIS R4,(R5)+ ;выводим на экран
;вывод остальных точек в следующее слово экрана
MOV TABLE+SHIFT-16(R3),R4 ;читаем нечётные биты
ADD R4,R4 ;ставим на законное место
ADD TABLE+SHIFT-16(R2),R4 ;добавляем к ним чётные
BIC #177777-MASK,R4 ;применяем маску
BIS R4,(R5) ;выводим на экран
;команд здесь конечно многовато, нужно еще подумать что можно сделать с циклическими сдвигами, вдруг 8 отдельных процедур будеть быстрее и меньше по размеру
;если остальные точки не выводить сразу а оставить скажем в регистре R0
;и взять из спрайта следующие 2 индекса
;то вместо команд BIC/BIS можно объединять 8 точек и вывести командой MOV
;при выводе точек из середины спрайта
XOR R0,R4
AND #MASK,R4
XOR R0,R4
MOV R4,(R5)+
;команд здесь столько же, но нет команд чтения/модификации/записи
;может по такому-же принципу можно объединять если выводим по 4 точки
- - - Добавлено - - -
Manwe, всё же отдельные функции вывода со сдвигом будут наверно работать чуть быстрее(считаем что данные спрайта уже загружены в R0):
сдвиг на 1 точку:
rol r0 rol r0 mov r0,r1 rol r1
сдвиг на 2 точки:
+ еще rol r0 rol r0 в начале
сдвиг на 3 точки:
в первом варианте rol меняется на ror, а в начале добавляется swab
сдвиг на 4 точки:
swab r0 mov r0,r1
для сдвигов на 5,6,7 точек:
rol меняется на rol и наоборот
То есть между чтением 8 точек из спрайта, наложением маски и выводом командами bic/bis требутеся не более 6 команд для его сдвига, можно вместо bic/bis делать объединение через xor, команд столько же, но для середины спрайта меньше обращений к памяти, а для хвостов пару раз читаем слово с экрана(и используем маски). В общем при выводе одной строки спрайта, для изменения 8 точек на экране требуется не более 12 команд(если цикл сделан через SOB). По объёму кода наверно тоже будет меньше чем табличка.
Manwe, извиняюсь не по теме вопрос, если вот такая крутизна как ваша ДЕМО (прямое и инферстное тыблоко)
- это второе место, как выглядело 1-е место
Manwe, извиняюсь не по теме вопрос, если вот такая крутизна как ваша ДЕМО (прямое и инферстное тыблоко) - это второе место, как выглядело 1-е местоВот так:
http://content.pouet.net/files/screenshots/00077/00077759.jpg
Занимает 4 килобайта. http://www.pouet.net/prod.php?which=77759
CodeMaster
14.10.2018, 20:56
Занимает 4 килобайта.
Это как?
platform : Windows
type : 4k
4k - демо, 400m - библиотеки для работы этого демо и 40g - ОСь для работы этих библиотек?
Это как? 4k - демо, 400m - библиотеки для работы этого демо и 40g - ОСь для работы этих библиотек?Из ресурсов системы используется драйвер видеокарты и входящий в состав драйвера транслятор с языка GLSL в машинный код видеокарты. Плюс вывод звука системной функцией waveout.
В принципе, никто не запрещает и на БК-0010 пользоваться функциями монитора в 4kb intro :)
CodeMaster
15.10.2018, 13:01
В принципе, никто не запрещает и на БК-0010 пользоваться функциями монитора в 4kb intro
Ну, это понятно, бы ли же вроде демы использующие функционал SMK, но во-первых тут сравнение было бы правильным, если бы эта дема использовала только функции BIOS/UEFI. А во-вторых, определение "platform: Windows" не совсем корректное. Скачал я этот экзешник и что - "работа программы была завершена" не начавшись, а меня тоже Windows на компутере.
Но, всё это уже жёсткий офф, так что завязываем ;-)
Manwe, администратор 1000бит добавил линк на вашу дему в самом низу на страничке портала про БК-11М )
https://www.1000bit.it/scheda.asp?id=1791
/* Для Manwe - запакованый лабиринт */
https://yadi.sk/d/BO9q5VcNdpHe9A
SCREEN:: - (0-91) массив ссылок на описание комнат.
PATTER:: -(0-117)ссылки на паттерны из тайлов.
SCRn::
1. 0, кол-во элементов (ниже) // нули добавлял чтобы читать словами
2. X, Y, № паттерна(PATnn), 0 (X,Y - координаты в буфере размерностью кратной размерам тайла т.е. Xmax кол-во тайлов в ширину..) //нули можно убрать или местами поменять, скажи как лучше.
.......
PATn::
1.x,y - размерность паттерна (так и выводить в буфер.. если 2x8 значит ширина 2 и вниз 8)
2. №тайла, №тайла...
........
P.S.
Сюда можно впихнуть описание объектов но я об этом пока не думал..
...
подправил малость
Для Manwe - запакованный лабиринтБлагодарю, я скоро к этому вернусь.
Думаю над хитрой буферизацией экрана под движущимися объектами. Хочу уложить всё в объём памяти стандартной БК-0010.
Пока идея такая:
1. Определять начальные адреса экрана для левого верхнего угла каждого спрайта.
2. Для каждой строки экрана считать сколько спрайтов на неё приходится. Это буфер из полторы сотни байтов.
3. Сортировать спрайты в порядке отрисовки сверху вниз и слева направо.
4. Формировать массив вида «содержимое, адрес». Для 10 спрайтов шириной в 3 слова и высотой в 10 пикселей получается массив 300*2 слов. В 16 раз меньше, чем полный буфер экрана.
5. Поскольку спрайты отсортированы, при отрисовке легко проверять массив на несколько элементов назад: а не записывалось ли уже по этому адресу содержимое других спрайтов. Если не записывалось - делаем просто MOV. Если записывалось - смешиваем содержимое (с применением масок если хватит памяти на них или без, просто XOR’ом).
6. Помимо отрисовки новых спрайтов, одновременно стираем старые, оставшиеся с предыдущего кадра. Таким же образом, с сортировкой и сравнением адресов.
7. На выходе получаем небольшой массив, который по сути содержит дельта-информацию: чем новый кадр отличается от старого. Выводим этот массив на экран MOV (R1)+,@(R1)+ Так у нас сделано в демке «Good Apple». Это гораздо быстрей, чем копировать полный экран.
Плюсы такого подхода:
+ При выводе спрайтов на экран ничего не мерцает.
+ Нужно мало памяти. Сможем сделать даже на БК-0010.
+ Быстрее, чем рисовать в экранном буфере и потом копировать его.
Минусы:
- Нужно продумывать детали. Неизведанная территория, так никто ещё не делал.
- Сортировка и поиск в массиве могут оказаться медленными. Суммарного выигрыша в скорости не получится.
Статические объекты (геометрия лабиринта) во всём описанном не участвуют, так как персонажи летают только поверх чёрного фона. Статику рисуем только один раз при входе в новую комнату.
Идея интересная, но скорее всего с быстродействием проблемы будут, много предварительных расчетов. Хотя сам вывод и быстрее будет. Я вот схалтурил, просто при выводе спрайта со всех сторон по точке стираю, быстро и не мерцает. (перед этим спрайт в буфере сдвигаю и BISом накладываю)
Я вот схалтурил, просто при выводе спрайта со всех сторон по точке стираю, быстро и не мерцает. (перед этим спрайт в буфере сдвигаю и BISом накладываю)А если два спрайта пересекаются в одном экранном слове – неужели в этом месте не мерцает?
/* два спрайта пересекаются в одном экранном слове – неужели в этом месте не мерцает? */
Враги движутся достаточно быстро, определение столкновений - прямоугольник (враги чаще движутся по диагонали), пока заметишь мерцание - уже взрыв нужно выводить.
Возможно я не увидел всех "частных" случаев, буду решать проблемы по мере поступления. (либо маску придется добавлять)
определение столкновений - прямоугольникПопробую придумать как во время отрисовки пушки проверять столкновения с точностью до пикселя (понятно что командой BIT, но непонятно пока - для любых спрайтов или отдельно для пушки).
Меня удручает быстродействие. В итоге мудреные алгоритмы придется откинуть. Нужно минимум действий - максимум эффективности.
Я бы сделал с двумя экранами, но пока не могу придумать как их переключать достаточно синхронно.. ПП живет своей жизнью :)
Тогда можно было проверять пространство под спрайтом при выводе (поскольку фон черный) зная квадрат врага выводить пока не будет 1-1.
Кстати в версии для PC просто стирают фон в предыдущем расположении спрайта и никаких морганий.. нам такая роскошь недоступна :)
Меня удручает быстродействие. В итоге мудреные алгоритмы придется откинуть. Нужно минимум действий - максимум эффективности.Да, вот сейчас думаю, что не нужна мне сортировка. Если движущихся объектов мало, то вместо сортировки проще тупо перебрать все объекты подряд, сравнивая не совпадает ли адрес.
Пока что столкнулся с дилеммой.
Спрайты лучше хранить по байтам, а не по словам, чтобы меньше места занимали. Ширина получается кратной четырём пикселям, а не восьми, значит для многих (но не для всех) спрайтов мы будем экономить целый столбец байтов. С другой стороны, выводить на экран быстрее словами, чем байтами. Это известная дилемма, но я не о ней. Всё гораздо хуже:
Я составляю список изменений на экране (новый кадр по отношению к старому) в таком виде: значение1, адрес1, значение2, адрес2,.. значениеN, адресN. Если адрес уже встречался в списке, то значение перезаписывается поверх существующего (там коротенький поиск в пределах одной экранной строки).
Поскольку спрайты хранятся байтами, адреса вывода на экран могут быть нечётными. Соседние два байта будут храниться двумя записями с чётным и нечётным адресами. Выходит, что в этом списке все "значения" будут содержать по лишнему пустому байту. Тратится лишнее место. Но главное, что вывод командой MOVB (R1)+,@(R1)+ становится невозможным, так как R1 будет переставляться на следующую запись неправильно.
Придумал хитрость: если адрес нечётный, то переделывать его в чётный и класть "значение" в старший байт. Тогда все адреса в списке получаются чётными, всё круто. Но! Теперь оказывается, что невозможно заранее посчитать сколько слов у нас получится при выводе. Так как чётные и нечётные смешиваются непредсказуемо (зависит от X-координаты каждого спрайта). Раньше с байтами было просто: ширина спрайта (+1 с учётом сдвига) и так для каждого спрайта, приходящегося на эту экранную строку. В сумме знаем сколько байт надо вывести в каждую экранную строку. А теперь при смешивании байтов в слова уже не знаем.
И вот дилемма: придумывать какой-то костыль для правильного подсчёта? Это затормозит работу алгоритма.
Либо хранить спрайты не байтами, а словами, тогда проще подсчёт и проще обращение со списком изменений. Но тормознутей сдвиг спрайтов (потому что становится возможным сдвиг уже не на 3, а на 7 пикселей).
Какой путь выбрать?
Manwe, во всех своих проектах на УКНЦ использую для тайлов/спрайтов хранение словами -- каждое слово это 8x1 пикселей в 4 цвета -- для вывода через ЦП передачей слова сразу в порт. Иначе слишком много времени тратится на подготовку данных для вывода на экран.
Так-то да, но ведь место жалко. Я хочу уложиться в 16 kb БК-0010.
/* Иначе слишком много времени тратится на подготовку данных для вывода на экран. */
При движении спрайта (сдвиге) все равно приходится слова разделять, поскольку в слове лежат две плоскости..
поскольку в слове лежат две плоскости.. имеется в виду два плана? давайте на одном языке говорить - плоскости = это тригономнтрия какая-то )))
Black Cat / Era CG
28.11.2018, 19:22
плоскости = это тригономнтрия какая-то )))
Стереометрия.
"плоскости" отражают суть процесса, а "план".. :)
Кстати, на счёт плоскостей. Возможно, придётся развернуть алгоритм на 90°
Раньше я перебирал все объекты (спрайты) и заполнял графическими данными массив строк. Проблема была в том, что непонятно какой длины получится каждая строка.
Но, возможно, правильней во внешнем цикле перебирать экранные строки, а во внутреннем цикле для каждой строки смотреть что за объекты в неё попадают, брать из соответствующих спрайтов только по одной строчке графических данных и заносить в массив. Это вроде бы дольше, но зато конечный вывод массива будет «вжух!»
Попробовал идею со строками. Назвал этот подход "scanlines".
Для компьютеров с маленьким объёмом памяти идея очень вдохновляющая: двойной буфер экрана, размер которого... не зависит от размера основного экрана! А зависит лишь от площади присутствующих на экране анимированных спрайтов. В моём эксперименте с семью спрайтами размер буфера получился всего 776 байт.
Но как обычно, есть и потери: скорость снизилась раза в три по сравнению с прошлым алгоритмом. Надо думать как оптимизировать.
Может быть более эффективно отсекать объекты, которые не попадают в scanline. Возможно, отслеживать когда спрайт полностью нарисован и ставить ему признак "сразу пропускать" для следующих сканлайнов.
Вторая причина тормозов: обращение к спрайту происходит не один раз за кадр, а много раз (столько, сколько строк на экране), и каждый раз вычисляется смещение в спрайте, чтобы выбрать соответствующую строку пикселей. Попробую запоминать прошлый указатель на графические данные спрайта, а не пересчитывать его заново при каждом обращении.
В целом такие оптимизации помогут ускорить раза в два, наверное. Перспективы есть :)
P.S. ещё идея со сканлайнами интересна тем, что она решает проблему выхода (полного или частичного) спрайта за пределы отображаемой области.
S_V_B, достаточно шестнадцати движущихся объектов для каждого экрана? Если да, то попробую массив слов, в которых каждый бит отвечает за 1 объект - присутствует он в данной экранной строке или нет.
7 объектов максимум.
Как вычисляются экранные координаты для отрицательных Х?
7 объектов максимум.Считая всякие искрящиеся разряды?
Как вычисляются экранные координаты для отрицательных Х?Пока никак. Сканлайны отсекат только координату Y.
/* Считая всякие искрящиеся разряды? */
Да.
я сначала хотел вращать спрайты там же где они лежат, что бы каждый раз только один сдвиг делать, двигаемся же по одной точке.
потом сделал ASHC.
Чтобы не моргало через буфер фон->BIC (x-1)->BIS(X)->MOV.
В итоге ломаю голову как с периферийным процессором подружиться (диспетчер процессов) чтобы два экрана переключать.
Так будет проще и быстрее.
"Аппаратные" спрайты УКНЦ.. вещь сомнительная, скорее всего под знакогенератор заточена.
Глюки порождают "современное искусство". Буду бороться с ним :)
67115
Дизассемблирую программки для УКНЦ наткнулся на такую конструкцию:
seg001:006676 mov #2600, R0
seg001:006702 mov #2500, word_17414
seg001:006710 call sub_17420
seg001:006714 br loc_6676
.................................................. ..........
.................................................. ..........
seg001:017420 mov SP, word_17412
seg001:017424 call sub_56274
.................................................. ..........
.................................................. ..........
seg001:056274 sub_56274: ; CODE XREF: sub_12226↑P
seg001:056274
seg001:056274 mov (SP)+, #0
seg001:056300 mov R1, -(SP)
seg001:056302 mov R2, -(SP)
seg001:056304 mov R3, -(SP)
seg001:056306 mov R4, -(SP)
seg001:056310 mov R5, -(SP)
seg001:056312 call @sub_56274+2
seg001:056316 mov (SP)+, R5
seg001:056320 mov (SP)+, R4
seg001:056322 mov (SP)+, R3
seg001:056324 mov (SP)+, R2
seg001:056326 mov (SP)+, R1
seg001:056330 return
seg001:056330 ; End of function sub_56274
Для чего может использоваться такая процедура?
Для чего может использоваться такая процедура?Самое интересное, по-моему, пропущено (второй ряд многоточий).
Я так понимаю, call sub_56274 делает следующее: сохраняет в стек регистры с R1 по R5, возвращается чтобы выполнить команды, идущие после call sub_56274 (где многоточия). Потом, встретив команду return, процедура восстановит из стека регистры с R1 по R5 и продолжит выполнение. А что там дальше со стеком и возвратом в основную программу - непонятно. Скрыто за многоточиями.
То есть смысл всего этого - одной командой сохранить и восстановить регистры до и после вызова подпрограммы.
- - - Добавлено - - -
67131
Выкладываю bin и исходники алгоритма вывода спрайтов без мерцания посредством дельта-буфера.
Получилось изящно, занимает мало памяти, но... жутко тормознуто. Для игр где много больших спрайтов не годится.
67130
Зачем она сама себя вызывает.. call @sub_56274+2..
многоточия это три разных процедуры.. начинается все с call sub_17420.. идет дальше на sub_56274..
а внутри нее call @sub_56274+2.. вот в чем вопрос..
...
то что они пытаются сделать PUSHA я догадываюсь этот вызов часто встречается..
и вообще такое ощущение что на ЯВУ написано, передача параметров через стек делается.. везде.
/* Выкладываю bin и исходники алгоритма */
Чуть бы побыстрее и было бы новое слово в игрописательстве.. :)
На УКНЦ этот алгоритм наверное тоже не подойдет потому что все нужно будет делать 2 раза :(
Зачем она сама себя вызывает.. call @sub_56274+2..Она не себя вызывает, она берёт число #0 (только оно уже не 0, а заменено на адрес) и переходит по этому адресу.
и вообще такое ощущение что на ЯВУ написано, передача параметров через стек делается.. везде.Похоже, да.
Чуть бы побыстрее и было бы новое слово в игрописательстве.. :)Если выполнять в статической памяти контроллера SMK, то будет намного быстрее.
На УКНЦ этот алгоритм наверное тоже не подойдет потому что все нужно будет делать 2 раза :(А зачем два раза?
/* А зачем два раза? */
Ну плана ВОЗУ два же используем.. это в БК все за раз делается..
Да и с регистровым доступом все равно долго будет.
/* и переходит по этому адресу. */
А ну да.. что-то я торможу.. это действительно PUSHA..
в #0 .. лежит адрес возврата и когда делает call то возвращается в вызывающую процедуру но с сохраненными регистрами, а потом возвращается чтобы их восстановить.. точно ЯВУ.. потому что понатыкано где надо и где нет..
хотел подсмотреть как они в "NEWTET.SAV" периферийным процом общаются, но код тяжело читается..
Попробую ещё одну идею вывода спрайтов.
Поскольку больше двух спрайтов вряд ли буду пересекаться в одном месте, а если и будут, то три наложенных спрайта – это уже непонятная каша, то можно попарно сравнивать спрайты и искать области пересечения. Если такие области есть, то дополнять изображение в соответствующей области каждого спрайта, взяв пиксели (целыми словами) из другого спрайта.
Если в какой-то области будет пересечение трёх и более спрайтов, то алгоритм обработает только первое найденное пересечение.
Спрайты сначала целиком копируются во временный буфер (с применением сдвига на сколько-то точек), потом запускается поиск пересечений по координатам и размерам, в конце происходит обмен пикселями (словами) в найденных областях.
Муторная выйдет подпрограмма вычисления области пересечения. Некрасивая.
update: можно придать чуть-чуть красоты, сравнивая попарно левые и правые границы двух спрайтов и устанавливая (или сбрасывая) один бит для каждого сравнения. Получим число (16 вариантов), которое можно использовать как индекс в таблице ссылок на разные процедуры (для разных типов пересечений).
Дизассемблирую программки для УКНЦ наткнулся на такую конструкцию
Извращение какое то. (насколько я помню, но правильный вариант легко восстановим) Это делает так:
JSR R5, $SAVAL
...
RETURN
...
$SAVAL: MOV R0, -(SP)
MOV R1, -(SP)
MOV R2, -(SP)
MOV R3, -(SP)
MOV R4, -(SP)
MOV R5, -(SP)
CALL @(SP)+
MOV (SP)+, R4
MOV (SP)+, R3
MOV (SP)+, R2
MOV (SP)+, R1
MOV (SP)+, R0
MOV (SP)+, R5
RETURN
Попробую ещё одну идею вывода спрайтов.
Поскольку больше двух спрайтов вряд ли буду пересекаться в одном месте, а если и будут, то три наложенных спрайта – это уже непонятная каша, то можно попарно сравнивать спрайты и искать области пересечения. Если такие области есть, то дополнять изображение в соответствующей области каждого спрайта, взяв пиксели (целыми словами) из другого спрайта.
Если в какой-то области будет пересечение трёх и более спрайтов, то алгоритм обработает только первое найденное пересечение.
Спрайты сначала целиком копируются во временный буфер (с применением сдвига на сколько-то точек), потом запускается поиск пересечений по координатам и размерам, в конце происходит обмен пикселями (словами) в найденных областях.
Муторная выйдет подпрограмма вычисления области пересечения. Некрасивая.
update: можно придать чуть-чуть красоты, сравнивая попарно левые и правые границы двух спрайтов и устанавливая (или сбрасывая) один бит для каждого сравнения. Получим число (16 вариантов), которое можно использовать как индекс в таблице ссылок на разные процедуры (для разных типов пересечений).
помнится как-то видел такой алгоритм рисования
по маске удаляется старая фаза спрайта
потом поверх накладывается новая фаза
при пересечении выглядело занятно
если интересно игра со спека DanDare2
сама маска для удаления создавалась из спрайта
Я сейчас пишу другую маленькую игру, отлаживаю на ней всякие сопутствующие моменты. Из полученного опыта вот что думаю на счёт Last Mission:
При переходе в новую комнату нужно не только рисовать лабиринт, но также генерировать все варианты используемых в этой комнате спрайтов врагов. Я имею в виду варианты спрайтов со сдвигом на 1,2 и 3 точки. Если есть такие варианты, то процедура вывода получится самой быстрой.
Хранить в памяти все возможные спрайты по 4 раза - расточительно, места не хватит. Но если только те, которые используются в данной комнате - может, и хватит.
Manwe, /* маленькую игру, отлаживаю на ней всякие сопутствующие моменты*/
чертей гонять по сгенеренному случайному лабиринту со сгенеренными ямами и камнями на голову
размер лабиринта - гдето на полгода
:) не, там не лабиринт вообще
мне уже стало интересно когда вы поймёте/признаете что этот ваш БК полный отстой по сравнению со спеком (скорость проца/экранная память)
Last Misson вполне реально портировать на БК... и не нужно обсерарть другие процы. дело прошлое.. а это ВЫЗОВ... и "понимание" это не главное..
Кто-то же написал DOOM на осцилографе, вы же не будете утверждать, что там проц - *****.. :)
мне уже стало интересно когда вы поймёте/признаете что этот ваш БК полный отстой по сравнению со спеком (скорость проца/экранная память)а Спек – отстой по сравнению с Амигой, значит срочно перестаём писать под Спек и вообще обсуждать его, и отныне переходим на Амигу. Ага? ;)
Я про то же... Амига стоит рядышком с БК, но это не значит, что она (БК) не интересна..
Это последний из могикан... который перенес БОЛЬШОЙ компьютер тебе на стол..:) А Спека- это оскал буржуазии... :)
- - - Добавлено - - -
БК - это мечта которая воплотилась в реальность, когда меня принимали в пионеры.. нас привели в ВЦ.. и все, я понял, что жизнь моя будет связана с компьютерами (люди в белых халатах, читающие перфоленты)... а спека- это что-то собранное на коленке в кооперативе.
Lethargeek
10.03.2019, 11:02
сдаётся мне, что на спек с амиги проще портировать)))
Как бэ... зачем? Все что было на амиге пытались перетянуть на однобитный спек.. и наоборот.. хорошие идеи всегда кто-то у кого-то... пока мы в "Ну-погоди" яйца ловили.. за бугром целая эпоха промелькнула...., а потом пришли писюки и все опошлили..
мне уже стало интересно когда вы поймёте/признаете что этот ваш БК полный отстой
http://zxpress.ru/book_articles.php?id=2404
Lethargeek
27.03.2019, 13:07
смешноватая статья даже для 1991 (особенно про "избалованность хорошим профессиональным" софтом доставило))
смешноватая статья даже для 1991 (особенно про "избалованность хорошим профессиональным" софтом доставило))в 1991-ом году было уже много хороших игр на БК.
Lethargeek
27.03.2019, 13:40
в 1991-ом году было уже много хороших игр на БК.
ага, помню я, сколько и какой был софт тогда на бк - уровня zx-игрушек года так 1984 в лучшем случае
Не забывайте что хорошие игрушки на БК писали дети - самоучки, а не буржуйские компании..
Сколько в 91м году написали хороших игрушек школьники на ZX? То-то и оно.. спека с его обилием игрушек.. разжижал мозг школьников :)
А графика на спеке - "вырви глаз" :)
Lethargeek
27.03.2019, 14:08
Не забывайте что хорошие игрушки на БК писали дети - самоучки, а не буржуйские компании..
дети-самоучки на (не только лишь) спектруме:
https://www.youtube.com/watch?v=jt7Md1huWqY
а типичная игровая "буржуйская компания" того времени - молодой программист, работающий в собственной спальне
и в комплекте зачастую такая же сурьёзная компания-издатель, состоящая из президента и секретарши
- - - Добавлено - - -
А графика на спеке - "вырви глаз"
в 1984 - в основном да (так я и говорю, что на бк и в 1991 было не лучше)
"На вкус и цвет" - фломастеры разные.. в любом случае БК был и есть интересный комп, не только из-за игрушек.. чувствуется порода.. отголоски БОЛЬШИХ машин.
И нужно не забывать, что повальное увлечение спеками у нас началось несколько позже, когда мальчишки у которых были БК подросли.. пошли в армию, институт, а потом была уже другая жизнь :(
И нужно не забывать, что повальное увлечение спеками у нас началось несколько позже, когда мальчишки у которых были БК подросли.. пошли в армию, институтПочему-то все забывают, что в конце 80-ых Спектрум был редкостью (https://ru.m.wikipedia.org/wiki/Клоны_ZX_Spectrum) (а советские аналоги Z80 начали производить только в конце 1991-го года). У меня так вообще ни одного знакомого спектрумиста не было в то время. Вот с «Микрошей» знакомый был. В школах и домах пионеров стояли БК, Агаты, Ямахи, ДВК, чуть позже УКНЦ. В компьютерных цетрах стояли ЕС-1840 и Искры. В Детском Мире стояли Атари. А спектрумов нигде не стояло. Поэтому БКшные игры 1989-1990 годов на этом фоне выглядели неплохо. Не так круто как на Ямахе, но зато доступно. Лучшее из того, что можно было иметь дома обычному человеку.
Лучшее из того, что можно было иметь дома обычному человеку.
В 1989 купили "Ленинград", но необычным человеком от этого я вряд ли стал, как и большинство других обладателей клонов спека того времени. Кстати, через год или два соседу нечаянно купили в магазине БК. Его интересовали в первую очередь игрушки и когда оказалось, что спековские игрушки на БК запустить не получится, БК вернули в магазин и купили спек (уже не помню какой).
БК интересный компьютер, но даже если выбирать "лучший" (по каким критериям?) только из советских разработок, он вряд ли будет первым. Возможно по массовости среди бытовых советских того времени он впереди.
когда мальчишки у которых были БК подросли..
У меня одноклассник торговал моими поделками для БКек в Тушино, и на накопленные бабули купил в 1993 г. Спектрум-48 кбайт ( самодел ).
Да, игр там было много, и они были существенно играбельней БКшных, в первую очередь за счет большего быстродействия Z80 - почти что в 3 раза по отношению к БК0010-3 мгц.
Возможно по массовости среди бытовых советских того времени он впереди.Да, речь об этом. Уже 1 января 1986-го года БК был на прилавках, а в организации поступил ещё в 1985-ом. Первый клон Спектрума тоже относится к 1986-ому году, но пока устранили все глюки платы и довели до нормального производства, был уже 1988-ой год. А массовое шествие началось и того позже. БК к этому времени уже прочно заняла место в школах и многие были в курсе что это такое. Как раз к этому времени и относится статья. В своём моменте она достаточно верно передавала ситуацию. Но вскоре, и очень быстро, всё изменилось в пользу Спектрума. И вообще в пользу западной техники.
И вообще в пользу западной техники.
У меня коллега торговал софтом для БК и спектрума на кассетах в период 1990-1995 г..
С его слов - всё испортили Денди.
Сколько был тираж кассет - да сотни в год - несколько городов окучивал - Орехово-Зуево, Эл-сталь, Ногинск, может еще какие - я в его дела не лез.
Ребенку покупали 3-5 картриджей, потом ребенок еще на пару-тройку др. выменивал, и всё - спрос на гейминг заканчивался.
А так да - в П-Посаде до 1990 г. о Z80 вообще никто не слыхивал.
В 1990 г. стали в НПК "Электрон" ( бывший сектор 21-го отдела ОКБ Э. под руководством Акафьва ) делать Спектрум-48 кбайт ( подпольно ), а с ~~1991 г. - и полметровые Спектрумы в корпусе БК, на КР565РУ7Г ( крошили МС1201.04 в основном на РУшки ).
Статья написана в 1990-ом году, и о Спектруме в ней ни слова. Клоны Спектрума в то время были мало распространены (или как минимум автор о них не знал). Аргументы "в пользу БК" построены на сравнении БК с клонами IBM PC. Вообще интересна постановка вопроса "DEC vs IBM". Не мог автор знать, что через полгода после выхода номера с его статьёй развалится СССР и архитектуру DEC у нас некому будет поддерживать.
А Денди да. Убийца домашних компьютеров :)
Да, речь об этом. Уже 1 января 1986-го года БК был на прилавках, а в организации поступил ещё в 1985-ом. Первый клон Спектрума тоже относится к 1986-ому году, но пока устранили все глюки платы и довели до нормального производства, был уже 1988-ой год. А массовое шествие началось и того позже. БК к этому времени уже прочно заняла место в школах и многие были в курсе что это такое. Как раз к этому времени и относится статья. В своём моменте она достаточно верно передавала ситуацию. Но вскоре, и очень быстро, всё изменилось в пользу Спектрума. И вообще в пользу западной техники.
84-85 год разработки (https://old.computerra.ru/vision/606586/)
БК никогда не был массовым. Сколько всего было выпущено БКшек?
Сколько самодельных БК ты видел? чтобы печатные платы травить, там, детали искать.
Да речь была не об этом.. холивар не имеет смысла. Получилось два поколения, первое (любители БК), к моменту появления спеки у второго (горячо любимого ностаольгического компьютера) была либо в армии либо в институте.. и проблемы БК их уже мало волновали.. Я вот например в 91 уже учился в институте и вовсю уже осваивал IBM понимая, что за ним будущее..
И выросшие в это время как грибы после дождя кооперативы клепающие спеки меня просто забавляли (сравнивая спек и IBM я понимал, что спек убог). А кто-то в это время получил свой первый спек и травму на всю оставшуюся жизнь :)
Сколько всего было выпущено БКшек?
Всеми заводами в период СССР 1983-1991 г. - порядка 500 т., из них продано населению в розницу - не менее 100 т.
Потом, в 1992-1993 г. еще порядка 100 т. сделали. Последнюю коммерческую БК11М на Э. сделали в декабре 1993, для ЧПУ - в апреле 1994 ( есть у меня такая - на ней всё делаю ).
84-85 год разработки (https://old.computerra.ru/vision/606586/)Ну тогда БК это 1979-1983 разработки. Важно же не когда разрабатывалось, а когда в магазинах появилось для широких народных масс.
БК никогда не был массовым. Сколько всего было выпущено БКшек?Ну почему? Для своего времени - скажем, на 1988-ый год, БК-0010 был массовым, во многих школах стоял. Сомневаюсь, что в 1988-ом году в СССР было больше Спектрумов, чем БК.
Сколько самодельных БК ты видел? чтобы печатные платы травить, там, детали искать.Так это уже история 1990-го года и позже. Тогда Спектрум по массовости превзошёл БК. С этим никто не спорит.
Я немного парирую S_V_B, но, с другой стороны, и соглашусь: когда я увидел первый Спектрум, уже имел к тому времени представление об Amiga, Sun и Silicon Graphics. IBM PC меня вдохновла не больше, чем ДВК, а вот Амига - да. Какой уж там Спектрум... Действительно, люди, выросшие на ДВК и БК сразу перепрыгнули на 16- и 32-разрядные машины, минуя Спектрум. Другое поколение.
68599
Но в то же время, "борьба" между Спектрумом и БК продолжалась в андеграундной культуре года до 1996-го. Тогда ещё БК-шники глумились над ZX ("ни музыки, ни графики!"), одновременно тыря графику и портируя игры со Спектрума на БК
:)
PC меня вдохновла не больше, чем ДВК, а вот Амига - да
Амига в нашей дыре была зверем неведомым, а PC сколько угодно. Амиги встречались в городах к европе поближе, в украине вообще полно.
Амига в нашей дыре была зверем неведомым, а PC сколько угодно. Амиги встречались в городах к европе поближе, в украине вообще полнов Москве были выставки Италия-2000 и Комтек-91. После них всё представление о компьютерах переворачивалось. Становилось уже не до Спектрума.
:)
Хотя, я не отрицаю, что в домашних условиях по-прежнему было интересно возиться хоть со Спектрумом, хоть с БК.
Lethargeek
27.03.2019, 19:51
Статья написана в 1990-ом году, и о Спектруме в ней ни слова. Клоны Спектрума в то время были мало распространены (или как минимум автор о них не знал). Аргументы "в пользу БК" построены на сравнении БК с клонами IBM PC.
Личный опыт: в маленьком сибирском городке на рубеже 90-х среднестатистический школьник как минимум имел представление об уровне игрового софта для: Atari-800, C64, ZX, БК, особо продвинутые имели дома ПМК или щупали песюки в кружках или у родителей на работе (которые особо не котировались, ибо были CGA либо монохром, только принц рулил); кто ходил на УПК, тот видел УКНЦ. БК в рейтинге школоты был на самом дне, ниже только калькулятор и яйцеловка (и то насчёт последнего не уверен)))
Нам очень повезло в детстве, за такой короткий период промелькнула целая эпоха. Сейчас детям и стремиться не к чему.. все есть и ничего кардинально нового не происходит.
У нас БКшками в основном парни серьезные занимались, склонные к программированию и несомненно гордившиеся тем чем занимаются.., а школота-гопота денди уважала.. картридж ткнул и понеслось. У богатеньких.. сеги были.., а когда спектрумов стало как мусора.. и игрухи копировать можно было.. наверно дети и к нему потянулись.
Lethargeek
27.03.2019, 20:09
у нас денди только с 1993-1994 расплодился, по зомбоящику про него узнали раньше, чем в магазинах
- - - Добавлено - - -
а самый первый широкоизвестный комп с игрушками был атарик, до него только пмк
У нас наоборот, Атари только в игровых салонах был. А денди дофига было потому что китай рядом.
Lethargeek
27.03.2019, 20:16
в игровых и был - так и быкашка только в школе сперва была
чтобы разницу в софте увидеть, было достаточно
Да речь была не об этом.. холивар не имеет смысла. Получилось два поколения, первое (любители БК), к моменту появления спеки у второго (горячо любимого ностаольгического компьютера) была либо в армии либо в институте.. и проблемы БК их уже мало волновали.. Я вот например в 91 уже учился в институте и вовсю уже осваивал IBM понимая, что за ним будущее..
И выросшие в это время как грибы после дождя кооперативы клепающие спеки меня просто забавляли (сравнивая спек и IBM я понимал, что спек убог). А кто-то в это время получил свой первый спек и травму на всю оставшуюся жизнь :)
А я не ради холивара. Спектрум делали в СССР вполне себе взрослые люди.
Просто линейку от IBM вообще никак нельзя было равнять с БК или Speccy или С64 итд
Одни создавали устройства для юрлиц по астрономической цене, другие создавались для обучения, развлечения и прочего использования в быту.
А здесь совершенно другие задачи и цены.
так что не надо тут разворачивать холивар про травмы и прочее.
без бытовых компов мир выглядел бы совсем не так.
а по поводу количества
Всего было произведено более 162 тысяч БК-0010/0011; завод «Экситон» в 1985—1992 годы изготовил около 125 тысяч машин: около 78 тысяч для розничной продажи и более 44 тысяч в составе школьных классов.[1] Последние произведённые экземпляры БК относятся к 1993 году[6]
287 тысяч штук.
только 48 спеков было создано более 3.5 миллионов.
это дало огромное количество людей пытавшихся писать, писавших и профессионально создававших, преимущественно игровое, ПО.
именно поэтому для БК очень мало действительно интересных игр - их было некому и не для кого писать.
Одни создавали устройства для юрлиц по астрономической цене,
В том-то и дело что в 90е все возможно было. В 91м я с оказией (прогорел как часто бывало какой-то комерц) приобрел свой первый IBM PC 386SX33 за смешные 400 долларов и естественно в сторону спека даже смотреть не стал. Да и баловство это уже было, у племянника был спек48 помню арканоид ему на басике написал,он до сих пор считает что я колдун :)
- - - Добавлено - - -
именно поэтому для БК очень мало действительно интересных игр - их было некому и не для кого писать.
опять же вы не читаете выше.. к тому времени когда "расцвел" спек, уже практически "некому и не для кого было писать на БК" -те дети выросли.., а рыночные отношения отодвинули БК.
За какие-то пять лет все перевернулось.
И еще один показатель из всех миллионов спектрумистов программерами стала очень незначительная часть, а из БКшников практически все. Располагала она знаете ли к мозговой деятельности :)
в Москве были выставки Италия-2000 и Комтек-91. После них всё представление о компьютерах переворачивалось. Становилось уже не до Спектрума.
:)
Хотя, я не отрицаю, что в домашних условиях по-прежнему было интересно возиться хоть со Спектрумом, хоть с БК.
Увы, бро, но Москва от Самары неблизко.
В 1988 году я начинал с БК 0010/0010-01
но вот только она была в клубе юных техников и их было 3 и от 30 до 15 человек народа на всё это.
а потом к нам в клуб один товарищ принес Спектрум и вот это уже было откровением.
Атари нам сбросили как неликвид (из столиц поди) еще позднее.
ну и в тоже время были уже 286 машинки.
к тому времени БК почти загнулись от перегрузки.
так вот Спек я купить смог, А БК нет.
а рыночные отношения отодвинули БК.
Точнее, рынок погнал алкашей из НЦ в охрану и торговлю. Самым выдающимся инженерам поручили присматривать за радиобудками и ЧПУ станками ( на мебельном, например :v2_frown: ).
А почему не сделали русскую Амигу ( типа УКНЦ на ВМ3-6 мгц и СОЗУ 1 такт ) - так по одной простецкой причине - с похмелья О-Ч-Е-Н-Ь сложно что либо думать, а тем более рисовать.
А не пить долго нельзя - начинает понемного проветриваться голова, и наступает ощущение, что чел в глубокой ж. сидит, и какая-то толстая вредная тетка орет на него с утра и особенно вечером, и детишки наседают "пап, дай на карман трояк !", и доченьке надо платье новое ( а то сиськи неправильно подаются перреспективным женихам ).
Lethargeek
27.03.2019, 20:46
И еще один показатель из всех миллионов спектрумистов программерами стала очень незначительная часть, а из БКшников практически все.
http://youtube-lessons.ru/wp-content/uploads/2017/06/dryjko-mem-frazy.jpg
Вполне обоснованное, те кто думать не хотел "сдавали БК обратно в магазин" (патамушто игрушек нет) :)
опять же вы не читаете выше.. к тому времени когда "расцвел" спек, уже практически "некому и не для кого было писать на БК" -те дети выросли.., а рыночные отношения отодвинули БК.
читаю конечно.
но вот есть нюансы
импортные игры
http://zxnext.narod.ru/pics/cpbyyr.gif
отечественные игры
http://zxnext.narod.ru/pics/slrugam.gif
И еще один показатель из всех миллионов спектрумистов программерами стала очень незначительная часть, а из БКшников практически все. Располагала она знаете ли к мозговой деятельности :)
прости, но это миф. больше всего программистов среди пользователей Apple //
Вполне обоснованное, те кто думать не хотел сдавали БК в магазин (патамушто игрушек нет) :)
больше всего программистов среди пользователей Apple
Дожил до седых волос, а Яблоко только пару раз юзал, не прижился как то он у нас :)
Это больше американский идол. А про БК я говорю что видел, про разницу мировоззрений среднестатистического пользователя БК и прочих спектрумов и денди.
Выше я фотку кидал чёрно-белую, сижу за ДВК в доме пионеров. Это год 86-ой, наверное. В соседнем зале был клуб авиамоделистов и у них внезапно была БК-0010 с плоской клавиатурой и монохромным монитором. Меня она притягивала гораздо больше, чем ДВК, потому что 1) не текстовые игры, 2) такую в теории можно раздобыть для дома. Спектрумов не было и в помине во всей округе. Год спустя в том же доме пионеров появился ещё класс с Yamaha MSX, но это совершенно недосягаемая техника была, она просто не продавалась. А БК появились в школе. Поэтому у нас в Москве выбор в пользу БК был очевиден в 1986-1988 годах.
http://zxnext.narod.ru/pics/slrugam.gif
Ну вот, на Спектруме пик в 1995-ом году. А на БК пик был в 1992-ом. Как раз та самая "фора", что БК получил до широкого распространения Спектрумов. Очень короткое поколение БК-шников - это 1986-1996 годы, с пиком в 1992-1993.
Вполне обоснованное, те кто думать не хотел сдавали БК в магазин (патамушто игрушек нет) :)
ой не надо ляля
что было на кассете которая шла с компом?
Дожил до седых волос, а Яблоко только пару раз юзал, не прижился как то он у нас :)
Это больше американский идол. А про БК я говорю что видел, про разницу мировоззрений среднестатистического пользователя БК и прочих спектрумов и денди.
ну а я о чем? :)
БК стоил денег 600-650 руб
плюс магнитофон, плюс монитор.
так что он скорее всего в школе\техникуме на информатике, либо у людей с деньгами.
- - - Добавлено - - -
Выше я фотку кидал чёрно-белую, сижу за ДВК в доме пионеров. Это год 86-ой, наверное. В соседнем зале был клуб авиамоделистов и у них внезапно была БК-0010 с плоской клавиатурой и монохромным монитором. Меня она притягивала гораздо больше, чем ДВК, потому что 1) не текстовые игры, 2) такую в теории можно раздобыть для дома. Спектрумов не было и в помине во всей округе. Год спустя в том же доме пионеров появился ещё класс с Yamaha MSX, но это совершенно недосягаемая техника была, она просто не продавалась. А БК появились в школе. Поэтому у нас в Москве выбор в пользу БК был очевиден в 1986-1988 годах.
http://zxnext.narod.ru/pics/slrugam.gif
Ну вот, на Спектруме пик в 1995-ом году. А на БК пик был в 1992-ом. Как раз та самая "фора", что БК получил до широкого распространения Спектрумов. Очень короткое поколение БК-шников - это 1986-1996 годы, с пиком в 1992-1993.
да да помню я этот смертный грех БК0010. с фокалом, черно-белым монитором и пленочной клавиатурой. Писать на ней что-то было ооочень сложно.
Ямаху видел 1 раз. Один раз ЕС. Не Москва да :(
Но из-за немассовости БК нет ЦА для ПО - нет ПО.
потому и поколение короткое. Все разбежались туда где есть люди.
что было на кассете которая шла с компом?
Мне купили БК-0010-01 в 1991 году. На кассете была унылая хрень, которая либо сподвигала к занятию программированием, либо "сдать БК обратно в магазин".
Меня, например, - начать программировать. Наличие игр на бейсике было примером и стимулом к изучению бейсика, а фокал я даже не рассматривал как что-то полезное. Тормознутость бейсика и ограниченные возможности стали стимулом к изучению ассемблера, изоляция и ограниченность в софте стали стимулом для написания софта для себя. В общем, БК таки стимулирует стать программистом. Хотя, у некоторых моих одноклассников тоже были БКшки и они делились со мной кассетами с играми, так что и некоторые игры я на БК тоже играл, и эти игры так же становились стимулом к программированию, хотелось понять, как это работает и сделать так же или лучше.
плюс магнитофон, плюс монитор.
Ну, магнитофон как правило не был уже дефицитной редкостью. Дефицитной редкостью был двухкассетник или хороший магнитофон.
Монитор не обязателен. БК отлично подключалась к телевизору. Я так всё время пользования БК использовал телевизор. Ибо ни я, ни мои родители никогда не были людьми с деньгами.
Lethargeek
28.03.2019, 12:22
Мне купили БК-0010-01 в 1991 году. На кассете была унылая хрень, которая либо сподвигала к занятию программированием, либо "сдать БК обратно в магазин".
Меня, например, - начать программировать. Наличие игр на бейсике было примером и стимулом к изучению бейсика, а фокал я даже не рассматривал как что-то полезное. Тормознутость бейсика и ограниченные возможности стали стимулом к изучению ассемблера, изоляция и ограниченность в софте стали стимулом для написания софта для себя.
Ха! Стимулом к изучению ассемблера стал встроенный монитор турбо-90, позволяющий с относительным удобством хакать спектрумовские игрушки, а как раз возможность вволю наиграться в неунылую нехрень дома стала стимулом в игровом салоне не играть, а поковыряться в других компах (что очень быстро убедило в безнадёжности и малопригодности любых бейсиков, а также полной отстойности быкашек - на атари некоторые бейсиковые игры игрались и выглядели лучше быкашных машиннокодовых). Дополнительным плюсом стало то, что владельцы тягу к знаниям уважали и со временем пускали уже бесплатно, когда было мало клиентов. Минусом - си осилил значительно позже форта и ассемблеров x86 и z80 из-за стойкого приобретённого на слабых компах недоверия к ЯВУ вообще.
а также полной отстойности быкашек - на атари некоторые бейсиковые игры игрались и выглядели лучше быкашных машиннокодовых
Да, так и есть.
Всё дело в быстродействии.
И ориентации советских разработчиков железа на дешевизну и максимальную простоту компов ( в части их проектирования ), в ущерб всем др. параметрам.
Причины - разработчики получат премии/квартиры/дачи при любом результате работ, разве что кроме изображения на экране "квадрата малевича".
Как то прикинул - сколько МЭП делали для гражданских от шт. продукции - с учетом серий К155, К561 и др. в общей сложности - в районе менее 15% от общего вала продукции. Всё остальное - оружие и средства производства оружия. В МРП уровень бытовухи был повыше - в районе 25%, за счет многочисленных телеков-мафонов-приемников. Но МРП и РЛС, и спутники делала - вовсе не для быта.
Lethargeek
28.03.2019, 13:22
Да, так и есть.
Всё дело в быстродействии.
И ориентации советских разработчиков железа на дешевизну и максимальную простоту компов ( в части их проектирования ), в ущерб всем др. параметрам.
В основном второе - подозреваю, что не только не старались, но и в принципе не понимали, что такое домашний комп, зачем он нужен, и на что должен быть способен. Насколько помню, сам по себе атариевский бейсик довольно медленный, если не учитывать компиляторы, об этом и в буржуйской прессе писали; но при том он позволял неплохо пользоваться возможностями железа.
В основном второе - подозреваю, что не только не старались, но и в принципе не понимали, что такое домашний комп, зачем он нужен, и на что должен быть способен.Да, из воспоминаний о создании БК следует, что руководство института 5 лет игнорировало разработку персонального компьютера, начатую инженерами по собственной инициативе, а в конце концов и вовсе взбесилось, предложив "разбить себе о голову" эту штуку.
Насколько помню, сам по себе атариевский бейсик довольно медленный, если не учитывать компиляторы, об этом и в буржуйской прессе писали; но при том он позволял неплохо пользоваться возможностями железа.Зато Бейсик С64 был без графики. И не факт что Бейсик для Atari поддерживал вещественные числа - большинство Бейсиков в то время были целочисленными. В отличии от БК. Вильнюсовский Бейсик для БК оказался тем, что с него можно было сразу перейти на Microsoft Quick Basic на PC. Нужно было выучить только команду "Screen 12", и можно переносить программу с БК без изменений.
konst_st
28.03.2019, 16:17
Я заинтересовался компьютерами еще до того, как увидел их вживую. Помнится, изучал схемы ПК в журнале Радио (кажется это был Радио-86РК). Так же в руки попалась неплохая книга про простейшую микро ЭВМ на 580 процессоре с довольно подробным описанием двоичной логики, ассемблера и т.п.
Впервые получил доступ к компьютеру на УПК (учебно-производственный комбинат) - это был класс БК-0010. С тех пор от компьютера меня уже было не оторвать :)
Быстро освоил бейсик, начал изучать ассемблер. Там же был класс Yamaha MSX2 - на нем тоже немного довелось попрограммить на бейсике. Затем (где то в 90 году) мне купили БК-0010.
Конечно, по играбельности БК был слабоват. В сравнении с Ямахой и звукового сопроцессора не было, и графика всего 4 цвета, что для игр явно недостаточно, и памяти маловато. Помню как здорово на Ямахе смотрелся тот же Vampire Killer. Но для обучения программирования в то время БК вполне подходила и, что особенно важно, была достаточно легко доступна.
Бейсик на БК был очень даже ничего. Отличная плавающая арифметика - достаточно быстрая и высокая точность. Можно было быстро решать огромное количества всевозможных задач - численное решение всяких систем уравнений (в том числе и дифференциальных), создание всевозможных мат.моделей и т.п., вывод результатов в виде графиков. Помнится я с этим много развлекался. Ассемблер для подобных экспериментов не особо подходил :)
На ассемблере тоже много чего экспериментировал.
В общем БК для меня был отличной базой для дальнейшего развития. С тех пор я примерно тем же и занимаюсь - пишу софт для микроконтроллеров, иногда пишу софт для моделирования всевозможных физических процессов и т.п. И до сих пор получаю от этой работы удовольствие :)
Lethargeek
28.03.2019, 19:03
И не факт что Бейсик для Atari поддерживал вещественные числа - большинство Бейсиков в то время были целочисленными.
факт; правда, так себе поддерживал в первой версии:
https://atariwiki.org/wiki/Wiki.jsp?page=Atari%20Basic%20vs.%20Commodore%20C6 4%20Basic%20vs.%20Apple%20II%20Basic
но к 1984 это пофиксили
Мне купили БК-0010-01 в 1991 году. На кассете была унылая хрень, которая либо сподвигала к занятию программированием, либо "сдать БК обратно в магазин".
что за странное желание "сдать назад"?
Меня, например, - начать программировать. Наличие игр на бейсике было примером и стимулом к изучению бейсика, а фокал я даже не рассматривал как что-то полезное. Тормознутость бейсика и ограниченные возможности стали стимулом к изучению ассемблера, изоляция и ограниченность в софте стали стимулом для написания софта для себя. В общем, БК таки стимулирует стать программистом. Хотя, у некоторых моих одноклассников тоже были БКшки и они делились со мной кассетами с играми, так что и некоторые игры я на БК тоже играл, и эти игры так же становились стимулом к программированию, хотелось понять, как это работает и сделать так же или лучше.
а разве бывает по другому.
С БК у меня не сложилось, потому как у нас в продаже их не было. Тем более таких денег у меня в 1991 году не было
а вот тот человек который познакомил меня с Спектрумом с АУ к нам как то даже БК0011 приносил. то ли его, то ли брал у кого.
Ну, магнитофон как правило не был уже дефицитной редкостью. Дефицитной редкостью был двухкассетник или хороший магнитофон.
Монитор не обязателен. БК отлично подключалась к телевизору. Я так всё время пользования БК использовал телевизор. Ибо ни я, ни мои родители никогда не были людьми с деньгами.
ну как то раз я взял БК домой на выходные. И всё на этом.
ну как то раз я взял БК домой на выходные. И всё на этом.У меня пару недель гостил Спектрум, пару недель УКНЦ и пару недель Денди. Обменивался со знакомыми: я им свою БК, они мне это. В общем, я вообще не понял, что на этих компьютерах можно делать и зачем :) Играть точно лучше на Денди - подумал я. И раздобыл себе Gameboy на халяву :) А программировать продолжил на БК. Там уже вскоре и 286-ой компьютер появился.
что за странное желание "сдать назад"?
Могу сказать из личного опыта наблюдения - сдавали. И в магазины и в комиссионки.. Даже я свой БК продал потому что... УК-НЦ появился :) Молодой был, глупый :) Шаз - жалею. Пусть и имею уже три из четырёх - всё равно - свой экземпляр - он... свой :)
- - - Добавлено - - -
Но мой пример - точно не показатель - к тому времени, когда я купил БК - я уже очень приличное количество лет и развлекался и работал на PDP-11 совместимом, так что - процессор совместим с PDP-11 - это был как приговор - НАДО БРАТЬ! :)
Раз уж пошла групповая терапия. Я свою БК купил по объявлению году в ~92, на коробке год выпуска 91-й. Юноше купили не то Спектрум не то Денди, программирование на БК его не увлекло. Он смотрел на меня с удивлением, я на него тоже -- играть хотел, когда можно было программировать. Это была уже эпоха, когда в компьютерном клубе Дворца пионеров, где я проводил все доступное время, были 286-ые и наверное уже появлялись 386-е, и всем было понятно, что будущее -- это не БК. Но время за современным компьютером было ограничено, а мне хотелось программировать еще пуще и больше и как-то так сложилось, что у родителей нашлись деньги на это чудо-юдо. В любом случае, свою БК я сумел вклячить в тракт телевизора Юность Р-603, показывал он волшебно, а во время загрузки с кассеты можно было переключиться на телевизор. Доступность сильно более продвинутых компьютеров не умаляла радости владения своим. Забыл, как звался суперский такой ассемблер с редактором, который работал с кассеты. Довольно долго я делал в нем вращающийся кубик. Линии я осилил, но до конца не довел. Помню, что начинал он хорошо кубиком, но потом его уносило в какое-то другое измерение ;)
У меня пару недель гостил Спектрум, пару недель УКНЦ и пару недель Денди. Обменивался со знакомыми: я им свою БК, они мне это. В общем, я вообще не понял, что на этих компьютерах можно делать и зачем :) Играть точно лучше на Денди - подумал я. И раздобыл себе Gameboy на халяву :) А программировать продолжил на БК. Там уже вскоре и 286-ой компьютер появился.
ага только вот тогда БК у меня просто лежал на выходных. он не подключался к ТВ
а вот Дельта С128 купленная в 93 уже подключалась.
правда магнитофон я взял в 94.
А вот предки мои увлечения не поддерживали.
Денди была у однокласника но как то не впечатлила - компы давали больше.
он не подключался к ТВ
Все советские телемастера ( из городских СЦ ) за несколько бутылок подключали БК/видаки по НЧ к любому советскому телеку.
А вот если нужен был декодер ПАЛ ( для видака ) - то речь шла уже о нескольких ящиках бухла ( для ~1991 г. )
Я заработал свои 400 убитых енотов мотаясь в новосиб на выходных покупая ТДКС для телеков, пропустить "рабыню Изауру" было никак нельзя... а советские телики горели раз в неделю....вот и поднялся студент... мужик который продавал все барахло... растратчика... даже не понял.. нафига так много за "беспонтовый ящик" (386 SX)..то-ли дело Бэха... :)))
Все советские телемастера ( из городских СЦ ) за несколько бутылок подключали БК/видаки по НЧ к любому советскому телеку.
А вот если нужен был декодер ПАЛ ( для видака ) - то речь шла уже о нескольких ящиках бухла ( для ~1991 г. )
ага, чукча не читатель, чукча писатель.
для тебя крупными буквами.
РОДИТЕЛИ МОЁ УВЛЕЧЕНИЕ КОМЬЮТЕРАМИ НЕ ПОДДЕРЖИВАЛИ.
БК ВЗЯЛ С КЛУБА НА ВЫХОДНЫЕ (СУББОТА, ВОСКРЕСЕНЬЕ). ПОДКЛЮЧИТЬ НЕ СМОГ.
ПОТОМ КУПИЛ ДЕЛЬТУ С128 - В НЕЙ БЫЛ НЧ ВЫХОД.
это чтобы в телевизор не лазить.
так понятнее?
А так да подключить проблем не было совсем
РОДИТЕЛИ МОЁ УВЛЕЧЕНИЕ КОМЬЮТЕРАМИ НЕ ПОДДЕРЖИВАЛИ.
а вот это загадка - обычно наоборот, тайна суровости навсегда раскрыта )
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot