Вид для печати
В эмулятор (emu) гружу через евонный отладчик, там есть возможность вдуть бинарь по произвольному адресу.Цитата:
Сообщение от NEO SPECTRUMAN
У "Океана" нет какого-то особенного формата, исполняемые CP/M файлы с 100h, как обычно.
- - - Добавлено - - -
(легкомысленно) ну вот потом и подумаюЦитата:
Сообщение от NEO SPECTRUMAN
в принципе там или буфер для ракеткиЦитата:
Сообщение от tnt23
если фон будет совсем простеньким типо узорчек 8х8
перед каждым уровнем можно генерировать 8 положений ракетки на своем фоне
и быстро рисовать одну из них
Не удержусь и (снова) процитирую Дениса Грачева про "лдпуш" из замечательной статьи "Мультиколор будет побежден" (http://hype.retroscene.org/blog/dev/768.html):
Ну и так далее. Сделаю буфер, куда рендерится мячик/ракетка/бонусы, по такому же принципу кода вперемешку с данными и посмотрим, кто кого.Цитата:
А дальше нужно было ускорить вывод пикселей с сохранением возможностью их лёгкого скролинга. После всех экспериментов я остановился на оптимальном размере игровой область в 24*16 знакомест. Отрисовка пикселей это достаточно затратно, поэтому я решил взять самый быстрый метод вывода изображения из буфера в простонародье известный как «лдпуш» он основан на постоянном повторении комбинации команд ld и push. Мы отводим огромный кусок памяти в который генерируем такой код
Код:;у нас будет 320 линий
dup 320
;код для вывода одной линии
ld sp,адрес конца линии экрана
dup 12: ld de,2 байта данных: push de : edup
edup
Это и будет наш пиксельный экран, он статичен. Он просто выводит данные на экран которые в нём же и хранятся. Причем выводит он их задом наперёд, т.к. команда push уменьшает указатель стека, который в нашем случае является адресом куда мы кидаем данные. Таким образом, вместо того чтобы рисовать напрямую в экран мы, будем рисовать прямо в код! Т.е. нам нужно будет каким то образом преобразовывать реальные игровые координаты в адрес нужного нам байта в этом куске кода. К тому же нужно учитывать, что всё будет зеркально, т.к. рисуется задом наперёд и вдобавок ко всему, чтобы двигать горизонтально плавно спрайты шириной 16 пикселей по экрану нам необходимо перерисовывать 3знакоместа в ширину, а значит вычисление соседнего знакоместе будет совсем не тривиальным. Не стоит забывать, что под спрайтами ещё нужно сохранять и восстанавливать фон. К тому же нужно как-то скролить это всё прыгая на нужную строчку кода и выпрыгивать с неё и ещё обновлять адреса линий куда всё будет выводится.
В Рива Рейде у меня все спрайты так выводятся, они все суть код. Сам код сгенерен заранее. Не обязательно замыкаться на push, иногда быстрей mov m, r. А что именно ты собрался делать у себя таким образом? Спрайты, или тут куда-то еще глубже дело пошло? Процитированный текст слишком поэтичен.
Подозревал я что-то такое, но стеснялся спросить/посмотреть.Цитата:
Сообщение от svofski
Разве что в параллельных вселенных, где стек живет в отдельной медленной памяти. Так-то два mov m, r = 14 тактов, а один push = 11. Крохоборствовать так уж крохоборствовать.Цитата:
Сообщение от svofski
Я собрался так рисовать ракетку, мячик, бонусы, да в принципе все можно.
1. pop + mov + inr + mov + inr - 34 такта на пересылку двух байт. Плюсы: 1) пересылаемые данные идут подряд, 2) не обязательно разворачивать до упора, т.е. размер процедур пересылки может быть умеренным.
2. pop + shld - 26 тактов на пересылку двух байт. Плюс: пересылаемые данные идут подряд, 2) быстрее п.1. Минусы - 1) обязательно разворачивать до упора, 2) фиксированное место назвначения.
3. lxi + push - 21 такт на пересылку двух байт. Плюс: быстрее п.1 и 2. Минусы - 1) обязательно разворачивать до упора, 2) пересылаемые данные идут не подряд.
Третий вариант может быть еще быстрее. Если выводим фиксированные (не меняющиеся) тайлы с регулярным узором, то там есть много повторов и не обязательно каждому push должен предшествовать lxi, т.е. получается еще быстрее.
В зависимости от потребностей использовал все три варианта.
Если не изменяет память, то в спековском арканоиде 2 фон (вроде фон) выводится ld rp,(память) + push + push + ...
mov m,r не всегда нужны парами а у пуша есть оверхед с сохранением sp итд. На этом можно выгадать в мелочах. Как раз тут крохоборство настоящее :)
И да, существенный момент это повторение байт, или слов. Иногда можно вообще весь спрайт рассовать по регистрам и пушать и мовать их повсюду. Представляется, что например середина ракетки вполне может быть подогнана под регистры.
(Не упущу случая поворчать о том, что самолюбие не обязано страдать от того, что спрайты не вычисляются в рантайме эпическим кодом, а подготавливаются заранее внешней колченогой тулзой, которую проще подгонять и оптимизировать. Баланс езды и шашечек, getting shit done, etc..)
Ты прав, но питон... (деликатно сморкается в занавеску)Цитата:
Сообщение от svofski
tnt23, выбор языков не ограничен ассемблером для 8080 и питоном.
ivagor, я пока сделаю самый простой вариант варианта 3. Все рисуемые объекты так или иначе кратны цветному квадратику 8х8 пикселей (см. PaintBitmap). То есть выводить нужно либо два столбика по 8 байт (бонус), либо четыре столбика (мячик и кирпичи), либо восемь столбиков (ракетка).