VPF::Карта для игры - Форум программистов

regis

Дата 10.5.2006, 14:31 (ссылка)

(нет голосов)

Загрузка ...

Бывалый

Профиль
Группа: Участник
Сообщений: 232
Регистрация: 12.12.2005
Где: Москва, Россия

Репутация: нет
Всего: 7

Неужели действительно нужна карта ТАКОГО размера?
И насколько она будет заполнена в реальности? Если достаточно редко -- не лучше ли попробовать "разреженную" матрицу для реализации?

--------------------

В. В чем разница между hardware и software?О. В отличие от второго, по первому можно двинуть кулаком или пнуть ногой.

ALKS

Дата 10.5.2006, 14:45 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 354
Регистрация: 22.3.2006

Репутация: 1
Всего: 11

вот-вот. смысла резирвировать кучу памяти для зон непроходимых гор и непереплываемых рек. или для зон полностью заполненных однотипным лесом. лучше описывать границы зоны и не каждую клетку. памяти можно здорово съэкономить.

Stampede

Дата 10.5.2006, 22:09 (ссылка)

(нет голосов)

Загрузка ...

Гносеолог

Профиль
Группа: Участник Клуба
Сообщений: 963
Регистрация: 25.4.2005
Где: Calgary, Alberta, Canada

Репутация: 24
Всего: 144

Цитата(LSD @ 7.5.2006, 03:15

)

Я бы использовал MappedByteBuffer на 64-bit машине с оперативкой не менее 4Гб. Мы не требуем от данных постоянно находится в памяти, но при этом если памяти хватает ОС будет держать эти данные в памяти. И плюс распологать данные в файле так, чтобы соседние ячейки имели близкие адреса, например квадратами 64х64. Для расчета движения вся карта не нужна, а вот соседние ячейки понадобятся.

LSD дело говорит. Только я бы маленько развил идею. Тебе нужне абстрагировать представление карты от формата хранения, примерно в виде такого интерфейса:

Код


public interface FieldMap {
  public long get(int x, int y);
  public void set(int x, int y, long val);
}

А потом написать, скажем, файловую реализацию:

Код


public class FileFieldMap implements FieldMap {
  private String fileName;

  public FileFieldMap(String fname) {
    fileName = fname;
  }

  public long get(int x, int y)  {
    Block block = getBlock(x, y);
    return block.get(x, y);
  }

  public Block getBlock(int x, int y) {
    // тут ты вычисляешь номер блока, которому принадлежит точка,
    // смотришь, нет ли данного блока в кэше (типа LRU), подгружаешь
    // при необходимости с диска (вычисляешь физическое смещение в файле)
    // и возвращаешь готовый объект типа Block - описатель квадратной
    // области карты
  }
}

Если сделаешь такую штуку, да экспериментальным путем подберешь оптимальные размеры блоков и размер кэша блоков - то у тебя все будет летать почти так же быстро, как если бы ты все хозяйство держал в памяти.

А после этого можешь над всем этим сделать надстройку в виде описателей зон произвольной формы, что предлагал ALKS. Но сначала - поточечный интерфейс к физической среде хранения. Тогда уже будешь чувствовать себя как в танке smile

Это сообщение отредактировал(а) Stampede - 10.5.2006, 22:10

--------------------

"If you want something done right, do it yourself"
По секрету: выучить английский - реально!

arts80

Дата 12.5.2006, 10:28 (ссылка)

(нет голосов)

Загрузка ...

Новичок

Профиль
Группа: Участник
Сообщений: 7
Регистрация: 25.4.2006

Репутация: нет
Всего: нет

спасибо, буду рассматривать каждый вариант отдельно, что потому получиться покажу :_)

1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Java: Общие вопросы \| Следующая тема »