Войти
ПрограммированиеФорум2D графика и изометрия

Создание объектов во время работы программы в GlScene (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
20:59, 27 янв. 2011

у меня во время движения мыши вправо\влево камера двиджется вверх\вниз. что надо написать в glCamera.Direction.SetVector?


#31
2:14, 28 янв. 2011

Вектор должен быть {0,0,-1}

Кстати, а что ты так ваяешь? Шутер, понятно. Це проект, или просто балуешься?

#32
16:52, 28 янв. 2011

не помогает( уже все значения перебирал. рпг будет. на область поедет, как бы смешно это не звучало

#33
16:52, 28 янв. 2011

не помогает( уже все значения перебирал. рпг будет. на область поедет, как бы смешно это не звучало

#34
16:55, 28 янв. 2011

А, все запилил

#35
18:02, 28 янв. 2011

Хорошо. Но в при таком коде, не очень то рассчитывай на результаты. Если ты будешь писать так и дальше, то в итоге, быстро запутаешься, и не успеешь к сроку.

Далее, на слабых машинах твоя работа не пройдет. Например, в одном месте ты 125 раз загружаешь в память одну и ту же модель(!!!), я не помню уже, но так ты делаешь с несколькими моделями, когда можно загрузить модель, а юнитов унаследовать от проксиков. В итоге на машинах с малой памятью будут сначала тормоза, а потом и падение. Еще ты создаешь массив обьектов( причем нехилы по весу ), когда можно было обойтись и классами.

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

Ты используешь шейдер океана, и если комп не поддерживает достаточно высокие АРБ-шки ты выбрасываешься и программы. Тем самым ты минусуешься на конкурсе по полной, потому что никто не будет искать именно для твоей программы хороший комп, тебе просто скажут: "Ваша игра не запустилась, попробуйте в следующем году". Сколько у тебя времени? Уверен что немного. Тогда зачем заморачиваться из-за шейдеров? Тем более в RPG, они и не нужны по сути. А с шедерами мороки будет много. Плюс шейдеры требуют определенных навыков аналитической геометрии.

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

Смотри исходники сцены и копируй стиль написания. Это не плагиат, или что-то в этом роде. Любой графический движок - это сокращение бесконечных возможностей графических интерфейсов к некоторому набору пародигм работы с ними. Так GLScene, это "объектная надстройка над OpenGL". Это значит что парадигма этого движка -ООП. Это просто набор объектов которые оперируют графическим интерфейсом OpenGL, объектная оболочка если угодно. Выбирая этот движок, ты выбираешь парадигму этого движка. И чтобы в итоге не возникало конфликтов между движком и программой, ты должен следовать парадигме движка. Вот как наследуются там классы, ты должен это копировать. Как пишутся алгоритмы, ты должен это копировать. Т.е. твоя программа, твои алгоритмы, должны основываться на движке, продолжать его, завершать его в программу.

Ну и конечно не бойся глубоко копать. Понимаю, тебе может быть и лень. Но тем не менее это интересно, ну во всяком случае я нахожу это интересным. Видишь разные алгоритмы. Разные авторы писали. Разные подходы. Разные стили. Узнаешь устройство. Просто интересуйся компонентами.

Ну, вроде бы и все. Удачи!

#36
12:34, 29 янв. 2011

>Далее, на слабых машинах твоя работа не пройдет. Например, в одном месте ты 125 раз загружаешь в память одну и ту же модель(!!!), я не помню уже, но так ты делаешь с несколькими моделями, когда можно загрузить модель, а юнитов унаследовать от проксиков. В итоге на машинах с малой памятью будут сначала тормоза, а потом и падение. Еще ты создаешь массив обьектов( причем нехилы по весу ), когда можно было обойтись и классами.

в этом и заключался главный вопрос данного топика :D

шейдер я взял из примера и вставил его, т.к. заморачиваться с ландшафтом нет времени (5 февраля показывать :DDDD)

ну насчет красот  я и не заморачиваюсь.

а если не пойдет то на ноуте покажу, ибо на нем  и пишу. есть даже опасения что попадется комп с интегрированой видеокартой, ибо это школьная конференция >_<

сечас у меня дви проблемы:

1) из-за этого чертового шейдера пришлось повернуть сцену на угол в 90 градусов, чтобы он не выглядел как водопад (шейдер эмитирует морские волны), в результате чего камера двигается вверх-вниз, вправо-влево но только по одной оси Y (или X), короче я только через центр карты могу смотреть

2) она же стала и причиной основания данного топика: наследование, которое я так и не допер как делать.

p.s: щас нашел демку с наследованием. буду пытаться. а вот с камерой незнаю что делать

pps: наследование сделал *yahoo*

#37
14:15, 29 янв. 2011

РПГ, за неделю? Ты что робот что-ли? РПГ за неделю не делается, и за месяц не делается. Ну не льсти себе, честно оценивай свои возможности. Ты не знаешь как следует движка, плохо знаешь ООП, не знаешь основных алгоритмов. И хочешь сделать РПГ за неделю? За неделю тетрис толко и можно сделать, с твоими возможностями, и то если поднапряжешься. Предлагаю тебе просто забить на этот конкурс. За такие сроки из этого ты ничего не сделаешь.

#38
16:11, 29 янв. 2011

не-а. к новому году у меня было уже готове рпг, работающее на чистом OpenGL только с процессором. Последний факт и стал причиной перехода на GlScene. Я всеголишь хочу сменить технологию. Все остальное у меня готово

#39
16:24, 29 янв. 2011

Неее. На чистом ОЖЛ? И сколько же ты его делал? :))) Ну в любом случае не зная движка, не успеешь за неделю. Кстати, на разных конкурсах отсутствие стороних компонентов засчитывается как большой плюс. Если готово, то не парься и сдавай как есть. Если выгорит, тогда и будешь переносить, иначе весь перенос теряет всякий смысл.

#40
16:40, 29 янв. 2011

с сентября где-то. там на код даже не смотрят- т.к. языки высокого уровня и ,тем более, графическая библиотека не для них, мягко говоря. Вот именно что выгорело переносить игру: она выдавала 40 фпс максимум!! За это я лишился призового места на предыдущей конференции

#41
18:20, 29 янв. 2011

Я очень долго смеялся. Спасибо. Получается, у тебя нет оптимизации, и вместо того, чтобы просто посвятить оставшееся время оптимизации, ты решаешь перенести все на движок, который на самом деле больше 300 не выдает!!! А я ведь уже говорил, что неординарные идеи,всегда в авангарде нации!!! Прости, но это действительно  очень смешно.

Будь проще! Просто посмотри где в твоей программе тормоза и оптимизируй( юзай гугл ), смотри форум ГД. Так нужно дотянуть до 120, это граница. И все. Ну во всяком случае это наилучшее что можно сделать в оставшееся время. :)))) Кэп Очевидность, какбэ упражняется, не краснея перед трудностями. :))))))

#42
18:23, 29 янв. 2011

не, там слишком все замусорено+ писать VBO нет особого желания. + дело не в фпс, а в тормозах: фпс то было 40 но тормаза были жуткие, т.к. все лежало только на цп

#43
19:00, 29 янв. 2011

Пф, ну так GLScene тоже еще на процессоре весит. Ребята там что-то мутили с GLScene 2. С контектами через Ж.ПУ, однако чего-то тишина. Возможно рабочая тишина. Не знаю.

Знаешь, в жизни есть моменты, когда нужно наплевать на собственные амбиции, на свои "хочется", и действовать максимально сосредоточенно, быстро и аккуратно. У тебя сейчас как раз такой момент. Если будешь капризничать и продолжать переносить на движок, то в итоге тебе придется сдать OpenGL-ый вариант работы, потому что процесс переноса на новый движок готовой игры, это очень долгий процесс, месяц минимум. Не зная движок как следует, месяца два, а то и три. И уж точно не неделя. И угадай какое место ты займешь? Готов спорить что не призовое.

Однако, если плюнешь на свои хочу, не хочу, и будешь, пусть даже пересиливая себя, копаться в своем коде, и оптимизировать то что есть, то очень даже возможно, что сможешь набрать достаточно фпс, чтобы победить. VBO лишь кажется легким. Когда ты подключишь его( что само по себе занимает достаточно времени ), он потребует ещё большее количество подгонок в первоначальном варианте, и так много раз. В итоге тебе придется переписывать больше половины кода, что не годится.

Ещё раз говорю, просто оптимизируй написаное. Увеличение системы всегда ведет к увеличению ошибок в ней. Подключая VBO, ты лишь получишь очередной геморой. Перенося на движок, ты лишь получишь очередно геморой.

Ладно, твоя проблема уже решена. Это твоя работа и твой выбор. Желаю удачи на конкурсе, она тебе понадобится. Пока!

#44
21:15, 29 янв. 2011

спасибо

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорум2D графика и изометрия

Тема в архиве.