[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 9999)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3229 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
137217704530.jpg-(251.35KB, 810×810, 7118cd632eddd22b7a4b6559bff5e2fa.jpg)
9999
No. 9999 watch    
http://sourceforge.net/projects/rr-rr/
Предыдущий тред: >>4274
81 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 12081    
141519296484.jpg-(127.27KB, 600×600, 0e5a3fd858cf31e84ce509109406a914.jpg)
12081
Сравнительный тест производительности куч от 1337_POCAN.

- Входные данные и примечания -
На графе с 12K точек и 88K рёбер выбраны 2000 пар точек (начало, конец), для каждой из которых существует путь длиной 200–272 (в среднем 228).
Все поиски покрывают 99,25% точек, все пути — 42,4%.

Для алгоритмов Дейкстры и A★ применяются различные реализации очереди с приоритетами.

RMHhttp://en.wikipedia.org/wiki/Randomized_meldable_heap. Используется ГПСЧ https://gitorious.org/crawl/crawl/source/83560a2567f7eacda5d71d64f4a813efe1c88c2f:crawl-ref/source/asg.cc с фиксированным начальным состоянием, причём выжимаются ВСЕ биты (это быстрее).
Наивная куча — подразумевает хранение узлов в неупорядоченном списке и поиск за O(N), но зато Put и Decrease за O(1).

- Статистика по алгоритмам -
A★ в среднем вызвал 6600 Put, 6500 Get и 3400 Decrease, максимальный размер очереди — 310.
Дейкстра в среднем вызвал 10800 Put/Get и 2450 Decrease, максимальный размер очереди — 262.
Поиск в ширину: максимальный размер очереди — 398.

- РЕЗУЛЬТАТЫ -
Двоичная куча: A★ 17,4 с, Дейкстра 22,4 с.
Троичная куча: A★ 15 с, Дейкстра 20 с.
Четверичная куча: A★ 13,8 с, Дейкстра 18 с.
Восьмеричная куча: A★ 13,1 с, Дейкстра 17,2 с.
Шестнадцатеричная куча: A★ 13,2 с, Дейкстра 18,1 с.
Фибоначчиева куча: A★ 17,8 с, Дейкстра 24,2 с.
Двоичная RMH: A★ 12,6 с, Дейкстра 18,6 с.
Троичная RMH: A★ 14.7 с, Дейкстра 18,5 с.
Четверичная RMH: A★ 13,6 с, Дейкстра 17,1 с.
Восьмеричная RMH: A★ 15,6, Дейкстра 19,9 с.

Наивная куча: A★ 10,6 с, Дейкстра 13.3 с.
Поиск в ширину: 6,2 с. лол
No. 12089    
>>12081
Автор Braid об этом весело рассказывал. Про Doom особенно смешно.

https://www.youtube.com/watch?v=JjDsP5n2kSM#t=554
No. 12539    
>>10050
Как хорошо быть программистом, эх
No. 12843    
14302199491.png-(12.66KB, 270×105, 28_04_2015 14:13:50_133.png)
12843
Перекатился на Lua 5.3. Настоящие целые на уровне VM — это хорошо.
No. 12855    
Простите, а что это такое? Ни на сайте, ни в обоих тредах внятно и четко не сказано, что являет собой эта rr-rr.
Ну разве так можно?
No. 12858    
143194331882.jpg-(233.81KB, 528×800, f72f5c09bf5ffa8ff2aa43a7e6988172.jpg)
12858
>>12855
Во-первых, мне лень и писатель из меня так себе.
Во-вторых, это уберёт элемент загадочности, при условии, что он вообще существует.
В-третьих, до «3D-бродилка про Сырну» можно и догадаться (я делал концепт подетальнее, которого один хрен не придерживаюсь).
В-четвёртых, считаю невозможным мейнстримом навязываться аудитории «смарити какой у нас клёвый праэкт можно делать так и вот так» каким бы то ни было образом и не очень люблю, когда так делают (а коль скоро так почти все делают... ну ты понял).
В-пятых и подытоживая — да, можно, мне норм.
No. 12866    
143301213136.png-(952.09KB, 1050×700, 28_05_2015 21:59:43_994.png)
12866
С мылом и подправленным глазом, хоть проблемы им далеко не исчерпываются.
No. 12932    
143479761614.png-(347.40KB, 1200×800, контуры-а.png)
12932
Thy soul shall be my breakfast!
No. 12933    
So sexy~
No. 13006    
143827621290.zip-(24.81KB, log-Shu [debug].zip)
13006
Падает при старте
No. 13014    
143836689633.png-(786.51KB, 768×768, 30957620.png)
13014
>>13006
Спасибо, обновил драйвер, словил то же, исправил. Narkomani. Вот была функция glGenBuffers(..., &id), «старая» модель glBindBuffer(id) + работа с прибинденным буфером без указания id и «новая» glNamedBuffer...(id, ...), так нужно было её сломать до несовместимости, «кароч glGenBuffers на самом деле не создаёт буфер до первого Bind'а, бинди сразу или используй glCreateBuffers, введенную в OpenGL 4.5 не пойми зачем)))». Это могло было быть сделано, чтобы заставить меня как программиста указывать конкретную версию API, чтобы ломающие изменения в дальнейшем обходили меня стороной, но я это и так делаю, лол.
No. 13015    
>>13014
Fixed pipeline api давно depricated, чего ты хотел?
No. 13018    
143837591582.jpg-(240.04KB, 680×771, 22934769.jpg)
13018
>>13015
-_-" То API не имеет никакого отношения к FFP (ты бы ещё DOS вспомнил), я назвал модель

bind(A)
foo(...)
bar(...)
bind(B)
foo(...)


исторически более старой против

foo(A, ...)
bar(A, ...)
foo(B, ...)

(ARB_direct_state_access)

но принципиального преимущества нет ни у одной. Первая менее удобна и с ней теоретически больше заморочек при работе из нескольких потоков, т. к. «текущий объект» должен быть thread-local, зато она и более расширяема, тогда как попытка расширить вторую приведёт к объединению недостатков обеих. Мне просто непонятен смысл вводить функции вроде glCreateFramebuffers с чуть другой семантикой, когда уже есть glGenFramebuffers. При том что семантика glCreate*, по-видимому, обратно совместима с glGen*. Нонсенс.
No. 13229    
144390631514.jpg-(297.38KB, 567×800, b5ffb94b33bd494380072e8b439b4348.jpg)
13229
Сделал интерполяцию строк в скриптах, т. е.
> format "цепочка длины {n} (R = {dist})"
вместо
> format("цепочка длины {0} (R = {1})", n, dist)
или
> "цепочка длины " .. n .. " (R = " .. dist .. ")".
No. 13243    
>>13229
>интерполяцию
значение знаешь?
No. 13244    
Алсо, это твой рисунок последний? Ты нехило так продвинулся, мож ну его этот кодинг, иди лучше хентай рисуй.
No. 13251    
>>13243
https://en.wikipedia.org/wiki/String_interpolation же.
No. 13252    
>>13251
А, спасибо, не знал что это так называется. Термин дурацкий все-таки, при чем тут интерполяция?
No. 13253    
>>13252
Не термин дурацкий, а восприятие у тебя дурацкое. Весь мир несколько десятков лет использует это слово и всем норм.
No. 13254    
>>13253
Извини, что задел твои чувства, братан, но я программирую десятилетиями и слышу это словосочетание впервые. И оно не имеет ни малейшего отношения к интерполяции, поэтому оно дурацкое. Там же в вики приведены нормальные аналоги - подстановка переменных и раскрытие переменных. Сразу понятно, о чем идет речь.
No. 13256    
Удваиваю, это всегда называлось шаблонированием, а интерполяция - это вычисление промежуточных значений между известными.
No. 13259    
>>13252
Интерполяция означает, что в рантайме вычисляется "содержимое" строковой переменной.
http://perlmeme.org/howtos/using_perl/interpolation.html
Во всяком случае, это то, про что статья >>13251. К обработке строк это никакой причастности не имеет, поскольку идет речь именно про распихивание байтов внутри кода во время выполнения программы.
No. 14172    
> Last Update: 20 hours ago
Сидит в крысу пилит, а тред забросил, гад.
No. 15149    
148047253655.gif-(6.69MB, 640×376, ReadDirectoryChanges.gif)
15149
Когда прочитал про ReadDirectoryChanges.
No. 15181    
148087286242.jpg-(160.35KB, 664×768, 1342459081764.jpg)
15181
Анон, я уже довольно долго наблюдаю за твоим проектом, с периодичностью в 3-4 месяца забывая про него, и вспоминая снова.

Расскажи, пожалуйста, вот что. Откуда ты черпаешь информацию по правильному применению OpenGL? Я сам разработчик, немного пытающийся в игродев. Вот только с гл, по всей видимости, без бутылки не разберешься. То-есть, я знаю всю базовую функциональность: шейдеры/вершинные массивы/индексы/состояния, но нету абсолютно представления, как рендерить сложные сцены, а все попытки попробовать кончаются как гроб, кладбище, лаги, ноль кадров в секунду. Мне кажется я упускаю что-то. Может, посоветуешь что-то почитать из книг, или подскажешь правильный вектор гуглинга?
No. 15188    
14809469241.jpg-(1.44MB, 1181×1748, 6a9f80e2550288b094a14ef14be8b053.jpg)
15188
>>15181
Оно не «правильное», я до сих пор не могу UBO и окклюжн запилить :(

Очень сильно не должно тормозить, если только ты какую-нибудь глупость не делаешь, типа пересоздания/перезаливки ресурсов каждый кадр, или Get*/Finish. Посмотри в профилировщике, откуда именно лаги. Если действительно OGL, отсечения должны помочь. По фрустуму легко отсекается под 3/4 (в предположении, что вид от первого лица, угол обзора 90°, а сверху-снизу ничего нет), окклюжн в закрытых пространствах должен отсекать вообще почти всё, но он сложнее.
No. 15189    
>>9999
А с чего ты вообще начинал, Стив?
No. 15190    
>>9999
То есть, ты студент? Чем по жизни занимаешься? Как у тебя вообще ЧТО-ТО выходит? Если не затруднят вопросы, ответь, пожалуйста.
No. 15191    
14810216033.png-(560.45KB, 750×750, efc185a092d69e0dc67ecf84ef087bd9.png)
15191
>>15190
Я крутой хикки! (Поэтому делать нечего.)
И у меня не выходит...

И я бы к этому ТАК не относился. Я с ужасом осознаю, что отношусь к некой немногочисленной, но прослеживающейся категории людей (специально не искал: раз http://freepascal.ru/forum/viewtopic.php?t=10058, два http://spaceway.1gb.ru/, три http://www.gamedev.ru/projects/forum/?id=140784), которые, значит, решают запилить некий «сложный» (нет) проект на Паскале, но при этом:

а) не имеют представления о базовых вещах. Первый в конце треда на полном серьёзе говорит о формировании финальной картинки из нескольких не как о чём-то самом собой разумеющемся, у третьего вообще какая-то непортируемая жесть, которая сегфолтится при любых сценариях использования, отличных от тривиальных, и куда «Lua-ссылки» добавлены автор сам не понимает зачем (в доке так и сказал... «я не так часто пользуюсь Lua», ну просто лол, оно и видно). Да достаточно на исходники взглянуть. Второй их закрыл, но там было хуже первого и третьего вместе взятых, что-то уровня глБегин с шейдерами. (Некрасиво с моей стороны, да, пацаны в лицо говорят. Пофиг.)

б) ввиду (а), а также сломанности самого языка (отчасти — RTL), у них получается многословная и неповоротливая система, нет, груда плоти, которая кровоточит и кричит «убей меня» (aka «перепиши на C#», как Game Maker). Иногда её тянут и иногда она всё же выезжает, чисто экстенсивно, как Castle Engine. Но, как по мне, в проектах на других языках относительная доля треша всё же поменьше 100%.

Вооот. Не то чтобы я собирался свой проект переписывать, но как-то это всё неправильно. :(
No. 15207    
>>15191
>Я крутой хикки! (Поэтому делать нечего.)
Но образование есть какое-нибудь?
No. 15211    
>>15188
А чем можно профилировать эффективно? Вот есть стрейтфорвард вей, установить swap-интервал в 0 и засечь количество кадров в секунду, например. Но это измерение в попугаях. Прочитав твое сообщение, погуглил и наткнулся на apitrace. Весьма неплохо, показывает состояния, полный трейс вызовов gl*, но это все равно не дает понятия о том, где происходит потеря производительности. Такое ощущение, что где-то провал в софтварный режим. У меня Intel HD4000, но что меня смущает, это то, что даже ААА-игры более-менее сносно работают, не проваливаясь никуда.

Что имею конкретно: пытался прикрутить к контексту рендеринг текста. Был взял FT2, и для каждого требуемого символа загружена текстура и создан дисплейный лист (glNewList) с прямоугольником. Далее происходит биндинг требуемой текстуры, вызов нужного листа, перенос матрицы отображения, всё. На мой взгляд, простейшие операции, но стоит выйти за сотню рендеримых прямоугольников, так количество попугаев падает до нуля. Я даже выкинул другие изменения состояний из цикла вывода, но это не изменило ничего. Неужели это так и должно происходить? Что тогда делают в топовых игорях, чтобы держать частоту кадров на уровне, не понимаю?
No. 15214    
148133635299.gif-(80.10KB, 384×256, trebuc.gif)
15214
>>15211
Склей все буквы в один текстурный атлас (у меня прям весь из себя динамический ←>>10485, но если не выделываться, то проще и надёжнее единожды сгенерировать и забыть) и рисуй текст моделью из N квадратиков, вырезающих нужные буквы текстурными координатами. Оптом дешевле, это очень общий принцип. Не используй glNewList, он мог бы быть полезной штукой (коль скоро что-то похожее, буферы команд, есть на низком уровне), но на деле давно убран из спецификации. Листы < ничего (glDraw*) < VBO (glDraw* под glBindBuffer).

>>15207
https://vk.cc/5WSQTW

Раз уж такое дело, я хотел за начало декабря запилить
1) нескучные MIDI-с-изменяемыми-параметрами (т. е. каждый раз у конкретной песенки подкручивается скорость или октава, что как бы превращает её в несколько) — в принципе, это должно свестись к (BASS_MIDI_)StreamGetEvents + <шаманство над MIDI-дорожкой> + StreamSetEvents

2) сделать нормальный парсер шейдеров (очень бы пригодился для человеческого синтаксиса всего, что я там нагородил, и вытаскивания метаинформации вроде используемых юниформов, например, чтобы автоматически подставить вместо них layout(shared) UBO) — можно слизать у https://github.com/graphitemaster/glsl-parser

3) переделать пространственные деревья (а они просто глючат) — этих ребят хочу заставить самих переразбивать себя, когда посчитают нужными

но сделал только, э, подзадачу (1) остальное как-нибудь в январе, ладно?)): теперь, короче, музыка (и звуки) работают в отдельном потоке, вернее, на таймерах, подсел на это дерьмо (ранее я и освобождение ресурсов по таймауту на них переписал). Зачем: чтобы не требовать дёргать BGM.Process(DeltaTime) в «основном цикле», которого может вообще не быть. Что именно происходит: во-первых, с началом воспроизведения песенки плеер взводит на оставшееся время таймер поставить новую, во-вторых, можно начать воспроизводить звук (или сказать ему фейдаутнуться) и забыть о нём, освободив все ссылки — на время воспроизведения звук доверит одну таймеру и тот освободит её, когда звук довоспроизводится/дофейдаутится (избегая немедленной остановки в деструкторе).
No. 15215    
>>15214
Это получается, что на каждый текстовый объект проще сгенерировать массив вершин? Что делать, если текст динамический? При изменении перезагружать вершины? Звучит сомнительно, но я попробую.
Что до текстурного атласа - получается, что набор символов должен быть известен заранее. А если это нет возможности узнать, то как быть?
Ну и возвращаясь к идее более сложных сцен. Допустим, что текст можно попытаться уложить в один-два объекта. Но если, не дай боже, нужно будет рендерить различные модельки с различными текстурами? Их же не склеишь в одну большую модель и текстуру.
No. 15216    
148140143474.jpg-(81.07KB, 480×640, 24577265.jpg)
15216
>>15215
В варианте с матрицами ты, заливая по 16 чисел на символ, косвенно делаешь то же самое, а ведь они на такое даже не рассчитаны! (против потока вершин, даже usage-подсказки в glBufferData завезли).
Чисто ради самоуспокоения спроси у своего шрифта количество символов и нарисуй их все =3.

Один дип на модельку — нормально, их ведь так и делают, с развёртками, вот этим всем. Одномоментно видимых вблизи много не будет. Невидимые рисовать не нужно. Вдали можно рисовать спустя рукава (импостером etc.).
No. 15347    
>>9999
Уважаемый, ты там с голоду умер?
No. 15388    
148378933818.jpg-(137.49KB, 1188×791, QUALITY_7.jpg)
15388
>>9999
Ответь же!
No. 15465    
Где предыдущий тред? Совус, заяем удалил?
Объясните же уже, что это такое-то, блдажд, о чём тред!
No. 15493    
14847808827.gif-(32.35KB, 330×194, ship.gif)
15493
>>15347
Нормалфаги под кроватью пытаются отбирать еду, но они тупые, легко обхитрить. Сделал двухминутное кинцо, зацени: https://github.com/runewalsh/rox-loh/releases/download/v1.0/rox.rar. Это было в меру бесполезно, но по крайней мере понял, как нужно было работать с окном и GL-контекстом — потом как-нибудь перенесу реализацию в основной движок.
No. 15574    
>>15493
Целый месяц еду отбивал?
No. 15616    
148596215790.jpg-(293.10KB, 744×908, 26152978_p0.jpg)
15616
Ой дебил, навелосипедил тогда слежение за звуками, которые закончили воспроизведение, закончили фейдаутиться, etc., а мог бы просто дочитать документацию до возможности установить коллбэки на эти события. То же касается и MIDI: можно, конечно, патчить треки при загрузке, но официально одобренный способ >«подкрутить скорость или высоту» — хукнуть и перекрывать на лету соответствующие MIDI-события (TEMPO/PITCH/etc.). Завтра переделаю (от велосипеда останется одна блокировка).
No. 16218    
14929689979.gif-(816.89KB, 700×500, qwe.gif)
16218
Попробовал переписать пространственные деревья: моя реализация от 2k11 слегка глючила и требовала вызывать перестроение явно, а теперь решил для каждого узла вести учёт ИСКАЖЕНИЙ (красные прогрессбары толщиной в пиксель), и по превышении порога искажённости перестраивать автоматически. По части глюков получилось ещё хуже прежних, вплоть до неработоспособности. На гифке-то всё в порядке, но вот на реальной сцене... Нужно ковырять. Например, записать последовательности операций с деревом, приводящие к «невозможным» результатам, и плясать от них. Эх, вот я криворучка.

С этим условный фейл, а вот MIDI доделал.
No. 16286    
>>16218
Красивая гифка.
No. 16349    
>>16218
Я не понял, математические деревья ты имеешь в виду или реальные, потому что на гифке как будто программа для моделирования сада. Сам хотел такую написать.
No. 17390    
Бамп, хотелось бы апдейтов. Продолжай пилить, ну.
No. 19389    
Что-то застряла разработка. А сф теперь при скачке говорит: malware detected, download at your own risk. Это что же получается?
No. 19390    
>>19389
ОП взял твои деньги и свалил в Мексику.
No. 19393    
152095217856.png-(475.92KB, 800×1067, 67132246_p0.png)
19393
>>19389
Всё не могу себя заставить ту Сырну дорисовать. Ничего, уже вот-вот, сейчас всё будет, ещё немного, ух. шёл 2018

Мальварь, по-видимому, детектится из-за того, что скомпилированный FPC бинарник зачем-то импортирует ReadProcessMemory. Возможно, стоило бы посмотреть, зачем именно, и репортнуть на багтрекер, но вот, скажем, у меня похожая проблема с PyInstaller, и их позиция — не подстраиваться под антивирусы (https://github.com/pyinstaller/pyinstaller/issues/680), что в идеологическом смысле правильно:
>The only correct way to deal with antivirus is to report them that they are wrong. If we are working around them, we simply start a cat-and-mouse game that never ends.
Если убрать из таблицы импорта ReadProcessMemory (в качестве незаконного решения, не требующего перелопачивания структуры EXE, а только HEX-редактора, можно затереть названием какой-нибудь другой 17-буквенной функции kernel32, например, GetCurrentProcess), бинарник продолжает работать, но уже не даёт ни одного срабатывания на VirusTotal. Подозреваю, что там в каком-нибудь недостижимом пути исполнения какая-нибудь ерунда уровня ReadProcessMemory(GetCurrentProcess(), ...), т. к. если такое нужно сделать один раз, это может быть проще SEH или VirtualQuery.

Кстати, упоминавшийся в >>16218 баг был из-за того, что объекты сцены сдвигались, соответственно, и дерево апдейтилось в Newton-коллбэке http://newtondynamics.com/wiki/index.php5?title=NewtonSetTransform, который вызывается в ходе NewtonUpdate в потоках физики, а не потоке, дёрнувшем саму NewtonUpdate. Когда я делал физику, я ввиду своей наивности проигнорировал параметр с недвусмысленным названием threadIndex, а старое дерево не меняло топологию на лету (требуя явно вызывать Rebuild) и поэтому слабо портилось при гонке.

>>16349
Зелёным цветом показаны объекты, серо-синим вокруг них — узлы пространственного дерева (BVH), жёлтым — запрашиваемый объём, объекты внутри которого нужно вернуть. Обойдённые для этого узлы подсвечиваются красным. Если узел оказался полностью вне объёма, значит, все объекты внутри него можно сразу отбросить, не проверяя дальше (в этом весь смысл такой структуры). Если узел подсвечен сиреневым, то с точностью до наоборот: он полностью попал внутрь объёма и объекты внутри него можно сразу вернуть, не проверяя по отдельности. Выигрыш демонстрируется тем, что число проверок < числа объектов. Красная полоска над узлом эмпирически учитывает внесённые в него изменения, узел автоматически перестраивается, когда она переполнилась. По бенчмаркам всё плохо (но я пока не сделал нормальный бенчмарк, учитывающий разные сценарии, и не откалибровал логику автоперестроений), зато использовать проще, чем прежнюю реализацию, т. к. не нужно перестраивать руками.
No. 19685    
152431309321.png-(19.33KB, 689×824, _resetstkoflw.png)
19685
Всегда хотел это проверить =3.
No. 20299    
Жив еще, значит. Я спокоен.
Удалить сообщение []
Пароль  
[Mod]