Решил изучить эту новую (для меня) фишку пакета. Штатные примеры (для меня) слишком запутанные, хотелось бы два простых примера:

• Неподвижный спрайт (лучше - два)
• "мячик в коробке" (спрайт, отражающийся от краёв формы)

Плюс есть ряд вопросов:
1. Как взаимодействовать со спрайтом с помощью мыши?
2. Как отрабатывать "многерные" (тройные и более) коллизии?

Заранее спасибо!

Пример вывода стпайтов - статический и с анимацией
code_18259.txt

отражение от краев формы
code_18260.txt


для определения попадания мышью в спрайт использовать PointInRect


каждое пересечение спрайта с другим объектом сцены пораждает событие onHitX или onHitY, которое выдает в поток ID объекта и ссылку на него. Соответственно проверка ID на конкретное значение позволит управлять каждым столкновением в отдельности.

Можно доработать спрайты что бы динамически загружать массивы или хотя бы отдельной спрайты, а то чтобы заменить картинку спрайта приходиться все пере компилировать

А мне хотелось бы видеть просто элемент "Рикошет", так было бы более понятно.
Задал в свойствах с какими объектами проверять коллизии и все. Столкнулся, отразился.
А так же элемент "гравитация", "прыжок" итд как во многих игровых движках.
Собственно понимаю что написал для галочки, но это так вдруг появятся доработчики Game Engine

Еще есть сложности в понимании защиты ресурсов. Ну не должен разработчик отвлекаться на технические моменты... что где зачем защищать..

Еще сложно отлаживать схемы. Ставишь Дебаг и схема виснет или рантайм.
Бывало так зависнет, что только ресет один ответ.

ЧЯДНТ?

code_18268.txt

003 и 004 GE_SpriteMove Sprite = (empty)
code_18274.txt
Если понажимать на add (раз 10-20) можно понаблюда за жизнью в муравейники .

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

sla8a, спасибо! И всё же, походу, нужную логику на GE не сделать - слишком запутанная будет схема. Но в этом есть и плюс - можно будет изучить PyGame.

конечно же для игрового движка нужно прикручивать что-то готовое - с нормальной физикой и отрисовкой спрайтов в DirectX и OpenGL.

Dilma, там физики нет - одна химия ;) Проблема в том, что у игры есть три разных состояния: добавление объектов так, чтобы не было коллизий; перемещение объектов (захват мышкой, до отпускания проверки на столкновения отключены); отпускание объекта - с проверкой коллизии и (если соответствует правилам) удаление объектов (плюс иногда удаление объекта определённого типа, находящегося где-то ещё в поле). Количество типов объектов - 170, для каждого свой набор правил взаимодействия с остальными.

1 А как создать новый спрайт во время выполнения программы?
2 Есть ли возможность дублировать спрайты?
3 Можно ли реализовать отдельную точку для задания имени спрайта?

Antender,
1. Смотри примеры выше. Там как раз создаются спрайты во время выполнения программы
2. Смотри примеры выше. Там как раз дублируются спрайты во время выполнения программы
3. А зачем?

1 Не создаются - там количество спрайтов жёстко заданы
2 Не дублируются - только перемещаются
3 Чтобы можно было менять выводимые на экран объекты, либо требуется метод создания спрайта.

У спрайта есть метод doDestroy, но нет doCreate

Antender, это всё делается через GE_SpriteArray

Так GE_SpriteArray просто контейнер для спрайтов - у него ни одного метода нет