Просмотр полной версии : ASTEROIDS на УКНЦ
Давайте сделаем фоорк ASTEROIDS на УКНЦ.
- - - Добавлено - - -
Что уже есть - Бризинхем рукописный и из ПЗУ, будем пробовать.
Синусы табличные и фиксированная точка s15.16
На Си написал.
Вопросов много (к специалистам), например куда воткнуть константу учитывающую разрешение экрана.. в матрицу.
На реале пока кособоко (как обойтись без лишних умножений)... нужен специалист.. (можно же сразу еденичеую матрицу кривую сделать)
Сорри.. в арифметике не силен.. я ж механик.
Исходники Asteroids в виде аркадного автомата - то есть самого что ни на есть оригинала: https://www.computerarcheology.com/Arcade/Asteroids/
В википедии - https://en.wikipedia.org/wiki/Asteroids_(video_game)
Я уже копнул глубже, астероиды нарисовал как в первоисточнике.. читал, где он на бумажке варианты рисовал.. все есть. (времени нет)
- - - Добавлено - - -
На Си++ все просто, теперь перекладываю на АСМ ПДП.
- - - Добавлено - - -
Со стиранием проблемы есть..
Здесь получается что все объекты движутся в каждом кадре, все нужно перерисовать с нуля.
Я думаю что я бы сделал "теневой экран" в виде как на БК - плоский ч/б фреймбуфер - на нём рисовать все линии, и выводить его целиком в каждый кадр - может быть эту задачу можно на ПП положить.
Горизонтальное разрешение УКНЦ взять в 320 точек, из них использовать под векторный экран например 256x288 или ещё меньше, а на оставшемся месте рисовать очки, номер уровня итп.
Больше всего от процессора будет есть видимо как раз рисование линий, плюс ещё расчёт столкновений, остальная логика уже меньше.
320.. не красиво точки крупные.
Я сначала думал тоже ограничить 256.. арифметики меньше.
В оригинале же метеоры проходят друг-друга..
Пули только считать нужно.
- - - Добавлено - - -
Здесь получается что все объекты движутся в каждом кадре, все нужно перерисовать с нуля.
Не все.. у всех скорости разные и если использовать фиксированную точку.. то отрисовка будет не каждый кадр.
- - - Добавлено - - -
плюс можно рисовать чет-нечет
- - - Добавлено - - -
выводить его целиком в каждый кадр -
Все мои эксперименты... провалились.. с перерисовкой. (долго).
Живые примеры есть?
Переключение экранов тоже отстой..
Я уже близок к победе.. (список отображения по 100му вектору)
- - - Добавлено - - -
Я про стирание говорил.. что точки иногда остаются.. когда BICом повторно, сейчас точность должна выше быть. (сегодня только сделал)
- - - Добавлено - - -
Придется на все по два слова тратить... в итоге думаю даже красивее будет.. (отсюда выплыла мысль использовать фиксированную точку для вектора скорости всегда).
А нельзя ли полупериоды синуса заменить на дугу части окружности или эллипса, для них вроде даже в ПЗУ БК11М есть целочисленные методы вычисления координат...
А нельзя ли полупериоды синуса заменить на дугу части окружности или эллипса
Все уже решено.. таблица четверть периода.
Целочисленные методы не катят.. :)
- - - Добавлено - - -
Решено тратить два слова на целую и дробную часть.. быстро
сначала складывай дробную часть при переполнении инкремент целой
- - - Добавлено - - -
Какой год на дворе?? Я в муках рожаю трехколесный велосипед... боком идет... И никто из вас не знает как облегчить роды??? Какие бля.. эллипсы и параболы..
Есть ещё таблицы Брадиса :)
Утверждаю это как инженер-электрик))
Точность таблиц - 4 знака после запятой.
Есть ещё таблицы Брадиса
Кусок таблицы Брадиса я уже сгенрил.. cos тот же синус со сдвигом в полпериода.
Кусок таблицы Брадиса я уже сгенрил.. cos тот же синус со сдвигом в полпериода.
Думаю, это верный путь :)
Есть ещё таблицы Брадиса
Какие ещё таблица, ты про что??
Я ему предложил просчитать - какие будут углы при целочисленной арифметике (учитывая симметрию), взять для них (с нужной точностью) синусы-косинусы, для получившихся значений посчитать пары целых чисел, которые дадут эти значения (типа - умножаем на первое, делим на второе), но похоже, человек даже не понял, про что я.
Он так и будет синусы косинусы считать функциями. Если, конечно, найдёт реализацию числовыми методами для PDP.
16 бит после запятой это какая точность? Наверно нужно еще на два поделить.
Там вообще можно всё целочисленно всё сделать, нет, нам нужен decimal вариант
Там вообще можно всё целочисленно всё сделать
Да нифига... инкремент.. Theta никуда не денется...кто его будет считать???
16 бит после запятой это какая точность? Наверно нужно еще на два поделить.
Старший бит - это 1/2, следующий имеет вес 1/4, следующий - 1/8, и так далее...
Hunta, верно намекал, что 640 = 256 + 256 + 128 :)
Затем можно определиться с максимальной амплитудой синусоидальной кривой и сделать таблицу четверти периода синуса умноженного на максимальную амплитуду.
А уж уменьшить амплитуду для конкретного случая в алгоритме всегда можно DIV-но и сложениями-вычитаниями в целых числах. Я так думаю :)
Или будет скакать... иначе зачем я всю тему насчет арифметики затеял?????
- - - Добавлено - - -
Затем можно определиться с максимальной амплитудой синусоидальной кривой и сделать таблицу полупериода синуса умноженного
Вопрос закрыт... два слова.
Через двадцать лет Manwe скажет как из двух слов сделать полтора...но это будет уже не интересно.
Или будет скакать... иначе зачем я всю тему насчет арифметики затеял?????
- - - Добавлено - - -
Вопрос закрыт... два слова.
Через двадцать лет Manwe скажет как из двух слов сделать полтора...но это будет уже не интересно.
Уверена, что из двух слов он сделает один байт :) просто разложив ваше уравнение из курса теоретической механики на слагаемые, исходя из принципа, что 640 = 256 + 256 + 128 :)
И максимальная амплитуда в таблице четверть периода не будет превышать значения = 255...
Но это если нужно будет ещё и ОЗУ экономить, а для максимального быстродействия можно и целое слово под выборку забрать, а амплитуду максимальную сделать = 511.
Умножить на 1.25 амплитуду можно достаточно быстро на asm-е :)
из курса теоретической механики
Термех у нас был пять семестров.... и не было там никаких разложений.. только свод нагрузок.. постоянных и моментов.
- - - Добавлено - - -
И максимальная амплитуда в таблице четверть периода не будет превышать значения = 255...
И будет прыгать.. если уж просрали слово..давайте его использовать
Термех у нас был пять семестров.... и не было там никаких разложений.. только свод нагрузок.. постоянных и моментов.
Странно, у нас вроде бы пару семестров (или четыре, уже не помню), но траектории движения выбранной точки в системе связанных рычагов преподавали :)
А нагрузки и прочие твердые заделки с фермами, в рамках сопромата рассчитывали...
LeoN65816
11.10.2020, 00:15
взять для них (с нужной точностью) синусы-косинусы, для получившихся значений посчитать пары целых чисел, которые дадут эти значения (типа - умножаем на первое, делим на второе), но похоже, человек даже не понял, про что я.
Более того, делителем можно выбрать 65536, тогда делить вообще не надо, а просто отбрасывается младшее слово произведения.
исходя из принципа, что 640 = 256 + 256 + 128 :)
Никак не вкурю, а что это даст (для экранной координаты) ?..
Умножить на 1.25 амплитуду можно достаточно быстро на asm-е :)
Элементарно, 4 инструкции.
Более того, делителем можно выбрать 65536
Зависит от нужной точности
LeoN65816
11.10.2020, 00:52
Зависит от нужной точности
Мда-а-а... Рукалицо...
Мда-а-а... Рукалицо
Не мои проблемы
Более того, делителем можно выбрать 65536, тогда делить вообще не надо, а просто отбрасывается младшее слово произведения.
Никак не вкурю, а что это даст (для экранной координаты) ?..
Предположим, что спрайт движется по оси X по следующему закону:
X = Xo() + A*sin(z), где Amax = 639.
Тогда нам достаточно иметь табличную функцию синуса в виде её четверти периода с амплитудой 255 (условно sin255) , и представить закон так:
X = Xo + sin255(z) + sin255(z) + sin255(z)/2.
Как-то так, думаю :)
А если спрайт синусит вдоль X, где Amax = 255, то:
Y = Yo + sin255(z), к примеру.
Если скачет как мячик о низ экрана, примерно, так:
Y = 255 - |sin255(X)|...
Тогда нам достаточно иметь табличную функцию синуса в виде её четверти периода с амплитудой 255 (условно sin255)
Сделал четверть периода с амплитудой 65536. Арифметика будет двухсловная.
А зачем вам синусы? Сделайте фиксированное число углов поворота, нарисуйте заранее повёрнутые спрайты. А для стрельбы хватит арктангенса: как здесь (https://forthsalon.appspot.com/haiku-view/ahBzfmZvcnRoc2Fsb24taHJkchILEgVIYWlrdRiAgIDAzJqXCQ w)
нарисуйте заранее повёрнутые спрайты
Векторы не спрайты будут
Векторы не спрайты будутНо зачем, если разрешение фиксированное?
Но зачем, если разрешение фиксированное?
Это ты о чем?
Все будет как в канонической версии (даже форма астероидов).
250 байт на описание 10 видов объектов + масштабирование + повороты с разрешением в один градус..
А со спрайтами как? Будет 365 спрайтов кораблика (или в четверть но с извратами)? :)
Мне такие больше по душе:
https://pic.maxiol.com/thumbs2/1602602950.630630946.ast.png (https://pic.maxiol.com/?v=1602602950.630630946.ast.png&dp=2)
https://pic.maxiol.com/thumbs2/1602603025.630630946.ast2.png (https://pic.maxiol.com/?v=1602603025.630630946.ast2.png&dp=2)
https://pic.maxiol.com/thumbs2/1602603046.630630946.ast3.png (https://pic.maxiol.com/?v=1602603046.630630946.ast3.png&dp=2)
Как-то так :)
- - - Добавлено - - -
Все будет зависеть от скорости арифметики.
С векторами можно гораздо больше эффектов взаимодействия придумать.
Сами же астероиды не масштабируются. И кораблик тоже.
Для кораблика достаточно 32 спрайта плюс зеркальные.
Сами же астероиды не масштабируются.
Почему? Когда его раскалываешь.
1. З2 спрайта или 5 слов.
2. Даже стрельба будет интересней с векторами чем в фиксированных направлениях.
3. Мне интересна сама механика.
4. "Законы движения и взаимодействия" можно придумать более разнообразные и гибкие в описании. (например воткнуть в центре экрана сингулярность).
Со спрайтами придется все упрощать и выглядеть будет более коряво.
S_V_B, а сколько у тебя Экранных плоскостей?
не слушай никого делай векторами.
Ну, как хотите. Моё предположение: будет либо тормозить, либо мерцать.
Хотя бы стирание объектов сделайте «спрайтами» – чёрными квадратами. Чтобы не очищать весь экранный буфер.
Хотя бы стирание объектов сделайте «спрайтами» – чёрными квадратами. Чтобы не очищать весь экранный буфер.
Зачем стирать весь экранный буфер?
Моё предположение: будет либо тормозить, либо мерцать.
Рисовать по 100му вектору и не будет мерцать.
Вариантов оптимизации миллион (пройденный этап).
- - - Добавлено - - -
Например если не влезаешь во фрейм 100го прерывания, можно выводить объекты "чет-нечет".
Дальше оптимизировать все от арифметики до рисования-стирания линий (отсюда выплывет максимальное количество одновременно выводимых объектов).
S_V_B,
Рисовать по 100му вектору и не будет мерцать.
так и до Elite для КЦГД или УК-НЦ можно докатиться с векторами то )))
Зачем стирать весь экранный буфер?Так я и говорю: не весь, а только bounding box вокруг каждого объекта. Это быстрей, чем чёрным цветом вектора рисовать.
Это быстрей, чем чёрным цветом вектора рисовать.
Зато не сотрет лишнего. (я постараюсь разнести вывод объектов, чтобы можно было больше отобразить, т.е. не выводить все объекты сразу, а только те у которых произошло приращение. Соответственно квадратом можно затереть неподвижные).
Хотя, война план покажет.
Задумался над динамическим выделением памяти, кто сталкивался посоветуйте как лучше сделать.
Проблема в том, что все объекты разного размера. Или лучше разбить на участки по объекту максимального размера? И допустим сделать два списка - текущий (при удалении объекта на его ссылку в списке ставить последний и уменьшать количество и список МЭП свободных-занятых.?)
Наверное это самый быстрый способ.
- - - Добавлено - - -
Hunta, ты же все про все знаешь? Как быть? Как в одной странице организовать new/delete? Насколько я понял в ПП УКНЦ также есть список занятых участков памяти..(с заголовками).
Нужно - просто/быстро :) (Без SysLib :))
Задумался над динамическим выделением памяти, кто сталкивался посоветуйте как лучше сделать.
Проблема в том, что все объекты разного размера. Или лучше разбить на участки по объекту максимального размера? И допустим сделать два списка - текущий (при удалении объекта на его ссылку в списке ставить последний и уменьшать количество и список МЭП свободных-занятых.?)
Наверное это самый быстрый способ.
зачем тебе динамическая память?
у тебя есть максимальное количество обьектов, их и обрабатывай.
зачем тебе динамическая память?
у тебя есть максимальное количество обьектов, их и обрабатывай.
Согласен с предыдущим оратором.
И стоит ещё померить, сколько объектов УКНЦ максимум вытянет.
зачем тебе динамическая память?
у тебя есть максимальное количество обьектов, их и обрабатывай.
Если отбросить выделение памяти то так и будет. Только есть одно НО - максимальное кол-во это количество одновременно выводимых на экран, но количество объектов непостоянно и мы их добавляем и убираем непоследовательно, соответственно нужно отслеживать занятые и освободившиеся участки памяти. Вот я и думаю как лучше сделать - отдельным массивом или в каждом элементе сделать признак занятости. Или еще как.
Тут дело даже не в том "почему и как", а в том как это сделать быстро и красиво.. без лишних "движняков" :)
- - - Добавлено - - -
Да и объектов будет чуть больше но не суть.. (например мы разбили большой астероид, а из него получилось два маленьких.. с вектором +-45)..
- - - Добавлено - - -
ТО что например было в LM(LastMission) .. я заранее знал, что в комнате будет восемь врагов.. и при их уничтожении .. их становится только меньше..т.е. ты их не отображаешь..
Как вариант - партиклсистемс.. ну например мы захотим хвост за кораблем сделать..
- - - Добавлено - - -
P.S.
Последние десять лет я занимаюсь сиквелом, от которого меня тошнит :)
Не имея опыта разработки игрушек на асме тем более PDP-11 я надеюсь найти понимание от ГУРУ. (и надеюсь, что мои "мысли в слух".. помогут такому же.. страждущему).
Может я не умею искать в ГУГЛЕ но я не нашел ничего мало-мальски интересного.
По сему считаю ВАЖНЫМ то, что пытаюсь сделать (с вероятностью 10% кто-то тоже ищет эту информацию :)).
Может быть так...
Пока объект состоит из одного элемента, то его ID описывается в 16-ти битном слове: b11111111'00000000, где 00000000 - байт описывающий количество частей, на которые разделился объект после столкновения с другим.
Тогда остаётся только определиться с макс. Количеством осколков объекта, продумать таблицу свойств объекта и его осколков, которая будет храниться в ОЗУ, пока объект отображается на экране, но может быть выгружена, или удалена, для освобождения памяти под другие объекты, когда объект уже не нужен, или вскоре не понадобиться для отображения на экране.
- - - Добавлено - - -
Таким образом, у каждого осколка уже заранее определён свой ID...
Старший байт - это основной ID, в котором можно шифровать по маске и тип объекта, и его номер.
Ну, и основному ID можно выделить 12 старших бит, а осколкам - 4 бита, в ID :)
- - - Добавлено - - -
Прочитав ID как слово, сразу становится известно о типе объекта, есть ли у него осколки (или спутники), и как глубоко шерстить таблицу осколков, исходя из их количества...
Тогда остаётся только определиться с макс. Количеством осколков объекта, продумать таблицу свойств объекта и его осколков, которая будет храниться в ОЗУ, пока объект отображается на экране, но может быть выгружена, или удалена, для освобождения памяти под другие объекты, когда объект уже не нужен, или вскоре не понадобиться для отображения на экране.
Чет.. ты замутила.. :).... основной принцип программирования - "делай это проще".. тут нам уже пентиум нужен :)
Согласен, для осколков выделим отдельный кусок памяти.. партиклы будут закользованы отдельно - объекты отдельно. "мухи и котлеты" :)
- - - Добавлено - - -
для осколков
Не путать с объектом -астероид.
Партиклы- частицы, для красоты.
- - - Добавлено - - -
Но если ты подстрелил большой астероид - получишь два маленьких (объекта).
Если отбросить выделение памяти то так и будет. Только есть одно НО - максимальное кол-во это количество одновременно выводимых на экран, но количество объектов непостоянно и мы их добавляем и убираем непоследовательно, соответственно нужно отслеживать занятые и освободившиеся участки памяти. Вот я и думаю как лучше сделать - отдельным массивом или в каждом элементе сделать признак занятости. Или еще как.
А зачем у тебя разная размерность описателей для обьектов?
это же непрактично
Чет.. ты замутила.. :).... основной принцип программирования - "делай это проще".. тут нам уже пентиум нужен :)
Согласен, для осколков выделим отдельный кусок памяти.. партиклы будут закользованы отдельно - объекты отдельно. "мухи и котлеты" :)
- - - Добавлено - - -
Не путать с объектом -астероид.
Партиклы- частицы, для красоты.
- - - Добавлено - - -
Но если ты подстрелил большой астероид - получишь два маленьких (объекта).
Если подстрелил астероид, то он исчезает, т.к. количество осколков не равно 1, и не равно 0, но равно 2 :) Но появляются осколки - 2 шт.
Если бы кол-во осколков стало 1, то появился бы, например, астероид с трещиной (который при следующем попадании в него непременно расколется)...
Чтобы шерстить таблицу не надо Пентиума, нужно её тщательно продумать, с учётом возможности использовать модифицирующийся код и косвенно - индексную адресацию, например.
А зачем у тебя разная размерность описателей для обьектов?
это же непрактично
Не совсем так.
Или лучше разбить на участки по объекту максимального размера?
Но не стоит сюда впихивать партиклы - они гораздо проще.
- - - Добавлено - - -
Тогда остаётся только определиться с макс. Количеством осколков объекта, продумать таблицу свойств объекта
Я думаю, что проще большой астероид (как в оригинале) разделять на два +-45 по ходу движения с масштабом в два раза меньше. И это будет просто два новых объекта которые при попадании будут просто уничтожаться. В любом случае для этих дел памяти должно хватить и нужно делать все максимально линейно и быстро.
- - - Добавлено - - -
А на чсчет партиклов, это если останется запас по быстродействию, для антуража :)
- - - Добавлено - - -
Лет двадцать назад увлекался OpenGL, были вещи которые реально мотивировали:) Например как шикарно смотрелся дым от паровоза в игре Comandos, сразу решено было повторить:)
Уже не помню как называются полигоны всегда повернутые к зрителю.. билборды вроде.. было здорово, но это не про УКНЦ:)
Я думаю, что проще большой астероид (как в оригинале) разделять на два +-45 по ходу движения с масштабом в два раза меньше. И это будет просто два новых объекта которые при попадании будут просто уничтожаться. В любом случае для этих дел памяти должно хватить и нужно делать все максимально линейно и быстро.
Наконец-то разумные мысли.
Вообще на каждый объект должно быть достаточно:
- тип - один байт - определяет размер + ориентацию, либо ориентация отдельным байтом
- координаты X и Y - два слова
- скорости по X и Y - два слова
Итого - 5 слов, 10 байт.
Сейчас самое важное - сделать тест производительности, определить сколько и каких объектов УКНЦ потянет без задержек - от этого уже всё остальное зависит.
Сейчас самое важное - сделать тест производительности, определить сколько и каких объектов УКНЦ потянет без задержек - от этого уже всё остальное зависит.
По отдельности все процедуры уже готовы, осталось все в кучу собрать, надеюсь на выходных дадут мне этим заняться :)
BlaireCas
25.10.2020, 21:08
Исходники KRAKOUT-a (сорри не выложил раньше).
Там есть процедурки для музыки в периферийном процессоре. Насколько помню это была некая жуть с портами :) Типа tst @#177714 по нескольку раз делать (одного нехватало). Спасибо тут люди помогли.
Музыкальные вещи в KRKPPU.MAC
Для полноценного компиляния будет нужен php и rt11.exe (не включаю их). Ну и вообще там crazy code в куче мест :) Но вдруг кому надо будет мол как работать с переферийным процессором и музыкой/звуками встроенной пищалки.
73778
- - - Добавлено - - -
Кстати на УКНЦ я бы не про астероиды, а про River Raid подумал бы. Времени нет помучаться, а так с УКНЦшным скроллом через таблицу строк экрана - самое оно бы было. Но если астероиды получатся - то тоже очень неплохо будет.
, а про River Raid подумал бы.
Думал, даже на си генератор ландшафта написал, не понравилось. Для УКНЦ с вертикальным скроллом можно что-нибудь интереснее придумать. (тайловую графику сдвигать)
Как правильно учесть "неквадратность" пикселей без лишних вещественных умножений?
Без коррекции выглядит так (кораблик под 45град):
https://pic.maxiol.com/thumbs2/1603816441.630630946.20201027222601.png (https://pic.maxiol.com/?v=1603816441.630630946.20201027222601.png&dp=2)
тупо сделал ASL Y:
https://pic.maxiol.com/thumbs2/1603816598.630630946.20201027222901.png (https://pic.maxiol.com/?v=1603816598.630630946.20201027222901.png&dp=2)
тоже что-то не то.
- - - Добавлено - - -
Я думал сделать масштаб кратный двум (дешево-сердито).
Наверно придется делать с точкой и для Y на 2.44 больше.
Как правильно учесть "неквадратность" пикселей без лишних вещественных умножений?
Сделай две таблицы синусов. Одну обычную, а другую умноженную на 1.6.
Как правильно учесть "неквадратность" пикселей без лишних вещественных умножений?
Без коррекции выглядит так (кораблик под 45град):
https://pic.maxiol.com/thumbs2/1603816441.630630946.20201027222601.png (https://pic.maxiol.com/?v=1603816441.630630946.20201027222601.png&dp=2)
тупо сделал ASL Y:
https://pic.maxiol.com/thumbs2/1603816598.630630946.20201027222901.png (https://pic.maxiol.com/?v=1603816598.630630946.20201027222901.png&dp=2)
тоже что-то не то.
; Y = Y * 1.75
MOV Y, Yhalf
ASR Yhalf ; = Y/2
ADD Yhalf, Y
ASR Yhalf ; = Y/4
ADD Yhalf, Y
Всё в таком духе :)
2.44 = 2.5 - 0.06, если что ;)
; Y = Y * 1.75
MOV Y, Yhalf
ASR Yhalf
ADD Yhalf, Y
ASR Yhalf
ADD Yhalf, Y
https://pic.maxiol.com/thumbs2/1603817831.630630946.20201027225615.png (https://pic.maxiol.com/?v=1603817831.630630946.20201027225615.png&dp=2)
Лучше :)
- - - Добавлено - - -
Что-то я совсем тупить начал, пора завязывать :)
https://pic.maxiol.com/thumbs2/1603817831.630630946.20201027225615.png (https://pic.maxiol.com/?v=1603817831.630630946.20201027225615.png&dp=2)
Лучше :)
- - - Добавлено - - -
Что-то я совсем тупить начал, пора завязывать :)
Нужен совет. Что делать, если температура тела падает ниже 36'С во время кодинга? :)
Нужен совет. Что делать, если температура тела падает ниже 36'С во время кодинга?
Не кодить)
С арифметикой вроде разобрался (можно уже порулить влево-вправо):
https://yadi.sk/d/W-HF4hAPftLbUQ
Нужно думать как все это ускорить (регистровый доступ б..).
- - - Добавлено - - -
В принципе если делать монохромной, то можно поизвращаться.
Написать все в ПП и открыть прямой доступ к 3му плану. (без прерываний достаточно хардкорно)
Или сдвинуть адрес ВОЗУ в ЦП и работать с одним планом (памяти должно хватить.. кода немного, а данных дык вообще почти нет :))
Это если совсем тормозить будет.
Написать все в ПП и открыть прямой доступ к 3му плану. (без прерываний достаточно хардкорно)
Зачем? ПП значительно медленнее, чем ЦП.
Можно и из ЦП адресовать два плана напрямую, спроецировав их в нижние 64Кб.
Можно и из ЦП адресовать два плана напрямую, спроецировав их в нижние 64Кб.
Или сдвинуть адрес ВОЗУ в ЦП и работать с одним планом (памяти должно хватить.. кода немного, а данных дык вообще почти нет )
Тлько в прошлый раз когда делал так в верхней строчке мусор какой-то шевелился:) разбираться не стал поскольку для LM это был не вариант.
Возможно там неотображаемые строки стали отображаемыми :)
И работать будет проще с одним планом т.к. они разнесены в пространстве и времени :)
По поводу твоего корабля - ездит хорошо, но попадает под луч, потому что не синхронизирован с кадровой разверткой.
Еще он немного растянут по горизонтали.
А так же по горизонтали в 2 раза медленнее двигается.
но попадает под луч, потому что не синхронизирован с кадровой разверткой.
Проверял только математику.. другим особо не заморачивался.
Еще он немного растянут по горизонтали.
Делал на эмуляторе, под реал не подгонял.. дальше исправлю.
А так же по горизонтали в 2 раза медленнее двигается.
Чтобы одинаково двигался нужно нормализацию делать, думаю как проще.
А сейчас только снусы и косинусы прибавляются, а по горизонтали как известно у нас точек в два раза больше.
Делал на эмуляторе, под реал не подгонял.. дальше исправлю.
Соотношение сторон проверяй на моем эмуляторе. Оно очень близко к оригиналу.
В любом случае расстояние считать придется для коллизий. (это я к нормализации)
А сейчас только снусы и косинусы прибавляются, а по горизонтали как известно у нас точек в два раза больше.
В 1.6 раза больше.
В 1.6 раза больше.
Не суть, если по правильному считать - без разницы. Только по правильному ресурсов не хватит :(
Не суть, если по правильному считать - без разницы. Только по правильному ресурсов не хватит :(
Умножение на константу - это вообще самое простейшее.
Обычно для этого используют готовую таблицу.
Да я не про то, если ввести другие векторные величины скорость, ускорение, импульс, гравитация.. все колом встанет. На ПЦ о таких вещах не задумываешся :)
А было бы красиво :)
А на константу-то мы помножим.. обязательно :)
Наткнулся на исходники игры SPACE WAR, 1974 года.
Вдруг чем-то будет полезно - https://github.com/MattisLind/SPACEWAR/tree/master/SRC
Наткнулся на исходники игры SPACE WAR, 1974 года.
Для таких игрушек векторный дисплей самое оно.. не нужно линии по точкам вырисовывать и смотрится классно (особенно с двухслойным люминофором):)
Новая тема - "подключение векторного дисплея к УКНЦ" :)
Да я не про то, если ввести другие векторные величины скорость, ускорение, импульс, гравитация.. все колом встанет. На ПЦ о таких вещах не задумываешся :)
А было бы красиво :)
А на константу-то мы помножим.. обязательно :)
Попробуйте все показатели движения умножить, например, на 32. Далее вести расчёты в целых числах, и только перед передачей значений графическим процедурам делить их на 32...
Тогда, скорее всего, акромя целочисленной таблицы синусов ничего и не понадобиться из монструозного :)
Попробуйте все показатели движения умножить, например, на 32.
Насколько я понимаю в этом смысл арифметики с фиксированной точкой, хотя я поступил проще и сделал s15.16 что гораздо быстрее но все равно очень медленно :(
Смысл в том, что УКНЦ ни при каких раскладах не потянет такое количество параметров (с тормозной графикой.. и медленным рисованием линий).
Я про векторный дисплей не просто упомянул:)
- - - Добавлено - - -
Если вы заметили в примере программы который я привел выше, размеры кораблика несколько гуляют.. не хватает точности.. и это при 16ти бит после запятой.. ,а вы говорите раздели на 32.
Сначала умножить на 32 :)
Потом считать в целых числах (без потери точности).
И уже затем, на самой последней стадии, подготовить реальные координаты графического примитива, поделив относительные (и более точные, в другом масштабе) целочисленные координаты на 32. Погрешность, в любом случае не меньше +-1 пиксель :) Вдруг, при таком способе и не больше ;)
Просто представьте, что у вас (виртуальный) экран размером (640*32)х(350*32), а не 640х350, например. И доступны только целочисленные вычисления.
А в самом конце, вы всё это масштабируете в окно 640х350, простым делением координат точек на 32...
- - - Добавлено - - -
Да, кстати, подобрать масштабную сетку, и отработать целочисленную математику векторов, может быть проще в Бейсике? :)
И уже потом мучать себя ассемблерами))
А в самом конце, вы всё это масштабируете в окно 640х350, простым делением координат точек на 32...
И получается какка :)
Сначала умножить на 32
Потом считать в целых числах (без потери точности).
И уже затем, на самой последней стадии, подготовить реальные координаты графического примитива, поделив относительные (и более точные, в другом масштабе)
Я о чем выше распинался?... У меня вся арифметика s15.16 и то огромная потеря точности. Вы мне глаза хотите открыть что 5 бит лучше 16ти?
- - - Добавлено - - -
Да, кстати, подобрать масштабную сетку, и отработать целочисленную математику векторов, может быть проще в Бейсике?
И уже потом мучать себя ассемблерами))
Если вы такой знаток Васика, пожалуйста изобразите, что хотели сказать.. плавное вращение (без скачков пикселей) в пять бит :)
И получается какка :)
Я о чем выше распинался?... У меня вся арифметика s15.16 и то огромная потеря точности. Вы мне глаза хотите открыть что 5 бит лучше 16ти?
Лучше, чем когда фиксированная точка используется влоб, без учёта потери точности вычислений на каждой из операций расчёта :)
- - - Добавлено - - -
Чего там такого нужно знать в Васике?
Просто указываете, что переменные целочисленные явным образом))
Всё остальное - чистая начертательная геометрия))
Пока сам не споткнешься о проблему все кажется элементарно.. (попробуйте - рекомендую :)
И Васик тут не самый лучший помошщик.. копайте глубже :)
Сейчас есть время только на советы :)
Когда-нибудь изображу, если останется в этом необходимость =)
Чего там такого нужно знать в Васике?
Просто указываете, что переменные целочисленные явным образом))
Всё остальное - чистая начертательгая геометрия))
Ссылку в студию на решение этого элементарного вопроса..
- - - Добавлено - - -
Проблема как вы могли видеть ВЫШЕ не в арифметике, а в общей тормознутости видеосистемы УКНЦ.
От арифметики все равно никуда не денешься, а вот скорость отрисовки - проблема.
Ссылку в студию на решение этого элементарного вопроса..
Чукча не читатель, чукча - писатель! (это я про себя)
Просто поделилась своими мыслями вслух.
Вдруг, они окажутся разумными :)
По отрисовке в точности не подскажу. Если какой-то из двух ЦПУ имеет прямой доступ к грОЗУ, нужно стараться, чтобы он рисовал графику спец процедурами. Я не знаю, насколько хороший и быстрый код в ПЗУ УК-НЦ для векторной графики.
Вдруг, они окажутся разумными
Выше по теме мысли по ускорению я уже высказал.
А когда тему открывал.. думал тоже все элементарно. Двадцать лет назад уже в OpenGL рисовал, ан нет.. чем дальше в лес тем толще партизаны..
ВДРУГ не получится:)
- - - Добавлено - - -
По отрисовке в точности не подскажу. Если какой-то из двух ЦПУ имеет прямой доступ к грОЗУ, нужно стараться, чтобы он рисовал графику спец процедурами. Я не знаю, насколько хороший и быстрый код в ПЗУ УК-НЦ для векторной графики.
Вот в этом вся проблема форума, никто его не читает, а пишет "умные" ответы только на последний пост :)
- - - Добавлено - - -
чтобы он рисовал графику спец процедурами.
С этим вышел великий облом.. спец. процедуры даже быстрее рисуют (и даже мысль глупая была.. 8цветов, работают в ПП.. живи и радуйся).. но не работают по 100му (поскольку общаются по "телеграфу").. и в "графическом" режиме у меня не получилось стандартную графику выводить.. поправьте если я не прав.
Если ПП умеет рисовать векторную графику быстро, то может стоит в его памяти разместить п/п аниматора экрана игрового поля.
Между КСИ передавать таблицу параметров объектов для отображения/стирания, а по КСИ отправлять аниматору этому только сигнал "обнови экран" (согласно таблице объектов)...
- - - Добавлено - - -
а ЦП пусть считает координаты и шлёт звуки через порт принтера на AY или Covox...
без комментариев
- - - Добавлено - - -
(копни на пару сантиметров глубже)
Да, кстати, подобрать масштабную сетку, и отработать целочисленную математику векторов, может быть проще в Бейсике?
И уже потом мучать себя ассемблерами))
Сейчас есть время только на советы
Когда-нибудь изображу, если останется в этом необходимость =)
Ждем атероидов на Васике Вильнюс86 :)
/*Оффтоп*/ Как в этом форуме сделать упоминание? Человека.. Gid
- - - Добавлено - - -
Я это к чему.. в отличии от Вас этот человек абсолютно безкорыстно.. делится исходниками.. и если бы не он я бы не смог написать звук на свой ИРПР... и с арифметикой тоже помог.
- - - Добавлено - - -
Есть люди которые реально помогают, а есть которые только озвучивают себя :)
S_V_B, не отчаивайтесь :)
Терпение и труд -- всё перетрут!
Просто GID уже столько "перетёр", что мы за ним не поспеваем =)
Есть люди которые реально помогают, а есть которые только озвучивают себя :)
Просто GID уже столько "перетёр", что мы за ним не поспеваем =)
Просто я ему хотел сказать спасибо... в отличии от остальных троллей..
- - - Добавлено - - -
Ну и как мне добавить ему звезду на шеврон?
Чем можем, тем и помогаем))
И искренне надеемся, что Вы, в итоге, справитесь со всеми особенностями УК-НЦ!
А исходниками разными делимся, просто они (https://zx-pk.ru/threads/32173-adapter-myshi-ps-2-v-standart-myshi-marsianka.html?p=1080005&viewfull=1#post1080005) Вам неинтересны :)
Но все таки ждем от Вас чуда на ВАСИКЕ86
Найдите сообщение от GID, и в левом нижнем углу этого сообщения нажмите кнопку [Спасибо!] :)
Потихоньку переписываю свои библиотеки для работы с графикой.
вариант функции ABS (R0):
MOV R0, R1
ASH #-15., R1
ADD R1, R0
XOR R1, R0
Может кому полезно будет или более интересный вариант предложит :)
TST R0
BPL 10$
NEG R0
10$:
TST R0
BPL 10$
NEG R0
10$:
Это очевидный вариант.
Нужно без ветвлений - "борьба за скорость" :)
Например при расчете AABB этих ABS будет много.
- - - Добавлено - - -
Скоро проверю в "реальной жизни" несколько вариантов.. там видно будет.
ASH #-15., R1
Это очень-очень медленная операция. Читай тему с реверсом ВМ2.
#4+R0(2000) empty 623 697 оп./сек
#4+R0(2000) 312 238 оп./сек -> 625 256 оп./сек
CMP (R0)+,(R0)+ empty 624 476 оп./сек
CMP (R0)+,(R0)+ 173 051 оп./сек -> 239 389 оп./сек
#2+R0(2000) empty 624 476 оп./сек
#2+R0(2000) 312 238 оп./сек -> 624 476 оп./сек
INC R0 INC R0 empty 624 476 оп./сек
INC R0 INC R0 390 086 оп./сек -> 1 039 290 оп./сек
TST (R0)+ empty 624 476 оп./сек
TST (R0)+ 270 808 оп./сек -> 478 169 оп./сек
CLR R0 - SOB R0, . empty 2 079 037 оп./сек
CLR R0 - SOB R0, . 5 оп./сек -> 5 оп./сек
ABS1 73 300 оп./сек
ABS2 345 979 оп./сек
.
- - - Добавлено - - -
Нужно без ветвлений - "борьба за скорость"
Буковки голубеньким подкрась - реально ускорится
Буковки голубеньким подкрась - реально ускорится
подкрасил:
MOV R0, R1
SXT R1
ADD R1, R0
XOR R1, R0
Заменил конструкцию:
MOV R3,R2
ASR R2
ASR R2
ASR R2
MUL #40.,R2 ;Y/8*40
ADD R3, R0 ; адрес под спрайтом в тайлбуфере
на эквивалентную
BIC #7, R3
MOV R3,R2
ASL R3
ASL R3
ADD R2,R3
ADD R3, R0 ; адрес под спрайтом в тайлбуфере
на эквивалентную
Она не эквивалентная.
ADD R3, R0 после команды MUL, к R0 прибавляет не R2*5, а старшую часть умножения на 40., то, что за 16 бит из R2 вылезло.
У меня эквивалентный код получается такой:
mov R3, R2
bic #7, R2
clr R3
mov R2, -(SP)
asl R2
rol R3
asl R2
rol R3
add (SP)+, R2
adc R3
add R3, R0
- - - Добавлено - - -
Ну, либо в первом примере опечатка.
что за 16 бит из R2 вылезло.
Там такая формула получается
R3 := (R3*8193*40) mod 65536
- - - Добавлено - - -
И до 1638 даёт в результате в R3 умножение на 40, дальше пошло усечение результата
ADD R3, R0 после команды MUL, к R0 прибавляет не R2*5, а старшую часть умножения на 40., то, что за 16 бит из R2 вылезло.
Код эквивалентный по результату.
в первом примере Y (в точках) делится на 8 (8х8) тайл и умножается на 40 (ширина буфера в байтах) = адрес в нужной строке буфера.
во втором примере сократили деление на 8 и сделали быстрое умножение.
- - - Добавлено - - -
работает заметно быстрее
Вот только MUL #40.,R2 - это, внезапно, не умножение R2 на 40, а умножение 32-ух битного числа (R2 старшая часть и R3 младшая часть) на 40, так что по результату - тупо умножить R3 на 40 с усечением до 16 бит
не умножение R2 на 40, а умножение 32-ух битного числа
А MUL как будет работать с 16ю битами?
Нет, с умножением ошибся (всё таки 16-ти битное из R2, с DIV спутал), но результат всё равно интересный
.EXE T
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 40
9 40
10 40
11 40
12 40
13 40
14 40
15 40
16 80
17 80
18 80
19 80
20 80
21 80
22 80
23 80
24 120
25 120
26 120
27 120
28 120
29 120
30 120
31 120
32 160
33 160
34 160
35 160
36 160
37 160
38 160
39 160
40 200
41 200
42 200
43 200
44 200
45 200
46 200
47 200
48 240
49 240
50 240
51 240
52 240
53 240
54 240
55 240
56 280
57 280
58 280
59 280
60 280
61 280
62 280
63 280
64 320
65 320
66 320
67 320
68 320
69 320
70 320
71 320
72 360
73 360
74 360
75 360
76 360
77 360
78 360
79 360
80 400
81 400
82 400
83 400
84 400
85 400
86 400
87 400
88 440
89 440
90 440
91 440
92 440
93 440
94 440
95 440
96 480
97 480
98 480
99 480
100 480
101 480
102 480
103 480
104 520
105 520
106 520
107 520
108 520
109 520
110 520
111 520
112 560
113 560
114 560
115 560
116 560
117 560
118 560
119 560
120 600
121 600
122 600
123 600
124 600
125 600
126 600
127 600
128 640
129 640
130 640
131 640
132 640
133 640
134 640
135 640
136 680
137 680
138 680
139 680
140 680
141 680
142 680
143 680
144 720
145 720
146 720
147 720
148 720
149 720
150 720
151 720
152 760
153 760
154 760
155 760
156 760
157 760
158 760
159 760
160 800
161 800
162 800
163 800
164 800
165 800
166 800
167 800
168 840
169 840
170 840
171 840
172 840
173 840
174 840
175 840
176 880
177 880
178 880
179 880
180 880
181 880
182 880
183 880
184 920
185 920
186 920
187 920
188 920
189 920
190 920
191 920
192 960
193 960
194 960
195 960
196 960
197 960
198 960
199 960
200 1 000
.
Код эквивалентный по результату.
Он был бы эквивалентный, если бы в оригинале было бы
MOV R3,R2
ASR R2
ASR R2
ASR R2
MUL #40.,R2 ;Y/8*40
ADD R2, R0 ; адрес под спрайтом в тайлбуфере
к R0 прибавляли бы R2
Вот только MUL #40.,R2 - это, внезапно, не умножение R2 на 40, а умножение 32-ух битного числа
В 1801ВМ2 и ВМ3 - нет, MUL там умножение Rn:Rn+1 = Rn * (SS), т.е. умножение 16-битного числа на 16 битное число, с сохранением результата в 32-х битное число
В 1801ВМ2 и ВМ3 - нет, MUL там умножение
Уже написал
- - - Добавлено - - -
Rn+1
Rn v 1
с сохранением результата в 32-х битное число
Правильно, в R3 младшая часть.. В R2 ноль будет (и есть)
Оба примера рабочие, первый еще двухлетней давности, когда не заботился о скорости выполнения.
Уже написал
А я слоупок, пока я пишу ответ, могут вперед меня ответить и трое и пятеро, и уже даже забыть про тот пост, на который я отвечаю.
Rn v 1
это я скопипастил с распространённых источников, подозреваю, "+" там подразумевается как старая советская запись операции или, которая всех в заблуждение потом вводить начала.
подозреваю, "+" там подразумевается как старая советская запись операции или
Скорее всего в первоначальном источнике был + в кружке
Правильно, в R3 младшая часть
блин. Точно, тут же задом наперёд. Опять я всё перепутал. Привык уже к Low Order, и автоматом подразумеваю, что в регистре с мл. номером и часть младшая.
Чтож, извиняюсь, был неправ во всех местах.
Посмотрел на оригинал игры, на аркадном автомате.
Там из вращающихся объектов - только сам кораблик, всё остальное хоть и векторное, но рисуется без поворотов.
Получается, что все объекты можно один раз отрендерить под фиксированное разрешение и хранить как статичные спрайты.
Только с корабликом уже возиться - либо на лету рендерить либо держать N спрайтов для одного сектора в 90 градусов и отражать по вертикали и горизонтали.
Может так скорости хватит?
Если векторами рисовать, то все равно вращаются они или нет, по любому каждый раз на матрицу переноса-поворота умножаем.
Хочу попробовать рисовать средствами граф. режима терминала, вроде быстрее рисует. (разом выводить просчитанный кадр.. массивом кодов)..хотя.. хз.
Если рантайм отрендерить в память кораблик через градус, а камни статичные сделать .. можно попробовать на крайняк.
- - - Добавлено - - -
Кому интересно:
Преобразование чисел в коды терминала (для граф. режима)
;---------------------------------------------------------------------
; П/п преобразование целого числа в три символа
;вход: R1 - число , R3- буфер для 3х смволов.
;---------------------------------------------------------------------
ACE1:
MOV R0,-(SP)
MOV R3,-(SP)
MOV R4,-(SP)
TST R1
BGE 1$
NEG R1
1$: MOV R1,R0
ASH #-12,R0
BIC #177700,R0
BIS #100,R0
MOVB R0,(R3)+
MOV R1,R0
ASH #-4,R0
BIC #177700,R0
BIS #100,R0
MOVB R0,(R3)+
MOV R1,R0
BIC #177760,R0
BIS #40,R0
MOVB R0,(R3)+
MOV (SP)+,R4
MOV (SP)+,R3
MOV (SP)+,R0
RETURN
;---------------------------------------------------------------------
; П/п преобразования двух целых чисел в пять символов
;вход: R1 - X, R2-Y , R3- буфер для 5ти смволов.
;---------------------------------------------------------------------
ACE2:
MOV R0,-(SP)
MOV R3,-(SP)
MOV R4,-(SP)
MOV R2,R0
ASH #-7,R0
BIC #177740,R0
BIS #40,R0
MOVB R0,(R3)+
MOV R1,R4
BIC #177774,R4
MOV R2,R0
BIC #177774,R0
ASL R0
ASL R0
BIS R0,R4
BIS #140,R4
MOV R4,R0
MOVB R0,(R3)+
MOV R2,R0
ASR R0
ASR R0
BIC #177740,R0
BIS #140,R0
MOVB R0,(R3)+
MOV R1,R0
ASH #-7,R0
BIC #177740,R0
BIS #40,R0
MOVB R0,(R3)+
MOV R1,R0
ASR R0
ASR R0
BIC #177740,R0
BIS #100,R0
MOVB R0,(R3)+
MOV (SP)+,R4
MOV (SP)+,R3
MOV (SP)+,R0
RETURN
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot