Новый игровой движок

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

 

Ну, это поверхностное суждение. И так, тайлы и спрайты могут быть в несколько слоёв. Можно делать декорации мелкие, составные элементы, эффекты. Идём дальше, в 3д режиме никого не удивляют почему то сотни тысяч объектов, с десятками полигонов на каждый. Всё что доступно в 3д, можно реализовать в 2д. Делается просто, если слегка вопрос разжевать. Неохота всё расписывать, но делаем два буфера. В одном храним статические данные для спрайтов, во второй пишем всё что меняется, и индекс к дополнительным данным из статического буфера. Нам потребуется ну может 3-5 мегабайта перегонять из основной памяти в видеопамять. Текстуру, тоже можно не перезаливать. Если вся графика не лезет. То записываем, то что всегда надо, и оставляем остальную часть для сменяемой графики, и заменяем эту часть при смене уровня/локации. Так же можно уменьшить расход памяти,если вместо 32 битного цвета использовать палитровую графику.
Гугл мне сказал, что это всё можно провернуть и на Гогот и на Юнити, но на чистом OpenGL будет чуть быстрее. В случае палитровой графики, если палитра отличная от 256 цветов, то я огребу кучу геморроя.

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

 

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

 

Это не важно, от игры зависит. Для тетриса больше и не надо. Большинство движков (самописных) на ней базируется. Если бы там чуть больше было возможностей, то и движков бы меньше писали )) 3 версия, так вроде там уже всё наоборот переусложнили...

 

В 3D режиме не нужно каждый кадр перегружать заново все текстуры и расчитывать как и что на кого наложится, а в 2D нужно, видяха при помощи программера будет накладывать спрайты с самого нижнего слой за слоем, причем копировать спрайт полностю, даже если от него будет видна всего одна линия. Наверное есть смысл рендерить мелкую графику в обычную память(которая намного быстрее записи в видеопамять) по оптимизированным алгоритмам, сокращая ненужные копирования, хоть миллион спрайтов, лишь бы CPU поспевал. И только в самом конце скопировать законченный кадр на реальный экран.

 

Ну посчитай, для 2д, используется обычно простой шейдер, который берёт, данные из текстуры по координатам и всё. Таких пикселей видеокарта из 2010года (плюс минус год), скажем ATI 5750 около 180 млн должна прогонять, флагманы тех лет раза в 3-4 больше тянут. (примерно 180 тысяч спрайтов 32х32). Ты в реальной программе не упрёшься в эти цифры. Если тормозит, значит делаешь что-то не так.
Главная проблема, это обычно данные которые идут от CPU для видеокарты, и если как я описал выше, то их будет мало. Если посмотреть код, то многие движки, не пытаются уменьшить объём передаваемых данных по шине, не то что не сжимают данные, а беспечно их наращивают. Вот на кой в 2д координаты передавать двумя числами с плавающей точкой (32х2=64 бита), когда размеры экрана... Уместятся в два 16 битных числа, в два раза меньше. Текстурные можно уже хранить там. В общем если оптимизировать под конкретное дело, то 200к спрайтов можно вывести будет, на нормальных видюхах, которые были выпущены в последние 15 лет.
Еще можно поэксперементировать, с чтением пикселя в шедере texelFetch, dascard или z-буфер использовать. Просто не надо игнорировать то что есть в 3д. А если выводить как по умолчанию sdl и sfml делают, то пределом при нормальном фпс будут 8-12к спрайтов.