|
Monkey Разработка игр на движке Monkey |
26.03.2013, 17:53
|
#1
|
Злобный Админ
Регистрация: 04.09.2005
Сообщений: 5,926
Написано 3,415 полезных сообщений (для 9,330 пользователей)
|
Отрицательные моменты в Monkey
Для того чтобы у всех сформировалось правильное представление об этом движке, надо добавить к плюсам и очевидные минусы.
Поехали: - В Monkey нет такого понятия как Деструктор. Сам Марк пишет в хелпе что всё заменяет сборщик мусора, и всё что нам нужно это присвоить Null объекту. И вот тут и кроется противоречие. Если в вашем классе есть поля являющиеся объектами (данные по ссылке), то при удалении объекта класса этим полям так же нужно присвоить Null, иначе сборщик мусора их не заметит. Обычно это делается в деструкторе, где программист указывает как правильно удалить связанные данные. Причём этих проблем полны стандартные модули. Например:
Local myImage:image = LoadImage("someimage.jpg")
'free memory by Mark's solution
myImage = Null
'memory leak
|
Память утекает потому что внутри класса image есть поля ссылающиеся на текстуру, и их надо обнулить вручную. Благо Марк таки предусмотрел метод который это сделает, но вызывать его надо вручную до обнуления самой картинки так:
myImage.Discard()
myImage = Null
|
Вот такой вот костыль, а стоило сделать чтобы все методы Delete или Discard были деструктора и вызывались сами при обнулении - было бы всё красиво. Однако проблема куда глубже чем одна дополнительная строчка при удалении картинки: если мы загрузим картинки и будет хранить их в списке, то возможно нам захочется удалить их все просто воспользовавшись методом Clear списка. Который уничтожает все элементы. Однако опять же кто будет вызывать Discard() у каждой картинки? Fail - Нет никакого нормального способа получить доступ к пикселям картинки. Только через граббинг бэкбуфера, что имеет такие побочные эффекты как отсутствие изначальной альфы, необходимость делать граббинг в событии OnRender, и ограничение на размер картинки - не превышающий размеры этого самого бэкбуффера который обычно равен текущему разрешению экрана/окна
- Очень большие ограничения на свободное чтение/запись файлов. В основном Monkey предлагает загружать файл одним махом и потом работать с результатом, рандом же доступ к файлам обычно осложнен или вовсе запрещен (особенно это странно при доступе на чтение).
- Отсутствие вообще какой либо поддержки работы с файловой системой. Небольшая поддержка имеется лишь у пары таргетов.
Продолжение следует
__________________
|
(Offline)
|
|
Эти 6 пользователя(ей) сказали Спасибо SBJoker за это полезное сообщение:
|
|
26.03.2013, 19:41
|
#2
|
Разработчик
Регистрация: 17.01.2007
Сообщений: 409
Написано 114 полезных сообщений (для 281 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Объективные и верные замечания. Хотел только немного уточнить ситуацию под Discard.
Этот метод нужно использовать только тогда, когда вы больше не планируете использовать высвобождаемый ресурс, совсем. Т.к. в противном случае, при обращении к изображению ссылающемуся на ресурс, который был высвобожден из памяти вы получите ошибку. Именно поэтому не всегда удобно и практично добавлять этот метод в деструктор. Лучше, чтобы этим занимался менеджер ресурсов
Например:
Local myImage:image = LoadImage("someimage.jpg")
Local myImage2:image = myImage
myImage.Discard()
myImage = Null
'ошибка
DrawImage(myImage2, 0, 0)
Так, ошибки не будет (утечки памяти тоже не будет):
Local myImage:image = LoadImage("someimage.jpg")
Local myImage2:image = myImage
myImage = Null
DrawImage(myImage2, 0, 0)
myImage2.Discard()
myImage2 = Null
Также, нет смысла вызывать Discard для изображений полученных через GrabImage. т.к. эти изображения хранят только ссылку на источник, а не новую копию ресурса. Mojo это учитывает и игнорирует высвобождение ресурсов.
Discard помимо изображений нужно вызывать также и для звуковых файлов. Опять таки только в том случае, если больше не планируете использовать данные ресурсы.
|
(Offline)
|
|
26.03.2013, 20:39
|
#3
|
Злобный Админ
Регистрация: 04.09.2005
Сообщений: 5,926
Написано 3,415 полезных сообщений (для 9,330 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Ну это всё понятно, класс image был приведен как пример от Марка. На самом деле для вообще любого класса верно то что перед удалением объекта класса нужно обнулить все поля являющиеся объектами (т.е. не примитивными типами данных) включая массивы. И это явно указывает на отсутствие деструкторов как понятия.
__________________
|
(Offline)
|
|
26.03.2013, 20:44
|
#4
|
.
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений (для 6,863 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Вопрос относительно этих ссылок: это относится только к медии, или также распространяется на объекты в коде? Или же Марк всё таки реализовал глубокое сканирование на ссылки для сборщика?
UPD
Сообщение от SBJoker
Ну это всё понятно, класс image был приведен как пример от Марка. На самом деле для вообще любого класса верно то что перед удалением объекта класса нужно обнулить все поля являющиеся объектами (т.е. не примитивными типами данных) включая массивы. И это явно указывает на отсутствие деструкторов как понятия.
|
Это указывает на отстутсвие глубокого сканирования для сборщика. Т.к. большинство языков с автоматической сборкой мусора, имеют глубокое сканирование.
Но тут всё имхо сложнее, т.к. все платформы под которые он компилирует имеют разные имплементации по сборке и деструкторах, и наследование или перегрузка методов деструкции - её вроди нету в Monkey?.
Относительно файлов - тут всё очевидно же, работа с файлами не только отличается по функциям и правам доступа на разных платформ, но и ещё хуже совсем другими принципами работы с файлами, что объединить под одним представлением будет очень сложно, скорее всего это приведёт к куче кривых дополнений по конверсиям и т.п. например в бинарный вид, и ещё чего похуже..
|
(Offline)
|
|
26.03.2013, 20:51
|
#5
|
Разработчик
Регистрация: 17.01.2007
Сообщений: 409
Написано 114 полезных сообщений (для 281 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Сообщение от SBJoker
Ну это всё понятно, класс image был приведен как пример от Марка. На самом деле для вообще любого класса верно то что перед удалением объекта класса нужно обнулить все поля являющиеся объектами (т.е. не примитивными типами данных) включая массивы. И это явно указывает на отсутствие деструкторов как понятия.
|
Просто не очень удачный пример приведен. Одно дело выгрузка ресурсов из памяти, другое - обнуление ссылок. В остальном согласен.
|
(Offline)
|
|
26.03.2013, 21:54
|
#6
|
|
Ответ: Отрицательные моменты в Monkey
ой нимагу жить без супер умного GC, говно говно говно
|
скока можно же
|
|
|
26.03.2013, 22:03
|
#7
|
[object Object]
Регистрация: 01.08.2008
Адрес: В России
Сообщений: 4,361
Написано 2,473 полезных сообщений (для 6,857 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Какой сборщик? В каждом таргете тупо юзается свой сборщик вот и всё.
Пишем на мартышке - js|as|c#|c++,gcc в уме.
__________________
Retry, Abort, Ignore? █
Intel Core i7-9700 4.70 Ghz; 64Gb; Nvidia RTX 4090 3070
AMD Ryzen 7 3800X 4.3Ghz; 64Gb; Nvidia 1070Ti
AMD Ryzen 7 1700X 3.4Ghz; 8Gb; AMD RX 570
AMD Athlon II 2.6Ghz; 8Gb; Nvidia GTX 750 Ti
|
(Offline)
|
|
26.03.2013, 22:43
|
#8
|
.
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений (для 6,863 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Сообщение от Randomize
Какой сборщик? В каждом таргете тупо юзается свой сборщик вот и всё.
Пишем на мартышке - js|as|c#|c++,gcc в уме.
|
Ну по сути можно было бы и реализовать абстракцию деструкторов для всех платформ, что решило бы проблему, как предложил SBJoker.
|
(Offline)
|
|
26.03.2013, 23:20
|
#9
|
Разработчик
Регистрация: 17.01.2007
Сообщений: 409
Написано 114 полезных сообщений (для 281 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Сообщение от MoKa
Ну по сути можно было бы и реализовать абстракцию деструкторов для всех платформ, что решило бы проблему, как предложил SBJoker.
|
Так как не все языки поддерживают деструкторы, то единственный выход который я вижу - на уровне транслятора, во время транслирования, добавлять вызов деструктора перед = Null. Например есть следующий код,
После трансляции получаем:
If (a <> Null) a.Destroy()
a = Null
Но это далеко не самый оптимальный подход. Чтобы избежать лишних вызовов по мне лучше самому контролировать этот процесс (в данном случае). Можно написать свой деструктор, просто не забывать его вызывать, вот и все.
|
(Offline)
|
|
Эти 2 пользователя(ей) сказали Спасибо devolonter за это полезное сообщение:
|
|
02.04.2013, 21:34
|
#10
|
ПроЭктировщик
Регистрация: 19.02.2011
Сообщений: 134
Написано 81 полезных сообщений (для 219 пользователей)
|
Ответ: Отрицательные моменты в Monkey
Сообщение от devolonter
<snip>
|
Проблемы сборщика мусора это проблемы сборщика мусора.
А если он не проверяет связи между переменными, то он уже не совсем то и сборщик.
Приведенный метод вроде бы и работает, но на самом деле порождает еще большее количество проблем.
Рассмотрим, к примеру, такой случай:
Есть некий глобальный assets, в котором хранятся загруженные ресурсы (дабы память не переводить дубликатами тех же изображений).
Мы загружаем на старте игры в него изображения:
assets.circle_png = LoadImage("circle.png")
assets.dog_png = LoadImage("dog.png")
' (и так далее)
Так же допустим, что у нас есть некий класс объекта, отображающего изображение из своей переменной (как PictureBox в NET/VCL/...).
И мы делаем подобную манипуляцию:
' Загружаем изображение в элемент 1:
picture1.image = assets.circle_png
' Загружаем изображение в элемент 2:
picture2.image = assets.circle_png
' После, к примеру, нам нужно выгрузить изображение
' из элемента 1. Может быть это деструктор, может
' нам просто нужно убрать из него изображение...
picture1.image = null
' И тут программе приходит конец: мы только что
' успешно выгрузили из памяти изображение, которое
' еще используется в элементе 2.
Конечно же, можно было бы сделать подсчет ссылок, и вызывать деструктор при потере последней ссылки на экземпляр, но это возвращает к ранее упомянутой проблеме того, что в JS и AS модифицировать сборщик мусора нельзя вовсе.
В общем, нужно или ждать пока разработчики добавят достойный сборщик мусора, или использовать текущий "полу-ручной" метод управления памятью.
__________________
Мой сайт-блог. Игры, обновления, примеры для Haxe, JavaScript(+HTML5), GameMaker, Love2d...
|
(Offline)
|
|
Ваши права в разделе
|
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 05:05.
|