Клёво. Используют ли эту библиотеку для десктопного gui-софта? И легче ли это в сравнении got/qt/tk...?

Есть примеры десктопного софта(не игр) на ней?

Используют ли эту библиотеку для десктопного gui-софта?

Нет.

это инструменты, предназначенные для разных целей

удивительно, но в большинстве случаев требуется SDL версии 1.2 , а 2.0 не катит! почему так я до сих пор не понимаю... может Вы знаете?

Вообще SDL1 и SDL2 между собой несовместимы, так что старый софт, который не портировали, будет требовать SDL 1.2

There is no compatibility layer built in to SDL2. If an API changed for 2.0, we've changed or removed the old functions where it makes sense. If you point your 1.2 program at the 2.0 headers, it will probably fail to compile.

http://wiki.libsdl.org/MigrationGuide

Есть примеры десктопного софта(не игр) на ней?

sfxr, milkytracker

Но вообще для написания гуя SDL не годится, условно всё что он умеет, это блиттить картинку на экран, играть звук и считывать с устройств ввода. Это довольно низкоуровневая библиотека.

Я наверно перепутал его с freeglut или с чем-то еще таким.

Они (2 и 1) вместе в системе нормально уживаются, это штатная ситуация?

API разный от слова совсем. Под SDL подразумевают или 1.2, или 2.0. Но чтобы не было путаницы, если проект использует 2.0, то так и пишется — SDL2.

Да. Инклуды лежат в SDL2, в либы называются libSDL2.

это штатная ситуация?

Почему нет? Так с очень многими библиотеками.

Поэтому и поинтересовался, вдруг не так

Великая вещь! Великая! Она помогает стандартизировать разработку игр под Linux. И поэтому, тот кто не использует ее - великий м***к!

Примеры десктопного софта на базе SDL

Используют ли эту библиотеку для десктопного gui-софта?

Да.

Есть примеры десктопного софта(не игр) на ней?

MilkyTracker – кросс-платформенная программа для создания и редактирования трекерной музыки.

http://milkytracker.titandemo.org
MilkyTracker 1.0.0

Эта великая вещь так и не научилась переключать разрешение экрана

Ну,вот! Глянул скриншоты - красиво. Спасибо.

Самое забавное, что в 1.2 вполне умела. Там вообще SDL_SetVideoMode. :)

Это не заслуга sdl. Sdl там только окно открывает

Gary> Но вообще для написания гуя SDL не годится, условно всё что он умеет, это блиттить картинку на экран, играть звук и считывать с устройств ввода

А что «высокоуровневого» вам нужно-то??? Понятно, что окон там не будет, но это решаемо. Откровенно, венда как раз и лажает в том, что слишком много делает в бэкграунде, что коверкает всю логику в приложении.

Но зачем? Это довольно бесполезная фишка

Ну вот в Qt и GTK+ есть хотя бы готовые виджеты и обработка событий от них, я уже молчу про всё остальное

Окна, кстати, в SDL2 есть

Я пишу на SDL во время секса. Настолько плох мой секс.

SDL is written in C

бальзам на душу. немедленно пробую. спасибо автору новости за то, что я теперь знаю за SDL

эта. а есть книги/учебники на Великом и могучем? (на языке вероятного противника я читать умею, но на родном, все же лучше :)

Использую эту библиотеку. Отличная штука.

чтобы не блиттитть на экран 1080p ккртинку 320x240.
Даже если сделать изменение разрешенмя через fbo, это будет медленнее работать т.к в итоге будет блиттиться и прогоняться через пиксельный шейдер весь экран каждый кадр.

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

Во-вторых, что ты будешь делать, есть на целевом устройстве нет разрешения 320x240?

очевидно - использовать те разрешения которые есть.
Любая отрисовка через opengl - прогон через фрагментный шейдер за исключением некоторых редких случаев когда оборудование использует ffp.
А изменение разрешения нужно для относительно старых платформ, где не всегда можно себе позволить лишний раз прогнать через fbo картинку (и то если этот fbo вообще есть. А если нет что? glReadPixels??? enjoy your 10fps)

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

Не совсем. Там еще есть https://wiki.libsdl.org/SDL_StartTextInput и какие-то SDL_TEXTINPUT, SDL_TEXTEDITING эвенты, которые при этом срабатывают, т.е. есть какая-то поддержка языков ввода: https://wiki.libsdl.org/Tutorials/TextInput

Ну а в остальном эта штука по своей сути очень напоминает какой-то XCB или Xlib по части обработки событий мыши/клавиатуры, отрисовки всякой ерунды.

SDL2 - это новая библиотека разработанная при активной поддержке Valve. С SDL1 несовместима, но это к лучшему.

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

Хотя если интересно, почти каждая опенсорсная игра его использует: можно поглядеть в сорцы игры.

Все она умеет, с.м. SDL_SetWindowDisplayMode.

Минорщина.

На первой работе пилили гуй для касс ресторанов как раз на sdl

очевидно - использовать те разрешения которые есть.

Ну и как ты будешь скейлить тогда? У тебя же картинка под другое разрешение

Любая отрисовка через opengl - прогон через фрагментный шейдер за исключением некоторых редких случаев когда оборудование использует ffp.

Погоди, я-то думал тебе представился какой-то дополнительный масштабирующий шейдер, сейчас ты вообще говоришь что через OpenGL рисовать нельзя потому видеокарта производит растеризацию? На каких это платформах фрагментный шейдер из двух строк ведёт за собой гроб крест 10 фпс?

Лол. Так а почему SDL выбрали? Там какие-то супер фичи для гуя есть?

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

10fps там где fbo нет т.к glReadPixels достаточно медленный.
Однако когда fbo есть - не очень всё хорошо. На системах с низкими частотами памяти и большими дисплеями можно получить просадку fps в 2 раза на достаточно простой графике.Проблема будет заметна на мобильных платформах и на старых пк 2004-2005 года. И если игру работавшую хорошо тогда перенести на современный SDL - обидно будет терять такую возможность. Понятно, что эта проблема незаметна если используются какие-то сложные шейдеры - оно там всё равно нормально работать не будет.
У меня даже на Intel HD Graphics 2500 дополнительный рендер через fbo отнимает треть fps. Но это на быстрой памяти. А что будет на всяких виндопланшетах, в которые помимо медленного атома запросто поставят 1080 дисплей?

Да? А зачем тогда 2 отдельных флага SDL_WINDOW_FULLSCREEN и SDL_WINDOW_FULLSCREEN_DESKTOP? Только что проверил - все корректно работает. Вот просто изменить разрешение десктопа, чтобы на нем не было SDL окна - нельзя и это сделано намеренно, т.к. пользователей бесит когда они видят как искажается их десктоп, да еще и если вылетит при этом не изменив обратно. Просто разрешение десктопа пользователь сам меняет в настройках системы, эдакая защита от дурака.

само окно нормально выглядит. Только оно размером не с экран в итоге, а с рабочий стол. И если ты рисуешь там что-то через opengl, то вьювпорт будет попадать не туда, куда надо. Если используется какой-либо композитинг без отключения редиректа (ну захочу я например экранную клавиатуру поверх нарисовать) - будет оверхед от текстуры всего этого огромного окна.

Нет, это тут не причем. Даже создав не полноэкранное окно размер фреймбуффера может отличаться от размера окна. Именно для этого есть SDL_GetWindowSize и SDL_GL_GetDrawableSize (glfwGetWindowSize/glfwGetFramebufferSize для glfw etc, это есть везде). При этом при SDL_WINDOW_FULLSCREEN вы правы, изменения разрешения не произойдет и соотношение размеров окно/буфер изменится, но оно и могло не совпадать. При SDL_WINDOW_FULLSCREEN_DESKTOP же изменение разрешения произойдет, точно так же как в SDL 1.2, а соотношение будет таким же.

Причем здесь вообще FBO/glReadPixels? Какой ещё дополнительный рендер через FBO? Или я что-то не понимаю, или ты, давай разбираться.

На нефиксированном пайплайне для того чтоб отрисовать простую картинку достаточно одного вершинного и одного фрагментного шейдера. Мастшабирование происходит во фрагментом шейдере. Откуда «дополнительный прогон»?

SDL_WINDOW_FULLSCREEN_DESKTOP не позволяет задать разрешение отличное от текущего разрешения экрана. внимательнее читай доки. В итоге у нас просто не остаётся способа изменить разрешение средствами SDL - размер opengl буффера будет неправильным.

Прошу прощения, перепутал SDL_WINDOW_FULLSCREEN и SDL_WINDOW_FULLSCREEN_DESKTOP местами. При SDL_WINDOW_FULLSCREEN происходит изменение видеорежима.

fbo это единственный способ изменить разрешение средствами SDL и opengl - т.е не прибегая к обращениям к иксам/winapi напрямую. Вместо того чтобы изменять разрешение открывается полноэкранное окно и делается рендер в текстуру с последующим растягиванием её на весь экран. Source и GoldSource при переходе на SDL2 стали менять разрешение через fbo т.к нормальная смена разрешения там не работает.

Вместо того чтобы изменять разрешение открывается полноэкранное окно и делается рендер в текстуру с последующим растягиванием её на весь экран.

ЗАЧЕМ?

Я уже описал как оно происходит. Он изменяет реальное разрешение экрана оставляя окно растянутым до виртуального. В результате получается неправильный размер окна. Придётся или городить хаки с glViewPort и преобразованием координат мыши даже не зная как их сдвинуть корректно или не использовать такую смену разрешения.

Потому что это работает в отличие от SDL_WINDOW_FULLSCREEN

Нет, SDL2 прекрасно меняет видеорежимы, вот это в коде:

int
SDL_SetWindowDisplayMode(SDL_Window * window, const SDL_DisplayMode * mode)
{
    CHECK_WINDOW_MAGIC(window, -1);

    if (mode) {
        window->fullscreen_mode = *mode;
    } else {
        SDL_zero(window->fullscreen_mode);
    }

    if (FULLSCREEN_VISIBLE(window) && (window->flags & SDL_WINDOW_FULLSCREEN_DESKTOP) != SDL_WINDOW_FULLSCREEN_DESKTOP) {
        SDL_DisplayMode fullscreen_mode;
        if (SDL_GetWindowDisplayMode(window, &fullscreen_mode) == 0) {
            SDL_SetDisplayModeForDisplay(SDL_GetDisplayForWindow(window), &fullscreen_mode);
        }
    }
    return 0;
}

SDL_SetDisplayModeForDisplay не публична специально, причины выше.