У моих Мидландов родной аккум прожил пол-года, потом не держал заряд больше получаса (эффект памяти?), пока не ушел в утиль совсем.
Еще из забавного: рация иногда переключается в режим Lo, что сразу заметно снижает радиус работы.
Раз движок не поддерживает 3D, то это явно оправдано. Но если бы поддерживал, то интересно было бы сравнить скорость. Без «честного» света, конечно же, он тут не нужен — хватило бы простого шейдера с маской.
Именно проблем в нестандартных подходах я не вижу вообще, да и сам этим грешу. Но в этом конкретном случае подозреваю, что «чесное» 3D было для планет как минимум быстрее и читабельнее.
Шейдер это хорошо, но технически это довольно просто повторить и просто 2D графикой, как и было в КР. habrahabr.ru/post/180353/#comment_6261603
Конечно, годы идут, руки у людей все прямее и мой старый пример уже не смотрится без облаков, свечения и пр., но все же задумайтесь, вы пишете микропрограмму для 3D ускорителя, чтобы в 2D имитировать 3D!
под 2D игрой я имею в виду ту, где все спрайты находятся в одной плоскости. Какая при этом камера — дело десятое, если все равно все плоское и рисуется точно так же, как и при ортогональной камере.
Простите, это чушь.
Простите, откуда вы это взяли? Это не так. Биндинг текстуры это не то же самое, что и отрисовка.
Взял из ранних презентаций, где говорилось и показывалось, как рисовать тысячи спрайтов в кадре этой функцией. Ищите, это было в сети на заре OpenGL ES 1.1. Что у функции внутри сказать сложно, потому что работает она всегда вне зависимости от текущей камеры в screen space и сделана сугубо 2D; не удивлюсь, если она копирует текстуру напрямую из видеопамяти в фреймфбуфер на некоторых устройствах. Заодно тогда проводилось немало тестов и производительность этой функции подтверждалась не раз.
Для красоты, очевидно же. А какая вообще связь между фактом использования шейдеров и количеством людей в команде?
На счет красоты это вопрос вкуса, запрограммировать эффект такой же красивый, как может нарисовать хороший художник очень и очень сложно, а зачастую это займет еще и больше времени. Опять же, посмотрите на современные 2D мобильные игры, там шейдеры не используются, а выглядят они отлично. Корреляция с размером команды, конечно, условная, но прослеживается четко — небольшому проекту для небольшой команды не нужны FSAA, SSS, Deferred Lighting, пост-эффекты и прочие навороты. Есть исключения, но не существенные.
А теперь представим, что этот спрайт рисуется во весь экран (или занимает большую его часть). Отрисовка обесцвеченного спрайта поверх обычного будет означать практически удвоение филлрейта. В шейдере же я мог бы забиндить две текстуры и сблендить их прямо в шейдере разом, тем самым не потеряв в филлрейте
Извините, неверно. Два texture fetch в шейдере вдвое уменьшат филрейт (+- пара процентов). Выигрыш у вас может быть только на спичках вроде discard при прозрачности и т.п. Но я все-равно не могу представить задачи, эта скорость будет что-либо значить.
Опять же спор зашел в странную плоскость. Судя по всему, вы сразу начали работать с шейдерными технологиями и считаете все, что было до них анахронизмом. Но это не так, и разница тут совсем не такая, как у языков высокого уровня против ассемблера. Более того, режим без шейдеров еще и может быть быстрее в некоторых задачах. Шейдеры же дают гибкость, возможность принимать решения на GPU без CPU и прочие радости, а не скорость в примитивных действиях. На сим я откланиваюсь, ибо свою точку зрения высказал и аргументировал, а дальше уже не за чем хабру марать.
Если камера перспективная, а не ортогональная, то это все же уже не совсем 2D графика.
Количество Draw Calls для glDrawTexfOES равно количеству используемых текстур, это 1в1 то же самое, что используется в «больших» движках внутри. Даже CGLayer вроде как умеет так делать, хотя поручиться не могу.
это все делалось бы на раз-два, и уж всяко на порядок проще, чем городить странные костыли
Повторюсь, а зачем это в 2D играх того уровня, что может сделать команда в 1-3 человека за 3-6 месяцев?
в том же хидденобжекте может понадобиться сделать спрайт, скажем, пульсирующим от полноцветного до оттенков серого (первое, что в голову пришло)
Плохой пример, в шейдере это сложнее, чем без него, потому что вариант с l = (color.r+color.g+color.b)/3 даст откровенно плохой эффект. Можно сделать так, почти откидывая синий цвет (коэффициенты уперты где-то в инете):
float luminance = dot(vec3(0.2126,0.7152,0.0722), color);
color = mix(color, luminance, mix_amount);
Но все-равно контрастность и яркость пострадает. Если графикой занимается арт-лид, а не программист, то он в этом месте просто скажет художнику сделать еще один спрайт, обесцвеченный вручную, с соблюдением правильного цветового разделения и будет этот спрайт блендиться с мигающей альфой поверх оригинального. Ну а скорость такого решения может оказаться на микросекунду выше, потому что пиксельный конвейер отлично воспринимает ситуации с OUT.color = IN.color, а вот попиксельная обработка не бесплатна, пусть и скорости там порядка миллиона пикселей в секунду.
Осилит без особых проблем. Правда, Crimsonland это все-таки 3D, но если перевести в 2D и рисовать именно спрайты — не вижу никаких трудностей. Собственно, как и можно то же самое сделать обычными CGLayer в iOS, и SpriteBatch в MonoGame, и SpriteRender в Unity. Самое смешное, что еще и принципиальной разницы в скорости не будет между этими подходами, потому что транслируются они примерно в один и тот же шейдерный код, как и glDrawTexfOES в OpenGL ES 1.1 на современном железе.
А вот шейдерную воду, огонь, отражения, свет и прочие радости я в самопальном движке не сделаю, тут вы правы на все 100%. Правда, игру с ними и не потяну, наверное, своими силами.
На 100% верно. Проблема в том, что я пошел с обратной стороны — сначала сделал большую часть для на iOS и Android, а потом подумал о Unity. И переделывать уже не было смысла.
К сожалению я не могу в принципе представить мобильную 2D игру, для которой этого не достаточно. Все разновидности злых птиц, загадочных домов, хидден обжекты и т.д. реализованы выводом спрайтов. Конечно, есть исключения, есть псевдо-2D платформеры со светом и другие гибриды, где это сделано для пущей красивости, но по большому счету более половины современных игр в маркетах занимаются выводом спрайтов и требуют от видеокарты аж одну функцию — рисовать прямоугольник с текстурой. И вот тут выбор у меня очень прост, на iOS и Android я ничего не выиграю при использовании огрызков XNA c SpriteBatch и корявой архитектурой против велосипеда, который ближе к телу.
Глобально glDrawElements обусловлен тем, что его скорости для этого примера более, чем достаточно. Технически тут не будет бутылочного горлышка даже при glEnd/glBegin, потому что мобильные 2D игры рисуют уж совсем мало элементов и на ПК видеокартах просесть тут может что-либо из-за Fill Rate, а не передачи всех наших 20-50 треугольников на всю сцену.
glOrtho, кстати, тут обязателен для текущей Projection матрицы. Использовать же его для каждого вызова тоже не имеет смысла.
Воспринимайте этот кусок кода как пример, во что можно развернуть glDrawTexfOES c максимальной читабельностью, а оптимизировать его есть смысл лишь если нагрузка возрастет до десятков тысяч треугольников в кадре.
В трекере пока не регистрировался, напишу тут, а дальше уже в зависимости от свободного времени.
После установки Mono в его папку etc\mono кладется config файл с ссылками на DLL. В строках с ссылками на библиотеку gdiplus почему-то забыто указание ОС:
Из-за этого на ReactOS он пытается загружать указанные .so, причем безуспешно. Возможно, так же происходит и на Windows, а может там срабатывает еще какая-то проверка и конфиг игнорируется. Достаточно добавить в каждую строку аттрибут os="!windows" и после правки игра запускается и в целом работает, хоть и без звука — не подхватился OpenAL. Еще есть проблема с кликами — порядок событий отличается от Windows и Wine, но это позже отлажу.
Скрины игры
Одним словом, баг в конфиге mono и из-за него не работают поголовно все WinForms приложения на ReactOS. Думаю, он уже отрепорчен, хотя может стоит и форсировать процесс.
Мне из Москвы отправили 9 декабря посылку в Украину. Пока она проехала аж 4км и лежит на Казанском вокзале. Правду говорят, что детям, которые плохо себя вели, подарки доставит «Почта России»
Он хочет быть еще одним, или путает лево и право? :)
Еще из забавного: рация иногда переключается в режим Lo, что сразу заметно снижает радиус работы.
habrahabr.ru/post/180353/#comment_6261603
Конечно, годы идут, руки у людей все прямее и мой старый пример уже не смотрится без облаков, свечения и пр., но все же задумайтесь, вы пишете микропрограмму для 3D ускорителя, чтобы в 2D имитировать 3D!
Простите, это чушь.
Взял из ранних презентаций, где говорилось и показывалось, как рисовать тысячи спрайтов в кадре этой функцией. Ищите, это было в сети на заре OpenGL ES 1.1. Что у функции внутри сказать сложно, потому что работает она всегда вне зависимости от текущей камеры в screen space и сделана сугубо 2D; не удивлюсь, если она копирует текстуру напрямую из видеопамяти в фреймфбуфер на некоторых устройствах. Заодно тогда проводилось немало тестов и производительность этой функции подтверждалась не раз.
На счет красоты это вопрос вкуса, запрограммировать эффект такой же красивый, как может нарисовать хороший художник очень и очень сложно, а зачастую это займет еще и больше времени. Опять же, посмотрите на современные 2D мобильные игры, там шейдеры не используются, а выглядят они отлично. Корреляция с размером команды, конечно, условная, но прослеживается четко — небольшому проекту для небольшой команды не нужны FSAA, SSS, Deferred Lighting, пост-эффекты и прочие навороты. Есть исключения, но не существенные.
Извините, неверно. Два texture fetch в шейдере вдвое уменьшат филрейт (+- пара процентов). Выигрыш у вас может быть только на спичках вроде discard при прозрачности и т.п. Но я все-равно не могу представить задачи, эта скорость будет что-либо значить.
Опять же спор зашел в странную плоскость. Судя по всему, вы сразу начали работать с шейдерными технологиями и считаете все, что было до них анахронизмом. Но это не так, и разница тут совсем не такая, как у языков высокого уровня против ассемблера. Более того, режим без шейдеров еще и может быть быстрее в некоторых задачах. Шейдеры же дают гибкость, возможность принимать решения на GPU без CPU и прочие радости, а не скорость в примитивных действиях. На сим я откланиваюсь, ибо свою точку зрения высказал и аргументировал, а дальше уже не за чем хабру марать.
Количество Draw Calls для glDrawTexfOES равно количеству используемых текстур, это 1в1 то же самое, что используется в «больших» движках внутри. Даже CGLayer вроде как умеет так делать, хотя поручиться не могу.
Повторюсь, а зачем это в 2D играх того уровня, что может сделать команда в 1-3 человека за 3-6 месяцев?
Плохой пример, в шейдере это сложнее, чем без него, потому что вариант с l = (color.r+color.g+color.b)/3 даст откровенно плохой эффект. Можно сделать так, почти откидывая синий цвет (коэффициенты уперты где-то в инете):
Но все-равно контрастность и яркость пострадает. Если графикой занимается арт-лид, а не программист, то он в этом месте просто скажет художнику сделать еще один спрайт, обесцвеченный вручную, с соблюдением правильного цветового разделения и будет этот спрайт блендиться с мигающей альфой поверх оригинального. Ну а скорость такого решения может оказаться на микросекунду выше, потому что пиксельный конвейер отлично воспринимает ситуации с OUT.color = IN.color, а вот попиксельная обработка не бесплатна, пусть и скорости там порядка миллиона пикселей в секунду.
А вот шейдерную воду, огонь, отражения, свет и прочие радости я в самопальном движке не сделаю, тут вы правы на все 100%. Правда, игру с ними и не потяну, наверное, своими силами.
www.youtube.com/watch?v=vZFxN7Yq8Cc
glOrtho, кстати, тут обязателен для текущей Projection матрицы. Использовать же его для каждого вызова тоже не имеет смысла.
Воспринимайте этот кусок кода как пример, во что можно развернуть glDrawTexfOES c максимальной читабельностью, а оптимизировать его есть смысл лишь если нагрузка возрастет до десятков тысяч треугольников в кадре.
После установки Mono в его папку etc\mono кладется config файл с ссылками на DLL. В строках с ссылками на библиотеку gdiplus почему-то забыто указание ОС:
Из-за этого на ReactOS он пытается загружать указанные .so, причем безуспешно. Возможно, так же происходит и на Windows, а может там срабатывает еще какая-то проверка и конфиг игнорируется. Достаточно добавить в каждую строку аттрибут os="!windows" и после правки игра запускается и в целом работает, хоть и без звука — не подхватился OpenAL. Еще есть проблема с кликами — порядок событий отличается от Windows и Wine, но это позже отлажу.
Одним словом, баг в конфиге mono и из-за него не работают поголовно все WinForms приложения на ReactOS. Думаю, он уже отрепорчен, хотя может стоит и форсировать процесс.