Пилю A*, 2D и 3D Tile Map Editor

[ilkalawson]

вместо 1000 строк у меня 150

А ну!? Уверены что дорабатывая они не превратятся в ту же 1000у?
А можно хоть глянуть, или это конфиденциально пока что?

[bwolf88]

Уверены что дорабатывая они не превратятся в ту же 1000у?

Пока я убеждался только в обратном.

А можно хоть глянуть, или это конфиденциально пока что?

Вот для примера функция отрисовки куба алгорима марширующих кубов с закидыванием вершин и треугольников (накидал на скорую руку). Его возможно сократить еще на треть при желании. Я сокращал до 11 строк если мне не изменяет память. ТАк же я могу этот код ускорить в два раза, чуть увеличив код. А теперь сравните с листингами в сети.

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

public void DrawCube3D(int cX, int cY, int cZ)
    {
        int _bestCube = 0;
        int m = 1;
        for (int x = 0; x <= 1; x++){
            for (int z = 0; z <= 1; z++){
                for (int y = 0; y <= 1; y++){
                    if (node[sizeY * (сX+x * sizeZ + cZ+z) + cY + y].iso == 1) _bestcube += m;
                    m *= 2;
        }}}
        if (_bestCube == 0 || _bestCube == 255) { return; }

        int idx = verts.Count;
        Vector3 startVerts = new Vector3(cX, cY, cZ);
        for (int i = 0; i < 15; i += 3)
        {
            if (MCTables.edgeTable[_bestCube + i] == -1) break;
           
            //табличные значения
            Vector3 _verts1 = offsets[MCTables.edgeTable[_bestCube + i]] + startVerts;
            Vector3 _verts2 = offsets[MCTables.edgeTable[_bestCube + i + 1]] + startVerts;
            Vector3 _verts3 = offsets[MCTables.edgeTable[_bestCube + i + 2]] + startVerts;

            verts.Add(_verts1); verts.Add(_verts2); verts.Add(_verts3);
            tris.Add(idx + i); tris.Add(idx + i+1); tris.Add(idx + i + 2);
        }
    }
 

[getAlex]

Ты не понимаешь как работает компилятор и в какую школьную лапшу превратит твой "идеальный код", он может понасоздавать классов и переменных, которые ты не создавал - для того чтобы ускорить свою работу. Так что твоё ужимание приведёт к расширению. И самое смешное, что возможно он будет работать медленнее, чем изначально написанная индусами лапша. Так что можешь сократить свой код хоть до одной строчки - это не приведёт к приросту скорости. Напомнило алгоритмы на паскале, которые в 2 строчки рисовали папоротники и деревья с высокой детализацией.
Пример Vector3.Distance -всё так компактно, но sqrt быстрее, хоть выглядит больше.

Или если говорить про твой код:
1)
сX+x * sizeZ у тебя высчитывается Z*Y раз, вместо того чтобы написать так:
for (int x = 0; x <= 1; x++){
int _x = сX+x * sizeZ;
2)
List изначально в 10 раз более тормознутый, чем если пересоздавать обычный массив из-за излишка функционала и проверок, плавающих капасити и прочее. Это создаст много лишних строчек кода, но работать будет быстрее списка.
Туда же относится и Vector3.
3)
Зацикливаться на оптимизации, когда пишешь на шарпе - это как бояться простудиться, во время падения с небоскрёба. Тормознутый язык, тормознутый компилятор, всё тормознутое.
4) "синдром бесконечного ремонта" (с)

[bwolf88]

Вы невнимательно читаете

Его возможно сократить еще на треть при желании. Я сокращал до 11 строк если мне не изменяет память. Так же я могу этот код ускорить в два раза, чуть увеличив код.

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

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

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

List изначально в 10 раз более тормознутый, чем если пересоздавать обычный массив из-за излишка функционала и проверок, плавающих капасити и прочее.

На счет листов пруф пожалуйста .
Мои эксперименты показывают ~3х-кратную потерю скорости, но зато "+100" к удобности использования . Если покажете прирост скорости при поочередном добавлении 10000 (или хотя бы 5000) элементов путем пересоздания массива по сравнению с добавлением элементов в List, я немедленно все перепишу под массивы. Даже еще скнизим планку: по сравнению с добавлением элементов в List + переброс окончательного списка в массив методом List.ToArray().

Тормознутый язык, тормознутый компилятор, всё тормознутое.

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

4) "синдром бесконечного ремонта" (с)

Тоже не совсем верно - потому что сейчас цель научиться, а не сделать и продать. И даже если цель сделать и продать, все равно сначала пишется прототип, а потом уже готовый "красивый" вариант. А чтобы сразу сделать красиво и продать, нужно лет 10 учиться делать красиво. Я пока только год учусь из которых "красиво" начал учиться делать месяца 3-4 назад и даже сейчас я уверен что и трети возможностей языка не знаю. Но если вы каждую свою мысль способны превратить код, я Вам могу только позавидовать и ровняться .

[Dewa1s]

2)
List изначально в 10 раз более тормознутый, чем если пересоздавать обычный массив из-за излишка функционала и проверок, плавающих капасити и прочее. Это создаст много лишних строчек кода, но работать будет быстрее списка.
Туда же относится и Vector3.

Постоянное пересоздание массива при добавлении новой переменной будет работать быстрее добавления в лист?
Лист делает ровно то же самое, только при заполнении массива до краев он удваивает свой размер.
Грубо говоря, при заполнении массива до тысячи элементов он всего 10 раз будет увеличивать размер, как это может быть медленнее тысячекратного пересоздания массива?
Ржаки ради:

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

System.Diagnostics.Stopwatch sw = new Stopwatch ();
                        sw.Start ();
                        List<int> newList = new List<int> ();
                        for (int i = 0; i < 100000; i++) {
                                newList.Add (i);
                        }
                        sw.Stop ();
                        Console.WriteLine (sw.ElapsedMilliseconds);
                        sw = new Stopwatch ();
                        sw.Start ();
                        int[] array = new int[0];
                        for (int i = 0; i < 100000; i++) {
                                var temp = new int[array.Length + 1];
                                array.CopyTo (temp, 0);
                                temp [temp.Length-1] = i;
                                array = temp;
                        }
                        sw.Stop ();

                        Console.WriteLine (sw.ElapsedMilliseconds);

разница: 2 миллисекунды против 15000
bwolf88, не думал над этим ?

[getAlex]

Основные тормоза списка не при расширении капасити, а при List.Add(), в отличии от arr[i] =value;
В 10 это я преувеличил. Была где-то статья, где сравнивались массивы и списки. Там ещё есть зависимость от числа элементов в списке/массиве, т.е. разница производительности не равномерна.

[bwolf88]

bwolf88, не думал над этим ?

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

[Paul Siberdt]

Dewa1s, вы не ведаете, что сотворили. Гореть вам в Оду!

[getAlex]

Length + 1

Серъёзно? Т.е. для листа норм удваивать капасити, а для массива вы решили +1 делать?
Если так интересно плюсавать, то расширяйте сразу на 100 массив с заполнением всех 100, а в список Add 100 раз. Тогда будет честно до наоборот.

[bwolf88]

Серъёзно? Т.е. для листа норм удваивать капасити, а для массива вы решили +1 делать?
Если так интересно плюсавать, то расширяйте сразу на 100 массив с заполнением всех 100, а в список Add 100 раз. Тогда будет честно до наоборот.

А как потом удалить пустые элементы ? Хотя можно сразу перебрать до первого пустого в принципе.

[bwolf88]

Еще один тест. Карта 75х75, 4 дополнительных потока, 750 ботов в реальном вермени ищут путь к курсору мыши, перестраивая путь когда курсор меняет свое положение (то есть постоянно ). ФПС я так понял стал падать, потому что 750 ежекадровых запросов в майн треде к трансформу дают о себе знать. Вот если бы и это можно было вынести в потоки...

[bwolf88]

Кто хочет можно потестировать. производительность будет зависеть от вашего компа, потоки создются автоматом по количестве ядер/2
Управление:
зажать "E" поставить препятствие
зажать "Q" убрать препятствие
зажать LBM - ставить ботов (осторожно можно переборщить с количеством)
AStar_WEB


У меня получилось 1300 ботов и 30 фпс

[Paul Siberdt]

1300, 130fps, за сведенные мышцы руки и раздолбанную клавишу E ты у меня еще ответишь!

[bwolf88]

1300, 130fps, за сведенные мышцы руки и раздолбанную клавишу E ты у меня еще ответишь!

4000+ ботов и 25 фпс у Paul Siberdt. Кто больше ?

[getAlex]

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