Без долгих предисловий начну свою трагическую историю...
  Начали мы с товарищем недавно делать квест. Сюжет, графика (2D ala "Петька и Ко") - это не проблема, а вот код... Я перебрал множество бесплатных конструкторов вроде WME, однако, почему-то они мне показались все малофункциональными и я решил изобрести в очередной раз велосипед...)
  Так вот, в чём же суть вопроса... ВОЗМОЖНО ЛИ НАПИСАТЬ ДВУХМЕРНЫЙ КВЕСТ БЕЗ ИСПОЛЬЗОВАНИЯ КАКИХ-ЛИБО ДВИЖКОВ (то бишь - чистый код...)? Я так подозреваю, что возможно (хотя и очень неудобно и вообще...).

  Собственно, кое-какие наработки уже есть, однако, тут же возникают интересные и многочисленные проблемы с, например, TImage, который, при перемещении по экрану (посредством изменения Top и Left) как-то странно обновляется... Короче, это его обновление очень уж заметно невооружённому глазу. Никакие Application.ProcessMessages не помогают. ЧТО ДЕЛАТЬ?!

>   Так вот, в чём же суть вопроса... ВОЗМОЖНО ЛИ НАПИСАТЬ
> ДВУХМЕРНЫЙ КВЕСТ БЕЗ ИСПОЛЬЗОВАНИЯ КАКИХ-ЛИБО ДВИЖКОВ (то
> бишь - чистый код...)?

тут, наверное, какое то недопонимание...
движок - это совокупность высокоуровневых средств для работы с низкоуровневыми операциями (грубо говоря). Он обычно чистый код:) Или речь о GDI?

TImage - это значит, что все хуже, чем кажется на первый взгляд:) Нужно рисовать на TBitmap в памяти все объекты, а потом его выводить одним махом на форму.

<TImage - это значит, что все хуже, чем кажется на первый взгляд:) Нужно <рисовать на TBitmap в памяти все объекты, а потом его выводить одним <махом на форму.

Короче, думаю, ясно, что я ужасный программист... Я имел в виду компонент Image. А изображения в него я гружу в начале работы программы

<движок - это совокупность высокоуровневых средств для работы с <низкоуровневыми операциями (грубо говоря). Он обычно чистый код:) Или <речь о GDI?

Движок - это некая система, облегчающая выполнения многих операций. Например, в квестовых движках "хождение" основного персонажа прописано изначально. По крайней мере, я так думаю =))))

А ведь всё дело именно в этой ходьбе! Предполагается, что наш главгерой будет не только ходить, но и летать. Так что...

рекомендую сначаа поделать игры попроще - Питона, сокобана :)
серьезно:)

> mr.sokolOFF ©

ну тык движок и есть чистый код. По твоему, как движки пишут? С бубном и волшебной палочкой?

> mr.sokolOFF ©   (25.09.07 19:01)

Лучше плюнь на TImage. Это одна картинка выводится на нём туда-сюда, а если их будет целая куча, да ещё с анимациями, то это будут одни сплошные тормоза.

В крайнем случае глянь демки от G32: http://sourceforge.net/projects/graphics32
Там более менее со скоростью нормально.

И думаешь люди от хорошей жизни 3D графику выдумали?

Она позволяет хранить в видеопамяти все твои картинки, и выводить их без лишних тормозов.

И, наконец, главный вопрос, с которого вообще то нужно начинать. Кто будет рисовать персонажей со всеми анимациями и бэки?

> В крайнем случае глянь демки от G32: http://sourceforge.
> net/projects/graphics32
> Там более менее со скоростью нормально.
>
> И думаешь люди от хорошей жизни 3D графику выдумали?
>
> Она позволяет хранить в видеопамяти все твои картинки, и
> выводить их без лишних тормозов.

ой да ладно, хватит и обычных TBitmap :)

Самый простой способ для вывода 2Д графики - это рисовать на Canvas
Сначала всю сцену рисуешь в Bitmap, который хранится в памяти и равен размерам элемента, на который выводится изображение.
Затем на экран одним махом выводишь уже готовую картинку.
Все эти процедуры по копированию картинок туда-сюда можно весьма просто реализовать через функцию BitBlt.  Думаю, с ней вопросов не возникнет. Она весьма хорошо описана в помощи.

>mr.sokolOFF ©   (25.09.07 19:01)
> Собственно, кое-какие наработки уже есть, однако, тут же возникают интересные и многочисленные проблемы с, например, TImage, который, при перемещении по экрану (посредством изменения Top и Left) как-то странно обновляется...

Ты грузишь картинку в контейнер (TImage), у которого офигенная избыточность, для твоих нужд. Потом ты этот контейнер начинаешь мурыжить по форме, вызывая лавину сообщений об обновлении и переисовки на форме и самом TImage.
Если таким образом делать мультипликацию, то уже на паре-тройке TImage всё встанет колом.

Метода создания движущегося изображения придумана аниматорами, в тех лохматых годах, когда даже кино было не мультимедийным :) Однако принципы эти действуют и по сей день.

Итак, берётся картника, которая будет фоном.
Берётся картинка которая будет двигаться.
Берётся картника, которая будет выполнять роль "закулисного" вместилища. Её еще называют back buffer.
Далее, на back buffer копируется изображение фона.
Потом, в нужном месте, копируется картинка, которая двигается.
Затем, back buffer копируется на "экран".
Следующий цикл -
На back buffer копируется изображение фона.
В нужном месте, копируется картинка, которая двигается.
back buffer копируется на "экран".
Следующий цикл - ...

Как это реализуется в двоём случае.
Я пишу самый примитивный вариант, чтобы было предельно просто и понятно. Потом, когда разберёшься с этим, сам поймёшь, как и что улучшить.

На форму ложишь таймер, и устанавливаешь интервал 10.
Объявляешь 3 глобальных TBitmap:
Фон
"Персонаж"
задний буфер.

На событие создания формы
Создаёшь все три битмапа.
Битмапу заднего буфера задаёшь размеры сцены.
Грузишь в битмап фона картинку фона из файла (loadfromfile)
Грузишь в битмап персонажа картинку, которая должна двигаться.

На событие таймера
Копируешь на битмап заднего буфера картинку фона (canvas.draw)
Копируешь на битмап заднего буфера картинку персонажа в нужных координатах.
Копируешь на канвас формы битмап заднего буфера.

Всё. Запускаешь и смотришь.

Если картинка фона меньше по размерам чем задний буффер, то последний придётся принудительно очищать.

Можно использовать готовый движок, если не хочешь изучать какой-то GAPI и писать свой. Та тот же ДелфиХ(или Asphyre) для такой игры покатит.

> рекомендую сначаа поделать игры попроще - Питона, сокобана
> :)
> серьезно:)


Игры попроще? Мною уже был реализован толковый "Компьютерщик")) Толку, конечно, от него - как от тетриса, но всё же...


> ну тык движок и есть чистый код. По твоему, как движки пишут?
>  С бубном и волшебной палочкой?


Вполне вероятно, что я некоректно выразился: ну разумеется, движок - это и есть чистый код. Однако. Мой, пусть и небольшой, опыт делания всяких аркад говорит от том, что для реализации всяких "леталок" в любом движке гораздо больше удобных средств, нежели это творить стандартными средствами дельфи. Скажем, в том же двиге LKI Creator уже сразу существует тип "игровой объект", который имеет массу интересных параметров, вроде "скорость", "кол-во хитпоинтов" и пр. Мысль, надеюсь, ясна.


> И думаешь люди от хорошей жизни 3D графику выдумали?


Думаю, на данном этапе нам будет сложновато реализовывать ещё и 3д))

>
> И, наконец, главный вопрос, с которого вообще то нужно начинать.
>  Кто будет рисовать персонажей со всеми анимациями и бэки?
>


В принципе, мог бы и я, но, слава богу, есть толковый 2д\3д-художник, который с радостью согласился. Другое дело, что он-то действительно толковый, а вот я...))


> Самый простой способ для вывода 2Д графики - это рисовать
> на Canvas


Спасибо большое, Dark Lord, за идею - как-то я сразу об этом и не подумал... Насколько Я понимаю, в качестве cancas'а можно использовать даже саму форму? Или я в очередной раз говорю бред?))

Ну и напоследок - самое главное.

Shirson, спасибо большое)) Мало того, что подсказал и развил идею, так ещё и предоставил псевдокод)) Всё работает! Я весьма удивлён...
Конечно, глупая затея - обходить стороной движки и конструкторы. Может, я всё же образумлюсь... Но пока - всё отлично!) С перемещением, по крайней мере. Анимацию ещё попробовать не удалось...

> Можно использовать готовый движок, если не хочешь изучать
> какой-то GAPI и писать свой. Та тот же ДелфиХ(или Asphyre)
> для такой игры покатит.


Просто всё дело-то в том, что я уже пробовал для этих целей переделать LKI Creator... Однако, обнаружились невиданные глюки))) Но всё же спасибо за совет... Движок - это однозначно - более правильный вариант, нежели заниматься такой вот ерундой...

Хотя... Только что вот обнаружил интересную вещь (типа, глюк).

Создаю я, значит, TBitMap. Гружу в него картинку. Реализую затем её на форму. Сворачиваю форму. Снава разворачиваю - картинки уж нет. Короче, если хоть какое-то стороннее окно (тот же Winamp, например) перекрывает форму - нарисованное в области перекрывания сразу исчезает.

Вопрос: Как быть?

Поётся на мотив оды: ОпенДжыЕль, ОпенДжыЕель, ОпенДжыыЕееееель!!! =)

> Реализую затем её на форму
А по теме: может ты не так "реализуешь"? Выводи прямо на DC окна и 90% вероятности будет тебе щастье...

> [12] mr.sokolOFF ©   (26.09.07 18:53)
> Вопрос: Как быть?

Используй стронний 2D движок.

элементарно ватсон.
Отлавливать события и выполнять перерисовку.

mr.sokolOFF если ты один раз вывел картинку на канву формы, она там проживёт до первого сообщения о перерисовке, которое приходит при перекрытии формы чем-либо или при разворачивании формы.
Если посмотреть внутрь коспонентов, они рисуются. Просто сделано это хитрым способом, с завязкой на события по перерисовке. Потому, компоненты "хорошо выглядят" при всяческих пертрубациях с формой.
В игре такой подход не самый правильный. Если речь идёт про игру с динамичной графикой. Для "Компутерщика" бы прокатило :)

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

>Мой, пусть и небольшой, опыт делания всяких аркад говорит от том, что для реализации всяких "леталок" в любом движке гораздо больше удобных средств, нежели это творить стандартными средствами дельфи. Скажем, в том же двиге LKI Creator уже сразу существует тип "игровой объект", который имеет массу интересных параметров, вроде "скорость", "кол-во хитпоинтов" и пр. Мысль, надеюсь, ясна.

Сначала сам сделай хоть одну игру в динамике. Полностью сам. Когда поймёшь, что к чему и как, когда появится свой стиль и своё понимание, как лучше всего делать, тогда и выбирай из готовых движков.
Много времени надо? Нет, не очень, зато результат будет. А если сразу за движки браться, то а) ничему толком не научишься и б) всё заглохнет из-за непонимания сути процесса построения игр.
Т.е. и время потеряно и результата нет.

> Для этого можно использовать таймер, как самый лёгкий путь.


А нелёгкий?)) Просто циклами обойтись, н-р? Или и то, и то?

Я кстати, тоже абсолютно согласен, что особенно на первых порах важно игру написать от "А" до "Я". Когда опыта много и не хочется возиться с тем, чтобы что-то опять в тысячный раз писать с нуля, можно и движок чей-то взять. Тем более, что если движок действительно функциональный, то в нем еще и разобраться надо. А это тоже непросто. Мне проще лично написать с нуля, чем разобрать чужой код. Особенно когда он сложный и большой. Да и вообще - а зачем вы игру делаете? Ты именно? Если ты не получаешь удовольствия от самого процесса создания - значит и делать ее не стоит. А смысл находя удовольствие в самом процессе написания игры пытаться нарыть готовый движок? Давайте тогда вообще сразу чей-то код полностью стырим, заменим ресурсы простнапросто и скажем что это мой новый супер хит! В чем же тогда прикол?

2Dark Lord
  Разумеется, делается это всё ради удовольствия. Всегда хотел быть девелопером)) Да и программирование мне дико нравится. Раз рисовать не умею - чего ж ещё делать?))
  А насчёт движка - я полагаю просто, что моего уровня (простирающегося лишь, как писал выше, до создания всяких "Компьютерщиков" и прочих "Туалетных империй") не хватает для написания "с нуля". Однако... Будем пробовать с нуля))