skypo
> На старом одноядерном атлоне на 2.5ГГц рогалик идет комфортно даже на full hd
> мониторе. Правда долго не играл (помираю моментально). а вот на двуядерном
> атоме на 1,5ГГц просто беда.
Кстати, тут может быть дело в баге таймера. Таймер, взятый из предыдущего движка в новый, показал ошибку у некоторых людей: http://www.gamedev.ru/flame/forum/?id=169115&page=9#m126
В итоге, из за неверной работы таймера, программа неверно поддерживает свою скорость. :)
Чисто теоретическое предположение.
sb3d
> Софтрендер сильнее теряет в скорости при увеличении разрешения, чем рендер на
> видеоускорителе.
Теряет за счёт низкой пропускной способности памяти. Ускорители давно обзавелись солидной шиной памяти 128-256 бит, на классическом же мосту скорость передачи ой как не ахти.
sb3d
> хотя видеокарта на 7 лет новее
Да, только full HD означает что на одну OpenGL-игру нужно запустить 5 лордов одновременно: 1920 на 1200 против 800 на 600. Рогалик на fullhd вообще не вытягивает. Филлрейт растёт в квадратичной пропорции. К тому же в лорде филлрейт даже меньше - там две полосы сверху и снизу для уменьшения полезной площади рендера. И я не говорил что на моей машине лимбо лагает - он идёт плавно, но фпс померить там невозможно. Для современного ускорителя (возьмём, скажем, GT 520 за 900 рублей) fullhd уже не проблема даже с десятикратным наложением и шейдерными эффектами. Для старого - проблема, но в "весе" 800 на 600 он будет рвать. На ноутах ставятся неигровые карты, только здесь я могу сказать что хороший софт будет лучше плохого OpenGL.
А таймер из движка выпиливать поганой метлой надо. Сделать слип до 60 фпс и всё.
sb3d
> он уже опережает старый в 2-3 раза за счёт многопоточности. Так что всё впереди
Это потолок :( Дальше вы столкнетесь с междутредовой синхронизацией. И скорость будет только падать.
RPG
> только здесь я могу сказать что хороший софт будет лучше плохого OpenGL.
Слишком оптимистично, "ящетаю". Плохой опенгл (в смысле на один треугольник 6 дипов плюс текстурные выборки - должен рвать софт). Софт может победить только в смысле экономии памяти. А память сейчас стоит копейки. И дальше память будет только дешеветь.
Специально для sb3d
Никогда софт рендер не будет быстрее чем ускоренный железякой. (Причем вы можете сравнивать текущий софт с десятилетней давности графускорителем) http://www.ixbt.com/video/nv20-preview.shtml
Вернее софт может победить хард. (В теории). Это случится тогда, когда инженеры смогут без проблем лепить неограниченное количество ядер на чип. Это сложно. Это очень сложно. :( Увы. И судя по последним тенденциям - простое увеличение тактовой частоты становится всё сложнее и сложнее. (Хотя правило Мура всё еще работает, но следовать ему всё труднее.)
Все ребята, которые занимаются CG, будут неимоверно рады, когда смогут получить железку, сравнимую по набору команд и скоростью их выполнения с AMD Athlon XP 2000, но с количеством ядер в штук 60. Но на данный момент это невозможно.
Почему невозможно?
Вот почему:
Во первых память. Гораздо проще делать память, и устройства с ней работающие, когда предполагается, что доступ к памяти будет последовательный, а не случайный как в современных процессорах. Причем еще очень желательно, когда устройство либо только читает, либо только пишет в память.
Во вторых: ветвления. Эта гадость даже в CPU сейчас считается очень нежелательной, а уж в GPU тем более. Но за счет того, что в GPU ядер больше, можно допускать ветвления в программе обработки данных. (Десять ядер считают один вариант ветвления, десять - другой. Когда выяснится результат ветвления - отдаем соответствующие данные. Правда просираем половину вычислительной мощности).
Я это к чему тут понаписал... Дело в том, что когда мы пишем программу для процессора общего назначения, то мы предполагаем, что лазить в память мы будем как бог на душу положит, и ветвиться будем невозбранно, и вообще может в сеть полезем или (ужас!) на диск какой.
А когда мы пишем программу для специализированного процессора (в нашем случае GPU), то выясняется, что
1: Скорее всего мы будем читать дохрена последовательных данных.
2: Скорее всего мы будем писать дохрена последовательных данных.
3: пункты 1 и 2 совместно не встретятся.
3: Обычно значение конкретной ячейки памяти не зависит от предыдущих вычислений,
4: Значение конкретной ячейки скорее всего вычисляется точно так же как значение предыдущей и последующей. (Одна операция, разные операнды)
6: Количество операций ограничено. Т.е, к примеру, не нужно вычислять вещи типа (а каков у нас адрес следующей команды, а не нужно ли нам включить/выключить некий флаг (типа переноса), а не выравнены ли у нас операнды и операции на N бит) и т.д. (ХОТЯ НА САМОМ ДЕЛЕ ТУТ УЖЕ У МЕНЯ СОВСЕМ ОТСЕБЯТИНА ПРЁТ, ПОПРАВЬТЕ МЕНЯ ПОЖАЛУЙСТА, ЕСЛИ Я ОШИБАЮСЬ, а я ошибаюсь :)).
7: Следовательно мы можем значительно упростить процессор:
1: Блок предсказания ветвлений - не нужен.
2: Контроллер памяти - примитивизм из каменного века.
3: Счетчик команд - ровесник динозавров.
4: Кувалдочкой сколачиваем память, от души сыпем тупых, умеющих выполнять три с половиной команды, но быстрых процессоров.
5: Кэш? Не, не слышал.
...
99: Profit.
Правка:
5: Кэш? Не, не слышал.
youtube
> Плохой опенгл (в смысле на один треугольник 6 дипов плюс текстурные выборки -
> должен рвать софт).
Да вы оптимист! Я видел такие убер-конструкции, когда текст рисуется вообще без батчинга, две строки текста в кадре - и всё, привет 20 фпс.
youtube
> 4: Кувалдочкой сколачиваем память, от души сыпем тупых, умеющих выполнять три с
> половиной команды, но быстрых процессоров.
Ну почти. Современный GPU умеет делать всё то же самое, что и CPU, в т. ч. даже работать с целыми числами, но некоторые операции выполняет медленно (циклы и ветвления). Разворот цикла на CPU уже слабо спасает, а вот на GPU можно раз 5 повысить фпс просто разворотом цикла.
Для тех кто понимает в чём дело: GPU разрабатывался с расчётом на 3D, поэтому на старых GPU было так: вершинный процессор, текстурный процессор, процессоры для пискельных шейдров, процессоры для вершинных шейдров. В 2D графике половина мощности простаивает - вершин в 2D кот наплакал. Далее, GPU всегда выполняет семплирование. В 3D никогда не бывает так, что текстура выводится последовательно - она обязательно смещается и очень редко попадает в пиксельную сетку, поэтому семплирование на GPU отключить просто невозможно. А в 2D сплошь и рядом нужно выводить спрайты со смещением 1:1. Но стоит начать вращение - софтрендер сдувается в 5-10 раз, а GPU сохраняет FPS таким же как и раньше. Таким образом за счёт кучи хаков, поставив раком GPU в невыгодное положение и нагрузив его до кучи шейдрами можно добавиться превосходства софтрендера над хреновым ускорителем вроде Intel GMA. Но не более того. Стоит начать вращение картинки и любой софт сольёт.
Так кто-нибудь будет писать "убийцу gnh20" под GPU чтобы проучить негодника sb3d ;-) ? Если что, я мог бы помочь с тестированием и документацией
soflot
> Так кто-нибудь будет писать "убийцу gnh20" под GPU чтобы проучить негодника
> sb3d ;-) ?
Я пишу.
Но не для того чтобы проучить. А просто самому хочется 2д двигатель свой.
soflot
> Так кто-нибудь будет писать "убийцу gnh20" под GPU чтобы проучить негодника
> sb3d ;-) ? Если что, я мог бы помочь с тестированием и документацией
Дык это к автору - пусть открывает исходники и проект будет развиваться, порт на GPU несложно прикрутить как и несложно перенести на SDL и следовательно мак и линукс. А так заброшенный проект быстро порастёт мхом.
RPG
> пусть открывает исходники
с каких это пор отсутствие исходников останавливает ынтузиастов? Ведь и так ясно что надо и какой функционал должен быть в игре, берёшь и пишешь.
youtube
> Я пишу
не не, gnh20 это игра а не движок (там движок - ванильный сухарь). А ты судя по словам пишешь двиг, а не игру. Я имел в виду именно игру
soflot
> с каких это пор отсутствие исходников останавливает ынтузиастов? Ведь и так
> ясно что надо и какой функционал должен быть в игре, берёшь и пишешь.
Ну а смысл делать клон DF и террарии? Нужно что-то новое придумывать... Я имею ввиду поддержка этого проекта: исправление багов, улучшение производительности и добавление фич.
soflot
> А ты судя по словам пишешь двиг, а не игру. Я имел в виду именно игру
А ну да. Двиг пишу. Успехи грандиозные. (Умеет выводить чОрное ОКНО). Неделю назад начал разбираться с многопоточностью. Щас вот выясняю, а нужны ли мне conditional variables. Вроде нужны для вещей типа Input/Ouptut куда бы то ни было.
Вообще идея такая:
1: пользователь инитит, всё что там полагается.
2: создает опенгл контекстов сколько ему надо.
3: посредством двигателя пихает в опенгл ресурсы.
4: меняет состояние двигателя как хочет. Плюс п. 2 и п. 3.
5: УмныйРендер :)
Умный в смысле - сам решает чего надо рисовать, чего не надо.
Ну и чтоб треды во все поля, асинхронность там и всё такое.
Почему у меня тогда один тред, асинхронный рендеринг, а главное - всего хватает?:)
RPG
> Почему у меня тогда один тред, асинхронный рендеринг, а главное - всего
> хватает?:)
Очевидно же. Нишариш ваще :)
А если серьезно: Хочется еще и кроссплатформенности хотя бы Win, Linux. Попробовал GLFW - понравилось, но в винде почему-то если обновлять контекст в том треде, в котором выполняется прием очереди сообщений от ОС, то артефакты вылазят. Ну к примеру, если попробовать поменять размеры окну, в которое идёт вывод графики, то будут артефакты (множественное повторение границ окна, фриз рендера) пока не закончишь изменение размеров/изменение положения окна. Если рендерить в другом треде, то всё ок. И чё-то так меня попёрло с этих тредов, что я решил их пихать куда только можно и нельзя.
Правка:
Синтаксис и орфография.
Потому что рендерить нужно в одном потоке, в остальных - выполнять батчинг, подгрузку, вычисление вершин и прочее. И то только когда это сильно нужно (в 2D - не нужно).
Для кроссплатформенности SDL. С ним никаких проблем никогда не было.
youtube
> Никогда софт рендер не будет быстрее чем ускоренный железякой.
Это в философской теории. А на прошлой странице некий достойный сэр позапускал игры на двух компах, и увидел быстродействие _сравнимое_. Просто найди комп 6-летней давности, и убедись сам, запустив 2д игры с тяжёлыми пост эффектами.
soflot
> не не, gnh20 это игра а не движок (там движок - ванильный сухарь)
Небольшая поправка.
Ванильный сухарь - это новый движок, который в разработке. Gnh20 написана на старом sb_engine1 от 2007 года. Который с кучей тормозов и глюков.
добавил:
RPG
> Таким образом за счёт кучи хаков, поставив раком GPU в невыгодное положение и
> нагрузив его до кучи шейдрами
Я того же мнения: GPU не нужен для 2д графики. На нём её делать неудобно, он и вся система огл\дх предназначены для 3д. А выгоды по быстродействию можно не дождаться, ты сам тестировал.
Так, давайте уже про игру, что ли.
Вот один человек записал видео, как он пытается играть в релиз. Постоянные смерти, он плохо разбирается в управлении, всё сурово.
Ссылка: http://ru.twitch.tv/exarkun69/b/340835912
Этот автор, как я понимаю, ведёт свои стримы.
Тема в архиве.