Ответ: The Maze
 

:-) Спасибо за исходники

Ответ: The Maze
 

>>
Добавил алгоритм спрайтов, нужно оптимизировать и добавить логику, тогда будет хорошая игрушка. Подобных программ на MP не видел.. Кто возьмется делать логику? у кого есть интересные идеи?
>>
надобы сделать редактор 3д мира - можно на дельфях (в фольфштейне был мир 64*64 клеточки)
- клеточкам присваивать текстуры
- расстановку в клетках спрайтов... факелы - освещаемые пятна(анимац)
- расстановка "монстров"
- расстановка "обьектов" - аптечки - патроны - ключи...
и типа "компиляцию" ресурсов в какойнить DAT файл
АИ врагов - простую (по колву ед жизни -100% ищет игрока - 50% убегает) типа стрелялки

---
про первые 3д игры хорошо описано у Андрэ Ламот Программирование Игр - алгоритмы рендеров...

Ответ: The Maze
 

про это уже писал, некоторое из этого не получится, потому что ограничение на кол-во текстур (добавил еще 2 и перестало запускаться на V3i), карту лучше сделать в текстовом файле, редактор пока не обязателен. размер карты в wolf3d 64x64 обусловлен размером целой части в числах с фиксированной точкой.
Также врятли найдется рендер 2.5D быстрее чем представленный здесь, вся задержка только в методе вывода на экран

Ответ: The Maze
 

случайно заглянул на http://wap.mtsgames.ru/free/?p=1 и нашел кучу 2.5D игр...
вот некоторые ссылки
http://get.mtscity.ru/free/id.9416/j...e.210/game.jar
http://get.mtscity.ru/free/id.16003/...e.210/game.jar
http://get.mtscity.ru/free/id.18974/...e.210/game.jar
http://get.mtscity.ru/free/id.21239/...e.210/game.jar
http://get.mtscity.ru/free/id.21990/...e.210/game.jar
http://get.mtscity.ru/free/id.22479/...e.210/game.jar
http://get.mtscity.ru/free/id.22477/...e.210/game.jar
http://get.mtscity.ru/free/id.25361/...e.210/game.jar
графика сделана довольно профессионально, работать будет на большинстве моделей телефонов, клавиши тоже на своих местах, вот только через какое-то время выскакивает окошко с требованием регистрации, которое выкидывает из игры...

некоторые игры виснут на motorola v3i, те что работают тормозят, но чуть быстрее чем MIDletPascal-версия движка.
____
p.s. а все-же где весь народ? все что-то потерялись... хочется увидеть исходники/логику от другого программиста,... а в свои игрушки играть-то неинтересно

Ответ: The Maze
 

Почитал я эту тему от и до и... Захотелось сделать что-нибудь похожее на Wolfenstein3D. Странно, не правда ли? :)

Вот я вот все мучаюсь, каким же образом сделана эта игра:
http://get.mtscity.ru/free/id.22477/...e.210/game.jar
(Bunker3D)

Все так плавно, гладко... При этом вся проекция 3d мира растянута на весь экран, используются анимированные стены, полустены, анимированные спрайты... Блин, как же у них это так получилось?

В Мидлет Паскале нет аналогов drawRGB случаем? :)
* через некоторое время *
Хм, а если попробовать сделать библиотеку для MP, в которой будет находится метод, тело которого будет вызывать drawRGB?

Так, пойду попробую...

Ответ: The Maze
 

Фух! Только что написал библиотеку, которая работает с ARGB массивом, после чего дает перевести результат в простой Image.
Попробовал слегка переделать наш проект, подключив эту библиотеку...
Ура! Апплет стал работать быстрее раз в 10-20! Скорость стала более-менее порядочной! Больше не тормозит так, как раньше.
Появился шанс на светлое будущее... :)

Так, ребят, а кто-нибудь знает, как реализовать двери? Я вот все понять не могу... Кто сможет написать?

P.S. Данная версия подстроена под экран 176х220.
Если у вас не такой экран, тогда идите в мою библиотеку и изменяйте там параметры width и height (или просто в главной проге переменные w и h замените на 176 и 128 соответственно).

Ответ: The Maze
 

есть игра catacombs 3D написана перед wolfenshtein 3D, по задумкам интересней... можно подглядеть идеи.
___
анимированные стены это просто смена текстуры, проще всего и оптимальнее делать так:
а) на карте имеется 2 элемента со схожими изображениями проходить всю карту и менять друг на друга.
б) или же рисовать текстуру непосредственно в битовый массив.
___
дверь такой-же элемент стены, только он имеет 2а состояния и анимированный переход между ними

Ответ: The Maze
 

2cahekp - ммм.. запустил прогу на моторолке - картинка появилась - а при нажатии на любую клавишу - вылетает.. :-(

Ответ: The Maze
 

to Serg153:
Что за телефон? Размер экрана 176х220? Хм... Может, не хватает памяти?
А если попробовать закомментировать строку
" world:=argb_to_image(w,h); drawImage(world,0,0); "
в блоке MAIN LOOP и снова запустить?
Если все-равно не пойдет, то, значит, дело все-таки в памяти.
Если пойдет - дело в выводе изображения (хотя я сомневаюсь, что это так).

Сколько у тебя доступно динамической памяти (Heap) для приложений?

Попробуй выбросить из проекта какие-нибудь ресурсы на 150 кбайт.. Глядишь, пойдет! :)

to abcdef:
По поводу анимации: Ну, думаю, более оптимальный будет, конечно же, первый вариант. Либо мы один массив 64х64 перерисуем, либо кучу текстур точно с таким же размером 64х64...
По поводу двери: Ну, насчет того, что дверь - это такая стена, как и другие... Да еще и просто анимированная... Хм, ну не знаю...

А теперь пошли мои размышления... :)
Как я поглядел, есть две различные реализации дверей - это объемная (как, например, в Бункер3Д) и в виде спрайта, который имеет свою собственную ось вращения (Вольфенштейн3Д).
Я вот, например, совсем не представляю, как можно сделать объемную дверь и считаю, что это еще тот геморрой. Почему? Ну, во первых, надо создать объект, который имеет размер меньше обычных стен (дверь же будет выглядеть не в виде куба, правильно? :)). Это первая заноза: сделать на 2-мерной карте объекты, размеры которых будут меньше стандартных. Дальше - больше. Вот во время открытия двери что делать лучу? Вот он вылетает из нашего глаза и идет по клеткам с числом 0, пока не дойдет до какого-либо препятствия. Дошел он до клетки, скажем, 5. Это клетка, которая означает, что это - дверь. Да дверь то и не простая, а еще и в процессе анимации! И открыта наша дверь наполовину. Нет, пусть лучше будет чуть больше, чем в половину... ;) И что делать лучу? По логике, он каким-то макаром должен понять, именно в ЭТОЙ точке есть кусочек двери, или же тут ничего нет и нужно просто продолжать движение дальше? Для большей ясности смотрите аттач к посту. Это заноза номер два: проблема трассировкой лучей. Более того, а что делать спрайтам, которые находятся позади двери? Как им объяснить, что часть их находится позади двери и должна быть отображена, а часть - нет? Заноза три: проблемы со спрайтами. Хотя, наверно, последний пункт можно выбросить. Если мы сможем правильно заполнить массив ScreenDist, то, по ходу, проблем возникнуть не должно...

Я думаю, что гораздо легче будет создать дверь в виде спрайта. Это полезно, так как помимо дверей, можно будет точно также создать какие-нибудь решетки, стены со сквозными дырками... Да и просто спрайты, которые не будут постоянно поворачиваться в сторону игрока, а будут смотреть только строго туда, куда им указал смотреть разработчик. :)
Спрайтовую дверь будет легко всунуть в любое место, задать ей начальный поворот, двигать... С помощью спрайтов можно будет попробовать создать "битую" дверь, с небольшими сквозными отверстиями. Будет выглядеть круто. :)
Вот только как сделать так, чтобы спрайт имел свою собственную ось?!?? Вот, что меня больше всего мучает!!! :(
Как менять его вид, опираясь на угол зрения игрока? Не понимаю...
Кто сможет это объяснить (а еще лучше: реализовать)?

Ответ: The Maze
 

насчет дверей :) допустим младший байт на карте будет элемент, а остальные статус и тд. Т.о. у нас появляется место для записи положения. при столкновении луча с дверью находим место столкновения 0...63 и смотрим, если луч попадает в открытую часть - пропустить дальше. чтобы дверь рисовалась тоньше чем обычная стена лучу необходимо шагнуть немножко вглубь. да, и еще лучше разделить элемент карты на 4е элемента и для каждой стороны рисовать свою текстуру.
__
чтобы программа запускалась на motorola нужно освободить место для битового массива, удалив 8 картинок, в таком случае текстуры должны подгружаться по мере надобности

Ответ: The Maze
 

Хм, интересненько... )
Пойду эксперименты ставить.. )

Ответ: The Maze
 

Мда.. Весь день этой фигней промаялся и вот что сделал:
1. Алгоритм поиска квадратного корня для целых чисел был усовершенствован и теперь работает довольно быстро. :)
2. Карту игра считывает из файла 1.map. Файл имеет читабельный вид и представляет из себя набор символов, которых может быть меньше, чем 64*64 штук.
3. Изменил текстурки. Старые надоели. Пофиг, что новые не блещут качеством, зато они новые!.. :)
4. Еще немножко прооптимизировал игрульку.

НО! Я так до сих пор и не понял, КАК ЖЕ ВСЕ-ТАКИ ПУСТИТЬ ЛУЧ ЧУТЬ ДАЛЬШЕ, ЕСЛИ ОН СТОЛКНУЛСЯ С ДВЕРЬЮ! Точнее, понял, но как только я его начинаю пускать чуть дальше, то начинается ВСЯКАЯ НЕХОРОШАЯ КАЛЯ-БАЛЯ!!! Видимо, математик из меня никакой... :(
Блин, как же все-таки сделать?! Бесит уже! :crazy:

Ответ: The Maze
 

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

Ответ: The Maze
 

Хм... Ну что же, буду ждать твоей реализации... :)

А потом буду сравнивать со своей... Хех.

Ответ: The Maze
 

>>1. Алгоритм поиска квадратного корня для целых чисел был усовершенствован и теперь работает довольно быстро
...ммм - я так понимаю что квадратный корень нужен для определения растояния до пересечения с гориз или верт стеной -
а может отказаться от вычисления корня и использовать разницу квадратов?