ачо игры не обновляют и не фиксят?
тем более тут рассказывают
что нету памяти поэтому менее важный фикс заменен более важным...
Вид для печати
я обратил внимание что при наборе энергии герой становится неуязвимым ?
хорошо заметно при падении с высоты. если погибнуть то упав снова (во время набора энергии) она не отнимется.
также во время набора энергии можно спокойно пройти через врага
Прости нас, дураков, что не бросили и не побежали хотелки исполнять. Теперь-то обязательно всё сделаем, не волнуйся. Вы, ребята, крепко нас подбодрили, так и надо было, а то расслабились, скоты ленивые.
- - - Добавлено - - -
Есть такое дело, еще со времён CKD, если не изменяет память. Мы решили, что игре это не мешает, и не злит игрока, когда свежепоявившийся диззи сразу же страдает от врагов. Своего рода временный иммунитет получился, как на игровых автоматах, где герой после потери жизни и респавна какое-то время мигает и неуязвим.
Всё это здорово, но пока что реально свободных кусков, не отведенных под буферы, или мусорного кода вы, ребята, не нашли. А как дышал, как дышал (C)
Тем не менее, это не забытые части и не мусорный код, и уменьшение этих буферов чревато вполне реальными трудно воспроизводимыми глюками. Я бы сказал, что без очень веской причины идти на их уменьшение было бы глупо, а сэкономить там можно копейки.
Что там с упаковкой графики стало? Есть рабочий рецепт или вариант отпал?
Написать игру - задача куда более сложная, чем её оптимизировать. Перед критиками не стоят дедлайны, обязательства и прочее, не говоря об объеме работы, не висит усталость от предрелизной нервотрепки. А тут ещё и недовольные некстовцы. Трындеть - не мешки ворочать, найти неиспользованные байты - не упаковать код так, чтобы их можно было использовать. Если программист говорит, что свободных байт нет - значит, в его карте памяти их нет, с устоявшимися в голове структурами данных и процедурами. А оптимизировать почти всегда можно, а уж объемные проекты и подавно. Другое дело, что drbars может быть не до этого. Что-то мне подсказывает, что если бы он дал исходники, охотников до оптимизации резко поубавилось бы до нуля.
Мысль любопытная. По идее, чистые функции можно тестировать без эмулятора, то есть хотя бы юнит-тестинг можно себе представить. Но рантайм - штука сложная, тут прерывания, AY, такты - для интеграционных тестов нужен суперпроизводительный эмулятор, иначе тесты будут очень сильно упираться в скорость эмуляции. В общем, идея любопытная, но я, честно говоря, не слышал, чтобы кто-то в ретро её применял.
Поэтому да, руками проходили не раз. Может, не после прямо каждого билда от начала и до конца, но только я игру отыграл от и до раз пять, наверное. В среднем по полтора часа уходит, когда знаешь, куда идти.
какое автоматическое
доСИХ ПОР нет эмулятора который бы имел бряк счетчик
поставив который можно было бы подсчитать частоту срабатывания...
нет эмулятора который может сделать лог времени от начала фрейма до спецбряка
итд
я могу перичислять долго и нудно...
НО наконец ТО появился эмулятор в котором есть история выполнения
(точнее список выполненных адресов до) после срабатывания бряка
:v2_dizzy_turn: :v2_yahoo:
это в унриал от тс если чо
до этого было вообще
факт перехода мы поймали
но от куда он мать его произошел было неизвестно :v2_dizzy_facepalm:
кстати хороший пример русификации несжимаемого это dizzyV 48k.
тексты разжали/перевели/снова сжали + несколько русских букв
да ещё похоже несколько разных способов (от разных авторов)
https://spectrum4ever.org/download.p...ulltape&id=956
http://www.cxemateka.ru/v1/DIZZY_5r_48k.zip
да никого не чешет, что незабытые
так и на таблицу рекордов можно отвести 20 килобайт
а потом плакаться, что места нет и нечего ужимать
это проверяемо и считаемо
точно, килобайты - это копейки :v2_dizzy_facepalm:
а что с ней будет? хуже ужиматься она не стала)))
ради интереса визуализировал память по ширине тайлмапа
https://jpegshare.net/images/95/1b/9...7adab9ff4d.png
точнее снапшот
поэтому видимая последовательность страниц может быть левой
Я с Женей разговаривал по вопросу сжатия текстов. Говорит перепробовал уйму вариантов, остановился на оптимизированном lz. Сомневаюсь, что можно зажать еще сильнее (вернее не сомневаюсь что можно, сомневаюсь что это будет работать в условиях игры и спектрума в целом). В Диззи5 вроде какой-то несложный токенизатор и не особо оптимальный (поправь, если я ошибаюсь, я смотрел его очень давно и могло в голове смешаться с какими-то из старых частей), поэтому можно было например процедуру формирования словаря пооптимальней сделать и вот оно уже лучше упаковало.
правда тут используются спрайты почти на всю высоту в 64 пикселя
и автоматически использовать свободное место
при урезании размера тайлмапа
получилось бы только при помощи ADP (которого на тогда еще не было)
или нужно было хранить перевернутый на 90 градусов тайлмап (хотя если быть точнее тот что сейчас это перевернутый : )
возможно, лучше было бы организовать в высоту на 256 пикселей и ширину не доводить до 32, что-то распаковывая внизу
но это всё уже, конечно, чисто теория, ясно же, что радикально переделывать уже никто ничего не будет
тут найти хотя бы место для дисковой подгрузки и багофиксов, ужимая слишком жирные буфера
А есть какой-то вариант, который не потребует переписывания пол-движка? Вы не забывайте, что это не движок под графику делается, а наоборот: сначала оформляется движок общего назначения под универсальные задачи, а потом уже делается графика с учетом его возможностей. Такого, чтобы сначала сделать всю графику, а потом кодить под неё частные случаи, в большом проекте быть не может, это не демка. Хуже того, тут еще и графика поменяться может. Тогда опять движок подгонять под изменения придется, или как?
То есть, постфактум-то можно прикинуть, что какие-то части используются только на каких-то экранах, то есть их можно хранить отдельно упакованными, а весь тайлмап тогда пересобрать и уменьшить, но как вы себе представляете рабочий процесс? Сколько такая работа займёт лет? Десять? Кто будет рисовать в таких условиях? Сам разработчик, разве что, потому что художника шиза накроет, если понадобится такое сочинить.
В общем, фантазии в теории отличные, а на практике, имхо, игру так не сделать от слова совсем.
А, и еще: как быстро будет выводиться комната, если под каждую комнату надо будет распаковывать откуда-то свой набор графики? Сколько будет такая комната занимать места в памяти? Сейчас комната описывается окнами из спрайтмапа. А если не будет спрайтмапа, а графика будет упакованной, то как добиться необходимой гранулярности? Упаковывать всё мелкими кусочками отдельно? А откуда тогда выигрыш будет по месту?
например, очевидное - запаковать спрайты мобов и нужные декранчить при переходе
их размер небольшой и на скорости заметно не скажется, а в 7 странице можно место освободить
- - - Добавлено - - -
главное, чтобы это место нашлось хотя бы, перебросить же потом не проблема, данные игры уже не нужны
а может описываться теми же ссылками на тайлмап + адрес данных предварительной распаковки
в игре так-то несколько регионов, у которых большинство тайлов разные
часть тайлов была бы постоянной, а часть менялась бы
- - - Добавлено - - -
ты размеры этих спрайтов помнишь вообще?
- - - Добавлено - - -
три не пролетишь, только две
до
память насилуется хорошо
только первые несколько комнат
а уже практически все прочесано (про 1,2-е окно)
https://jpegshare.net/images/b6/3b/b...975a51577e.png