Неприятное в BlitzMax, ч.2 - библиотеки

2.1. Нет списка со значениями, не являющимися объектами. Например, целыми - Int.

2.2. Списки не очень удобно реализованы. Было бы хорошо наличие у элементов списка TLink поля Parent, для ссылки на родительский список (И поля Child для многоуровневых древовидных списков). Это связано с менеджером памяти языка, который не в состоянии корректно удалять объекты с кросслинками.

2.3. Утечка памяти в функции LoadImage при загрузке *.png. Ее практически не заметно, т.к. вылазит она при особых случаях, например при перегрузке картинок, что обычно не требуется - они загружаются один раз обычно. Но, например, при отсутствии менеджера ресурсов, когда нам нужно перезагружать изображение (при обработке скриптов, например), то утечка становится заметной. Причем внутренний меденжер памяти утечку не показывает.
Прим.: при загрузке *.jpg утечки нет.

2.4. При создании нового pixmap, он не инициализируется. Т.е. мы создали новый pixmap, а там мешанина из пикселов, а не черный или белый или заданный программистом фон. Надо писать функции заполнения новообразованных пиксмапов, а это - время/деньги.

2.5. Неясности со шрифтами: LoadImageFont("Arial.ttf"…) не приводит к ожидаемому результату, а с полным путем LoadImageFont("C:\Windows\Fonts\Arial.ttf"…) все работает. Хотелось бы без указания путей. Хоть и есть фонт по умолчанию.

2.6. Отсутствие такого хорошего понятия как контекст устройства. Есть в вынь и в пурике ( StartDrawing(OutputID) ). На CreateGraphics(…) его заменить нельзя - если разрешение не поддерживается, контекст не создается. Это очень-очень плохо. Нельзя рисовать нормально в оффскрин окно. Другими словами рисовать в текстуру (спрайт) можно только ручками через массив пикселей, что медленно. Сторонние библиотеки для этого - платные.

2.7. Метод pixmap. Paste(…) не проверяет размеры - это приводит к глюкам с затиранием памяти и необходимостью писать много чего своими ручками. Это unsafe (при том, что полезные вещи в страхе этого самого unsafe не делаются), и время/деньги на дополнительный код.

2.8. Глючность идиотическая, надеялся, что такого не встречу. Пример: когда работа с пиксмапами формата PF_RGBA8888 проходит отлично, а смена формата на PF_BGRA8888 приводит к непонятным глюкам в официальных библиотечных функциях.

2.9. Глюки при работе с созданием пиксмапов, если их делаешь много, то возникает глюк. Этот глюк как-то связан с форматом картинки. При формате PF_BGRA8888 он возникает раньше. GCCollect() не помогает, дело не в переполнении, а хз в чем.

2.10. Звук: Полная распаковка/загрузка в память, потом проигрывание. Это приводит к тому, что мы в программе уже запустили звук на проигрывание, а оно начинается позже - после полной распаковки. Это заметно даже на не сильно больших звуках, не треках. Сначала было совсем жестко - распаковка была не в отдельном процессе и можно было нарваться на притормаживания при попытках проиграть звук. Сейчас сделали распаковку в фоне (отдельным процессом). Этим убрались притормаживания всего приложения при проигрывании. Но остались паузы между желаемым началом проигрывания (вызовом в коде) и реальным началом, когда уже слышен звук.
При этом фоновая распаковка породила другую проблему. Тормоза при не фоновой распаковке можно было обойти правильной организацией ресурсов. Загрузкой и распаковкой звуков в начале игры или уровня, когда можно и подождать. Таким образом, при самой игре звуки проигрывались уже распакованные из памяти, не вызывая никаких нареканий. Теперь при такой организации, если приложение загрузилось достаточно быстро, а звуки в фоне не распаковались, то опять есть паузы в начале работы, между тем, когда звук должен проиграться и когда он звучит на самом деле. Вылез теперь немного иной недостаток - невозможность узнать, когда звук распакован, чтобы дождаться полной загрузки ресурсов.
Правильнее бы делать блочную распаковку/загрузку и проигрывание. Как в винампе, например. Когда подгружается кусок и распаковывается быстро и играется сразу, незаметно для слуха. А потом в фоне догружаются остальные части.