Корованы грабить можно будет? ;)
Вид для печати
Корованы грабить можно будет? ;)
ИМХО, самое оно. Всё же на асме, и данные хранятся экономно - байты и биты.
На карте будут хранится только типы местности (штук 6), видимость/невидимость клетки (1 бит), занята/не занята (1 бит), тип дороги (грунтовая, автомобильная, ж.д.). Можно уместиться в 5-6 бит на клетку. Координаты и данные каждого юнита и каждого здания для каждой цивилизации хранятся в отдельных списках, так экономнее и легче обрабатывать. Если карта 6 бит на клетку 256х192 клеток, то будет всего 36864 байта.
А если еще поиграться флагом море/суша, а также только сушу кодировать, то еще можно сэкономить.
Города на практике так и будут по 20-30 зданий, больше не будет смысла их строить. Хотя ничего не будет мешать.
---------- Post added at 14:55 ---------- Previous post was at 14:54 ----------
Age Of Empires - я когда-то на нее смотрел. Но не понравились магии всякие, не реально.
---------- Post added at 14:56 ---------- Previous post was at 14:55 ----------
естественно. Чужие обозы с ресурсами будут сновать :)
А что, была пошаговая Дюна? Я имел в виду именно переход TB->RT, X-COM 3 - как пример.
С 48к я конечно просчитался, карта ещё нужна.
Насчёт отдельных списков для относительно редких объектов на карте - согласен.
>видимость/невидимость клетки (1 бит), занята/не занята (1 бит), тип дороги (грунтовая, автомобильная, ж.д.)
А вот такого наверное следует избегать. От массива видимости наверное не избавиться, если только не хранить его в RLE. Занятость определять можно и по содержимому, а типы дороги в отдельный список дорог.
Но чтобы сделать оптимально, надо сначала определиться с перечнем того, что вообще будет встречаться на карте =)
у меня есь наброски для платформера -идея
была вследущем, для экономии места под уровни. может оно и старо как мир.
описание локации идет слоями .
например cтена кирпичная
Layer1
dw adr_spr
dw х
dw y
int repr_count
int w
int l
int page
10 байт для описания стены адцать на адцать
соответсвенно можно порезать еще и длину ширину если заранее известно
и страницу тоже
дальше на ту же стену в других координатах
только
координаты и количество повторов.
.....
....
Layer1_single
одиночные спрайты
...
...
Layer2_mask
спрайты накладываются по маске на слой 1
итд
все это парсится и строится в виртуальном экране 12кб
соответсвеноо в какойто странице процедура вырезания фона и буфер под них.
и кидается на екран пушом попом
досточно быстро но очень мало нижней памяти остатся
заманаешся шелкать страницами-собственно на диспетчере ресурсов проект и заглох.
для описания фона сверху не изометрии нормально
можно хронить много пейзажей городов и тд без дозагрузки .
Если речь про пошаговую стратегию, то нафига эти виртуальные экраны и пуши-попы. Только память тратить.
Карта будет очень разнообразная, поэтому блоки из одинаковых спрайтов - крайне редки.
Да и вообще, не думайте этими чёртовыми картинками. Не надо страдать болезнью конца 90х. Картинка хранится один раз в одном месте, а на нее только двухбайтовые ссылки из любых мест.
Юнит или здание полностью описывается буквально 8-12 байтами. Ссылается на таблицу типов юнитов/зданий, у которой свои параметры 8-12 байт на строку. А таблица типов ссылается на конкретные спрайты. Это такое ООП - если кто не понял.
---------- Post added at 15:59 ---------- Previous post was at 15:49 ----------
Занятость по содержимому - это значит бегать по всем спискам юнитов и зданий. Для пошаговки, наверно, нормально. А для RTS плохо.
Дороги в отдельных списках - это хорошо. Тогда легче будет писать алгоритм нахождения пути!
Andrew771, хозин барин
задчи разные в моем случае, я не хотел каждый раз строить фон, сделать его максимално нассыщенным и детализированым, запихать как можно больше его в память.
поэтому блоки из одинаковых спрайтов - крайне редки.
Дико например хочу посмотреть как будет реализвана разная трава, разный песок, разный лес, разная вода, разные дороги -это площади с одинаковыми спрайтами.
ну не суть вообще прожект интерецный будем пацматреть.
>>Занятость по содержимому - это значит бегать по всем спискам юнитов и зданий.
Не, по всем не надо бы. Идея в том, чтобы хранить статическую карту(море/земля/лес/горы), а на ней динамические объекты - юниты, города, дороги и пр. Ландшафт, я надеюсь, ты чем-то ядрёным изменять не собираешься? =) Вот в таком случае, идёт только проверка на наличие объекта, а потом его типа.
NovaStorm, во во я вообщем то о томже
И сколько же тогда будет занимать один элемент карты, если идет ссылка на каждый юнит? И зачем это? Всё равно обрабатывать каждый юнит за ход, так можно и по списку бегать. А занятость/не занятость клетки нужна только для определения, можно пройти или нет, и больше не для чего.