SDL infinite sprite

делашь цикл, считаешь кадры, в определенный момент рисуешь со смещением...

Один из вариантов уже подсказали. Если хотите действительно красивые облака - копайте в сторону шума перлина, если я ничего нигде не напутал.

А новый фрейм рисовать как? Я действительно алгоритм не понимаю

В интерфейс игры типа «Mario Br.» вряд ли влезут красивые облака на общем фоне. Пока скилл оттачиваю на точном клоне со спрайтами, срезанными с оригинала. В продакшен такую не выставишь, но логику отработать поможет

В DX и OpenGL можно просто смещать текстурные координаты.

А новый фрейм рисовать как? Я действительно алгоритм не понимаю

ничего рисовать не нужно, все спрайты нужно грузить/генерировать/рисовать заранее перед игрой либо перед загрузкой уровня

отрисовывая ее хвост у изголовья?

Рисуй два раза просто:

    +--------------+
 /~_|~~^\_    /~_~~|^\_
(   |     )  (     |   )
\~~^|~~_^^   \~~^~~|_^^
    |              |
    |              |
    |              |
    +--------------+

так вот и представлял - создаем один спрайт(если облачка перемещаются[так захотелось попробовать]), двигаем медленно влево, когда доходим до точки склейки рисуем второе облако(на самом деле группу, но не важно, это спрайт), доходим до точки невидимости первого, удаляем его, повторяем цикл. После всего этого остался один вопрос: как заставить прятаться левый край спрайта раньше границы окна? Пробовал surface толкать в SDL_SetClipRect() с заранее созданным прямоугольником(выделением) нужной области, но похоже не понял для чего он нужен - не сработал.

    +---------------+
    |+-------------+|
    ||~~^\_    /~_~||
    ||     )  (    ||
    ||~~_^^   \~~^~||
    ||             ||
    ||             ||
    |+-------------+|
    +---------------+

Тогда расчитай видимый прямоугольник и передавай его в SDL_UpperBlit

Ух-ты! Спасибо!

Костыли itt. Каждому облачку — по своему спрайту, проверка области видимости и отсечение того, что не попадает в кадр, должны быть встроены в движок и быть универсальными.

// dmfd

должны быть встроены в движок и быть универсальными

должны быть встроенными в OpenGL. поправил тебя.

Зайчатки frustum culling'а в opengl таки предусмотрены: треугольник, попадающий в кадр частично, по стандарту должен биться на несколько треугольников, полностью попадающих в кадр, и растеризация делается только для них. Но более сильная оптимизация всё равно ложится на движок, что правильно: человек, программирующий мерзкое 3D, должен страдать.

Это просто камень в огород sdl? Тогда не интересно - начинать с него легко и просто

Как вы пришли к такому странному выводу? Это камень в огород вашего движка.

frustum culling

вон отсюда

более сильная оптимизация

оп рисует пачку спрайтов, о какой оптимизации должна идти речь? пусть хоть 200 раз свою сцену отрендерит. как только речь зайдет о высокополигональных сценах и шейдерах на 5 экранов - позовете.

оп рисует пачку спрайтов, о какой оптимизации должна идти речь?

Я тогда не понимаю, при чём здесь была ваша фраза про "встроены в opengl". Можете не рассказывать, мне это совершенно не интересно.

поверх закрасил и все :) Всем спасибки в этом чатике!