Прошло немало времени с тех пор как я взялся за этот проект, а именно 47 дней, 44 ревизии, 12482 строчки кода тому назад, но кто считает? Вообщем, как видно сделано уже немало, и собственно в данной теме я собираюсь отныне и впредь делиться радостями и горечью результатов разработки. Да кстати, для не посвященных поясню что тут приведены "логические строчки кода", т.е. число строк кода без учета пустых, служебных символов, комментариев, объявлений переменных, классов и прочего (а порой они очень увесистые, к примеру объявление одного enum'а у меня заняло примерно 1000 строк, но считается за 0), также тут не учитывается язык разметки XAML и по техническим причинам остался не учтенным код написанный на С\С++ и ассемблере (его конечно пока не так много, но несколько тысяч тоже наберется). Вообщем это все к тому, что на самом деле писанины куда больше, но если начать считать просто строчки текста, то хоть как-то объективно оценить масштаб проекта будет совсем сложно. А теперь назад к теме - те из Вас, кто слышал или даже видел старые демки, коих было мягко сказать немало, а возможно даже и приложил свою лапу к их разработке, знают, что особого энтузиазма и оптимизма они не вселяли, из-за чего даже рассматривался вариант окончательно похоронить проект. И возникает вопрос зачем проливать столько пота и поднимать столбы пыли ради его? А дело в том, что изначальный концепт изменился игра будет куда более интереснее, серьезнее и глубже. Что именно она будет из себя представлять пока является страшной тайной за шестью печатями, что будут постепенно сниматься по ходу продвижения работ. Пока могу лишь сказать, что в привычные жанровые рамки ее вписать будет не просто и одним словом тут все равно не ответить. Но что бы не вселять ложные надежды отвечу сразу - нет, "корованы грабить" нельзя будет и не просите...



Ранее в новостях уже упоминалось, что в игре будет 3х мерный рельеф. Конечно в наше время этим уже никого не удивишь, но я все же попытаюсь. Дело в том, что не смотря на 3х мерный рельеф, игра полностью 2х мерная. Нет я говорю не о "фиксированной камере", ибо ее нет в принципе, все сделано собственными ручками с нуля без использования любых сторонних движков, фреймворков и библиотек вроде DirectX или OpenGL. Собственно большую часть этого времени я провел за написанием, того от чего современная легкая жизнь нас отучила думать - рисовка линий, кругов, эллипсов, спрайтов, вращение и масштабирование спрайтов, наложение цветов с частичной полу-прозрачность и многое другое, но самое суровое испытание что мне выпало и съело несколько дней реальной жизни это написание собственного алгоритма нахождения квадратного корня. Те кто немного знаком с программированием вероятно удивятся зачем, ведь в любом приличном языке есть готовое решение и даже более того в основе их лежит использование одной единственной ассемблерной инструкции. Но дело в том, что ее скорость работы на CPU исторически прославилась своей заторможенностью. И вот результате сей бурной деятельности проб десятков алгоритмов, изучения чужих сурсов, гугла и чтение книжек по математике стали 11 строчек кода, что заставили меня почувствовать беспощадность времени, на примере собственного постарения, ибо выяснилось что в процессорах последнего поколения FPU мягко сказать доработали и нынче "тормозной" вариант оказывается в два раза шустрее, хотя на процессорах прошлого поколений мое творчество и дало прирост более чем на 50%, но тем не менее досадно. Так зачем же изобретать велосипед и почему не взять готовый движок? Ну если Вам будите так угодно зовите меня старым извращенцем, но данный вариант я посчитал более простым и удобным. Дело в том, что у многих умные слова вроде GPU, DirectX, OpenGL, CUDA и другие вызывают какой-то сакрально-мистический трепет, мол они творят магию и заставляют прорисовку летать в тысячи раз быстрее. Но никакой мистики там вовсе нет и хватает своей специфики и собственных заморочек, даже когда речь заходит о том что раньше не вызывало проблем теперь требует изворотства, к примеру простые вещи вроде палитр приходиться делать через шейдеры. И есть много подтверждений когда проекты написанные на С++ с использованием аппаратного ускорения графики оказывался тормазнутее аналогов написанных без аппаратного ускорения. Не по причине что оно плохо конечно, а как раз по той причине, что авторы наивно понадеялись на магию и что DirectX сделает все сам... Обратная сторона медали это разделение платформо зависимого от платформо независимого кода, так что адаптация под линуксы и макоси не за горами, а после настанет черед и андройда с айось, правда о них говорить еще рано - компилятор новый и с его заморочками не знаком, к тому же еще остается вопрос насколько производительность мобильных процессоров ужасна по сравнению с десктопами, но проблемы нужно решать по мере их поступления и пока разработка ведется лишь под форточкой. А теперь сделаем CR LF и вернемся назад к теме.



Итак начало разработки игры инициализировалось с создания матрицы тайлов (размеры кстати могут быть любые и не обязательно равные по вертикали и горизонтали). Вообщем-то задачка не сложная, сложности тут вызвала лишь возня с системой координат, в особенности обратное преобразование экранных координат в номер тайла (ведь вершины тайла имеют произвольную высоту). В результате я получил аж 4 системы координаты для описания тайлов (id, экранная, матричная и декартовая). К чему столько много? Матричная удобна для работы, но не безопасна так как не обладает свойством непрерывности в отличии от декартовой, структура хранения и отрисовки основана на одномерном представлении и как следствие завязана с id, ну а без экранной системы координат не обойтись, как же иначе сопоставить положение тайлов на экране?

Следующим шагом стала конвертация и наложение текстур, вообщем задачка для CPU в общем случае конечно достаточно громоздкая, но в данном случае все сводиться лишь к упрощенной линейной интерполяции вертикальных строк, естественно при этом мы бы получили лишь растянутую картинку на которой без сетки 3х мерность почти не чувствуется. Все дело в освещении, что должно подчеркивать подъемы и спуски придавая рельефу объем. С этим пока туго, хотя крайне грубый и зачастую не работающий корректно вариант уже можете тут наблюдать. Да и конечно это не бутафория, худо-бедно, но в редакторе уже можно редактировать карту, правда прокрутка пока еще не реализована, зато появился списочек текстур.



Ну а на этом пока наверное стоит остановиться, а то длинно-пост уже начинает угрожать превращением в роман-мемуары, которые наверняка никому не интересны.


PS По причине почти полного отсутствия собственной графики на данный момент(что как мне кажется продлиться почти до релиза) используются ресурсы надерганная откуда попало. Так что просьба отныне и до релиза не сильно беспокоиться качеством графики и заимствованием ресурсов из других игр.

О, спасибо, не ожидала, что будет столь развернуто, видно, что очень старался! И внезапно даже дни считаешь я уже давно счет потеряла

Отписала на главной то же самое более кратко Надеюсь, что раздел приживется и понравится нашим форучанам. Да и всегда лучше, когда из первых уст пишет программист, чем когда я порой перевираю по той части, в которой не разбираюсь. И пояснение, почему выбор пал именно на средство разработки "с нуля" - очень полезно, я как раз не могу это объяснить, когда меня спрашивают на чем проект и почему, теперь буду отсылать сюда
я про это писать даже в новостях боялась, настолько это было сурово, что осталось за кадром, ну теперь тайное стало явным!

Ну, не так уж и бедно-грубо на мой взгляд, объемчик чувствуется, что прикольно. На этих текстурах пока не очень понятно, потому что они тестовые, ну вообще прикольно ведь работает освещение!


Ну уж я не думаю, что до самого релиза это будет продолжаться. Возможно, эти "мемуары" как раз станут отправной точкой, чтобы заинтересовать нового члена команды в области графики. А если и нет, то я серьезно начну теребить всех знакомых мне художников после того, как будет готов играбельный прототип. А для прототипа заимствование ресурсов мне не кажется чем-то криминальным

AnnTenna пишет: Не хочется конечно разочаровывать тебя, но на самом деле я лишь посмотрел на метки времени первых файлов на SVN...

AnnTenna пишет: Ну да текстуры конечно не очень удачные, так как не совсем хорошо стыкуются и разрешение исходника очень большое, к примеру текстуры трава 512х512 там каждая травинка видна но при ресайзе это все превратилось в невзрачную кашу пикселей. Но с освещением тоже не все гладко, но не совсем корректно работает и затемняет осветляет пока лишь тайл целиком, хотя после обдумывания понял что лучше будет разбить тайл на 4 треугольника образованные диагоналями и применять освещение уже к каждому по отдельности.

AnnTenna пишет: Ну будем надеяться что народ хоть немного заинтересует сабж...

Скажу свои пару слов, пожалуй. Как геймдев я не шибко-то опытен, поэтому всё ниженаписанное следует воспринимать исключительно как моё ИМХО.

Первое впечатление проект вызывает отличное - рендеринг поверхности здоровский, свои механизмы отрисовки - отлично, видно что с душой сделано, круто. А вот после прочтения этой темки появляются несколько смешанные мысли по поводу будущего этого проекта.

Во-первых, смущают объёмы кода. 12к логических строк с ассемблерными вствками (зачем они тут?), какие-то тысячи строк с объявлением переменных. Чем более объёмный и громоздкий код, тем сложнее развивать его вширь, так сказать. Кстати, не увидел в теме, на каком языке всё пишется-то?

Во-вторых, рендеринг без использования GPU - это не очень хорошо. Люди используют DirectX и OpenGL в 2д-играх не для того, чтобы пользоваться готовыми математически-графическими фукнциями. Их испоьзуют потому что это удобный способ возложить работу с грфикой на то, что для этого предназначено - на видеокарту, а не мучать процессор.

По поводу текстур, думаю, беспокоиться не стоит - если будет готов движок и механика игры, то найти художников и поменять текстуры на свои не будет проблемой.

А вообще, хочется пожелать удачи в разработке, пишите о дальнейшем развитии)

На самом деле это не так уж и много для серьезного приложения. К примеру достаточно простая игра SmileIt! где-то в районе 10к строк кода и это при том что она была разработана на готовом движке.

Это на самом деле зависит от качества кода и архитектуры проекта. Если это сплошная каша, то конечно тут и 2к хватит чтобы утонуть, а если все разбито на модули, описано и продумано, то все очень легко и просто. Собственно на практике как раз для развития вширь и приходиться писать лишний код, делая классы и методы более универсальными и прорабатывая ситуации и задачи что могут быть востребованы в будущем, даже если они не нужны сейчас.

В основном все пишется на C# под кроссплатформенную сборку .NET 4.5 (в частности код совместим с андройдом и иосом, хотя как я говорил пока разработка ведется под винь, с остальными платформами разбираться буду позже), GUI редактора на XAML и C#, весь остальной платформо зависимый код или на C# или на С\С++ c ассемблерными вставками, причем все это сделано в виде дополнительных опционально подключаемых модулей, в том числе и сам редактор. Т.е. это не просто какая-то куча где все перемешано а упорядочная модульная иерархия.

Компьютер может выполнять кучу операций в секунду, но он не умеет думать. В узких с точки зрения производительности местах требуется ручная оптимизация. В основном это связанно с графикой, т.к. чтобы отрисовать картинку разрешением 1024х768 с 60 фпс, нужно каждую секунду совершать более 47 миллионов итераций (перемножьте ширину,высоту и фпс).

Не переменных а enuma, к примеру:Перечисление на 1000 строк относилось к описанию клавиш клавиатуры\мышки + комменты (в районе 256 объявление + 3 строки комментариев на каждую и 1 пустая строка между записями.) Ну это просто крайний пример, просто написал чтобы не сведующие люди лучше могли бы представить себе объем работы, так как если сложить объявление всех классов, переменных, методов, интерфейсов, делегатов и тд и тп в сумме набежит тоже очень прилично строк текста)

Не все так просто, DirectX и OpenGL не творят магию, это лишь инструмент. Результат зависит не столько от инструмента сколько от того кто и как его применяет. Наглядный пример - загрузка текстур в видеопамять, которой тоже занимается процессор, а теперь представим у нас 16к текстур (в данной демке под 200 штук, так что это реальность ну если все же не верите то представьте себе спрайтовую анимацию 8 направлений, допустим по 5 кадров и по 5 действий (бездействие, хотьба, атака, получение урона, смерть) итого 200 спрайтов на один "юнит", а их как правило десятки). Постоянно хранить их в памяти это гигабайты памяти (текстуры должны быть со стороной равной степени двойки в 32 битном цвете), а если постоянно гонять туда сюда получаем что у нас надрывается процессор и из-за того что он не успевает их гонять FPS проседает до 10. Конечно все можно оптимизировать, в данном случае расположить спрайты на одной большой текстуре (атласы), что еще лучше генерировать программно в зависимости от того какие именно требуются в данный момент. Оптимизировать рендинг таким образом, чтобы минимизировать число переключения текстур (на самом деле даже смена используемой текстуры, что уже загружена в память видеокарты негативно влияет на производительность). Это лишь один из нюансов, есть и множество других к примеру как быть если нужно красить юниты в разные цвета? Раньше для этого применялись палитры, теперь или дублировать спрайты или подключать шейдеры, работа и возможности которых тоже имеют свои особенности. В результате конечно же можно получить красивую картинку с современными спецэффектами, шейдерами и большим FPS, я этого не оспариваю, я лишь хочу сказать что само по себе ничего не происходит и даже чтобы добиться быстрой работы нужно не просто задействовать GPU но и оптимизировать свой код, ресурсы и возможно даже логику приложения. В каком-то смысле разрабатывать 3д игру на OpenGl даже проще чем тяжелую 2D игру. Тем не менее я с вами согласен применение DirectX\OpenGL технологичнее и более привлекательно, однако так как разработкой занимаюсь пока в одиночку, сам проект не маленький мне хочется больше сосредоточиться на геймплее а не на технической части, а учитывая что стилистика тяготит к играм "старой школы" и пиксельной графике (не показушной как это нынче модно, имитируя пиксели квадратами с "пол экрана") я решил что лучше будет обойтись без использования DirectX\OpenGL.

Кстати DirectX я все же использую правда только для отрисовки на экран, т.к. он позволяет обойти механизмы тормозной отрисовки окон винды + позволяет рисовать прямо 16 битное изображение на 32 битный рабочий стол. (естественно т.к. это платформо зависимый код, он легко заменяем и в частности уже есть вариант что использует только программные средства винды)

Я сторонник того чтобы разрабатывать свой код и свои движки, но это касается только замены стороннего софта. Когда идёт речь о gapi надо понимать что это в первую очередь доступ к вычислительным ресурсам gpu, а не только библиотека. gapi в целом разделяется на ядро и дополнительный функционал. Можно использовать только ядро, которое в основном отвечает за управление видеокарточкой, а функционал писать самому, если это эффективней. Шейдеры там не просто так тоже. По сути это возможность исполнять твой собственноручно-написанный код, но на gpu. То есть тоже самое что ты делаешь сейчас, но в 10 раз быстрее (ну разве что подходы немного другие как следствие другой архитектуры).

fpu медленный -- используй sse. 4 корня разом. Тоже самое касается тригонометрии. Я пробовал писать свои корни и тригонометрию, профит будет только если нужны совсем неточные результаты, например для кучи мелких частиц, которые плохо видно. И то это неправильный подход, потому что тоже самое gpu сделает намного быстрее и с нормальной точностью.

В общем у меня был опыт написания софтварного рейкастинг рендера и я там делал sse, многопоточность, максимально устранял кешпромахи и всё-равно было медленно даже на i7, особенно когда потребовалось сделать альфа-блендинг для дыма. Правда в моём случае перерисовывался весь буфер, как в 3d приложениях. Если изредка изменять отдельные тайлы, может и прокатит. Но тогда нельзя будет создать анимации по большой площади, например волны на воде, когда воды на весь экран. Самое узкое место это даже не процессор, а скорость памяти. Как следствие нужно создавать такие алгоритмы которые меньше обращаются к памяти и больше выполняют операций с данными, пока они не вытеснены из кеша. А такие алгоритмы крайне неудобны. На gpu там как: выполняешь одну простую операцию сразу над всем буфером кадра, затем вторую и т. д. несколько проходов. А с cpu так нельзя: нужно взять несколько десятков килобайт пикселей, проделать над ними сразу все нужные операции и затем результат записать обратно, потом следующую порцию также и т.д. Но например такие операции как размытие, анизотропная фильтрация, pcf, требуют доступ ко всему исходному буферу и видимо невыполнимы в условиях cpu. Так что не надо делать на cpu то, для чего он не приспособлен.

На мобильных платформах gpu единственный способ выводить хоть какую-нибудь вменяемую графику.

Для подсчёта строк кода можно использовать программку cloc -- она разделит сколько кода, сколько комментариев, сколько кода на каждом языке и т. п.

Редактор тайлов есть -- это здорово. Лучше недоработанный работающий движок чем доработанный неработающий =).

sam0delk1n пишет: Я тоже так думал, но как оказалось на процессорах последнего поколения FPU уделывает даже код Кармака. Тем более мне нужны как раз абсолютно точный результат причем используются только целочисленные значения. SSE использоваться затруднительно так как я пишу на C#, а тормазнутость маршалинга нивелирует любой прирост производительности, даже ручное заполнение стека и вызов не сильно меняют ситуацию. Тем не менее я все же смог реализовать вариант, что работает шустрее FPU на старых процессорах:


sam0delk1n пишет: В случае 3d софтверный рендер представляет лишь академический интерес (ну возможно кроме случая 2.5D аля Doom1\2, DukeNukem3D и тд), практически превзойти GPU не получиться в принципе. Но в данном случае речь идет о 2д причем с пиксельной графикой и всякие шейдеры и анизотропная фильтрация мне тут нафиг не нужна.

Если кто-то сделает современные красочные спрайты и 3д модели с анимацией, с радостью возьмусь и за 3D с шейдерами, вокселями и прочим. А до тех пор мне данный вариант менее удобнее и привлекательнее.

sam0delk1n пишет: Ни разу, в противном случае не было бы проблем эмуляции современных консолей на ПК. А проблемы вызваны не тем что они другие а тем что архитектура отличается. Ну покрайней мере раньше, сейчас насколько я понял тенденция подогнать консоли к ПК с специальной ОС... ))

fpu это 80-битный float. sse это 32-битный float для x86. Для игр этого хватает. Можно брать int конвертировать во float, делать все раcчёты в нём, затем результат обратно в int. Если считать в int без конвертации, то с каждой следующей операцией будет накапливаться погрешность. Я с этим сталкивался в вышеприведённом проекте. Хотя например в Doom1/2 были целиком целочисленные вычисления, но там всё было подогнано так, чтобы никаких округлений и остатков от делений в принципе не возникало, это очень ограничивает действия программиста, сейчас такого делать не стоит -- float также быстро как и int считается (а в случае sse можно сразу пачками считать). Но если всё же хочешь целочисленные расчёты использовать, то можно ускорить их через mmx, но это довольно старый набор инструкций. Кармак в idTech4 делал ускорения не только арифметическими хаками, но и вариантами с неполными функциями. Например нам надо сравнить длины двух векторов. Нужно найти сначала длины, затем их сравнить. Для вычисления длины нужно сделать sqrt( x * x + y * y ). Здесь sqrt потенциально медленная функция. Но можно вместо длины, сделать квадрат длины x * x + y * y. И сравнить квадраты длин двух векторов -- если нам надо определить только лишь условие какой из векторов длиннее, без абсолютных величин, то этого достаточно. Таким образом мы избавились от двух квадратов. И вот в матлибе к idTech4 было много таких примеров, но мне кажется это досталось по наследству из более древних версий idTech. Я немного попробовал использовать подобные функции и это оказалось очень накладно -- нужно постоянно следить, выбирать какую функцию использовать, код плохочитабелен, можно легко напутать что-нибудь и скрытые баги словить. В общем я остановился на использовании sse -- это самый рациональный вариант математики cpu на сегодня, баланс между сложностью кода и скоростью работы.
Писать движки, мне кажется, надо на языках у которых на выходе бинарный код. c# я так понимаю был бы полезен как альтернатива скриптам. Весь игровой код и общую логику которую можно изолировать пишешь на c# и она кроссплатформена. Код взаимодействующий с системой и gapi пишешь на c/c++ для каждой платформы свой. В принципе я и общую логику пишу на с/с++ кроссплатформено. Передача управления нативному коду и обратно надо минимизировать, тут всё верно. Даже вызов блока ассемблера из с/с++ приводит к расходам на перераспределение регистров. Так что нужно достаточно большие блоки кода на ассемблере группировать, и достаточно большие функции нативного кода, вызываемые из c#.
Ну там рейкастинг, только в doom1\2 он упрощён, там грубо говоря бросается по одному лучу на вертикальный столбец пикселей (количество лучей равно разрешению по ширине экрана), а более современные варианты ближе к рейтресингу, где лучи бросаются для каждого пикселя. Да cpu такое не вытянет, но в целом тот же алгоритм можно реализовать на gpu с compute shaders вполне. Один в один конечно не получится, поэтому нельзя эмулировать консоли. Но переписать код на основе той же теории в целом можно. Шейдеры это не дополнение, это фактически замена стандартного конвеера. Вот например в твоём случае отрисованное изображение нужно каждый раз через шину pci-e перегонять на видеокарточку. А это лишние пару мегабайт =). Ну вот в моём случае точно-такая же ситуация, при 60 fps это уже превращается в трафик 60-120 мб/сек. В целом это 20% производительности в моём случае сжирает. Правильней было бы все ресурсы заранее загружать в память карты и как можно больше вычислений делать на карте, чтобы шину использовать только для команд управления. Консоли и ПК с gpu в cpu лишены данной проблемы потому что у них общая память.
Короче говоря всё будет зависеть от того какое у вас разрешение рендер-таргета, какое количество анимации относительно площади изображения, и как часто будут меняться кадры. Тут разброс возможного результата очень большой, так что если всё сделать правильно, наверное легко прокатит даже на старых компах и мобильных платформах. Но как только художники начнут привносить красивости "вот там водичка плещеца, а там листочки шевелятся" то производительность может неожиданно резко просесть. В общем у вас всё как-то рискованно.

sam0delk1n пишет: Спору нет С++ шустрее, а С шустрее С++, а ассемблер шустрее С. Однако что значит "шустрее"? Это лишь инструмент, что в теории позволяет сделать код быстрее, но практически все зависит от программиста - хороший алгоритм дает куда больше выигрыш, чем оптимизация машинного кода, а порой и аппаратное ускорение и производительность железа. Не верите? попробуйте написать код для подсчета определителя матриц (конечно тут речь о больших матрицах вроде 1000х1000) на ассемблере и сравните его с матлабом. Скорее всего даже при самой идеальной оптимизации вашего кода он будет работать в десятки а то и сотни раз медленее вовсе не потому что у Вас плохой код, а потому что Вы плохо знаете численные методы (кстати к слову тот же матлаб для этого использует библиотеку написанную где-то в 80х годах). Вместе с эволюцией производительности железа растет и объем и сложность разработки ПО и хоть раньше и писали на ассемблере с задачей спокойно справлялся программист одиночка, попутно успевавший сделать звук, музыку, графику, сюжет, геймплей и вычистить почти все баги (не замечали что игры 80х куда реже крашуться чем современные?). Теперь же десятки программистов с современными IDE и отладчиками, разрабатывая код на готовых движках, API и библиотеках выдают продукт что работает через пень колоду. Конечно тут дело не в том что современные программисты идиоты, просто работая на ассемблере приходиться держать в голове состояние всех регистров, всех переменных и параллельно думать как минимизировать перегонку байт из памяти\стека в регистры и обратно. Сегодня же нам приходиться плодить столько переменных, что даже сами быстро забываем где что и зачем. И что еще хуже возросшая сложность приложений говорит, что в любой момент может потребоваться впихнуть что-то в середину написанного ранее кода. Вообщем я это к тому что сегодня зачастую скорость и удобство разработки кода становиться куда важнее чем возможности низкоуровневой оптимизации. Конечно спору нет без ручной оптимизации узких мест на SSE, AVX и прочем ваш движок не удивит мир и не приблизиться к проектам ААА класса, вот только Вы правда хотите в одиночку тягаться с толпами корптящими над этими ААА проектами?? Лично я нет, а так как разработка любой игры или движка дело серьезное, а человеческий ресурс не большой вывод напрашивается сам. Покрайней мере C# позволит отладить и оттестировать алгоритмы и если уж совсем прижмет к стенке можно фактически через кат-копи перенести проблемный код на С\С++ разбадяжить ассемблером и радоваться жизни. Только не поймите не правильно я вовсе не собираюсь разжигать холивар С# vs C++, каждый язык имеет свои сильные и слабые стороны и каждый выбирает исходя из задачи, обстоятельств и собственного опыта.
PS тут достаточно интересная статейка на тему - www.codeproject.com/Articles/212856/Head...chmark-Csharp-vs-NET (с кучей графиков и бенчамарков). В конце автор приходит к данному выводу:sam0delk1n пишет: Вот только в некоторых играх спрайты весят в районе гигабайта и это с учетом того что она в 8\16 битная и как минимум с сжатием уровня RLE.

sam0delk1n пишет: Да нет, во первых пиксель арту не нужно большое фпс (ну кроме специфики вроде скрола карты, курсора, возможно еще чего-то) по причине того что Вы хоть раз видели спрайтовую анимацию с частотой смены кадров более 20 в секунду? Врядли даже более 10 видели. Во вторых все это мелочи, что легко решаются или не на столько принципиальны. Проблемы везде свои в тех же смайлах из релиза пришлось выпилить все шейдеры и отказаться от всех красот, ибо половина видеочипов мобил это не тянули. Из-за закоса под GLES оно имеет большие проблемы с совместимостью на многих современных ноутбуках, т.к. разработчики интегрированных видео чипов взяли моду экономить на поддержке старых версий. Конечно все можно списать на корявых китайцев, но тем не менее этот один из самых популярных и активно разрабатываемых движков. Вообще тут еще дело в том что создать высокопроизводительный движок общего назначения в принципе не возможно, в каждой игре\жанре своя специфика используя которую можно заметно поднять производительность.

StaticZ пишет: Верю.


StaticZ пишет: Естественно, если можно что-то не считать, то это и не надо считать. Кармак говорил относительно графики: сейчас качество движков определяется не рендером -- все движки рендерят одинаково, а тем что в этот рендер подаётся. С этим понятно. Что касается самого кода :StaticZ пишет: Вот. Это инструмент преобразования из одной формы записи (С/С++) в другую (ассемблер). Скорость в любом случае зависит от того что получилось на ассемблере. Прогер может писать на ассемблере свой код, может писать на С и понимать (ну или посмотреть после компиляции) что будет на ассемблере. Может писать на С++ и тоже убедиться что на ассемблере получилось то что требуется. А вот если он пишет на C# уже не очень понятно как виртуальная машина будет исполнять байт-код. Можно писать на каких угодно высокоуровневых языках, но понимать/посмотреть что идёт на выходе. Пока есть возможность контролировать свой код он будет быстрым настолько насколько ты сам его таковым сделаешь. Да есть std которая написана сторонними программистами, есть оптимизация компиляторами, которые на выходе выдают труднопонимаемый ассемблер, но в целом код можно контролировать.
Так что мое мнение: С++ (и другие бинарные языки) хорош тем что даёт как высокоуровневую абстракцию, так и контроль вниз до ассемблера. Иногда С++ чрезмерно сложен для простых задач -- тогда С идёт ему на замену. Я вот матлибу пишу на С, а игровую логику на С++. Бинарный код хорошо совместим между собой через соглашения о вызовах например, поэтому можно легко подключать библиотеки написанные на других бинарных языках. В C#, Java напротив требуются дополнительные механизмы для передачи данных из одной среды в другую. И дело не в том что они медленные, а в том что я не могу контролировать _насколько_ они будут медленными. Вот кстати C#, Java поощряют программисту не вылезать из предоставляемой песочницы, а с внешним миром контактировать через их библиотеки. Если так, то отпадает большинство проблем этих языков. В общем они для такого подхода и разрабатывались. Но движки как правило достаточно разнородны чтобы обеспечить их разработку одним языком.
Так что вывод будет :StaticZ пишет: Я просто объяснил в чём для меня преимущество бинарных языков в вопросе контроля кода и чем контроль важен для оптимизации (и кстати безопасности в дальнейшем!).


StaticZ пишет: DXT и сжимает и ускоряет выборку из текстур. Гигабайт нарисованного вручную пиксельарта? В больших играх если текстуры не влезают в память -- их стримят параллельно (обычно сразу с диска, мимо озу), без фризов игры. А пока текстуры нет в памяти, вместо неё рисуется дамми-текстура, либо очень низкого разрешения, либо просто что-то процедурно сгенерированное, ну на худой конец просто монотонный цвет. А вот например у игр портированных с консолей часто есть проблемы. У ps4 8 гб общей памяти. Например игра watch dogs обычно прогружается туда целиком, ну или стримит по мере катания по локации, но не выгружает ничего. На пк её портировали таким образом что всё грузится в видеопамять и если её перестаёт хватать игра благополучно вылетает. Причем для высоких настроек графики требуется видеокарта с 6 гбайтами. Был бы в игре хороший стриминг, можно было бы обойтись 2гб видеопамяти наверняка.


StaticZ пишет: А кстати здесь никого потенциальных 3д-артистов нет?