А ёп-тыть... Шо, 1000000 элементв по сто раз за время создания карты ПОЭЛЕМЕНТНО копировать?! Блин, придёццо моск напрячь, да шо-нить придумать... Ну, типа, что-то вроде "присвоение неподходящего значения"...

_________________
Сообщество креативных механоидов:
aim-fans.ru

2 Шаман
А ты как хотел?
А в васике разве можно копировать так? Вроде это практически во всех языках "общего назначения" нельзя вот так прям сразу сложные типы данных копировать.

ага, нельзя. Тут через цикл нужно.

Добавлено спустя 50 секунд:

Во чё нашёл:

Как быстро скопировать содержимое одного массива в другой

Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, ByVal ByteLen As Long)

Private Sub Form_Load()
Dim a(10) As Integer, b(10) As Integer
a(5) = 10
Call CopyMemory(b(0), a(0), 22)
MsgBox b(5)
End Sub

Добавлено спустя 23 секунды:


тока на Си переписать надо

_________________
Земля, Земля - я Юпитер!
Зарисовка в стиле AIM - https://www.youtube.com/watch?v=JiWtIz9g3Uw

Так не в голом же Васике, а в Ехселе! Там просто блок ячеек на листе копируешь, да и сё. Э-э-э... Ну, я лучше просто циклом задам каждый элемент одной матрицы приравнять каждому элементу другой аналогичной матрицы.

Ошибку на приравнивание матриц одинакового типа и размера (dmapcur = dmap;) пишет такую: "Lvalue required".

Если задать построение на карте "х" главных горных цепей, то приравнивать эти матрицы в процессе построения рельефа нужно будет "2х" раз. В принципе, я придумал способ, как обойтись без этого. Но:
1) код незначительно увеличится;
2) максимальное количество гор главной цепи будет лимитировано (ну, лимит-то мы можем задать какой хотим, но только, как и размеры карты, до компилляции, а во время работы ЕХЕ-шника ничего уже не изменишь ). Но всё равно, копировать "поэлементно" придётся столько элементов, сколько гор в главной цепи, хотя их число уже и не так пугающе, как количество ячеек приравниваемых матриц.
Как лучше поступить?
а) Приравнивать матрицы поэлементно:
"-": элементов в матрицах столько, сколько точек на карте;
"-": размер занятой оперативки для хранения всех матриц равен: ([количество точек высот на карте] * 6) байт;
"+": поэлементное приравнивание матриц просто осуществить;
б) Придумать другой способ, отказавшись от второй матрицы:
"-": придётся установить максимум количества гор главной цепи;
"-": код чуть-чуть усложниться, плюс мне мозгопарьство ;
"+": размер занятой оперативки для хранения всех матриц равен: ([количество точек высот на карте] * 5 + [максимальное количество гор главной цепи] * 4) байт, т.е. это максимум на 17% меньше, чем при варианте с поэлементным копированием огромных матриц;

Я вот как думаю: если на поэлементное копирование матрицы размером 10000х10000 (100*10^6 элементов) проц частотой в 2ГГц (это 2*10^9 операций/сек) затратит менее 1 секунды, то лучше поэлементное копирование. Если больше, то стоит погнаться за ~15% оперативы и парусекундным временем процессора. Как Вы думаете, за сколько времени вышеописанный проц скопирует поэлементно матрицу размером 10000х10000 циклическим методом?

_________________
Сообщество креативных механоидов:
aim-fans.ru

А что такого?

_________________
Земля, Земля - я Юпитер!
Зарисовка в стиле AIM - https://www.youtube.com/watch?v=JiWtIz9g3Uw

Так-с, посчитаем. Присваивание - простая операция - выполняется за 1 такт процессора. Их надо будет сделать 10^8 раз. Пусть для осуществления внутреннего цикла нам потребуется в 5 раз больше операций(увеличение счетчика - 1 такт, проверка счетчика - 3 такта, переход в начало цикла - 1 такт). Для осуществления внешнего - 50000 операций - исходя из того же расчета. Итого - 6*10^8 + 5*10^4 - меньше, чем 2*10^9. Займет чуть больше чем 0.3 секунды.

интересно, а как эта штука работает? Теми же циклами?

2 grifon: спс.
Ну, тогда решено: буду копировать матрицы поэлементно без геморроя.
Даю анонс: если геморройных багов не обнаружиццо, завтра выложу свой А.Г.Р. в ЕХЕ-шном виде.

Добавлено спустя 4 часа 38 минут 29 секунд:

Мдя, ваще офигел от конкретнейшего галюна С++... Ща объясню.
Есть такая функция, как "random(int x)". Возвращает рандомное целое число от 0 до "х-1". Но вот мне понадобилось получить НЕцелое рандомное число, в пределах от 0 до 1 с точностью до сотых. Так что, понятное дело, я написал так: "random(101) / 100". И потом долго не мог понять, в чём дело. Вместо всяких там чисел подобных "0,39", я получал только "0" либо "1", причём чаще всего "0". Долго не мог понять, в чём дело, но оказалось, что (хрен пойми почему!) если написать "random(101) * 1 / 100", то есть разделить рандом-функцию и значок деления каким-нить множителем, то баг исчезает, и результат получается требуемый. Ну не бред ли, а? В общем, делюсь, блин, опытом. С++... Вот отстой... А мы ещё на разработчиков бочки катим, что в Мехах галюнов стока... Молодцы они - умудриццо на лажовом языке такую цацу написать!..

З.Ы.: кажысь, анонс придёццо отложить - хоть ошибок во время работы и не выдаёт, но и не делает ничего! Карту выдаёт пустую. Вот щас каждую строчку тестаю. Поди пойми что да где не так, если везде будет что-нить подобное вышеописанному...

_________________
Сообщество креативных механоидов:
aim-fans.ru

Дело, видите-ли, в том, рандом возвращает целое число. И 100 - целое число. Поэтому косая черточка интерпретируется как целочисленное деление с отбрасыванием остатка. А когда ты умножаешь целое число на еденицу, результат скорее всего приводится к типу float и все пучком. Ты попробуй еще вот так сделать:
((float)random(101))/100. Должно прокатить.

2 Шаман, если бы С++ был таким плохом, то на нём не програмировали игры!

Добавлено спустя 1 минуту 17 секунд:

И вообще, не делали бы серьёзные проекты.

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Бред С++ не имеет границ!!! Пишу:
a/(b + 1)*6.2832 - 1.5708
И результат всё время выдаёт одинаковый: "-1.5708"
Переставляю в записи местами делитель и множитель:
a*6.2832/(b + 1) - 1.5708
И тогда считает правильно.
Ёп-тыть, да что за бред?! Потом ещё, может, окажеццо, что "от перемены слагаемых сумма меняется?!"
Ребят, скажите, это глюк моего С++, тупость Страуспупа (ИМХО, фамилия подходящая ), или я какой-то тайны дебильного синтаксиса С++ ещё не знаю?
Да я не спорю. Но знаешь, после человеческого Васика сразу такое впечатление...
Да ё моё!!! А для обычного деления, БЕЗ ИЗВРАЩЕНИЙ, есть какая-нибудь другая нормально-работающая "чёрточка"?!
Блин, если в Васике я мог читать код, и сразу представлять во всех мелочах его работу, ловить баги даже не проверяя код в работе, а просто пробегая глазами по коду, то в С++ мне приходится каждую строчку, каждую переменную проверять отдельным встроенным кодом!!! Ну и геморрой, ну и геморрой с этим С++!!! Нормальных слов нет - за пару часов достал уже донельзя!!! Нахрена делить число с остатком, если я этого не указал отдельно? Что он мне за "услуги" такие, блин, нахрен никому не нужные, оказывает?
Фух... Ну так как, есть в С++ "чёрточка" для обычного деления?

_________________
Сообщество креативных механоидов:
aim-fans.ru

Сейчас проверил - что-то у меня вообще не пашет... А пример тот работает. Копирует один массив в другой

_________________
Земля, Земля - я Юпитер!
Зарисовка в стиле AIM - https://www.youtube.com/watch?v=JiWtIz9g3Uw

Пиши на "асемблере"...............

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Раз уж нет способа заставить С++ делать именно то, что от него хотят, то объясни, плиз, чё это, и с чем это кушать? Т.е. перед числом можно в круглых скобках пояснять, какую его типовую интерпретацию использовать для расчёта?
З.Ы.: в мануале не описан данный геморрой. Но зато для тобою описанной истории с делением интовых чисел и возвращением остатка от деления, в мануале говорится про использование не оператора "/", а "%". Так что не знаю - мож мой компиллятор глючный...

_________________
Сообщество креативных механоидов:
aim-fans.ru

2 ШаманПоробуй Pascal. Исходники обладают, наверное уникальным, свойством читабельности в отличие от С++. Синтаксис проще так точно.

_________________
Тока тока тока МАК.... токамак! Краааасный клаааасный мааак! )

/ - деление с отбрасыванием остатка.
% - взятие остатка от деления.

Хреновому танцору все знают чего постоянно мешает.
А Си-рулезный и удобный язык, и всякие васики и прочее ему и в подметки не годны.

Ага. Это называется приведение типов.

Ну, для проффесиональных серьёзных программистов - да. Но мне как-то, знаешь ли, удобность синтаксиса Васика дороже универсальности С++... ...а если надо просто поделить без извращений, то нужно это, как "особый случай", пометить в скобках? ОК. Внял.

Ну, раз вчера анонс давал, то надо сегодня чё-нить выложить. Успехи, несомненно, есть: А.Г.Р. заработал. Хотя пока что он всё ещё не полностью функционален по сравнению с Ехселевской версией: за сегодня так и не удалось понять, что не так с макросом, рисующим побочные цепи, так что я его временно отключил. Таким образом, сегодняшняя версия А.Г.Р. рисует такой рельеф, который выдавал Ехселевский А.Г.Р. v.2.1, т.е. одиночные цепи гор простой формы. Но раз это всё же первая ЕХЕ-шная версия, то назвал я её соответствующе:
А.Г.Р. v.1.0 (214 kb).
Насчёт настроек: т.к. макрос, строящий побочные цепи отключён, то соответствующий раздел настроек тоже не работает. Но во всём остальном - милости прошу испытывать и комментать.

_________________
Сообщество креативных механоидов:
aim-fans.ru

Хай, че то мне выдает ошибку CC3260MT.DLL не найден не подскажите че делать.

2 Шаман
Поглядел. Ниче так, неплохо работает, правда, медленно. Но по сравнению с экселем уже очень мощьный прогресс. В принцие, все понравилось, разве что зеленый цвет надо потемнее сделать - глаза режет.
Тока генерируемое твоей прогой не очень похоже на горы, скорее оно похоже на пузыри на гладкой водной поверхности. Ну, может, с побочными цепями не будет так казаться.

Добавлено спустя 5 минут 51 секунду:

CC3260MT.DLL
Файл для шамановской проги. Забубеньте его в папку windows\system32.
Только переименуйте его в то, что требуется, так как на серваке имена меняются зачем-то.

Добавлено спустя 57 секунд:

А Шаману советую поглядеть, какие такие у него библиотеки используются, и зачем вдруг его проге этот файл.

Может Шаман додумается выложить эту библиотеку!

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Гы. А ты поставь расброс высот на "0", и тогда увидишь скопление аскарид! Ага. Правда, возможно, в 2D немного непонятно получится - не знаю. И рабатить с побочными цепями в десять раз медленнее будет. Ну а вообще, чем ниже гора, чем меньше её пологость, чем меньше побочных цепей, тем меньше ячеек нужно просчитывать, а значит тем быстрее будет работать А.Г.Р. Причём зависимость от высоты и пологости - экспоненциальная.
А где посмотреть? А можно ли как-нить сварганить ни-от-чего-не-зависимый ЕХЕ-шник, чтоб подобных геморроев не было? Ну, типа, а откуда я знал, что она понадобиться?! Я ж в этом не секу нихрена...
Обнаружил требуемый файл. Вот его местоположение на моём компе:
C:\Program Files\Borland\CBuilder6\Bin\cc3260mt.dll
А вот и он сам: cc3260mt.dll (259 kb)

Ну а вообще, как мне знать, какие блибляотеки нужно выкладывать вместе с ехе-шником?

_________________
Сообщество креативных механоидов:
aim-fans.ru

Тебе же писали...

Добавлено спустя 11 минут 43 секунды:

Можно просто, библиотеку копировать в папку с екзешником.

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Где?
Так и как же мне УЗНАТЬ, какие библяотеки нужны?!


Гениальнейшая идея осенила меня сегодня при утренней активации ментальных цепей. Обнаружил я в своём моске способ чудовищного ускорения кода моего А.Г.Р.!
Дело в том, что для каждой точки склонов горы, высота точки рассчитывается по такой чудовищной формуле:
(cos(pow(Rrad / Rh, Rpike) * 3.1416 / Rs) + 1) * Rh / 2
Учитывая то, что элементарная гора идеальной круглой формы, то на одинаковом отдалении от её вершины находятся десятки, сотни точек, высоты которых рассчитываются по одинаковой формуле и имеющих одинаковую высоту. Так вот, что я придумал: я просто перед началом построения горы создам линейную матрицу, в которой изначально, всего один раз вместо сотен и тысяч раз, просчитаю значение высот точек для всех отдалений от вершины горы, и тогда для каждой точки склона с заданным отдалением можно будет просто выбирать значение из этих элементов в массиве!
Т.е. постоянного употребляемая сложная формула
(cos(pow(a / b, c) * 3.1416 / d) + 1) * b / 2
будет заменена на
sqrt(x*x + y*y)
(это для определения расстояния точки до вершины)

Ну не гениально ли? В следующей версии А.Г.Р. воплощу.

_________________
Сообщество креативных механоидов:
aim-fans.ru

Файлы с расширением *.dll это библиотеки.

На заметку. Если будеш отображать рельеф на OpenGL (аналог DirectX), тебе придётся подключать соответствующие библиотеки. И их скорее всего ни у кого не будет, т.к. игр на OpenGL уже мало.

Добавлено спустя 6 минут 48 секунд:

Медленно? У меня всё мгновенно происходит.

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Открыл Америку. Если ты имеешь в виду, что нужно сливать те ДЛЛ-льки, что в папке с проектом, то там у мну ни одной такой не имеется.
А ещё плюс к тому, я тут новую версию щас толкну, с вышеописанной сказочной оптимизацией! Вот оно:
А.Г.Р. v.1.1 (215kb)
-увеличена скорость построения рельефа;
-смягчён зелёный цвет.
-вторичные цепи пока ещё не работают.

Прошу протестать результат оптимизации - намного ли быстрее стало работить?
З.Ы.: надеюсь, ДЛЛ-ка сгодится и старая...

_________________
Сообщество креативных механоидов:
aim-fans.ru

Чтож тогда ?...

Не нужно, а можно.

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

Старая может и годится, но требует новую: BORLNDMM.DLL . Думаю, что будет лучше, если ты будешь включать в EXE-шник проекта все необходимые библиотеки. Размер будет больше, но проблем меньше.

Да нет там НИ ОДНОЙ ДЛЛ-ки!!!
А как это сделать? Объясни, плиз.

Ребята, у мну сегодня щчасце!!! Я, наконец, поборол упорное сопротивление С++, и мой А.Г.Р. заработал! Теперь полностью!!! До последней опции! Я в шоке от скорости его работы: даже при намного более мощных настройках, чем в Ехселевском варианте, мой ЕХЕ-шный А.Г.Р. сотворяет карту в десятки раз быстрее!!! А если на одинаковых настройках - то и сравнивать нечего! Так что делюсь своим щчасцем с Вами:
А.Г.Р. v.2.0 (215 kb)
Хотя, скорее всего, он снова потребует какую-нить ДЛЛ-ку, так что пока мне кто-нить не объяснит, как правильно компиллировать ЕХЕ-шник, на мою великую прогу Вы, скорее всего, не подивитесь. (Разве что Razum в очередной раз свою магию применит ).
Так что плиз, объясните хто-нить поподробнее, как надо компиллировать мой прожект?

_________________
Сообщество креативных механоидов:
aim-fans.ru

Да знаем что нету. . .
А как они называются должен знать тот кто их подключает. Или давать нам, чтобы если что, завопили "нет этого...".

_________________
https://sites.google.com/site/intelligencecells
http://www.youtube.com/user/IntelligenceCells

2 Шаман
У меня не работает. Говорит, не найден какой-то файл.

_________________
Кто сказал - борьба напрасна, зло сильней добра?
Кто сказал - спасайся, вот нора?
Путь тяжел, но цель прекрасна, как огонь костра.
Человек, настал твой час, пора!