Лабиринт с шариком внутри ( проблемка)

[klopmaks]

Эммм , после компиляции родными средствами блица, ну встроенным компилятором... и отправки на другой комп мне выдало Unable to set graphics mode
, а на еще другом компе тоже самое .
А типерь вниманийе фапрос!
Откуда оно береться и чем нужно компилировать чтоб от этой бяки избавиться , мне ее потом в школу нести на флешке

З.Ы. Не думайте что это готовая версия которую я отнесу в школу , я еще введу кучу всего интересного. Я просто говорю в общем смысле , что после всех доработок я отнесу игру к коммисии МАН работ

[FrankH]

Unable to set graphics mode - невозможно установить графический режим, например разрешение, разрядность или оконный режим. Никто за тебя учить язык не будет.

[ABTOMAT]

FrankH,

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

тут ты не прав. В аттаче смотри убедительное доказательство, крутится именно сам лабиринт, а не камера и вектор, даже на убогой коллизии блитца. (кстати ещё и ускорение свободного падения привинтил)

З.Ы.
блятцовые коллизии - та ещё жопа, их надо избегать всеми возможными способами...

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

klopmaks,

Эммм , после компиляции родными средствами блица, ну встроенным компилятором... и отправки на другой комп мне выдало Unable to set graphics mode
, а на еще другом компе тоже самое .
А типерь вниманийе фапрос!
Откуда оно береться и чем нужно компилировать чтоб от этой бяки избавиться , мне ее потом в школу нести на флешке

Блин, чел, у тебя проблема на ровном месте! Ладно если бы новичёк был, а ты уже сколько времени блиц юзаешь и всё...[слово было заменено на более приличное] не учишься. Конкретно по вопросу, поставленному в посте №16. Чтобы завтра хелп по этим командам:

• Graphics3D
• CountGFXModes
• GfxModeWidth
• GfxModeHeight
• GfxModeDepth

Был скурен от первого до последнего листа. Юзай мой семпл (пока я добрый )
Пользуясь терминологией тов. Михеева, ГАФ!

[FrankH]

тут ты не прав

Да, не прав, два апдейта не использовал никогда.

[ABTOMAT]

По-хорошему надо упдейтать конкретно 1 только шар. Но блин, так устроен блитз, что обновить можно либо всё, либо ничего (как вариант - группами).

[klopmaks]

2 frankH Первое место на районной олимпиаде по английскому йазыку среди 8-ЫХ класов г.Киева
G# = -9.8*0.000002 ; По закону тов. Ньютона... Давно? откуда 0.2 взялось?

Else
VY = VY + G*dt
End If
Модешь обьяснить плз этот кусок и зачем нужен dt?

2 АВТОМАТ ща попробуем фкурить =,,

[ABTOMAT]

0.2 - аналог массы
dt - синхронизация

[FrankH]

Сообщение от klopmaks

по английскому йазыку

я имел ввиду оба языка, но больше блитц, т.к.ты тут не первый день..
Старая аватарка мне больше нравилась)

[moka]

Не чётко прочёл всю тему, наверное уже говорили..
Коллизия в блице весьма странно устроена, прдположим такую ситуацию: есть объект динамичный (тот же шарик), и есть статичный уровень. Если между двумя тактами, перемещение шарика будет с одной стороны сразу на другую сторону фуйса лабиринта, то в проверке коллизии, как я понимаю будет проверка на весь путь, так сказать будет столько шагов проверки, сколько длина всего "пути / (примерно радиус сферы для фруструма)", таким образом объект не сможет проскочить, т.к. в одном из проходов наткнётся на стенку. Теория может быть ошибочна, но на практике всё упирается именно в подобное.
Далее, если уровень станет динамичным, а кручение не есть перемещение, то в один из тактов позиция одного из предпологаемых трианглов, с которым должно было произойти столкновение, проскочит тот кусочек, что даст возможность в один шаг объекту уже стать на другой стороне фейса. Но тут возникает моммент, к примеру если есть проходы, то по идее изменение окружения тоже должно быть по проходам, и теперь представим что всё будет вот так по проходам проверятся - комп умрёт. Поэтому эта теория, учитывая данный факт, весьма шатка и не убедительна.
Короче говоря, в моммент между двумя проходами проверки на коллизию, фейс крутящегося объекта проскочил. Кстати в PhysX и любом другом физическом движке будет также. Но в PhysX есть CCD (Continuous Collision Detection), эта функция включает какраз вот эту проходную проверку, при этом регулировать шаг тоже можно, но тут возникает моммент какраз который Очень сильно затормозит просчёт. Для одного шарика - думаю будет не сильно и тормозно, но не переусердствуйте с параметром проходности (если всёже юзать PhysX и эту функцию).
Варианты решения проблеммы:
- Увеличение размера коллизии шарика (не обязательно, но соответственно и визуальный шарик придётся увеличить)
- Ограничение скорости перемещения шарика. Скорость не должна превышать радиуса шарика, между двумя просчётами коллизии, с учётом встречной скорости перемещения трианглов лабиринта.
- Исползование CCD функционала в PhysX.
- Фиксировать по времени частость вызова функции просчёта физики.

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

[klopmaks]

FrankH, мне тоже иногда спать хочеться , кстати я чет давно ФМА не смотрел =)))
MoKa, спасибо =) . А физикс тяжело подключить???? =) И где его вобще взять? Можнтн подкинуть какую нибуть инструкцию.

[HolyDel]

MoKa, на самом деле шаг один. Просто проверяется коллизия не шара в текущем месте, а отрезка. из начальной точки в конечную.

klopmaks, www.rubux.net

[moka]

HolyDel, могу поспорить, т.к. ведь если на пути отрезка который будет из центра, не будет проходить трианглы, а будут только где-то объект задевать, то и позиция изменится, или проверка лучами происходит из каждой вершины, но опять же будут глюки, с острыми или маленькими объектами. Не соглашусь насчёт отрезка, и откуда такая информация?

[HolyDel]

отрезок толстый. даже не отрезок а капсула.
откуда? ну.. чисто аналитически получается так.
потомучто хоть ты объект здинеш на 1, хоть на 1000, время обработки будет одинаковым. Значит никак не циклом с мелкими шагами. По крайней мере стандартная блицовая коллизия.

[moka]

Хм, это с элипсоидом, а с кубом?
Эх..

[Billy]

Коллизию в блице не раз проклинал поначалу, тоже уже начал прикручивать ньютон, пока не понял, что туплю сам.
Коллизия бывало не обсчитывалась и ентитя порваливалась. Особенно заметно если треугольники в мешах ландшафта больших размеров и угол перехода крутой, те резковато вверх поднимается гора к примеру. Но проблема в том , что надо задавать второй радиус ентите и все начинает работать нормально. К коллизии блитца никаких претензий.
EntityRadius ball,1,2 к примеру (второй радиус подбирайте, чем больше размер треугольников тем больше радиус). Можно передвигать ентитю и на большое расстояние чем ее радиус, блитц все рассчитает нормально. Так что проблема не в блитце ...
А в данном случае FrankH правильно описал главную проблему. Да и лабиринт все таки я бы поаккуратнее сделал. Ни к чему там эти нестыковки между стенками. Пользуйся Snaps Toggle в максе и тогда не надо будет такой лабиринт из такого количества кусочков собирать. Вы поэтому, я так понял, и маштаб лабиринта уменьшили, что проваливалась сфера ? Просто у Вас 3 дыры размером около 3 юнитов, что позволяет проваливаться сфере радиусом 1.