PC-01 Lviv

It is currently 28 Mar 2024, 21:52

Forum Games WEB Tape Loader Twitter RSS

All times are UTC+03:00




Post new topic  Reply to topic  [ 115 posts ]  Go to page Previous 14 5 6 7 8 Next
Author Message
PostPosted: 14 Sep 2013, 10:54 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Quote:
Прикольно !!!!
Это быстродествие "не Львова" вот поэтому и прикольно... :-)
боюсь, что когда перепишу процедуру вывода на экран на команды КР580(и их быстродействие), дак совсем не прикольно будет... :-) :-( У меня уже были попытки вывода на экран путём сравнивания всего экрана с таким же масивом (игровым полем)... ну так как в наших эмуляторах VRAMDirty и VRAM сравнивается и выводит на экран... дак переписав на команды КР-580 очень медленно было... уже и процедуру куда-то забросил...
Quote:
тоже самое в LVT можно ?
Буду добиваться что-бы можно было, но...
1.надо сначала написать игру хоть как-то :-) т.е. на Дельфи с использованиеем моего модуля
2. Перевести каждую процедуру в команды КР-580 (с использованиеем модуля)
3. Потом уж как-то компилировать в Память ПК-01. Видимо это будет комбинированно как-то... НО ВОЗМОЖНО!
Quote:
по спрайтам вот отсюда http://zx-pk.ru/showthread.php?t=20498
Спасибо осмотрюсь чего там..
Quote:
Вывод спрайта 12x16
За код конечно спасибо! Но... ты не забывай что я в КР-580 дилетант.. И поэтому прошу выкладывать код с максимально возможным описанием... т.е. в какие регистры задается адрес спрайта, в какие ширина/длина и т.д.


Top
   
PostPosted: 14 Sep 2013, 11:22 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Итак..
В планах опробовать следующее... Что из этого явно неверно (верно) подскажите плиз..
Существует экран, куда будет выводится игра(сама карта с самолетом) это 256х200, существует игровое поле (Playingfield) размером больше 256х250 (256х300) в котором будет формироваться игра. Видимо Playingfield необходимо располагать от 32768 там же и процедуру вывода на экран (DisplaceAndReproducePlayingField) которая в зависимости от смещения (SMPlayingfieldY) будет выводить ту часть игрового поля на экран которую нужно (ну это видимо типа скролла)...
Возникающие у меня вопросы существует ли процедуры скролла подходящего мне ? Где ?
Для «тупая перерисовка» всего поля (байт в байт) быстродействия ведь нехватит!?...
«Долго» ли выполняется само переключение памяти «ОЗУ» и «Экранное ОЗУ»?.. стоит ли включать и отключать за каждым выводом спрайта?... Или стоит переключить один раз и вывести все спрайты на экран?... Если переключившись на «само ОЗУ» быстродействие обращения (чтен ие и записи ячеек ) медленнее чем к памяти «неЭкранОЗУ»?... Можно ли (по быстродействию) «Экранное ОЗУ» испоьзоваить для стравнения и с игровым полем (Playingfield)?...
Нужны эффективные процедуры выводов спрайтов и их наложением на другие спрайты и т. д. С описанием как их использовать
(По ссылке Марата сейчас «прошвырнусь»...)
Благодарю за внимание.


Top
   
PostPosted: 14 Sep 2013, 13:26 
Offline
Site Admin
User avatar

Joined: 24 Jul 2008, 12:05
Posts: 1070
Quote:
т.е. в какие регистры задается адрес спрайта, в какие ширина/длина и т.д.
В DE адрес спрайта, в HL место в видеопамяти. Высота, это верхняя строчка (MOV B,16), ширина захардкоджена на 12. Чтобы ее изменить нужно добавлять фрагменты
Code:
LDAX D
INX D
MOV M, A
INX H
для каждых четырех пикселей. И, соответственно, в строке LXI B, 62 уменьшать значение на единичку.
Хотя, для больших спрайтов имеет смысл сделать два цикла.
Quote:
Существует экран, куда будет выводится игра(сама карта с самолетом) это 256х200, существует игровое поле (Playingfield) размером больше 256х250 (256х300) в котором будет формироваться игра.
Получается, что вся игра меньше двух экранов?
Quote:
Видимо Playingfield необходимо располагать от 32768 там же и процедуру вывода на экран (DisplaceAndReproducePlayingField)
Не влезет. 256х256 пикселей - это уже 16К байт. А у Вас выше 32768 всего 16К, дальше идет ПЗУ.
Quote:
Возникающие у меня вопросы существует ли процедуры скролла подходящего мне ? Где ?
В этой же теме. Сообщение самого Калашникова от 04 июн 2012 02:50 am
http://lvovpc.ho.ua/forum/viewtopic.php ... t=30#p1648
Скролл на PUSH/POP и перемещении вершины стека. Это, фактически максимум для "Львова". Но, боюсь, даже его не хватит для нормальной полноэкранной игры.
Quote:
Для «тупая перерисовка» всего поля (байт в байт) быстродействия ведь нехватит!?...
Нужно писать логику, чтобы не перерисовывать все поле. Например, по краям у нас вечная зелень, зачем ее перерисовывать? Можно схитрить и больше, как напирмер Чистяков в Аэрокобре:
http://lvovpc.ho.ua/forum/viewtopic.php?f=3&t=108
Так же, думаю стоит уменьшить отображаемый экран.
Quote:
«Долго» ли выполняется само переключение памяти «ОЗУ» и «Экранное ОЗУ»?.. стоит ли включать и отключать за каждым выводом спрайта?
Нет, не особо долго. Но тут вопрос сколько и каких спрайтов у Вас на экране планируется. Для спрайта, скажем, выстрела 4х4, если их будет с добрый десяток, то тут переключение ОЗУ будет сильно бить по производитлеьности. Если же планируется 4-5 спрайтов игрока и врагов (24х24 либо 16х15), то можно переключать.
Quote:
Можно ли (по быстродействию) «Экранное ОЗУ» испоьзоваить для стравнения и с игровым полем (Playingfield)?

Можно.
Quote:
Нужны эффективные процедуры выводов спрайтов и их наложением на другие спрайты и т. д. С описанием как их использовать
Для данной игры это бессмысленно. У Вас и так ожидается аховая ситуация с производительностью. Рисуйте спрайты на однотонном фоне. Самолетик и так не может вылетить за пределы реки, а при пересечении должен сразу взрываться. Конечно, некрасиво будет при пролете заправки, но это уже минимальное зло.


Top
   
PostPosted: 14 Sep 2013, 16:35 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Нда.... Результаты моих исследований быстродействия ПК-01 плачевней чем я думал... :-( :-)
Вот создал простейшую процедуру по выводу спрайтов...
Code:
Procedure RefreshScreenLV;//Переброска и воспроизвести игровое поле
var WremW:Cardinal;wremb:Byte;
Label ForWremW,m1,m2;
begin
{Переброска Игрового поля  в реальную память Львова}
For WremW:=0 to (256*64)  do begin WriteRAM(wremW+32768,PlayingfieldLV[wremW]);end;


MVIA($00); OUT_($C2);// включить видоОЗУ

LXIH($4000); // в HL -адрес ВОЗУ
LXID($8000);// в DE -адрес ОЗУ спрайта

m1:LDAXD;// в рег A значение по адр DE

if GetRgA<> ReadVRAM(GetRgHL-$4000) then MOVMA;// рег А в адрес в HL -адрес ВОЗУ

INXH;INXD;// приплюсовать 1 к регПарам

{256х200 линий (16384 + 64*200 = 29184 ($7200) экран игры}
{256х100 линий (16384 + 64*100 = 22784 ($5900) экран игры}
{256х50 линий (16384 + 64*50 = //19584 4C80 экран игры}
{256х25 линий (16384 + 64*25 = //17984 4640 экран игры}

movAH; Cpi($46);  If JNZ then goto m1; // если не нулевое продолжать вывод
movAL; Cpi($40);  If JNZ then goto m1; // если не нулевое продолжать вывод

MVIA($02); OUT_($C2);// отключить видоОЗУ
end;

И вот результаты... :-(
Attachment:
1.7z [282.89 KiB]
Downloaded 828 times
дак это еще при всём при том, что ТОЛЬКО эта процедура выпоняется с Львовским быстродействием, а всё остальное (генерация уровня) «Дельфийским» быстродействием... да и проверка значения и в случае не равества байта в ВОЗУ (if GetRgA<> ReadVRAM(GetRgHL-$4000) then MOVMA;) выполняется тоже Дельфи командами...
Насколько я понял, что даже если я учту советы все которые Вы мне дали, да и советы со всего мира в обще, врядле исправят ситуацию и у меня получится, что-то сделать (не «обрубанное») ?!... И никакие «хистрости» с кодом и выводом на экран мне врядле помогут. :-( Если еще учесть, что анализ ситуации и ее обработка тоже будет написана на подобном быстродействии то... - О УЖАС! Точнее о УЖОС!

Иль это у меня модуль чёто выёживается ?... :-)

Прошу заценить примеры испытаний (RiverRaid025.exe RiverRaid050.exe RiverRaid100.exe RiverRaid200.exe). Это такое (приблизительно) и будет быстродействие при выводе спрайтов соответственного размера???...

Можно конечно «подёргаться» со смещением не 1 пиксель в вертикали, но что оно будет? Да и по горизонтали сложности на 1 пиксель, а если на 4, то это будет уже не Ривер!...


Top
   
PostPosted: 14 Sep 2013, 16:47 
Offline
Site Admin
User avatar

Joined: 24 Jul 2008, 12:05
Posts: 1070
sas9568635
Вы выбрали себе очень трудную для реализации на ПК-01 игру. Советую начать с чего-нибудь со статическим экраном.
Quote:
Если еще учесть, что анализ ситуации и ее обработка тоже будет написана на подобном быстродействии то... - О УЖАС! Точнее о УЖОС!
Это да.
Quote:
И никакие «хистрости» с кодом и выводом на экран мне врядле помогут.
Нужно кардинально менять подход к движку. Опять же, для РиверРейда лучше использовать наработки Чистякова. Не скажу, что Ривер на "Львове" невозможен. Но не с таким подходом "в лоб".


Top
   
PostPosted: 14 Sep 2013, 17:29 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Quote:
Вы выбрали себе очень трудную для реализации на ПК-01 игру.
Я вибрал интересную МНЕ для реализации игру.... Меня интересовало написать её бесконечной используя генераторы СЧ и процедыры для красивой обработки СЧ и прорисовки уровней...
Quote:
Советую начать с чего-нибудь со статическим экраном.
Не понимаю что это такое....
Quote:
Нужно кардинально менять подход к движку. Опять же, для РиверРейда лучше использовать наработки Чистякова. Не скажу, что Ривер на "Львове" невозможен. Но не с таким подходом "в лоб".
Я думал про это. Понимаешь все "хитрости" будут отражаться в исполняемом коде, в его количестве, а увеличение обрабатываемого процессором кода, приведет к тому же!!, т.е. падению быстродействия. Да и Я еще не спец по написанию и оптимизации каких либо игрушек, да и в Асме (КР580) я не шурупаю. Спецы конечно может и умудрятся написать Ривер для ПК-01 но все равно это будет не то!..
Я конечно попытаюсь что-то написать для Львова (и скомпилировать в ЛВТ) но... на моё сожаление это будет не ривер (ну или ривер в окошке (52х52)... :-) Шучу конечно.

Видимо упрощу задачу - сделаю весь экран синим, спрайты движение по 4 пиксела(горизонтально), небольшие зеленые островки... вообщем неполучается настоящий Ривер - попытаюсь зделать жалкую подобию на Ривер тем более это для аппарата который жалкое подобие на комп. На ПК-01 есть подобная игрушка "Полет" называеться... вот попытаюсь сделать подобную, но более отработанную, чтобы хотябы у самого было желание поиграться.

Zelya, а ты тест мои запускал?... Что скажешь?... Похоже, что оно на реальном Львове так и будет? (по быстродействию) (приблизительно)?... при таком выводе на экран?...


Top
   
PostPosted: 14 Sep 2013, 17:38 
Offline
Site Admin
User avatar

Joined: 24 Jul 2008, 12:05
Posts: 1070
Quote:
Не понимаю что это такое....
Это когда игровой экран не двигается.
Quote:
Понимаешь все "хитрости" будут отражаться в исполняемом коде, в его количестве, а увеличение обрабатываемого процессором кода, приведет к тому же!!, т.е. падению быстродействия.
Image
Вы либо не читаете половины из того, что я пишу, либо отказываетесь понимать прочитанное. Самый простой пример. У Вас по краям всегда зеленая трава. Зачем ее каждый раз перерисовывать? Рисуйте скажем в диапазоне 30-225, а не 0-255. Хитрость? Хитрость. И стало быстрее. В идеале все сведется к тому, что перерисовываются только те точки, которые поменяли цвет (см. Чистякова).


Top
   
PostPosted: 14 Sep 2013, 19:21 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Quote:
Вы либо не читаете половины из того, что я пишу, либо отказываетесь понимать прочитанное.
Читаю! Причём внимательно!
Quote:
Самый простой пример. У Вас по краям всегда зеленая трава. Зачем ее каждый раз перерисовывать? Рисуйте скажем в диапазоне 30-225, а не 0-255. Хитрость? Хитрость. И стало быстрее.
Да знаю я про это!
Мои тесты указывают на то что ОБЩИЙ ОБЪЕМ ПРОРИСОВАННЫХ ТОЧЕК НЕ МОЖЕТ БЫТЬ БОЛЕЕ скажем 50х256 (либо 12800 пикселей) иначе БЫСТРОДЕЙСТВИЕ СВОДИТСЯ НА НЕТ! ХОТЬ ЛОПНИ! И ХОТРОСТИ ТУТ УЖЕ НЕ ПОМОГУТ ! Как ты обхитришь, если ИХ НАДО прорисовывать?.. и если даже без "травы", дохрена точек которые надо будет прорисовывать. А кеширование (определение точек которые не надо прорисовывать) ведь тоже занимает время!... и быстродействие все равно падать будет. И мой тест этому пример. Пусть не идеальный, но пример!

Zelya, я понимаю ,что ты создал Рика, А Читстяков Аэрокобру, но... и тебя и у него прорисовка не в сравнении с Ривером... и ты сам ведь это понимаешь, да в Ривере еще и поточечное передвижение экрана и самолета и поточечная обработка столкновений... хитри не хитри.. а циклы какие-то писать нада которые садят быстродействие. У тебя и Чистякова проще.

Рик: объектов мало, скрола не нужно, быстродействие не "полётное", ускорения объекта Рик не нужно, шаг по 4 пиксела, обработка тоже по 4 пиксела.

Аэрокобра: Объекты маленькие, "скрол" не быстрый, ускорения его не нужно, скрол справа-налево!!! по 4 пиксела, обработка столкновения тоже по 4 пиксела, экран 70% пустой(черный), прорисовка только ланшафта (и то не всего) и объектов, что прорисовывать можно определять только по кординатам текущих объектов и по самой нижней части экрана (небольшой кусок все таки..)

И что я не так понимаю?... и что я не читаю?... тобой писанное?...
Quote:
В идеале все сведется к тому, что перерисовываются только те точки, которые поменяли цвет (см. Чистякова).
Вот в моих тестах так и делалось! см.процедуру. А 50х256 (либо 12800 пикселей) прорисовку считаю, что это мало для Ривера.

З.Ы. Я так понял ты меня считаешь за дурака больше, чем Я есть на самом деле!...
Либо тебе этого так хочеться!... :-)


Top
   
PostPosted: 14 Sep 2013, 21:54 
Offline
User avatar

Joined: 11 Aug 2008, 17:05
Posts: 1405
Location: Украина
Quote:
Вы выбрали себе очень трудную для реализации на ПК-01 игру. Советую начать с чего-нибудь со статическим экраном.
И я знаю такую игру - "Preliminary Monty"! :mrgreen:



Круг замкнулся.

_________________
Carthago delenda est, Carthaginem delendam esse


Top
   
PostPosted: 14 Sep 2013, 22:03 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Не-е-е.... За монтисумму я не возьмусь! :-)
попробую для начала Крестики нолики... возможно будут с тридэ звуком :-):-):-)


Top
   
PostPosted: 15 Sep 2013, 21:06 
Offline

Joined: 28 Nov 2011, 20:54
Posts: 43
Quote:
Вот в моих тестах так и делалось! см.процедуру. А 50х256 (либо 12800 пикселей) прорисовку считаю, что это мало для Ривера.
Посмотрел видео на ютубе. похоже за кадр обновляется процентов 10-15 пикселей. Похоже что техническая возможность таки есть.


Top
   
PostPosted: 15 Sep 2013, 23:43 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
Quote:
Посмотрел видео на ютубе. похоже за кадр обновляется процентов 10-15 пикселей. Похоже что техническая возможность таки есть.
Неа! :-) неверю! :-) В смысле в реализацию Ривера на ПК-01, даже если и 10-15 процентов...

Задумайся какие "больные места" есть...

1. Поточечная прорисовка движения экрана в вверх-вниз
2. спрайтов тоже поточечная прорисовка (и это представь на 4 пикселах в байте)
3.Поточечное определение столкновения.(и это представь на 4 пикселах в байте)
4.Накладка спрайтов ТОЖЕ ПОТОЧЕЧНАЯ (и это представь на 4 пикселах в байте)
5. Ускорение самолета при нажатии "вверх", скажем скорость норм = 10едениц потом -20-30-40-50 (помоему раза 3 или 4 ускоряется)
6. Скорость процессора не ахти
7.... (может еще чего забыл)

Если бы был ОДИН пункт из этих шести (и более), то я бы еще мог поверить в то, что можно исхитрится как-то... ну а "тут"... ведь завал полный! :-)

Кстати а какое у атари быстродействие?... Если разов в шесть больше чем в ПК-01 - тогда понятно, почему она на нём Ривер работает нормально.... Было бы в ПК-01 такое быстродействие тогда - ДА! Соглашусь! Можно бы было!
А на Львове... по 4 пиксела из байта "выковыривать", накладывать, и опять "вковыривать" в байт что-бы вывести на экран... на это тоже ведь нужны циклы которые занимают время...

Вот представь Аэрокобру :-) Если сделать поточеную (а не по 4точки) прорисовка ландшафта, также поточечное (а не по 4) прорисоку объектов... (и так все остальные пункты) во сколько раз уменьшиться её скорость работы ? В 4?.. В 16?.. Для примера замедли эмулятором Аэрокобру во столько же раз (в 4 или в 16) - Вот это и будет Ривер для Львова! Кто в него играть будет?

Zelya поспешно начал со мной спорить и очередной раз считать за дурака... :-) просто он не очень то вник, в то, насколько гигантская куча нужна всяких хитростей которые не покроет быстродействие ПК-01.

На дельфи я запроста напишу Ривер :-) под свой эмулятор (под экран ПК-01) :-) Может позже, "по приколу"... Быстродействие в Дельфи покроет мне всё! :-) И полноэкранное кеширование... и поточечную прорисовку спрайтов в кеш экрана.. .. и т.д. в этом я не сомниваюсь не на секунду...
А в ПК-01 нет главного - БЫСТРОДЕЙСТВИЯ которым можно покрывать гигантское кол-во циклов хитростей!
Вот сообственно и всё ! :-)


Top
   
PostPosted: 16 Sep 2013, 00:11 
Offline

Joined: 20 Apr 2012, 16:00
Posts: 372
Location: Конотоп
ДОП.
В точности быстродействия процессора(6502) на Атари я не нашел...
Но вот что вычитал...
Quote:
MOS Technology 6502, или просто 6502, — восьмиразрядный микропроцессор, разработанный компанией MOS Technology в 1975 году. В момент появления на рынке он был дешевле аналогичных изделий компаний-конкурентов (Motorola и Intel). Несмотря на это, а также низкую тактовую частоту, в среднем он показывал сходную с ними производительность за счёт продуманных способов адресации памяти, коротких циклов исполнения команд и некоторой конвейеризации. .....
http://ru.wikipedia.org/wiki/6502


Top
   
PostPosted: 16 Sep 2013, 01:07 
Offline

Joined: 28 Nov 2011, 20:54
Posts: 43
Quote:
Задумайся какие "больные места" есть...

1. Поточечная прорисовка движения экрана в вверх-вниз
2. спрайтов тоже поточечная прорисовка (и это представь на 4 пикселах в байте)
3.Поточечное определение столкновения.(и это представь на 4 пикселах в байте)
4.Накладка спрайтов ТОЖЕ ПОТОЧЕЧНАЯ (и это представь на 4 пикселах в байте)
5. Ускорение самолета при нажатии "вверх", скажем скорость норм = 10едениц потом -20-30-40-50 (помоему раза 3 или 4 ускоряется)
6. Скорость процессора не ахти
7.... (может еще чего забыл)
1. Не понял причем здесь поточечность.
2. Просто 4 разных спрайта на модель
3. не уверен, что столь критично. столкновение проверяется только для самолетика да снарядов
4. вот даже не уверен, что нужно. самолет только над водой, корабли тоже друг друга не заслоняют. но может был невнимателен.
5. Ну тут не знаю. не играл

А вот то, что ривер рейд заточен под очень своеобразный видеоконтроллер у которого и памяти с гулькин...
эт да. для этого контроллера программирование своеобразное, ограничений много, но в это игре их классно обошли.


Top
   
PostPosted: 16 Sep 2013, 09:47 
Offline
Site Admin
User avatar

Joined: 24 Jul 2008, 12:05
Posts: 1070
Quote:
Аэрокобра: Объекты маленькие, "скрол" не быстрый, ускорения его не нужно, скрол справа-налево!!! по 4 пиксела, обработка столкновения тоже по 4 пиксела, экран 70% пустой(черный), прорисовка только ланшафта (и то не всего) и объектов, что прорисовывать можно определять только по кординатам текущих объектов и по самой нижней части экрана (небольшой кусок все таки..)
Размер и скорость скролла и для River Raid более чем достаточны. Третий уровень аэрокобры - как раз то, что Вам нужно, там ландшафт обступает игрока с двух сторон. И там уже 50%-60% экрана синие. Вобщем-то не понимаю в чем проблема. В Вашей игре черная зона просто станет синей, а синяя - зеленой. Абсолютно также нужно вести себя с 4-х пиксельным смещением и проверкой стлокновений. Это все полностью нормально.
Единственное, что кардинально отличает две игры, это то что Аэрокобра имеет горизонтальный скролл. Да, тут не попрешь, это легче. Ну, сделайте хотя бы "горизонтальный" Ривер. А мы все вместе подумаем, как его развернуть.
Quote:
попробую для начала Крестики нолики... возможно будут с тридэ звуком :-):-):-)
А хотя бы их! Для начала :)


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 115 posts ]  Go to page Previous 14 5 6 7 8 Next

Forum Games WEB Tape Loader Twitter RSS

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited