Проблемы с подключением Allegro 5 к DEV C++ 5.11

Allegro 5 - это библиотека для 2D игр типа SFML только низкоуровневая, решил в ней покопаться, потому что там графика идёт на любой видяхе даже без драйверов.
Не находит библиотеку allegro_image.h ! Где это взять ? У кого то вообще Allegro 5 присоединялась к DEV C++ 5.11 ,,,,,,???

0

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

Вряд ли кто-то считает иначе

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

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

0

Сообщение от Igor3D Но как грамотно действовать/решать?

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

0

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

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

Вынести долгую операцию в поток (чтобы гуй не замерзал)

Эта популярная рекомендация часто оказывается неверной/неуместной. Может даже в большинстве случаев. Пример

Приложение грузит (большой) файл данных, напр 3D сцену. Должна ли загрузка быть в отдельном потоке?

Первая реакция типа "да, конечно должна! Ведь это учебный/хрестоматийный пример". Но, поразмыслив, приходим к выводу что нет

0

Igor3D, в серьезных случаях я даже сделал бы не отдельные потоки, а даже отдельные процессы.

Вот, возьмем к примеру Google Chrome. Ты глянь, сколько процессов он создает.
- процесс самого браузера
- процесс рендера для каждой открытой вкладки !
- процесс GPU
- процесс сети
и т.д.

А почему браузер создает по процессу для каждой открытой вкладки? Потому что, это перестраховка. Если на какой-то вкладке/странице случится глюк и прочее, то чтобы эта вкладка во время своей гибели не убила сам браузер. В случае краша и прочего, уничтожится процесс вкладки, а браузер будет работать дальше.

А вот внутри процессов есть уже потоки.

А прикинь, ты работаешь в 3d редакторе, при загрузке 3d сцены/модельки случается глюк/краш и весь редактор крашится и ты теряешь работу... В таких глючных редакторах единственное решение это юзать автосохранение с маленьким интервалом. Но фича автосохранения влияет на производительность.

1

Royal_X, современные браузеры стали намного лучше обрабатывают ситуации когда страница потребляет память до упора или уходит в "бесконечный цикл", не вешая при этом ОС/ПК и даже себя.
Но это связанно не только с многопроцессорной архитектурой. Потому что с этой задачей хорошо начали справляться относительно недавно. Ещё что-то придумали/поправили.
С загрузкой сцены может быть и часто бывает в играх. Что при загрузке, вылетает игра, и если ты не сохранился...
А ведь можно и с этим справляться. Как минимум дать возможность сохранится.
Учитывая современную архитектуру ПК и ОС, боятся потоков/процессов, архаичность, не более.

1

Все хорошо про "современные браузеры" и.т.п. Но вот простой, житейский вопрос

Сообщение от Igor3D Приложение грузит (большой) файл данных, напр 3D сцену. Должна ли загрузка быть в отдельном потоке?

И ответа как-то не звучит

0

Простой житейский ответ. Никто никому ничего не должен, можешь грузить как хочешь.)

0

Royal_X, вулкан работает медленнее чем Direct X, - это жертва кроссплатформенности !

Добавлено через 1 час 7 минут
НЕ РАБОТАЕТ статическая линковка Ни с библиотеками -s Ни с библиотеками -s-d
Может надо чтото в makefile.win дописывать ?> Который автоматически создаётся ?

в линковщике
-lsfml-graphics-s
-lsfml-window-s
-lsfml-system-s
-static-libgcc
-static-libstdc++ Проект на релизе, все каталоги прописаны и ничего не работает
тоже добавлено. В чём проблема ?

Всё, короче можно оставить всё в дебаге и без статика и там всего два DLL от компилятора в папку с проектом закинуть надо
Я то думал он весь компилятор заставит в проект качать

0

Сообщение от Mr_den -lsfml-graphics-s -lsfml-window-s -lsfml-system-s

для динамической линковки, когда используется CMake-проект, действительно трех библиотек указать достаточно, чтобы заработал пример из сайта SFML, поскольку остальные подтягиваются сами. Если не ошибаюсь, даже одной графической либы достаточно в CMakeLists.txt.
Но для статика я указываю прям все зависимости, причем порядок, как ты прописываешь либы, тоже имеет значение.

для VS 2022 я указываю эти либы

этот список из официальной документации для SFML 3.1. Но на практике порой нужно и другие либы подключать, например, при работе со шрифтом, оказалось, что нужна еще либа harfbuzz.lib. Но эту либу разрабы начали юзать с версии 3.1 и наверное они забыли обновить документацию.

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

0

Сообщение от Royal_X При статике в бинарник пойдут только те символы, которые ты действительно используешь.

Звучит слишком обнадеживающе.
Вереница зависимостей символов может тянутся далеко. Но на практике, это больше половины либы.
А то что неиспользуемые либы не участвуют в линковке, это да.

0

RabbitAttaks, это, кстати, еще одна из причин, почему я не люблю динамическую линковку. Допустим, есть либа на 25 МБ и оттуда тебе лишь нужен один символ. При статике вся 25-мегабайтная либа не пойдет в бинарник. Компоновщик видит, что нужен лишь один символ и затаскивает только этот символ и смотрит дальше, если этот первый символ запросил куски из других символов, то и их затаскивает. И так делает, пока всё нужное не будет выбрано.

Но есть один нюанс. Статик так прекрасно работает, только если либа создана не криво. Если вся либа создана из одного объектного файла, то вся статическая либа пойдет в бинарник. Компоновщик не умеет вырезать куски из объектных файлов.
Но, обычно, в приличных библиотеках типа SFML, wxWidgets, Qt и т.д. одна либа (имеется в виду .a / .lib файл) содержит множество .o файлов. Это видно и во время компиляции этих всяких фреймворков, когда множество .cpp файлов сперва компилируется в .o и потом вся группа .o файлов идет в один .a / .lib файл.

0

Сообщение от Royal_X Статик так прекрасно работает, только если либа создана не криво. Если вся либа создана из одного объектного файла, то вся статическая либа пойдет в бинарник. Компоновщик не умеет вырезать куски из объектных файлов.

Это объясняет почему итоговый файл больше ожидаемого и уменьшается раза в (3-5)+ после strip)

0

RabbitAttaks, ради интереса проверил sfml-graphics-s.lib

Т.е. видно, что SFML грамотно делает библиотеки.

С другой стороны, начиная с SFML 3.1 для работы со шрифтами, нужно использовать либу harfbuzz.lib, которая весит 13,6 МБ. По крайней мере, загрузка ttf-шрифта без этой либы уже не получается.

А тут всего один объектный файл. Из-за этого, размер бинарника прилично увеличивается при использовании этой либы.

0

Сообщение от Mr_den #define SFML_STATIC

Сообщение от Mr_den тоже добавлено. В чём проблема ?

Это ещё что такое и куда его добавляют? В кормовые добавки?
Как будто попал в фильм "Тупой и ещё тупее".

0

Сообщение от Igor3D Первая реакция типа "да, конечно должна! Ведь это учебный/хрестоматийный пример". Но, поразмыслив, приходим к выводу что нет

Если мы говорим про десктоп или мобильные, то если ассеты небольшие (несколько десятков или сотен мегабайт), то можно загрузить сразу в одном потоке после запуска приложения, показывая Progress Bar. На десктоп, как правило, ассеты загружаются с SSD, а не скачиваются с интернета. Но если ассеты весят десятки и сотни гигабайт, то не хватит RAM, чтобы сразу всё загрузить, либо не хватит VRAM. Поэтому ассеты загружают и выгружают по мере того, что видит или увидит пользователь во время отрисовки сцены.

Для веба есть асинхронная загрузка для C/C++ с помощью emscripten_async_wget(), что никак не влияет на рисование. На вебе нужно уложиться в 1-3 секунд первой загрузки, потому что, например, согласно исследованию Google 53% пользователей прекращают загрузку веб-приложения, если оно грузятся дольше 3 секунд. Это цитата из статьи с запрещённого в РФ LinkedIn (перевод с английского с помощью Google Translate):

53% посещений мобильных сайтов заканчиваются отказом, если страница загружается дольше 3 секунд». Это слова Даниэля Ана, глобального руководителя отдела разработки продуктов в Google, основанные на внутреннем исследовании более 900 000 мобильных страниц. Это же исследование показало, что при увеличении времени загрузки с 1 секунды до 3 секунд вероятность отказа мобильного посетителя возрастает на 32%. Увеличьте время загрузки до 5 секунд, и вероятность отказа достигнет 90%.

На Grazy Games даётся только максимум 50 МБ для обязательной первой сцены и 250 МБ для остальной сцены. Рекомендуют первую сцену делать не больше 20 МБ. На itch такого нет, но логично, что на веб надо делать отложенную асинхронную загрузку потому что, алгоритмы продвижения этих площадок быстро отбросят приложение, которое долго загружается, потому что пользователи будут его закрывать и переключаться на соседние приложения из предложки.

Я будут стараться избегать работы потоками на вебе (Web Workers) до последнего, когда без этого невозможно уже будет, даже для физического движка. Для небольших проектов это не нужно, это добавит огромное количество сложностей и съест много времени на исправление багов, специфичных для многопоточности, и на саму разработку. Сейчас многие современные физические движки, которые собираются в Wasm, поддерживают SIMD, например: Box2D, Jolt Physics, Bullet Physics и т.д. Да, конечно, если на сцене решу сделать разрушающееся здание на Jolt, то update() физического движка может не уложиться в 16 мс между кадрами отрисовки, но пока такое не нужно. Даже для написания своего сервера на C++ для небольшого мультиплеера можно обойтись без потоков, если найти подходящую либу, с которой можно взаимодействовать ассинхронно.

Физика по-любому нужная для многих игр, что в 2D, что в 3D. Сейчас мне интересно знакомиться с новым Box3D, который намного намного легковеснее, чем Jolt Physics, и Box3D почти один в один по API, как Box2D v3, что упрощает работу с ним для тех, но работал и работает с Box2D. Box3D на альфа стадии разработки, но пока его на базовом уровне освоишь, он уже не будет альфа. Это видео от разработчика Box3D на YouTube:

0

Сообщение от 8Observer8 Я будут стараться избегать работы потоками на вебе..

Ну (упорно) избегать не стоит, ничего особо страшного там нет, просто часто "вынос в поток" неуместен

Сообщение от Igor3D Приложение грузит (большой) файл данных, напр 3D сцену. Должна ли загрузка быть в отдельном потоке?

Здесь зависит от того умеет ли приложение работать с 2 (и более) сценами. Если да, то все получается "по книжке", загрузка второй сцены в фоне = то что нужно, юзер спокойно продолжает работать с текущей сценой пока вторая грузится. А если есть опасность краша, то не нужно стесняться спросить юзера сохраниться. Заметим что краш (как exception) в другом потоке приятнее
Однако очень может быть что приложение работает только с одной сценой (в данный момент времени). Тогда загрузка сцены в отдельном потоке - только лишние, ненужные заботы как для программиста, так и для юзера, ведь он не может предпринять ничего разумного пока сцена не загрузится (наоборот, надо еще следить чтобы не нагадил). Правильное решение здесь выставить модальный индикатор прогресса загрузки. "Ложный вынос" - очень популярная ошибка. Ах, гуй залип, в поток, в поток это! И побежал выносить. Да еще ИИ подтвердит

Заметим что "вынос в поток" сам по себе скорость не повышает. И создает ложную иллюзию что потоки - да это, мол, "элементарно", "за 2 минуты", "чего их бояться" и.т.п. Ну это пока переписываются книжные примеры

0

Сообщение от Royal_X вот мой сапер

Что-то нет так?

Миниатюры

 

0

упс

0

Сообщение от vlisp Что-то нет так?

Да, в сапера играть не умеешь)

1

Сколько можно наступать на эти грабли? Dev-C++ нужно похоронить официально. Возьми нормальный clang через winget, иначе так и будешь вечно воевать с отсутствием allegro_image.h.

0