Just another roguelike game -- survival с зомби и прочей нечистью в жестокой атмосфере с радио GhostBox на фоне. Крафт, модульные автомобили, бионика, псионика, мутации, болезни. Города, дороги, заброшенные и не очень базы, поиск еды и лекарств, оружия и патронов. Вот про все это будет наш рогалик. (Opensource проект, C#, Python, XNA->Monogame)
Ууу..... зачеееммм???? Неужели тебе важнее каких то там пару килобайт, по сравнению с затратой времени на упаковку и распаковку строк? Строки очень плохое решение.
Во-первых затраты на хранение снизились не на пару килобайт, а на 69 килобайт или в 100 раз. Во вторых сериализация -- это отдельный метод, сделать двоичную сериализацию никто не запрещает. В-третьих, скорость упаковки\распаковки не слишком важна, все равно гораздо больше времени уйдет на ожидание ответа сервера да и происходит распаковка на фоне.
P.S. Накладные расходы на строку -- 14 (26 для x64) байт, плюс до 4 байт на выравнивание.
P.P.S. Также стоить добавить, что все Id -- это интернированные, во время загрузки базы блоков, строки.
Кст, если мне не изменяет память, то хэш структуры занимают много памяти. Тобишь ты сам себе противоречишь. Одно место оптимизируешь по памяти в ущерб времени, другое наоборот...
Был бы рад узнать решение для разреженного массива неограниченного размера, лучше, чем хеш-таблица
К слову, какие-то пару килобайт выходили в ограничение по памяти для приложения где-то за пол часа.
Замерил время на сериализацию\десериализацию: UnstoreSector TotalMilliseconds = 1.0504 (в основном из-за выделения памяти, пул секторов сократит это время тоже до 0.25 мс), StoreSector TotalMilliseconds = 0.2683, на ноутбуке 7ми летней давности
К слову, адресация происходит по hash пары координат {x, y}, так что сложность поиска в любом из списков O(1)
Кст, если мне не изменяет память, то хэш структуры занимают много памяти. Тобишь ты сам себе противоречишь. Одно место оптимизируешь по памяти в ущерб времени, другое наоборот...
И вообще. Преждевременная оптимизация корень всех зол
Вместо хранения секторов в виде экземпляров класса MapSector было выбрано хранение в виде строки, в сжатом виде. Сначала для каждого списка (блоков, полов, юнитов) формируется словарь, чтобы обозначать длинные идентификаторы одной цифрой, затем они сжимаются при помощи RLE (крайне успешно). В результате затраты на хранение сектора снизились с 70KiB, в среднем, до 800 B, а также полностью отпала необходимость подготовки секторов к сохранению на диск.
Ууу..... зачеееммм???? Неужели тебе важнее каких то там пару килобайт, по сравнению с затратой времени на упаковку и распаковку строк? Строки очень плохое решение.
От пользователей портала sc2tv поступило предложение провести серию стримов на twitch и sc2tv по написанию рогалика. Не совсем ясно с формой: либо ответы на вопросы по программированию, либо совместное создание контента. Что скажете на этот счет? Если кому-то интересно, то какие рекомендации по форме исполнения.
возможно сначала стоит порассказывать,на какие грабли встал в самом начале,описать распространенные ошибки и описать некоторые хитрые плюшки,позволяющие делать быстро и качественно
потом можно поотвечать на интересные вопросы из чата
дальше хз)
JARG
Комментарии проекта JARG
Мысли о с++ glew+glfw
Работа с секторами карты в JARG
Ред. Pray_AD
P.P.S. Также стоить добавить, что все Id -- это интернированные, во время загрузки базы блоков, строки.
И вообще. Преждевременная оптимизация корень всех зол
Нужен ли стрим?
потом можно поотвечать на интересные вопросы из чата
дальше хз)
JARG