Разработка игры Dash

[jerri]

Угу. Нужен стандартный звук, стандартная музыка, стандартная работа с графикой и вывод тайлов стандартного разрешения.

ок, я понял - нет ТЗ нет процедур

Можно одинаково, но можно и по-разному. Это как разработчик решит. На Спеке для лабиринта 16x16 трудно добиться цветности, но как бы нет смысла делать игру для Jme специально не цветной. Но ты затронул важный вопрос. Нужно чтобы игра, оставаясь платформенно-нейтральной, всё-таки учитывала платформенные особенности. Мне этого удалось добиться. В Спектрум-версии будет выбор управления с джойстиками. На Jme это не имеет смысла, поэтому там его и не будет. Что можно предложить ещё в этом случае?

и приходим в итоге к тому от чего уходим. или 4 версии основной программы
или километровый набор условий для сборки.

Это ты так оправдываешь то, что достиг всего и стал мега-мастером, но это может оценить только кучка стареющих дядек?

так, ты опять меня не понимаешь.

с64 работает с аппаратными спрайтами 24х21, играет палитрой и умеет строить фон из тайлов.

Спектрум работает с экраном напрямую, аппаратных возможностей не имеет никаких

ZXEvo с прошивкой TSLab умеет каждую точку своим цветом
4 разрешения экрана, до 85 аппаратных спрайтов 64х64

Java ME это вообще не пойми чо имеющее вообще рандомный разброс параметров при этом на голову превосходит предыдущие позиции.

потому и конь и трепетная лань.

Назрел новый вопрос. Подскажите, по какому максимальному адресу может находиться таблица векторов для IM 2?

#fe00-#ff01

#ff00-#ffff со значением #f3 не рекомендую.

[Oleg N. Cher]

#FE00
хотя можно обойтись без таблицы, выставив #FF
#FFFF #18F3 JR #FFF4

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

Просто иногда читаешь авторитетную статью, где утверждается, что это так-то, а оказывается что есть тонкости, и каждый использует свой собственный вариант, который считает верным (примерно как было с опросом Kempston joystick'а).

ок, я понял - нет ТЗ нет процедур

jerri, тут мы подходим к тому, что нужно эти вопросы оперативно обговорить, и, соответственно, я набиваюсь к тебе в аську, хотя не уверен, что тебе это понравится. Чувствуешь деликатность момента?

и приходим в итоге к тому от чего уходим. или 4 версии основной программы
или километровый набор условий для сборки.

Собственно, да. Но тут язык программирования не виноват - просто такая уж специфика поставленной задачи. Но я не утверждаю, что все игры должны быть так устроены. Просто хорошо, что Оберон удаётся использовать таким способом - программить любую железку, где есть процессор. И не нужно для этого минимум 1 Гб ОЗУ, установленный .NET такой-то версии или чего-то в таком роде.

Java ME это вообще не пойми чо имеющее вообще рандомный разброс параметров при этом на голову превосходит предыдущие позиции.

О, ты прав. Она приносит много головняка. Вот хотя бы взять разные разрешения экрана. Оказывается, их не единицы, а десятки. И если исходить из архитектуры Dash'а (чтобы без прокрутки) и из сознательного выбора использовать только MIDP 1 получается, что нужно рисовать несколько наборов тайлов разного разрешения. Я думаю, справлюсь с этим, но не знаю насколько быстро.

И со звуками траблы, да... midi что ли использовать...

потому и конь и трепетная лань.

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

#fe00-#ff01

#ff00-#ffff со значением #f3 не рекомендую.

Отчего же, можно узнать?

Сейчас я прикинул, что игра будет лагать при большом количестве монстров на уровне (хотя БК-шный вариант ведёт себя так же), поэтому хочется сделать чтобы звук не использовал слишком много тактов. Нормально если для 48k-игры звук будет только на AY?

[Alex Rider]

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

Проблем с клонами не будет. Я бы сделал так:

setup_im2:
        ld hl,#fe00
        ld a,h
        ld de,#fe01
        ld bc,#100
        ld (hl),#ff
        ldir
        di
        ld i,a
        im 2
        ld a,#18        ; jr *
        ld (#ffff),a
        ld a,#c3        ; jp **
        ld (#fff4),a
        ld hl,ISR
        ld (#fff5),hl
        ei
        ret

Процедура сформирует следующее:
1. Таблицу векторов прерываний из 257 байт с #fe00 по #ff00 включительно. В тиаблице будут байты #ff. Получается, что сама процедура будет по ардесу #ffff
2. Команду перехода jr #fff4 по адресу #ffff (смещение перехода возьмется из адреса #0000 в ПЗУ, а там #f3 - код команды di).
3. Команду перехода jp ISR по адресу #fff4 - переход на, собственно, процедуру обработки - плеер, например.
4. Ну и, собственно, включит im 2.

Кстати, байты #ff01 - #fff3 и #fff7 - #fffe можно невозбранно использовать по своему усмотрению.

---------- Post added at 05:36 ---------- Previous post was at 05:27 ----------

Отчего же, можно узнать?

Я вижу только один большой минус: основной код и данные должны заканчиваться до #f3f3, а обработчик прерывания или прыжок на него гарантированно находиться по адресу #f3f3. Это минус 3 Кб в ОЗУ. Ну либо "обтекать" кодом #f3f3 и дальше. Геморно на ЯВУ, ИМХО.

[drbars]

Если в игре планируется использование режима прерывания, то лучше всего таблицу вектора прерывания разместить с пределах адресов #8000-#BFFF, таблица должна быть полной, а не двухбайтной. В противном случае, совместимость с разными фирменными машинами и советскими клонами будет потеряна. Опрос клавиш нужно проводить в начале прерывания и вызывать из обработчика прерываний.

[Oleg N. Cher]

Эх, всё уже сделано за нас. И пока я тут прилежно изучаю Java ME... Мдя.

http://yogadestiny.ru/android/bolder.apk

Чувствую себя динозавром. Кардинально сменился не только парк языков программирования, но и менталитет игроков, само предпочтение игр. Мне современные игры совсем не по душе, а от сильно динамичного 3D голова кружится.

И всё меньше простоты. А так хотелось бы... Но одно понимаю чётко - в идеальном софте привязок к платформам быть не должно. Это должен быть грамотно структурированный набор принятых решений, на основе которого динамически генерится софт. Это, правда, только мечта. Но я не согласен учить ещё сто языков из-за того что каждый из них чем-то лучше прочих.

А вы тем временем убеждайтесь насколько сильно действуют привязки из детства. И не спрашивайте зачем я делаю этот порт Dash, ладно?

[Alex Rider]

Если в игре планируется использование режима прерывания, то лучше всего таблицу вектора прерывания разместить с пределах адресов #8000-#BFFF

В 48К все равно где ниже #8000. Только это, Олег, есть намек: на старте игры сделать POKE (#5b5c),#10: out (#7ffd),#10, а то не известно какую страницу 128К мог оставить впечатанной после себя коммандер, используемый для запуска игр.

[Oleg N. Cher]

Хорошо, я как-то этот момент упустил. А что если вообще переходить в режим 48k с открытым портом? Когда-то Wlodek Black давал для этого такой код:

        DI
        LD      SP,(23613) ; взять изначальный адрес ERR_SP
        POP     HL
        LD      HL,4867 ; заменить адрес входа в интерпретатор
                          Бейсика при ошибке на 48-й
        PUSH    HL
        LD      HL,7030 ; заменить адрес возврата из USR на 48-й
        PUSH    HL
        RES     4,(IY+1) ; сбросить флаг 128-Бейсика
        LD      DE,5566 ; взять 2 адреса каналов клавиатуры и экрана
                          для 48-Бейсика...
        LD      HL,(23631) ; CHANS
        LD      BC,15
        ADD     HL,BC
        EX      DE,HL
        LD      C,4
        LDIR ; ...и водрузить их на законное место
        EI
        RET ; не бояться Ret после манипуляций со стеком! Всё правильно!

Кстати, размещать таблицу в медленной памяти (contended memory) нежелательно, вы же именно поэтому советуете адрес не ниже #8000?

[Alex Rider]

Кстати, размещать таблицу в медленной памяти (contended memory) нежелательно, вы же именно поэтому советуете адрес не ниже #8000?

Да, вектор в области #4000 - #7fff будет давать на фирменных машинах снег. А вектор с адресов #c000 - #ffff не будет только если он находится в 0-й странице. Но адреса #8000 - #bfff для ЯВУ неудобны, лучше использовать для таблицы область в конце ОЗУ. Поэтому на мой взгляд идеальный вариант - #fe00 - #ff00 в 0-й странице.

Когда-то Wlodek Black давал для этого такой код:

Этот код, во-первых, порушит стек и вернется в BASIC, во-вторых, нужен для нормального продолжения работы BASIC-программы и ZX-Printer'а. Если возврата в BASIC и печати нет, то и не нужен этот код совсем. Единственное, ZXDev, насколько я помню, активно зовет ПЗУ и может словить BASIC-овскую ошибку типа Out of screen или Invalid color. Если они у тебя обрабатываются корректно (то есть, если ты хочет возврат в BASIC при возникновении, а не зависон со спецэффектами), то надо бы поправить адрес обработчика ошибок на 48-й. Если надо, соображу код, который можно звать из SDCC. А можно сделать и свой обработчик таких ошибок, его адрес должен лежать в двух байтах, адрес которых лежит в (23613).

[Oleg N. Cher]

Поправочка: ZXDev не зовёт ПЗУ если того не хочет программист. Смотря какие библиотеки юзать - Basic активно пользуется ПЗУ, это логично.

Да, у меня были проблемы с тем кодом выше, поэтому остановился на таком варианте:

void Basic_Init_IM0 (void) {
  __asm
  RES  4,1(IY) /* RESET OF 128K FLAG */
  __endasm;
} //Basic_Init_IM0

И вроде бы никаких проблем с обработкой 48k-ошибок не было. Но Dash этот флаг не сбрасывает, наверное нужно поправить.

[Alex Rider]

а, у меня были проблемы с тем кодом выше, поэтому остановился на таком варианте:

Он тоже не нужен Если ты не возвращаешься из программы в интерпретатор, то программа как бы так и остается в 48К с открытыми страницами навсегда. Ибо код функции USR отрабатывает в ПЗУ 48.