Помогите плиз! Нужно срочно узнать, как средствами 2D делать псевдо 3D гравику??? Тиееся в виду игры такого характера:
http://www.kujuwireless.com/games_lotus.htm
Буду очень благодарен всем, кто ответит по теме!
Необходимо в работе, помогите плиз!!!

А что в этом сложного ?
Делишь всю графику на следующие категории:

1) горизонт-бэкграунд - постоянное изображение бэка, представлен битмапом в половину высоты экрана и шириной в 180 градусов (ну или 360, если трасса позволяет развороты)
2) трасса-бэкграунд - фон трассы ("ландшафт" вокруг неё). Обычный битмап, который повторяется по вертикали (wrapped), и можно просто смещать его сверху вниз, чтобы имитировать движение вперёд
3) объекты на трассе-бэкграунд - спрайты (битмапы с прозрачными пикселами), которые размещены на трассе-бэкграунд и имитируют движение вперёд. Примеры: щиты по бокам трассы, кактусы в пустыне, деревья на европейской трассе, железяки на индустриальной трассе, "зрители"-спрайты
4) сама трасса - это набор спрайтов, небольших по высоте и по длине равных ширине трассы на самом близком приближении. Просто совмести
эти спрайты по вертикали, увеличивая их ширину от минимума до максимума, продвигаясь от горизонта к "камере". Изгибы трассы - это всего лишь смещения этих спрайтов по горизонтали. Можно сделать разметку дороги, разные виды дорожного покрытия и т.д., комбинируя различные виды спрайтов дороги.
5) наконец, машины. Тоже спрайты, отмасштабированные в зависимости от удаления. Чтобы выглядело чуть более реалистично, нужно сделать для каждой "машины" по несколько спрайтов на каждый угол поворота - тогда машина спереди слева будет отличаться от такой же машины, едущей спереди справа.

В общем, всё можно сделать в 2D, было бы желание и фантазия. Туториалы по DirectDraw есть на тех же firststeps.ru и sources.ru.

Спасибо большое за столь раскрытое описание. Самая сложность возникает только в одном месте:
реализация проекта выполняется на мобильном телефоне. Отрисовывать самую сложную часть - дорогу - необходимо средствами самого телефона, т.е. через канву(я сейчас говорю о программировании на j2me). Т.е. отрисовка будет осуществляться примитивными вещами - линиями. Видл игры где это делалось прямоугольниками, но качество не то уже получается. разглядывая игры я тоже пришел где-то к такому же раскладу, спасибо за то что написал его, теперь я более уверен в том, как реализовывать это. И еще один маленький вопросик:
Как можно иммитировать стену? Т.е. приведу пример: слева от машины находится река и вдоль набережной идет небольшое ограждение, что-то типа ограждения вдоль наших набережных у р. Москва. Есть мысли, что так же путем линий, но вот как именно? одними линиями там сложно будет делать узоры(железные прутья), а
спрайтами... сложно представить.

Цитата(Nemesis @ 22.7.2005, 22:35)

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

Если линиями - то действительно, вертикальные узоры будет невозможно нарисовать. А вот если спрайтами - то просто. Берём рисунок части огражения с видом "в лицо", скажем, 32x32. Разрезаем его на вертикальные полоски - получаем 32 спрайта шириной в 1 пиксел (или 16 шириной в 2). Теперь всё - дело техники: размещаем эти 32 спрайта по границе(-ам) нашей изогнутой дороги, и получаем непрерывную по длине ограду, "ажурную" сбоку.

Если нужно сделать "ограду" более объёмной - типа, шире чем 1 пиксел, тогда каждый спрайт нужно сделать шириной в 2-4 пиксела, и все вертикальные полоски спрайта залить одним цветом, кроме самой правой полоски (там у нас "ажурная" полоска от рисунка ограды).

Слушай, действительно, офигенно! огромное спасибо!!! К сожалению, постов не хватает, но обязатльно реп дам. Еще раз спасибо!:)
--------
Все гениальное - просто !

Ну и как всегда влезу со своим советом, который даю не в первый раз

Есть возможность (теоретически, а как там процессор твоей трубки с этим справится я не знаю) сделать точки в трехмерном пространстве и работать с ними (поворачивать, приближать, удалять...) игнорируя только при отображении Z координату. Тоже самое с линиями...

Тут пример того, чего я таким образом добился:
http://forum.vingrad.ru/index.php?showtopic=22163

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

Цитата(Nemesis @ 22.7.2005, 23:44)

А писать таблицы синусов и косинусов уже пробовали))) забавное дело)

Потому, что очень долго считает?

По идее, кол-во элементов в такой таблице будет невелико, т.к. разрешение экрана не позволит выводить объекты, повёрнутые с шагом менее чем 1..5 градусов. Расчитать таблицу можно заранее и зашить в программу. Если процессор не позволяет работать с float-числами, то можно хранить в таблице значения косинуса или синуса, умноженные к примеру, на 1000.

Цитата

Расчитать таблицу можно заранее и зашить в программу. Если процессор не позволяет работать с float-числами, то можно хранить в таблице значения косинуса или синуса, умноженные к примеру, на 1000.

Так и поступали. Дело в том, что появляется очень большая погрешность в силу низкого разрешения экрана, поэтому простые повороты осуществлялись немного некорректно. А про повороты спрайтов вообще молчу, поскольку это необходимо делать уже по-другому. Исходное изображение можно вращать лишь на 90, 180, 270 градусов, а также зеркально отображать. Но к примеру, если его нужно поворачивать на 30 градусов необходми писать свой класс, который считывает байты из изображения, сохраняет в массив, а затем для каждого пикселя высчитывает его новые координаты, после применения операции умножения матрицы на вектор, что скажу я вам, для телефона очень нагрузно. Т.е. приходится делать очень большое кол-во операций с умножением(для трансформации кадого пикселя исходного изображения). Я некорректно сказал, не трансформация пикселя, а, конечно, изменение цвета каждого пикселя.

Вместо поворота можно использовать нелинейное масштабирование спрайта. То есть, по оси X и по оси Y спрайт масштабируется с разными коэффициентами. Тогда не нужно расчитывать координаты каждой точки, а погрешности поворота вообще не существует.

Не совсем понял то, что вы хотите сказать.. Но ведь тогда мы получим непропорциональную картинку... ???
Скажем, как верхнюю центральную точку на спрайте повернуть на 60 градусов против часовой или по (без разницы)?
------------
Касательно масштабирования скажу следующее: масштабирование изображений в j2me не предусмотрено (midp 2.0), поэтому делается это ручными методами, но в реал-тайме это занимает порядка 2х секунд (масштабирование изображения 176 х 220 в 1,5 раза), если спрайты малы(порядка 20 х 20), то их обычно много в игре и время масштабирование будет где-то 1с, но это с учетом того, что кроме масштабирования мы ничего не делаем, а приплюсуйте еще остальные вычисления..., поэтому масштабирование здесь не будет пригодным. . Увы, телефоны пока слабы...

Так для чего вообще поворачивать спрайт в рантайме, немного не понял. Можно на компе расчитать несколько поворотов изображения (хоть 3D модель поворачивать в 3DMax) и сохранить в разные битмапы.

З.Ы. насчёт масштабирования - это конечно не самый лучший вариант, правильнее было бы назвать это не "поворот", а "наклон", в PainBrush есть такая операция, но наверное можно найти ситуации, когда он имеет право на жизнь...

случайно набрел на сайт...
вот вариант с 3d. требуется midp2:
http://www.soneric.ru/forums/viewtopic.php?t=7494