ZXNet эхоконференция «code.zx»

Hello, All

Пишу кой-какие заготовки, потенциально для игрушки, вот думаю, насколько
целесообразно будет сделать так:
Повесить всю логику (опрос клавы, примитивный AI, игровую физику) на
перерывания, а основной вывод на экран и копирование инфы между банками памяти
реализовывать в основное время.
Что это даст? независимость хода игры от скорости процессора и, при продуманной
реализации, так сказать, fps-систему.

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

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

Hello, moroz1999

IG#6/code/Игровой цикл

Hello, moroz1999

mor> У меня мало опыта в игростроении, поэтому требуются ваши мнения. Что
mor> вы можете сказать по этому поводу? какие могут быть минусы у такой
mor> системы?

Очень сложно оценить данную схему, ведь всё зависит от того какая именно
графика, нужно ли синхронное изменение бордюра с экраном ... Вообщем множество
факторов, которые могут повлиять на строение кода. Я всегда стараюсь всё, что
работает с изображением делать только на прерываниях, это хоть и заставляет
постоянно искать выходы из тупиков, но в итоге приводит к оптимальному коду,
или близком к идеалу. А вне прерывания делаю всяческие депакенги и декранченги

Однако, когда-то у меня была клавиатура с кабелем длиной 1 метр, уж очень я
любил выложить ноги и программировать в развалку. И длина кабеля очень влияла
на проверку дребезга клавиатуры. Поэтому есть у меня один очень дивный
ONE-FRAME редактор текста с необычным опросом клавиш. Hо всего в этом мире не
учтёшь. Хотя это я со своим асмовским взглядом на "ВОРЛД" !!!

Hello, Robus

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

ну например вот наша старая игра moorhuhn;
//; на прерываниях опрос клавы, мышки и проигрывание музыки
// вывод курсора (каждый фрейм на новом месте =)

// в основное время обработка данных от органов управления (кадр строится и
выводится за 2 фрейма
// следующие процедуры:
// движение петухов (кто, где, когда, как)
// обработка выстрела (если был, то что произошло - убиваем петуха?, вычитаем
пулю?, обсчет "комбо"
// управление выстрелом
// вывод на экран

последняя процедура обрабатывает очередь спрайтов, где указаны координаты
спрайтов и номера анимаций. она абсолютно (ну теоретически=) не зависит от
остальных блоков, и опять же теоретически ее можно в любой момент поменять
и/или переписать...