Достаточно знать что в фреймбуффер все пойдет как если бы выполнялось в порядке вызова drawcall-ов, в внутри drawcall-а в порядке полигонов и буфере

Зачем сортировать на CPU, если это видюха сама умеет?

Видюха не умеет сортировать прозрачность.

Смотри пдфки про Order Independent Transparency от нвдида, и то там не общий случай.

Если есть полупрозрачность, то надо на CPU

Буффер глубины надо кстати, это уменьшает филлрейт.

Тогда рисовать в обратном порядке

Или depth-prepass делать

Ну да

Я ж говорю надо

Но опять же, только без полупрозрачности

Да

А если у тебя кругом полупрозрачность, то не парься и рисуй снизу вверх

Это кстати тоже отдельная попа-боль по началу. Вроде ты собрался делать пиксельную 2d игру, но игровой движок почему-то оперирует float-ами и у него ещё есть какой-то антиалисинг. "Нахрена оно мне" - думаешь ты. Но ни куда не деться - там везде эти float-ы торчат.
При этом приходится иногда оперировать половинными координатами, что бы пиксели текусты попали ровно в пиксели экрана.

ну оперируй физическими пикселями вместо логических

Я делал в два пасса, сначала рисуем всё непрозрачное снизу вверх и пишем в глубину, затем перестаём писать и рисуем всё прозрачное с тестом глубины.

И как это делать, если там внутри всё на 3d полигонах, текстурах и шейдерах?

Там всё не на 3д-полигонах.

Хотя тут наверное дело в сырых реализациях разных штук для игровых движков. Начиная от того что origin-point у тех же спрайтов находится в середине спрайта, а не в его углу. И продолжая тем что рисование произвольного прямоугольника делается как шейдер "обводка" для полигона. И центры "пикселей" этой обводки делаются ровно по границе прямоугольника и при выводе на экран попадают в промежуток между фигическими пикселями. Приходится исходный полигон уменьшать в размерах на 0.5 пикселя с каждой стороны.

Что бы всего этого не было, надо видимо нормальный 2d фреймворк, который всё это учитывает.