1. C++ / Говнокод #7529

    +163

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    void Model::setPieceRotationAngleDegrees(uint pieceIndex, float angleDegrees)
    {
    	check(pieceIndex < cfg_.getPiecesQuantity());
    	pieces_[pieceIndex].angle_ += angleDegrees;
    
    	if (pieces_[pieceIndex].angle_ == 360.0f)
    	{
    		pieces_[pieceIndex].angle_ = 0.0f;
    	}
    }

    Фееричный сеттер в модели простенького Jigsaw-паззла.

    Запостил: Kirinyale, 12 Августа 2011

    Комментарии (14) RSS

    • Самое страшное, что если кусочки вращаются, например, по 90 градусов за раз и только в сторону увеличения угла, то это еще и работать будет.
      Ответить
      • Именно так оно и было. Я эту хрень вообще заметил только благодаря тому, что полез дописывать к этой игрушке неработавший скип (с автоматической расстановкой всего на свои места) и обнаружил, что очевидная вроде бы строчка даёт совсем неочевидный результат:

        setPieceRotationAngleDegrees(pieceIndex, cfg_.getPieceFinalAngleDegrees(pieceInde x));

        Ничего, в понедельник автор выходит из отпуска... :)
        Ответить
        • Монтировку вазелином намазали уже?
          Ответить
          • Для начала - отправили ссылочку на ГК в оффлайн через корпоративный мессенджер... Прелюдия - это святое!
            Ответить
    • Кстати, а почему float?
      Ответить
      • Ну а почему нет? :) Всё равно ж в радианы конвертить для поворота графики...
        Ответить
        • я про double
          Ответить
          • На эту тему уже начинали здесь:
            http://govnokod.ru/5982
            Почему-то не закончили.
            Ответить
            • Надо конечно смотреть на конкретной программно-аппаратной платформе какие будут результаты.
              Но, я вот например, прогнал банальный тест с умножением двух float, а потом двух double.
              С double получилось на ~10% быстрее. (VS 2010, Core2duo)
              Ответить
              • По-моему, у нас в казуалках не те масштабы, чтобы умножение float начало тормозить игру в целом, даже если оно и немного медленнее. Кроме того, и в DirectX, и в OpenGL, насколько знаю, матрицы, вектора и всё остальное лежит во float, т.е. придётся постоянно преобразовывать результаты вычислений. Короче, выглядит как экономия на спичках, которая не приведёт ни к чему, кроме дополнительных неудобств. Тут, кстати, надо будет ещё смотреть не только на производительность умножения float, но и на общую производительность работы DirectX, если ему запретить переключать FPU по-своему. Мало ли какими соображениями мог руководствоваться MS, делая такую хачину... Если не забуду - попробую как-нибудь провести такой эксперимент на готовой игре и сравнить фпс.

                А серьёзные тормоза гораздо легче получить каким-нибудь другим способом. Например, не отсечь от рендера парочку полноэкранных (или близких к тому) полигонов с нулевой альфой. Или пересоздавать вершинные буферы половины объектов на каждый кадр из-за какого-нибудь бага в отслеживании его изменений.
                Ответить
                • >А серьёзные тормоза гораздо легче получить каким-нибудь другим способом.
                  Например бесконечным циклом :)
                  А если по теме, то я бы не назвал 10% спичками. Сказав про DirectX и OpenGL вы в принципе подтвердили мои слова про конкретную программно-аппаратную платформу. Всё таки привидение к double при умножении float'ов в стандарте не прописано, стало быть надо разбирать каждый конкретный случай отдельно. Так что ждем результатов вашего эксперимента.
                  Ответить
                  • > А если по теме, то я бы не назвал 10% спичками.
                    Речь о том, что умножение двух float - это далеко не 100% от того, на что в такой игрушке тратятся ресурсы процессора. Да и неизвестно ещё, как то же умножение работает на GPU (новые карты, насколько помню, fixed pipeline уже подковёрно эмулируют на шейдерах). Так что простой эксперимент с умножением даёт мало гарантии, что в итоге это действительно будут 10%. Посмотрим.
                    Ответить
                  • Согласен, замена float на double никаких проблем не создаст, зато добавит скорости.
                    Ответить
    • Piece выделить в отдельный класс

      градусы хранить нада в целочисленном типе, если нужна неебическая точность, то тада в радианах в double

      если еще подумать, то мона обернуть градусы в отдельный класс, чтобы всегда обеспечить условия 0 => && <= 360 imho
      Ответить

    Добавить комментарий