>своего убийцу юнити
Расскажешь?
Хуле там рассказывать? Школоподелие с косо прилепленным lua которое пробрасывает в lua SDL API, чтобы не надо было каждый раз по полчаса канпелять сишный код когда я хочу передвинуть спрайт на пиксель.
Разве от SDL не всего несколько строчек нужно? Ты же его юзаешь только для создания окошка и GL-дескриптора(или как там его).
А графон месишь уже GL-ом, а не SDL.
Simple Directmedia Layer
И сдл-ем только свапаешь буферы при выводе кадра. Ну и управление считываешь.
А графон месишь уже GL-ом, а не SDL.
Simple Directmedia Layer
И сдл-ем только свапаешь буферы при выводе кадра. Ну и управление считываешь.
Я решил зарубиться в него по хардкору, так как люблю извращения.
Просто сначала они в доках пишут мол хуячте все в аппаратно ускоренный SDL_Texture, и потом будете их аппаратно-ускоренно выводить на аппаратно-ускоренный экран.
А потом оказывается, что когда начинаешь собирать тайловый бэкграунд тормоза начинаются при количестве тайлов меньше 500 да хуле там, 100 рендеров уже вызывает атата ,
Я недопонял юмор в этой ситуации. Где обещанное ускорение? Если я сам должен строить конвеер отрисовки кадра да я его и так уже построил ебана, я жэ в бэкбуффер рисую , то нахуя было топить в туториалах за использование текстур, которые как оказывается используются как непонятная хуйня, которая загружается в видеопамять и лочится там насмерть, и чтобы туда что-то дорисовать нужно выгрузить ВЕСЬ ДЕСТИНЕЙШЕН-буфер в раму, выгрузить СОРЦ текстуру в руму, нарисовать туда и потом загрузить его обратно в видеокарту. Охуеть просто. Что за приколы? Нахуя тогда эти функции вообще есть?
Может я невкупаю в аппаратно-ускоренную фишку или там надо какую-то магию применять?
Может у тебя комп медленный и видюха без видеопамяти?
SDL тебе нужен для работы с устройствами ввода и для инициализации OpenGL. Не используй больше ничего.
Естественно медленный. Но оно тормозит на 100+ рендерах на 1280х960xARGB, когда я ему говорю "скопируй текстуру из атласа (x.y.w.h) в текстуру-буффер (x.y,w,h)" сборка тайлового бэкграунда .
Ту же операцию оно на сурфейсах пережевывает без проблем.
Среди меня сейчас идут жаркие дискуссии на тему "я такой тупой и недогоняю чего или это так и задумано и прям всамом деле нужно сложные кадры собирать в оперативке а в текстуру они помещаются просто чтобы было потому, что модно-стильно-молодежно".
Подобные загоны на быстром компе работают быстро, но по профайлингу тот же затык что и на "медленном" т..е. рендер-копи сжирает 90% времени, что не есть хорошо, так как если постпроцессить фрейм дальше то там вообще начнется лютый пиздец, ведь я не делаю вообще нихуя сложного - просто память копирую из одного места в другое.
Потому что атласы собирай.
А вообще да, обычно SDL используется как более менее продакшн-реди запускайка для опенгла с клевыми батарейками в виде потоков, звука и инпута гейпадов.
Тому что ты идиот.
Никто не использует SDL для рендера.
>Тому что ты идиот.
>Никто не использует SDL для рендера.
Вот и мне всегда казалось, что SDL - это такой навороченый глут который типа уже взрослый и со всеми наворотами.
Он навороченный, но не для рендера. Слой изоляции от железа.
Лол, сам хз чё не так
Итак резюме на текущий момент:
Что было:
SDL Блит картинки без всинка 2100+ итераций в секунду на встроененом в ноут интеле (именно поэтому я вообще поверил в то, что можно на SDL рисовать графу).
Что есть:
После того, как подчистил некоторые куски кода от дампов с помощью std::cout (!) - ситуация с тормозами выровнялась до приемлемой (хотя сейчас статичный тайловый бек без анимаций, но бегает пара мобов + плеер).
Что говорят в интернете:
SDL Hardware accelerated renderer + vsync - тормозное говно слабо управляемое в части vsync (возможно чуваки пиздят и вертикальная синхронизация нормально вырубается уже, так как инфа старовата).
Че говорит гугол - SDL рендер сасает (где-то натыкался на тесты рендер копи текстурки в 1 пиксель занимает 20+ больше времени чем просто поставить пиксель), поэтому крузис на нем написать можно, но будет тормозить.
Способы акселерации когда опять упрусь в производительность:
Внезапно, он есть. Заключается в полном выбрасывании SDL2 и возврате в старое злое SDL1, когда весь конвеер рисует в стримминговую текстуру с помощью memcpy, а потом оно в свою очередь презентается в конце конвеера (кстати, нельзя вынести отрисовку в отдельный поток ибо не тред сейф операция, кекне то, чтобы я это умел, но оказывается, мультрединг должен организовываться не по принципу " основной поток форкает процесс отрисовки " а наоборот - "цикл рендера форкает основной процесс").
Что было:
SDL Блит картинки без всинка 2100+ итераций в секунду на встроененом в ноут интеле (именно поэтому я вообще поверил в то, что можно на SDL рисовать графу).
Что есть:
После того, как подчистил некоторые куски кода от дампов с помощью std::cout (!) - ситуация с тормозами выровнялась до приемлемой (хотя сейчас статичный тайловый бек без анимаций, но бегает пара мобов + плеер).
Что говорят в интернете:
SDL Hardware accelerated renderer + vsync - тормозное говно слабо управляемое в части vsync (возможно чуваки пиздят и вертикальная синхронизация нормально вырубается уже, так как инфа старовата).
Че говорит гугол - SDL рендер сасает (где-то натыкался на тесты рендер копи текстурки в 1 пиксель занимает 20+ больше времени чем просто поставить пиксель), поэтому крузис на нем написать можно, но будет тормозить.
Способы акселерации когда опять упрусь в производительность:
Внезапно, он есть. Заключается в полном выбрасывании SDL2 и возврате в старое злое SDL1, когда весь конвеер рисует в стримминговую текстуру с помощью memcpy, а потом оно в свою очередь презентается в конце конвеера (кстати, нельзя вынести отрисовку в отдельный поток ибо не тред сейф операция, кекне то, чтобы я это умел, но оказывается, мультрединг должен организовываться не по принципу " основной поток форкает процесс отрисовки " а наоборот - "цикл рендера форкает основной процесс").
>Заключается в полном выбрасывании SDL2 и возврате в старое злое SDL1, когда весь конвеер рисует в стримминговую текстуру с помощью memcpy
А квады с текстурками из атласа с анимацией, не?
Используй OpenGL и не еби себя в анус вилкой.
Так уже. Поэтому и удивился просадке. Ведь я все картинки конверчу в текстуры. И они должны по идее дальше вариться в видяхе. А копировать куски памяти должен любой гпу уметь. Тем более что я не стопицот спрайтов ворочаю а всего пару соток.
Ты идиот?
Ммм. Чем https://love2d.org не угодил?
Почти все твои проблемы уже решили до тебя, включая lua с jit, за который ты отдельное спасибо скажешь.
Чмонь, ты б ему еще гейммейкер посоветовал.
Ты крутой прогер? Я вапобще не понимаю как можно сделать редактор типа Юнити, в принципе не понимаю вообще низкоуровневого программирования.
Я пиляю своего убийцу юнити, и все у меня было хорошо (кнопка на патреон и майнер битков уже есть), до тех пор пока я не добрался до графической подсистемы.
И тут я столкнулся с охуительнейшим часом досуга в мире юникс, а именно с багом фичей SDL2 которая заключается в том, что SDL_RenderCopy - ебаное тормозное говнище которое ставит раком любую систему уже при 20-30 вызовах в секунду (и это блядь при том, что я делаю рендер в текстуру которой выставлен SDL_TEXTUREACCESS_TARGET).
В интернете пацаны говорят что надо делать через отрисовку всего говна в буфер с SDL_TEXTUREACCESS_STREAMING, что по факту превращает текстуру в SDL_Surface с более другим типом (в который мы так же блитим сурфейсы как делали это диды на SDL1.x).
Если кто-нибудь насиловал SDL2, это действительно так и SDL_Texture это наебалово, а я повелся как лох? Всмысле того, что хуй мне а не аппаратно ускоренный рендер в чем ускорение блядь, если я все, что надо делают в RAM с помощью CPU а не просто говорю GPU - скопируй кусок из оттуда в вон туда а потом хуйни все в скринбуффер когда я делаю Render_Present?