Вид для печати
Это происходит потому, что сдвиговый регистр условно говоря 32-битный. И ему все равно, что сдвигать, 16 бит или 32 бита.Цитата:
Сообщение от BlaireCas
Дополнительные 8 тактов занимает лишь копирование второго слова в сдвиговый регистр (4 такта), и копирование после сдвига обратно (4 такта). И все.
Добавил несколько звуков. Схема ну не прям та что описал, что-то навроде. То-есть идея да, идея та - некими приращениями менять длительности чередования низкого и высокого уровней бипера с разным шагом.
Надо будет разумеется допиливать. Пока-что все кривовато.
(если что - UKNCBTL чутка кривит в звуках/музыке, на настоящем получше)
И прям смешно тут стало. Ирония судьбы. В играх детства ну вот ненавидел этот звук прыжка .. и что-же? И такой-же сделал у себя :) Ахахах
Хорошо бы посмотреть видео со звуком с реала.Цитата:
Сообщение от BlaireCas
- - - Добавлено - - -
Багрепорт: Каждый раз при входе на экран лопата появляется заново)
Завтра сделаюЦитата:
Сообщение от Titus
Это нормально. Тут просто я еще в раздумьях неких насчет формата хранения лабиринтов и объектов.Цитата:
Сообщение от Titus
Пока-что лабиринт сделан в виде массива цельного [dy*dx] без разделений на экраны. При прокапывании в нем проходов - запоминается сразу по всему этому массиву и пока-что не восстанавливается если скажем выйти по клавише "стоп" и опять запустить. (т.е. одноразово все).
Объекты-же привязаны к каждому "экрану" игровому (поэтому паук не может переползти на другой экран). Ну тут понятно - чтобы мне не обрабатывать вообще всех пауков/etc по карте, а только тех которые на экране. Ну и также чтобы игрок не смог теоретически собрать всех пауков на один экран и устроить аццкие тормоза
Ну и вот тут я еще не решил (казалось-бы) мелкие вопросы. И таких мелких моментов тьма :) для большого компа о таких вещах не думают, но тут слишком все ужато по памяти-ж..
Например:
- сколько выделить байт на хранение инфы об объекте. Хватит 4-х (тип/подтип, аргумент 1, аргумент 2, координата тайла) или может сделать 3 байта, а может и наоборот 6.
- нужно-ли фиксированное число объектов делать (скажем 4) для экрана (не нужно). Раз не нужно, то как получше хранить кол-во объектов для экрана (в ниблах/в байтах, вроде нибла хватит на 15 объектов, а это прилично.. но а вдруг - ведь объекты там не только те которые рисуются на экране, а еще триггеры действий и то что на экране рисоваться и не будет)
- сколько выделить для объектов про-запас (для "спавна" тех-же пауков например или еще для каких динамически создаваемых штук)
- стоит-ли вообще хранить цельный лабиринт в виде здорового массива (пока-что решил что стоит ибо у меня экраны пересекаются по одной строке/столбцу - иначе в связи с изменяемым лопатой лабиринтом будут проблемы с "а можно-ли вообще перейти на сл. экран, может там занято")
Поэтому пока-что когда входишь на экран - объекты его переписываются в рабочую область, а когда выходишь с экрана - они должны будут сохраниться откуда взяты, но пока выясняю этот момент как их хранить - я и не делаю сохранение.
Если хранить "целиком" как массив, то каждый тайл удобней для экономии места кодировать полубайтом, это 16 вариантов. Так сделано в Lode Runner, причём там вообще 8 вариантов тайлов, насколько помню. Само собой, можно ещё и сжать каждый экран, вопрос во времени распаковки-упаковки обратно (раз планируется сохранение "истории действий" на карте при переходах по экранам).
Либо генерить программно, тут основная задача - подбор алгоритма построения, чтоб рисовалась вменяемая карта, а не хаос по RND. Грамотному алгоритму понадобятся лишь несколько байт, задающих генерацию всего экрана.
Местоположение итемов, врагов и прочее тоже можно генерить, хотя бы частично.
Я бы хранил невидимую часть лабиринта в сжатом виде, а прокопы -- в виде битовой карты. Битовая карта 256x256 займёт 8 КБ, а лабиринт большего размера всё равно ни один вменяемый игрок не осилит раскопать.
Если лабиринт фиксированный, то есть варианты, как сжимать получше. Собственно, они известны: автогенеренаторы различные и сборка из типовых блоков. В принципе, можно написать автоупаковщик, который будет по нарисованному вручную лабиринту искать блоки. Это небыстро, но нужно же всего один раз при сборке мастера. Ну, естественно, при сборке из блоков нужно предусмотреть возможность накладывать блоки друг поверх друга и в конце делать мелкие патчи. Собственно, полторы сотни экранов в Эксолоне так и сделаны. Да и вообще это достаточно типовой подход.
- - - Добавлено - - -
Тут хорошо работает гибридный подход: базовую структуру уровня, т.е. проходы, платформы, двери, аретефакты мы задаём вручную, а всякий декор расставляет рандом. Если поиграться с параметрами генератора, то обычно получается вполне натурально.Цитата:
Сообщение от reddie
Да, ключевые места всё равно задаются вручную. Главное найти компромисс с генератором, дабы смена экрана не превращалась в "подождите, генерю карту" =)) Если быстродействие и аппаратные особенности позволяют, можно распаковывать соседние экраны "фоном", пока игрок занят делами на текущем.Цитата:
Сообщение от Sandro
Записал на реале.
https://youtu.be/5JE3qYMBnpA
Очень прелестные звуки. И вроде совсем игру не тормозят.Цитата:
Сообщение от Ynicky
Сколько они занимают по времени?