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 фрейма // следующие процедуры: // движение петухов (кто, где, когда, как) // обработка выстрела (если был, то что произошло - убиваем петуха?, вычитаем пулю?, обсчет "комбо" // управление выстрелом // вывод на экран последняя процедура обрабатывает очередь спрайтов, где указаны координаты спрайтов и номера анимаций. она абсолютно (ну теоретически=) не зависит от остальных блоков, и опять же теоретически ее можно в любой момент поменять и/или переписать...