• Мобильный 2D игровой движок для TBS?

    bfDeveloper
    @bfDeveloper
    Два месяца назад исследовал этот вопрос. Задача стояла так: найти кроссплатформенный игровой движок, желательно, но не принципиально С++, для написания любых игр под Android, IOS, и по возможности остальные системы типа blackberry.
    Сначала хотелосб Unity3D. Для 2d текущая версия unity мне показалась совершенно неприспособленной. Вроде обещали в ближайшей версии допилить. Но стоит учитывать, что некоторые необходимые для мобильника фичи типа texture batching весьма странно реализованы и только в pro версии. Смотрел CoronaSDK, показалась неплохой штукой, но писать всё на Lua лично мне не хочется. Это индивидуальные тараканы, вам может подойдёт. Ещё неплох Cocos2d-x. Это C++ порт Cocos2d, который тоже неплох, много чего умеет. Сейчас мне кажется лучшим вариантом среди готовых фреймвёрков. Все эти движки пугали как чёрный ящик, ограничивающий возможности списком своих фич. Особенно это касается unity3D, залезть в Cocos2d не проблема.
    Остановился в конце концов на неиспользовании готового. Взял C++, SDL2, пошаманил с Open GL и получил самописное чудо. Основное достоинство — полное понимание внутренностей, нет вопросов, как что-то сделать, никаких проблем с производительностью. Очень круто то, что этот же код работает на десктопе и можно тестить любые разрешения, просто меняя размер окна. Ну и запускается без деплоя на устройство, что ускоряет разработку. За чуть более чем месяц появился сам движок и почти есть игра на нём. Недостатки подхода очевидны — за каждой фичей типа сети, json, xml, шрифтов, форматов картинок и физики надо искать и осваивать отдельную либу. Так же надёжность не проверена. Ну и свой велосипед никак не упрощает вхождение новых людей в команду. На данный момент игра не завершена, но пока не жалею, что выбран такой путь. Подумайте, возможно тоже захотите своё велосипед.
    Ответ написан
    3 комментария
  • Матричный полиморфизм?

    bfDeveloper
    @bfDeveloper
    У вас описано одно из лучших решений: M классов по N методов. Дублирования легко избежать, реализовав всё по 1 разу, а в остальных методах просто вызывать уже реализованные. Ваша задача для ООП стиля гуглится по фразе «множественный полиморфизм». Кажется, у Меерса предлагалось решение в виде map<key, function>, в которую просто записываются указатели на функции так, как вам уже предлагали выше.
    Ответ написан
    Комментировать
  • Алгоритм/принцип построения графика неявной зависимости f(x,y) = 0?

    bfDeveloper
    @bfDeveloper
    Есть ещё одно интересное соображение по трёхмерному решению, навеянное методом Хука-Дживса.
    Пусть мы нашли одну точку нашего графика (например, рассмотрев сечение x = const и применив в нём метод Пиявского). Назовём эту точку опорной. Если предположить, что мы ищем одну непрерывную кривую, то можно утверждать, что рядом с найденной точкой есть другие, принадлежащие этой кривой. Возьмём некоторый шаг h и посчитаем значение функции F(x, y) в нескольких точках на расстоянии h от первой. Выберем точку со значением максимально близким к 0 за следующую опорную и повторим действия. Таким образом мы как бы пройдёмся по дну оврага (если брать модуль F) или просто по склону, сохраняя высоту.
    Если хорошо подумать над тем как искать следующую точку, то можно сообразить как от начальной точки пройти сразу по двум направлениям (она же не обязательно будет на границе, и описанный выше метод найдёт кривую только по одну сторону от точки).
    Получив массив точек, мы можем применить метод градиентного спуска для каждой из них для получения более точного результата. Так как точки уже близки к кривой, практически исключается возможность скатывания в локальные минимумы.
    Вообще в методах глобальной оптимизации принято сначала локализовывать точки минимума, а потом запускать методы локальной оптимизации в найденных областях. Здесь это тоже неплохо работает.
    Ответ написан
    Комментировать
  • Framework Qt 4.7. Проблема при формировании указателей виртуальной таблицы?

    bfDeveloper
    @bfDeveloper
    В коде есть нарушение двух правил наследования от QObject:
    1) Макрос Q_OBJECT надо писать всегда. Допускается использование без него, но это только если вы в этом уверенны на 100% и понимаете, как это работает. В официальной доке по Qt настоятельно рекомендуется писать этот макрос всегда, когда наследуете QObject.
    2) Конструктор наследника QObject должен иметь вид:
    explicit MyObject(..., QObject* parent=0);
    Это требуется для реализации объектных иерархий.

    Кроме того, в конструкторах ваших классов нет вызова конструктора предка, т.е QObject(parent).

    Не уверен, что что-то из этого приводит к вашей ошибке, однако так, как написано у вас, писать точно не стоит.

    Кстати, бывает, что возникают проблемы, когда класс, который не был наследником QObject в процессе разработки им становится. QtCreator не всегда соображает правильно и не запускает qmake после этих исправлений. Попробуйте запустить qmake руками и потом пересобрать проект.
    Ответ написан
    4 комментария
  • Как настроить слайдер в объекте QTextEdit из Framework'a Qt 4.7?

    bfDeveloper
    @bfDeveloper
    Дело в том, что у QTextEdit автоматическое управление скролом для того, чтобы курсор всегда было видно (возможно ещё для чего-то). Вам помогут методы управления курсором, например:
    
    edit->moveCursor (QTextCursor::Start); //или QTextCursor::End
    edit->ensureCursorVisible() ;
    

    Если курсоры нужны для других целей, то придётся подумать. Хотя вопрос неплохо гуглится по английским форумам, поэтому можно выкрутиться.
    Ответ написан
    1 комментарий
  • Qt AutoFillBackGround и полупрозрачное окно?

    bfDeveloper
    @bfDeveloper Автор вопроса
    Решил проблему, сделав отдельное окно для плеера (виджет верхнего уровня). Пришлось отслеживать движение основного окна и двигать за ним плеер, но зато всё отлично работает.
    Ответ написан
    Комментировать