[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 9999)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, OGG, PDF, PNG, PSD, RAR, SVG, SWF, TXT, XCF, ZIP размером до 10000 кБ.
  • Ныне 2584 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
137217704530.jpg-(251.35KB, 810×810, 7118cd632eddd22b7a4b6559bff5e2fa.jpg)
9999
No. 9999 watch    
http://sourceforge.net/projects/rr-rr/
Предыдущий тред: >>4274
76 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 11670    
>>11669
> после
Последние
No. 11800    
Бампну тогда СыОПа на ичаневе.
No. 11815    
Я надеюсь, проект не заброшен?
Мечтаю, что когда-нибудь я скачаю готовую версию и ммм....
Меня охватит единый организм самописного движка.
No. 11907    
141143536194.jpg-(182.45KB, 640×640, 36657218_p12.jpg)
11907
>>11669
Ответ со скоростью молнии. Движок на FPC, игра на Lua. Что такое движок, а что — игра? А хрен его знает! Движок предоставляет примитивы вроде звука-в-сцене, таймера-привязанного-к-объекту-сцены, ригид-боди или GUI-окна, которые скрипт собирает во что-нибудь осмысленное, как-то так. В Элоне, да, влюбился в атмосферу приключения, хотя дальше убийства короля даже не проходил: пусть и проникнувшись философией DCSS, ничего не имею против гриндинга, по крайней мере, в таком-то мире, но вот кое-откуда она позаимствовала худшее, что вообще можно было позаимствовать — отвратительные боёвку и особенно магию. Музыка местами хорошая. А впрочем, пойду пройду.

Я рипнул перо ಥ_ಥ Посему говнорисунков не будет, просто расскажу, что сделал:

ГПСЧ с сохраняемыми состояниями. Случайность в макромире подразумевает не Ъ-недетерминированность, а набор факторов, которые ты не смог или не захотел учитывать. Связываем с каждым объектом, использующим RNG, отдельный генератор, и последовательности «случайных» событий повторяются после сохранения/загрузки. PROFIT!

Сопрограммы a.k.a. волокна a.k.a. невытесняющая многопоточность. В луа поддерживаются из коробки, для нативного кода WinAPI предоставляет SwitchToFiber, а POSIX — setcontext, но последний меня пугает. В смысле соотношения пользы и сложности реализации оно того не стоило и у меня иногда падает обработка исключений в волокнах (может, проблема в RTL? ещё проверю), так или иначе, теперь можно в скрипте вместо

Scene:Query(center, radius,
  function(obj)
    print("Объект в радиусе: " .. obj)
  end)


делать

for obj in Scene:ObjectsInRadius(center, radius) do
  print("Объект в радиусе: " .. obj)
end
,

где очередной объект возвращается в недрах поставленного на паузу рекурсивного обхода дерева, т. е. технически это прежний вариант с yield(obj) вместо вызова функции. В пределе на синтетическом тесте вообще без работы по получению следующего значения, т. е. for i := 1 to N do Yield(i), волокна до 5 раз медленнее формирования списка результатов, которое, в свою очередь, до 3 раз медленнее варианта с пользовательской функцией, однако разница быстро нивелируется, если между вызовами итератора или в них самих выполняется хоть какая-то работа. К примеру, взвешенно-случайный выбор элемента алгоритмом, который здесь: http://eli.thegreenplace.net/2010/01/22/weighted-random-generation-in-python/ — назван «king of the hill», с волокном в качестве источника весов медленнее всего в 1.5 раза.
No. 12012    
141315379655.jpg-(671.90KB, 1023×723, 1016122.jpg)
12012
Прикрутил https://code.google.com/p/crunch/.
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    
Бамп, хотелось бы апдейтов. Продолжай пилить, ну.
Удалить сообщение []
Пароль  
[Mod]