Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз мультимедийной библиотеки SDL 3.4.0"	+/–
Сообщение от opennews (??), 01-Янв-26, 09:35
Представлен релиз библиотеки SDL 3.4.0 (Simple DirectMedia Layer). Библиотека нацелена на упрощение написания игр и мультимедийных приложений, и предоставляет такие возможности, как аппаратно-ускоренный вывод 2D- и 3D-графики, обработка ввода, воспроизведение звука и вывод 3D через OpenGL, OpenGL ES, Metal, Direct3D или Vulkan. Код написан на языке Си и распространяется под лицензией Zlib. Предоставляются обвязки для использования SDL в проектах на различных языках программирования... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64537
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 01-Янв-26, 09:35	+/–
Неплохой релиз. Жаль, что поддержку png впихнули, но это связано с поддержкой работы с иконками в трее, так что ладно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #5, #25, #29

2. Сообщение от Аноним (2), 01-Янв-26, 10:58	+6 +/–
Что плохого в пнг?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

3. Сообщение от Мемоним (?), 01-Янв-26, 10:58	+/–
> SDL_PROP_GPU_DEVICE_CREATE_VULKAN_REQUIRE_HARDWARE_ACCELERATION_BOOLEA Прям напомнило ОченьДлиннаяФункцияНепонятногоНазначенияИмениБорисаНуралиева()
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

4. Сообщение от Аноним (4), 01-Янв-26, 11:36	–2 +/–
В некоторых прогах до сих пор сидят на 1.0 из за косяков 2.0, а тут 3.0. Я на нем еще ничего напсианного не видно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #36, #48

5. Сообщение от Аноним (5), 01-Янв-26, 11:57	+1 +/–
Сильно жаль? Прям вот очень? Ок, держи нас в курсе. А то формат-то офигенный, а ты так прям весь расстроился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11

6. Сообщение от Аноним (6), 01-Янв-26, 12:56	+/–
Это нормально, только бы не дропали старые версии, переписывать на новое может оказаться некому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от Аноним (7), 01-Янв-26, 12:57	+/–
хотели так SDLPGPUDEVCVULREHARDACCBOOL?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #9

9. Сообщение от Мемоним (?), 01-Янв-26, 13:50	–2 +/–
Хотели SDL.vkGPUDevice.ReqHWA
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #24

10. Сообщение от Аноним (1), 01-Янв-26, 13:51	+/–
windows.h здорового человека
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

11. Сообщение от Аноним (1), 01-Янв-26, 13:52	+/–
да, ведь png как и bmp и wav никакого отношения к прослойке для работы с оборудованием не имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #52

12. Сообщение от Аноним (12), 01-Янв-26, 13:56	+2 +/–
windows.h здорового человека это mingw
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (13), 01-Янв-26, 14:18	+1 +/–
Does SDL support PCX, JPG, PNG, etc... The BMP and WAV file loaders included with SDL are simple examples demonstrating how to load an image and sound format. You should be able to write your own reader for any format. The main library is supposed to be fast and small, and so does not include any additional loaders
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #14

14. Сообщение от Аноним (13), 01-Янв-26, 14:22	+/–
>>simple examples sdl_wave.c на 2000 строк прикольный "простой" пример.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #51

16. Сообщение от рассерженый фанат sdl (?), 01-Янв-26, 14:36	–2 +/–
Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL/Direct3D/Metal/Vulkan Ну и что поддержка png, bmp, wav (включая ms-adpcm и ima-adpcm) делает в данной библиотеке, когда для этих целей существуют sdl_image и sdl_mixer?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17

17. Сообщение от рассерженый фанат sdl (?), 01-Янв-26, 14:46	–2 +/–
sdl это bloatware. они добавили 2d api, gpu api и кучу других абстракций. это никак не low level access
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #19, #22

18. Сообщение от Аноним (18), 01-Янв-26, 14:46	+/–
>Добавлена встроенная поддержка изображений в формате PNG, для работы с которыми предложены функции SDL_LoadPNG Я надеюсь не такой идиотизм, как в большинстве опенсорсных игр, когда png распаковывается в RGB-массив, когда простенькие 2D спрайтовые игры уровня 90х жрут память как не в себя, потому что разработчик не заморочился сделать компрессию текстур, кеширование и  memory-mapping. А не заморочился он сделать компрессию текстур потому, что это нетривиально: Compressonator говно недоделанное, которое в виде пакета не сделано, а других опенсорсных слоёв абстракции, которые умеют в интроспекцию видеокарты на поддержку форматов и выбор нужного - у нас нет. Также basis_universal и etcpak (это кодировщики в форматы сжатых текстур) в виде либ недоступны. В геймдеве же в профессиональных продуктах как водится - для каждой игры всё с нуля делают, а потом в опенсорс не выкладывают, в лучшем случае - из предыдущего проекта тащат. Без автоматического использования сжатых текстур по-умолчанию ничего хорошего наличие этого API не принесёт.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #23, #28

19. Сообщение от рассерженый фанат sdl (?), 01-Янв-26, 14:52	–1 +/–
а еще эти audiostream, которые конвертируют сэмплы на лету перед подачей на аудиокарту. Так и до интеграции lua недалеко
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #30

20. Сообщение от Аноним (20), 01-Янв-26, 15:23	+/–
Не говоря уже о том, что во многих случаях картинка спрайта сдела без изврата, и её можно аппроксимировать цветными треугольниками, и соответственно вместо текстуры хранить эти треугольники, экономяя память и получив автомасштабирование.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

22. Сообщение от Аноним (51), 01-Янв-26, 17:50	+/–
> они добавили 2d api, gpu api и кучу других абстракций. это никак не low level access В таких абстракциях как бы и весь смысл SDL. Если тебе нужен "low level access", то зачем тебе SDL? > sdl это bloatware Нет, потому что вся подобная функциональность отключается флажками компиляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #40

23. Сообщение от Аноним (51), 01-Янв-26, 18:02	+2 +/–
> простенькие 2D спрайтовые игры уровня 90х жрут память как не в себя, потому что разработчик не заморочился сделать компрессию текстур Ты реально вместо игры в "2D спрайтовую игру" сидишь и замеряешь потребление видеопамяти? Это такое проявление ОКР, или ты просто решил кекспертизы навалить? Эксперт, а ты не задумывался над тем что компрессия текстур - это lossy процесс, и для 2D его не делают потому, что никто не хочет видеть угашенные по цветам/деталям спрайты и задники? Это первое. > Без автоматического использования сжатых текстур по-умолчанию ничего хорошего наличие этого API не принесёт. Ну почему же: вот уже принесло подгоревшие гузна опеннетных псевдоэкспертов, которые "слышать звон" умеют, а головай думать - не очень. Сжимать текстуры по-умалчанию, убивая тем самым ее цвет и детали - это идея 10/10.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #141

24. Сообщение от Аноним (7), 01-Янв-26, 18:04	+/–
//github.com/libsdl-org/SDL/blob/main/include/SDL3/SDL_gpu.h строка 2354 #define SDL_PROP_GPU_DEVICE_CREATE_VULKAN_REQUIRE_HARDWARE_ACCELERATION_BOOLEAN         "SDL.gpu.device.create.vulkan.requirehardwareacceleration" что-то изменилось?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #72

25. Сообщение от Аноним (25), 01-Янв-26, 18:28	+/–
Это мультимедийная библиотека, там вообще должны быть все видео, аудио и фото форматы, по идее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #31, #66

26. Сообщение от Аноним (51), 01-Янв-26, 18:29	+3 +/–
> API 3D GPU и API для двумерной отрисовки Самое большое разачарование с выходом SDL 3 стало то, что они так и не привели SDL_Renderer в человеческий вид. Высокоуровневое 2D API, в котором нельзя нарисовать повернутый на N градусов прямоугольик, не говоря уже о банальном круге - это какой-то позор. Зачем было добавлять такой огрызок - так и осталось для меня загадкой.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68, #96

27. Сообщение от Аноним (27), 01-Янв-26, 18:49	+/–
> Добавлена встроенная поддержка изображений в формате PNG, для работы с которыми предложены функции SDL_LoadPNG(), SDL_LoadPNG_IO(), SDL_SavePNG() и SDL_SavePNG_IO(). Для определения формата (PNG или BMP) и загрузки изображений в качестве поверхностей добавлены функции SDL_LoadSurface() и SDL_LoadSurface_IO(). Так вот почему в OpenXRay (неофициальном порте Сталкера на Linux) Splash Screen в формате BMP. Походу, его показывают ещё до того, как запустилась сама игра (до появления окна с игрой). А значит, ранее был доступен только BMP.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34, #94

28. Сообщение от Аноним (28), 01-Янв-26, 19:00	+/–
>> поддержка изображений в формате PNG > Я надеюсь не такой идиотизм, как в большинстве опенсорсных игр, когда png распаковывается в RGB-массив, когда простенькие 2D спрайтовые игры уровня 90х жрут память как не в себя, потому что разработчик не заморочился сделать компрессию текстур, кеширование и  memory-mapping. Осталось только понять, как все то, что ты настрочил, относиться к SDL и цитируемой тобой поддержке загрузки PNG картинок в памятьв частности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #32

29. Сообщение от Аноним (29), 01-Янв-26, 19:44	+/–
> Жаль, что поддержку png впихнули, но это связано с поддержкой работы > с иконками в трее, так что ладно Его и так почти все перли - ибо популярный формат для ассетов и проч. Только приходилось добавочной SDLной либой-довеском его вкрячивать. И png уж явно популярнее BMP всяко. Хоть у них обоих и есть свои дурацкости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

30. Сообщение от Аноним (-), 01-Янв-26, 19:59	+/–
> а еще эти audiostream, которые конвертируют сэмплы на лету перед подачей на аудиокарту. То ли дело когда вон там апя и система умеет только 48000 какое, а у нас 22050 было - и у системы нет своего ресэмплера и микшера - так что SDL выдает жутко хрипатый крап. Пардон - но этот блоат вполне оправдан. Ибо абстрагирует взбрыки и заскоки ВСЕХ мыслимых систем - до ОДИНАКОВОГО common denominator на который уже можно уповать. Везде и всюду. Даже на всякой эзотерике если кто и туда ухитрится собрать сабжа. А собирают его под всяко разно. Скажем Android, Nintendo Switch, и наверное еще что-нибудь этакое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #38

31. Сообщение от Аноним (-), 01-Янв-26, 20:06	+2 +/–
> Это мультимедийная библиотека, там вообще должны быть все видео, аудио и > фото форматы, по идее Ты же лопнешь, деточка! Ffmpeg когда-нибудь видел? И как тебе оно? А теперь представь себе интеграцию оного - в libsdl! Он сразу раз в пять распухнет. В общем кому надо - берет ffmpeg отдельно, сам. А SDL немного другой мандат - simple directmedia layer. Т.е. апи абстракции вывода аудио, графония и обработки ввода для игр, плееров и проч. Чтою не париться особенностями каждой платформы в вооооон той игре допустим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #71

32. Сообщение от Аноним (32), 01-Янв-26, 20:17	–3 +/–
Что тут не понятного? SDLу не следовало экспортировать функцию SDL_LoadPNG в принципе. Должна была быть функция SDL_LoadImage(..., const char* path, const IMAGE_LOAD_CONFIG* config = &IMAGE_LOAD_DEFAULT_CONFIG, ...); где struct IMAGE_LOAD_CONFIG { IMAGE_FORMAT format; TEXTURE_COMPRESSION texture_compression; bool use_mmap: 1 = true; }; struct IMAGE_LOAD_CONFIG IMAGE_LOAD_DEFAULT_CONFIG = { .format = IMAGE_FORMAT_AUTO, .texture_compression = TEXTURE_COMPRESSION_AUTO, .use_mmap = true, }; При вызове она проверяет наличие файлов кеша, если они есть - мапит их, если нет - открывает файл-оригинал, создаёт кеш, закрывает файл-оригинал, мапит кеш. Свежесть кеша определять по хранимых в NTFS ADS/xattrах/сайдкарах хешу оригинального файла и дате изменения. По-другому - не взлетит. Оригинальным разрабам для разработки опенсорсных игр проще чтобы игра грузила оригинальные PNG - они их в графическом редакторе редактируют! Поэтому код их будет вокруг оригинальных PNG. И если сам фреймворк не будет делать всё это автоматически во время загрузки - то игра это делать не будет вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #39, #57

33. Сообщение от Аноним (33), 01-Янв-26, 20:30	+/–
Какой директ-то поддерживается? 12? 12.1?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #46, #53

34. Сообщение от Аноним (34), 01-Янв-26, 20:33	+/–
А толку. Новая версия ждалкера, говорят, глюкодром на уровне предыдущих. Вероятно в переиспользованном движке как был глюкодром, так и остался. Говорят что в новой версии даже A-Life доломали, я не понимаю, как это вообще возможно, была же рабочая версия. А в новом говорят нового ничего, тот же самый экспериенс, только с другим сюжетом и более высокими системными требованиями. Даже качать не буду, мне испорченных нервов от ЗП после того, как игра с определённой точки вылетать стала, и никакие патчи это не чинили, хватило. Пусть GSC сами наслаждаются своим глюкодромом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #35, #95

35. Сообщение от Аноним (27), 01-Янв-26, 20:45	+/–
> говорят Ну, я посмотрел пару десятков стримов и обзоров. Нормальный такой глюкодром, не больше чем у других AAA-игр. Коммент-то не про это. Выше спрашивали, зачем в SDL нужна поддержка PNG, когда она должна быть в SDL_image? Ну вот, походу, и ответ на вопрос - чтобы Splash Image показывать перед спавном окна, и следовательно до того, как в дело пошёл SDL_image.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #41

36. Сообщение от Аноним (36), 01-Янв-26, 20:46	+4 +/–
> В некоторых прогах до сих пор сидят на 1.0 А список этих прог можно в студию, или просто васян не осилил новую версию?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #44

37. Сообщение от Аноним (36), 01-Янв-26, 20:49	+/–
Ваш Radeon 9200 SE не покатит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

38. Сообщение от рассерженый фанат sdl (?), 01-Янв-26, 20:55	–1 +/–
>>умеет только 48000 какое при чем тут это? открывай в любом формате в каком пожелаешь. это не то же самое что автоконвертация на лету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #43, #45

39. Сообщение от Аноним (51), 01-Янв-26, 20:56	+/–
> SDLу не следовало экспортировать функцию SDL_LoadPNG в принципе. > Должна была быть [...] texture_compression Чел, иди проспись. Какое еще texture_compression, если SDL_LoadPNG грузит изображения в память (SDL_Surface), а не GPU? > При вызове она проверяет наличие файлов кеша, если они есть - мапит их, если нет - открывает файл-оригинал, создаёт кеш, закрывает файл-оригинал, мапит кеш. Свежесть кеша определять по хранимых в NTFS ADS/xattrах/сайдкарах хешу оригинального файла и дате изменения. Ммм, каеф. Функция загрузки картинки что-то там сношается с кешами на ФС и плодит там левые файлы. Да ты не иначе как гений разработки! > И если сам фреймворк не будет делать всё это автоматически во время загрузки - то игра это делать не будет вообще. Во второй раз вопрошаю: как твои дикие фантазии про кеши, фреймворки и компрессию текстур отняться к SDL?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #49

40. Сообщение от рассерженый фанат sdl (?), 01-Янв-26, 20:57	+/–
sdl нужен чтоб весь этот доступ одинаковым способом работал на разных ОС
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #42

41. Сообщение от рассерженый фанат sdl (?), 01-Янв-26, 20:59	+/–
нет, не для этого
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

42. Сообщение от Аноним (51), 01-Янв-26, 21:08	+/–
>> В таких абстракциях как бы и весь смысл SDL. > sdl нужен чтоб весь этот доступ одинаковым способом работал на разных ОС Я тебе буквально об этом и написал: абстракции как раз и дают этот "одинаковый способ".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #61

43. Сообщение от Аноним (51), 01-Янв-26, 21:11	+/–
>> То ли дело когда вон там апя и система умеет только 48000 какое, а у нас 22050 было > при чем тут это? открывай в любом формате в каком пожелаешь По-моему, ты не понимаешь, о чем говоришь. Какое "открывай в любом формате", если тебе чел прямо написал о случае, когда аудиокарта поддерживает только определенный набор сэмплрейтов и форматов сэмплов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

44. Сообщение от Аноним (51), 01-Янв-26, 21:13	+1 +/–
> А список этих прог можно в студию, или просто васян не осилил новую версию? Это те проги, на которые васяны забили еще в нулевых. Но виновата SDL2, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #47

45. Сообщение от Аноним (-), 01-Янв-26, 21:54	+/–
> при чем тут это? открывай в любом формате в каком пожелаешь. > это не то же самое что автоконвертация на лету. И потом мне что, самому ресемплить под возможности системы? Узнаая их для начала? А оно мне надо?! Сабж юзают как раз чтобы этим мозг не делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #60

46. Сообщение от Аноним (-), 01-Янв-26, 21:56	+/–
> Какой директ-то поддерживается? Сабж - не двигло 3D рендера как таковое, внезапно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #62

47. Сообщение от _kp (ok), 01-Янв-26, 23:32	+1 +/–
Если прога написана под какую то из версий sdl, и всё устраивает, сама прога работает, да и автор жив здоров, то только ради новой версии её не часто не переписывают. Могут быть более важные или интересные дела. Знаю, что если лень ковыряться что переломали в API вручную, перенос с помощью ИИ с одной версии SDL на другую делается за несколько секунд и первой же попытки. Но, бывает что не требуется ничего переписывать. Да и что добавится, например при портированиии с 1 на вторую версию? В основном, из того что заметно, мыльное масштабирование добавится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

48. Сообщение от Ilya Indigo (ok), 02-Янв-26, 00:16	+1 +/–
Например, в openSUSE Tumbleweed уже давно выкинyли SDL1 и SDL2 и используют только SDL3 с пакетами совместимости SDL1 и SDL2. Все игры/эмуляторы/соурспорты на SDL1 и SDL2 работают с SDL3 даже НЕ понимая этого, и для SDL1-приложений появляется обработка мультимедийных клавиш в полноэкранном режиме, чего в SDL1 не было! На чистом SDL3 работает, например dolphin-emu (эмулятор Nintendo GameCube/Wii) и прекрасно работает. > В некоторых прогах до сих пор сидят на 1.0 из за косяков 2.0 > из за косяков 2.0 Вы эту чушь сами только что придумали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #55, #75

49. Сообщение от Аноним (49), 02-Янв-26, 01:52	+/–
>если SDL_LoadPNG грузит изображения в память Изображения должны быть не в памяти, а на HDD. А в память их должна грузить либо ОС, либо конечное приложение. Иначе это дерьмо будет в свопе место занимать вместо того, чтобы из файла по новой грузиться, когда выгружено из оперативы. В свопе место то пофиг, но вот скорость обмена со свопом оставляет желать лучшего, да и лишние записи ни SSD ни HDD ресурса не прибавляют. И то, и другое можно реализовать через mmap: картинка записана на диск ровно так, как она в памяти. Если приложение управляет префетчингом - ему ничего не стоит память потрогать, и ОС картинку загрузит. Если приложение не управляет - ну будут лаги, если выгружена, но поменьше, чем при свопинге туда-сюда-обратно. >Во второй раз вопрошаю: как твои дикие фантазии про кеши, фреймворки и компрессию текстур отняться к SDL? SDL - это по сути слой абстракции и тулкит. Всё платформоспецифичное: ОС, видеокарта, детали реализации текстур - всё должно быть там. Разработчик же дёргает SDL API и не долбается с кешированием сам. Они  не долбаются. Поэтому, поскольку SDL не подолбалась - игры с 2D геймплеем уровня 90х занимают непомерное количество памяти и вгоняют систему в трешинг. У меня ЧАС игра грузилась. А у разраба меньше секунды, наверное: у него и камень топовый, чтобы PNG разжимать, все 230 мегабайт сжатых PNGшек, и SSD, и 64 гига оперативы, а может все 128.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #50, #56

50. Сообщение от Аноним (51), 02-Янв-26, 02:39	+1 +/–
Новая порция кекспертизы! > А в память их должна грузить [...] конечное приложение. Да. При помощи SDL_LoadPNG, например. > Иначе это дерьмо будет в свопе место занимать вместо того, чтобы из файла по новой грузиться, когда выгружено из оперативы. "Из оперативы выгружено", но при этом "в свопе место занимает"? Ты хоть сам понимаешь, что несешь? > И то, и другое можно реализовать через mmap: картинка записана на диск ровно так, как она в памяти Круто! Расскажи мне, как ты сделаешь mmap для ресурсов в андроидном APK. > ОС картинку загрузит Вот это магия! Оказывается, у нас ОС картинки грузит! Прямо в линуксячем ядре, наверное, PNG декодер зашит? > не долбается с кешированием сам. Они  не долбаются. Поэтому, поскольку SDL не подолбалась Сори, но я в этой каше так и не понял, кто кого долбал. > игры с 2D геймплеем уровня 90х занимают непомерное количество памяти и вгоняют систему в трешинг. У меня ЧАС игра грузилась Давай конкретное название игр, чтобы я мог оценить, на какой дряни ты их запускаешь, что у тебя аж "трешинг" и ЧАС загрузки. > А у разраба меньше секунды, наверное: у него и камень топовый, чтобы PNG разжимать Я так и не понял, как твои фантастические идеи ускорят разжимание PNG.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #54

51. Сообщение от Аноним (51), 02-Янв-26, 02:41	+/–
> sdl_wave.c на 2000 строк > прикольный "простой" пример. Ок, а за сколько строк С кода ты напишешь загрузчик WAV?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #58, #63

52. Сообщение от Аноним (51), 02-Янв-26, 02:42	–1 +/–
> да, ведь png как и bmp и wav никакого отношения к прослойке для работы с оборудованием не имеет. Они тебя как-то трогают, или что? В чем конкретно проблема?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #59, #64, #65

53. Сообщение от Аноним (53), 02-Янв-26, 03:50	+/–
Тебе какая разница, ты же не разработчик-пользователь. Ну а в конечном приложении для тебя всё укажут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

54. Сообщение от Аноним (54), 02-Янв-26, 06:00	+/–
>"Из оперативы выгружено", но при этом "в свопе место занимает"? Ты хоть сам понимаешь, что несешь? Я всё правильно несу. Что выгружено в своп - то в физической DRAM места не занимает. Для этого в своп и выгружают. >Круто! Расскажи мне, как ты сделаешь mmap для ресурсов в андроидном APK. Во-первых все APK полагается выравнивать zipalignом. Во-вторых в zip (а apk - это zip) есть поддержка хранения несжатых данных. В третьих, большое дерьмо хранят не в самих apk. >Прямо в линуксячем ядре, наверное, PNG декодер зашит? В видеокарте, аппаратный, с конца 90х. Только не PNG, а тайлов - компрессия текстур идёт потайлово. >Сори, но я в этой каше так и не понял, кто кого долбал. Ну это ведь хорошо, хоть настроение себе портить не будешь! >Давай конкретное название игр Endless Space. Так как игра постоянно обновляется, собирать надо из гита. >Я так и не понял, как твои фантастические идеи ускорят разжимание PNG. Очень просто: PNG не используется. Это формат для гимпа, а не для потребления игрой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #69, #84

55. Сообщение от Аноним (-), 02-Янв-26, 06:51	+/–
> Все игры/эмуляторы/соурспорты на SDL1 и SDL2 работают с SDL3 даже НЕ понимая > этого, Вот только у SDL1 пайплайн 2D вывода был намного быстрее если у вас GPU нету или он дрейний. А с SDL2 или 3 в подобной ситуации будет тот еще якорь. И все б ничего но при желании делать вот именно СВОЮ SDL программу - это те еще грабли. Потому что юзеры запускают сие на чем попало от малины до древнего интел интеграта и потом жутко делают мозг тем что тормозит. И вот тут Valve таки не совсем прав, пожалуй.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

56. Сообщение от Аноним (-), 02-Янв-26, 06:56	+/–
> Изображения должны быть не в памяти, а на HDD. А в память > их должна грузить либо ОС, либо конечное приложение. Ну так оно и загрузит - позвав вот эту либу. Потому что вот именно самому грузить PNG это довольно много возни так то. > Иначе это дерьмо будет в свопе место занимать вместо того, чтобы из файла по > новой грузиться, А если постоянно грузить картинку из файла - тем более упаси боже с HDD - это может вызывать нефиговейший ЛАГ. Ибо пока хард сгоняет головы, пока это прочтется, распакуется и проч - может пройти весьма измеримое время. Хотя любителям лагов, дерга и статтера - зайдет, конечно. > не управляет - ну будут лаги, если выгружена, но поменьше, чем > при свопинге туда-сюда-обратно. Хоть управляй, хоть не управляй а картинки грузятся не моментально. > SDL - это по сути слой абстракции и тулкит. Всё платформоспецифичное: ОС, > видеокарта, детали реализации текстур - всё должно быть там. Кому должно, что должно? > игры с 2D геймплеем уровня 90х занимают непомерное количество памяти и > вгоняют систему в трешинг. Да ничего оно не вгоняет особо. > У меня ЧАС игра грузилась. Что сие за конфиг и игра? А то может там новомодный геймдев текстур навесил больше чем у вас оперативки было...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #79

57. Сообщение от Аноним (51), 02-Янв-26, 06:57	+1 +/–
> При вызове она проверяет наличие файлов кеша, если они есть - мапит их, если нет - открывает файл-оригинал, создаёт кеш, закрывает файл-оригинал, мапит кеш А что именно ты предлагаешь кешировать, если у тебя и так есть "файл-оригинал"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #82

58. Сообщение от рассерженый фанат sdl (?), 02-Янв-26, 10:34	+/–
ну да, можно и lua было встроить. там ведь еще меньше 2000 строк понадобится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

59. Сообщение от рассерженый фанат sdl (?), 02-Янв-26, 10:36	+/–
bloated же. тебе нравится раздутый софт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #78

60. Сообщение от рассерженый фанат sdl (?), 02-Янв-26, 10:38	–1 +/–
>>low level access >>а оно мне надо ясно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #102

61. Сообщение от рассерженый фанат sdl (?), 02-Янв-26, 10:39	+/–
u16 во float на линуксе и винде как то по особому конвертятся?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #81

62. Сообщение от рассерженый фанат sdl (?), 02-Янв-26, 10:42	+3 +/–
но поддержку png впихнуть им это не мешало. правильно анон сказал выше - огрызок какой то. зачем-то в низкоуровневой библиотеке намутили апи, в котором повернутый прямоугольник даже не нарисовать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #121

63. Сообщение от Аноним (63), 02-Янв-26, 12:01	+/–
alutLoadWAVFile(...);
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #112

64. Сообщение от Аноним (63), 02-Янв-26, 12:03	+/–
У png постоянно проблемы с дырами, через которые взламывали системы, в т.ч. PSP ломали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #80

65. Сообщение от Аноним (63), 02-Янв-26, 12:04	+/–
> В чем конкретно проблема? Например, через PNG ломали PSP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #131

66. Сообщение от Аноним (63), 02-Янв-26, 12:06	+1 +/–
> там вообще должны быть все видео, аудио и фото форматы А давайте ещё Qt туда же статикой, а то слишком компактная либа, особенно для мобилок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

67. Сообщение от Аноним (63), 02-Янв-26, 12:11	+1 +/–
Зачем png в sdl, если есть libpng кому надо.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70

68. Сообщение от Аноним (68), 02-Янв-26, 13:04	–4 +/–
Почему нельзя? Берите и рисуйте. Сами. А то одному прямоугольник повернуть, другому блюру добавить, третьему… и уже ImageMagick получится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #73, #85

69. Сообщение от premium user (?), 02-Янв-26, 13:30	+/–
> В видеокарте, аппаратный, с конца 90х В алгоритмах сжатия - либо высокая скорость, либо высокое отношение качества к размеру, так вот у видяшных алгоритмов текстурного сжатия - первое. Лучше jpegxl какой-нибудь взять или heic, который аппаратно на мобильном соке разжимается 4к 60к/с. > map для ресурсов в андроидном APK через AssetFileDescriptor наверно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #83

70. Сообщение от llolik (ok), 02-Янв-26, 13:30	+/–
Судя по git-у, изначально всё началось с этого https://github.com/libsdl-org/SDL/issues/12716 . В linux (если я ничего не путаю, то и в Mac) иконки умеют либо в png, либо в svg. Но не умеют в bmp, который изначально умел sdl. Поэтому реализовали ещё и простой загрузчик png (с помощью stb библиотеки). Тащить для этой цели целый libpng как-то перебор, не кажется?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #77, #86

71. Сообщение от Аноним (63), 02-Янв-26, 14:08	+/–
Если точнее, SDL - это ступенька инициализации перед OpenGL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #99

72. Сообщение от Аноним (63), 02-Янв-26, 14:16	+/–
> SDL.gpu.device.create.vulkan.requirehardwareacceleration Нелогично же. Надо так: ROOT.factory.init.module.singleton.system.libraries.SDL.gpu.device.create.vulkan.require.acceleration.hardware
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

73. Сообщение от Аноним (63), 02-Янв-26, 14:20	+1 +/–
> Берите и рисуйте. Сами. Сам я это и в OGL прекрасно нарисую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

75. Сообщение от mos (??), 02-Янв-26, 14:54	–2 +/–
Кто переходит? Все кастомные опен сурсные движки сидят на SDL2. А SDL3 сырой мусор на том же Android с кучей регрессий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #89

77. Сообщение от Аноним (77), 02-Янв-26, 16:02	+1 +/–
Не кажется. libpng линкуется динамически, и постоянно в памяти висит, поэтому заюзать её - и дешевле, и полезнее будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #92

78. Сообщение от Аноним (51), 02-Янв-26, 16:37	+/–
> bloated же. тебе нравится раздутый софт? Bloated - это ядро Линукс, в котором каждые несколько месяцев корпораты заливают сотни тысяч строк. А несколько десятков килобайт от кода загрузки WAV меня вообще не колышат. Почему у тебя иначе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #98

79. Сообщение от Аноним (83), 02-Янв-26, 16:39	+1 +/–
>А если постоянно грузить картинку из файла - тем более упаси боже с HDD - это может вызывать нефиговейший ЛАГ. Ибо пока хард сгоняет головы, пока это прочтется, распакуется и проч - может пройти весьма измеримое время. >Хоть управляй, хоть не управляй а картинки грузятся не моментально. Разумеется. А ты что хотел, something for nothing? Так не бывает. А нефиговейший лаг будет по-любому если свопинг начался. А он при распаковке дофига картинок в RGBA-массивы начнётся. И будет более жёстким - так как программе придётся данные в добавок в своп ещё и сохранять, и туда-сюда-обратно. >Хотя любителям лагов, дерга и статтера - зайдет, конечно. Да нет там дёрга и статтера. Большинство этих картинок не нужно, так как виды пространственно сегрегированы, их местные демиурги держат в разных банках (из-за чего коалиция кентавров, жуков и пауков очень рассержена на них), а джамп-движка почти ни у кого нет (но игрок может его захватить у пиратов-коратов), текстуры кораблей бурондоа одновременно с текстурами хаи и людей не требуются, а когда нужно становится (прыжок в банку разумных стрекоз и система с деревьями-интегралами там же, вообще вся игра испытала сильное влияние Ларри Нивена) - игра при загрузке локации подвисает на секунду - из свопа RGBA-массивы перегоняются в оперативу, игра будится, оттуда - игра их перегоняет в видеокарту. Чтобы освободить место в оперативе другие массивы отправляются в своп. Вообще пространственная и временная локалльность - это частый мотив в вычислениях, на нём все кеширование основано. >Что сие за конфиг и игра? "Кора дуба", 2 гига. https://github.com/endless-sky/endless-sky Геймплей уровня 90х. >Да ничего оно не вгоняет особо. Вгоняет. >А то может там новомодный геймдев текстур навесил больше чем у вас оперативки было А ты как думаешь? Вот у него - всё приемлимо работает. Там игра чтобы не пе***олиться с управлением подкачкой текстур просто грузит их все в оперативу на старте (когда прогресскруг заполняется). На современных компах современных смузи-разработчиков работает приемлимо. Но если сделать правильно - за игру с подкачкой текстур будет ОС пердолиться, не будет записей RGBA-массивов текстур в своп, да и изначальная загрузка игры будет намного быстрее, так как mmap почти мгновенен. Да, первая загрузка уровня будет дольше, ибо с диска всё пойдёт в память, но только то, что реально используется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #105

80. Сообщение от Аноним (51), 02-Янв-26, 16:40	+/–
Как тебя взломают через загрузчик PNG из SDL, если ты его не используешь? Я же спрашивал "они ТЕБЯ как-то трогают, или что"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #97

81. Сообщение от Аноним (51), 02-Янв-26, 16:42	+/–
> u16 во float О чем ты вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

82. Сообщение от Аноним (83), 02-Янв-26, 16:44	+/–
Я предлагаю кешировать на диске сжатую текстуру в оптимальном формате компрессии под конкретную видеокарту. Игра распространяется с оригинальными PNG-файлами. При запуске игра проверяет доступность форматов - либа опрашивает OpenGL-расширения (в compressonator всё это есть, как и в современных игровых движках). Далее выбирается формат. После чего при попытке загрузить PNG-файл сначала проверяется наличие и свежесть файла кеша, если его нет - он конвертится в выбранный формат, формат дампится на диск, и оттуда - mmapится. RGBA-данные для работы игры не использовать совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #87

83. Сообщение от Аноним (83), 02-Янв-26, 16:46	+/–
>В алгоритмах сжатия - либо высокая скорость, либо высокое отношение качества к размеру, так вот у видяшных алгоритмов текстурного сжатия - первое Ну это известно. >Лучше jpegxl какой-нибудь взять или heic, который аппаратно на мобильном соке разжимается 4к 60к/с. Зависит от платформы.  Моя десктопня карта такое не поддерживает. Либа должна интроспектировать карту и выбирать оптимальный формат сама.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #138

84. Сообщение от Аноним (83), 02-Янв-26, 16:47	+/–
Ошибся, не Endless Space, а https://github.com/endless-sky/endless-sky
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

85. Сообщение от Аноним (51), 02-Янв-26, 16:48	+2 +/–
> Почему нельзя? Потому что API для этого отсутствуют. Ты цирк решил развести, или что? > Берите и рисуйте. Сами Зачем тогда SDL_Renderer нужен? Сношаться с OpenGL, Vulkan и т.д. по отдельности я и сам могу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #129

86. Сообщение от Аноним (51), 02-Янв-26, 16:56	+/–
> Тащить для этой цели целый libpng как-то перебор, не кажется? А его и не нужно "тащить": в том же SDL_Image он подгружается динамически. Код загрузки PNG получается мизерным, а сама libpng разделена в памяти между другими приложениями. Здесь же решили "притащить для этой цели целый" статически слинкованный stb_image, который мало того, что NIH в вакууме, так еще и кешит дыренями (в libpng за десятки лет ее использования примерно ВЕЗДЕ их хотя бы почти все залатали).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #123

87. Сообщение от Аноним (51), 02-Янв-26, 17:04	+/–
Я никогда не видел, чтобы игра загаживала диск кешем текстур. Кто будет вычищать сотни мегабайт (а то и гигабайты) данных после удаления игры? > RGBA-данные для работы игры не использовать совсем. А если ни разработчик, не игроки не хотят видет убитое компрессией месиво вместо спрайтов нормального качества? В общем, ты предлагаешь разработчику делать больше работы ради того, чтобы пользователи  получили худшее визуальное качество спрайтов. Сори, но уж лучше ТЫ приобрети нормальное железо и перестань делать голову себе и другим людям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #88, #130

88. Сообщение от Аноним (88), 02-Янв-26, 17:41	+/–
>Кто будет вычищать сотни мегабайт (а то и гигабайты) данных после удаления игры? Деинсталлятор, конечно же. В случае портативки никто не вычищает. В случае линукса - bleachbit, как всегда, чистит ~/.cache. >Я никогда не видел, чтобы игра загаживала диск кешем текстур. Коммерческие проекты поставляются с уже сконвертированными текстурами. >А если ни разработчик, не игроки не хотят видет убитое компрессией месиво вместо спрайтов нормального качества? Читайте внимательно предложенное API. Там ответ на ваш вопрос. >В общем, ты предлагаешь разработчику делать больше работы Да, предлагаю. Так много "больше работы" - это запилить в игре настройку "сжимать спрайты" и "кешировать спрайты" и пробросить её в предложенное API. А ещё я предлагаю разрабам SDL делать больше работы. Запилить предложенный механизм и обособить его в отдельную либу, после чего в SDL задействовать эту либу. >ради того, чтобы пользователи  получили худшее визуальное качество спрайтов Всё в мире трейдофф, абсолютно всё. Можно сделать игру с очешуенным качеством спрайтов, которая работать будет только на суперкомпьютере. Вот в приведённой в пример игре написано: >System Requirements >Minimum >RAM 750 MB >Recommended >RAM 2 GB При двух гигах она грузится час непрерывного трешинга. Видимо разрабы совсем от реальности оторвались. Это вполне типично для разрабов опенсорсных программ - тут же не рынок, за отсутствие оптимизации насяльника не выдолбит без смазки. И проекту SDL следует учитывать эту специфику. Грамотное проектирование библиотека подразумевает архитектуру такую, которая подходит максимально широкому набору use-caseов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #90, #120

89. Сообщение от Аноним (51), 02-Янв-26, 18:02	+/–
> Кто переходит? Unreal, например: https://dev.epicgames.com/documentation/en-us/unreal-engine/... Godot, например: https://godotengine.org/releases/4.5/#sdl3-gamepad-input-driver > Все кастомные опен сурсные движки сидят на SDL2 Да плевать на эти васяноподелия. Пусть хоть на SDL1 сидят - ими все равно никто не пользуется, кроме авторов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #91

90. Сообщение от Аноним (51), 02-Янв-26, 18:29	+/–
> Коммерческие проекты поставляются с уже сконвертированными текстурами. Да, но Quake 3 и даже Doom 3 в свое время поставлялись с текстуроми в обычном JPEG. Если в конце 90х - начале нулевых несжатый RGB в GPU не был проблемой, а у тебя в 2026 железо такое не вывозит даже для пары сотен спрайтов - то это именно тебе нужно обновлять железо, а не разработчикам пилить нелепые костыли ради 0.001% таких, как ты. >> А если ни разработчик, не игроки не хотят видет убитое компрессией месиво вместо спрайтов нормального качества? > Читайте внимательно предложенное API При чем здесь твое API? Я тебе о том, что это никому, кроме тебя, не нужно. > А ещё я предлагаю разрабам SDL делать больше работы. Запилить предложенный механизм и обособить его в отдельную либу, после чего в SDL задействовать эту либу. Непонятно, почему разрабов низкоуровневого SDL должны волновать механизмы, реализующиеся на уровне выше самим приложением. >>ради того, чтобы пользователи  получили худшее визуальное качество спрайтов > Всё в мире трейдофф, абсолютно всё. Можно сделать игру с очешуенным качеством спрайтов Вот именно друг, что трейдофф: вместо того, чтобы тратить время ради проблемных 0.001% пользователей вроде тебя, можно потратить его ради 99.99% нормальных юзеров с адекватным железом. > При двух гигах она грузится час непрерывного трешинга. Видимо разрабы совсем от реальности оторвались На так если игра опенсорсная, ты же можешь разрабам на Гитхабе написать об этой проблеме! И советов им заодно надаешь (а может и код напишешь, лол). Я уверен, что они ради одного тебя особенного и твоего некрожелеза из кожи вон будут лезть! > Грамотное проектирование библиотека подразумевает архитектуру такую, которая подходит максимально широкому набору use-caseов. Хорошо ты устроился: значит, ты свое время (в переводе на 500-700 баксов для адекватного железа) тратить не собираешься, а предлагаешь разработчикам сделать это вместо тебя? А сам ты будешь сидеть и только потреблять все готовенькое? Широкий набор use-caseов они как раз покрыли, и твой музейных экспонат в него, очевидно, не входит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #108

91. Сообщение от смотритель за котами (?), 02-Янв-26, 18:37	+/–
Насчёт кастомных движков - все так. Это никому не нужный мусор. Все кому надо писать игры - пишут их или на unity или unreal engine. На крайний случай - годот. А этот катомный мусор пишется десятилетиями и он никому не нужен. Зато сколько у них гонора. Например у того же openmw, разработчики которого считают тот же unreal engine и unity мусором. Но на деле никому не нужный мусор - только их движок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #103

92. Сообщение от llolik (ok), 02-Янв-26, 18:43	+/–
> Не кажется. libpng линкуется динамически, и постоянно в памяти висит, поэтому заюзать > её - и дешевле, и полезнее будет. Только ты забываешь, что SDL предполагает работу не только в linux, а, в идеале, практически везде, где libpng не обязательно болтается. А SDL_Image - это опциональная библиотека расширения, а не "базовый", назовём так, SDL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #93

93. Сообщение от Аноним (51), 02-Янв-26, 19:11	+/–
> Только ты забываешь, что SDL предполагает работу не только в linux Но проблема с иконкой в трее, ради которой притащили PNG, была как раз только в Linux. Почему было не загрузить libpng динамически (ведь они и так это делают с libappindicator) - загадка. Зато встроили дырявый stb_image.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #100, #122

94. Сообщение от Аноним (96), 02-Янв-26, 20:38	+/–
BMP - это буквально RAW-пиксели. Их можно передать почти как есть в GAPI, чтобы на экран скопировать. А PNG - формат со сжатием (без потерь), его ещё распаковать нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #132

95. Сообщение от Аноним (96), 02-Янв-26, 20:40	+/–
A-Life никогда не был рабочим в официальных релизах. Его фанатскими модами восстанавливали и правили всем миром, всем народом, всей страной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

96. Сообщение от Аноним (96), 02-Янв-26, 20:58	–1 +/–
https://wiki.libsdl.org/SDL3/SDL_RenderTextureRotated
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #107

97. Сообщение от Аноним (63), 02-Янв-26, 21:34	+/–
> его не используешь Хороший совет не пользоваться линуксом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

98. Сообщение от Аноним (-), 02-Янв-26, 23:01	+/–
> Bloated - это ядро Линукс, в котором каждые несколько месяцев корпораты заливают > сотни тысяч строк. А несколько десятков килобайт от кода загрузки WAV > меня вообще не колышат. Почему у тебя иначе? Тем не менее linux запускают даже на каких-то совсем м усорных мыльницах типа 4/32 (мега, flash/ram). И ничего - лезет как-то. А остальное там вообще в пролете как мухи в самолете. Вот тебе и bloated.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

99. Сообщение от Аноним (99), 02-Янв-26, 23:12	–1 +/–
> Если точнее, SDL - это ступенька инициализации перед OpenGL. А вот отучаемся говорить за всех. 1) Есть 2D программы которым GL нахрен не упал. Да даже игры - есть. Вот что pixel art типа Wesnoth вообще с GL должен хотеть делать вообще? 2) GL так то устаревшее апи, нынче в моде Vulkan. А сам SDL как таковой движками и рендером 3D не занимается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #104

100. Сообщение от llolik (ok), 02-Янв-26, 23:24	+/–
В принципе, там #ifdef SDL_HAVE_STB макросами обнесено. Хочешь, можешь и без него собирать (но и без PNG, конечно). Будут просто заглушки, с SDL_SetError.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

102. Сообщение от Аноним (-), 03-Янв-26, 00:36	+/–
>>>low level access >>>а оно мне надо > ясно Я другой анон и не собирался в регистры звуковухи лично лезть. Сабж юзают чтобы как раз этим всем не заниматься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

103. Сообщение от Аноним (-), 03-Янв-26, 00:50	–3 +/–
> Это никому не нужный мусор. Мусор это инди хлам на {годоте, юнити и анрыле}. Через который все забывают за пару лет после его выхода. А в какой-нибудь Xonotic мы шпилим уже N лет с его кастомным движком. И дальше продолжим. Да и openmw на отлично переживет 99% инди барахлишка, на это можно ставки принимать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

104. Сообщение от Аноним (51), 03-Янв-26, 03:31	+/–
> Вот что pixel art типа Wesnoth вообще с GL должен хотеть делать вообще? Ускорять графику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #113

105. Сообщение от Аноним (-), 03-Янв-26, 06:34	+/–
> Разумеется. А ты что хотел, something for nothing? Так не бывает. А зачем играть в лагучее нечто? Или рассуждая как дев зачем релизить во что я даже сам играть не стану? > А нефиговейший лаг будет по-любому если свопинг начался. У меня ничего не начинается. > А он при распаковке дофига картинок в RGBA-массивы начнётся. Нормальные движки таки это - as needed. Но да буферизуют по крайней мере то что скорее всего потребуется. > И будет более жёстким - так как программе придётся данные > в добавок в своп ещё и сохранять, и туда-сюда-обратно. В конечном итоге - у вас либо "горячие" ассеты помещаются в RAM или вы всяко радуетесь тупнякам. Чудес не бывает. >>Хотя любителям лагов, дерга и статтера - зайдет, конечно. > Да нет там дёрга и статтера. Большинство этих картинок не нужно, так > как виды пространственно сегрегированы, их местные демиурги держат в разных банках > (из-за чего коалиция кентавров, жуков и пауков очень рассержена на них), Звучит как какие-то заморочки одной конкретной штуки. И тут уж как накодили так и накодили. Кодить продвинутые cache manager занятие специфичное и результат не всегла получается стоящим тех усилий. Если вы лучше всех знаете как надо - идете и показываете. Делом. И PNG сам по себе всему этому никак не мешает. > испытала сильное влияние Ларри Нивена) - игра при загрузке локации подвисает > на секунду - из свопа RGBA-массивы перегоняются в оперативу, игра будится, > оттуда - игра их перегоняет в видеокарту. Чтобы освободить место в > оперативе другие массивы отправляются в своп. Вообще пространственная и временная локалльность > - это частый мотив в вычислениях, на нём все кеширование основано. Я сподвигся это поставить, забавная фигня. Даже с hi-dpi плагином. Жрет оно у меня менее 500 мегс оперативы. И ничего нигде не подвисает, конечно. Да и из свопа у меня ZRAM только есть. И вот MGLRU системный да, разберется кто там горячий а кто не очень, только в этом случае ему pressure никакого не подваливает. А с чего? > "Кора дуба", 2 гига. Тут видимо смотреть надо что еще запущено. Само по себе ЭТО у меня сожрало менее 500 мегс. > https://github.com/endless-sky/endless-sky > Геймплей уровня 90х. Графоний у него явно не из 90х и куда приличнее. Будем честны, в кишки я особо не въезжал. >>Да ничего оно не вгоняет особо. > Вгоняет. Сэр, это опенсорс. Если вам не нравится как у кого-то что-то сделано и вы лучше знаете как надо - вот вы присылаете им патчи и тогда будет разговор. В айти вообще лидерство и экспертиза подкрепляется исключительно ДЕЛАМИ. Так себе и запишите. Но вот при чем тут PNG я решительно не догоняю. Можно подумать PNG как формат как-то влияет на то как те или иные девы будет кеширование и ассеты менеджить. Да и называя вещи своими именами - жор 500 мегабайтов в 2025 году для игры - это вообще ни о чем. Ибо одна долбаная вкладка браузера с рикталжыэс сожрет в 2 раза больше. И близко не рисуя такого графония и кучи фич. > А ты как думаешь? Вот у него - всё приемлимо работает. У меня - тоже. Вся упомянутая штука с HiDPI который "может почти удвоить жор оперативы" сожрала около 500 мегс. Не понимаю как сабж на что-то повлияет кроме того что не надо будет SDL_Image для вон того таскать. > все в оперативу на старте (когда прогресскруг заполняется). На современных компах > современных смузи-разработчиков работает приемлимо. На моем компе я честно говоря не успел разгделеть что там какой-то круг заполняется. И это далеко не новый конфиг. Впрочем у меня есть passion по части быстрых, low latency систем. Поэтому свопа нет совсем, есть только zram. Ну и ssd'шник под систему. Чтобы нормальным user experience наслаждаться. А если у вас в системе нет zram - тем хуже для вас. > Но если сделать правильно - за игру с подкачкой текстур будет ОС пердолиться, ЧСХ это может сделать все только хуже. Не говоря о том что ос разные бывают и их поведение тоже. У меня вот с ZRAM и SSD и без свопа чисто технически радикаьлно лагать нечему. > не будет записей RGBA-массивов текстур в своп, да и изначальная загрузка > игры будет намного быстрее, так как mmap почти мгновенен. Чтобы mmap работал надо вообще совсем не жатые ассеты. Без всяких там контейнеров. Это раздует размер ассетов в РАЗЫ. И так HiDPI плагин качался довольно заметное время так то. > Да, первая загрузка уровня будет дольше, ибо > с диска всё пойдёт в память, но только то, что реально > используется. mmap() это довольно специфичный механизм и наверняка там есть куча грабель между разными системами. У меня впрочем mglru сам разберется что в "swap" сжать а что нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #110

107. Сообщение от Аноним (63), 03-Янв-26, 15:49	+/–
Где тут повёрнутый прямоугольник? А его нету. Вращается текстура, а не прямоугольник.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #128

108. Сообщение от Аноним (108), 03-Янв-26, 15:50	–1 +/–
>Если в конце 90х - начале нулевых несжатый RGB в GPU не был проблемой Был, именно тогда сжатые текстуры и внедрили в продукты. >железо такое не вывозит даже для пары сотен спрайтов 6228. Как и ожидалось, фактуру вы не знаете. >Непонятно, почему разрабов низкоуровневого SDL должны волновать механизмы, реализующиеся на уровне выше самим приложением. Ну тогда надо проект закрыть, сказав что вообще всё можно и нужно реализовывать в самом приложении, в "лучших" традициях коммерческого геймдева. >твой музейных экспонат С хамами и троллями дискутировать не имеет смысла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #109

109. Сообщение от Анрним (?), 03-Янв-26, 17:00	+/–
>>Если в конце 90х - начале нулевых несжатый RGB в GPU не был проблемой > Был, именно тогда сжатые текстуры и внедрили в продукты. Ну давай, расскажи мне, как тогда было. >>Непонятно, почему разрабов низкоуровневого SDL должны волновать механизмы, реализующиеся на уровне выше самим приложением. > Ну тогда надо проект закрыть, сказав что вообще всё можно и нужно реализовывать в самом приложении Кроме инфантильных передергиваний по существу ответить нечего? >>твой музейных экспонат > С хамами и троллями дискутировать не имеет смысла Ты сам же написал о проблеме, с которой не сталкивается НИКТО среди других игроков. Очевидно же, что проблема в ТВОЕМ железе. Но так как ничего внятного возразить на этот факт ты не можешь, ты решил слиться под предлогом выдуманного "троллинга и хамства". Ну так что там, ты разрабам игры и SDL написал Issue на Гитхабе, или только тут экспертизу можешь наваливать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #111

110. Сообщение от Аноним (110), 03-Янв-26, 18:16	+/–
>У меня ничего не начинается. #worksforme, #notabug, clasic! >А зачем играть в лагучее нечто? Или рассуждая как дев зачем релизить во что я даже сам играть не стану? У дева на топовом железе ничего не лагает. >В конечном итоге - у вас либо "горячие" ассеты помещаются в RAM или вы всяко радуетесь тупнякам Разумеется. Всё в мире трейдофф. Только можно делать так, чтобы тупники минимизировать, а можно наоборот делать как попало - а всем рекомендовать выкинуть "музейный экспонат", "калькулятор", "хлам", "обогреватель" и прочее. >Кодить продвинутые cache manager Можно не кодить продвинутый, а делать progressive enhancement и оутсорсить это в ОС. Предложенный же универсальный механизм по-видимому подойдёт любой программе, имеющей дело с текстурами. >Графоний у него явно не из 90х и куда приличнее. Будем честны, в кишки я особо не въезжал. Графоний - да, спрайты большего разрешения, но я сказал не про графоний, а про геймплей. По сути игра - это клон косморейнджеров. >Тут видимо смотреть надо что еще запущено LxQt. Но уже и он жрёт дофига. Возможно, системные требования в README.md - для Windows XP. >А если у вас в системе нет zram - тем хуже для вас. Да есть он, просто разрабы всё в дерьмо превращают своим отношением к оперативе. Один данные в оперативу копирует memcpy, другой тоже - и систему уже в мусор можно выкинуть теперь. >Да и называя вещи своими именами - жор 500 мегабайтов в 2025 году для игры - это вообще ни о чем. "Ни о чём" - потому что вредители забил на оптимизацию. Ибо одна долбаная вкладка браузера с рикталжыэс сожрет в 2 раза больше. Курочка по зёрнышку клюёт - а весь двор засран. >Но вот при чем тут PNG я решительно не догоняю. Можно подумать PNG как формат как-то влияет на то как те или иные девы будет кеширование и ассеты менеджить. PNG как таковой тут ни при чём. Не нужно вообще такое низкоуровневое API экспортировать. Кеширование нужно абсолютно везде - значит должно быть умолчанием, и потрудиться (немного, но потрудиться, в конфиг добавить аргумент) должно быть нужно не для того, чтобы его запилить, а для того, чтобы его отключить. >Чтобы mmap работал надо вообще совсем не жатые ассеты. Без всяких там контейнеров. Это раздует размер ассетов в РАЗЫ. Не, в видеокартах с 1999 есть аппаратная поддержка сжатия. Они хавают сжатые текстуры. Вот у меня: glxinfo | grep -iPo "GL_(ATI|EXT)_texture_compression_(\w+)" | sort --uniq GL_ATI_texture_compression_3dc, GL_EXT_texture_compression_latc <-> 3dc GL_EXT_texture_compression_bptc <-> bc7, bc6h GL_EXT_texture_compression_rgtc <-> bc5, bc4 GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc <-> bc2, bc1 (стрелками показаны маппинги на форматы) Вот, например, images/star/m-supergiant.png - самая большая картинка в папке images, красненькая звёздочка из некоторых систем... 1,9M m-supergiant.png оптимизируем через optipng -o5 1,8M m-supergiant.optimized.png PNG уже оптимизирован, а по опыту optipng почему-то жмёт лучше, чем zopflipng. Теперь посмотрим, сколько в RGBA это займёт: convert m-supergiant.png m-supergiant.ppm 6,8M m-supergiant.ppm А теперь пожмём для видеокарт: ../etcpak/build/etcpak -c bc1 m-supergiant.png m-supergiant.bc1.pvr ../etcpak/build/etcpak -c bc4 m-supergiant.png m-supergiant.bc4.pvr ../etcpak/build/etcpak -c bc5 m-supergiant.png m-supergiant.bc5.pvr ../etcpak/build/etcpak -c bc7 m-supergiant.png m-supergiant.bc7.pvr 1,2M m-supergiant.bc1.pvr 1,2M m-supergiant.bc4.pvr 1,8M m-supergiant.optimized.png 1,9M m-supergiant.png 2,3M m-supergiant.bc5.pvr 2,3M m-supergiant.bc7.pvr 6,8M m-supergiant.ppm BC1 в 6 раз меньше размера RGBA-массива. То что размер пожатой текстуры меньше, чем в PNG, тут ничего поразительного - это lossy-компрессия. Было бы ещё лучше, если было бы можно поверх BC4 пожать ещё каким-нибудь snappy, а на mmap повесить флаг, чтобы прозрачно разжимало, в ядре это всё есть для zram/zswap, главное тут - уязвимостей избежать. Избежать я вижу только одним способом - при отображении со сжатием сначала файл проверяется, потом лочится, и не может быть фактически открыт на запись кроме как через сжатый интерфейс, открытие на запись приводит к copy-on-write, открытие на чтение через любой интерфейс безопасно, открытие на запись через сжатый тоже, так как всё идёт через страницы памяти. Возьмём, напр. snappy, самый быстрый алгоритм из zram/zswap. snappy -f m-supergiant.ppm > m-supergiant.ppm.sz snappy -f m-supergiant.bc1.pvr > m-supergiant.bc1.pvr.sz snappy -f m-supergiant.bc4.pvr > m-supergiant.bc4.pvr.sz snappy -f m-supergiant.bc5.pvr > m-supergiant.bc5.pvr.sz snappy -f m-supergiant.bc7.pvr > m-supergiant.bc7.pvr.sz 701K m-supergiant.bc4.pvr.sz 740K m-supergiant.bc1.pvr.sz 1,5M m-supergiant.bc5.pvr.sz 1,8M m-supergiant.bc7.pvr.sz 3,0M m-supergiant.ppm.sz Со snappy в 4.4 раза меньше размера RGBA-массива, и меньше даже, чем размер оригинального PNG. Но реальная польза будет когда/если в ОС добавит API для отображения в память сжатых файлов. Сжатие на уровне ФС это вообще бред, сжатие - это вещь универсальная, ортогональна ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

111. Сообщение от Аноним (111), 03-Янв-26, 18:24	+/–
Сам себе расскажи, дейташиты, статьи и доклады на конференциях в открытом доступе есть. А передёргивания , хамство и троллинг - у тебя. >Очевидно же, что проблема в ТВОЕМ железе Очевидно, что то, что продукт написан как говно, и поэтому не идёт нормально на моём железе - это проблема продукта, а не железа. >Ты сам же написал о проблеме, с которой не сталкивается НИКТО среди других игроков Не аргумент в принципе. С большинством багов никто не сталкивается, кроме тех, кто их репортит. Вон с rowhamerом и spectre много лет живём, и всё нормально. Ну то есть в дерьме быть - это всегда нормальное состояние. Вообще во всём, универсально, ибо закон Старжена >90% всего - дерьмо . По вашей логике проблема - в Грюссе с Липпом, а не в процессорах Intel и DDR5.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #116

112. Сообщение от Аноним (-), 03-Янв-26, 19:51	+/–
> alutLoadWAVFile(...); И где тут загрузчик? А, мусор замели под ковер - перенеся его в воооооон ту мегалибу? Так с сабжем тоже так можно. И даже можно написать обертку и потом тоже пафосно вызвать 1 функцию. А так вы еще SndPlaySound() или как там его из винапи вспомните. Да, это просто как дрова. И ... в таком виде совершенно не годится для игродела и проч. В лучшем случае эффект в дурацкой програмке проиграть. Как только применения хоть капельку продвинутее - такая апя жесточайше пролетает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

113. Сообщение от Аноним (-), 03-Янв-26, 19:59	+/–
> Ускорять графику. Что можно "ускорять" в куче пикселей так по крупному? Это просто вывод битмапы на экран по большому счету. Если конечно поставить на пути видео-тормозитель типа Xorg, для которого вывод больших битмап по дефолту в in-band протоколе, и спасибо если не по TCP стеку - будет вам xenocara господня, конечно, за такую "инженерию". Но все что там "ускорение" делало - убирало такой треш и позор с data path, отдавая битмап менее #$%нутому апи отрисовки которое не будет гиг в секунду парсить прям в inband протоколе. А в целом тормозить в сплеве большой битмапы особо нечему. А скомпонована она игровым движком из кусков других битмап как это надо в соответствии с логикой. Это не особо тяжелые и тормозные операции сами по себе, memcpy буквально. Такие игоря и на 2D "неакселерированном" не тормозят от слова совсем. Потому что нечему там тормозить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #115

115. Сообщение от Аноним (51), 03-Янв-26, 20:56	+/–
>> Ускорять графику. > Что можно "ускорять" в куче пикселей так по крупному? Это просто вывод битмапы на экран по большому счету. Вот этот самый вывод пикселей и ускорять. CPU - это высокопараллелная обработка с тысячами и десятками тысяч пикселей одновременно. А на CPU ты циклом по каждому пикселю будешь бежать, и даже SIMD тебя не сильно спасет. > Такие игоря и на 2D "неакселерированном" не тормозят от слова совсем. Потому что нечему там тормозить. Экспертиза в графике - 10/10.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #117, #143

116. Сообщение от Аноним (51), 03-Янв-26, 23:45	+/–
> Сам себе расскажи, дейташиты, статьи и доклады на конференциях в открытом доступе есть. Какой нелепый спрыг. Я у тебя спрашивал о конкретно двух очень популярных в свое время играх, разошедшихся миллионами копий - а ты несешь какую-то чушь о докладах и презентациях. > не идёт нормально на моём железе - это проблема продукта, а не железа. Нет, у продукта проблем нет, потому что как самому продукту, так и его разработчикам на тебя и твое тщедушное железо наплевать. > что продукт написан как говно Я тебя в третий раз спрашиваю: ты уже разработчикам игры и SDL написал Issue на Гитхабе, или будешь продолжать тут цирк разводить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #125

117. Сообщение от Аноним (-), 04-Янв-26, 00:41	+/–
> Вот этот самый вывод пикселей и ускорять. Что там можно ускорять, если графическое API не совсем г-но? > CPU - это высокопараллелная обработка с тысячами и десятками тысяч пикселей > одновременно. А на CPU ты циклом по каждому пикселю будешь бежать, и даже SIMD тебя не > сильно спасет. Вообще-то обычно в вещах типа Wesnoth это просто блочная копия битмапов в основном. Какой-то обсчет нужен разве что для альфы и реколора но это надо не всем - и пардон но это даже на доисторических конфигах особо не тормозило ни у кого. > Экспертиза в графике - 10/10. Я вас не заставлял, вы сами. То добро на отлично фигачило на совсем лохматых конфигах с эры чуть не VGA адаптеров, и упиралось оно - в скорость вывода в этот адаптер в основном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #118

118. Сообщение от Аноним (51), 04-Янв-26, 01:11	+/–
> Что там можно ускорять Я уже написал: вывод и композитинг битмапов. >> CPU - это высокопараллелная обработка с тысячами и десятками тысяч пикселей одновременно. А на CPU ты циклом по каждому пикселю будешь бежать, и даже SIMD тебя не сильно спасет. > Вообще-то обычно в вещах типа Wesnoth это просто блочная копия битмапов в основном. Ну, и? Это как-то отменяет тот факт, что на CPU для их отрисовки нужно бежать попиксельно/SIMD циклом. >> Экспертиза в графике - 10/10. > То добро на отлично фигачило на совсем лохматых конфигах с эры чуть не VGA адаптеров, Ну я же говорю: экспертиза 10/10. Во времена лохматых конфигов и VGA двумерные спрайты были сугубо 8 бит (палитра 256 цветов) и выводились на разрешение в несколько сот пикселей. Причем не только на ПК, но и на консолях. И ситуация была таковой до тех пор, пока во второй половине 90х не появились 3D ускорители, что наконец-то позволило для 2D делать нормальные RGB спрайты с высоким разрешением и с 256 градациями альфа канала. О чем ты споришь - я хз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #137

120. Сообщение от Аноним (-), 04-Янв-26, 05:24	+/–
> Деинсталлятор, конечно же. В случае портативки никто не вычищает. В случае линукса > - bleachbit, как всегда, чистит ~/.cache. Предлагается потребовать в комплект к гамесе еще какую-то совершенно левую тулсень?! Вы там совсем ту-ту?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #126

121. Сообщение от Аноним (-), 04-Янв-26, 05:26	+/–
> но поддержку png впихнуть им это не мешало. PNG вообще никак к 3D не относится сам по себе. А вот ассеты в нем бывают довольно часто. В том числе и 2D сугубо. И это совершенно нормально. > - огрызок какой то. зачем-то в низкоуровневой библиотеке намутили апи, в > котором повернутый прямоугольник даже не нарисовать Я думаю что нормальные прямоугольники нужны сильно чаще чем повернутые. Ну там UI допустим какой-то отрисовать. И все такое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

122. Сообщение от Аноним (-), 04-Янв-26, 05:28	–2 +/–
> они и так это делают с libappindicator) - загадка. Зато встроили > дырявый stb_image. Потому что png это несколько круче чем опциональщина в трее и юзается много где еще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

123. Сообщение от Аноним (-), 04-Янв-26, 05:32	–1 +/–
> А его и не нужно "тащить": в том же SDL_Image он подгружается > динамически. Код загрузки PNG получается мизерным, а сама libpng разделена в > памяти между другими приложениями. Вот только надо тащить еще 1) SDL_Image который не core part как таковой. 2) Libpng. И это все для того что давно стало самой базовой вещью. Нравится вам или нет но png используется в дофигища программ. И в гамезах его немеряно. По поводу чего умение с ним работать в core либе явно не в минус. > мало того, что NIH в вакууме, так еще и кешит дыренями И вы это пруфанете, конечно? Ну и с практической точки зрения игры у меня так то пакетник качает и левые исполняемые и ассеты - ниоткуда не возьмутся. Так что от чего вы меня рветесь защищать? От авторов гамезы? Они и так в свой код могут что угодно втулить. > (в libpng за десятки лет ее использования примерно ВЕЗДЕ их хотя > бы почти все залатали). Тем не менее сие не такая уж мелкая либа - и с довольно так себе апи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #124

124. Сообщение от Аноним (51), 04-Янв-26, 05:50	+/–
>> А его и не нужно "тащить" [...]он подгружается динамически. > Вот только надо тащить еще 1) SDL_Image который не core part как таковой. 2) Libpng. Что и куда ты собрался тащить? Ты понимаешь, что такое ДИНАМИЧЕСКАЯ загрузка библиотеки? >> мало того, что NIH в вакууме, так еще и кешит дыренями > И вы это пруфанете, конечно? Конечно: https://github.com/nothings/stb/issues?q=is%3Aissue... Ну и в целом большими буквами написано: "This project discusses security-relevant bugs in public in Github Issues and Pull Requests, and it may take significant time for security fixes to be implemented or merged. If this poses an unreasonable risk to your project, do not use stb libraries."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #127

125. Сообщение от Аноним (125), 04-Янв-26, 07:20	+/–
>Нет, у продукта проблем нет, потому что как самому продукту, так и его разработчикам на тебя и твое тщедушное железо наплевать. Мне тоже на хотелки всяких хамоватых троллей в интернете наплевать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

126. Сообщение от Аноним (125), 04-Янв-26, 07:21	+/–
Не хочешь - чисти вручную, как на Linux и полагается по-умолчанию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

127. Сообщение от Аноним (125), 04-Янв-26, 07:24	+/–
Всё правильно делают, full disclosure.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

128. Сообщение от Аноним (130), 04-Янв-26, 14:17	–1 +/–
Геометрию фигуры ты вообще-то сам определяешь. Располагай вершины как хочешь. Поворот фигуры можно получить умножением её вершин на матрицу поворота, которую ты можешь задать отдельной библиотекой линейной алгебры (например, GLM). Если ты работал с OpenGL, то там, внезапно, тоже самое: 2D - частный случай 3D (третья координата игнорируется), самостоятельные переносы и повороты системы координат перед отрисовкой фигуры. Какие тут могут быть претензии к SDL? Только нелепые, дилетантские.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #134

129. Сообщение от Аноним (130), 04-Янв-26, 14:24	+/–
SDL_Renderer - кроссплатформенная абстракция над GAPI. Затем и нужен, чтобы не писать код под каждую платформу отдельно, и чтобы твой код не превратился в тыкву, когда производители карт захотят продать тебе новую карту и объявят используемые тобой API устаревшими.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #135

130. Сообщение от Аноним (130), 04-Янв-26, 14:29	+/–
> Я никогда не видел, чтобы игра загаживала диск кешем текстур. Кто будет вычищать сотни мегабайт (а то и гигабайты) данных после удаления игры? А что насчёт кэша шейдеров на сотни мегабайт для каждой игры? Причем, в клиенте Steam даже есть функция загрузки (и удаления) этого кэша, вместе с игрой. Причем, это не маргинальный случай, а норма для современных GAPI. (https://www.sebastianaaltonen.com/blog/no-graphics-api)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #142

131. Сообщение от Аноним (131), 04-Янв-26, 15:36	+/–
Вроде бы TIFF был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

132. Сообщение от Аноним (131), 04-Янв-26, 15:56	+/–
BMP - это не совсем RAW-пиксели. >Each scan line is zero padded to the nearest 4-byte boundary. If the image has a width that is not divisible by four, say, 21 bytes, there would be 3 bytes of padding at the end of every scan line. >Scan lines are stored bottom to top instead of top to bottom. >RGB values are stored backwards i.e. BGR. Там ещё поддержка RLE есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

133. Сообщение от Lamerok (?), 04-Янв-26, 15:57	+/–
иех.. ушла эпоха, гоняли спрайтики на wince pda + sdl1.2, щас sdl3 уже не торт)
Ответить | Правка | Наверх | Cообщить модератору

134. Сообщение от Анрним (?), 04-Янв-26, 17:34	+/–
>>> SDL_RenderTextureRotated >> Где тут повёрнутый прямоугольник? > Геометрию фигуры ты вообще-то сам определяеш Покажи мне, как определить геометрию в SDL_RenderTextureRotated. > Какие тут могут быть претензии к SDL? Ты вообще читал комментарии выше? Претензии в отсутствии возможности нарисовать круг вызовом одной функции, как это делается в любом нормальном аысокоуровневом 2D API. > Только нелепые, дилетантские. Нелепо встрявать со своей экспертизой, не разобравшись в сути обсуждения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

135. Сообщение от Анрним (?), 04-Янв-26, 17:35	+/–
К чему ты это мне написал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

137. Сообщение от Аноним (137), 04-Янв-26, 20:43	–1 +/–
> Я уже написал: вывод и композитинг битмапов. Оно и так шустро работает - с лохматых времен. Если апя вывода графония не совсем г-но. Не, "vga" фреймбуфера и Xorg - в "не совсем г-но" не попадают. Но там тупняки на именно скорости вывода битмапы через столь похабные и-фейсы апи. >> Вообще-то обычно в вещах типа Wesnoth это просто блочная копия битмапов в основном. > Ну, и? Это как-то отменяет тот факт, что на CPU для их > отрисовки нужно бежать попиксельно/SIMD циклом. Битмап подразумевает что он УЖЕ есть. И тасовать его попиксельно - в общем случае как раз и не надо, блочное копирование какое скорее. Может быть альфу или цвет посчитать, но вот это как раз можно и кешануть просто. А memcpy() нынче так то и simd-оптимизированный бывает и - упирающийся в скрость работы RAM, а не что-то еще. RAM уж какой есть, быстрее не будет работать. Отдельный VRAM есть только у DGPU но там видите ли есть проблема шаринга системного RAM и VRAM, некие латенся от протона инфо туда-сюда по PCIe и проч. То что это однозначно выигрышное комбо для вон того - ниоткуда не следует. Плееры какие могут шейдерами постпроцессинг оформить вместо CPU, но битмапным игорям сие просто не надо - pixel perfect by design. >> То добро на отлично фигачило на совсем лохматых конфигах с эры чуть не VGA адаптеров, > Ну я же говорю: экспертиза 10/10. Во времена лохматых конфигов и VGA > двумерные спрайты были сугубо 8 бит (палитра 256 цветов) И тем не менее выглядели весьма неплохо за счет адаптивных палитр и их грамотного использования. Кто глядя на Starcraft вообще подумает что там 256 цветов? Но мы можем взять HMM III например. Отлично работают со всеми эффектами, анимахами, без всяких "акселератров 3D" и прочих шейдеров. Плоское 2D как оно есть, если вывод 2D не совсем тормоз - работает изумительно. Что в оригинале что в VCMI. Что там 3D и шейдерами делать то? И SIMD куда применять, по большому счету? К memcpy()? Сейчас его системные либы сами и применят, забыв вас спросить. > и выводились на разрешение в несколько сот пикселей. HMM III так то 800 x 600 нативно и довольно круто выглядит. И даже на винтажном 5x86 с 486 сокетом - единственное что там реально тупило это декод MP3. Грайоний же изумительно пер на этом всем - без каких либо требований 3D, ускорения оного и проч. Все что такому дизайну игоря надо это быстрый вывод 2D которое они скроили. Ускорять там особо нечего. > О чем ты споришь - я хз. О том что HMM III был уже на отличненько 24 bpp и пер без всяких ускорителей с весьма шустрой плавной графикой. И ничего, нормуль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #139

138. Сообщение от Аноним (-), 04-Янв-26, 20:49	+/–
> Зависит от платформы.  Моя десктопня карта такое не поддерживает. Либа должна > интроспектировать карту и выбирать оптимальный формат сама. А, простите, ассеты как юзерям при этом доставлять? Запаковать с игрой пять версий одного и того же? А юзеры качать это все - не заманаются? Проще послать в пень лохов с underspec оборудованием которые мало что дрыщи - так еще и не смогли нарулить свою систему нормально. С таким комбо скиллов и железа - в пакмана играйте в менуэте, большего не заслужили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #140

139. Сообщение от Аноним (51), 04-Янв-26, 22:22	+/–
> Оно и так шустро работает - с лохматых времен. Как скажешь. Какой смысл с неадекватом разговаривать... > Но мы можем взять HMM III например. Отлично работают со всеми эффектами, анимахами, без всяких "акселератров 3D" Хватит бред собачий нести. HMM III требовал GPU с DirectX 7 и 4 MB памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

140. Сообщение от Аноним (141), 04-Янв-26, 23:08	+/–
>А, простите, ассеты как юзерям при этом доставлять? Как - вот игра сама и конвертит, прямо как предлагается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

141. Сообщение от Аноним (141), 04-Янв-26, 23:13	+/–
>Эксперт, а ты не задумывался над тем что компрессия текстур - это lossy процесс lossy. >и для 2D его не делают потому, что никто не хочет видеть угашенные по цветам/деталям спрайты и задники А придётся. Память-то небесплатная, вызов `dimm.emplace_back(memory);` памяти не прибавит. Либо так, либо наслаждайтесь трешингом. >Сжимать текстуры по-умалчанию, убивая тем самым ее цвет и детали Вообще обычно лучше просто разрешение повыше сделать, но при этом - пожать, но большом разрешении артефакты только при зуме видны, да зачастую только на разностном изображении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

142. Сообщение от Аноним (141), 04-Янв-26, 23:15	+/–
Очень интересное чтиво, спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

143. Сообщение от Аноним (-), 04-Янв-26, 23:20	+/–
> Вот этот самый вывод пикселей и ускорять. CPU - это высокопараллелная обработка > с тысячами и десятками тысяч пикселей одновременно. Что вы там ускорять в memcpy() собрались и с чего вдруг его уберпараллелизация даст какие-то бенефиты? > А на CPU ты циклом по каждому пикселю будешь бежать, и даже SIMD тебя не > сильно спасет. Зачем в пикселарте и 2D трогать каждый пиксел? Их просто блочным копироанием фигачат куда надо. И все. Ускорять в этом процессе мало чего. По сути memcpy. > Экспертиза в графике - 10/10. Я вас не заставлял, вы сами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

144. Сообщение от Аноним (144), 05-Янв-26, 00:12	+/–
Объясните пожалуйста GPU api которое то ли работает без отдельного репозитория с транслятором шейдеров то ли не работает... Как его использовать? Насколько все плохо без opengl? webassembly реально не планируется?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема