Извините, ничего не найдено.

Halk-DS · 04.10.2011, 23:11

Не могу создать большой массив. Мне выдает Memory acces violation
Большой это: 1000х1000х1000
Если беру 1000х1000х300 то все делается ок, только оч долго прога грузится. Ну в принципе я понимаю что это 300 млн. значений.
Это какое то ограничение в блитсе или природа сей ошибки неизвестна?

Mr_F_ · 04.10.2011, 23:20

даж если бы у тебя 1 ячейка занимала 1 байт, то это выходит 1000*1000*1000 = 1000000000 = 976562.5kb = 953.67mb.
но ячейки скорее всего больше 1 байта.
у тебя просто оперативки не хватает.

Halk-DS · 04.10.2011, 23:43

А каг тогда хранить информацию? Оо
Полюбому должен быть способ. Много игрушек есть похожих с подобных построением ландшафта.

Mr_F_ · 04.10.2011, 23:47

нотч не настолько ещё говнокодер чтобы такие массивы создавать.
у него мир из чанков 256х16х16
пруф: http://www.minecraftwiki.net/wiki/Chunks

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

RBK · 04.10.2011, 23:56

Почитай эти статьи: Дерево (структура данных) и Октодерево

Mr_F_ · 04.10.2011, 23:58

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

RBK · 05.10.2011, 00:13

Согласен, элементы будут храниться на диске, в память будет загружен небольшой фрагмент. Октодерево поможет этим правильно управлять.

Halk-DS · 05.10.2011, 01:43

Сообщение от Mr_F_

нотч не настолько ещё говнокодер

Некрасива говнокодером обзиватся

Я просто спросил что не знал.
Спасибо за подсказки. Уже есть вопросы, но сначала прочитаю ссылки.

Halk-DS · 05.10.2011, 02:24

RBK я понял что ты хотел сказать что то важное, но прости, я этого не понял. Понял только то что мне нужно хранить инфу в виде октодерева. То есть ячейки с 8 чилдами. Но я даже не представляю как это сделать без массива. (была идейка как то использовать для этого типы, но походу бред)

Насчет чанков:
Если создать файл с информацией о ландшафте. И пусть он даже бесконечно большой, но одновременно загружено чанков в память будет припустим 441 как у Нотча(это кстате 14,5млн ячеек в массиве). Во время перехода с одного чанка на другой мне придется часть чанков что за областью зрения выгружать, а другую часть подгружать. Что сделают большие рывки во время игры. Я конечно знаю что в мморпг есть какой то отдельный буфер в котором подгружаются все текстуры и меши во время игры не влияя на фпс(на норм машинах), но помойму в блитсе еще такого нету...

Как же хранить и подгружать инфу о больших ландшафтах вроде того как это делал нотч но на блитсе? Очень помогло б без кода описать сам принцип словами и примерами. Заранее сенк

Mr_F_ · 05.10.2011, 02:36

Что сделают большие рывки во время игры.

кстати в майне они заметны

Как же хранить и подгружать инфу о больших ландшафтах вроде того как это делал нотч но на блитсе?

либо в фоновом потоке (незя в блице), либо по маленьким порциям за кадр.

Halk-DS · 05.10.2011, 03:01

Спасибо. Теперь ясно. Но походу геморно ппц.

RBK · 05.10.2011, 16:03

Сообщение от Halk-DS

RBK я понял что ты хотел сказать что то важное, но прости, я этого не понял. Понял только то что мне нужно хранить инфу в виде октодерева. То есть ячейки с 8 чилдами. Но я даже не представляю как это сделать без массива. (была идейка как то использовать для этого типы, но походу бред)

Можно и в типах, например:

Type material

field mesh ;сетка загружаемого мира, работать лучше с поверхностями.
field surface ;собственно поверхность
field p1, p2, p3, p4 ;вершины квада поверхности

field brush ;кисть которой закрасим поверхность

;другие переменные 
End Type

Type node

field x,y,z ;координаты узла

field FrontNode.node ;соседние узлы
field BackNode.node
field LeftNode.node
field RightNode.node
field TopNode.node
field BottomNode.node

field FrontMaterial.material ;поверхности этого узла
field BackMaterial.material
field LeftMaterial.material
field RightMaterial.material
field TopMaterial.material
field BottomMaterial.material

;другие переменные
End Type

Но мне больше нравится вариант с использованием банков. ReadBytes позволяет загружать блок информации любого размера прямо из файла.

Сообщение от Mr_F_

либо в фоновом потоке (незя в блице), либо по маленьким порциям за кадр.

Не совсем точно, фоновый поток нельзя сделать командами блица, но можно загрузить DLL библиотеку, которая загрузит всё хоть в десять потоков.

Как создать dll библиотеку для блица в PureBasic(спасибо MadMedic за статью)

P.S. для тех кто хочет повозражать, "бдиц устарел(другие варианты)", вопрос был:

Сообщение от Halk-DS

Как же хранить и подгружать инфу о больших ландшафтах вроде того как это делал нотч но на блитсе?

Igor · 06.10.2011, 01:03

Вроде в майне чанки хранятся в сжатом виде в папочке игры. А вообще, имхо, разумнее сделать алгоритм генерации зависящим от координат чанка, и если его никто не меняет - то и не сохранять. (тогда не будет проблем с ушедшими на 100500 далеко игроком)

LLI.T.A.L.K.E.R. · 06.10.2011, 15:50

Но тогда скорее всего мир будет меняющимся..
Допустим игрок ушёл далеко - нашёл что-то особое в этом месте. Но ему нужно возвратиться (чтобы освободить инвентарь), а потом опять идти к тому месту.
Но мир уже перегенерировался..

Igor · 06.10.2011, 22:22

Но мир уже перегенерировался..

нужна функция, которая имеет входные данные - координаты чанка и зерно карты. Результат (собственно чанк) зависит только от них, и при новой генерации мир останется таким же.
А если игрок начнёт что-то строить, уже ничего не поделать - сохранять изменённый чанк и тратить память