Каскадный · [ Стандартный ] · Линейный НА каком языке ппрограммируют все игры, НА каком языке программируют игры на ГБ?

[Eduard-x]

Если программу написать быстро - скрипты, С или С++. Если программу динамичную, то тут надо уже думать об оптимизации, причем речь может не идти о ассемблере сразу. Асм - это когда до последнего все выжато, что часто маловероятно, или переписываем подпрограмму за неимением времени на асм - и основная проблема скорости решена. Причем у каждого проца есть свои приколы, но самый простой трюк (который будет работать на любом из них) для оптимизации - сделайте размеры матриц (спрайтов например) кратными 2. На Сях - ширина матрицы, и программист будет приятно удивлен. Многие об этом не знают, а ведь это один из "дешевых" трюков оптимизации по скорости.

[Leadder]

У меня проблем нет... Пиши в вижуал хаме на с++ без гемороя Если не считать это дурацкое интро

[Don]

мда 8))))))))))))))))

чего только не узнаешь на этом форуме.... 8)
хохохох

[odolya]

кому нужен полиморфизм и виртуальные классы и проч для игр ГБАшных?

Неудобно мне вмешиваться в дискуссию гуру разработки игр под ГБА , сам я писал что-либо только под РС, но фраза

кому нужен полиморфизм и виртуальные классы и проч для игр ГБАшных?

мне кажется странной
Все это или нужно, или не нужно независимо от платформы, а зависимо только от задачи. Если где-то память настолько перерасходуется, что из-за возникают траблы, то это значит, что проблема или в программисте, или в компиляторе, но никак не в концепции ООП (извините за пафос ). А уж про быстродействие - это вообще гон

[arabesc]

Никто тут концепцию ООП вроде не ругает. Вопрос в другом.
GBA это далеко не PC. На нём нет операционной системы, для него нет полной реализации run-time библиотек, так привычных для нормальных компьютеров. На GBA действительно мало памяти, (иногда приходилось считать что где лежит с точностью до байта), и, представьте себе, эта память у него разная. Разная по объёму, по скорости работы, по назначению.
Нужен полиморфизм и виртуальные классы? Но для этого тогда нужны операторы работы с динамической памятью new/delete, а их поддержки в run-time нет! Нужно писать своё. С++ хорош большим объёмом generic библиотек, таких как stl или boost, но мне страшно представить их использование на GBA.
По поводу быстродействия. Экспериментально было установлено, что вызов функции на GBA очень дорог. С случае, когда в цикле нужно обработать большой список объектов (вызвать для каждого функцию), учитывая какой-либо признак, гораздо быстрее будет разместить проверку признака внутри тела цикла, а не внутри функции обработки, избежав таким образом лишних вызовов. В С++ же чёткая идеология - данные и методы для работы с ними, т.е. огромное число вызовов функций для работы с одинаковыми данными.
Использовать C или C++ конечно личное дело каждого. Вполне возможно, что некоторые задачи на C++ можно решить проще и быстрее. Но моё личное мнение - C++ для GBA это слишком мощный и сложно контролируемый инструмент, который, к тому же, не получиться использовать в полную силу. А вот С - совсем другое дело... :)

[KoCMoHaBT]

Нужен полиморфизм и виртуальные классы? Но для этого тогда нужны операторы работы с динамической памятью new/delete

Хуже того. Создание каждого объекта сопровождается серией неконтролируемых действий в ОЗУ (например, заполнение vtable).
Соответственно -- нельзя заранее создать кучу статических объектов. Соответственно -- огромная ПЗУха не используется, а работа переносится в ОЗУ. Ну и так далее.

[Don]

в общем, крест на этой части ООП ставим.
и все - кол в сердце осиновый

[pan]

гон все это по поводу тормознутости ООП и т.п. Если хорошо все реализовать, никаких особых проблем не возникает, в том числе и в динамичных играх. Говорю не просто так, а на основе реального опыта программирования коммерческих игр для GBA (разных жанров).
new/delete делаются не так сложно - к тому же есть куча исходников менеджеров памяти, которые можно заюзать. Работает достаточно быстро, а без собственного менеджера памяти тяжко по любому - что обычный C что C++
То что всякие vtable и т.п. выделяются - так блин, это всего несколько байт.. Никогда не сталкивался с проблемами из-за этого.
Куча статических объектов не есть хорошо, ТЕМ БОЛЕЕ с ограниченной памятью AGB.. конечно, приходится выбирать компромис между памятью и быстродействием - у меня он чаще всего решается в пользу динамических объектов, а замедление почти не заметно.
Статические объекты в ПЗУ... хм.. ну всегда можно хранить в ПЗУ константный массивчик их параметров коли нужно.. Вообще эта проблема решаема вполне. Хотя я вообще не очень понимаю - если это объекты, то они и должны быть в ОЗУ а не ПЗУ.
библиотеки stl и т.п. - тут действительно верно, в GBA особо такое кол-во кода не запихнешь.. С другой стороны не особенно то оно и нужно обычно. Используется реально всего несколько вещей из огромной библиотеки - ну для таких пишется просто собственная мини-библиотека.
Вызов функций в GBA... Для того и существует компилятор - это его задача оптимизировать в inline вызовы мелких процедур и функций. Таким образом ООП ничуть не медленее не-ООП в этом плане. В коде оно хоть и функции, а при компиляции совсем даже нет.
Совсем в полную силу С++ на GBA конечно вряд ли удастся использовать, но достаточно большую часть его - очень даже реально, причем независимо от игры...

[KoCMoHaBT]

Вообще эта проблема решаема вполне. Хотя я вообще не очень понимаю - если это объекты, то они и должны быть в ОЗУ а не ПЗУ.

Зачем? Хранить там только меняющиеся параметры. Даже выгоднее предварительно создать два экземпляра с пересчитанными параметрами и переставлять указатели чем писать какие-нибудь setStatusDoorOpen() setStatusDoorClosed() getDoorStatus() с установкой какого-нибудь bool в true/false.

[SIBIQ]

[KoCMoHaBT]

Куча статических объектов не есть хорошо, ТЕМ БОЛЕЕ с ограниченной памятью AGB.. конечно, приходится выбирать компромис между памятью и быстродействием - у меня он чаще всего решается в пользу динамических объектов, а замедление почти не заметно

Компромисс, кстати, не между памятью и быстродействием, а между ОЗУ, ПЗУ и быстродействием.