2. Diman - 11 Августа, 2015 - 22:09:20

Вот если бы вы довели его до ума (в плане отображения) - не было бы вам цены. Я бы использовал его на своем сайте, как превью для загружаемых карт. (Добавление) А задумка очень интересная. Что немаловажно - удобная и полезная (Добавление) А вообще-то... Сэр - вы гений :Д

3. [M210®] - 11 Августа, 2015 - 23:39:59

klimaka01 Привет. не ты ли мне помогал с эффектами для BloodTC? ) На счет рендера - как раз сейчас изучаю, каким образом можно написать рендер "того времени" не хочу использовать меши, т.к. это не даст основной build фичи - пересечение секторов и рисование только того, в котором находится игрок, а наложенный через него - не виден - типа недоделанного ROR (в дюк нюкеме так можно было сделать) У тебя как рисуются сектора? Может в будущем напишу рендер на Java, тогда без труда перенесу свой BloodCM на него, а там дальше и до Androidа недалеко....но это пока только замыслы

4. klimaka01 - 12 Августа, 2015 - 09:08:01

Цитата: Вот если бы вы довели его до ума (в плане отображения) - не было бы вам цены. Я бы использовал его на своем сайте, как превью для загружаемых карт. По мере появления свободного времени я стараюсь дорабатывать сие детище. Осталось вроде и немного но и ни мало в то же время: скайбокс, ROR, тот же z-fighting починить и текстуры в некоторых местах, кастомные палитры, таблицы теней, прозрачность, анимированные текстуры. Цитата: Привет. не ты ли мне помогал с эффектами для BloodTC? Улыбка) да, я Цитата: На счет рендера - как раз сейчас изучаю, каким образом можно написать рендер "того времени" не хочу использовать меши, т.к. это не даст основной build фичи - пересечение секторов и рисование только того, в котором находится игрок, а наложенный через него - не виден - типа недоделанного ROR (в дюк нюкеме так можно было сделать) У тебя как рисуются сектора? Ну я как раз таки все мешами делаю, но видимость рассчитываю исходя из структуры секторов, поэтому практически нигде нет ошибочного отображения невидимых поверхностей (сейчас вспомнить могу только момент в E1M3, в третьем вагоне возле лифта, там на первом этаже немного видны спрайты и стены второго). Там где это есть, это вполне решаемо доработкой алгоритма удаления невидимых поверхностей. Например, на той же E1M3 этот второй этаж не должен быть виден исходя из структуры секторов, поэтому и рисовать его не нужно. Поэтому все можно сделать мешами и при правильном расчете видимости не должно возникать проблем с нередкими случаям для BUILD, когда несколько секторов занимают один и тот же объем в пространстве.

5. [M210®] - 12 Августа, 2015 - 11:07:17

А как с тобой можно связаться? Я хотел бы задать тебе вопросы по поводу рендера. Например, когда я писал свой рендер Gta2, я постоянно сталкивался с проблемой - либо загружать ресурсы быстро но при этом потребляя кучу оперативки, либо же загружать ресурсы медленно, но при этом потребляя минимум оперативки, вот хотел бы научиться загружать ресурсы правильно) Далее я заметил, что твоя прога загружает все ART файлы целиком, каким образом потом рендеряться все текстуры? Если представлять каждую текстуру как отдельный материал, тогда будет такое же количество вызовов рендера, что будет дико тормозить. Я в своем рендере собирал из всех текстур атлас размером 4096х4096. Такой атлас на CPU собирается около 1.3сек на достаточно мощной 8ядерной машине, что довольно долго, у тебя же загрузка карты происходит быстро...как?) Помню, я добился сборки атласа в 0.3сек на GPU на той же машине, но на андройдах время сборки на CPU и GPU практически не отличается, плюс ко всему, чтобы скормить массив пикселей в GPU, его нужно преобразовать в ему понятный...и тут проявляется моя главная проблема загрузки ресурсов: у меня есть 30мб массив с данными о индексированных картинках...GPU понимает только 32 битные RGB картинки, поэтому мне пришлось создать еще один такой же массив, только в 4 раза больше (ARGB - 4 байта на каждый пиксель) в итоге такое преобразование атласа для GPU занимает чуть ли в 5 раз больше оперативки, поэтому я решил отказаться от такого метода и оставил все расчеты на CPU (хотя в реальных условиях потребление памяти было в 3 раза выше, а не в 5...поработал сборщик мусора) Перенос расчетов на GPU помог только при сборке 24битной tga картинки....там и скорость и легкость по весу P.S. как меня бесят горячие клавишы гугл хроме из-за них пришлось писать весь этот текст дважды! Пишешь-пишешь, а потом бац...долбаная пустая страница и текст потерян

6. klimaka01 - 13 Августа, 2015 - 08:44:23

Цитата: А как с тобой можно связаться? По скайпу можно kirill.klimenko_ Цитата: Далее я заметил, что твоя прога загружает все ART файлы целиком, каким образом потом рендеряться все текстуры? Если представлять каждую текстуру как отдельный материал, тогда будет такое же количество вызовов рендера, что будет дико тормозить. Сначала грузятся все ART файлы на клиент, затем начинает загружаться карта и в процессе обхода всех секторов из ART файлов достаются нужные картинки и из них делаются текстуры. Для E1M1, например, загружается 200 текстур (кстати, если хочется посмотреть на подробности рендеринга, то можно использовать плагинчик для хрома http://benvanik.github.io/WebGL-Inspector/ ). При загрузке текстуры она из индексной с помощью палитры перегоняется в RGBA, и аплодится на GPU. Что до того, что это будет тормозить - я пока не пытался особо оптимизировать рендеринг и и как-то специально уменьшать кол-во переключений состояний, т.к. вроде и так пока не особо тормозит. А кол-во DrawCalls можно посмотреть в графе Batches. Конечно можно и атлас делать, но это нужно в шейдере реализовывать враппинг, да и кол-во DrawCalls это особо не уменьшит, т.к. геометрия рисуется не цельным куском, а отдельно постенно/посекторно, и часто оказывается так, что индексы нужных вершин в индексном буфере находятся в несмежных местах, так что экономия на одном бинде текстуры - это такая себе экономия. Хотя простора для оптимизации еще достаточно. Цитата: у меня есть 30мб массив с данными о индексированных картинках...GPU понимает только 32 битные RGB картинки, поэтому мне пришлось создать еще один такой же массив, только в 4 раза больше (ARGB - 4 байта на каждый пиксель) в итоге такое преобразование атласа для GPU занимает чуть ли в 5 раз больше оперативки, поэтому я решил отказаться от такого метода и оставил все расчеты на CPU (хотя в реальных условиях потребление памяти было в 3 раза выше, а не в 5...поработал сборщик мусора) Перенос расчетов на GPU помог только при сборке 24битной tga картинки....там и скорость и легкость по весу Ну, собственно, в RGBA переводить все текстуры не обязательно, можно обойтись и индексной+палитрой и в шейдере применять палитру, но это не даст использовать аппаратную фильтрацию. Но в случае, если хочется добиться исконного вида, без фильтрации - то это идеальный подход. Или в крайнем случае фильтрацию писать в шейдере. (Отредактировано автором: 13 Августа, 2015 - 08:44:53)

7. [M210®] - 13 Августа, 2015 - 13:16:56

Цитата: Ну, собственно, в RGBA переводить все текстуры не обязательно, можно обойтись и индексной+палитрой и в шейдере применять палитру, но это не даст использовать аппаратную фильтрацию. Но в случае, если хочется добиться исконного вида, без фильтрации - то это идеальный подход. Или в крайнем случае фильтрацию писать в шейдере. Я понял, что если продолжать GTa2, то без такого шейдера не обойтись, но пока забил на все это, на последний момент пилил логику, забив на потребление памяти аж в 50мб и достаточно медленную загрузку в 4-5 сек Кстати загрузку ресурсов я понял как нужно загружать, когда начал потихоньку переносить Build на Java...там очень хороший метод загрузки GRP-файла...потом как-нить я применю такой же метод в Gta2. А на счет Buildа вот уперся в тамашний рендер 3D, который абсолютно не понимаю, как рисуется...поэтому пока тоже приостановил и занялся 3м эпизодом BloodCM, все-таки я им давно не занимался. Кстати до исходников твоего рендера я так и не добрался, где они лежат? на с++ написан? (Отредактировано автором: 13 Августа, 2015 - 13:17:29)

8. klimaka01 - 13 Августа, 2015 - 17:08:50

Цитата: А на счет Buildа вот уперся в тамашний рендер 3D, который абсолютно не понимаю, как рисуется Есть неплохой ресурс http://fabiensanglard.net/duke3d/ там и рендерер неплохо описывается Цитата: Кстати до исходников твоего рендера я так и не добрался, где они лежат? на с++ написан? Лежат они в куче других моих проектов, вот основной файл https://github.com/KLIMaka/ts_webgl/blob/master/src/build.ts . Отсюда уже можно проследить все остальные ссылки. Писал это все я на TypeScript, такая себе типизированная разновидность JavaScript. Это же браузер, здесь ни о каком с++ речи идти не может.

9. [M210®] - 13 Августа, 2015 - 18:32:54

Цитата: Есть неплохой ресурс http://fabiensanglard.net/duke3d/ там и рендерер неплохо описывается Да знаю про этот сайт Проблема в том, что там пишут только последовательность рисования элементов сектора - я это и без этого сайта бы понял....а как именно оно там рисуется не пишут...чтото типа меша это или искаженные 2D картинки...и это еще пол беды - найти методы рисования в исходниках я тоже не смог...вижу что есть например drawwalls, а внутри метода непонятная хрень с циклами, котторые не имеют никакого отношения к GPU или чему то подобному Цитата: Это же браузер, здесь ни о каком с++ речи идти не может. Ну я например использую Libgdx, он использует Java и при этом кроссплатформенный, его тоже можно использовать для Веба...некоторые делают игры на нем под браузеры

Powered by ExBB 1.9.1 Original Style v1.5a2 created by Daemon.XP