PSP рогалиг
Модератор: Jolly Roger
Re: [test] PSP рогалиг, нужно потестить
Aerton - ты чертовский прав!
Мало того, что всю память выделял под стек, так еще и требовал от ядра память. Ввиде маленьких кусков. В итоге, если выделять память динамический и кусками, то через некоторое время, когда выделенно около 1000 кусков... происходят странные вещи, память перестает выделятся (хотя система показывает что еще есть место). Aerton прав, у системы зызки есть лимит на количество выделяемых указателей на память.
Печально.
Тогда идем следующим путем.
Выделяем большой кусок памяти, и пишем свой менеджер.
Гуглим про распределение памяти, много чего есть. Но все както слишком монстрообразно. и непонятна...
У меня есть чудная библиотека (физическая). Достаем книжку Кнута "Исскуство программирования" глава "динамическое выделение памяти", там подробно описывается механизм работы с памятью.
Основная идея - хранить информацию не о используемой, а о свободной памяти.
Есть список, который описывает свободные блоки памяти, этот список, хранится в самом свободном блоке.
Узел списка состоит из двух полей "размер свободного блока" "указатель на свободный блок".
+ такого подхода, не нужна дополнительная память под массив, где хранится описание распределения памяти.
Мало того, что всю память выделял под стек, так еще и требовал от ядра память. Ввиде маленьких кусков. В итоге, если выделять память динамический и кусками, то через некоторое время, когда выделенно около 1000 кусков... происходят странные вещи, память перестает выделятся (хотя система показывает что еще есть место). Aerton прав, у системы зызки есть лимит на количество выделяемых указателей на память.
Печально.
Тогда идем следующим путем.
Выделяем большой кусок памяти, и пишем свой менеджер.
Гуглим про распределение памяти, много чего есть. Но все както слишком монстрообразно. и непонятна...
У меня есть чудная библиотека (физическая). Достаем книжку Кнута "Исскуство программирования" глава "динамическое выделение памяти", там подробно описывается механизм работы с памятью.
Основная идея - хранить информацию не о используемой, а о свободной памяти.
Есть список, который описывает свободные блоки памяти, этот список, хранится в самом свободном блоке.
Узел списка состоит из двух полей "размер свободного блока" "указатель на свободный блок".
+ такого подхода, не нужна дополнительная память под массив, где хранится описание распределения памяти.
- Aerton
- Сообщения: 503
- Зарегистрирован: 11 авг 2007, 02:58
- Откуда: Новосибирск
- Контактная информация:
Re: [test] PSP рогалиг, нужно потестить
Нет, не под стек. Это ты зарезервировал область памяти для выделения по malloc и new. Если в моём примере ты вставишь выделение нескольких мегабайт через malloc при малом размере PSP_HEAP_SIZE_KB, то оно обломится, если увеличишь - выделит.Yozka писал(а):Мало того, что всю память выделял под стек,
Это не особенность PSP, это стандартный подход, используемый почти везде.Yozka писал(а):если выделять память динамический и кусками, то через некоторое время, когда выделенно около 1000 кусков... происходят странные вещи, память перестает выделятся (хотя система показывает что еще есть место). Aerton прав, у системы зызки есть лимит на количество выделяемых указателей на память.
Печально.
Стандартная библиотека С (в данном случае newlib) при запуске программы просит у ядра кусок памяти через это же самый, размер которого ты указал в PSP_HEAP_SIZE_KB(), и когда ты вызываешь malloc и new она именно в нём и вырежет кусок.
Просто в "обычной" ОС начальный размер назначетсяч по умолчанию, и когда стандартной библиотке не хватает памяти для твоего malloc, она просит ещё один блок у системы. Но в linux всё это происходит незаметно для тебя, а на PSP надо указывать явно.
Об используемой памяти тоже надо хранить информацию, если нужна возможность не только выделения, но и освобождения памяти. В принципе, если тебе от менеджера памяти ничего особенного не надо, ты можешь использовать стандартный менеджер памяти, выделив в PSP_HEAP_SIZE_KB() побольше, и вызывая обычный malloc/new. Написание что-то получше потянет на самостоятельный проект в добавок к самой игре.Yozka писал(а):Основная идея - хранить информацию не о используемой, а о свободной памяти.
По картинке - я бы сделал побольше контраст между полом и стенами (цветом или яркостью), чтобы было лучше видно разницу.
Re: [test] PSP рогалиг, нужно потестить
Попробовал, сделал темнее. Стало чуть страшнее. Думаю, прикольно будет, чтобы нагнать страху на игрока (когда рядом сильный монстр) делать контраст высокий. Этакое "шестое" чувство. Чтобы у игрока акцентировалось внимание только на то что видет его персонаж.Aerton писал(а): По картинке - я бы сделал побольше контраст между полом и стенами (цветом или яркостью), чтобы было лучше видно разницу.
Сейчас силы брошены на менеджер памяти.
- Aerton
- Сообщения: 503
- Зарегистрирован: 11 авг 2007, 02:58
- Откуда: Новосибирск
- Контактная информация:
Re: [test] PSP рогалиг, нужно потестить
Неплохая идея, но надо и в нормальном режиме сделать разницу побольше. Возможно, придать немного цвета - кирпичи или, например, гранит не обязательно должны быть серго тона.Yozka писал(а):Попробовал, сделал темнее. Стало чуть страшнее. Думаю, прикольно будет, чтобы нагнать страху на игрока (когда рядом сильный монстр) делать контраст высокий. Этакое "шестое" чувство. Чтобы у игрока акцентировалось внимание только на то что видет его персонаж.
Я понял, чем мне не нравится пол: он состоит из мелких, чётких деталей, которые отвлекают на себя внимание. Предметы и понстры будут теряться на этом фоне. Стены в этом плане лучше - они из более крупных кирпичей и их грани не такие резкие. Интересно, как будет, если поменять текстуру пола и стен. Подсветку от LOS можно сделать слегка жёлтой или красноватой, чтобы было как от факела, а не от лампочки.
Так чем тебя стандартный не устраивает?Yozka писал(а):Сейчас силы брошены на менеджер памяти.
Re: [test] PSP рогалиг, нужно потестить
Прошло много времени.
Сделано много.
Переделано еще больше.
---
Перешел на linux, ибо на моем рабочем ноуте винда со средой программирования code::blocks еле шевелится.
Сделано много.
Переделано еще больше.
---
Перешел на linux, ибо на моем рабочем ноуте винда со средой программирования code::blocks еле шевелится.
мы дальше копаем ямы
Итог работы:
Запустил монстров, с интеллектом "идем по стеночке".
Возникла проблема. Когда монстров стало чуть более тысячи. Сохранение и подгрузка уровней стало безбожно тормозить.
Как сделано сейчас:
Есть в игре объект, который может сохранять себя в файле, этим объектом может быть монстр, лестницы, стрелы. итд. У этого объекта, при создании присваиваться уникальный идентификатор. Идентификатор служит в качестве метки в файле.
--
Структура файла, в котором сохраняют себя объекты представляет собой связанный список секций.
Первая секция находится в начале файла
Далее в поле dwAddressNext находится адрес в файле где записанна следующая секция. Так как эти адреса "плавают" то следующая секция может находится в любом месте файла.
Этот механизм прекрассно работает. Но при добавлении удалении объектов секций происходит жуткая дефрагментация файла. Что в конечном итоге приводит к снижению скорости. Теперь думаю над тем, чтобы хранить информацию не списком, а в виде дерева, тем самым увеличится скорость.
----
Рисую спрайты.
Сделал анимацию.
Камера двигается более плавно.
Столкнулся со следующей проблемой.
Во время анимации теряется цветность (из за инертности экрана) приходится подгонять цветовую палитру спрайтов.
Также к спрайтам добавил альфаканал.
----
Вобласти игровой механики.
Базовый класс монстров может перемещатся по лестницам. ЧТо они успешно и делают.
----
Полностью перелапатил управление.
Сделал как тут советовали, при зажатии "квдрата", стрелками можно двигать героя. При зажатии "крестика" стрелками уже делаются действия, такие как спустится по лестнице, взять осмотрется, подождать итд. Получилось ооочень удобно.
Запустил монстров, с интеллектом "идем по стеночке".
Возникла проблема. Когда монстров стало чуть более тысячи. Сохранение и подгрузка уровней стало безбожно тормозить.
Как сделано сейчас:
Есть в игре объект, который может сохранять себя в файле, этим объектом может быть монстр, лестницы, стрелы. итд. У этого объекта, при создании присваиваться уникальный идентификатор. Идентификатор служит в качестве метки в файле.
--
Структура файла, в котором сохраняют себя объекты представляет собой связанный список секций.
Первая секция находится в начале файла
Код: Выделить всё
struct
{
DWORD dwID;//идентификатор объекта.
DWORD dwType;//тип класс объекта
DWORD dwAddressNext;//указатель на следующий объект в файле
DWORD dwAddressProperty;//данные объекта
}
Этот механизм прекрассно работает. Но при добавлении удалении объектов секций происходит жуткая дефрагментация файла. Что в конечном итоге приводит к снижению скорости. Теперь думаю над тем, чтобы хранить информацию не списком, а в виде дерева, тем самым увеличится скорость.
----
Рисую спрайты.
Сделал анимацию.
Камера двигается более плавно.
Столкнулся со следующей проблемой.
Во время анимации теряется цветность (из за инертности экрана) приходится подгонять цветовую палитру спрайтов.
Также к спрайтам добавил альфаканал.
----
Вобласти игровой механики.
Базовый класс монстров может перемещатся по лестницам. ЧТо они успешно и делают.
----
Полностью перелапатил управление.
Сделал как тут советовали, при зажатии "квдрата", стрелками можно двигать героя. При зажатии "крестика" стрелками уже делаются действия, такие как спустится по лестнице, взять осмотрется, подождать итд. Получилось ооочень удобно.
Re: PSP рогалиг
Постарайся организовать данные так, чтобы для одного сохранения/загрузки требовалась ОДНА (ну максимум 2-3) операция с файлом (чтение/запись), а остальное все - в памяти. Не пожалеешь .)
Re: PSP рогалиг
В идеале этоб былоб замечательно, одна загрузка, одно сохранение. Я не индус, понимаю что сем меньше мы дергаем файл, то тем больше скорости. Но я немогу загрузить весь файл целиком в память. Ибо файл где хранятся все уровни (порядка 1000 (генерятся автоматический(рогаликже))), все игровые объекты (200(примерно)) в уровнях будет размером в 200 мегов... это чуть больше чем дохрена. вот и нужен механизм, в котором в памяти хранятся только некая индексная информация по которой идет работа с файлом.Anfeir писал(а):Постарайся организовать данные так, чтобы для одного сохранения/загрузки требовалась ОДНА (ну максимум 2-3) операция с файлом (чтение/запись), а остальное все - в памяти. Не пожалеешь .)
Re: PSP рогалиг
Может быть, процесс можно ускорить, если в процессе игры каждый уровень будет храниться в отдельном файле, а при сохранении-выходе все они будут объединяться в один целый. (Кажется, так в Nethack сделано?)
- Aerton
- Сообщения: 503
- Зарегистрирован: 11 авг 2007, 02:58
- Откуда: Новосибирск
- Контактная информация:
Re: PSP рогалиг
Я что-то тоже не сильно понял - ты диск как память чтоли используешь?
Да и DWORD в качестве указателя... Может уж тогда проще mmap() использовать и нормальные указатели? Или индексы, чтобы перезапуск порогаммы переживали.
И опять же, в памяти ни к чему хранить больше текущего уровня + пара соседних. Ведь если уж держать в памяти данные, то надо с ними что-то делать, или для чего они место занимают.
Да и DWORD в качестве указателя... Может уж тогда проще mmap() использовать и нормальные указатели? Или индексы, чтобы перезапуск порогаммы переживали.
И опять же, в памяти ни к чему хранить больше текущего уровня + пара соседних. Ведь если уж держать в памяти данные, то надо с ними что-то делать, или для чего они место занимают.
Re: PSP рогалиг
Спасибо за совет. Даже както и не подумал об этом. Почемуто решил, что пофеншую все должно быть в одом файле... Меня смущает только одно, это но тыща файлов в одном каталоге. незнаю как PSP в такой ситуации себя поведет, надо будет попробовать.Newman писал(а):Может быть, процесс можно ускорить, если в процессе игры каждый уровень будет храниться в отдельном файле, а при сохранении-выходе все они будут объединяться в один целый. (Кажется, так в Nethack сделано?)
Re: PSP рогалиг
1000 карт для рогалика... Не многовато ли? Учитывая, что игрок скорее всего умрет где-то на третьей. В том же нетхаке карты генерятся по мере их достижения и потому в начале игры сейвы короткие, а в конце - длинные.
Re: PSP рогалиг
Да, карты кешируются на диске. Я их физический немогу держить в памяти, мне место нехватит. Карты которые не используются, выгружаются на диск, вместе с потрохами, объектами итд. Тоесть выгружается сам контент карты. Самаже "объект карта" сидит в памяти. Далее, когда герой пришел на карту, дергается у карты метод loadContent() и идет собственно загрузка карты из диска.Aerton писал(а):Я что-то тоже не сильно понял - ты диск как память чтоли используешь?
Да и DWORD в качестве указателя...
Уточнение, "указатель" в файле, вернее сказать позиция в файле относитлеьно начала. Указатели на объекты в файле несохраняются, чеж их хронить то, ониж всегда разные
Для индификации карты (и нетолько карт а вообще всех объектов) использую
индексы, чтобы перезапуск порогаммы переживали.
Тут еще такой момент, пока я незнаю какие у меня будут объекты, мне неизвестна их структура. Соответственно, я немогу сделать типизированный файл. Тоесть получается что в файле хранится не только сама информация, но и внутрення структура объекта.
Да, у меня есть некий менеджер кешируемых карт. Он отдает задания на загрузку и выгрузку карт. также отдает игровому процессу все активные карты. Зачем это все?И опять же, в памяти ни к чему хранить больше текущего уровня + пара соседних. Ведь если уж держать в памяти данные, то надо с ними что-то делать, или для чего они место занимают.
Все дело в гемплее... у меня уже реализованно, несколько героев. Тоесть можно одновременно управлять несколькими героями, которые могут находится на разных картах. Соответсвенно эти карты должны всегда находится в памяти. При этом, соседние карты тоже находятся в памяти, чтобы там протекала жизнь.
Re: PSP рогалиг
Для теста взята цыфра 1000. Это максимум. В реале, будет ну 160 уровней, может 300 неболее. 1000 это предел для теста. ЧТобы я точно знал, что при 300 карт у меня небудет проблем.kipar писал(а):1000 карт для рогалика... Не многовато ли?
---
меня подламывает накрутить на рогалик всяких вкусностей, там инвентарь монстров атакующих итд. нннооо блин нужно доделать сам скелет игры. остальное попрет.
- Aerton
- Сообщения: 503
- Зарегистрирован: 11 авг 2007, 02:58
- Откуда: Новосибирск
- Контактная информация:
Re: PSP рогалиг
Если игра всё ещё планируется под PSP, то постоянно что-то записывать в файлы - это абсолютно неприемлемое поведение для программы. Либо отказывайся от сохранения всех уровней, либо от этой системы.
Посмотри на powder - она расчитана на гораздо более слабое устройство. Да и все классические роглайки делались в своё время для компьютеров, которые почти по всем параметрам были слабее PSP.
Так ли уж нужны эти сотни пустых карт, возвращаться на которые у игрока нет почти никакого резона?
Посмотри на powder - она расчитана на гораздо более слабое устройство. Да и все классические роглайки делались в своё время для компьютеров, которые почти по всем параметрам были слабее PSP.
Так ли уж нужны эти сотни пустых карт, возвращаться на которые у игрока нет почти никакого резона?
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 49 гостей