ClearWorld

[is.SarCasm]

Буквально недавно начал юзать эту команду и задумался. Она вообще как то влияет? Допустим ну загрузил я 1 уровень перешел на второй. Будут ли вообще как то влиять ресурсы с первого уровня на игру?

[H@NON]

ClearWorld() очищает ентити, браши, текстуры, загруженные в блитц. Как они могут влиять на что-то если их не будет ? разве что выдадут ошибку при попытке доступа к ним.

[is.SarCasm]

Хм...тогда какой смысл в использовании этой команды... ( я просто понять не могу_

[NitE]

как ты думаешь что делает эта команда ? правильно

очищает ентити, браши, текстуры, загруженные в блитц

[Dream]

очищает память проще говоря

[Ky3R_94]

её удобно юзать если влом писать функцию очистки уровня. тогда в апдейте нужно сделать проверку на валидность объекта(энтити и т.п.). если инвалидно, то сносим до конца с помощью delete. но если честно, то пока обходился и без clearworld

[impersonalis]

Сообщение от Igorian

Хм...тогда какой смысл в использовании этой команды... ( я просто понять не могу_

во многом соглашусь. при адекватном менеджементе игровых объектов - команда бесполезна.

[Dzirt]

Думаю команда создана для новичков(или просто любителей) которые используют Goto.Тогда скелет игр должен выглядеть примерно так:

[initialization]

.new_level
[load resurces]

[main cikle]

Clearworld()

Goto new_level

Если непользоватся типами совсем....и иметь много обектов разного предназначания,то стирать все ручками будет неудобно...именно для єтого она по моему мнению и бЫла создана.

[Randomize]

Программа:

1) инициализация
2) загрузка ресурсов
3) процесс (основной цикл)
4) выгрузка ресурсов (он самый ClearWorld и схожие операции)

В каждой программе её использую на ряду с EndGraphics().
Перед закрытием любого приложения не желательно, а очень важно всё выгружать (у Дяди Пети и так много дел).
Для эксперемента сделай рекурсивный батник который запустит 100 твоих приложений. А потом с ним попробуй.

[impersonalis]

Сообщение от Randomize

Программа:

В каждой программе её использую на ряду с EndGraphics().
Перед закрытием любого приложения не желательно, а очень важно всё выгружать (у Дяди Пети и так много дел).
Для эксперемента сделай рекурсивный батник который запустит 100 твоих приложений. А потом с ним попробуй.

http://forum.boolean.name/showpost.p...70&postcount=7
Кстати - перечисленные тобой действа не чистят память от экземпляров типов и проч.
Удаление ентити\имейджей и т.п. логично встроить в "деструкторы" типов, кторые их используют.
Смысла в команде - нет.
Разве что для бета-бета проги, которой не суждено перерасти во что-то серьёзное (раз до сих пор нет деструкторов!), или как тест - всё ли удалено (проверить объём занятой памяти после совей очистки и после топорной).

[Randomize]

У многих в B3D как:
Global чтото=LoadMesh("path")
Global чтото=CreateLight()
Global чтото=CreatePivot()
И прочее
Далее типы, а уж после них цикл.
Говоря о конечных проектах, то большенство проектов играбельных где был сорец я видел именно с такой организацией кода. Тоесть вверху сорца 30-50 глобалов а дальше типы.
Деструкторы в данном случае работают только с памятью типов, а остальное возложено на Дядю Петю.

[impersonalis]

вверху сорца 30-50 глобалов а дальше типы.

Думаю, если бы Лебедев был программистом, он бы сказал так
В идеале (в идеале для б3д) код вообще может (должен!) обходиться без глобалов. Известный в ГД человек советовал все их объединять внтри единственного экземлпяра типа для хранения глобальных перменных. Подобный подход улучшает переносимость и модульность кода, избавляет от багов из-за очепяток (т.к. производится контроль существования поля), позволяет ввести глобалы в единую для остальных объектов логику (создал-поюзал-удалил).
То что вы видели, имхо, разновидность Китайского кода. Это что же: вы когда гаджеты на форме делаете, хайдите и удаляете их вручную комбинацией из N повторяющихся строк? Или они всё же хранятся во внутреннем списке (учитывая что в блитце низкая типизация и удобные функции типа EntityClass$( entity ), написать деструктор приемлимого уровня абстракции легко)?
Кроме того - что эе это за ентити-глобалы такие? Даже интересно: террайн? фигня - он элемент уровня и имплементируется в соотвестующий тип! Камера? - относится к абстрактному типу присутсвие_игрока или непосредственно к типу игрок и т.д. и т.п.

[Randomize]

На счёт структуры приложения полностью согласен. Программы написаные таким образом более легки к восприятию ибо мы видим чёткие разграничения на уровни абстракции. Я вобще ярый сторонни MVC. Просто в своё время научен горьким опытом, когда сам не мог понять свою писанину.

По поводу проектов:
Все дефолтные примеры в папке Source Blitz3D (чёрт побери)
Особенно проекты с start.bb порадовали.

* Cразу предупреждаю авторов проектов, я нехочу никого обидеть, я просто привожу примеры и это не значит, что ваши проекты плохие.
Проекты "нашего городка":
http://forum.boolean.name/showthread.php?t=10381
http://forum.boolean.name/showthread.php?t=9663
http://forum.boolean.name/showthread.php?t=9643
http://forum.boolean.name/showthread.php?t=9004
http://forum.boolean.name/showthread.php?t=8425
Дальше продолжать не буду, думаю и так понятно.
Разработчику BlitzHacker`а подтвердить это будет не сложно.

Я вобще к чему. Я не доказываю свою правонту или вашу неправоту.
Я просто говорю, что 70-90% кодеров на булке работающих непосредственно с Blitz3D используют именно такой подход при разработке, как я писал выше. В принципе даже в таком "стиле" если можно так выразится может получится отменный игровой проект.
Я считал, что незримо все понимают какими способами сейчас в основном ведётся разработка на B3d. Это можно увидить по многочисленым исходникам, видимо ошибался.

Спасибо за ссылки. Очень улыбнуло

Как уже говорилось, некотором индусам до сих пор платят не за качество, а за количества кода, в результате чего можно встретить подобные шедевры (и это только цветочки!):

if (true) {
    // какой-то код
} else {
    // a вот тут чистый profit
}