Портировать Boulder Dash на ПК-01 Львов
Re: Портировать Boulder Dash на ПК-01 Львов
О! Zelya! И другие учасники форума тоже!
По ходу вопрос возможно дивный или странный о задержке, точнее говоря о её точности!
Вот только не подумайте, что я тролю (такое уже бывало в одной из тем).
Итак,
например, МНЕ НУЖНА ЗАДЕРЖКА КАК МОЖНО ТОЧНЕЕ И СТАБИЛЬНЕЕ относительно времени конечно!
Я беру и реализовываю её несколькими командами (потоком нескольких команд), по сути не важно какими именно.
Ну например
1.Nop = 4 такта
или
2. XTHL = 18 тактов
поток команд №1: - 18 команд подряд Nop , длительность всего = 72 такта
или
поток команд №2: - 4 команды подряд XTHL , длительность всего = 72 такта
Поскольку частота процессора (любого) нестабильна как я понял, то и КР580, частота не строго 2500000 Гц. а может колебаться, скажем процентов так на 10. (ИЛИ НА СКОЛЬКО ?)
А тепер вопрос. Можна ли сказать, что какой-то поток команд "1" или "2" более надёжен, стабилен, точен по времени, например, из за большего (меньшего) кол-ва команд в потоке или же из за большего(меньшего) так-тов в каждой команде потока ?
У меня почему-то предчувствие, что чем дольше тактов выполняется команда, тем надежнее, стабильнее и точнее время её выполнения! Другими словами, поток команд "2" надежнее, стабильнее и точнее чем поток команд "1".
Ну и "плюс" к точности "2", то, что команд поменьше в потоке!
Насколько логично и справедливо это все сказано ?
По ходу вопрос возможно дивный или странный о задержке, точнее говоря о её точности!
Вот только не подумайте, что я тролю (такое уже бывало в одной из тем).
Итак,
например, МНЕ НУЖНА ЗАДЕРЖКА КАК МОЖНО ТОЧНЕЕ И СТАБИЛЬНЕЕ относительно времени конечно!
Я беру и реализовываю её несколькими командами (потоком нескольких команд), по сути не важно какими именно.
Ну например
1.Nop = 4 такта
или
2. XTHL = 18 тактов
поток команд №1: - 18 команд подряд Nop , длительность всего = 72 такта
или
поток команд №2: - 4 команды подряд XTHL , длительность всего = 72 такта
Поскольку частота процессора (любого) нестабильна как я понял, то и КР580, частота не строго 2500000 Гц. а может колебаться, скажем процентов так на 10. (ИЛИ НА СКОЛЬКО ?)
А тепер вопрос. Можна ли сказать, что какой-то поток команд "1" или "2" более надёжен, стабилен, точен по времени, например, из за большего (меньшего) кол-ва команд в потоке или же из за большего(меньшего) так-тов в каждой команде потока ?
У меня почему-то предчувствие, что чем дольше тактов выполняется команда, тем надежнее, стабильнее и точнее время её выполнения! Другими словами, поток команд "2" надежнее, стабильнее и точнее чем поток команд "1".
Ну и "плюс" к точности "2", то, что команд поменьше в потоке!
Насколько логично и справедливо это все сказано ?
Re: Портировать Boulder Dash на ПК-01 Львов
Не было никакой мысли гнать на МАДЛ. Я гоню вообще на ассемблер, на котором предпочитаю программировать чем меньше - тем лучше.als wrote: 07 Jun 2021, 22:39А ты на мой МАДЛ гонишь!Я ж его не для написания бухгалтерских програм делаю!
А для писания динамических игр для ПК-01!
Итак, как и обещал, выкладываю исходник Bolder16K:
Игра будет. Работы не так много. Из трудностей: надо перерисовать все тайлы под 12x12. Читая на здешнем форуме тему про RiverRaid, я наткнулся на отличную реализацию вертикального скролла через стек. Это весьма пригодится для Болдера.
Пока затык только в свободном времени. Вернее, его малости. Всем спасибо за помощь. Ждите новостей по игре.
Это вообще будет моя иллюстрация разработки на Обероне, не более того. Как игра оно может и не столь хорошо.
als, спасибо за тёплые слова про Болдер)
Re: Портировать Boulder Dash на ПК-01 Львов
Ну я думаю, что ты не глупый человек, чтобы не понять какие возможности даёт МАДЛ (с помощью среды FPC), тому, кого МАДЛ заинтересует! И как можно "обвешать" его макросами (в виде возможностей FPC (процедур FPC)), для того чтобы АСМ в нём был конечно, но просто "утонул"! Причём, можна "обвешать" как самостоятельно до того момента пока самому нужно и хочеться, так и можна дождаться пока я это сделаю, но при этом МАДЛ всё равно можна уже использовать на "всю катушку"!Zorko wrote: 09 Jun 2021, 02:00 Я гоню вообще на ассемблер, на котором предпочитаю программировать чем меньше - тем лучше.
Коротко об этом изложено вот здесь:
Учимся писать на MADL2021
viewtopic.php?f=8&t=397&p=5453#p5440
И ты думаешь мне искренне не хочеться, что XDev была такой диковинкой как МАДЛ, а ?
Та я бы и про МАДЛ забыл и забросил бы его! Но у автора XDev, что-то там свои какие-то "чертики".
А теперь я тебе открою очень большой секрет
Но опять же, - зачем оно тебе ?! Я ж не заказчик и ты не под меня его делаешь, да и не зачем тебе его под меня одного делать, это верно!
Поэтому, почитал выше написанное мною и забудь!
Это хорошо! Спасибо! Приходится обязательно! Вот только пока не знаю когда и как!
Ну видишь, вот беда то, ты не делал обзор форума! Может тут много чего полезного можна найти! Я не в обиду! У меня тоже самое! Пример тому тема про "TASM" на которую я обратил внимание лишь только сейчас и создал "LVTtoTASM". А той теме лет 10 как!Zorko wrote: 09 Jun 2021, 02:00 Игра будет. Работы не так много. Из трудностей: надо перерисовать все тайлы под 12x12. Читая на здешнем форуме тему про RiverRaid, я наткнулся на отличную реализацию вертикального скролла через стек. Это весьма пригодится для Болдера.
Я то вроде и пробегался когда-то, но видимо, тогда не заострил особого внимания. Видимо надо время от времени обзор форума делать, может на что-то уже посмотрю другими глазами. И т.д. (ну это я так... больше себе "говорю" чем тебе! Тебе ж ПК-01, это как всего лишь часть из ретро-машин, а мне как основное!)
Та ради Бога!Zorko wrote: 09 Jun 2021, 02:00 Пока затык только в свободном времени. Вернее, его малости. Всем спасибо за помощь. Ждите новостей по игре.
Как видишь, вот
Оберон. Установка на Windows XP,"7" (32bit) среды разработки "XDev".
viewtopic.php?f=20&t=395
что мог то и сделал! Кому-то когда-то это дай Бог пригодится! Тебе помогаю как могу, МАДЛ в сторону подвинул, подождёт, еще всегда успею, особенно если есть чего поинтереснее, - помочь реально, чтобы игрушка была готовая на ПК-01, а на МАДЛе еще писать нужно, предварительно МАДЛ доведя то того, чтобы максимально по кайфу было на нём писать!
Да и лето на дворе! Комп надо побольше в сторону! Этим можна и зимой заниматься!
Та ладно не скромничай! Все СУПЕР!Zorko wrote: 09 Jun 2021, 02:00 Это вообще будет моя иллюстрация разработки на Обероне, не более того. Как игра оно может и не столь хорошо.
Ну вообще-то будлер даш мне понравился с "времен проката Атари", т.е. с конца "восьмедесятых", когда Атари ставили на каждом углу, так сказать на прокат! Сколько я на него денег потратил то...
И больше, чем на Атари, мне он нигде не нравился, - так ото, за неимением лучшего!
Клоны "Рокфорд" и "Супаплекс" мне тоже не очень-то, хотя и игрался в них.
Что касаемо Булдера на ретро-машинах, - хорошая у тебе задумка, чтобы уровень был весь на экране! Но на спеке я играться не буду, - управление мне явно не нравиться! Надеюсь, что на ПК-01 управление будет "стрелочками" и уровни как на спеке!
Да и насчет уровней.
Ну это уже когда выпустишь, то может я и сам, что-то для этого сделаю (если разберусь конечно как)- чтобы можна было редактировать уровни и данные уровней "компилить" в "Bolder16K.lvt" - и вот и готовый новый "булдер даш" с новыми уровнями! Автору булдера, лишь нужно делать базу уровней так, чтобы такое можна было делать без проблем и заморочек! ну и я как желающий в этом разобраться смог разобраться как туда "загонять" новые уровни!
Re: Портировать Boulder Dash на ПК-01 Львов
Тут я не силен. Лучше почитать/спросить тут:als wrote: 08 Jun 2021, 22:08 МНЕ НУЖНА ЗАДЕРЖКА КАК МОЖНО ТОЧНЕЕ И СТАБИЛЬНЕЕ относительно времени конечно!
https://zx-pk.ru/threads/33071-povyshae ... pk-01.html
Но, как мне кажется, если инструкция не обращается к памяти, то ей более-менее можно доверять по таймингам. Хотя NOP - еще лучше, он даже с регистрами не играется (хотя, скорее всего регистры не влияют).
Re: Портировать Boulder Dash на ПК-01 Львов
А ведь верно сказано! Наверняка есть разница пусть не ощутимая при обращение к адресу памяти $0000 и $FFFF. по идее чем выше адрес тем дольше обращение к нему!Zelya wrote: 09 Jun 2021, 14:54 Но, как мне кажется, если инструкция не обращается к памяти, то ей более-менее можно доверять по таймингам. Хотя NOP - еще лучше, он даже с регистрами не играется (хотя, скорее всего регистры не влияют).
А ноп действительно даже с регистрами не играется!
https://zx-pk.ru/threads/33071-povyshae ... pk-01.html - почитаю, что там такое.
Был бы конечно "железный" ПК-01 можна бы было испытания делать, запустив "пачку" "одноимеённых" команд на целые часы работы или на несколько суток даже и не один раз! Думаю что-то бы да показало! а на емулях никакого смысла нету ж!
Re: Портировать Boulder Dash на ПК-01 Львов
Zorko, запустил, чисто побаловаться на пару минут EmuZWin_2.7.
И игру Bolder16K для спека. И вот смотри до чего я "добаловался" Возможно то конечно глюк эмулятора,
а может и игрушки все таки!
В архиве файл Bolder16K.ezx, сохранил из эмуля "Save as..." когда такое показало!
Уж не знаю поможет ли чем тебе такое, что я делал т.е. в каком моменте это возникло, особо не помню, ну игрой управлял в общем-то!
И игру Bolder16K для спека. И вот смотри до чего я "добаловался" Возможно то конечно глюк эмулятора,
а может и игрушки все таки!
В архиве файл Bolder16K.ezx, сохранил из эмуля "Save as..." когда такое показало!
Уж не знаю поможет ли чем тебе такое, что я делал т.е. в каком моменте это возникло, особо не помню, ну игрой управлял в общем-то!
Re: Портировать Boulder Dash на ПК-01 Львов
als, благодарю за инфу. Это действительно была ошибка в игре. Я её исправил.
Суть ошибки: когда жизней становилось 0, внутренний счётчик жизней становился 255, и количество человечков, символизирующих жизни, тоже становилось 255. И вот такое количество человечков и выводилось, притом в цикле, который никогда не заканчивался.
Есть одна древняя и не решённая проблема в языке Оберон, которую мы с Олегом Комлевым постарались исправить. Но из-за того, что я не докрутил в своё время код Олега под беззнаковый байтовый тип, и случился недосмотр этой ошибки. Ничего смертельного, просто неприятно. И остались хвосты, есть что дорабатывать в трансляторе.
Zelya, ну, мы решили переписать игру под тайлы 12x12, что будет более нативно, тепло и лампово смотреться на "Львове", разве нет?)
als, иногда свой инструмент (МАДЛ) получше чужого (XDev), поскольку его не надо изучать. Так что занимайся, я тебе не конкурент) K580Dev очень плотно завязан на z88dk и вынужден учитывать массу его особенностей. Ну и конечно - писать на языке высокого уровня под "Львов" - это весьма сомнительная идея. С чем я спорить даже не собираюсь.
Суть ошибки: когда жизней становилось 0, внутренний счётчик жизней становился 255, и количество человечков, символизирующих жизни, тоже становилось 255. И вот такое количество человечков и выводилось, притом в цикле, который никогда не заканчивался.
Есть одна древняя и не решённая проблема в языке Оберон, которую мы с Олегом Комлевым постарались исправить. Но из-за того, что я не докрутил в своё время код Олега под беззнаковый байтовый тип, и случился недосмотр этой ошибки. Ничего смертельного, просто неприятно. И остались хвосты, есть что дорабатывать в трансляторе.
Zelya, ну, мы решили переписать игру под тайлы 12x12, что будет более нативно, тепло и лампово смотреться на "Львове", разве нет?)
als, иногда свой инструмент (МАДЛ) получше чужого (XDev), поскольку его не надо изучать. Так что занимайся, я тебе не конкурент) K580Dev очень плотно завязан на z88dk и вынужден учитывать массу его особенностей. Ну и конечно - писать на языке высокого уровня под "Львов" - это весьма сомнительная идея. С чем я спорить даже не собираюсь.
Re: Портировать Boulder Dash на ПК-01 Львов
Все равно не понимаю. А почему 12х12 более нативно? А не 16х16 или 32х32? Тем более, что приходится запарываться с конвертацией.Zelya, ну, мы решили переписать игру под тайлы 12x12, что будет более нативно, тепло и лампово смотреться на "Львове", разве нет?)
Ну почему же. Не особо динамичные игры вполне себе можно писать на чем угодно. Например, текстовые квесты, карточные игры, настолки разные.Ну и конечно - писать на языке высокого уровня под "Львов" - это весьма сомнительная идея.
Не уверен, что адрес будет иметь значение. Но сам факт обращения к памяти может "тормозить" процессор на моменте вычитки данных. А какие там тайминги, я понятия не имею.Наверняка есть разница пусть не ощутимая при обращение к адресу памяти $0000 и $FFFF.
Re: Портировать Boulder Dash на ПК-01 Львов
Я думаю, перенесу эту тему и соседние в "Разработку". Это все освсем не оффтопик.
Re: Портировать Boulder Dash на ПК-01 Львов
Во-первых, эта инкарнация игры задумана с одноэкранными лабиринтами 16x16 тайлов без прокрутки, и чтобы весь уровень сразу помещался на экране. Из этих соображений даже вертикальная прокрутка, которая сама собой напрашивалась для Спека, чтобы сделать игру цветной - отпадает.Zelya wrote: 10 Jun 2021, 10:54Все равно не понимаю. А почему 12х12 более нативно? А не 16х16 или 32х32? Тем более, что приходится запарываться с конвертацией.
Во-вторых, мы уже рассмотрели с als варианты тайлов размера 8x8 (слишком мелко) и 16x16 (поместится на экран железного "Львова" только с артефактами отображения, возможно, с отсечением части графики за пределы экрана телевизора.
Промежуточный вариант напрашивается сам собой: 12x12. Тут, правда, всё равно пришлось заморочиться на вывод в полупозиции (т.е. не кратной байту), но я прикинул, что такого вывода в процессе игры будет сильно меньше, чем обычного (кратного байту), так что должно быть не очень заметно.
Если ты рассмотришь мой вывод тайла, то там фактически две подпрограммы - одна выводит тайл шириной 3 байта, вторая шириной 4 байта (с наложением двух пикселей слева и двух справа от изображения, существующего на экране).
Ну да. Львову ещё повезло с 32 Кб ОЗУ. Но скорости всегда будет не хватать. Для некоторых людей (и игр) это неприемлемо. А памяти тоже всегда будет не хватать, тем более, в случае работы на Обероне можно на это всегда списать)Zelya wrote: 10 Jun 2021, 10:54Ну почему же. Не особо динамичные игры вполне себе можно писать на чем угодно. Например, текстовые квесты, карточные игры, настолки разные.
Re: Портировать Boulder Dash на ПК-01 Львов
А почему 32 а не 48 ?Zorko wrote: 10 Jun 2021, 14:46 Ну да. Львову ещё повезло с 32 Кб ОЗУ. Но скорости всегда будет не хватать.
Zelya, я создаю темы в "офтопик" чтобы не парится где её создаватьZelya wrote: 10 Jun 2021, 11:03 Я думаю, перенесу эту тему и соседние в "Разработку". Это все освсем не оффтопик.
Пересмотри "офтопик" может еще какие-то куда-то перенесёшь, ты все таки админ и тебе виднее какою тему куда перенести!
Re: Портировать Boulder Dash на ПК-01 Львов
Я Вас умоляю! Рик на реале:Zorko wrote: 10 Jun 2021, 14:46 поместится на экран железного "Львова" только с артефактами отображения, возможно, с отсечением части графики за пределы экрана телевизора.
https://www.youtube.com/watch?v=f2QIgRm ... C&index=18
Обрезано, дай бог, 8 пикселей слева и немного сдвинут верх (частая проблема). Думаю, на большинстве реалов проблемы не больше. Вот, уже существующий Boulder Dash:
http://pc01.lviv.ua/games/page.php?name=boulderdash
Никто не заморачивается отсечениями на ПК-01. Это имеет смысл разве что для "Сапера" какого-нибудь с клетками 8х8.
Бросайте конвертацию и хитрые процедуры для смещений. Используйте 16х16.
Почему 32? 48 же.
ПС Александр меня уже опередил, с 48
Re: Портировать Boulder Dash на ПК-01 Львов
Zelya, спасибо! Учту. Я было подумал, что совсем плохо с рамками вокруг основного изображения на "Львове". Но если всё это терпимо, то это даже к лучшему, графика крупнее будет.
Какой набор цветов нравится больше? (я пока рассматриваю только два):


(второй немного удобнее, потому что 0 - чёрный цвет. Но это не обязательно, просто надо свою процедуру очистки экрана сделать, вернее, заливки нужным цветом).
Какой набор цветов нравится больше? (я пока рассматриваю только два):
(второй немного удобнее, потому что 0 - чёрный цвет. Но это не обязательно, просто надо свою процедуру очистки экрана сделать, вернее, заливки нужным цветом).
Re: Портировать Boulder Dash на ПК-01 Львов
Прикрути вот такую штуковину и будет полный "фарш"!
И не надо будет парится с цветовой гаммой.
вот только по умному прикрути! Как в "САС-Лабиринт", чтобы абсолютно в любом моменте можно было нажатием цветовою гамму поменять! ВЕЗДЕ чтобы работало нажатие на "2".
И паузу реализовать не забудь! И при паузе должна работать изменение цветовой гаммы и в меню, да где угодно! Короче, глянь "САС-Лабиринт" там все это работает как надо!
И не надо будет парится с цветовой гаммой.
вот только по умному прикрути! Как в "САС-Лабиринт", чтобы абсолютно в любом моменте можно было нажатием цветовою гамму поменять! ВЕЗДЕ чтобы работало нажатие на "2".
И паузу реализовать не забудь! И при паузе должна работать изменение цветовой гаммы и в меню, да где угодно! Короче, глянь "САС-Лабиринт" там все это работает как надо!
Code: Select all
{изменеия цвета экрана нажатием на "2"
из игры "Лабиринт"}
program Project; uses uMD01u in 'uMD01u.pas';
VAR
EE_Cycle,Proc_Color_RET,Byte_Color,Proc_Color_cycle1,Proc_Color
:TLabelLV;
BEGIN
INITCompiler;
SetFullNameLVTfile('_res.LVT');
SetNameInternalKOI(#$20+#$20+#$20+#$20+#$20+#$20);
{Процедура Опроса нажатия кл "2"}
{Byte_Color - переменная установленного цвета}
LabelA(Proc_Color);
{ изменения цвета нажатием на '2'}
MviA($EF);Out_($D0);// посылаем на порт $D0, '11101111'{$EF}
In_($D1); // опрашиваем порт $D1
Cpi($BF); //'10111111'){BF}); // сравниваем нажата ли "2"
Jnz(Proc_Color_RET);// если не нажата выход
{если же нажата .....}
{Byte_Color = Byte_Color+4}
Lda(Byte_Color); MovBA; MviA($04); AddB; Sta(Byte_Color);
Out_($C1); // { отправиляем Byte_Color на порт $C1 }
{Ожидаем отжатия "2"}
LabelA(Proc_Color_cycle1);
MviA($EF);Out_($D0); // посылаем на порт $D0, '11101111'{$EF}
In_($D1); // опрашиваем порт $D1
Cpi($BF); //'10111111'){BF}); // сравниваем нажата ли "2"
Jz(Proc_Color_cycle1); // если не ОТЖАТА, - переход LabelA(Proc_Color_cycle1);
LabelA(Proc_Color_RET); RET;
LabelA(Byte_Color);DB($00); // переменная цвета
// конец процедуры
StartProgram; LabelA(EE_Cycle); Call(Proc_Color); Goto_(EE_Cycle);
FINALCompiler;
END.
Who is online
Users browsing this forum: No registered users and 1 guest

