нет…
мы пишем на С++. экран, тачскрин и кое-какие функции работы со временем эмулируются, все остальное есть в стандартной библиотеке С. для отладки игр хватает полностью… кроме этого получаем очень дешевый перенос на еще почти десяток мобильных и не очень платформ…
VS не только удобнее но и компилирует в несколько раз быстрее (несколько минут против 15-20)…
Поэтому я не совсем понимаю политику Microsoft, они разработали одну из лучших сред для разработки но при этом не собираются пользоваться ей сами…
поиграйте в последние демки от Valve на 4 iPhone и подумайте, как скоро там понадобится реалистичная физика… а теперь представьте что с Bullet (опен сорсный физический движок), можно было практически нормально жить еще на iPhone 2G…
сейчас разрыв в производительности С++ и C# заполнит более мощная аппаратная часть (по крайней мере анонсированные девайзы могли этим похвастаться), но почему бы не открыть доступ к этим мощностям разработчикам игр, которые могли бы прийти на эту платформу с более интересными идеями, чем возможны у конкурентов…
я приложения под iPhone пишу в VSExpress (благо С++ он и в африке С++), большая часть команды за год разработки xCode запускало меньше десятка раз… кое кто не видел его в глаза…
сейчас написали скрипт который заливает приложение на iPhone без явного запуска xCode…
для маленьких игр хватает, для более серьезных поначалу тоже будет хватать, но в итоге все упрется в ограничения платформы, и эти ограничения прийдется преодолевать и Шарп тут не лучший помошник…
Ну и постоянные вбросы антирекламы будут делать такие люди как Кармак, сравнивая возможности одного движка на разных платформах (как это было с ХБох и ПС3, но там ХБокс занимал более достойное положение)…
книжки книжками, но так вот тупо копировать советы очень глупо… информацию нужно хоть как-то фильтровать и переваривать… ибо складывается ситуация, что учат те кто не умеет…
очень ужасен класс анимации! большинство данных в нем константны кроме текущего времени, то есть логично было бы вынести это время отдельно, а в анимации сделать метод GetFrameByTime…
класс cApp не нужен…
вот сами подумайте зачем нам инициализация в 2 местах
сначала в main нужно создать нужный объект класса унаследованного от cApp, вызвать его функции Init, Run (предварительно их реализовав) и тд. если мы прям из этого же майна можем вызвать нужные функции инициализации… гляньте как это сделано в Irrlicht и вам сразу станет понятно что так удобнее и в дальнейшем не возникнет желания плодить синглтоны из наследников класса сАрр…
убивал бы за такое void (*Function)(void* CallerPtr, Purpose Purp);!!!
это же С++!!! может стоит сначала книжек почитать??
за такое void fun2(void* CallerPtr, Purpose Purp)
{
switch(Purp)
{
case STOP_PURPOSE:
cout << «fun2 Stopping» << endl;
break;
case INIT_PURPOSE:
cout << «fun2 Starting» << endl;
break;
case FRAME_PURPOSE:
cout << «fun2 processing» << endl;
break;
default:
cout << «fun2 no purpose» << endl;
break;
}
}
остаток жизни называл бы говнокодером… это сейчас в этой функции 10 строк, как в ней разбираться когда строк станет 100 или 1000… еще раз учите С++!!! в нем можно обойтись без таких извращений…
я расскажу про недостаток (по крайней мере у нас он проявляется)
конец каждой итерации как и конец проекта усиленно способствует появлению прикруток (если у вас каждый заинтересован в качестве проекта, чего не бывает даже если куча единомышленников делает игру мечты)…
ранные прикрутки особо вредны, так как поначалу они просто незаметны, а в дальнейшем на их исправление обычно не выделяется время (правило: работает — нетрогай), однажды настает день когда внесение нового функционала потребует открутки некоторых явных или неявных прикруток… сейчас вы конечно же улыбаясь скажете что вы проведете рефакторинг и все сделаете хорошо… но посмотрите правде в глаза, а потом в глаза своему начальнику, и попробуйте поклясться что помните о всех прикрутках и знаете их решения… скорее всего появятся воркараунды к прикруткам, то есть новые прикрутки, которые постоянно будут делать систему все менее гибкой…
мы пользуемся скрамом, но надеюсь на следующем проекте мы попробуем рассмотреть проблемы которые я привел выше и попробуем прийти к более гибким критериям итерации, чтоб минимизировать ущерб…
там где много разработчиков, там много программ… допустим геймлофт может позволить себе полное портирование (хотя это больше похоже на трансляцию), но вот какие нибудь мелкие конторы, где каждый доллар на счету, уже подумают о том, что им это принесет…
Gameloft — очень большая фирма, мы знаем о том чем занимаемся мы и о некоторых проектах на такой же платформе (ну и проектах внутри студии естественно). но судя по бурному обсуждению шарпа в рассылках, я так понимаю что нативного СДК нет, хотя портирование вроде как не ручное…
посмотрим, сколько придет разработчиков на такие «прекрасные» условия…
я давно знаю что Gameloft делает и будет делать игры под эту платформу, меня больше волнует вопрос: удастся ли мне пощупать эту платформу не пересаживаясь на шарп?..
мы пишем на С++. экран, тачскрин и кое-какие функции работы со временем эмулируются, все остальное есть в стандартной библиотеке С. для отладки игр хватает полностью… кроме этого получаем очень дешевый перенос на еще почти десяток мобильных и не очень платформ…
VS не только удобнее но и компилирует в несколько раз быстрее (несколько минут против 15-20)…
Поэтому я не совсем понимаю политику Microsoft, они разработали одну из лучших сред для разработки но при этом не собираются пользоваться ей сами…
сейчас разрыв в производительности С++ и C# заполнит более мощная аппаратная часть (по крайней мере анонсированные девайзы могли этим похвастаться), но почему бы не открыть доступ к этим мощностям разработчикам игр, которые могли бы прийти на эту платформу с более интересными идеями, чем возможны у конкурентов…
сейчас написали скрипт который заливает приложение на iPhone без явного запуска xCode…
Ну и постоянные вбросы антирекламы будут делать такие люди как Кармак, сравнивая возможности одного движка на разных платформах (как это было с ХБох и ПС3, но там ХБокс занимал более достойное положение)…
Когда выйдет С++ SDK и выйдет ли?
вот сами подумайте зачем нам инициализация в 2 местах
сначала в main нужно создать нужный объект класса унаследованного от cApp, вызвать его функции Init, Run (предварительно их реализовав) и тд. если мы прям из этого же майна можем вызвать нужные функции инициализации… гляньте как это сделано в Irrlicht и вам сразу станет понятно что так удобнее и в дальнейшем не возникнет желания плодить синглтоны из наследников класса сАрр…
это же С++!!! может стоит сначала книжек почитать??
за такое void fun2(void* CallerPtr, Purpose Purp)
{
switch(Purp)
{
case STOP_PURPOSE:
cout << «fun2 Stopping» << endl;
break;
case INIT_PURPOSE:
cout << «fun2 Starting» << endl;
break;
case FRAME_PURPOSE:
cout << «fun2 processing» << endl;
break;
default:
cout << «fun2 no purpose» << endl;
break;
}
}
остаток жизни называл бы говнокодером… это сейчас в этой функции 10 строк, как в ней разбираться когда строк станет 100 или 1000… еще раз учите С++!!! в нем можно обойтись без таких извращений…
сори, спешил…
конец каждой итерации как и конец проекта усиленно способствует появлению прикруток (если у вас каждый заинтересован в качестве проекта, чего не бывает даже если куча единомышленников делает игру мечты)…
ранные прикрутки особо вредны, так как поначалу они просто незаметны, а в дальнейшем на их исправление обычно не выделяется время (правило: работает — нетрогай), однажды настает день когда внесение нового функционала потребует открутки некоторых явных или неявных прикруток… сейчас вы конечно же улыбаясь скажете что вы проведете рефакторинг и все сделаете хорошо… но посмотрите правде в глаза, а потом в глаза своему начальнику, и попробуйте поклясться что помните о всех прикрутках и знаете их решения… скорее всего появятся воркараунды к прикруткам, то есть новые прикрутки, которые постоянно будут делать систему все менее гибкой…
мы пользуемся скрамом, но надеюсь на следующем проекте мы попробуем рассмотреть проблемы которые я привел выше и попробуем прийти к более гибким критериям итерации, чтоб минимизировать ущерб…
посмотрим, сколько придет разработчиков на такие «прекрасные» условия…