![]() |
Баг или мудаг?
Вложений: 1
Помогите, ребят, разобраться в топе вопроса)
Смысл такой, есть 3 фунции - HeroAction()-проверяет, 2 фунции вызываются из под неё. Код:
Global heroLeftHandFree%,heroRightHandFree% И проблема больше из-за того что я конкретно ошибку не вижу. Выдает такую фигню. Помогите плиз, может debugger какойто нормальный есть? |
Ответ: Баг или мудак?
О, та ошибка походу вылетала из-за функции ResourceCreate(..) там создается боди для физикса.
Но осталась ошибка MAV на : Код:
Function DropItem(mb) |
Ответ: Баг или мудак?
Вложений: 1
Ураааааа!!! Я не мудак!!! ))
Сам нашел баг в ксорсе, с синусами косинусами Код:
Include "Xors3d.bb" |
Ответ: Баг или мудаг?
Т.к. ты не описал "баг ксорса", после быстрого просмотра последнего исходника, вижу что вся "байда" у тебя с мат. вычислениями, следственно это не баг ксорса, а не знание математики или видов углов в которых идёт представление наклона объектов.
Да и я более чем уверен, люди которые как-то и могут тебе помочь, вряд ли будут запускать твой код.. |
Ответ: Баг или мудаг?
Вложений: 1
Не принимай за грубость, но ты умничаешь не разобравшись и твое сообщение бесполезно - услышал звон и не знаешь где он. И причем тут знания математики и видов углов (хотя у меня нет с этим проблем). Работа косинуса и синуса при любых значениях не должна быть Nan (т.е. Null)
Код:
Graphics3D 640,480,32,2 Я просто написав 2к строк наткнулся на этот баг, потратил часов 5. И кому-нибудь это может помочь поэтому создал тему. А не для того чтоб мне говорили что я не знаю как синусами пользоваться. |
Ответ: Баг или мудаг?
При валидных данных Cos и Sin всегда возвращает число.
Если данные не валидные (например это не число), то следственно и результат будет не валидный. Также числа очень близкие к 0 могут иногда выдавать ошибочные данные (проблема с точностью флоатов). Учитывая что Ксорс затачивали дружелюбно к Блицу, то данные из функций ксорса должны быть аналогичны блицу, лишь с отличием что как уже упомянул, данное из функции ксорса может быть не числом. Даже если и Cos возвращает что-то, и это не число - то это не баг Ксорса, это относиться к твоему незнанию что Cos может возвращаеть не числа а NaN. Груби, это лишь выказывает твою эмоциональность по поводу собственной тупости из-за которой ты убил пять часов заместо простого теста валидности данных в функциях Cos / Sin. |
Ответ: Баг или мудаг?
Не, вот ты нормальный вообще человек, код хоть посматри!
Объясняю специально для тебя Cos(xEntityYaw(camera)) - получается число (разжёвываю, косинус угла поворота камеры возвращает нормальное число) а xEntityZ(camera)+Cos(xEntityYaw(camera)) - получается NaN (разжёваваю, а когда к такому же косинусу прибавляешь позицию объекта получаем Null!) Но с Багом можно справиться так: a#=xEntityYaw(camera,1) xEntityZ(camera)+Cos(a) ПС. Вот кто из нас показывает тупость?! Тебе просто лень нормально посматреть, лиш бы побурдеть. |
Ответ: Баг или мудаг?
Это не ксорс.
Фикс твоего бага: Код:
Cos(xEntityYaw(camera)) + xEntityZ(camera) |
Ответ: Баг или мудаг?
Проблема и в хорсе и в блице. Синусы и косинусы тут вообще не причем.
В хорсе какая-то проблема в вычислении, т.к. функции EntityX, EntityPitch и подобные возвращают не 0. По стандарту IEEE-754, нуль в int представлении равен нулю во float представлении, а эти функции возвращают в int представлении одна 800, другая 1245080 и т.д. ( притом что ентити в нулевой позиции, и должно соответственно возвращать 0 ) В блице же такие числа в float представлении вызывают NaN, причем, как выше показано, не всегда. Видимо компилятор что-то мутит. |
Ответ: Баг или мудаг?
Цитата:
*да - трололо. Но с каким упорством и гонором набросился на участника дискуссии! Кстати тоже наблюдал неадекватное поведение (про одно уже писал, второе - некогда вычленить в минимальный код, но сильно смахивает на описываемое Hartmann1). Вот вам хороший пример (лишённые оков ревнители научных истин) как вы поклоняетесь авторитету, отвергая истину (Фрэнсис Бэкон негодует!) |
Ответ: Баг или мудаг?
Всё дело в точности float и преобразовании типов. Например добавление сверх малого float числа к сверх большому float числу может вызвать неадекватную реакцию в некоторых реализациях. Происходит это по тому что плавающая точка, меняет своё положение делая число или точнее (при малых величинах) или менее точным вплоть до целого при хранении большого близкого к придельному числа.
Естественно для числа 7654321,0 прибавление числа 0,1234567 или не даст ожидаемого эффекта, мы получим что то типа 7654321,1 или выдаст Inf/NaN. Хотя последнее возможно скорее при умножении/делении. ИМХО |
Ответ: Баг или мудаг?
Ну не скажите, у блица с математикой так себе. Он даже тангенс 90 считает. При том не NaN\Infinity, а вполне себе годное число.
|
Ответ: Баг или мудаг?
Цитата:
|
Ответ: Баг или мудаг?
Если не находит, значит всё верно. Или есть корень из отрицательного числа?
|
Ответ: Баг или мудаг?
Цитата:
а нечетный и так норм извлекается) |
Ответ: Баг или мудаг?
пардон. прочитал как "Он даже тангенс 90 НЕ считает"
|
Ответ: Баг или мудаг?
"Баг или мудаг?" =)
такая вот штука обнаружилась: когда после команды "FIX->StartDraw()" использую "xLinePick" то FastImage тупо перестает рисовать все что находится после вышеупомянутого "xLinePick" и еще: "xLinePick" возвращает совсем неверные результаты, это 100%, ибо пикабельных энтити в сцене !только! !2!(200%!), а в результатах указываются вообще хз что (хэндл неведомого энтити, уж точно не одного из этих двух пикабельных) единственное, что эта функция правильно определяет так это в результате "0" если ниодного энтити по дороге нету О_О |
Часовой пояс GMT +4, время: 03:38. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot