Просмотр полной версии : С# и Xna - революция в игросторении.
Люди почему вы прогаете на всяких Delphi и ВизуалБарсиках? Ладно я понимаю тех кто на С++ прогает. Надо смотреть в будушие. Вот как выйдет Singularity(Ну или её потомок) чего будете делать? Если вы думаете что там будет P-code(родной Visual Basic(Который не .NET)) - нет не будет. А вдруг вы думаете что там будет native код(Delphi, C++,...) - нет она будет написана целиком и полностью на C#. И только несколько мегабайт остального кода, да и то не объектно ориентированого(это через p/Invoke, или его потомок). Язык C# очень элегантен - даже у криворукого программера получится красивый код. Язык C# быстрей чем Delphi и даже С++(Если кто несогласен я вам расскажу много нового :) ). В нем нет утечек памяти, есть возможность пользоватся указателями, референс типы заместо тех же поинтеров - это делает vс# быстрой - лёгкой - безопасной средой разработки. Xna это надстройка над DirectX 9.0. Она очень легкая и быстродействующая. В ней есть конвейр-контента(!). Ну может сейчас её использовать не стоит - ибо она только бета. Но в рождество будет всё ок.
Что значит "лёгкая и быстродейсвующая"? Молодой человек, XNA ещё очееень далеко до Direct3D 10 и OpenGL 2.0. Может просто С++ выучить не могите? м?
Язык C# быстрей чем Delphi и даже С++(
Всё. Холивар. С++ намного быстрее. На 35%. Это не моя цифра - это microsoft. Учи матчасть %)
Язык C# очень элегантен - даже у криворукого программера получится красивый код
Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.
О, да! Еще один "великий программер" пришел всех учить!
Fulcrum абсолютно прав. Добавлю, что я пробовал писать 3D игру на C#. Результат - проект закрылcя в самом начале. К счастью. Так что я имею представление о быстродействии этого чуда. C# - это язык для написания, возможно, офисных программ, но ни в коем случае не требовательных к ресурсам приложений. Отсутствие заботы о памяти - не достоинство, а недостаток. Из него, а также из использования байт-кода, вытекает жутко медленная скорость работы, а также потребление лишней этой самой памяти - ведь объекты удаляются не сразу, а когда до них дойдет функция очистки. А за это время может еще понадобится наплодить объектов... Да и не будем забывать, что все функции в C# виртуальные! Кроме того, пиша программы на C#, Вы ставите себя в зависимость от Framework'. Если там вдруг будет глюк (что у Майкрософта не редкость) - все, программа накрылась медным тазом.
Если у Вас код на C# оказался быстрее кода на C++... Уж не знаю, что Вы такое сделали, что так могло получится... Бесконечный цикл, что ли, пытались выполнить :sml:. Может, просвятите?
Сейчас долго думал, и все же пришел к выводу, что для обучения программированию C# тоже не очень подходит. То же отсутствие заботы о памяти может здорово навредить программисту, если он после C# возьмется осваивать, например, C++...
P.S. А автору темы рекомендую попробовать Prolog или Mercury. Вот уж действительно дружественные к программисту языки! Все подчинено логике, задачи поиска реализуются элементарно, да и все остальные тоже. А если кто-то напишет 3D игру на одном из этих языков (и она будет выдавать больше пары FPS), то напишите мне - любопытно будет посмотреть на это чудо!
Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.
Так похоже вы ничего не знаете о платформе .NET.
я сказал же (Если кто несогласен я вам расскажу много нового)
вот начнем.
C#(.NET вообщем) это не ИНТЕРПРЕТИРУЕМАЯ а компилирумая в оптимизизированый к конкретному процесору и памяти, код прямо на машине клиента(Конечного юзера) среда. Есть два вида компиляции.
1) JIT - just-in-time это значит что вся програма компилируется во время выполнения. Вот это и есть ваши "На 35%". Я использую только для дебага.
2) AOT - Ahead-of-time это значит что прога компилируется прямо в нейтивный код во время устоновки. Времени занимает не очень много.Для увесистой проги это секунд 10 на pIII 800 MHz.
"Судя по вашей речи - вы не имеете никакого отношения к программерам."
Я прогаю уже 2 года на уже 4 языках и остановил свой выбор на C#.
Итог - сам учи матчасть
О, да! Еще один "великий программер" пришел всех учить!
Fulcrum абсолютно прав. Добавлю, что я пробовал писать 3D игру на C#. Результат - проект закрылcя в самом начале. К счастью. Так что я имею представление о быстродействии этого чуда. C# - это язык для написания, возможно, офисных программ, но ни в коем случае не требовательных к ресурсам приложений. Отсутствие заботы о памяти - не достоинство, а недостаток. Из него, а также из использования байт-кода, вытекает жутко медленная скорость работы, а также потребление лишней этой самой памяти - ведь объекты удаляются не сразу, а когда до них дойдет функция очистки. А за это время может еще понадобится наплодить объектов... Кроме того, пиша программы на C#, Вы ставите себя в зависимость от Framework'. Если там вдруг будет глюк (что у Майкрософта не редкость) - все, программа накрылась медным тазом.
Если у Вас код на C# оказался быстрее кода на C++... Уж не знаю, что Вы такое сделали, что так могло получится... Бесконечный цикл, что ли, пытались выполнить :sml:. Может, просвятите?
Сейчас долго думал, и все же пришел к выводу, что для обучения программированию C# тоже не очень подходит. То же отсутствие заботы о памяти может здорово навредить программисту, если он после C# возьмется осваивать, например, C++...
Про бесконечный цикл спасиб :) . Я же написал что этот байт код компилируется в найтив в стартапе (AOT). И значит никакого байт кода. Ну если только метаданные да и только если вас вдруг приспичит юзать
System.Reflection
Два года???? :lol:
О, ну тогда не нам, жалким ламерам, программирующим по восемь лет, Вас учить! Не подскажите, какой институт окончили, или Вы еще в школе?
А теперь о том, почему C# в принципе не может быть быстрее кода на C++:
1) Уборка памяти: как может код, который постоянно обходит все объекты и проверяет, не достигло ли количество ссылок на них 0, может быть быстрее кода, этого не делающего?
2) Как может код, компилирующийся во время выполнения (почти интерпритация!) может быть быстрее кода, этого не делающего?
3) Как может код, в котором все функции виртуальные, быстрее кода, в котором это не так?
4) Да, и еще вопрос вдогонку: как вообще может программа, использующая куда больше библиотек, чем c-шная, быть быстрее ее?
ДВА ГОДА???? :lol:
О, ну тогда не нам, жалким ламерам, программирующим по восемь лет, Вас учить! Не подскажите, какой институт окончили, или Вы еще в школе?
А теперь о том, почему C# в принципе не может быть быстрее кода на C++:
1) Уборка памяти: как может код, который постоянно обходит все объекты и проверяет, не достигло ли количество ссылок на них 0, может быть быстрее кода, этого не делающего?
2) Как может код, компилирующийся во время выполнения (почти интерпритация!) может быть быстрее кода, этого не делающего?
3) Как может код, в котором все функции виртуальные, быстрее кода, в котором это не так?
Ну два года я просидел по 12 часов в день за клавой.
1) Ну почему так сразу, ты слыхал про такую штуку как оптимизация.
Для .NET она тоже сушествует. Надо соблюдать её и всё будет ок.
2) Ты слыхал про утилиту ngen.exe? NativeGENERATOR переводится. Она делает очень быстрые native'ные файлы. Хотите сравнить две анологичные проги на C# и на С++ - ок я могу это устроить. Да и ктомуже если вы не поняли я хочу подметить что С# код оптимизируется под машину юзера - он будет использовать(Я имею ввиду код) проц на полную. Он учитывает начиная от разрядности до дополнительного набора инструкций. А теперь про С++. Интересно можно ли на С++ сделать такойже оптимизированый код как на С#. Мне интересно кто это будет делать на конечной машине - млжет юзер или святой дух?
3) Ты хоть понял что сам сказал :) ?
ЗЫ. Возраст и образование не имеет значения - слыхали про 16 летнего подростка который выпустил свой LiveCD Linux дистрибутив.
ЗЫЫ. С++ я знаю, но не имею большого опыта
ЗЫЫЫ. Вы сказали что XNA очень далеко до DirectX 10 и OpenGL 2.0. Да до ОпенЖеЛе 2.0 ему еше очень далеко - не думаю что
Microsoft опустится до такого :). А что касается DirectX 10 то я вам напомню что Xna строится на DirectX
1) Ну почему так сразу, ты слыхал про такую штуку как оптимизация.
Для .NET она тоже сушествует. Надо соблюдать её и всё будет ок.
Да ну? В таком случае, эта оптимизация должна не просто сводить количество дополнительных действий к нулю, а делать его отрицательным!
2) Ты слыхал про утилиту ngen.exe? NativeGENERATOR переводится. Она делает очень быстрые native'ные файлы. Хотите сравнить две анологичные проги на C# и на С++ - ок я могу это устроить. Да и ктомуже если вы не поняли я хочу подметить что С# код оптимизируется под машину юзера - он будет использовать(Я имею ввиду код) проц на полную. Он учитывает начиная от разрядности до дополнительного набора инструкций.
О! Оптимизирующийся под машину юзера код. Смешно :lol: . Во-первых, мне крайне интересно, что он вообще может использовать, кроме количества ядер процессора. А использование количества ядер процессора требует распараллеливание. А распараллеливание - штука черезвычайно сложная, на должном уровне ее только человек может сделать. Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода. А ведь на ее переписывание при появленнии новой модели тоже время нужно. Кстати, откуда эта утилита будет знать, а нужна ли вообще юзеру такая "оптимизация"? К примеру, хочу ли я, чтобы архивирующийся WinRAR жрал ресурсы с обоих ядер моего двухядерника, или я на втором проце в кваку поиграть хочу? Так что такая утилита должна быть не просто "умной" - она должна чуть ли не сильным AI быть! Что-то я не слышал про получение первой премии Тьюрига...
Про использовании разрядности процессора: оно приносит пользу только в специфических задачах, и их вполне можно изначально скомпилить в двух вариантах. К тому же я не совсем понимаю, как вообще можно написать, например, сетевое приложение, не зная, сколько в каком типе бит у тебя будет. Будешь слать по сети вроде 32-х битное число, а оно - опа! - 64-х битным станет. А откуда компилятору знать, что в нем у тебя не может быть числа, больше чем 1000000, чисто по конструкции программы?
А теперь про С++. Интересно можно ли на С++ сделать такойже оптимизированый код как на С#. Мне интересно кто это будет делать на конечной машине - млжет юзер или святой дух?
Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец! Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы и т.п., и это много на что влияет. Да, C++-код оптимизироваться на машине юзера не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше.
Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике.
3) Ты хоть понял что сам сказал :) ?
А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет.
ЗЫ. Возраст и образование не имеет значения - слыхали про 16 летнего подростка который выпустил свой LiveCD Linux дистрибутив.
ЗЫЫ. С++ я знаю, но не имею большого опыта
Возраст - да. Образование - нет. Гении всегда есть, но их мало, и не надо приводить единичные примеры. И на вопрос об образовании ты не ответил.
Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода.
Чет ты гониш. Я же не сказал что под конкретную модель подстраивается. Эт происходит так:
Win32: я загружаю ехе, тут флаги клр есть.
CLR: это флаги джита
JIT: нашли самого левого. О юзера 32 risc проц есть SSE,SSE2,MMX,3DNOW! итд. Буду оптимизить под нехо.
"Набор интструкций, кстати, у современных процессоров почти одинаков."
не спорю - а как насчет расширений? Как об этом узнает прога на С++?
"Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец!"
Драйверы тут не причем, устройства тоже, и вообще что мешает сделать так что-бы при изменении конфигурации, прога меняла свою нативный образ? Да и почему ты не упомянул статический C++? :)
"Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы"
Другие программы - нет, дригие либы - да. Только есть одно но - либы в .net на много отличаются от с++.
"а, C++-код оптимизироваться не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше."
Вот вот оптимизироватся неможет... Хош сказать что ты должен сделать
столько версий что-бы удолетворяло обсолютно всем конфигурациям?
Да и ктому же про конфигурации. Где ещё как не .net ты можеш одну прогу запускать как на Linux так и на Windows. Да и ктомуже как ты будеш давать всем свои "разные конфигурации" разным пользователям если твоя прога распростроняется посредством диска. Кстати ты смотрел на размер ексешника .NET? Так вот посмотрите.
"А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет."
- Судя по всему, нет - это судя по чему?
В .NET не так всё "виртулизировано" :) как кажется.
"Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике."
В С# можно игратся с адресной арфмитикой. Читай доки
Во-первых, пользуйся цитатой! Невозможно понять, где цитата, а где ответ на нее!
Чет ты гониш. Я же не сказал что под конкретную модель подстраивается. Эт происходит так:
Win32: я загружаю ехе, тут флаги клр есть.
CLR: это флаги джита
JIT: нашли самого левого. О юзера 32 risc проц есть SSE,SSE2,MMX,3DNOW! итд. Буду оптимизить под нехо.
не спорю - а как насчет расширений? Как об этом узнает прога на С++?
Эти расширения есть почти на каждом современном проце. Что же касается различий - их использование можно зашить в DLL библиотеки, так как они узкоспециализированны. По той же причине не надо оптимизировать C++-программу под все возможные конфигурации - достаточно скомпилить несколько вариантов DLL-библиотек. Для того их и придумывали.
Драйверы тут не причем, устройства тоже, и вообще что мешает сделать так что-бы при изменении конфигурации, прога меняла свою нативный образ?
То есть оптимизация идет только под процессор? И не важно, как и чем он забит помимо программы?
Как я уже говорил, такую оптимизацию сделать нереально хотя бы потому, что эта задача почти приравнивается к искуственному интеллекту. Такие ходы, как при оптимизации на C++, ни одна автоматическая система не повторит.
Другие программы - нет, дригие либы - да. Только есть одно но - либы в .net на много отличаются от с++.
Только если в сторону тормознутости. Не забывай, .NET исполняется Framework'ом, а Framework на чем написан? На C++ или другом полностью компилируемом языке. И как могут его либы быть качественнее C'шных?
Вот вот оптимизироватся неможет... Хош сказать что ты должен сделать
столько версий что-бы удолетворяло обсолютно всем конфигурациям?
Как уже писал выше, достаточно использовать разные библиотеки. Кстати, такую систему вполне реально реализовать в отрыве от C# для C++.
Да и ктому же про конфигурации. Где ещё как не .net ты можеш одну прогу запускать как на Linux так и на Windows. Да и ктомуже как ты будеш давать всем свои "разные конфигурации" разным пользователям если твоя прога распростроняется посредством диска. Кстати ты смотрел на размер ексешника .NET? Так вот посмотрите.
Размер екзешника такой как раз потому, что программа на C# тормознутие программы на C++ и требует выполнения байт-кода Framework'ом. Касательно Framework на Linux: многое, доступное под Windows, под ним работать не будет. К тому же, если программа пишется грамотно на C++, то она будет компилироваться как под Linux, так и под Windows, почти без изменений в коде.
В .NET не так всё "виртулизировано" :) как кажется.
Интересно, как это - при наличии только виртуальных функций "не все виртулизировано"?
Да, и тут еще один вопросец назрел:
Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования, да и просто найти твои ошибки, наконец? И использовать все это в своих грязных целях, бесповоротно запоров твою программу? Взломав компьютеры всех юзеров, ею пользующихся? За пару часов написав кряк? Вставив в нее вирус? Так что программа в байт-коде - мечта хакера. Не нужно часами копаться в ассемблере и ловить прерывания! Пара секунд - и программа предстает перед ним в своем исходном виде, готовая к любому вмешательству!
Итог: программа на C# медленне программы на C++ хотя бы в силу своей конструкции. Оптимизация не может ничего дать, кроме незначительного выигрыша, из-за сложности самой задачи. Программа на C# практически элементарно взламывается и модифицируется (и я не говорю уже про Framework - т.е. систему с закрытыми исходниками - от которого все зависит! Если в нем будет закладка, баг, дыра - конец всем C#-программам!
Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.
В С# можно игратся с адресной арфмитикой.
Да ладно? В языке без возможности работы с памятью? Мы точно об одном и том же говорим?
"То есть оптимизация идет только под процессор? И не важно, как и чем он забит помимо программы?
Как я уже говорил, такую оптимизацию сделать нереально хотя бы потому, что эта задача почти приравнивается к искуственному интеллекту. Такие ходы, как при оптимизации на C++, ни одна автоматическая система не повторит."
Оптимизация зависит от памяти, от проца, и не много от ОС. Там оптимизация зависит какбы от контрольных точек.
Допустим тебе надо перемножить флоаты. Если SSE будет то код будет вместе с этими SSE.
Только если в сторону тормознутости. Не забывай, .NET исполняется Framework'ом, а Framework на чем написан? На C++ или другом полностью компилируемом языке. И как могут его либы быть качественнее C'шных?
А теперь скажи на чем написан твой C++ компилятор :)
Как уже писал выше, достаточно использовать разные библиотеки. Кстати, такую систему вполне реально реализовать в отрыве от C# для C++.
Ладно можно но сложнее чем для С#
Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования, да и просто найти твои ошибки, наконец?
а ты слашал про Obfuscator'ы?
Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.[/qoute]
Ты хоть слышал про Singularity - нет? почитай. Про баг в .net framework, это странно но ещё не одного бага с framework'ом небыло.
[quote]Да ладно? В языке без возможности работы с памятью? Мы точно об одном и том же говорим?
Да ты уверен? А про unsafe код не слыхал, или вот это не видел.
using System;
namespace Knott.Benchmark
{
internal unsafe class Program
{
private unsafe static void Main(string[] args) {
DataHolder holder = new DataHolder();
for (int i = 0; i < 128 / 4; i += 4) {
DataStruct str = new DataStruct();
str.Offset = i;
str.Location = holder.Array;
str.Data = i * 10;
}
}
}
public unsafe struct DataHolder
{
public fixed byte Array[128];
}
public struct DataStruct
{
public int Offset;
public unsafe void* Location;
public unsafe int Data {
get { int* dataLocation = (int*)((byte*)Location + Offset); return *dataLocation; }
set { int* dataLocation = (int*)((byte*)Location + Offset); *dataLocation = value; }
}
}
}
Я не уверен что этот код работет правильно - но дело в том что поинтеры там есть.
Да до ОпенЖеЛе 2.0 ему еше очень далеко - не думаю что
Microsoft опустится до такого
Ась? о_О Чики - пуки. Бубль - гум. OpenGL теперь оказывается ламерский продукт. Надо известить моего закодычного дружбана Джонни. Который Кармак. А то этот ламер совсем обнаглел - использует понимаешь ли опенгл... Ты парень чего "того"? Самый быстрый апи называть опущением? о_О
Да ты уверен? А про unsafe код не слыхал, или вот это не видел.
pokibor в отличие от тебя программист и высказывает факты, а ты нахватался зивини меня дешёвых статей с сомнительных сайтов и пытаешься до всех донести...
А что касается DirectX 10 то я вам напомню что Xna строится на DirectX
Значит он медленнее директа по определению. Вотттактавот.
Оптимизация зависит от памяти, от проца, и не много от ОС. Там оптимизация зависит какбы от контрольных точек.
Допустим тебе надо перемножить флоаты. Если SSE будет то код будет вместе с этими SSE.
Я и говрю: все это сводится к написанным под тот или иной вариант функциям. Так на любом языке писать можно. И получится, кстати, быстрее, потому как там будет все с умом сделано под конкретный случай, а не под общий, как тут.
А теперь скажи на чем написан твой C++ компилятор :)
Это ты к чему? Ты утверждал, что C#'е либы быстрее C'шных. Я опроверг это. Ты мне в ответ какой-то глупый вопрос задал. C++'е компиляторы пишутся, как ни странно, на том же C++. Также как, например, Паскаль: спера был написан его компилятор (на чем-то, от Паскаля отличном), потом переписан на самом Паскале и скомпилирован этим компилятором - это обычная практика - писать компилятор на самом языке. Но вот для C# она не проходит, т.к. он компилирует в промежуточный код... То есть компилятор C#, конечно, можно переписать на C#, а вот .NET - бессмысленно. И потому либы .NET в приципе не могут быть быстрее C'шных.
Ладно можно но сложнее чем для С#
Не-а. Проще. Так как имеем дело с ассемлерными инструкциями, а не с байт-кодом. Ассемблер - самый простой язык, на нем писать медленнее, а не труднее...
а ты слашал про Obfuscator'ы?
Не забывай, у нас этот байт-код будет компилировать FrameWork. Соответственно, как бы там все не было запутано, оно в равной мере отразится как на хакере, так и на Framework, причем в равной мере. Возможно, Obfuscator'ы замедлят появление дизассемблера, но ненадолго. А ведь их применение еще более замедляет выполнение кода.
Ты хоть слышал про Singularity - нет? почитай.
Читал. И мне смешно. Это с какой же скоростью это чудо будет работать? Да не особо быстрый Windows по сравнению с этой ОС будет как заяц по сравнению с черепахой! Microsoft опять пытается выехать на своем монополизме на рынке ОС, но вовсе не факт, что у нее получится. Во-первых, подходит Google со своей бесплатной осью, которая базируется на Windows, а не начинает все с чистого листа, во-вторых, вряд ли пользователи, если они не дураки, захотят замедлить свой комп и сделать его уязвимым для хакерских атак (байт-код!) непонятно ради чего, в-третьих это чудо выйдет непонятно когда. Похоже, что ты начитался рекламных статеек от Майкрософта и начинаешь кричать всем, что "давайте поддержим дядю Билли!", хотя его за такие дела пора заставить на ассемблере программировать для стиральных машин! :sml:
Про баг в .net framework, это странно но ещё не одного бага с framework'ом небыло.
Это не значит, что их там нет. Впрочем, с такой открытостью кода проще искать баги в программах, чем в Framework.
Да ты уверен? А про unsafe код не слыхал, или вот это не видел.
Слыхал. Только смысла в нем? Его использование превращает язык в C++ с чуть другим синтаксисом и более тормознутым выполнением. И все. Ты, помнится, отсутствие необходимости работы с памятью выводил в преимущесива. Вот и не противоречь себе же.
Я не уверен что этот код работет правильно - но дело в том что поинтеры там есть.
Работает - не работает - не важно. Важно то, что с их использованием язык перестает быть собой и становится очевидно хуже C++. Так что их в расчет не берем.
Ты мне в ответ какой-то глупый вопрос задал. C++'е компиляторы пишутся, как ни странно, на том же C++.
Я да я знаю. Не ты мне сказал что Framework написан на С++. А ведь C++ компилятор тоже написан на С++. И в чем разница?
Не-а. Проще. Так как имеем дело с ассемлерными инструкциями, а не с байт-кодом. Ассемблер - самый простой язык, на нем писать медленнее, а не труднее...
Да на асм писать легко, но это-же дело вкуса. Например мне нравится IL Asm.
Не забывай, у нас этот байт-код будет компилировать FrameWork. Соответственно, как бы там все не было запутано, оно в равной мере отразится как на хакере, так и на Framework, причем в равной мере. Возможно, Obfuscator'ы замедлят появление дизассемблера, но ненадолго. А ведь их применение еще более замедляет выполнение кода.
Так если не ошибаюсь Dotfuscator был разработан припомоши МС.Надо его юзать.
Читал. И мне смешно. Это с какой же скоростью это чудо будет работать?
Эх читать до конца никто не учил? Этот код будет компилироватся во время установки. Да это займёт время. Компилятор называется Bartok.
Да не особо быстрый Windows по сравнению с этой ОС будет как заяц по сравнению с черепахой!
А ты читай http://blogs.zdnet.com/Murphy/index.php?p=459
свой комп и сделать его уязвимым для хакерских атак (байт-код!)
Да не хрена - байт-код байт-код читай выше
хотя его за такие дела пора заставить на ассемблере программировать для стиральных машин!
Это точно.
Ты, помнится, отсутствие необходимости работы с памятью выводил в преимущесива. Вот и не противоречь себе же.
Да приводил, и я не противоречю себе. Необходимости нет - возможность есть.
Работает - не работает - не важно. Важно то, что с их использованием язык перестает быть собой и становится очевидно хуже C++. Так что их в расчет не берем.
А в делфи тоже есть поинтеры. :)
Я да я знаю. Не ты мне сказал что Framework написан на С++. А ведь C++ компилятор тоже написан на С++. И в чем разница?
Да на асм писать легко, но это-же дело вкуса. Например мне нравится IL Asm.
Ты что-то уже совсем потерял нить нашей дискуссии. Это ты вообще к чему? Я все упомянутые примеры приводил в доказательство того, что C# в приницпе не может работать быстрее C++, ты какой-то оффтоп начал писать.
Так если не ошибаюсь Dotfuscator был разработан припомоши МС.Надо его юзать.
И чем это поможет? Опять никаких противоречий со сказанным мною нет. Как замедлял работу, так и будет замедлять. Как код был прост ко взлому хакерами, так и останется.
Эх читать до конца никто не учил? Этот код будет компилироватся во время установки. Да это займёт время. Компилятор называется Bartok.
Никогда не поверю, что Micro$oft, известная своей любовью к закрытым исходникам, будет поставлять ОС пусть даже в байт-коде! А если и вправду будет, то ой как хакеры порадуются! :lol:
А ты читай http://blogs.zdnet.com/Murphy/index.php?p=459
"Вы все еще не в белом? Тогда мы идем к Вам!" - вот что-то вроде этого. Больше походит на громкое реламное сообщение.
Да не хрена - байт-код байт-код читай выше
Вот именно что читай выше - как не запутай байт-код, он байт-кодом останется. Так что - ломаем, братцы! А написаная таким образом система будет медленной потому, что C# медленнее C++, чего ты так и не опроверг.
Да приводил, и я не противоречю себе. Необходимости нет - возможность есть.
А в делфи тоже есть поинтеры. :)
Опять бессмысленные сообщения. В компилируемых в двоичный код языках ссылки и адресная арифметика - основа динамичекого выделения памяти, в C# - абсолютно чуждый элемент, использование которого начисто убивает смысл C#.
P.S. Хотя, если все сказанное Knott и представителями мелкомягких правда, похоже, Microsoft отказалась от изначальной идеи Windows в пользу Linux! Ведь если не брать в рассмотрение язык - действительно получается система с практически открытыми исходниками, которую компилирует сам пользователь. И по сути единственным слабым местом становится как раз медлительность языка (что, впрочем, скорее реверанс в сторону неопытных программистов), причем оно вполне может быть преодолено поставкой с сисемой, кроме компилятора C#, нормального компилятора C++ в двоичный код (а какая разница - из байт-кода или из исходного компилировать программу)? Вот только, похоже, при обновлении чего-то в компьютере (а то и просто при появлении нового драйвера) систему придется перекомпилять заново (а как еще - она же "оптимизируется" как-то. Правда, непонятно, как.)...
Впрочем, в любом случае профессиональные программы как на C/C++ писались, так и будут продолжать писаться. Ибо в них обычно задействуются такие ресурсы, что малейшее замедление из-за сомнительных достоинств смерти подобно.
В общем, на революцию (а тем более в игростроении - отрасли, в которой конкуренция по ресурсам наиболее жесткая) не тянет. Совмещение идей Java и Linux - еще куда ни шло, но не более.
Вот письмо, присланное в нашу студенческую рассылку человеком по имени Алексей Лебедев. Отличный ответ на приведенное в начале этой темы высказывание:
А вы были на домашней страничке Бьярна Страуструпа?
Мне показался очень интересным раздел "Bjarne Straustrup's FAQ":
http://www.research.att.com/~bs/bs_faq.html
В частности:
Q: Что бы думаете о C#?
A: По поводу C# как языка -- без коментариев. Меня придется долго
убеждать в том, что миру нужен ещё один проприетарный язык (yet another
proprietary language -- YAPL). Особенно трудно будет меня убедить в том,
что миру нужен язык, тесно интергрированный с конкретной проприетарной
операционной системой.
Если хотите писать исключительно для платформы .Net, то C# -- не
худший вариант, но помните, что C++ -- хорошо поддерживаемая, хотя и не
такая раздутая, альтернатива.
Q: Почему Вы так ревностно относитесь к переносимости?
A: Успешные программные проекты живут долго. Нередко в течение
нескольких десятилетий. Хорошая программа часто переживает железо, для
которого она была создана, операционную систему, для которой она была
написана, СУБД, которую она использовала, и т. д. Часто хорошие куски
программ переживают компании, предоставляющие основные технологии,
используемые для их создания.
Часто пользователи успешних программных продуктов предпочитают
различные платформы. Множесто предпочитаемых платформ меняется вместе с
изменением людей. Привязываться к одной платфоме или поставщику означает
ограничивать потенциальное использование программы.
Очевидно, полная независимость от платфомы несовместима с возможностью
использовать удобства конкретной платфомы. Тем не менее, часто можно
достич платфоменной независимости используя для каждой платформы "тонкий
интерфейс", реализованный в виде библиотеки.
Q: Почему в C++ нет сборшика мусора?
A: Если вам нужна автоматическая сборка мусора, то для C++ есть много
хороших комерческих, а также свободно распространяемых сборщиков мусора.
Для приложений, где предпочтительно использование сборщика мусора, C++
-- это отличный язык с поддержкой сборки мусора и с производительностью,
которая хорошо соотноситься с производительстью языков со встроенной
сборкой мусора. По поводу дискуссий о сборке мусора в C++ можете
обратиться к книге The C++ Programming Language (3rd Edition).
Кроме того, C++ поддерживает техники программирования, которые
позволяют сделать управление памятью безопастным и прозрачным без
использоваиня сборщика мусора
(http://www.research.att.com/~bs/bs_faq2.html#memory-leaks)
Q: Почему для C++ нет графическго интерфейса (GUI)?
A: Для C++ есть множество комерческих и поставляемых с исходным кодом
графических интерфейсов (Gtkmm, SmartWin++, V C++ GUI, FLTK и Qt). В
частности, постовщик каждой платфомы предоставляет C++-библиотеку, для
доступа к графическому интерфейсу. Проблема в том, что не существует
стандартного графического интерфейса, а это, действительно, большая
проблема.
Заметте, что предоставление GUI -- это как техническая, так и
политическая проблема. Существует множество графических интерфейсов и
множество пользователей, и, как правило, им бы не понравилось, если бы
какой-то не их графический интерфейс был бы объявлен стандартом.
Как бы ни было, у комитетов по стандартизации недостаточно ресурсов для
создания нового и лучшего графического интерфейса.
И ещё много-много интересных вопросов-ответов.
Жаль, что Knott покинул форум. Было бы очень интересно узнать, что он может возразить Страуструпу...
PlagueMen
25.04.2007, 15:03
Знаю С++ 8лет, а С# 4,5 года, спор о производительности ваш для меня кажется странным. В больших проектах типа 1С:Бухгалтерия и т.п. написанных на ++ все равно используется автоматическая уборка мусора и быстродействие этих языков выравнивается. С# ускоряет разработку программ за счет простоты. О быстродействии могу сказать что в ближайшем будущем процессоры будут использовать НЕ команды Assembler в нынешнем виде, а микрокоманды которые не учитывают специфику расположения регистров и т.д. то есть будет использоваться высокоуровневый ассемблер типа MSIL. Microsoft ввела Framework ещё и потому, что ей проще стабилизировать 20 мегабайт кода Framework, чем 600 MB dll-библиотек которые используются сейчас в Windows сейчас. Мой вывод: Framework имеет будущее, он наверняка будет перенесён и на другие операционные системы (уже есть MONO Framework), и программисту не нужно будет задумываться под какую ОС он пишет программу, в перспективе код MSIL или подобный ему будет поддерживаться процессором НАПРЯМУЮ.
ага, тогда или фрэймворк, или виндоус ;) Им двоим тесно в 1 системе
Прашол гот.... С тех пор йа много понил/узнал/прочёл...
НУ ТИПЕРЬ КТО НА МИНЯ?????
Прашол гот.... С тех пор йа много понил/узнал/прочёл...
... кроме учебника по русскому языку.
Использование подобного диалекта Вас не красит как профессионала, а именно таким Вы себя стараетесь выставить.
НУ ТИПЕРЬ КТО НА МИНЯ?????
Эм... на Вас по-прежнему Страуструп, тремя постами выше. Знаете, кто это? Впрочем, в любом случае можете попробовать ему возражать.
Ну что, друзья, подождем еще годик? :lol:
Я хочу добавить только одно. То, как и с какой скоростью работает программа, в большей степени зависит от "пряморукости" програмера, который ее написал, а потом уже от языка. Gothic III, написанная на native, тормозила не хило, тоже было и с NWN2, написанной на managed, но вышли патчи, и все норм работает. Это вопрос удобства и скорости разработки. Большинство предпочитают C++ ассамблеру потому, что си УДОБНЕЕ и кодить под него БЫСТРЕЕ, чем под ассамблер. Пока, в чистом виде, xna пригоден для разработки казуальшины, но майкры двигают ее не из благих побуждений, а из-за наживы - xna работает на двух платформах: Win и XBOX360. И уж поверте, если майкрософт тянется за деньгами, она из получает. Через некоторое время разработчики перейдут на XNA хотя бы только потому, что она ЭКОНОМИЧЕСКИ эффективней, чем c++ и directX. Вот и все.
Я хочу добавить только одно. То, как и с какой скоростью работает программа, в большей степени зависит от "пряморукости" програмера, который ее написал, а потом уже от языка.
Не могу согласиться. Данное утверждение верно в отношении компилируемых языков, предоставляющих полный спектр возможностей вплоть до самых низкоуровневых. И то в настоящее время большинство компиляторов в той или иной степени оптимизируют код, и оптимизирующий код хуже заведомо медленнее.
Если же сравнивать C++ либо Pascal c C# (что и пытался делать автор данной темы), то говорить о главенстве пряморукости программера просто глупо. C++ - язык, компилируемый в машинный код. C# - язык, компилируемый в байт-код, а потом интерпритируемый Framework'ом, да ещё с автоматической очисткой памяти. Отсюда следует, что даже кривыми руками написанная программа, если только в ней нет явных ошибок, да ещё скомпилированная оптимизирующим процессором имеет все шансы оказаться быстрее, нежели на C#. Просто потому, что язык C# по-умолчанию включает в себя кучу замедляющих работу вещей.
И ещё давайте не будем забывать, что C++ предоставляет куда больше возможностей для оптимизации кода, нежели C# - опять же в силу низкоуровневых операций. Ну а повыкидывать ненужные блоки из кода и упростить нужные может, в принципе, и не такой крутой программист - если его заставят, конечно. :wnk:
Gothic III, написанная на native, тормозила не хило, тоже было и с NWN2, написанной на managed, но вышли патчи, и все норм работает.
О, да! Как Gothic III "норм работает" я уже имел счастье наблюдать. Так и не поиграл дольше часу, ожидая "норм работающего" патча. Ну а каких-то ускорений в случае NWN2 не заметил.
Впрочем, к теме это не слишком относится. Как я уже говорил, C# замедляет программы сами по себе. Конечно, на нём есть возможность использовать unsafe-код, да. Но тогда какой смысл в использовании C# как такового?
Это вопрос удобства и скорости разработки. Большинство предпочитают C++ ассамблеру потому, что си УДОБНЕЕ и кодить под него БЫСТРЕЕ, чем под ассамблер.
И при этом просто C разрабатывался таким образом, чтобы предоставлять все даваемые ассемблером возможности для оптимизации, а C++ от него это унаследовал. Простите, но сравнивать по скорости пары C++/ассемблер и C#/C++ просто некорректно. Вы бы ещё Prolog/ассемблер сюда добавили. C# даёт в нагрузку к себе уборку памяти и framework, С++ не даёт в нагрузку к себе ничего.
Пока, в чистом виде, xna пригоден для разработки казуальшины, но майкры двигают ее не из благих побуждений, а из-за наживы - xna работает на двух платформах: Win и XBOX360. И уж поверте, если майкрософт тянется за деньгами, она из получает. Через некоторое время разработчики перейдут на XNA хотя бы только потому, что она ЭКОНОМИЧЕСКИ эффективней, чем c++ и directX. Вот и все.
Да ну? Я как погляжу на современную игровую индустрию - почему-то ребята гонятся за скоростью своих приложений. Иными словами, намерено затормаживать игру будет только глупый человек. Потому что те, кто код свой ради XBOX не затормаживал, обойдут его по всем критериям - и по графике, и по физике, и по AI.
Что же XNA удобнее и быстрее - попробуйте мне ещё доказать, ибо под C++ сейчас столько движков и наработок у всех имеется, что преимущества C# в скорости разработки мне не совсем понятны. Работа с памятью упрощена? И что? Нормальный программист delete где нужно и так писать не забывает, а не нормальный и в C# кучу ошибок наделает.
Microsoft, конечно, известна своим упорством в делании денег. Однако сейчас, похоже, уже не так ситуация, когда она может выиграть. Сравните продажи/использование Висты и XP. Ох, как M$ Висту продвигали! DirectX 10! Давайте все переходите под висту, пишите под Висту! И что? Да плюнули разработчики игр на Висту, к счастью! А некоторые и DirectX в гробу видали - под OpenGL пишут.
Так что M$ в кои-то веки дали по носу с её инициативами.
И ещё ответьте: Вы читали интервью Страуструпа чуть выше? В кратце - для C++ реализованы дополнительные примочки, добавляющие в него преимущества C#. А теперь вопрос - так ёлки-палки, почему ими никто не пользуется, если это так "удобно" и "экономически выгодно", а C#'пом все вдруг вдохновятся, выкинут все движки/библиотеки на C++ и строем пойдут под XNA писать, а? Из-за XBOX? А не слишком ли это глупо - писать заведомо тормознутые игры только из-за приставки, опять же заведомо более тормознутой, нежели компьтер?
Если же сравнивать C++ либо Pascal c C# (что и пытался делать автор данной темы), то говорить о главенстве пряморукости программера просто глупо. C++ - язык, компилируемый в машинный код. C# - язык, компилируемый в байт-код, а потом интерпритируемый Framework'ом, да ещё с автоматической очисткой памяти. Отсюда следует, что даже кривыми руками написанная программа, если только в ней нет явных ошибок, да ещё скомпилированная оптимизирующим процессором имеет все шансы оказаться быстрее, нежели на C#. Просто потому, что язык C# по-умолчанию включает в себя кучу замедляющих работу вещей.
Не могу не согласиться.:wnk: Я ведь не говорю, что c# работает быстрее, здесь c++ в фаворе. Каждый выбирает, что нравится, есть же те, кто на бэйсике пишут.
Да ну? Я как погляжу на современную игровую индустрию - почему-то ребята гонятся за скоростью своих приложений.
Да, что-то последние проекты так и летают... Последней реально оптимизированной игрой бала Half-Life 2, а остальные делают так, лишь компилировалась.
Microsoft, конечно, известна своим упорством в делании денег. Однако сейчас, похоже, уже не так ситуация, когда она может выиграть. Сравните продажи/использование Висты и XP. Ох, как M$ Висту продвигали! DirectX 10! Давайте все переходите под висту, пишите под Висту! И что? Да плюнули разработчики игр на Висту, к счастью!
То же, помниться, было с ХР. Все говорили, что тормозит и никому она не нужна, но сейчас почти все под ней сидят.:wnk:
Sorry, всемени нету. Продолжение следует...
Не могу не согласиться.:wnk: Я ведь не говорю, что c# работает быстрее, здесь c++ в фаворе. Каждый выбирает, что нравится, есть же те, кто на бэйсике пишут.
Ну, на бейсике коммерческие игры никто не делает. Всё-таки при их разработки значима не только скорость собственно разработки, но и скорость работы.
Да, что-то последние проекты так и летают... Последней реально оптимизированной игрой бала Half-Life 2, а остальные делают так, лишь компилировалась.
Опять не могу согласиться! Конечно, известные игры часто делают спустя рукова, но хитами такие не становятся. А вот неизвестную игру так делать - путь к поражению.
И опять же к медлительности - не забываем, C# сам по себе замедляет игру при том, что основные процедуры давно уже упакованы в библиотеки. Я хочу сказать, что все те же тормоза при разработке на C# останутся + добавятся ещё тормоза языка. И какой смысл в C# тогда?
То же, помниться, было с ХР. Все говорили, что тормозит и никому она не нужна, но сейчас почти все под ней сидят.:wnk:
В случае XP под неё все достаточно быстро перешли, и там майкрософт эксклюзив пробить не пыталась.
Жду конкретных возражений.
Ну тут и баталия однако =) Я программирование знаю плохо но меня почему то больше убедил pokibor
=)
Kalimdor
27.11.2007, 17:15
Не могу не согласиться. Я ведь не говорю, что c# работает быстрее, здесь c++ в фаворе. Каждый выбирает, что нравится, есть же те, кто на бэйсике пишут.
Согласен.
Как Gothic III "норм работает" я уже имел счастье наблюдать.
После 4 патча у меня всё нормально работало.
Последней реально оптимизированной игрой бала Half-Life 2
Ну на счёт оптимизации. Помимо желания у разработчиков игр за спиной издательство, которому только деньги нужны. Соответственно это резко ограничивает время разработки.
CMogilko
27.11.2007, 19:13
такой вопрос: идёт ли работа DirectX под Framework через байт-код? Т.е. основная нагружаемая часть железа в играх - видео карты, процы же редко сильно нагружаются, а если игра через XNA идёт медленней только на процессоре, а на видео карте не отражается, то проблем нету и я могу плюнуть на относительную тормознутость. А вот если отражается на видео карте, то XNA говно полюбэ, ведь разрабочики всегда выжимают всё до последней капли из ведео карты(
такой вопрос: идёт ли работа DirectX под Framework через байт-код?
Очевидно, что частично. Иначе как через байт-код, программа под Framework работать не может. С другой стороны, реализовывать типовые функции из DirectX через байт-код было бы очень тупо даже для майкрософта.
Т.е. основная нагружаемая часть железа в играх - видео карты, процы же редко сильно нагружаются
ДА НУ??? То-то игры за тормознутость даже на топовом железе ругают... :lol:
Через видеокарту идут только достаточно низкоуровневые операции плюс шейдеры. Всё остальное грузит процессор. А игра - это, вообще-то, не только графика. Это ещё и физика, и огромные объёмы памяти. А память у нас в C# с автосборщиком. И вот этот автосборщик должен постоянно проверять, а нельзя ли очистить вот эти полтысячи ссылкок? А может ту тысячу отчистить? Догадываетесь, из-за чего будут программы тормозить? И даже всеобщий переход на физические ускорители и (о, Боже!) ускорители AI ситуацию с памятью не спасёт, ибо данные-то игровые в родимой ОЗУ хранятся, а там у нас сборочка памяти работает-с.
И скажите мне честно: Вы планируете на физический ускоритель и ускоритель AI переходить, а? Не думаю.
а если игра через XNA идёт медленней только на процессоре, а на видео карте не отражается, то проблем нету и я могу плюнуть на относительную тормознутость.
Щаз! Просто запустите Готику 3 на каком-нибудь старом Пентиуме, а потом уже будете говорить о плевках на относительную тормознутость.
"Система всегда тормозит со скоростью самого медленного своего компонента".
А вот если отражается на видео карте, то XNA говно полюбэ, ведь разрабочики всегда выжимают всё до последней капли из ведео карты(
Разработчики выжимают всё до последней капли из всего, откуда только могут её выжать. Если Вы не в курсе, именно мощь процессора стоит на пути улучшения искуственного интеллекта и физики игры. Физические ускорители пока проваливаются, а об ускорителях AI ничего, кроме туманных проектов, и не слышно.
CMogilko
27.11.2007, 21:21
ДА НУ???
на своём core 2 duo ни разу не наблюдал загрузку проца выше 60% даже в крайзисе. все тормоза в играх решаются ослаблением графики, что не должно влиять на нагрузку проца значительно.
на своём core 2 duo ни разу не наблюдал загрузку проца выше 60% даже в крайзисе. все тормоза в играх решаются ослаблением графики, что не должно влиять на нагрузку проца значительно.
А, ну Вы бы ещё на Cray'е протестировали. :lol: Создатели игр, как правило, редко ориентируются на топовое железо, а стараются заставить игру работать на менее мощной конфигурации.
Далее, насчёт ослабления графики - это зависит от реализации этой самой графики. Конечно, использованием топовой видекарты с последней версией шейдеров можно несколько разгрузить процессор, но всё-таки конфигурации у пользователей, как правило, сбалансированные. Ну и к тому же шейдеры - это отдельная статья программирования, не имеющая отношения к основному языку написания программы.
Кстати, Вы не думали, что в некоторых случаях, ослабляя графику, снимаете нагрузку именно с процессора, который вынужден тратить время на софтовую эмуляцию отстуствующих в видеокарте возможностей, а?
Ну и жду возражений на остальные аргументы, особенно по поводу памяти. Да и по поводу физики с AI тоже не помешает. В Кризис я, правда, не играл (и не собираюсь), но ещё не видел игры с нормально реализованным AI, а физика была нормально реализована только в специальных демках, только на то и рассчитаных. Это при том, что все алгоритмы для улучшения и того, и другого уже давно известны. А всё почему? Да как раз потому что если ЭТИМ загрузить процессор, то он загнётся всё считать. Потому сейчас и особо не разгоняются в этом плане, особенно по статье AI.
Далее, не лишне Вам будет напомнить, что Core 2 Duo он как бы немного двухядерный, а для получения максимальной выгоды от второго ядра в случае одного приложения нужно это самое приложение особо оптимизировать. Так что Ваши 60% могут быть не следом того, что Кризис не может загрузить процессор на все 100%, а следом плохой оптимизации под двухъядерный процессор. Только и всего.
CMogilko
28.11.2007, 15:41
Кстати, Вы не думали, что в некоторых случаях, ослабляя графику, снимаете нагрузку именно с процессора, который вынужден тратить время на софтовую эмуляцию отстуствующих в видеокарте возможностей, а?
Не стоит ориентироваться на видеокарты прошлого поколения, подавляющее большинство видеокарт сегодня имеют аппратную поддержку всех технологий для игр, имеющихся в момент выпуска видеокарты. Если запускать игру при высоких настройках на видеокарте 2х летней давности, то это проблема запускающего.
Ну и жду возражений на остальные аргументы, особенно по поводу памяти.
их нет.
А всё почему? Да как раз потому что если ЭТИМ загрузить процессор, то он загнётся всё считать. Потому сейчас и особо не разгоняются в этом плане, особенно по статье AI.
а я не про это говорил, я говорил, что если переделать игру под Framework, то из-за несильно возросшей нагрузке процессора тормозов не будет, т.к. он очень сильно не нагружается из-за слабого ИИ и физики. В данный момент процессор не так сильно нагружен, но и не выдержит всех обсчётов физики и ИИ, а вот работу через Framework справится. Он же не каждые 10 секунд проверяет ощистку памяти. Да и не совсем это байт-код, он всё-таки компилируется перед запуском из MSIL в машинные коды процессора.
Не стоит ориентироваться на видеокарты прошлого поколения, подавляющее большинство видеокарт сегодня имеют аппратную поддержку всех технологий для игр, имеющихся в момент выпуска видеокарты. Если запускать игру при высоких настройках на видеокарте 2х летней давности, то это проблема запускающего.
Это не проблема запускающего, а убытки издателя, который стремится впихнуть как можно лучшую графику в как можно меньшие требования. Далее, насчёт того, какие технологии поддерживаются в современных видеокартах, хотелось бы знать Ваш опыт написания шейдеров. Дело в том, что шейдеры накладывают приличные ограничения на обрабатываемое собой. Всё, что в них не укладывается, идёт в нагрузку на процессор.
А насчёт "Не стоит ориентироваться на видеокарты прошлого поколения" Вы скажите издателям игр. К счастью, пока они думают несколько иначе, а не заставляют всех повально на сверхновые железяки переходить.
их нет.
А смысл продолжения спора, если часть контраргументов не опровергнута?
а я не про это говорил, я говорил, что если переделать игру под Framework, то из-за несильно возросшей нагрузке процессора тормозов не будет, т.к. он очень сильно не нагружается из-за слабого ИИ и физики. В данный момент процессор не так сильно нагружен, но и не выдержит всех обсчётов физики и ИИ, а вот работу через Framework справится.
Точку зрения "давайте оставим технологии всё как есть, перейдём на фреймворк и будем радоваться жизни" будете издателям говорить.
Нет, конечно, если написать на Framework какой-нибудь Quake 3, он, конечно, полетит и на семпроне. Вот только такая игра провалится в конкурентной борьбе.
Железо, к сожалению, развивается медленнее алгоритмов, и зачастую как раз под них, как показала практика.
И насчёт двухядерника тоже возражений нет? Просто я не вижу реальных доказательств, что в сбалансированной конфигурации процессор играет меньшую роль, нежели видеокарта.
Он же не каждые 10 секунд проверяет ощистку памяти. Да и не совсем это байт-код, он всё-таки компилируется перед запуском из MSIL в машинные коды процессора.
А если он не каждые 10 секунд будет проводить очистку памяти, то она очень скоро банально забьётся ненужным для игры в данный момент мусором. Отлично - будем покупать в 2 раза больше ОЗУ, чем реально требуется игре. Это при том, что Вашему Кризису 2 гига рекомендуется. Значит, потребуется четыре. Одному ему. Весело. На цивилизованом западе, где игры покупаются честно, даже тамошние богачи разорятся так своё железо обновлять.
О, ну если этот байткод будет компилится в машинные коды процессора, то я с чистой совестью запущу какого-нибудь "Ведьмака" и подожду полчаса до запуска игры, пока код соизволит скомпилится. Зато потом буду радоваться жизни. До следующего запуска.
Нет, я всё-таки ещё надеюсь добиться у Вас объяснений, что же такое даёт C#, чего не даёт C++ и что позволит ему одержать верх.
Сборщики памяти для C++ есть (ими никто не пользуется). Библиотеки те же самые, что и для C#, есть. Так что же такое эта XNA даёт (кстати, она вроде как на DirectX 10, а потому по определению работает медленнее этого самого DirectX 10, уже не говоря про быстрый OpenGL), что игры будут под неё писаться в условиях противостояния красот и фишек? Ответ X-BOX не принимается т.к. насчёт заведомой тормознутости приставки по сравнению с компьютером опять же возражений не было.
CMogilko
28.11.2007, 16:27
Это не проблема запускающего, а убытки издателя, который стремится впихнуть как можно лучшую графику в как можно меньшие требования.
издатель ориентируется на игроков своей страны, а это, в основном, западные игроки, которые не сидят с одной видеокартой по 3 года.
хотелось бы знать Ваш опыт написания шейдеров.
небольшой есть, просто посмотрел ради интереса, но серьёзно не занимаюсь.
И насчёт двухядерника тоже возражений нет?
ещё при появлении Hyper-Threading 3 года назад многие игры начали обзаводится работой в 2х потоках, даже патчами, врядли эта тенденция остановилась.
Просто я не вижу реальных доказательств, что в сбалансированной конфигурации процессор играет меньшую роль, нежели видеокарта.
мой друг года 2 назад, очень комфортно играл в современные игры на GeForce 6200 и P3 1.0 GHz, в то время, когда у меня стояла GeForce 5500 и P4 3.06 GHz и игры шли с более низким качеством.
О, ну если этот байткод будет компилится в машинные коды процессора, то я с чистой совестью запущу какого-нибудь "Ведьмака" и подожду полчаса до запуска игры, пока код соизволит скомпилится.
игры под X-BOX360 идут под .NET и запускаются не пол часа, хотя идут под более медленной системой. Да и падение производительности максимум 10%, иначе игр под .NET вообще бы не было
Нет, я всё-таки ещё надеюсь добиться у Вас объяснений, что же такое даёт C#, чего не даёт C++ и что позволит ему одержать верх.
Но появляется мультиплатформенность, позволяющая играть на других осях, виндовс обязана своей популярностью именно играм, так вполне можно будет запустить игру с одного диска и под линуксом и под маком.
ЗЫ соре за даблпостинг, на клаве какая-то кнопка начала "отправлять быстрый ответ"
издатель ориентируется на игроков своей страны, а это, в основном, западные игроки
Верно-верно. Это в-основном западные казуальные игроки, которые не могут сами заменить видеокарту, у которых кроме компьютера ещё и приставки есть, у которых вообще цены повыше чем у нас будут... И которые именно что сидят с одной видеокартой по три года хотя бы потому, что не так интерисуются компьютером.
И в то же время есть хардкорщики и пресса, которые в играх разбираются и которые могут обеспечить достаточную рекламу и раскрутку игры (рекламную компанию Halo 3 не каждый может позволить). То есть нужно угодить и технологиями, чтобы игру расхвалили, и достаточно низкими системными требованиями, чтобы она шла у как можно большего круга обывателей.
Кстати, вот интересно - почему мы считаем, что Запад поголовно как сыр в масле катается? Это вовсе не так. Уровень жизни там выше, да. Но не будем забывать, что у нас многие люди вообще и компах только в новостях слышали.
небольшой есть, просто посмотрел ради интереса, но серьёзно не занимаюсь.
Честно говоря, это и видно.
ещё при появлении Hyper-Threading 3 года назад многие игры начали обзаводится работой в 2х потоках, даже патчами, врядли эта тенденция остановилась.
Оптимизация под два потока вовсе не так проста, как кажется.
мой друг года 2 назад, очень комфортно играл в современные игры на GeForce 6200 и P3 1.0 GHz, в то время, когда у меня стояла GeForce 5500 и P4 3.06 GHz и игры шли с более низким качеством.
Года два назад? Это при том, что для вышедшего в 2004 году Half-Life уже требовался минимум 1.2 ГГц процессор, а разработчики занижать требования ох как не склонны? И физика, и AI нормально работали? И почему я банально не верю...
игры под X-BOX360 идут под .NET и запускаются не пол часа, хотя идут под более медленной системой. Да и падение производительности максимум 10%, иначе игр под .NET вообще бы не было
Они компилируются в код ядра, да? :eek: И не тратят на это времени? Ага, как же.
А как насчёт того, что по данным Майкрософта ( http://forum.igromania.ru/showpost.php?p=1038528&postcount=2 ) замедление 35%, а?
А хороших передовых не тормозящих игр под .NET и нет. Ну а сапёра какого на C# в пример приводить как-то несерьёзно. :lol:
Так игры и на Basic'е есть. Будем кричать, что Basic C++ рвёт на запчасти теперь?
Но появляется мультиплатформенность, позволяющая играть на других осях, виндовс обязана своей популярностью именно играм, так вполне можно будет запустить игру с одного диска и под линуксом и под маком.
Ага, сейчас пойду ставить на компьютер мак специально чтобы погонять под ним в квейк какой. Виндоус, как не печально, прочно укрепился на роли популярной домашней системы, иначе бы игры преимущественно под него не писали.
Далее, запуск под Линуксом и Маком - это лишь теория, т.к. под ними ещё должен появится не только базовый фреймворк, но и DirectX (при том, что 10 вроде как для висты эксклюзив пока... или уже нет?, а XNA на десятке), и всё прочее...
Между тем вот незадача - C++ сам по себе кроссплатформенный язык, а OpenGL есть под тем же линуксом. То есть можно перенести игру с OpenGL без серьёзных перемен в коде. Однако ж почему-то под OpenGL не таки много игр делают (кстати, вот это зря!). Так может, дело не в мультиплатформенности?
Ну и насчёт того, что XBOX медленнее компа я уже говорил, да и Вы это сами написали.
[CCCP] Monster
29.11.2007, 13:57
CMogilko
Давай подождем пока со спором. Ты еще не знаешь многого. Когда будем проектировать движок, ты сам многое поймешь. Сейчас ты просто не совсем себе предстваляешь, как работает двигатель игры и как именно он использует ресурсы процессора и видеокарты. Поэтому порой пишешь не совсем правильные ыещи и пытаешься всё под одну гребенку загрести (что не получится - есть там куча неочевидных нюансов, влияющих на производительность). Поэтому мы с Покибором и затеяли написание учебного проекта - игры.
pokibor
Давай лучше статьи писать:) А то тут спор глухого с немым получается:)
serializer
30.11.2007, 15:28
Не могу не высказаться по этому поводу.
О, да! Как Gothic III "норм работает" я уже имел счастье наблюдать.
Сам себе противоречишь: сначало говоришь, что все крупные разработчики гонятся за скоростью, а теперь приводишь такие игры. Хотя 3-я готика с последним патчем на рекомендуемой конфигурации и не тормозит (по крайней мере у меня)
И что? Да плюнули разработчики игр на Висту, к счастью!
Да вы что? Кто плюнул? Кармак?
А некоторые и DirectX в гробу видали - под OpenGL пишут.
Опятьже Кармак и некоторые энтузиасты. Да и вообще, все известные игры на огл сделаны восновном на кармаковском движкеа C++ от него это унаследовал.
Основное отличие С++ от С - это поддержка ООП (ктобы этого не знал?)
И говорить, что самое главное в движке - ООП, это бред. Есть и неооп движки.
-----
Если виста тормозит на вашем компьютере, то это не значит, что Виста - говно.
И разработчики современных игр не учитывают, что у пользователя видеокарта 10 лет не менялась.То есть нужно угодить и технологиями, чтобы игру расхвалили, и достаточно низкими системными требованиями, чтобы она шла у как можно большего круга обывателей.
Однако прогресс давит на разрабтчиков. Если бы все ориентировались только на скорость то 3D графики так бы и не появилось.Виндоус, как не печально,
И чегоже печального. Чтобы говорить, что гейц дурак, нужно как минимум быть умнее его ). А вы наверное создали свою ОС, которая лучше Виндовс?
Оптимизация под два потока вовсе не так проста, как кажется.
А что разработка игры - это просто и легко. К томуже если это даст хоть 5 фпс, это того стоит. и современные приложения делают обычно больше 2-х потоков.
-----
Никто и не спорит, что С++ быстрее С#, но говорить, что последний - говно и никто не будет на нем писать как минимум глупо. Игры и движки на нем делают и есть готовые. А если вам хочется оптимизации, пишите под DOS, он вообще не больше 1мб памяти ест, вот только боюсь проблемы будут.
Почемуже на С# будут писать? Может потому что в это вбухивает MS? Или они просто не имели дело с pokibor'ом? =)
Monster;2777515]Сейчас ты просто не совсем себе предстваляешь, как работает двигатель игры и как именно он использует ресурсы процессора и видеокарты.
Неужто нужно быть гением, чтобы понимать как работает движок?
serializer, во-первых, попрошу воздержаться от бранных слов. Во-вторых, [CCCP] Monster про спор немого с глухим написал верно, так что воздержусь от своих комментариев, особенно после Вашей последней фразы, отлично Вас иллюстрирующей. В-третьих, перечислите игры "только под DirectX 10 и Висту" (как и хотела M$) и тогда поймёте, кто именно на неё плюнул. В-четвёртых, я и сам на C# пишу. Удивлены? А я пишу, потому что всякую мелочь на нём писать действительно быстрее и удобнее, нежели на Visaul C++ под Win 32. Там есть быстрый и удобный конструктор оконных приложений и нет глюков Борландовского Builder'а. Но вот писать на нём серьёзную игру мне в жизни в голову не придёт по указаным выше причинам. И по ним же это не будет быстрее и удобнее, нежели на C++.
И перечитайте название темы: "С# и Xna - революция в игросторении". Речь идёт конкретно об игростроении, причём в-основном о серьёзных коммерческих играх.
P.S. А статьи я пишу, только медленно. Сейчас вот хочется собрать небольшую программу по нечёткой логике. Кстати, собираю я её на C#, ибо для небольших оконных приложений он вполне удобен. Вот так.
serializer
30.11.2007, 16:03
pokibor
Я написал свои коментарии и четко их аргументировал.
Отвечаю вопросы:
последней фразы, отлично Вас иллюстрирующей.
Вот уж не думал, что это может так обидеть другого человека, а темболее и "иллюстрировать" меня.
В-третьих, перечислите игры "только под DirectX 10 и Висту" (как и хотела M$)
Естественно, что на заре ДХ10 их мало. Но говорить что их не будет... и сам на C# пишу
Ничуть не удивлен.И по ним же это не будет быстрее и удобнее, нежели на C++.
Разве я писал чтото про быстроту и удобноть? Какраз наоборот.так что воздержусь от своих комментариев
А зря, я расчитывал на ответ
ЗЫ. закройте тему если нечего писать.
ЗЫ. Избавте от ВЫканья, это всеже действует на нервы
Естественно, что на заре ДХ10 их мало. Но говорить что их не будет...
Их не мало, их нет вообще. То есть ни одной. Даже для Halo 2 Виста необходима не по реальным, а по маркетинговым причинам - её взломали и заставили запускаться на XP. Crysis тот же заставили идти на XP в максимальном качестве: http://forum.ixbt.com/topic.cgi?id=25:19980-10#331 и http://forum.ixbt.com/topic.cgi?id=25:19980-9#292.
Особенно радуют слова "Но все равно играбельней, чем под Windows Vista." и "разглядывая скриншоты Dx10 very high и dx9 very high... не вижу никакой разницы (vista x86, 8800gts)!!! Но зато четко вижу разницу в скорости (~15-20%)."
Иными словами факты говорят о том, что Виста и DX10 как основа для игр реально никому не нужны, разве что Micro$oft денег даст и заставит всех писать под них (но столько денег даже у M$ не найдётся).
А если ещё иметь в виду, что DirectX 10 - это не XNA, то XNA тем более вообще никому не нужна и даже не планирует быть нужной.
Так что извините, но факты - вещь упрямая. А предполагать Вы можете всё, что угодно. Я же предпочитаю на факты смотреть.
А зря, я расчитывал на ответ
Ладно, в виде исключения, хотя чувствую, что результат будет столь же глухим:
То, что разработчики не оптимизируют свои игры ещё не значит, что они не гонятся за скоростью и пойдут писать на C#. Потому что на C# у них выйдет точно такая же "оптимизация", а скорее даже хуже за счёт отсутствия работы с памятью.
Что OpenGL быстрее DirectX - факт. Кармак далеко не самый глупый человек, его движки вроде как покупают за боооольшие деньги.
Про ООП Вы ответили на какой-то выдуманный собой вопрос, моего же аргумента и краем не коснулись.
ЗЫ. закройте тему если нечего писать.
Это не ко мне. Хотя я бы её не закрыл в любом случае. Писать есть чего, людей, разбирающихся на должном уровне в теме, нет.
ЗЫ. Избавте от ВЫканья, это всеже действует на нервы
Если это Вам действует на нервы, то опять же см. про иллюстрацию. Я собеседников на форумах привык уважать и обращаться к ним соответсвующе. На "ты" я только с теми, кого хорошо знаю.
serializer
30.11.2007, 16:58
pokibor
Пишу последний, надеюсь, пост в этой теме:
1 . Будут писать только потому что МС так надо. И МС вложит масимум сил и денег для этого.
2 . Разве я писал чтото про быстроту и удобноть? Какраз наоборот.
3 . Про ООП я взял это из темы "Проектируем ядро игры"
4 . Вот именно, что все огл игры основаны на кармаковском движке. Покупают? Unreal Engine 3 (это тот что с ДХ10) тоже покупают и по статистике гораздо больше.
5 . Очевидно, что API, основанное на СОМ объектах будет медленнее
6 . "разбирающихся" в чем? вы хотите найти людей, которые смогут оспорить ваше мнение. Тогда на gamedev.net или подобные сайты. А здесь вы таких точно не найдете.
7 . Если для вас Ты - это оскарбление, то с вами я буду на ВЫ.
pokibor
1 . Будут писать только потому что МС так надо. И МС вложит масимум сил и денег для этого.
А вот это утверждение абсолютно бездоказательно и пока что ни капли не подтверждено.
2 .
Если по этому вопросу мы согласны, тогда какого ответа Вы от меня ожидаете?
3 . Про ООП я взял это из темы "Проектируем ядро игры"
Тогда и цитату оттуда приводите. Я пока не понимаю, как Ваш ответ к текущей теме относится.
4 . Вот именно, что все огл игры основаны на кармаковском движке. Покупают? Unreal Engine 3 (это тот что с ДХ10) тоже покупают и по статистике гораздо больше.
А подавляющее большинство игр написано на C++. Если брать Вашу логику - то вопрос о C# вообще закрыт по умолчанию.
А я и не спорю, что на DirectX 9 (вот про 10 не надо! см. ситуацию с Кризисом по ссылкам) больше игр, нежели на OpenGL. Вы, похоже, забыли исходную фразу.
5 . Очевидно, что API, основанное на СОМ объектах будет медленнее
Играет роль не только COM, но и аппаратная реализация - в частности, у славящейся этим NVidia.
6 . "разбирающихся" в чем? вы хотите найти людей, которые смогут оспорить ваше мнение. Тогда на gamedev.net или подобные сайты. А здесь вы таких точно не найдете.
Стоп-стоп-стоп. Перечитайте-ка первый пост. Тему я создал? Это я изначальное мнение о "революции в игростроении" оспариваю. Если Вы не можете моё оспорить - это не значит, что другие не смогут. Сюда ходят и грамотные люди - [CCCP] Monster, например. Или Вы считаете себя самым умным человеком на этом форуме?
А на gamedev'е скорее с моим мнением согласятся, а не оспорят его.
7 . Если для вас Ты - это оскарбление, то с вами я буду на ВЫ.
Лично для меня "ты" это не оскорбление, поэтому можете обращаться ко мне как угодно. Однако у меня есть своё мировоззрение, по которому я ко всем недостаточно знакомым людям обращаюсь на "вы".
serializer
30.11.2007, 18:06
pokibor
ох... Чувствуется мне доночи здесь сидеть чтоб вы поняли мои слова.
А вот это утверждение абсолютно бездоказательно и пока что ни капли не подтверждено.
Посмотрите в интерете - что сделала МС для продвижения висты: начиная от обильного пиара, зпканчивая специальным специальным сертиыфикатом поддержки висты. (тема закрыта)
Если по этому вопросу мы согласны
Если брать Вашу логику - то вопрос о C вообще закрыт по умолчанию.
Если Вы не можете моё оспорить - это не значит,
Да прочитайте мои слова! Что мне оспаривать. То что С++ быстрее # , давно доказано. А оспаривает пусть автор темы. Я оспариваю лишь то, что "C# и виста мастдай"
насчет [CCCP] Monster
Он сюда заглядывал толко ничего не писал.(тема закрыта)
Или Вы считаете себя самым умным человеком на этом форуме?
Возможно вы преставляете меня дураком, я себя уникумом несчитаю. (тема закрыта)А на gamedev'е скорее с моим мнением согласятся, а не оспорят егоЕсли вы скажете что все должны перестать писать на C#, только потомучто он медленнее, то врядли.
Опятьже посмотрите движки на С# (тема закрыта)
[CCCP] Monster
была о медлительности с#, а стала о том, что C# говно и не надо на нем писать
pokibor
fixed
[CCCP] Monster
30.11.2007, 18:13
pokibor
serializer
Я вот вообще не понял, о чем был спор
Посмотрите в интерете - что хделала МС для продвижения висты: начиная от обильного пиара, зпканчивая специальным специальным сертиыфикатом поддержки висты. (тема закрыта)
Смотрю, смотрю, и вижу, чем эти усилия закончились. Из всех моих друзей на Висте никто не сидит, в Висте куча багов, постоянно уязвимости находят, DirectX 10 реально ни одно игре не нужен, "купленно" нужен лишь немногим играм... Именно что тема закрыта. Micro$oft в кои-то веки промахнулся. Вовремя Билли слинял с руководящего поста. :lol:
Да прочитайте мои слова! Что мне оспаривать. То что С# быстрее ++ , давно доказано.
:eek: :eek: :eek:
Простите? Вы точно нигде описку не допустили? C# быстрее С++? :eek: Тогда ещё раз ссылки на доказательства ("давно доказано"?), пожалуйста.
C++ быстрее C# по работе кода (на 35%) и равен ему по скорости - для разработке игр, в которых всё равно интерфейс свой, а не стандартный. А с учётом имеющихся наработок на C++ - даже по скорости разработки игр он быстрее.
А оспаривает пусть автор темы. Я оспариваю лишь то, что "C# и виста мастдай"
Тогда ссылку, где я это говорил. И где вообще кто-нибудь это говорил. C# разумен только для разработки оконных приложений, не слишком требовательных к ресурсам. Про Висту промолчу из цензурных и оффтопных соображений. Пока ни капельки не ощутил необходимости и желания переходить на неё с XP. Как и любой из моих друзей.
А движки и на Прологе можно сделать. Вон на бейсике есть. Будете и про бейсик также спорить?
[CCCP] Monster
30.11.2007, 18:37
pokibor
Директ Х 10 дает возможность пользоваться аппаратной поддержкой геометрических шейдеров - это его единственное сильно отличие от 9-го. Правда, ведутся работы для адаптации интерфейсов для XP.
Кстати, в отличие от историков и политиков, у программеров есть мощное оружие для спора, железные факты. Пишем код в обоих технологиях, делающий в принципе одно и то же. Берем таймеры выского разрешения и анализируем. И конфу машины, на которой проводились испытания не забудьте.
Кстати, задач рекомендую разных понаделать. Математических, выборки, прохода массива с несколькими условными преходами в теле цикла и т.д.
Кстати, о SSE1 оптимизациях забываем. Они позволяют, воспользовавшись 128-битными регистрами математического сопроцессора, считать за один машинный такт 4 числа с плавающей точкой в формате 32 bit IEEE. С# в силу своих особенностей использовать эти оптимизации пока не в состоянии.
И кстати, по контексту, Покибор не говорил, что Си Шарп вообще не достоин использования. Он говорил, что такие сложнве и требовательные к ресурсам приложения, как современные игры, писать на Си Шарпе, использующем ДотНет как основу, было бы не разумно.
Monster;2784462']
Директ Х 10 дает возможность пользоваться аппаратной поддержкой геометрических шейдеров - это его единственное сильно отличие от 9-го. Правда, ведутся работы для адаптации интерфейсов для XP.
Я бы выделил вот так. Последние расширения OpenGL, кажется, дают тоже самое и не требуют Висты. Кстати, фраза "ведутся работы для адаптации интерфейсов для XP" меня умиляет. Майкрософт осознаёт провал своих планов с популяризацией Висты по ходу дела.
Так что же такое эта XNA даёт (кстати, она вроде как на DirectX 10, а потому по определению работает медленнее этого самого DirectX 10, уже не говоря про быстрый OpenGL)
XNA на dx9 пока работает.
Сейчас делают dx10.1 в котором, как обещают :wnk:, устранят основные глюки и тормоза dx10.
Вообще, меня, наверное, не так поняли. Я не говорю, что XNA уделает связку C++ + (калабур:wnk: ) dx или OpenGL. Просто появилась реальная альтернатива этой паре. Это не тормоза типа GLScene или Dark Basic. На предтече XNA, MDX, выпущена NWN2. Пример NWN2 доказывает, что на .NET можно делать коммерчески успешные продукты и оправдывает существование XNA.
Хотя, в сегодняшнем виде, XNA пригодна только для casual проектов.
Вообще, меня, наверное, не так поняли. Я не говорю, что XNA уделает связку C++ + (калабур:wnk: ) dx или OpenGL. Просто появилась реальная альтернатива этой паре.
Чем же она реальная, эта альтернатива?
Это не тормоза типа GLScene или Dark Basic.
:lol: Извините, но после такого сравнения с Вами говорить не о чем. Сравнить далеко не лучшие движки "для самых маленьких" с XNA и делать из этого какие-то выводы... это признак из разряда "слышал звон..."
На предтече XNA, MDX, выпущена NWN2. Пример NWN2 доказывает, что на .NET можно делать коммерчески успешные продукты и оправдывает существование XNA.
Простите??? Каким боком NWN2 связана с .NET? Инструментарием? Да я в курсе, что инструментарий у NWN2 на .NET написан. Это как раз и проходит по статье оконных приложений, не слишком требовательных к ресурсам... точнее, как раз из-за того, что он на .NET, редактор NWN2 и любит кушать.
В основе NWN2 лежит Electron engine, построенный на старом Aurora Engine, который уж точно с .NET никак не связан. Единственно, что в NWN2 может быть написано на .NET - некая внешняя обёртка, т.к. движок довольно специализирован под RPG. Если XNA будет настолько крутой, что предложит все необходимые процедуры для любого жанра, причём на уровне скорости специализированного движка, то я готов взять свои слова о ней обратно. Но пока что позволю предположить, что универсальный быстрый движок под любой жанр - это нечто из области фантастики, тем более в исполнении Micro$oft.
Хотя, в сегодняшнем виде, XNA пригодна только для casual проектов.
А с этим я и не спорю, но в теме заявляется "С# и Xna - революция в игросторении". Так что о создании клонов Lines и тетриса речи не идёт.
Простите??? Каким боком NWN2 связана с .NET? Инструментарием? Да я в курсе, что инструментарий у NWN2 на .NET написан.
Я каким-то образом открыл в netreflector'е либы nwn2, хотя не все. Там были классы дла магической и ролевой систем, а так же, не помню точно, что-то связанное с рендером. Не спорю, может, вы и правы.
Извините, но после такого сравнения с Вами говорить не о чем. Сравнить далеко не лучшие движки "для самых маленьких" с XNA и делать из этого какие-то выводы... это признак из разряда "слышал звон..."
Я сравнивал движки не на C++ с XNA. Это все известные мне доступные движки из этого рода. Если вам известны какие-то другие, напишите, плиз, буду благодарен.
Чем же она реальная, эта альтернатива?
Бысторотой? Нет. Удобством? Дело вкуса. Легкостью? Как посмотреть. Реальность альтернативы я рассматриваю, прежде всего, исходя из наличия, или нахождения в стадии разработки, коммерческих проектов, основанных на данной альтернативной технологии. А такие есть: к примеру http://www.visual3d.net/.
Я сравнивал движки не на C++ с XNA. Это все известные мне доступные движки из этого рода. Если вам известны какие-то другие, напишите, плиз, буду благодарен.
Я не знаю ни одного нормального движка, написаного не на C++. Наверное, поэтому серьёзные игры пишут именно на C++, а не на чём-то другом, как Вы считаете? Стало быть, если Вы сравниваете XNA с этими отсталыми движками, то она автоматически идёт в их категорию - используемых новичками в казуальных проектах движков. Что ж, такой роли XNA я не отрицал, для написания проектов уровня Quake 2 по графике она подходит и даже тормозить не будет. Но вот на "революцию в игростроении" такое применение XNA как-то не тянет...
Бысторотой? Нет. Удобством? Дело вкуса. Легкостью? Как посмотреть. Реальность альтернативы я рассматриваю, прежде всего, исходя из наличия, или нахождения в стадии разработки, коммерческих проектов, основанных на данной альтернативной технологии. А такие есть: к примеру http://www.visual3d.net/.
Так есть и на бейсике игры, и на Blitz3D (тоже ещё тот смех). Хоть один известный тайл либо компанию назовите. А коммерческими и казуальные проекты являются. В общем, см. выше. В категории движков для самых маленьких как раз майкрософтовского продукта не хватало...
Knott
Насчет XNA. XNA действительно полезная утилита.Конечно же в ней легко работать(у меня XNA нету,но знаю по обзорам).Но с её установкой куча возни. Хоть мне и 10 лет,скажу,что лучше использовать OpenGL 2.0.
XNA действительно полезная утилита.Конечно же в ней легко работать(у меня XNA нету,но знаю по обзорам).
из серии "Слышал звон, но не знаю где он". В ХНЕ копаюсь около 2-х недель
Но с её установкой куча возни. Хоть мне и 10 лет,скажу,что лучше использовать OpenGL 2.0.
нет никаких проблем с установкой кроме криворукости и невнимательности. Ваше утверждение по поводу OGL2.0 смешно.
ну а теперь обо всем по порядку :D
Что значит "лёгкая и быстродейсвующая"?
быть может, в плане понимания внутреннего устройства игрового механизма
Всякие споры о том, программы на каком языке написаны, на шарпе, или на плюсах - это очередной бессмысленный спор. pokibor, некоторые люди языки программирования знают и по 10 лет, и код пишут не ахти какой. На личном опыте убедился. Преподаватель паскаля в нашем городе в престижнейшем учебном заведении вместо цикла в 25 повторов написал в коде программы 25 конструкций if then else.
И про нативный vs IL код. Выскажу свое мнение. Процессору нет разницы на чем написана прога, на шарпе, па плюсах, на асме, или вообще на перфокартах. Процессор машинный код выполняет, который ему готовит транслятор(Прошу прощения за грубость в определениях). И пофиг, что программы на шарпе грузятся чуть подольше.
Кстати, а Вы не сталкивались с проблемами утечки памяти?(об очистке ее чуть пониже).
Так вот, таких проблем нет в .NET, т.к. во время "компиляции" на машине конечного пользователя происходит оптимизация именно для его машины.
Сейчас долго думал, и все же пришел к выводу, что для обучения программированию C# тоже не очень подходит. То же отсутствие заботы о памяти может здорово навредить программисту, если он после C# возьмется осваивать, например, C++...
Как раз для обучения программированию шарп очень подходит в силу своей легкости в понимании. Человек сразу учится ООП, а значит, очень велик шанс что в его коде по мере роста опыта будет расти и качество. И не будет такого бардака, который можно написать в делфи, плюсах, или перфокартах.
А если он не каждые 10 секунд будет проводить очистку памяти, то она очень скоро банально забьётся ненужным для игры в данный момент мусором.
В интернете где то статью читал, в ней было сказано примерно следущее "Если Ваш компьютер тормозит - купите новый компьютер", а еще там было сказано "Выполняйте только те задачи, которые от вас требует задача", и еще там было сказано "Компилятор лучше знает, когда производить сборку мусора и очистку памяти, оставьте это на его совести". Последняя цитата сказана к тому, что в плюсах Вы можете после каждой опирации выполнять сборку мусора. Но подумайте, в плюсах процесс сборки мусора - это команды, это процессорное время, и далеко не факт, что Ваша забота о памяти нужна будет конечному пользователю. Напишите блокнот с офигенно хорошо продуманным механизмом работы с памятью, но кому он нужен, когда есть Word? пусть он ресурсов ест больше, пусть он грузится дольше, но зато он много чего умеет, так что аргумент "Он не умеет работать с памятью" не уместен.
Имхо в самом начале получения программерского опыта нужно получать и осваивать азы технологии программирования, а не очистку памяти, поэтому шарп как нельзя кстати подходит для этих целей.
ps// Сборка мусора осуществляется либо в моменты простоя программы (когда она ожидает команд пользователя), либо по мере необходимости в свободной памяти (сборку мусора можно вызвать и в коде). Сборщик мусора отслеживает состояние объектов — ссылается ли на них кто-нибудь или нет.
Уф.. написал много чето.. иду дальше...
Размер екзешника такой как раз потому, что программа на C# тормознутие программы на C++ и требует выполнения байт-кода Framework'ом.
Нет, ну это просто смешно, простите, без слез прочитать это не получилось. .NET FRamework - Он один. Это проще говоря библиотека классов, коих во фрэймворке тысячи. Какакая бы конфигурация компьютера у пользователя ни была, фрэймворк останется один. Если программа написана с использованием стандартных средств .NET, в сам эхешник попадут описания только классов и методов, которые основаны на уже существующих классах платформы .NET В этом плане Win32 приложения проигрывают, и ненадо спорить, я лет 7 на делфи кодил, знаю с++, подключение любого хедера к проекту вызывало прибавление в "весе" конечного эхешника, т.к. эти нативные компиляторы для каждой проги вешают оди и те же включения. Представь себе 20 программ написанных на .net Framework 2.0, общий вес которых максимум 200 кб без использования графики и нестандартных методов. Размер дистрибутива .NET 2.0 - примерно 20 МБ. А теперь возьмите 20 нативных Win32 приложений. В каждом из них куча повторяющегося мусора. Конечно, можно писать только с использованием WinAPI, но это как то... мягко говоря сразу в проигрыше по сравнению с разработками на шарпе и .NET. Опять же, это все мое имхо.
Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования
А кто мешает систему защиты на с++ написать?
да и просто найти твои ошибки, наконец? И использовать все это в своих грязных целях, бесповоротно запоров твою программу?
А кому этот самый юзверь плохо сделает, когда прогу запорет? себе разве что.
Взломав компьютеры всех юзеров, ею пользующихся? За пару часов написав кряк? Вставив в нее вирус?
А как он взломает компьютеры? каким способом? Если, я, скажем, тот же самый блокнот написал на шарпе, в котором работы с сетью нет как таковой, то КАК можно будет взломать комп? силой мысли только если.
Так что программа в байт-коде - мечта хакера. Не нужно часами копаться в ассемблере и ловить прерывания! Пара секунд - и программа предстает перед ним в своем исходном виде, готовая к любому вмешательству!
Ага, изменить то можно, а вот контрольная сумма md5 или sha1 совпадать не будет.
Дело в том, что шейдеры накладывают приличные ограничения на обрабатываемое собой. Всё, что в них не укладывается, идёт в нагрузку на процессор.
Раз уж вы заговорили про шейдеры, то вы наверняка в курсе, что XNA устроен таким образом, что отрисовка графики происходит используя шейдеры. А что такое шейдеры? чето все говорят, пиксельные шейдеры, вершинные... Шейдеры - это программы, которые исполняются непосредственно графическим процессором, а не ЦПУ. Шейдеры придумали чтобы графика рисовалась быстрее, а не физику или ИИ считать.
Это при том, что Вашему Кризису 2 гига рекомендуется.
в оффициальном руководстве написано что требуется 3 гб оперативки м 768 мб видеопамяти
Нет, я всё-таки ещё надеюсь добиться у Вас объяснений, что же такое даёт C#, чего не даёт C++ и что позволит ему одержать верх.
Прошу прощения, но пока читал эту тему, такое ощущение сложилось что Вы просто папа в программировании. В Шарпе одна отладка только чего стоит, я уже молчу о некоторой кроссплатформенности. Кстати, о кроссплатформенности. На компьютере у меня установлен WindowsXP. У меня есть КПК с ОС Windows Mobile 5.0, так же мобильный телефон с ОС Windows Mobile 5.0. Решил написать для телефона свой ирц клиент. Начал отлаживать его, сначала реализовал работу с сокетами, потом UI. В итоге, 1 раз нажав на F5(Build and Run) получился эхешник, который запускается и КОРРЕКТНО РАБОТАЕТ на смартфоне, кпк, и компьютере. А ВАМ слабо ТАКОЕ на Ваших этих плюсах?.
А в плюсах есть сериализация?
А рефлексия?
Кстати, об отличиях шарпа и плюсах можно почитать здесь (http://www.statmod.ru/3-5/programming/csharp_potapov/index.htm)
X-BOX не принимается т.к. насчёт заведомой тормознутости приставки по сравнению с компьютером опять же возражений не было.
.....
Ну и насчёт того, что XBOX медленнее компа я уже говорил, да и Вы это сами написали.
у бокса характеристики железа по сравнению с компьютером(в дальнейшем ББ) ниже, да и у ps3 тоже, однако работают они в разы быстрее чем комп. на пк в ос встроены кучи сервисов, драйверов, программ. Запуская игру на ББ он(ББ) помимо обработки игровых данных еще и все сервисы операционной среды обслуживать должен, которые между прочим так же едят память.
Игровая приставка устроена проще. Там нет никаких вордов, нету интернет эксплореров, нету звукозаписывающих программ, или программ для записи диском\эмуляции дисков. Там реализован базовый функционал, которого достаточно для того, чтобы запускались игры и воспроизводился медиа контент. Больше и не требуется.
Виндоус, как не печально, прочно укрепился на роли популярной домашней системы
Вас никто не заставляет использовать ОС Windows. линукс и макинтош последнее время набирают популярность
кстати, вот несколько полезных ссылок о .NET:
http://www.interface.ru/fset.asp?Url=/microsoft/Net/mic_net1.htm
http://msdn2.microsoft.com/ru-ru/netframework/aa569283(en-us).aspx
http://www.statmod.ru/3-5/programming/csharp_potapov/index.htm
ну и еще добавлю.
Каждый выбирает то, что ему больше нравится. Нравится тебе - пиши хоть на асме(вспомните kkrieger-beta.exe весом в 65 кб, и который вобрал в себя все самые современные рюшечки по тем временам).
Может быть с++ действительно чем то хорош, но полтора года занимаясь кодингом на языке C#, плюсы вспоминаю как страшный сон.
В перспективности C# сомневаться нет смысла, сомниваетесь? посмотрите какие деньги им платят.
Вы можете сидеть на своих плюсах и месяц вылавливать глюк с утечкой памяти, ибо где то неправильно указатель поставили, или рендерер писать.
В современном ритме жизни не имеет значения, сколько лет ты знаешь плюсы, асм, пролог, меркури, или 001111011011. Главное - RAD. Опять сомниваетесь? тогда почему придумали VCL в делфи и билдере? Можно сидеть и париться с апи пытаясь нарисовать окошко с текстовым полем и кнопкой ОК внутри, только надо ли оно, когда можно парой-тройкой кликов реализовать это все ВИЗУАЛЬНО.
C# является одним из представителей высокоуровневых RAD языков.
C# легко читаем
C# легко усвояем
Я не сомневаюсь в том, что на шарпе, а точнее на платформе .NET в скором времени начнут появляться довольно неплохие игры.
Если еще что нибудь вспомню - напишу.
Как средство разработки игр для начинающих XNA - очень хороший вариант. Она в первую очередь ведь и рассчитана на студентов и энтузиастов. Я очень сомневаюсь что те, кто сейчас известен такими играми как HalfLife, HalfLife2, Crysis прям с первой попытки писали нечто напоминающее игры с суперсовременной меганавороченной графикой. И вообще, разве графика в играх главное??
pps// то, что в шарпе пишится 1 строчкой кода, на плюсах иногда минимум в 2 строчки выходит.
Ваше утверждение по поводу OGL2.0 смешно.
А может напишите, почему? OpenGL (так, на минуточку) - самый быстрый API для трёхмерной графики. А какие преимущества у DX10, на котором XNA построена?
Всякие споры о том, программы на каком языке написаны, на шарпе, или на плюсах - это очередной бессмысленный спор. pokibor, некоторые люди языки программирования знают и по 10 лет, и код пишут не ахти какой. На личном опыте убедился. Преподаватель паскаля в нашем городе в престижнейшем учебном заведении вместо цикла в 25 повторов написал в коде программы 25 конструкций if then else.
И про нативный vs IL код. Выскажу свое мнение. Процессору нет разницы на чем написана прога, на шарпе, па плюсах, на асме, или вообще на перфокартах. Процессор машинный код выполняет, который ему готовит транслятор(Прошу прощения за грубость в определениях). И пофиг, что программы на шарпе грузятся чуть подольше.
Во-первых как модератор прошу воздержаться от спорных в плане цензурности выражений. Тут Вам не башорг.
Во-вторых, имейте уважение к собеседнику и правильно пишите ники.
В-третьих, по существу:
Про то, кто какой код пишет, Вы абсолютно не в тему. Мы обсуждаем не криворукость отдельных программистов, а достоинства сред разработки/языков/компиляторов/библиотек.
Далее, последнее утверждение демонстрирует Вашу абсолютную некомпетентность в рассматриваемом вопросе. Процессору, конечно, нет разницы, какой код выполнять. Зато юзеру есть разница, что код на C# выполняется Framework'ом, и в нём производится автоматическая сборка мусора в памяти, что вылевается в 35%'ое замедление программ на C# по сравнению с аналогичными на C++. Учите матчасть, уважаемый, прежде чем других в некомпетентности обвинять.
Кстати, а Вы не сталкивались с проблемами утечки памяти?(об очистке ее чуть пониже).
Так вот, таких проблем нет в .NET, т.к. во время "компиляции" на машине конечного пользователя происходит оптимизация именно для его машины.
Нет, не сталкивался. В своих программах, по крайней мере, потому что умею их отлаживать. А если кто-то не умеет - это, извините, их проблемы. Такие люди и на C# с кучей ошибок напишут.
Так вот, в .NET таких проблем нет ценой замедления работы программы (см. выше про сборку мусора), а "оптимизация под конечную машину" - это чушь и рекламный трюк Micro$oft. Мне ещё никто толком не смог объяснить, под что там она оптимизируется и каким образом ей это удаётся.
Как раз для обучения программированию шарп очень подходит в силу своей легкости в понимании. Человек сразу учится ООП, а значит, очень велик шанс что в его коде по мере роста опыта будет расти и качество. И не будет такого бардака, который можно написать в делфи, плюсах, или перфокартах.
Как раз для обучения он не подходит в силу отсутствия заботы о памяти. Программист сразу расхолаживается, а потом, когда у него просят написать быстрый код на C++ и появляются те самые утечки памяти - просто потому, что бедняга не привык её очищать.
А то, что C++ - эталон в плане ООП, Вы слышали? В C# ООП практически чисто C++'ное.
В интернете где то статью читал, в ней было сказано примерно следущее "Если Ваш компьютер тормозит - купите новый компьютер", а еще там было сказано "Выполняйте только те задачи, которые от вас требует задача", и еще там было сказано "Компилятор лучше знает, когда производить сборку мусора и очистку памяти, оставьте это на его совести". Последняя цитата сказана к тому, что в плюсах Вы можете после каждой опирации выполнять сборку мусора. Но подумайте, в плюсах процесс сборки мусора - это команды, это процессорное время, и далеко не факт, что Ваша забота о памяти нужна будет конечному пользователю. Напишите блокнот с офигенно хорошо продуманным механизмом работы с памятью, но кому он нужен, когда есть Word? пусть он ресурсов ест больше, пусть он грузится дольше, но зато он много чего умеет, так что аргумент "Он не умеет работать с памятью" не уместен.
Имхо в самом начале получения программерского опыта нужно получать и осваивать азы технологии программирования, а не очистку памяти, поэтому шарп как нельзя кстати подходит для этих целей.
Ага, так и хочется добавить "спонсор статьи - Micro$oft", ибо так оно и есть. Перечитайте только заголовок темы, там немного об играх как бы говорится. Стало быть, Вы утверждаете, что "если для Crysis на C# требуется суперкомпьютер - купите его, это ваши проблемы"? Ну-ну, а теперь идите объяснять это же миллионам пользователям. И что же это злобные игроманцы в своих статьях неимоверно тормозящие игры обругивают... Наверное, не хотят купить компьютер помощнее, не слушают увещиваний Micro$oft'а. Уууу, нехорошие!
А про цитатку - этого добра у нас тоже навалом. Вон почитайте Страуструпа где-то в теме.
Далее, Вы опять забыли, что мы говорим об играх, у которых не бывает моментов простоя программы, ибо игровой цикл бегает постоянно. Так что Вы опять отлично продемонстрировали свою абсолютную некомпетентность в рассматриваемом вопросе.
Нет, ну это просто смешно, простите, без слез прочитать это не получилось. .NET FRamework - Он один. Это проще говоря библиотека классов, коих во фрэймворке тысячи. Какакая бы конфигурация компьютера у пользователя ни была, фрэймворк останется один. Если программа написана с использованием стандартных средств .NET, в сам эхешник попадут описания только классов и методов, которые основаны на уже существующих классах платформы .NET В этом плане Win32 приложения проигрывают, и ненадо спорить, я лет 7 на делфи кодил, знаю с++, подключение любого хедера к проекту вызывало прибавление в "весе" конечного эхешника, т.к. эти нативные компиляторы для каждой проги вешают оди и те же включения. Представь себе 20 программ написанных на .net Framework 2.0, общий вес которых максимум 200 кб без использования графики и нестандартных методов. Размер дистрибутива .NET 2.0 - примерно 20 МБ. А теперь возьмите 20 нативных Win32 приложений. В каждом из них куча повторяющегося мусора. Конечно, можно писать только с использованием WinAPI, но это как то... мягко говоря сразу в проигрыше по сравнению с разработками на шарпе и
Вы хоть поняли, что написали, и что сказал я? Вы целиком подтвердили мои слова, и не опровергли моего утверждения, что отчасти из-за этого программы на C# тормознутие программ на C++. Да, проги на C++ больше размером (этого никто не отрицает), но при современных масштабах, да ещё В ИГРАХ, когда ресурсы занимают несколько гигабайт, прибавление в весе экзешника хоть десятка мегабайт ничего не значит.
Или, может, Вы будете утверждать, что чем программа меньше, тем быстрее она выполняется? Тогда я рассмеюсь Вам в лицо и в который раз отправлю учить матчасть.:lol:
А кто мешает систему защиты на с++ написать?
А Вы опять не поняли написанного. Учите... ага, именно её, родную, матчасть. Речь идёт о том, что код дизассемблируется в два счёта. Какая система защиты, Вы о чём? Хаккер вскроет Вашу игру и выкинет из неё код вызова любой системы защиты. Или Вы предлагаете, чтобы система защиты динамически распаковывала зашифрованный экзешник на C# при каждом запуске? Первое место в конкурсе "как затормозить игру" присуждается (барабанная дробь!) noLove! Ура, товарищи!
А кому этот самый юзверь плохо сделает, когда прогу запорет? себе разве что.
Нет, Вам. Потому что хаккер взламывает вашу программу и пользуется результатами. Итог - хорошо если просто пиратское распространение повсеместное. А если найдена уязвимость похлеще - ждите исков от разъярённых пользователей на возмещение ущерба.
А как он взломает компьютеры? каким способом? Если, я, скажем, тот же самый блокнот написал на шарпе, в котором работы с сетью нет как таковой, то КАК можно будет взломать комп? силой мысли только если.
Вы опять-таки в тему посмотрите. Мы про игры говорим. Впрочем, на Ваш вопрос я отвечу. Он украдёт все Ваши коммерческие тайны и вытащит наружу все недочёты. В серьёзных компаниях это - многомиллионые убытки.
Ага, изменить то можно, а вот контрольная сумма md5 или sha1 совпадать не будет.
А зачем ему что-то менять? Он обнаружит уязвимости, украдёт коммерческие тайны, вытащит на свет божий баги. Какое из этих действий нарушает контрольную сумму?
Кроме того, при чём тут вообще контрольная сумма? Если мы говорим, например, о выкидывании кода защиты, хакер после дизассемблирования Вашего экзешника и выкидывания кода просто-напросто скомпилит экзешник по-новой, и выложит в сеть. При чём тут контрольная сумма? Кто будет проверять неравенство сумм в старом и новом экзешниках, если новый экзешник целиком заменяет старый?
Раз уж вы заговорили про шейдеры, то вы наверняка в курсе, что XNA устроен таким образом, что отрисовка графики происходит используя шейдеры. А что такое шейдеры? чето все говорят, пиксельные шейдеры, вершинные... Шейдеры - это программы, которые исполняются непосредственно графическим процессором, а не ЦПУ. Шейдеры придумали чтобы графика рисовалась быстрее, а не физику или ИИ считать.
Не поверите, я это знаю, т.к. сам писал диплом на тему разработки игр. А вот Вы явно опять не поняли, что я написал. XNA не может всё обрабатывать через шейдеры хотя бы потому, что не всё в этих шейдерах быстро реализуется, и не всё поддерживается. Например, шейдеры до версии 3.0 совершенно не поддерживают циклы. Как Вам такое ограничение? Я уж не говорю, что если вывод всей, абсолютно графики идёт через шейдеры помимо пользователя, то итог - замученный графический процессор, тогда как центральный отдыхает в теньке. В программе всё должно быть сбалансированно, а система тормозит со скоростью самого медленного своего компонента. Вы забыли эту истину.
в оффициальном руководстве написано что требуется 3 гб оперативки м 768 мб видеопамяти
Ещё лучше. Значит, ошибка в данных на этом форуме. Я, если что, в Кризис не играл и играть не собираюсь. Ну да не суть. Вы только подтвердили мои слова своим утверждением.
Прошу прощения, но пока читал эту тему, такое ощущение сложилось что Вы просто папа в программировании.
А пока я читал Ваше сообщение, изобилующие принципиальными ошибками, у меня такое ощущение сложилось, что так оно и есть.
В Шарпе одна отладка только чего стоит, я уже молчу о некоторой кроссплатформенности. Кстати, о кроссплатформенности. На компьютере у меня установлен WindowsXP. У меня есть КПК с ОС Windows Mobile 5.0, так же мобильный телефон с ОС Windows Mobile 5.0. Решил написать для телефона свой ирц клиент. Начал отлаживать его, сначала реализовал работу с сокетами, потом UI. В итоге, 1 раз нажав на F5(Build and Run) получился эхешник, который запускается и КОРРЕКТНО РАБОТАЕТ на смартфоне, кпк, и компьютере. А ВАМ слабо ТАКОЕ на Ваших этих плюсах?.
А в плюсах есть сериализация?
А рефлексия?
Ну, кросплатформенность у него в пределах Windows (на Линусе - урезанная версия, про приставки я не говорю, т.к. они заведомо тормознутее компа). Код на C++ тоже кроссплатформенный, да будет Вам известно. Только его компилить надо, и учитывать, какие библиотеки где есть. Ну так C# тоже, положим, не без библиотек существует.
Мне такое не слабо, повторюсь, дело в библиотеках. Вся штука в том, что если такое есть на C# - значит возможно и на C++, ибо сам .NET-то не на себе же написан, а на том самом C++. Вот так-то. Значит, везде, где кроссплатформенностью обладает C#, ею будет обладать и C++, вопрос только в получении библиотек (если их M$ прячет, то альтернатив куча) и в компиляции (ну так это не проблема, подождать повторной сборки ради скорости работы).
Сериализация, простите, штука в C++ как бы встроенная, Вы, по ходу дела, не совсем её значения понимаете.
Насчёт рефлексии - поясните, что Вы имеете в виду, а то у меня складывается стойкое ощущение как раз того самого "слышал звон..." с Вашей стороны.
Кстати, об отличиях шарпа и плюсах можно почитать здесь (http://www.statmod.ru/3-5/programming/csharp_potapov/index.htm)
А о том, почему C# не нужен - почитать у Страуструпа выше в теме. Уж он-то действительно "папа в программировании".
у бокса характеристики железа по сравнению с компьютером(в дальнейшем ББ) ниже, да и у ps3 тоже, однако работают они в разы быстрее чем комп. на пк в ос встроены кучи сервисов, драйверов, программ. Запуская игру на ББ он(ББ) помимо обработки игровых данных еще и все сервисы операционной среды обслуживать должен, которые между прочим так же едят память.
Игровая приставка устроена проще. Там нет никаких вордов, нету интернет эксплореров, нету звукозаписывающих программ, или программ для записи диском\эмуляции дисков. Там реализован базовый функционал, которого достаточно для того, чтобы запускались игры и воспроизводился медиа контент. Больше и не требуется.
И что дальше? Приставки, работающие лет по пять на одном и том же железе объективнее медленнее обновляемых компов если не сразу после своего выхода, то уж через полгода после него - точно, даже с учётом всех дополнительных "тормозов" от ОС (которая, надеюсь, всё-таки не Виста) и прочего. Плюс Вы не понимаете, что Framework на XBOX будет требовать примерно такой же универсализации доступа к оборудованию, как и на компьютере. Приставки "относительно быстрее" только за счёт тонкой оптимизации игр под себя, т.ч. и в плане памяти. C# убьёт такую возможность.
Вас никто не заставляет использовать ОС Windows. линукс и макинтош последнее время набирают популярность
И к чему это замечание? Программы-то я пишу для большинства, как программист. Если бы Вы были правы, то Вы бы, кстати, противоречили самому себе, ибо под линукс полноценного Framework'а нет, он пока здорово порезанный.
Каждый выбирает то, что ему больше нравится. Нравится тебе - пиши хоть на асме(вспомните kkrieger-beta.exe весом в 65 кб, и который вобрал в себя все самые современные рюшечки по тем временам).
Может быть с++ действительно чем то хорош, но полтора года занимаясь кодингом на языке C#, плюсы вспоминаю как страшный сон.
В перспективности C# сомневаться нет смысла, сомниваетесь? посмотрите какие деньги им платят.
Вы можете сидеть на своих плюсах и месяц вылавливать глюк с утечкой памяти, ибо где то неправильно указатель поставили, или рендерер писать.
В современном ритме жизни не имеет значения, сколько лет ты знаешь плюсы, асм, пролог, меркури, или 001111011011. Главное - RAD. Опять сомниваетесь? тогда почему придумали VCL в делфи и билдере? Можно сидеть и париться с апи пытаясь нарисовать окошко с текстовым полем и кнопкой ОК внутри, только надо ли оно, когда можно парой-тройкой кликов реализовать это все ВИЗУАЛЬНО.
C# является одним из представителей высокоуровневых RAD языков.
C# легко читаем
C# легко усвояем
Я не сомневаюсь в том, что на шарпе, а точнее на платформе .NET в скором времени начнут появляться довольно неплохие игры.
Поздравляю, Вы сейчас доказали то, с чем никто и так не спорил, а я - писал прямым текстом - что C# идеально подходит для написания небольших офисных приложений. К сожалению, при написании серьёзных игр все перечисленные Вами преимущества C# не работают, ибо игры пишутся на основе кучи библиотек и движков, игры требовательны к быстроте своего кода (с чем у C# принципиальные проблемы) и игры обладают собственным интерфейсом, про стандартные компоненты в них можно забыть. Так что перечитайте-как ещё раз название темы и больше не оффтопьте.
Как средство разработки игр для начинающих XNA - очень хороший вариант. Она в первую очередь ведь и рассчитана на студентов и энтузиастов. Я очень сомневаюсь что те, кто сейчас известен такими играми как HalfLife, HalfLife2, Crysis прям с первой попытки писали нечто напоминающее игры с суперсовременной меганавороченной графикой. И вообще, разве графика в играх главное??
Как я и писал - XNA является майкрософтовским вариантом движка "для самых маленьких". К сожалению, эта тема у нас о профессиональном игрострое. Вы же можете идти в тему, например, о Game Maker'е и там доказывать состоятельность XNA как продукта в подобном классе. Тогда у Вас есть неплохие шансы.
pps// то, что в шарпе пишится 1 строчкой кода, на плюсах иногда минимум в 2 строчки выходит.
Зато работает гораздо быстрее, ибо C# вызывает те же самые 2 строчки кода на C++, но через кучу дополнительных функций. Что же касается скорости написания кода - для кого делались библиотеки и директивы препроцессора?
А может напишите, почему? OpenGL (так, на минуточку) - самый быстрый API для трёхмерной графики. А какие преимущества у DX10, на котором XNA построена?
Да кто тебе сказал что ХНА на дх10??? погугли на эту тему хотя бы раз
Про то, кто какой код пишет, Вы абсолютно не в тему. Мы обсуждаем не криворукость отдельных программистов, а достоинства сред разработки/языков/компиляторов/библиотек.
мы обсуждаем это из за вашей твердолобости. Тема топика какая была? правильно, про XNA в играх. а Вы начали тут лечить про утечку памяти
Далее, последнее утверждение демонстрирует Вашу абсолютную некомпетентность в рассматриваемом вопросе. Процессору, конечно, нет разницы, какой код выполнять. Зато юзеру есть разница, что код на C# выполняется Framework'ом, и в нём производится автоматическая сборка мусора в памяти, что вылевается в 35%'ое замедление программ на C# по сравнению с аналогичными на C++. Учите матчасть, уважаемый, прежде чем других в некомпетентности обвинять.
Юзеру абсолютно нет разницы. Прога работает - и ладно. Современные компьютеры достигли таких мощностей, что это как вы говорите "35% замедления" почти не заметно.
Так вот, в .NET таких проблем нет ценой замедления работы программы (см. выше про сборку мусора), а "оптимизация под конечную машину" - это чушь и рекламный трюк Micro$oft. Мне ещё никто толком не смог объяснить, под что там она оптимизируется и каким образом ей это удаётся. Ты плохо знаешь .NET если говоришь так
Как раз для обучения он не подходит в силу отсутствия заботы о памяти. Программист сразу расхолаживается, а потом, когда у него просят написать быстрый код на C++ и появляются те самые утечки памяти - просто потому, что бедняга не привык её очищать.
Ага, тебя через неделю после того как ты начал плюсы изучать попросили написать игровой движок, или субд.
А то, что C++ - эталон в плане ООП, Вы слышали? В C# ООП практически чисто C++'ное.
С++ - набор процедур и функций. так называемое ООП ложится целиком и полностью на плечи программиста.
Шарп - большая библиотека классов. В каждом классе есть свои свойства, методы, делегаты, события. Т.е. с самого начала программист подхватывает этот принцип, что все разложено по полочкам, и он знает что и где искать.
Ага, так и хочется добавить "спонсор статьи - Micro$oft", ибо так оно и есть. Перечитайте только заголовок темы, там немного об играх как бы говорится.
противоречишь себе т.к.
...Мы обсуждаем не криворукость отдельных программистов, а достоинства сред разработки/языков/компиляторов/библиотек.
ты оффтопишь с самого начала топика
Стало быть, Вы утверждаете, что "если для Crysis на C# требуется суперкомпьютер - купите его, это ваши проблемы"? Ну-ну, а теперь идите объяснять это же миллионам пользователям. И что же это злобные игроманцы в своих статьях неимоверно тормозящие игры обругивают... Наверное, не хотят купить компьютер помощнее, не слушают увещиваний Micro$oft'а. Уууу, нехорошие!
Если напишут крайзис на шарпе - в него в любом случае будут играть. И никому не нужно будет этого объяснять. Пусть он на плюсах написан, для него и сейчас требуется суперкомпьютер, однако играет народ.
А про цитатку - этого добра у нас тоже навалом. Вон почитайте Страуструпа где-то в теме.У не воспринимаю культ личности как таковой. Я не знаю этого человека, где то слышал, но не знаю кто такой. Пусть он хоть папа римский будет
Далее, Вы опять забыли, что мы говорим об играх, у которых не бывает моментов простоя программы, ибо игровой цикл бегает постоянно. Так что Вы опять отлично продемонстрировали свою абсолютную некомпетентность в рассматриваемом вопросе.
Сам светишь неграмотностью. Если нет простоя => нет автоматической уборки памяти => делай выводы
Вы хоть поняли, что написали, и что сказал я? Вы целиком подтвердили мои слова, и не опровергли моего утверждения, что отчасти из-за этого программы на C# тормознутие программ на C++. Да, проги на C++ больше размером (этого никто не отрицает), но при современных масштабах, да ещё В ИГРАХ, когда ресурсы занимают несколько гигабайт, прибавление в весе экзешника хоть десятка мегабайт ничего не значит.
Или, может, Вы будете утверждать, что чем программа меньше, тем быстрее она выполняется? Тогда я рассмеюсь Вам в лицо и в который раз отправлю учить матчасть.:lol:
Тормознутость шарпа в том, что у него есть единая библиотека классов?
а чем плюсы лучше? у них ведь тоже mfc есть.
Расскажи пожалуйста по подробнее механизм выполнения программы на шарпе написанной и на плюсах, чтобы я наконец понял каким боком общая библиотека классов замедляет выполнение программы.
А Вы опять не поняли написанного. Учите... ага, именно её, родную, матчасть. Речь идёт о том, что код дизассемблируется в два счёта. Какая система защиты, Вы о чём? Хаккер вскроет Вашу игру и выкинет из неё код вызова любой системы защиты. Или Вы предлагаете, чтобы система защиты динамически распаковывала зашифрованный экзешник на C# при каждом запуске? Первое место в конкурсе "как затормозить игру" присуждается (барабанная дробь!) noLove! Ура, товарищи!
Нет, Вам. Потому что хаккер взламывает вашу программу и пользуется результатами. Итог - хорошо если просто пиратское распространение повсеместное. А если найдена уязвимость похлеще - ждите исков от разъярённых пользователей на возмещение ущерба.
В лицензии моего ПО будет написано "Использование отладчиков и дизассемблеров запрещено. Если контрольная сумма Вашей копии не совпадает с контрольной суммой программы оригинала, разработчик данного ПО не несет никакой ответственности за возможную порчу, или утрату информации, либо другого рода убытки"
Вы опять-таки в тему посмотрите. Мы про игры говорим. Впрочем, на Ваш вопрос я отвечу. Он украдёт все Ваши коммерческие тайны и вытащит наружу все недочёты. В серьёзных компаниях это - многомиллионые убытки. На этот случай люди придумали авторские права. Отсудить эти убытки при желании не составит много проблем. Хотя с нашим законодательством....
А зачем ему что-то менять? Он обнаружит уязвимости, украдёт коммерческие тайны, вытащит на свет божий баги. Какое из этих действий нарушает контрольную сумму?
Кроме того, при чём тут вообще контрольная сумма? Если мы говорим, например, о выкидывании кода защиты, хакер после дизассемблирования Вашего экзешника и выкидывания кода просто-напросто скомпилит экзешник по-новой, и выложит в сеть. При чём тут контрольная сумма? Кто будет проверять неравенство сумм в старом и новом экзешниках, если новый экзешник целиком заменяет старый?
ПО уже написано, и распространяется. Пиратство сейчас оффициально сводится на НЕТ. Придет проверка из налоговой, или ФСБ, что вы им скажете?
Не поверите, я это знаю, т.к. сам писал диплом на тему разработки игр. А вот Вы явно опять не поняли, что я написал. XNA не может всё обрабатывать через шейдеры хотя бы потому, что не всё в этих шейдерах быстро реализуется, и не всё поддерживается. Например, шейдеры до версии 3.0 совершенно не поддерживают циклы. Как Вам такое ограничение? Я уж не говорю, что если вывод всей, абсолютно графики идёт через шейдеры помимо пользователя, то итог - замученный графический процессор, тогда как центральный отдыхает в теньке. В программе всё должно быть сбалансированно, а система тормозит со скоростью самого медленного своего компонента. Вы забыли эту истину.
Пусть видеокарта рендерит картинку. Какая разница, замученная она или нет. Процессору помимо графики своих проблем хватает.
Ну, кросплатформенность у него в пределах Windows (на Линусе - урезанная версия, про приставки я не говорю, т.к. они заведомо тормознутее компа). Код на C++ тоже кроссплатформенный, да будет Вам известно. Только его компилить надо, и учитывать, какие библиотеки где есть. Ну так C# тоже, положим, не без библиотек существует.
Мне такое не слабо, повторюсь, дело в библиотеках. Вся штука в том, что если такое есть на C# - значит возможно и на C++, ибо сам .NET-то не на себе же написан, а на том самом C++. Вот так-то. Значит, везде, где кроссплатформенностью обладает C#, ею будет обладать и C++, вопрос только в получении библиотек (если их M$ прячет, то альтернатив куча) и в компиляции (ну так это не проблема, подождать повторной сборки ради скорости работы).
Какой бы ни был урезаный .NET на *никс системах, рано или поздно он будет полноценным, ибо время идет, люди ведут работы над портированием.
Про приставки. Может быть конфигурация железа у них слабее компа, зато производительность у них бОльше, и не надо здесь пытаться спорить. Хотя бы потому, что Sony и MS очень много денег вложили в исследования в этой области, и им наверняка лучше вас известно, как будет лучше.
Проги написанные на шарпе тоже нужно компилить, но о библиотеках заботится CLR а не программист. Программисту только нужно указать требуемое пространство имен.
Выложите пожалуйста свою какую нибудь программу, самую простую, которая показывает сообщение "Hello world!". Я попробую ее запустить на всех своих девайсах. Запустится она только на ББ, ибо на PPC и Smartphone другая архитектура.
Кстати, среда разработки Microsoft Visual Studio, по крайней мере версии 2005 и выше на шарпе написаны.
Насчёт рефлексии - поясните, что Вы имеете в виду, а то у меня складывается стойкое ощущение как раз того самого "слышал звон..." с Вашей стороны.
При написании программ обычно для каждой задачи создаю свой класс. Например, класс, в котором хранятся все настройки программы. Этих настроек, скажем, пунктов 15. Как в плюсах узнать значение каждой переменной этого класса? А если моя прога вырастит до 50 параметров?
В шарпе код нужно будет написать 1 раз, и не важно, вырастит прога, или наоборот уменьшится.
И что дальше? Приставки, работающие лет по пять на одном и том же железе объективнее медленнее обновляемых компов если не сразу после своего выхода, то уж через полгода после него - точно, даже с учётом всех дополнительных "тормозов" от ОС (которая, надеюсь, всё-таки не Виста) и прочего. Плюс Вы не понимаете, что Framework на XBOX будет требовать примерно такой же универсализации доступа к оборудованию, как и на компьютере. Приставки "относительно быстрее" только за счёт тонкой оптимизации игр под себя, т.ч. и в плане памяти. C# убьёт такую возможность.
Приставки быстрее, потому что им нужно только игровой контент воспроизводить и не беспокоиться о том, что кто то проводит сканирование портов, либо нужно забэкапить документы пользователя, либо нужно распаковывать какие то архивы, либо с бубном танцевать.
Приставки делают то, для чего они были созданы - игры, и не больше
Так что перечитайте-как ещё раз название темы и больше не оффтопьте.
Мастер оффтопа здесь Вы. С самого начала
Как я и писал - XNA является майкрософтовским вариантом движка "для самых маленьких". К сожалению, эта тема у нас о профессиональном игрострое. Вы же можете идти в тему, например, о Game Maker'е и там доказывать состоятельность XNA как продукта в подобном классе. Тогда у Вас есть неплохие шансы.
Эта тема у нас называется "С# и Xna - революция в игросторении".
Зато работает гораздо быстрее, ибо C# вызывает те же самые 2 строчки кода на C++, но через кучу дополнительных функций. Что же касается скорости написания кода - для кого делались библиотеки и директивы препроцессора?
цитата из книги C# и платформа .NET
Программы написанные на C# компилируются не в Win32 Приложения, а в сборку из IL кода. IL код является платформонезависимым. Во время запуска сборки она компилируется в набор платформо-зависимых инструкций. Компилируется при помощи JIT(Just in time compiler). Используя IL код разработчик может не задумываться об особенностях архитектуры конечного компьютера, т.к. эти особенности будут учтены JIT(о чем и говорил нам Knott). Откомпилированные из IL платформо-зависимые инструкции JIT помещаются в кэш памяти, что очень сильно ускоряет работу приложения. Так, например, при первом вызове какого либо метода какого либо класса, JIT откомпилирует IL код, относящийся к этому методу, при повторном обращении к этому методу JIT возьмет его уже из кэша и не будет компилить повторно.
pokibor, все же рекомендую изучить спецификации .NET
Да кто тебе сказал что ХНА на дх10??? погугли на эту тему хотя бы раз
Ммм... дайте подумать... Micro$oft, который всё кричал, что XNA с DX10 будет. Значит, ещё не...? Собственно, с точки зрения моего вопроса до лампочки, ещё на DX9 она или уже на DX10, ибо отличия их (ну, кроме геометрических шейдеров, которые и в OpenGL есть) нужно с лупой искать.
Так я жду описания преимуществ XNA и на чём там она построена над OpenGL.
мы обсуждаем это из за вашей твердолобости. Тема топика какая была? правильно, про XNA в играх. а Вы начали тут лечить про утечку памяти
Так, ещё один переход на личности - и рейтинг поставлю. Про Ваши умственные качества я молчу.Укажите-ка мне мою цитату, которая, якобы, не в тему.
Юзеру абсолютно нет разницы. Прога работает - и ладно. Современные компьютеры достигли таких мощностей, что это как вы говорите "35% замедления" почти не заметно.
Приехали! Юзеру нет разницы, с какой скоростью работает игра. Круто. :lol: Наверное, Вы являетесь счастливым обладателем суперкомпьютера дома.
Выделю. Возможно, устрою опрос согласных с таким утверждением. Ибо я от него укатился под стол.
Ты плохо знаешь .NET если говоришь так
Так соизвольте мне разъяснить мою ошибку. Перечислите пункты оптимизации, ссылочки можете дать. Пока что факты - это 35%'ое замедление, а вот оптимизации что-то не видно. Уж не буду судить о своём знании .NET, но вот плохое знание Вами архитектуры компьютера - доказано (хотя бы вышестоящее утверждение - повторюсь, что же это в Игромании часто ругают игры за тормоза?)
Ага, тебя через неделю после того как ты начал плюсы изучать попросили написать игровой движок, или субд.
Нет, меня потом попросят писать игровой движок или СУБД, а я в работе с памятью ничего не смыслю. Вот тут-то и будет C# обруган, и не раз. У меня есть опыт осваивания Pascal'а после QBasic'а. Скажу честно - лучше бы я это майкрософское убожество не изучал вообще. Ибо долго вникал в тонкости работы с памятью (а в Pascal'е они ещё не чета C'шным!).
С++ - набор процедур и функций. так называемое ООП ложится целиком и полностью на плечи программиста.
Шарп - большая библиотека классов. В каждом классе есть свои свойства, методы, делегаты, события. Т.е. с самого начала программист подхватывает этот принцип, что все разложено по полочкам, и он знает что и где искать.
Вы знаете хотя бы, что такое STL? Подскажу: библиотека классов. Видимо, Вы какой-то не тот C++ изучали, что остальные программисты...
противоречишь себе т.к.
ты оффтопишь с самого начала топика
Нет, я говорю применительно к играм. Если Вы скажете, что "достоинства сред разработки/языков/компиляторов/библиотек" не влияют на разработку игр, то в копилке Ваших замечательных высказываний будет прибавление. Причём достоинства сред разработки и пр. слабо зависят от мастерства программиста, а вот Вы говорите сугубо об индивидуальном мастерстве.
Если напишут крайзис на шарпе - в него в любом случае будут играть. И никому не нужно будет этого объяснять. Пусть он на плюсах написан, для него и сейчас требуется суперкомпьютер, однако играет народ.
Ну-ну, как играть в то, что не запускается либо безбожно тормозит? К сожалению, у не каждый является сыном миллионера, чтобы позволить себе покупать под каждую топовую игру новый суперкомпьютер. Вы хоть задумайтесь, не от нечего делать компании стараются оптимизацией заниматься, а ради расширения круга потребителей.
У не воспринимаю культ личности как таковой. Я не знаю этого человека, где то слышал, но не знаю кто такой. Пусть он хоть папа римский будет
Ага, ну вот тут-то всё и объясняется. Вы верите майкрософтовским рекламным статейкам больше, чем известнейшему в программировании человеку. Верно, это не культ личности. Это культ компании. Конкретной компании с названием Micro$oft.
Сам светишь неграмотностью. Если нет простоя => нет автоматической уборки памяти => делай выводы
:lol:
Кошмар... такого бреда я от Вас не ожидал. Что самое весёлое, написано абсолютно верно. И в очередной раз иллюстриует Вашу вопиющую неграмотность. Ибо отсутствие уборки памяти и есть её утечка.
Тормознутость шарпа в том, что у него есть единая библиотека классов?
а чем плюсы лучше? у них ведь тоже mfc есть.
Прочитайте внимательно мой пост. Тормознутость шарпа в том, что у него
1) автоматическая сборка мусора в памяти либо инициированная программистом, но опять же уборка ВСЕЙ памяти разом
2) интерпретируемый Framework'ом байт-код.
Где хоть одно слово про библиотеку классов?
Расскажи пожалуйста по подробнее механизм выполнения программы на шарпе написанной и на плюсах, чтобы я наконец понял каким боком общая библиотека классов замедляет выполнение программы.
См. выше. Программу на шарпе берёт Framework, тащит из неё байт код и исполняет его, периодически сканя память и очищая из неё всё ненужное.
Программу на C++ исполняет непосредственно процессор, и она сама заботится об уборке своей памяти именно тогда (для каждого отдельного кусочка выделенной памяти), когда это нужно.
В лицензии моего ПО будет написано "Использование отладчиков и дизассемблеров запрещено. Если контрольная сумма Вашей копии не совпадает с контрольной суммой программы оригинала, разработчик данного ПО не несет никакой ответственности за возможную порчу, или утрату информации, либо другого рода убытки"
Обрадую Вас - дизассемблирование программ и без того сейчас запрещено. Однако почему-то хакеров это не слишком останавливает, к играм есть уйма no-cd, тот же World of Warcraft постоянно ломают. А Вы упрощаете хакерам жизнь, т.к. они могут восстановить исходный код на высокоуровневом языке, а не копаться в ассемблере. И если они найдут уязвимость - при чём тут контрольная сумма? Просто в один прекрасный день Ваша программа с той же самой контрольной суммой отформатирует всем пользователям диски.
Я уж не говорю о том, что после каждого выпущенного Вами обновления его просто-напросто будут ломать по новой, и у пользователей всегда будет самая свежая взломанная версия Вашей программы, за которую они не заплатили ни копейки и с которой Вы ничего сделать не сможете, ибо хакер будет знать Ваш код едва ли не лучше Вас самих.
На этот случай люди придумали авторские права. Отсудить эти убытки при желании не составит много проблем. Хотя с нашим законодательством....
Ага, только есть одна маленькая проблема. Как я уже говорил, дизассемблирование противозаконно. А без него Вам трудно будет получить доказательства своей правоты. А доказательства, полученные противозаконным путём, не считаются. Вот так вот. И с суда Вас выгонят в шею, я уже не говорю о том, что одно малюсенькое изменение Вашего кода - и укравший Ваши секреты вообще оставит Вас с носом даже при наличии законного разрешения на дизассемблирование.
ПО уже написано, и распространяется. Пиратство сейчас оффициально сводится на НЕТ. Придет проверка из налоговой, или ФСБ, что вы им скажете?
По домам ходит ФСБ, ищет пиратские копии игр? Пойду им чайку приготовлю. :lol:
Пусть видеокарта рендерит картинку. Какая разница, замученная она или нет. Процессору помимо графики своих проблем хватает.
Разница в том, что система тормозит со скоростью самого медленного своего компонента. Если видеокарта нагружена сейчас, когда она обрабатывает не всю информацию для визуализирования - потом она и будет самым слабым местом в система. Вот смотрите: сейчас есть графические ускорители, поговаривают о необходимости физических и ускорителей AI (стало быть, не хватает на них ресурсов процессора). А теперь внимание, вопрос: чем же таким требовательным к ресурсам процессор занимается ещё, помимо графики, физики и AI, если играм потенциально нужен аж такой комплект ускорителей? Вот и думайте, хватает процессору проблем помимо графики или нет.
Какой бы ни был урезаный .NET на *никс системах, рано или поздно он будет полноценным, ибо время идет, люди ведут работы над портированием.
Скажите, когда выйдет DirectX под Linux? Я что-то вообще не слышал, чтобы M$ как-то поддерживала Linux, ибо M$ это невыгодно. Следовательно, полноценного .NET под *nix не появится никогда.
Про приставки. Может быть конфигурация железа у них слабее компа, зато производительность у них бОльше, и не надо здесь пытаться спорить. Хотя бы потому, что Sony и MS очень много денег вложили в исследования в этой области, и им наверняка лучше вас известно, как будет лучше.
Я уже написал за счёт чего у них производительность кажется больше. Жду конкретных возражения. И по поводу того, что .NET требует универсальности - тоже.
Проги написанные на шарпе тоже нужно компилить, но о библиотеках заботится CLR а не программист. Программисту только нужно указать требуемое пространство имен.
Выложите пожалуйста свою какую нибудь программу, самую простую, которая показывает сообщение "Hello world!". Я попробую ее запустить на всех своих девайсах. Запустится она только на ББ, ибо на PPC и Smartphone другая архитектура.
Кстати, среда разработки Microsoft Visual Studio, по крайней мере версии 2005 и выше на шарпе написаны.
А Вам трудно перекомпилить один код с подключением разных библиотек, чтобы получить выигрыш в 35% скорости? :eek:
Среда программирования майкрософтовская, так что не удивительно. И не показательно, ибо оболочка среды программирования - это как раз категория далеко не требовательного к ресурсам ПО. Вот когда 3D MAX, например, на шарпе напишут - поговорим.
При написании программ обычно для каждой задачи создаю свой класс. Например, класс, в котором хранятся все настройки программы. Этих настроек, скажем, пунктов 15. Как в плюсах узнать значение каждой переменной этого класса? А если моя прога вырастит до 50 параметров?
В шарпе код нужно будет написать 1 раз, и не важно, вырастит прога, или наоборот уменьшится.
И что, я не совсем понимаю? Вы что ли variant-переменные имеете в виду? Ну так под C++ они тоже есть. Или что-то ещё? Поконкретнее, пожалуйста, в чём Вы видите недостаток C++. В класс новые члены спокойно можно добавить.
Приставки быстрее, потому что им нужно только игровой контент воспроизводить и не беспокоиться о том, что кто то проводит сканирование портов, либо нужно забэкапить документы пользователя, либо нужно распаковывать какие то архивы, либо с бубном танцевать.
Приставки делают то, для чего они были созданы - игры, и не больше
И что? Где тут возражение против требуемой Framework'ом универсализации доступа и отсутствия возможности оптимизации по памяти? А ведь при такой программы нельзя выжать из приставки все соки...
Мастер оффтопа здесь Вы. С самого начала
Доказательства? А то ж я это могу как клевету расценить. Только в лику или можете жалобу на меня подать с обоснованием.
Эта тема у нас называется "С# и Xna - революция в игросторении".
Вот именно. Никакой революцией ни C#, ни XNA не являются. Движков "для самых маленьких" достаточно, и ещё один продукт среди них - это не тянет на революцию (а "Революция (от позднелат. revolutio — поворот, переворот, превращение, обращение) — глобальное качественное изменение в развитии природы, общества или познания, сопряжённое с открытым разрывом с предыдущим состоянием.")
цитата из книги C# и платформа .NET
Ммм... И что это доказывает?
Это лишь говорит, что приложение собирается во время работы! При том, что код на C++ уже собран. Нет, я бы понимал, если бы код на C# на конечной машине сразу преобразовывался в набор платформенно-зависимых инструкций (честно говоря, я понимал слова Knott'а так). Но приведёная Вами цитата только показывает лишние тормоза в процессе, не более того. Кэш-то у нас не резиновый, а игре на каждой итерации игрового цикла нужно выполнять целый спектр действий. Иными словами, приведёная Вами цитата только показывает, что C# на игры не рассчитан вообще, а более-менее подходит лишь для небольших приложений, часто выполняющих одни и те же методы.
Я уж не говорю, что программа на C++ изначально собрана и ей никакого кэша с платформенно-зависимым кодом не требуется - он и так весь платформенно-зависимый.
pokibor, все же рекомендую изучить спецификации .NET
А Вам рекомендую изучить работу компьютера вообще и исполнение кода Framework'ом в частности.
Soder Dionis
18.12.2007, 22:36
Knott, не спорь со стариками, у них опыта много больше... Ты то, что говоришь откуда знаешь? В книжках прочитал, или в инете... Если ты считаешь, что программисты, которые практикуются уже десят лет читали меньше тебя, или вообще ничего не читали, ты глубоко ошибаешься... Они видели то, что не видел ты... Лучше используй их как учителей, а потом...
В любом случае, тов. Knott прав.
Ни для кого не секрет, что XNA разрабатывается с упором на разработчиков любителей\энтузиастов и студентов. Начинать программирование с простого , и постепенно переходя к сложному - это очень хорошая тактика. XNA отлично подходит для нее
В любом случае, тов. Knott прав.
В чём? В том, что C# и XNA - революция в игрострое? Вы так и не показали, в чём его революционность.
Ни для кого не секрет, что XNA разрабатывается с упором на разработчиков любителей\энтузиастов и студентов. Начинать программирование с простого , и постепенно переходя к сложному - это очень хорошая тактика. XNA отлично подходит для нее
Как уже было показано, для программирования сложных приложений, кушающих ресурсы по-максимуму, XNA не подходит в силу своей тормознутости. Профессиональный геймдевелопинг XNA не изменит, пусть хоть все любители поголовно перейдут на неё, ибо издатели будут требовать и красивую графику, и корректную физику, и хорошую скорость работы одновременно. Пользующиеся XNА'ой энтузиасты просто-напросто будут вынуждены перейти на C++ под ударани судьбы в их лице. Так в чём там революционность XNA, ещё раз спрашиваю?
Feanor62rus
20.12.2007, 21:23
Ух... чет я в эту тему раньше не заходил. Честно сказать всю тему так и не осилил прочитать в силу жуткого обилия оверквотинга.
Как я понял, в общих чертах, тут ктото пытается доказать pokibor'у о том, что C# и XNA является жутко революционной и крутой штукой? Если так, то у вас ниче не получится. Ну хотябы по тому, что он железобетонно прав. C# проигоывает С++ добрые 30% производительности, и хоть ты усрись, но ниче с этим поделать нельзя. Утверждения о том, что эти 30% никому не нужны просто смешны. Насчет XNA я не уверен, поживем - увидим. Но слишком уж это похоже на желание Microsoft срубить бабла. Я считаю, что чем проще среда, тем она менее функциональна и на ней труднее сделать чтото действительно сложное. Хотя я сам щас работаю на C#, но мы то пишем по сути не сложные офисные приложения, там C# действительно удобнее и разница в производительности не так заметна. Но использовать это для игр - извращение. Хотя как первый этап в игрострое для молодого студента, может и сойдет.
pokibor а ты пробовал XNA на вкус?
JITter кэширует все вызовы методом, так что поначалу может ты и заметишь какие нибудь тормоза, в чем я сомневаюсь, но в дальнейшем - он будет работать с такой же скоростью как и твой любимый плюсплюс
вот здесь (http://www.vestace.ru/Default.aspx?tabid=54&ctl=Details&mid=374&ItemID=46) наглядно расписана эта твоя фобия про GC.
Ты играешь в игры в бэкграунде, или в спящем режиме компа? можт научишь?
pokibor - модератор мог бы вести себя по скромнее ;)
XNA и C# - действительно революция. И я уверен, что в скором времени крупные конторы перейдут именно на XNA. Утверждение что C# прямо таки сильно отстает от С++ - неверно. Учитывайте факт о том, сколько десятков лет совершенствовались компиляторы С++'ные и сколько C# - это раз, второе: оптимизация .Net, действительно существует. Воть:being a professional C# programmer since .Net 1.0 Beta I can tell you a few tidbits about Managed code and C# compared to native C++.
When working with out-of-the-box namespaces in C#, you come across a lot of iterators. Iterators create clones of objects (a pointer object pointing to the real object) to be used in loops and such. By eliminating the need for LinkedList<T> and the like, you can achieve code speeds that are very close to C++. You can go even further if you know what you are doing and give into the world of pointers in C# to make it EQUALLY AS FAST AS C++.
I've written a Motion Capture Detection system using C# and in C++ (originally in C++) and I acheieve the SAME performance in C# (using pointers in unsafe code) as I do in C++.
Like many people have stated above. The speed decrease in Managed code lies in the fact that .Net has to get a pointer to the object to be used in the Managed Memory pools. Getting these pointers can be costly for high-performance code and would be better left to you.
A List<Model> is slower to iterate through than an unsafe { List<Model*> } however, you can really damage your system if you don't take care of your pointer objects or mess up on pointer math. Use with caution. This is how I am able to manage over 4,000 models at ~1200 poly each on screen in my game engine (running at 900fps with vsync off and all that jazz).XNA, крутая вещь только в прямых руках. Пара бенчмарков C#:
http://www.grimes.demon.co.uk/dotnet/man_unman.htm
http://www.osnews.com/story.php/5602/Nine-Language-Performance-Round-up-Benchmarking-Math-and-File-IO/page3/
http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx
Нужно время, чтобы на XNA начали делать действительно быстрые игры. Должно сложится правильное мнение "как" именно делать игры на .Net. XNA не подходит в силу своей тормознутости. Вы мне покажите тесты, доказывающие это. Словами я бросаться тоже умею. C# уже вплотную подходит к С++. Разница в скорости, в среднем, 3-5%. Но никто не отбирает у вас права оптимизировать. Но только не забывайте, что используя C# вы получаете комфорт, простоту, быстроту разработки. Просто на С++ прогят профи, вот и выходят такие крутые игры, да и материала полно. Так что утверждая что-то, у вас быть должно что нибудь, закрепляющее это.
Feanor62rus
20.12.2007, 22:11
Просто на С++ прогят профи, вот и выходят такие крутые игры, да и материала полно.
А как будто профи делать больше нечего, кроме как сидеть в неудобной и непонятной среде? Вот они и не слазят с С++ именно из за его скорости.
Был бы C# действительно так быстр, как ты утверждаешь, то профи давным давно бы сидели на нем, однако же этого не произошло. http://www.grimes.demon.co.uk/dotnet/man_unman.htm
http://www.osnews.com/story.php/5602...File-IO/page3/
http://blogs.msdn.com/ricom/archive/...ry-reader.aspx
Где тесты в 3D приложениях?
Кстати в одном из тестов есть:
___________________double math
Visual C++___________6.4
Visual C#____________17.7
Это довольно важно в 3D и как видим тут просто пропасть.
pokibor а ты пробовал XNA на вкус?
У меня достаточно опыта, чтобы понять недостатки XNA, не пробуя её на вкус. Вы, надо думать, на C++ игр тоже не писали. А вот я - писал дипломный проект.
JITter кэширует все вызовы методом, так что поначалу может ты и заметишь какие нибудь тормоза, в чем я сомневаюсь, но в дальнейшем - он будет работать с такой же скоростью как и твой любимый плюсплюс
Это - бред в случае игры, и выше я написал, почему. Впрочем, даже если он закэширует весь код программы, и пусть даже этот код будет оптимизирован по полной - он не достигнет результата C++ из-за уборки мусора.
здесь (http://www.vestace.ru/Default.aspx?tabid=54&ctl=Details&mid=374&ItemID=46) наглядно расписана эта твоя фобия про GC.
Спасибо. Отличная ссылка. Особенно мне понравилась фраза, смысл которой Вы, судя по всему, не поняли:
Операция сборки мусора достаточно дорогостоящее удовольствие. Во время ее выполнения все потоки приложения приостанавливаются.
То есть играете Вы в Quake, и тут - раз! - потоки приостановились, ибо мусорок решил кто-то убрать. Пусть даже на десятую долю секунды (а ведь программа памяти мнооого кушает! По 512 метрам поди пройдись, а тот же Кризис 3 гига жрёт, как Вы же говорили...). Но, как знают игроки, подобный тормоз не просто глаза режет - он смерти подобен. Ибо за эти доли секунды средней руки снайпер из вас отбивную сделает. Занавес.
Ты играешь в игры в бэкграунде, или в спящем режиме компа? можт научишь?
А у Вас привычка - задавать странные вопросы? Ибо вопрос этот ничего общего к моим постам не имеет. Если Вы что-то не поняли (а опыта у Вас, как я уже понял, нет) - спрашивайте прямо.
JohnK, Вы, как и noLove, не можете понять одной вещи: игры - приложения специфические. C# может не отставать от С++ в офисных программах, он даже может делать его в специально оптимизированных тестах - но в играх он будет безнадёжно отставать. Почему - почитайте хотя бы http://www.rsdn.ru/article/devtools/perftest.xml.
Посмотрите на тест с древовидной сортировкой (Tree sort). Вот где выходит наружу наличие в C# сборщика памяти.
Процитирую:
В новые языки/платформы типа C# и Java встроены модные ныне «сборщики мусора». Это программные сущности, призванные радикально ускорить выделение и освобождение небольших кусков памяти (так присущих ООЯ). Нам говорят примерно следующее: GC (сокращение от Garbage Collector) вообще не занимается лишним освобождением памяти. Вернее, он пытается отложить этот неприятный (для него) момент на как можно более поздний срок. Т.е. пока есть свободная память, ее будут занимать, занимать и занимать, а когда память иссякнет, или когда процессор будет менее загружен, начнется процесс сборки мусора.
Давайте даже представим, что это всё реализовано идеально и без ошибок. Но ёлки-палки! Нынешние игры жрут по 2-3 гигабайта памяти, когда же Вы это поймёте! В них память всегда будет висеть рядом с пределом, а сборщик будет постоянно (подчёркиваю - постоянно! Т.к. память висит у предела) бегать по этим трём гигабайтам (!!!) и пытаться там что-то освободить.
Только из одного этого примера видно, что для игр C# не подходит в принципе, и если у Вас нет чего возразить именно на ситуацию со сборкой памяти (а это вывод, подчеркну, из заявления о работе сборщиков, т.е. именно того, что должно быть в идеале), то уж признайте - написанные на C# Crysis и иже с ним будет тормозить безбожно просто потому, что постоянно будет пахать сборщик памяти.
В C++ же есть возможность оптимизации по памяти, inline-функции и соответствующая оптимизация и т.п., чего в C# просто быть не может.
Я не исключаю, что в простых приложениях с объёмом памяти в 50-100 мегабайт C# будет не уступать C++, и плевать даже на ситуацию с double math преснопамятным (хотя, как верно заметил Feanor62rus, все 3D-вычисления именно таковыми и являются). Но чисто из-за огромной потребности профессиональных игр в памяти сборщик мусора для них является катастрофой и гигантским тормозом.
Если Вы этого не понимаете - Вы не знаете азы программирования, а делаете поверхностные выводы из статей, даже не задумываясь над их содержанием.
У меня достаточно опыта, чтобы понять недостатки XNA, не пробуя её на вкус. Вы, надо думать, на C++ игр тоже не писали. А вот я - писал дипломный проект.
напиши на заборе об этом, чтобы стать реально крутым, здесь я только понты вижу, и ни бОльше. Сейчас куча народу поступает в универы на пристрижные специальности типа информационных технологий, автоматизация, и т.д. и лишь единицы из этих выпускников реально что то могут.
Спасибо. Отличная ссылка. Особенно мне понравилась фраза, смысл которой Вы, судя по всему, не поняли:
Операция сборки мусора достаточно дорогостоящее удовольствие. Во время ее выполнения все потоки приложения приостанавливаются.
То есть играете Вы в Quake, и тут - раз! - потоки приостановились, ибо мусорок решил кто-то убрать. Пусть даже на десятую долю секунды (а ведь программа памяти мнооого кушает! По 512 метрам поди пройдись, а тот же Кризис 3 гига жрёт, как Вы же говорили...). Но, как знают игроки, подобный тормоз не просто глаза режет - он смерти подобен. Ибо за эти доли секунды средней руки снайпер из вас отбивную сделает. Занавес.
А у Вас привычка - задавать странные вопросы? Ибо вопрос этот ничего общего к моим постам не имеет. Если Вы что-то не поняли (а опыта у Вас, как я уже понял, нет) - спрашивайте прямо.
А ты явно статью до конца не дочитал. Там вроде ясно расписаны моменты, провоцирующие запуск GC.
А чтобы память не забивалась то ее тоже ручками освобождать можно, никто не мешает это делать
напиши на заборе об этом, чтобы стать реально крутым, здесь я только понты вижу, и ни бОльше. Сейчас куча народу поступает в универы на пристрижные специальности типа информационных технологий, автоматизация, и т.д. и лишь единицы из этих выпускников реально что то могут.
Повторите это сто раз, и у Вас поднимется самооценка. К сожаление, пока что конкретных возражений на прямые аргументы я от Вас не слышу. Вы только и можете что говорить "прочитайте". Так что же Вы сами-то не можете ответить на мои вопросы? Возможно, Вы не поняли статей и надеетесь, что я сам найду в них ответ на свои вопросы? Спешу расстроить - пока что я там нахожу лишь подтверждение своей правоты.
А ты явно статью до конца не дочитал. Там вроде ясно расписаны моменты, провоцирующие запуск GC.
Нет, я-то статью до конца и внимательно прочитал. Это Вы не понимаете, что любой вызов GC - это тормоз, а не вызов GC - это утечка памяти.
Я же лишь констатирую - Вам не хватает то ли логики, то ли знаний для конкретного спора.
А чтобы память не забивалась то ее тоже ручками освобождать можно, никто не мешает это делать
О-па! Очередная ошибка. Проблема-то не в ручном/автоматическом освобождении, а в том, что попытка освобождения памяти затрагивает её всю. Какая разница, три гигабайта будут пробегаться по ручному вызову раз в пять секунд, или четыре автоматически - раз в десять секунд?
Если бы в C# была возможность ручного удаления объектов... но вот незадача - тогда мы теряем так возносимое Вами отличие от C++, и постепенно превращаем C# чуть ли не в его аналог.
этот GC вызывается в тех случаях, которые описаны в статье, 3 и 4 пункты - это криворукость программиста.
А удалять объекты в шарпе никто не запрещал, GC здесь не при чем
На каком основании вы мне минус в репутации сделали? Слишком умный чтоли? Вот и показал какой ты модер.
Я вижу сборщик мусора - это единственный контр-аргумент. Так вот, многие уже давно научились делать так, чтоб провоцировать его вызовы как можно реже, если этого не умеете делать вы - примите мои собалезнования. Тем более XBOX360 имеет никакующий сброщик, вот и приходится аккуратно писать.
noLove
Сколько раз Вам повторять, чтобы Вы поняли? C# - это тот самый GC. Он записан в спецификации. Всё остальное - это, извините, unsafe. А unsafe - это C++. Какое у C# будет преимущество перед C++, если писать unsafe-коды, не подскажите?
Проблема не в том, когда вызывается GC, а в том, что когда он это делает, он пробегается по целым 3-4 гигам памяти и её чистит. А в Вашей же статье написано, что все остальные потоки на это время приостанавливаются... То есть и рендеринг, и физика, и AI. Привет, тормозам.
На каком основании вы мне минус в репутации сделали? Слишком умный чтоли? Вот и показал какой ты модер.
Есть одна проблема - репутация не имеет отношения к функциям модератора (чай, не предупреждение). А поставил за конкретное непонимание основ программирования. И вообще вынос подобных обсуждений в тему - флуд. Вот за него-то можно и рейтинг при желании влепить. А если не нравится, как я модерю - прошу отписать супермодерам, чтобы они меня приструнили.
Я вижу сборщик мусора - это единственный контр-аргумент.
Наверное, единственный, который Вы увидели или по которому у Вас есть что сказать. Вторым по серьёзности идёт double math - чуть выше написано. А дальше ещё много чего можно вставить. Принципиальное отсуствие inline'ов, например. Когда язык донельзя виртуализирован - это весело, я вам скажу.
Так вот, многие уже давно научились делать так, чтоб провоцировать его вызовы как можно реже, если этого не умеете делать вы - примите мои собалезнования.
И Вы туда же... Повторяю ещё раз для особенно внимательно читающих: не вызов сборщика - это утечка памяти. Вызов сборщика - это тормоз, ибо в игре он бегает через три-четыре гига. Ну научитесь вы его вызывать как можно реже, и что? Раз в минуту у Вас квейк будет на секунду полностью останавливаться. Вместо того, чтобы раз в полминуты останавливаться на полсекунды. Разница-то какая? Тормоза и так, и так будут. А баталия, допустим, online. И попробуйте игроку объяснить, что такое сборщик мусора и почему их убили из-за тормоза в тот момент, когда он этот мусор собирал.
Тем более XBOX360 имеет никакующий сброщик, вот и приходится аккуратно писать.
Вы сами себе противоречите. Вы фактически сейчас казали, что XBOX не поддерживает спецификацию .NET. Учитывая, GC есть даже в мобильных устройствах (см. статейку noLove), могу с уверенностью заявить - Вы ошибаетесь.
noLove
Сколько раз Вам повторять, чтобы Вы поняли? C# - это тот самый GC. Он записан в спецификации. Всё остальное - это, извините, unsafe. А unsafe - это C++. Какое у C# будет преимущество перед C++, если писать unsafe-коды, не подскажите?
XNA для .NET только :Ъ
да и к тому же писать на шарпе горадо приятнее. КОд получается легко читаем и легко усвояем
Проблема не в том, когда вызывается GC, а в том, что когда он это делает, он пробегается по целым 3-4 гигам памяти и её чистит. А в Вашей же статье написано, что все остальные потоки на это время приостанавливаются... То есть и рендеринг, и физика, и AI. Привет, тормозам.
а ты сам веришь в то что написал? я лично нет. Любую игру сверни, а потом переключись на нее, она тоже будет тупить.
А чтобы не провоцировать GC еще раз повторяю, ненужные объекты нужно удалять ручками. GC при этом не сработает
могу с уверенностью заявить - Вы ошибаетесь.
могу с уверенностью заявить что ты не знаешь о чем говоришь
XNA для .NET только :Ъ
да и к тому же писать на шарпе горадо приятнее. КОд получается легко читаем и легко усвояем
Опять двадцать пять... По второму кругу пошли. Код может умещаться хоть в одну строчку, но излишних потребностей в памяти и тормознутости это не изменит.
Я сейчас нашёл одну статейку про разработку игр на XNA. Так вот, там единственный аргумент в её пользу состоял как раз таки в том, что код на ней, видите ли, получается короче. Ну так код с использованием движка (напр. Irrlicht) получается столь же коротким и понятным. И что дальше?
P.S. При заходе на третий круг у меня лопнет терпение и я просто буду удалять уже рассмотренные вещи.
а ты сам веришь в то что написал? я лично нет. Любую игру сверни, а потом переключись на нее, она тоже будет тупить.
А чтобы не провоцировать GC еще раз повторяю, ненужные объекты нужно удалять ручками.
Верю, иначе бы не писал. А вот Вы то ли не можете, то ли не хотите понять написанного. При чём тут "сверни/разверни"? Я говорю о том, что вызов GC будет пробегать по 3 гигам памяти и без всяких сворачиваний тормозить игру непосредсвенно в её процессе.
При удалении объектов вручную, ещё раз повторяю, код будет unsafe и мало чем отличаться от C++'ого кроме отсуствия оптимизации. В чём тогда преимущество C#? Какая мне разница, выделять и очищать память на C++ или делать то же самое на C#?
могу с уверенностью заявить что ты не знаешь о чем говоришь
Ну так объясните мне, чего я не знаю. Кажись, M$ заявлял, что программы на C# и XNA будут на XBOX работать. Но как же они могут работать, если на PC есть GC и его можно использовать, а на XBOX его нет? :eek:
А поставил за конкретное непонимание основ программированияА не много ли на себя берете? Вы сами себе противоречите. Вы фактически сейчас казали, что XBOX не поддерживает спецификацию .NET. Учитывая, GC есть даже в мобильных устройствах (см. статейку noLove), могу с уверенностью заявить - Вы ошибаетесь.Может вы сначала ознакомитесь с программированием на XNA? У хкоробки есть сборщик, просто он вызывается очень часто, поэтому приходится писать аккуратно ( читай не мусорить ) и удалять некоторые объекты самостоятельно.При удалении объектов вручную, ещё раз повторяю, код будет unsafe и мало чем отличаться от C++'ого кроме отсуствия оптимизацииКакой еще unsafe? object.Dispose(); - и всё тут. Повторю еще раз: то, что вы пробовали XNA/C# год - два назад не означает, что ничего не изменилось.
Опять двадцать пять... По второму кругу пошли. Код может умещаться хоть в одну строчку, но излишних потребностей в памяти и тормознутости это не изменит.
Я сейчас нашёл одну статейку про разработку игр на XNA. Так вот, там единственный аргумент в её пользу состоял как раз таки в том, что код на ней, видите ли, получается короче. Ну так код с использованием движка (напр. Irrlicht) получается столь же коротким и понятным. И что дальше?
этот ваш ирич - готовый движок, или полуготовый. хна - нет, это даже не движок. это набор пространств имен и классов.
Верю, иначе бы не писал. А вот Вы то ли не можете, то ли не хотите понять написанного. При чём тут "сверни/разверни"? Я говорю о том, что вызов GC будет пробегать по 3 гигам памяти и без всяких сворачиваний тормозить игру непосредсвенно в её процессе.
А при том что просто так GC Тоже не врубается. Такого не будет, что сидиш играешь в кваку, и он врубился до тех, пока ты его сам не попросишь, или пока не произойдет одно из описанных четырех событий.
При удалении объектов вручную, ещё раз повторяю, код будет unsafe и мало чем отличаться от C++'ого кроме отсуствия оптимизации. В чём тогда преимущество C#? Какая мне разница, выделять и очищать память на C++ или делать то же самое на C#?
ты такой умный, а ты знаешь что такое IDisposible?
этот ваш ирич - готовый движок, или полуготовый. хна - нет, это даже не движок. это набор пространств имен и классов.
О-па! Так-так-так! Ну-ка, объясните-ка мне тогда, что такое движок, почему Irrlicht - готовый движок, а XNA - нет. :lol:
Ибо Irrlicht это как раз и есть, говоря Вашим языком, набор пространств имён (irr; irr::core; irr::gui; irr::io; irr::scene; irr::video) и классов/интерфейсов (IrrlichtDevice, IVideoDriver, ISceneNode, vector3d ...).
Уж тут то не надо пытаться со мной спорить, ибо я на Irrlicht писал, а Вы его, судя по всему, в глаза не видели.
Если Вы думаете, что Irrlicht - это конструктор по типу GameMaker'а, то крупно заблуждаетесь.
А при том что просто так GC Тоже не врубается. Такого не будет, что сидиш играешь в кваку, и он врубился до тех, пока ты его сам не попросишь, или пока не произойдет одно из описанных четырех событий.
В том-то и дело, что одно из этих событий - переполнение памяти. А игры (я уже писал Выше, но Вы не поняли!) играются на близкой к предельной памяти, и быстрое её жрут (постоянно нужно грузить что-то новое или изменять старое). Иными словами, этот самый сборщик будет врубаться часто и со вкусом. Я уж не говорю о том, что вся доступная память компьютера будет быстро сжираться игрой до последнего мегабайта.
ты такой умный, а ты знаешь что такое IDisposible?
ООО, Вы хоть по C# хелп читали (кстати, Вы ещё и название интерфейса неправильно написали. Оно через 'a' пишется)? Процетирую MSDN:
IDisposable Interface
Defines a method to release allocated unmanaged resources.
...
The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used, however, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.
Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed.
Этот Ваш интерфейс IDisposable обеспечивает уничтожение не относящихся с GC объектов, таких как дескрипторы открытых файлов, потоков, окон. ВСЁ! К освобождению выделенной под класс памяти он не имеет ни малейшего отношения, она всё равно убирается GC.
Мда... И Вы ещё обвиняете меня в незнании C# и XNA... А то что прямым текстом в MSDN написано, не прочитали.
Уж разрешите поправлю коллегу. Он, кстати вполне прав, но раз уж вы так придирчевы, то знайте: XNA это фреймворк, т.е. не GAPI, но и не двиг. А про ирлича вы отожгли, тов. модератор.В том-то и дело, что одно из этих событий - переполнение памяти. А игры (я уже писал Выше, но Вы не поняли!) играются на близкой к предельной памяти, и быстрое её жрут (постоянно нужно грузить что-то новое или изменять старое). Иными словами, этот самый сборщик будет врубаться часто и со вкусом. Я уж не говорю о том, что вся доступная память компьютера будет быстро сжираться игрой до последнего мегабайта.Сыграйте в XNARacer например, может вы перестаните нести подобный бред. Всё печетесь о каких то тормозах при переборе гигов памяти - на игре ясно видно.Этот Ваш интерфейс IDisposable обеспечивает уничтожение не относящихся с GC объектов, таких как дескрипторы открытых файлов, потоков, окон. ВСЁ! К освобождению выделенной под класс памяти он не имеет ни малейшего отношения, она всё равно убирается GC.Без комментариев. :lol:
Уж разрешите поправлю коллегу. Он, кстати вполне прав, но раз уж вы так придирчевы, то знайте: XNA это фреймворк, т.е. не GAPI, но и не двиг.
А про ирлича вы отожгли, тов. модератор.
XNA - такой же фреймворк, как Irrlicht - компилятор. Это, как достаточно верно выразился noLove, суть есть надстройка над DirectX в своей графической части, набор классов. Irrlicht - то же самое: библиотека, содержащая набор классов и функций для облегчения написания игровых приложений. Не более того.
Если Вы возражаете, распишите-как по-подробнее отличия XNA от Irrlicht. Кроме того, что Irrlicht позволяте писать как под C++, так и имеет .NET-версию, в отличие от чисто .NET'ной XNA.
Сыграйте в XNARacer например, может вы перестаните нести подобный бред. Всё печетесь о каких то тормозах при переборе гигов памяти - на игре ясно видно.
Простите, XNARacer - это вершина игростроя, по-Вашему? Мы тут, если Вы не в теме, говорим о революции в игростроении. Что на XNA можно делать игры вроде бы никто и не возражал. А вот что на ней можно делать топовые игры - очень даже. Сыграйте в Crisys. Он, как заявил noLove (так что претензии к нему, а не ко мне) 3 гига памяти требует. И посмотрите результаты провала C#'а в Tree Sort'е по приводимой мной ссылке выше, и их обоснование. Вот поэтому-то я и говорю и тормозах C# и гигах памяти.
А то так и я могу тетрис на Прологе написать и говорить Вам: "Смотрите! Он работает без тормозов на передовом Пне/Атлоне! Prolog - вот лучший язык для игростроя! Все переходим на него!"
Без комментариев. :lol:
Уж извольте прокомментировать. Этот текст взят из MSDN. Что такое MSDN и кто его писал Вы, надеюсь, знаете. А там прямо написано: "Defines a method to release allocated unmanaged resources." И что относится к unmanaged resources, там тоже написано: "unmanaged resources such as window handles, or open files and streams". Возражения? Сошлётесь на ошибку в MSDN?
Сейчас по-подробнее прочитал про IDisposable - чуть со стула со смеху не свалился. Я то по простоте душевной думал, что он только для определённого класса объектов. Оказалось - нет, M$ расщедрилась на возможность сделать класс unmanaged. После чего мы, правда, терям все достоинства автоматической сборки мусора, взамен получая кучу проблем.
Начнём с того, что наследование от IDisposable требует нехилых трудозатрат, т.к. нужно вручную вызывать Dispose() всех предков и обрабатывать все исключения, которые ими возвращаются, да ещё и необходимо ручками прописывать работу с любым классом, являющимся unmanaged.
Далее, если есть два класса - один unmanaged, другой - managed и они как-то связаны (а в игре все объекты тесно связаны) - то всё очень-очень печально, ибо проверки прописывать замучаешься. Значит, половину игры нужно делать unmanaged. При том, что долбаний с Dispose куча (не в пример нормальным деструкторам в C++).
Итог?
1) IDisposable порождает проблемы похлеще, чем C++'ные деструкторы, т.е. ухудшает код по сравнению с C++ (кто там хвастался, что на C# код понятнее?)
2) Он не даёт никаких преимуществ по сравнению с C++, зато убивает преимущества GC
3) Его нужно везде прописывать ручками. При этом замечу, что автоматическая сборка памяти всё равно никуда не девается и исправно жрёт свои ресурсы. Хотя бы на определение, а есть ли ей смысл сейчас вызываться (т.е. производительность всё равно страдает).
Такими темпами мы придём к необходимости писать на C# в стиле C++. Вперёд! Осталось совсем немного - признать необходимость юзания unsafe-кода (хотя unmanaged - это по сути и есть unsafe, ибо он опасен утечкой всех unmanaged ресурсов, которые C#-писатели освобождать не привыкли).
Я в шоке... Сейчас почитал про реализацию GC - ещё на пару минут жизнь себе продлил. Он-то, оказывается, реализован очень-очень грамотно. Он не считает ссылки на объект, а по дереву объекты обходит. И объект не нужен, если его нельзя достичь из корневого узла. А это ещё какое замедление алгоритма, особенно в сложных приложениях вроде игр, где дерево имеет кучу длинных ветвей...
P.S. Если что - реализация грамотная без сарказма (если реализовывать иным образом - то объект спокойно может "потеряться", к примеру, если сам на себя ссылается). Вот только опять же для сложных приложений плохо подходящая.
[CCCP] Monster
21.12.2007, 12:00
А не много ли на себя берете?
Нет, не много. Репутация является зеркалом того, как другие пользователи относятся к вашей персоне. Если вы пишете откровенную ерунду, либо не понимаете с первого раза, или просто своими постами вызываете отрицательные эмоции, пользователи вполне могут высказать свое отношение к вам с помощью репутации. Участвуя в дискуссии, модератор работает, как обычный пользователь, и поэтому вполне может поставить вам плюс или минус в репутацию, как любой другой пользователь на этом форуме, если сочтет нужным. ПОэтому в данном случае претензии безосновательны. На этом думаю оффтоп закончить.
Без комментариев.
Даже если бы они были, что вы собрались комментировать? Человек привел вам отрывок из MSDN, выделил главное, перевел на русский. Вы ставите пометку "без комментариев" к официальной документации?
О-па! Так-так-так! Ну-ка, объясните-ка мне тогда, что такое движок, почему Irrlicht - готовый движок, а XNA - нет. :lol:
Ибо Irrlicht это как раз и есть, говоря Вашим языком, набор пространств имён (irr; irr::core; irr::gui; irr::io; irr::scene; irr::video) и классов/интерфейсов (IrrlichtDevice, IVideoDriver, ISceneNode, vector3d
...).
Уж тут то не надо пытаться со мной спорить, ибо я на Irrlicht писал, а Вы его, судя по всему, в глаза не видели.
Если Вы думаете, что Irrlicht - это конструктор по типу GameMaker'а, то крупно заблуждаетесь.
если ты думаешь что XNA - конструктор по типу GameKakera тоже ошибаешься. в ХНЕ нету готовых классов игры, там нету классов гуя, сцены и прочего, там это все самому писать надо.
В том-то и дело, что одно из этих событий - переполнение памяти. А игры (я уже писал Выше, но Вы не поняли!) играются на близкой к предельной памяти, и быстрое её жрут (постоянно нужно грузить что-то новое или изменять старое). Иными словами, этот самый сборщик будет врубаться часто и со вкусом. Я уж не говорю о том, что вся доступная память компьютера будет быстро сжираться игрой до последнего мегабайта.
Этот Ваш интерфейс IDisposable обеспечивает уничтожение не относящихся с GC объектов, таких как дескрипторы открытых файлов, потоков, окон. ВСЁ! К освобождению выделенной под класс памяти он не имеет ни малейшего отношения, она всё равно убирается GC.
Мда... И Вы ещё обвиняете меня в незнании C# и XNA... А то что прямым текстом в MSDN написано, не прочитали.
а никто его не мешает к managed Объектам прикрутить
Простите, XNARacer - это вершина игростроя, по-Вашему? Мы тут, если Вы не в теме, говорим о революции в игростроении.
ты уж определись, о чем ТЫ говоришь, о GC, или о революции в игрострое.
XNARacer - наглядный пример игры на платформе .NET XNA, там есть все, современная графика, звук, физика, игровая логика. Оно летает при всем при этом
Сейчас по-подробнее прочитал про IDisposable - чуть со стула со смеху не свалился. Я то по простоте душевной думал, что он только для определённого класса объектов. Оказалось - нет, M$ расщедрилась на возможность сделать класс unmanaged. После чего мы, правда, терям все достоинства автоматической сборки мусора, взамен получая кучу проблем.
Начнём с того, что наследование от IDisposable требует нехилых трудозатрат, т.к. нужно вручную вызывать Dispose() всех предков и обрабатывать все исключения, которые ими возвращаются, да ещё и необходимо ручками прописывать работу с любым классом, являющимся unmanaged.
Далее, если есть два класса - один unmanaged, другой - managed и они как-то связаны (а в игре все объекты тесно связаны) - то всё очень-очень печально, ибо проверки прописывать замучаешься. Значит, половину игры нужно делать unmanaged. При том, что долбаний с Dispose куча (не в пример нормальным деструкторам в C++).
Итог?
1) IDisposable порождает проблемы похлеще, чем C++'ные деструкторы, т.е. ухудшает код по сравнению с C++ (кто там хвастался, что на C# код понятнее?)
2) Он не даёт никаких преимуществ по сравнению с C++, зато убивает преимущества GC
3) Его нужно везде прописывать ручками. При этом замечу, что автоматическая сборка памяти всё равно никуда не девается и исправно жрёт свои ресурсы. Хотя бы на определение, а есть ли ей смысл сейчас вызываться (т.е. производительность всё равно страдает).
Такими темпами мы придём к необходимости писать на C# в стиле C++. Вперёд! Осталось совсем немного - признать необходимость юзания unsafe-кода (хотя unmanaged - это по сути и есть unsafe, ибо он опасен утечкой всех unmanaged ресурсов, которые C#-писатели освобождать не привыкли).
ой, а в плюсах будто бы не надо все вручную писать
***
Всякие готовые GAPI на плюсах пользовать бред. Для этих так называемых супермегапроектов. ибо эти GAPI - очередная прослойка => очередные тормоза.
pokibor, а ты уычавствовал в создании "вершин игростроя"?
IDisposable - мечта pokibor
если ты думаешь что XNA - конструктор по типу GameKakera тоже ошибаешься. в ХНЕ нету готовых классов игры, там нету классов гуя, сцены и прочего, там это все самому писать надо.
Я это говорил? Я представляю, что такое XNA, можете не волноваться. Сцена - понятие довольно абстрактное, чтобы Вы могли говорить, что её в XNA нет. GUI в Irrlicht тоже никто самому писать не мешает (я Вам даже больше скажу - в Irrlicht нужно писать свой GUI, ибо стандартный... скажем так, имхо убог.
Но факт в том, что Irrlicht даёт полный спектр классов для доработки движка на любом уровне. И он, в отличие от XNA, open source (откуда, собственно, этот любой уровень и берётся).
Дальше у Вас идёт цитата моих слов в текте Вашего поста... к чему это, не понял. Наверное, ошибка... Потрудитесь перечитать свой пост после его публикации.
а никто его не мешает к managed Объектам прикрутить
И какой тогда смысл? Половина объекта будет managed и будет убираться сборщиком мусора, половина - unmanaged и будет убираться Dispose. Вы, кажется, не поняли, что Dispose работает в полном отрыве от сборщика мусора. Либо - либо, а попытки совместить приведут к тому, что у Вас в объекте будут недостатки обоих подходов - т.е. жуткие руковывороты с Dispose и лишние затраты памяти/её уборка GC.
ты уж определись, о чем ТЫ говоришь, о GC, или о революции в игрострое.
О революции в игрострое говорит тема, а GC не даёт C# и XNE быть революцией. Не только он, конечно (и что это про double math заглохло? Нет возражений?), но в частности.
XNARacer - наглядный пример игры на платформе .NET XNA, там есть все, современная графика, звук, физика, игровая логика. Оно летает при всем при этом
Я повторю, вменяемую игру можно хоть на прологе с юзанием библиотек написать, и существование этой игры вовсе не будет доказательством революционности языка. Пока что я не видел в магазинах ни одной игры, написанной на XNA. А мы всё-таки говорим о профессиональном игрострое.
ой, а в плюсах будто бы не надо все вручную писать
В плюсах деструктор вызывается автоматически и не ведёт к конфликтам с автоматически убираемой памятью, а также извращений с отловом исключений.
Всякие готовые GAPI на плюсах пользовать бред. Для этих так называемых супермегапроектов. ибо эти GAPI - очередная прослойка => очередные тормоза.
В таком случае бредом является и использование DirectX, а уж XNA как надстройки над ним - и подавно. Не смешите народ такими заявлениями!
GAPI - это сборник часто употребляемых функций, не более того. Вас никто не заставляет пользоваться только его средствами от начала и до конца. Вы всегда можете открыть исходный код (Irrlicht - open source, а вот XNA - нет...) и поменять там что нужно, или просто частично использовать стандартные функции, а частично - непосредственно DirectX или OpenGL-функции. C# и XNA такого выбора не дают.
pokibor, а ты уычавствовал в создании "вершин игростроя"?
К чему вопрос? Нет, не участвовал. Однако я писал диплом на соответствующую тему и защитил его с отличной оценкой (это если говорить о заслугах, причём отдельно замечу, что этот разговор начали ВЫ, а не я). Вы, надо думать, и этим похвастаться не можете.
IDisposable - мечта pokibor
За меня о моих мечтах говорите? IDisposable - это мой ночной кошмар. Деструктор, который нужно вызывать ручками, да ещё следить, чтобы он не дай Бог не стал конфликтовать с автоматической сборкой, отлавливать все исключения... Нет, спасибо. Моя мечта уже реализована в C++.
И в последний раз - просьба мой ник не искажать. Я над Вашим не издеваюсь.
в ХНЕ нЕчего править. ТАм долго базовые классы. Например, описание структуры Vector3, Texture, Texture2D, Texture3D, VertexBuffer, и так далее.
Профессиональные геймдевелоперы здесь не сидят, и врядли будут сидеть. А То, что ты называешь потенциальными геймдевелоперами - так они на геймдеве сидят, а здесь это так... для виду...
[CCCP] Monster
21.12.2007, 18:04
Профессиональные геймдевелоперы здесь не сидят, и врядли будут сидеть. А То, что ты называешь потенциальными геймдевелоперами - так они на геймдеве сидят, а здесь это так... для виду...
А вы - профессиональный разработчик игр? Игромания - единственный в природе журнал, активно занимающийся темой игростроения. С этого журнала очень многие начинают работать над созданием или модификацией игр. Поэтому этому форуму, как части сайта журнала, раздел по игростроению необходим. Однако, этот аргумент темы спора не касается. И если он ваш последний по обсуждаемому поводу, то скорее всего, это является вашим поражением в споре.
в ХНЕ нЕчего править. ТАм долго базовые классы. Например, описание структуры Vector3, Texture, Texture2D, Texture3D, VertexBuffer, и так далее.
В Irrlicht есть все эти классы, плюс ещё немного более высокоуровневых. Ими никто пользоваться не заставляет, можете использовать только базовые и самостоятельно писать рендер. Причём какие-то моменты можно брать из исходников самого Irrlicht (ах, как мне нравится Вам повторять, что он open source и знать, что по этой части Вам мне даже потенциально нечего возразить! :Grin: Извините, отвлёкся).
Ну а по остальному спасибо [CCCP] Monster, он ответил. Вообще, прошу меня простить, но спорить в ближайшее время буду куда менее активно. Ибо (1) надоедает одно и то же повторять и (2) мне уже давно пора продолжать писать своё произведение, а это время...
В Irrlicht есть все эти классы, плюс ещё немного более высокоуровневых. Ими никто пользоваться не заставляет, можете использовать только базовые и самостоятельно писать рендер. Причём какие-то моменты можно брать из исходников самого Irrlicht (ах, как мне нравится Вам повторять, что он open source и знать, что по этой части Вам мне даже потенциально нечего возразить!
а что в хне в исходниках искать? как выглядит структура Vector3 ? или че?
рефлектор в зубы и вперед!
ps// игрострой как кто то уже упоминал - это искусство, большинство современных игры - не искусство, а графические навороты, ну и немножко типасюжета. А еще интересно, че там такого эти разработчики пишут, что один тока эхешник весит 75 мег.
Будь ты хоть дважды папой в своем языке программирования, однако, если не придерживаться некоторых правил, то хоть на асме пиши - все равно фигня получится, и даже все его преимущества перед ЯВУ не помогут. Так же и с любым языком программирования. На этом шарпе если умело написать игру, и пусть ты его так нелюбишь из за GC, она по производительности любую твою игру только так уделает, и не важно что у нее математика с плавающей запятой в 3 раза медленней, и что там GC. Если уметь это делать - то просто пофиг будет на все это
noLove
1) Открытые исходники позволяют поправить ошибки, изменить глубинные рассчёты с целью увеличения быстродействия и т.п. Если в XNA нечего править таким образом, то спрашивается, накой она вообще нужна? А Майкрософт доступа к своему детищу никогда не даст.
2) Опять... Ещё одно повторение пройденного материала - буду тереть посты. Ибо мы говорим о профессиональном геймдеве, где работают профессионалы. И у них как раз профессионален и код на C#, и код на C++. Стало быть, им как раз есть разница в скорости double math, GC и всего прочего. А уж учитывая, что деструкторы в C++ реализованы в разы лучше Dispose в C#... Ваши претензии вообще теряют смысл.
И откуда Вы 75 метров экзешник взяли? Сейчас посмотрел у Ведьмака - 10 метров. Причём туда ещё защита вся входит.
Впрочем, могу сказать, откуда могли взяться 75 метров. От оптимизации. От раскрытия C++'ых inline-функций. Это, если что, не программист пишет, а компилятор делает. А код подобные фичи ускоряют многократно (см. тесты по моей ссылке, там как раз хорошо сказано про эту возможность C++).
как мелкософт скажет - так оно и будет. Скажут писать на шарпе - будут писать на шарпе, или же просто перейдут на *никс системы
CMogilko
22.12.2007, 21:06
как мелкософт скажет - так оно и будет.
если они будут спонсировать разработчиков, то - да
или же просто перейдут на *никс системы
такого никогда не будет(во всяком случае в ближайшие лет 15 точно), MS скорее цены убавит на винды, чем даст людям перейти на никсы.
noLove
Ну Micro$oft сказал "Все переходите на Висту!" - результат что-то не слишком впечатляет. Micro$oft сказал "Нет пиратству!" - сейчас отдаёт IE7 обладателям пиратских виндов, опасаясь совсем проиграть в гонке браузеров. Micro$oft - это ещё не весь рынок компьютерных систем, а то сейчас бы за написания игр под Windows ему бы отчисления делали. Думаете, будь у M$ такая возможность ввести подобную практику, они бы отказались?
Вот придёт Google со своей бесплатной ОС, тогда и посмотрим, насколько M$ у нас крут.
И, кстати, подобный пост граничит с оффтопом.
SolarWind
22.12.2007, 22:10
Интересно тут у вас...
Как я понял, основная тема холивара это скорость работы приложения .NET, а точнее эти пресловутые 35%, все остальное GC, вызов деструкторов, циклические ссылки, утечки памяти, это все вытекает из проиводительности. Моя точка зрения, что XNA вполне жизнеспособная технология и эти 35% при текущем положении дел не являются помехой. Посмотрите на производителей процесоров, в один прекрасный день они сказали, "сорри пацаны, но больще наращивать мощность проца мы не могем, но вот вам пока два, а там посмотрим...". Как известно на XBOX 360 стоит 3 двухядерных процессора и в приложениях .NET один из них как раз занимается сборкой мусора, так что приведенный пример со внезапной смертью в Quake из-за лага вследствие сборки мусора считаю несостоятельным. На рынке уже в свободном доступе 4-х ядерные процессоры и это не конец (кстати GC можно перевести в режим работы с 4 процессарами). Но в несомненный плюсы C# и XNA могу записать скорость разработки приложений, думаю с этим возражений-то не будет?
И в завершении всего один вопрос, почему соверемнные игры не пишут на ассемблере, ведь он по определению быстрее С++?
Как известно на XBOX 360 стоит 3 двухядерных процессора и в приложениях .NET один из них как раз занимается сборкой мусора, так что приведенный пример со внезапной смертью в Quake из-за лага вследствие сборки мусора считаю несостоятельным.
И всё бы хорошо, вот только товарищ noLove, сам того не ведая, дал нам в руки лишний козырь, преведя ссылку на статейку, говорящую, что во время работы GC всем потокам в приложении надлежит остановиться. Это раз.
Далее, 35%'ов-то никуда не деваются. При толковом распараллеливании (мы же о профессионалах говорим) все процессоры будут заняты игровым делом (физикой, AI, прочим...). А значит, эти самые 35% никуда не денутся.
И мы ещё не говорим о памяти, которую наличие GC (просьба не забывать) забивает напрочь. Чисто по своей конструкции и желанию вызываться пореже.
Но в несомненный плюсы C# и XNA могу записать скорость разработки приложений, думаю с этим возражений-то не будет?
Будут. Тут тот же самый noLove сказал, что XNA более низкоуровнева, нежели движки. Следовательно, с её использованием возиться придётся более, чем юзая движки вроде Irrlicht'а. А своих наработок у компаний сейчас хватает. Даже новые движки появляются на базе старых.
И я опять не упоминаю про кривейший Dispose (Господи, как же нам, противникам XNA, помог её сторонник - noLove!), с которым мороки в разы больше, чем с C++'ыми деструкторами
И в завершении всего один вопрос, почему соверемнные игры не пишут на ассемблере, ведь он по определению быстрее С++?
Потому что C++ обеспечивает оптимизацию почти до уровня ассемблера, чего C# позволить не в состоянии. В C++ можно сделать функции inline, использовать адресную арифметику... В общем, возможностей куча. Игры же как разрабатывают - сперва пишут от начала до конца, а потом оптимизацией занимаются.
Нет, не много. Репутация является зеркалом того, как другие пользователи относятся к вашей персоне. Если вы пишете откровенную ерунду, либо не понимаете с первого раза, или просто своими постами вызываете отрицательные эмоции, пользователи вполне могут высказать свое отношение к вам с помощью репутации. Участвуя в дискуссии, модератор работает, как обычный пользователь, и поэтому вполне может поставить вам плюс или минус в репутацию, как любой другой пользователь на этом форуме, если сочтет нужным. ПОэтому в данном случае претензии безосновательны. На этом думаю оффтоп закончить.Вы бы прочли бы все внимательно, прежде чем влезать с такими записями. Pokibor, утверждает, что снизил мне репутацию из-за незнания основ программирования. И это, я считаю, ни чем не доказано. Так сказать взял из
подтяжка и снизил. Так не делается - это по-женски. Ну и черт с ним.
Пока - спойлер. В следующий раз будут санкции жёстче. Особенно за последнее высказывание. А почему Вы не знаете основы - см. выше.
Потому что C++ обеспечивает оптимизацию почти до уровня ассемблера, чего C# позволить не в состоянии. В C++ можно сделать функции inline, использовать адресную арифметику... В общем, возможностей куча. Игры же как разрабатывают - сперва пишут от начала до конца, а потом оптимизацией занимаются.В том то и дело, что большинство прогеров на С++ - криворукие, вот и пользуются инлайн асмом. А без этого никак - скорость небольшая, вернее неудовлетворительная. Вот и выходит: свобода, даваемая С++ом лишь выращивает больше ламеров на С++ нежели чем профи. А утверждения что Крайзис не написать на XNA - ничем не обоснованы ( читай неверные догадки ). Так что нету доказаний нереальности, а так же реальности написания. Вопрос просто напросто висит в воздухе. И решиться он лишь со временем. Но, что на Шарпе будет написать легче - это факт.
А это и без разницы. Если написан - значит, требовал бы ресурсов меньше. Хотя факт написания проверяется достаточно легко. Факты - в другом. В памяти, потреблении ресурсов, в тестах.
А утверждения о криворукости - самый настоящий оффтоп, этот вопрос уже затрагивался выше. Потому опять ставлю под спойлер. При повторении - удаление и рейтинг. На C# тоже криворуких хватает. И про то, что писать легче, вовсе не факт - см. выше.
мы же о профессионалах говоримА я уже говорил, что на Шарпе пока профессионалов нету. Так что вновь не факт.
C# 1.0 окончательно вышел вместе с Microsoft Visual Studio .NET в феврале 2002 года. Ему уже 5 лет стукноло. Ваше утверждение крайне смелое.
Что будет при повторении бессмысленных постов, читайте в предыдущих замечаниях.
Ему уже 5 лет стукноло.Шарпу, но не XNA.
Feanor62rus
23.12.2007, 11:12
и эти 35% при текущем положении дел не являются помехой.
Еще один!!! Да откуда вы беретесь то такие? ТЫ пройдись сначала по форуму и почитай че люди говорят об оптимизапции в послених NextGen играх! По всему форуму одно только нытье о тормозах! В топике о крайсиса радуются прибавлению даже 5 FPS. А вы говорите 35% фигня?! Ну ну... поменьше бы таких людей как вы в геймдев.
Как известно на XBOX 360 стоит 3 двухядерных процессора
Там 1 трехъядерный, ЛОЛ. Бегом учить матчасть!
Но в несомненный плюсы C# и XNA могу записать скорость разработки приложений, думаю с этим возражений-то не будет?
На эту тему можно долго спорить. Но ответь мне, почему же на C# до сих пор профессионалы не пишут игр!!!??? Почему? А?
Вот вы все трубите "можно сделать крайсис на C#", но почему его всеже не сделали на нем? Если, как вы говорите, это так удобно?
Просьба воздержаться от спорных в плане цензурности выражений.
Хорошо, больше не буду))
Вот и выходит: свобода, даваемая С++ом лишь выращивает больше ламеров на С++ нежели чем профи.
Фейл. Эх, я б тебе еще один минус влепил бы, но прости, не могу, уже ставил.
Pokibor, утверждает, что снизил мне репутацию из-за незнания основ программирования.
Ой... какая жалость... КАРМО!!!! Не советую так трястись о карме, на этом форуме это не в почете. Только засрут быстрее.
В том то и дело, что большинство прогеров на С++ - криворукие, вот и пользуются инлайн асмом. А без этого никак - скорость небольшая, вернее неудовлетворительная. Вот и выходит: свобода, даваемая С++ом лишь выращивает больше ламеров на С++ нежели чем профи.
Тоесть вы утверждаете, что все прелести и удобства C# это гениально, а прелести С++ это фуфло и они только плодят ламеров? Очень своеобразная позиция. Ты уже похоже сам не замечаешь того, что защищая свой любимый # ты скатываешься до откровенного моразма.
На эту тему можно долго спорить. Но ответь мне, почему же на C# до сих пор профессионалы не пишут игр!!!??? Почему? А?
Вот вы все трубите "можно сделать крайсис на C#", но почему его всеже не сделали на нем? Если, как вы говорите, это так удобно?
ХНЕ примерно 1 год. Еще немножко, и будут писать, обязательно будут.
И то что мелкомягкие скажут писать на шарпе - разработчики будут писать на шарпе, никуда они не денутся. Иначе, почему нет фотошопа для *никс систем? премьера нету? те же самые игры пишут для винды. Вы злесь включая вашего главаря покибора умные самые - додумаетесь к чему это я написал
Feanor62rus
23.12.2007, 12:35
ХНЕ примерно 1 год. Еще немножко, и будут писать, обязательно будут.
Ждем.... с нетерпением. И вабще я в данный момент не о хне говорил а о C#. И то что мелкомягкие скажут писать на шарпе - разработчики будут писать на шарпе, никуда они не денутся.
Во-первых они так не скажут. Во-вторых, им это никогда не позволит антимонопольный комитет. В-третих, как они могут их принудить? Как?
Вот, к примеру, стал я разработчиком. Кто меня может принудить писать на #? И самое главное как? Да если я захочу я буду хоть на VB писать, хоть на ныне мертвом языке АДА, никакой Билли меня не заставит.
Иначе, почему нет фотошопа для *никс систем? премьера нету?
И почему же нету? Неужто Билли запретил?
Вы злесь включая вашего главаря покибора умные самые - додумаетесь к чему это я написал
Ты написал какуюто ересь понятную только тебе, научись правильно излагать мысль.
если человек пишет на С++ это вовсе не означает что у него прямые руки..
как вариант разрешения данного спора (на чем проще делать игры) - есть предложение забацать соревнование. выбираем игру и делаем ее, одна команда пишет ее на С++ а я пишу ее на шарпе.
я могу дать вам фору - команда С++ может состоять из 3 человек, я же буду один.
результат - время реализации работоспособной игры.
плюс к тому что я вас уделаю, могу гарантировать что ХНА-шный её вариант будет максимум на 10% медленнее) а не 35% :Grin:
Так как ХНА это враппер для DX то Главное условие - прямое использование АПИ (выбирайте любой: GL или DX). т.е. готовые движки нельзя а то дай вам волю и деньги так вы UE3 станете юзать дабы не остаться в дураках.
О себе - мне 30, программирую 16 лет, из них работаю программистом 13 лет, из них в геймдеве 8 лет. Начинал еще со спектрума (бейсик, ассемблер), потом были совковские ЭВМ (бейсик, ассемблер, С) как появились писюки - перешел на них (бейсик, паскаль, С++, Шарп), щас на шарпе работаю (геймдев), уже 6 лет, перешел на него с С++. и возвращаться не собираюсь.
Без этого соревнования - данный спор это просто слова. не важно кто и что защищает..
Ну так что, детишки, поиграем? Кто примет вызов?
В конце один небольшой факт -
13-го декабря вышла ХНА (2.0). и за первые ДВА дня пакет был скачан порядка миллиона раз.
уж не думает ли кто из С++ гулага, что этот миллион человек (а на данный момент уже больше) — полные недотепы и только вы одни самые умные?
Непомню такого ажиотажа вокруг какой-либо технологии связанной с геймдевом. Вывод из всего этого прост — в ближайшие годы геймдев разработчикам, пишущим на С++, придется сильно потесниться на этом рынке.. (надеюсь что они вообще не вымрут, как динозавры когда-то)
Авриелий
23.12.2007, 12:43
Я предлогаю афтору чёнить сделать на этом мега языке С# , а потом говорить что тут быстрее... С++ быстрее на порядок...
ХНЕ примерно 1 год. Еще немножко, и будут писать, обязательно будут.
А вот всяческим DarkBasic'ам и прочим Blitz3D уже гораздо больше лет. Но на них как писали исключительно любительские проекты, так и пишут. Откуда увереность в том, что XNA не постигнет их участь?
И то что мелкомягкие скажут писать на шарпе - разработчики будут писать на шарпе, никуда они не денутся. Иначе, почему нет фотошопа для *никс систем? премьера нету? те же самые игры пишут для винды.
Ну во-первых, многие игры есть в вариантах и для Linux. Сейчас вон собирают подписи, чтобы под Linux Fallout 3 сделали...
Далее, то, что игры пишут под систему от Micro$oft, вовсе не значит, что M$ всем диктует условия. Одно дело, если под новой супер-системой (Vista на это звание не тянет) вообще не будет иных компиляторов, кроме C# (но это - чистой воды бред, т.к. если под ту систему придётся переписывать ВСЕ СУЩЕСТВУЮЩИЕ приложения, у меня есть боооольшие сомнения, что такая система вообще продастся хоть парой экземпляров). А если написаные на C++ программы будут работать, то о каком диктате со стороны M$ может идти речь?
Вы злесь включая вашего главаря покибора умные самые - додумаетесь к чему это я написал
Додумались - к тому, что у Вас кончились все вменяемые аргументы в пользу своей правоты, и Вы прибегаете к откровенной чуши.
raxxla
Вообще-то честность подобного соревнования не проверишь никак. Это раз. Про скорость я уже говорил про существующие наработки. Это два. Миллионы человек - это любители, и студенты, для которых XNA - в самом деле весьма лакомый кусочек. Мы же говорим о профессиональном геймдеве. Это три. И четыре - сравнивать XNA с использованием чистого DX или OpenGL некорректно. XNA - специализированный инструмент для разработки игр. DX и OpenGL - нет.
А про спор, значица, возразить нечего в поддержку XNA и C#? То есть мы во всём были правы?
И позволю себе небольшой оффтоп, под спойлером, как и надлежит. Сейчас прочитал расшифровку названия XNA: "XNA's Not Acronymed". Сразу вспомнилось знаменитое "GNU's Not Unix". Майкрософт даже идеи для названий явно тырит, не стесняясь!
вы, конечно во всем правы, но истина дороже..
Миллионы человек - это любители, и студенты - это точно, в яблочко, и я один из них, у меня даже высшего образования нет (бросил институт), вам нестоит бояться такого как я, просто примите вызов и не нада юлить. а то я начну думать что вы просто в свое свободное время разводите демагогию по поводу никчемности шарпа в геймдеве..
Feanor62rus
23.12.2007, 13:11
если человек пишет на С++ это вовсе не означает что у него прямые руки..
Согласен, но мы тут обсуждаем языки программирования, а не людей, которые на них пишут. Ведь так?как вариант разрешения данного спора (на чем проще делать игры) - есть предложение забацать соревнование. выбираем игру и делаем ее, одна команда пишет ее на С++ а я пишу ее на шарпе.
Не знаю как к этому отнесутся другие участники, но омне лично не досуг тратить уйму времени(во время сессии), я еще и работаю. Так что, я пас. Считаю сей акт меряния пиписьками абсолютно безсмысленным. С++ обьективно лучше и этот факт уже доказан любовью к нему со стороны профессионалов.
щас на шарпе работаю (геймдев), уже 6 лет, перешел на него с С++. и возвращаться не собираюсь.
Слушай, а если ты пишешь игры уже 6 лет, то неужели тебе нечего нам показать. Ты покажи игру которая у тебя уже есть, я тебе лично скажу что ты крут если оно так и есть. И еще... Раз вы работаете в геймдеве, то хотябы поделитесь в какой конторе и какие игры у вас за душой. Просто наших толковых игр - по пальцам пересчитать, ивот незадача, они все писаны на С++. Мне очень интересно воочию увидеть красивую, нетормозную, профессиональную игру написаную на C#. Требую, чтобы вы мне ее показали. Иначе я вас считаю вруном.
я работаю щас тут - www.visual3d.net (http://www.visual3d.net) качайте на здоровье, правда там щас только бэта. релиз тока в феврале будет.
по поводу соревнования - я тоже занят. но время найду.
без соревнований - какой смысл спорить?
ведь в чем суть любого спора? - В споре рождается истина.
вот я и предложил способ ее родить.
вы, конечно во всем правы, но истина дороже..
Истина хороша, когда у неё есть обоснование. Хорошо, допустим, я - начинающий разработчик. Я приду к Вам и спрошу "На чём лучше делать игры? C++ с существующими движками или XNA с C#"? Вы в ответ "XNA!!!". Я спрошу "А почему?" И Вы мне "потому что миллион человек её скачал"?
А сколько человек качают C++'ые движки и прочие инструменты, связаные с C++?
Давайте уж говорить честно. Единственное преимущество XNA - это её полнота, то упорство, с которым её продвигает Micro$oft, то, что она в себя включает всё, что только может пригодиться для разработки игр (ой, и прошу Вас, не нужно говорить, что XNA одного уровня с DX и OpenGL как средство для разработки игр)!
Что взамен? Тормоза (результаты тестов: double math, работа с памятью и т.д.). Ограничения - если для C++ есть огромный выбор компиляторов, движков и чего только нет, то XNA существует только в одном варианте. И если с этим вариантом какие-то проблемы, недоработки и т.п. - не судьба. Негибкость - неужели XNA open source? M$ вообще враг свободных проектов с открытыми исходниками.
Что с точки зрения начинающего разработчика? Ему XNA действительно симпатична. Также, как симпатичны готовые движки, Blitz3D всякие и т.п. Так что тут революционность, извините, отменяется. Средства упорядочить DirectX-функции до уровня понятной классовой структуры (или вообще до уровня конструктора) уже были. Пишут на таких продуктах известные игры? Нет. Почему - подумайте сами. А я сошлюсь на факт.
Чего такого есть в XNA, чего ещё не было? Сборщики памяти, байт-коды - это всё уже было. XNA - коллекция старых идей, приправленная известностью Micro$oft, не более того.
Итак, Вам вопрос, как к профессионалу (как Вы заявили, по крайней мере): Чего такого есть в XNA, что не было до неё и что привлечёт к ней серьёзные игровые компании? Отвечайте.
Миллионы человек - это любители, и студенты - это точно, в яблочко, и я один из них, у меня даже высшего образования нет (бросил институт), вам нестоит бояться такого как я, просто примите вызов и не нада юлить. а то я начну думать что вы просто в свое свободное время разводите демагогию по поводу никчемности шарпа в геймдеве..
Простите, но тут я ставлю под сомнение то, что Вы заявили. Вы говорите, что работаете - и в то же время предлагаете соревнование, требующее затрат свободного времени.
Что ж. Если Вы работаете в геймдеве, значит, у Вас уже есть свои наработки на этот счёт, и мы с Вами не будем в равных условиях. Кроме того, как я уже сказал, нельзя сравнивать чистую XNA с чистым C++ + графическая библиотека. Это всё равно, что кричать о крутости того же Blitz3D по сравнению с C++. XNA - это выше, чем графическая библиотека, и никто с этим не спорит.
И наконец, я не знаю, как Вы там работаете, но вот я - работаю. Плюс ещё учусь в аспирантуре. Плюс модерю форум. Плюс пишу сейчас книгу. Вы думаете, я всё это брошу только ради подтверждения своей точки зрения и соревнования с Вами? Нет.
Да и как же Вы работаете, если можете уделить этому время? Позволю усомниться либо в том, что действительно Вы работаете, либо что будете соревноваться честно.
Хорошо, допустим, я - начинающий разработчик. Я приду к Вам и спрошу "На чём лучше делать игры? C++ с существующими движками или XNA с C#"? Вы в ответ "XNA!!!". Я спрошу "А почему?" И Вы мне "потому что миллион человек её скачал"?
Если вы придете комне, то я скажу что ХНА использовать вы должны потому что ее использую я. и этого будет достаточно. так как вы пришли именно комне.
А сколько человек качают C++'ые движки и прочие инструменты, связаные с C++?
Незнаю, сходите на сайт огра, посмотрите, поделитесь с нами инфой..
Давайте уж говорить честно. Единственное преимущество XNA - это её полнота, то упорство, с которым её продвигает Micro$oft, то, что она в себя включает всё, что только может пригодиться для разработки игр (ой, и прошу Вас, не нужно говорить, что XNA одного уровня с DX и OpenGL как средство для разработки игр)!
Хорошо, если вы примите вызов - вам будет разрешено использовать сторонние библиотеки (обсудим какие именно..)
Итак, Вам вопрос, как к профессионалу (как Вы заявили, по крайней мере): Чего такого есть в XNA, что не было до неё и что привлечёт к ней серьёзные игровые компании? Отвечайте.
У ХНА есть миллион студентов и я один из них, хотите знать что это значит? - примите вызов.
На всех форумах по всему инету народ гонит на шарп, заставляя дотнетчиков защищаться, при этом нападающие и не подозревают о том что сами защищаются (атака - лучший способ зашиты).
Вы нас боитесь, а мы вас - нет..
Если вы придете комне, то я скажу что ХНА использовать вы должны потому что ее использую я. и этого будет достаточно. так как вы пришли именно комне.
Веская причина. А если я кроме Вас приду ещё к другому человеку, и он использует C++? И как мне понять, кто из Вас прав? Наверное, всё-таки потребуется описание каких-то преимуществ...
Незнаю, сходите на сайт огра, посмотрите, поделитесь с нами инфой..
Зачем так далеко... в Google по всяческим запросам, связанным с XNA, около 2 миллионов количество. По "ogre 3d" - столько же. А ведь есть ещё и другие движки... Так что по такой логике выходит, что огр - конкурент XNA...
Хорошо, если вы примите вызов - вам будет разрешено использовать сторонние библиотеки (обсудим какие именно..)
Обсуждайте, какие библиотеки являются эквивалентом XNA. Не со мной. Но насчёт вызова я уже сказал. Если лично у Вас полно свободного времени, то есть на этом свете более занятые люди. Мне за новогодние праздники нужно вторую часть книги закончить, в ARIS стать асом и задания аспирантурные сделать. А потом уже всякие споры и соревнования.
У ХНА есть миллион студентов и я один из них, хотите знать что это значит? - примите вызов.
Это значит, что вменяемого ответа нет. Спасибо, я понял. Собственно, так я и думал.
На всех форумах по всему инету народ гонит на шарп, заставляя дотнетчиков защищаться, при этом нападающие и не подозревают о том что сами защищаются (атака - лучший способ зашиты).
Вы нас боитесь, а мы вас - нет..
Ммм... Возможно, потому, что C++ проверен временем, а C# и XNA - только лишь претендуют на его лавры? Слишком много было попыток выгнать С++ с пьедестала. Итог: C# - лишь очередная. Может быть, и удачная (на этот счёт мы и спорим).
Атака - лучший способ защиты, верно. Но почему тогда дотнетчики не атакуют? От бесстрашия ли? Или просто потому, что нечем атаковать-то?
Веская причина. А если я кроме Вас приду ещё к другому человеку, и он использует C++? И как мне понять, кто из Вас прав? Наверное, всё-таки потребуется описание каких-то преимуществ...
Возможно вы правы, если вы действительно собираетесь придти комне - я основательно подготовлюсь и неразочарую вас.
Атака - лучший способ защиты, верно. Но почему тогда дотнетчики не атакуют? Боятся ли? Или просто потому, что нечем атаковать-то?
Потому что им незачем это делать, они знают что если спор дойдет до реального дела, то народ из С++ сообщества предпочтет отсидеться в сторонке..
зачем тогда дотнетчикам тратить время впустую?
я могу на любом из форумов, где идут подобные холивары, запостить предложение о таком же соревновании и везде, я почти уверен, будут похожие ответы - мне некогда, это все фигня, С++ все равно круче..
Возможно вы правы, если вы действительно собираетесь придти комне - я основательно подготовлюсь и неразочарую вас.
Тогда почему бы не основательно подготовиться и выложить все аргументы здесь? Мы подождём.
Потому что им незачем это делать, они знают что если спор дойдет до реального дела, то народ из С++ сообщества предпочтет отсидеться в сторонке...
Ну, учитывая, что сейчас передовые коммерческие игры (а не всякие показные гоночки) всё-таки на C++ разрабатывают, то на отсиживание в сторонке это не тянет. Вот когда будет реальная игра по типу Кризиса, Старкрафта там второго и т.п. разработана на C# - тогда можно говорить про отсиживание в сторонке. А пока что в профессиональном геймдеве (повторюсь, спор у нас о нём, XNA как движок для начинающих уже тут вроде признали) C# зубов не показывал.
зачем тогда дотнетчикам тратить время впустую?
А C++'совикам? И тему-то эту, кстати, дотнетчик создал, прошу заметить, а не C++'овик, "опасающийся за любимый язык".
я могу на любом из форумов, где идут подобные холивары, запостить предложение о таком же соревновании и везде, я почти уверен, будут похожие ответы - мне некогда, это все фигня, С++ все равно круче..
Заметьте, тут Вам никто не говорит, что "это все фигня, С++ все равно круче". Мы привели аргументы и ответа не услышали. Требовать и так по уши занятый народ тратить время на соревнования, да ещё отказ от них принимать за доказательство своей правоты как-то совсем нехорошо...
Попробуйте, скажем, Кармаку соревнование такое предложить. Он тоже откажется, и по той же причине, будте уверены.
Всё-таки если Вы такой свободный, это ещё не значит, что другие такие же.
C# зубов не показывал.
это только вопрос времени. ведь С++ уже более 30 лет..
автор темы, в первом, посту просто поделился новой информацией. на него тут же набросились и пошло-поехало. все являются участниками этого спора - в одинаковой мере.
Заметьте, тут Вам никто не говорит, что "это все фигня, С++ все равно круче". Мы привели аргументы и ответа не услышали. Требовать и так по уши занятый народ тратить время на соревнования, да ещё отказ от них принимать за доказательство своей правоты как-то совсем нехорошо...
Попробуйте, скажем, Кармаку соревнование такое предложить. Он тоже откажется, и по той же причине, будте уверены.
Всё-таки если Вы такой свободный, это ещё не значит, что другие такие же.
Я нехочу тратить время на аргументы, я хочу доказать свою точку зрения на деле. Это дело принципа и ради того чтобы поставить вас на место я готов взять отпуск на несколько дней (девушка моя меня прикончит, но оно стоит того).
Грош цена вашим убеждениям, если вы не готовы пожертвовать ради них хоть что-то..
это только вопрос времени. ведь С++ уже более 30 лет..
Либо вопрос отсутствия этих зубов.
Как модератор попрошу воздержаться от выдвижения аргументов, предполагающих проверку будущим временем. Это почти флуд.
автор темы, в первом, посту просто поделился новой информацией. на него тут же набросились и пошло-поехало. все являются участниками этого спора - в одинаковой мере.
Он в категоричной форме заявил о революционности C# и XNA.
Если все являются участниками в одинаковой мере, то при чём тут споры о защите и нападении?
И вообще надо потихоньку прекращать всё, что граничит с оффтопом.
Я нехочу тратить время на аргументы, я хочу доказать свою точку зрения на деле. Это дело принципа и ради того чтобы поставить вас на место я готов взять отпуск на несколько дней (девушка моя меня прикончит, но оно стоит того).
Можете посоревноваться с ребёнком и вчистую победить его. Ибо никакой исход спора ничьей правоты не докажет, всегда можно будет списать на личное умение и на случайные факторы. Вот если бы сражались, например, 10 команд C++ и 10 - C#, да ещё специально отобранных - тогда можно было бы что-то говорить. А так...
Грош цена вашим убеждениям, если вы не готовы пожертвовать ради них хоть что-то..
Мне не 30 лет, а 23, и призыв у нас до 27. Из аспирантуры никто отпуска не даёт, на первом году обучения - тем более. Пожертвовать книгой ещё можно, но количество ожидающих её продолжения больше одного Вас (если не верите, могу дать ссылку).
Да и опять же - если Вы будете в отпуске, а я - не смогу быть, то какие могут быть разговоры о честности спора?
Не говорите глупостей. Честный и, главное, показательный спор через интернет двум людям организовать невозможно в принципе. Тогда какой в нём толк?
Feanor62rus
23.12.2007, 17:18
Все это на самом деле полная фигня. Все эти споры я имею в виду. Понимаешь, если посадить за руль копейки пилота ралли, а за руль мерса какого-нибудь чайника. То скорее всего победит профессионал. Но вот только копейка то от этого лучше не станет. Как была ведром с болтами так им и останется. Я к чему клоню... бестолку устраивать подобное соревнование. Все сведется к соревнованию по программированию. Да, это выявит кто лучший прогер. Но спор о том, что лучше C# или С++ так и останется висеть в воздухе.
Если уж есть такое желание, то можно попытаться всем вместе замутить, ну не игру если времени нет, то хотябы демосцену с одними и теми же моделями, текстурами и абсолютно одинаковыми алгоритмами(разработанными вместе) на двух разных языках и просто сравнить показатель FPS. Остальное просто безсмысленно.
Как модератор попрошу воздержаться от выдвижения аргументов, предполагающих проверку будущим временем. Это почти флуд.
Давайте уже вообще заканчивать с этим спором, иначе мы перейдем на личности а в итоге каждая сторона останеться при своем.
Давайте Вы научитесь пользоваться спойлером?
И лучший способ прекратить спор - это не продолжать его.
Можете посоревноваться с ребёнком и вчистую победить его. Ибо никакой исход спора ничьей правоты не докажет, всегда можно будет списать на личное умение и на случайные факторы. Вот если бы сражались, например, 10 команд C++ и 10 - C#, да ещё специально отобранных - тогда можно было бы что-то говорить. А так...
Вас победить мне будет намного проще чем даже ребенка. Потому что даже дети не говорят таких нелепостей. Где мы возьмем 10 команд? может тогда уж и бил гейтцу позвоним? А что, нам ведь не слабо, мы ведь центр мироздания, мы ведь С++ знаем..
Да и опять же - если Вы будете в отпуске, а я - не смогу быть, то какие могут быть разговоры о честности спора?
Не говорите глупостей. Честный и, главное, показательный спор через интернет двум людям организовать невозможно в принципе. Тогда какой в нём толк?
Вы заранее уверенны в моей нечестности - нехорошо, господин модератор.
Feanor62rus - У вас есть конкретная идея? выкладывайте. если у вас напряги со свободным временем - мы можем не учитывать его вообще. Давайте, сделаем одно и тоже и просто сравним ФПС.
Вас победить мне будет намного проще чем даже ребенка. Потому что даже дети не говорят таких нелепостей. Где мы возьмем 10 команд? может тогда уж и бил гейтцу позвоним? А что, нам ведь не слабо, мы ведь центр мироздания, мы ведь С++ знаем..
Если Вы так истолковали мои слова - лучше переосмыслите их. Только такой спор может дать объективный ответ. Если мы не можем его устроить (я разве предлагал?) - значит не судьба нам найти правду таким способом. Зачем тратить время на что-то, бессмысленное изначально?
Вы заранее уверенны в моей нечестности - нехорошо, господин модератор.
Вообще-то ничего личного (а тем более слова "уверен"!) не было. То, что я, уходя из дому, запираю дверь, ещё не значит, что я уверен в нечестности своих соседей и вообще всех людей на земле.
Цитата:
Сообщение от raxxla
Вас победить мне будет намного проще чем даже ребенка. Потому что даже дети не говорят таких нелепостей. Где мы возьмем 10 команд? может тогда уж и бил гейтцу позвоним? А что, нам ведь не слабо, мы ведь центр мироздания, мы ведь С++ знаем..
Если Вы так истолковали мои слова - лучше переосмыслите их. Только такой спор может дать объективный ответ. Если мы не можем его устроить (я разве предлагал?) - значит не судьба нам найти правду таким способом. Зачем тратить время на что-то, бессмысленное изначально?
Не судьба - это точно. Каждый при своем останеться. Да и планета геймдева - большая, на ней найдется место и шарпу и С++. Так что прекратим этот спор и займемся чем-то более полезным, у вас книга а у меня в конторе скоро очередная бэта (до НГ нада выпустить)
Надеюсь, оффтоп на этом прекратится.
K.A.I.N.
23.12.2007, 18:44
Всем привет!!! Я мало имею отношения к разработке игр, или каких либо других приложений для РС, поскольку пишу проги для цифровой обработки сигналов, и в основном на ассемблере, потому что хорошее быстродействие на другом языке получить несколько трудновато. Там очень много используются языки С и С++, но в любом случае, быстрее, чем хорошо написанной на ассемблере проги ничего из того, о чем вы тут говорите, работать не будет.
Далее, по поводу того, что С# вообще и XNA Game Studio в частности - это попытка попрать чей-то там пьедестал, и только, это чепуха. Microsoft сейчас очень уверенно продвигает сей продукт, поскольку разработка игр под ее консоль X-Box 360 будет проводиться в основном на XNA. Далее, .NET и С# - это НЕ ИНТЕРПРЕТАТОРЫ, это вам не бейсик. Это проги, которые компилируются непосредственно перед выполнением, т.е. после компиляции исполнимый код грузится в память и работает как любой другой ЕХЕ-шник, скомпиленный бог знает когда бог знает кем. Единственная разница, компилирование происходит под конкретный конфиг, т.е. оптимальнее, чем на конкретном железе. Пример, кто-то пишет прогу на машине типа Р-600 для использования ее на C2D. И вы хотите сказать, что она будет оптимально скомпилена??? Ой как не уверен.
Уважаемый K.A.I.N., вы бы хоть почитали тему! Всё, что Вы сказали, уже было сказано. Кое-что - по нескольку раз. Так что живите настоящим днём. :wnk:
Флуд удалён. Все вопросы - в личку. Тут только процитирую причину: "Никакой конкретики либо возражений." Повторение приведёт к получению баллов. Лишь посоветую ещё раз перечитать первую страницу темы и подумать, почему крупные компании не поставляют свой софт open source с компиляцией его на машине пользователя.
Pokibor
Ну во-первых, многие игры есть в вариантах и для Linux. Сейчас вон собирают подписи, чтобы под Linux Fallout 3 сделали...
Далее, то, что игры пишут под систему от Micro$oft, вовсе не значит, что M$ всем диктует условия.
Например, какие из известных игр есть для линукс? Quake3 & Quake4 не предлагать.
Сейчас прочитал расшифровку названия XNA: "XNA's Not Acronymed". Сразу вспомнилось знаменитое "GNU's Not Unix". Майкрософт даже идеи для названий явно тырит, не стесняясь!
Можно ссылку, где это написано? оффициально у хны не было расшифровки... по крайней мере раньше.
Если Вы не заметили, это оффтоп и я его в теге спойлера написал. От Вас как минимум требуется то же самое.
Ждем.... с нетерпением. И вабще я в данный момент не о хне говорил а о C#.
Во-первых они так не скажут. Во-вторых, им это никогда не позволит антимонопольный комитет. В-третих, как они могут их принудить? Как?
А зачем им принуждать? просто в их новой ОС не будет привычного Win32 API и все.
Про антимонопольный комитет. Вы знаете, США от MS получает очень хорошие деньги в виде налогов хотя бы, вроде бы, чуть меньше 1 трети. К тому же, MS занимаются написанием военных программ для армии США.
Кстати, девелоперы могут перейти на OpenGL, он ведь кроссплатформенный в отличие от DX
Ты написал какуюто ересь понятную только тебе, научись правильно излагать мысль.Ты не прав. Раз вы все тут говорите что плюсы круче шарпа в геймдеве, значит вы должны знать, как, а самое главное, на чем работают эти игры.
Тут тот же самый noLove сказал, что XNA более низкоуровнева, нежели движки.
.......
XNA - специализированный инструмент для разработки игр.
XNA для шарпа, это то же самое что и DirectX API для С++. Так что, с помощью XNA хоть что можно делать. (XNA - то, во что перерос MDX)
ps// pokibor, а можно ссылку на вашу книжку, или то, что будут ждать не 1 и не 2 человека?
pps// pokibor, ты говоришь что наверняка у raxxla есть какие то наработки. А чего ты так беспокоишься, если ты тут такие заявления делаешь, к тому же диплом защитил по теме геймдева - наверняка у тебя тоже есть какие то наработки
Личные вопросы - в личку или тоже как минмум под спойлером.
Значит так. noLove и всем остальным. Делаю последнее китайское предупреждение. КОНЧАЕМ ОФФТОП И ФЛУД. Если хочется/нужно поофтопить немного - к вашим услугам тег спойлера. По личным вопросам - ЛС. Если всё будет продолжаться в такой форме, как оно есть сейчас - обещаю, я буду тереть целые посты вместе со всей инфой в них и ставить предупреждения. И не говорите потом, что я затыкаю рот своим противникам. В особо критическом случае обещаю закрыть тему на неопределённый срок.
Например, какие из известных игр есть для линукс? Quake3 & Quake4 не предлагать.
Точно сказать не могу, т.к. этим вопросом не интересовался, да и к спору он имеет отношение постольку посколько. Однако всё, что использует OpenGL, спокойно под Linux перекомпилируется. Также гляньте список по http://en.wikipedia.org/wiki/Linux_games в графе "Linux versions".
Правда, тут, конечно, нужно оговориться, что многие компании просто не видят необходимости выпускать Linux-версии, т.к. под Linux'ом есть очень неплохие эмуляторы, позволяющие запустить какой-нибудь WoW без всяких проблем.
Можно ссылку, где это написано? оффициально у хны не было расшифровки... по крайней мере раньше.
Вообще-то это опять же не имеет значения для спора, но раз интересно - http://en.wikipedia.org/wiki/Microsoft_XNA. Однако в будущем прошу такие вопросы задавать в личку.
А зачем им принуждать? просто в их новой ОС не будет привычного Win32 API и все.
Ммм... А как же совместимость со старыми программами?
Нет, честное слово, подобная Ваша уверенность в том, что M$ может просто так взять и в очередных виндах не сохранить совместимость с программами для предыдущих меня просто забавляет! Покупатели такие Винды просто не купят. А M$ вылетит в трубу со всеми её миллионами.
А если совместимость будет - тогда почему не будут работать новые игры, написанные на всё том же C++ с тем же Windows API?
XNA для шарпа, это то же самое что и DirectX API для С++. Так что, с помощью XNA хоть что можно делать. (XNA - то, во что перерос MDX)
Вот не надо! XNA - специализированный продукт для разработки игр:
Microsoft XNA is a set of tools, complete with a managed runtime environment, provided by Microsoft, that facilitates computer game design, development, and management.
DirectX - библиотека, используемая далеко не только в играх. В ней куда более общие функции. Если XNA - то же самое, что DX, только под C# - то в чём её преимущество перед DX? Или DirectX M$ писать не умели и криво сделали, а к изданию XNA вдруг научились? Вы противоречите сами себе.
ps// pokibor, а можно ссылку на вашу книжку, или то, что будут ждать не 1 и не 2 человека?
Вопросы по моей книге (кстати, книга - не совсем верно, скорее "объёмное произведение") - только в личку. Однако предупрежу, что к программированию она не имеет никакого отношения. Это фентези. Если всё ещё интересует - повторяю, стучите в личку.
pps// pokibor, ты говоришь что наверняка у raxxla есть какие то наработки. А чего ты так беспокоишься, если ты тут такие заявления делаешь, к тому же диплом защитил по теме геймдева - наверняка у тебя тоже есть какие то наработки
Дипломный проект писался на бесплатном open source движке Irrlicht, с незначительными модификациями его исходного кода. Задача разработки движка в теме не значилась, рассматривались вопросы вроде шейдеров, проектирования, разработки AI и прочего.
У меня есть наработки, однако я не могу претендовать на их широконаправленность, к тому же в предлагаемом споре многое зависело от темы проекта и никто не мог гарантировать, что у кого-то не найдётся наработок как раз по теме, а у другого - нет.
Точно сказать не могу, т.к. этим вопросом не интересовался, да и к спору он имеет отношение постольку посколько. Однако всё, что использует OpenGL, спокойно под Linux перекомпилируется. Также гляньте список по http://en.wikipedia.org/wiki/Linux_games в графе "Linux versions".
Правда, тут, конечно, нужно оговориться, что многие компании просто не видят необходимости выпускать Linux-версии, т.к. под Linux'ом есть очень неплохие эмуляторы, позволяющие запустить какой-нибудь WoW без всяких проблем.
А ты пробовал запустить в эмуляторе этот самый вов? я пробовал, только не вов, а лайнэйдж2, невервинтернайтс, еще что то вроде бы.
Это ужос просто, или звук не работает, или глюки с графикой, или вообще не понять в чем дело.
Есть 1 нормальный эмулятор - Cedega, но он ПЛАТНЫЙ. думаю, не стОит объяснять.
Игры ориентируются для ОС Windows, т.к. эта ОСь коммерческая, игры - тоже коммерция, для винды проще продать что то, чем для *никс систем из за их идеологии(этих самых систем)
Вообще-то это опять же не имеет значения для спора, но раз интересно - http://en.wikipedia.org/wiki/Microsoft_XNA. Однако в будущем прошу такие вопросы задавать в личку.
Акей босс!
Ммм... А как же совместимость со старыми программами?
Нет, честное слово, подобная Ваша уверенность в том, что M$ может просто так взять и в очередных виндах не сохранить совместимость с программами для предыдущих меня просто забавляет! Покупатели такие Винды просто не купят. А M$ вылетит в трубу со всеми её миллионами.
А если совместимость будет - тогда почему не будут работать новые игры, написанные на всё том же C++ с тем же Windows API?
Я ж не говорю, что прям так сразу РАЗ, и нету! Они постепенно
Вот не надо! XNA - специализированный продукт для разработки игр:
Про директХ то же самое можно написать. Хну тоже куда угодно прикрутить без проблем
DirectX - библиотека, используемая далеко не только в играх. В ней куда более общие функции. Если XNA - то же самое, что DX, только под C# - то в чём её преимущество перед DX? Или DirectX M$ писать не умели и криво сделали, а к изданию XNA вдруг научились? Вы противоречите сами себе. Как говорил тов. raxxla, XNA - это .net прослойка над DirectX, или врапперы, как хочешь. Хну придумали для наибольшей совместимости при кодинге графике для ББ и коробки, чтобы облегчить портирование
Дипломный проект писался на бесплатном open source движке Irrlicht, с незначительными модификациями его исходного кода. Задача разработки движка в теме не значилась, рассматривались вопросы вроде шейдеров, проектирования, разработки AI и прочего.
У меня есть наработки, однако я не могу претендовать на их широконаправленность, к тому же в предлагаемом споре многое зависело от темы проекта и никто не мог гарантировать, что у кого-то не найдётся наработок как раз по теме, а у другого - нет.
Ну вот видишь, наработки ведь есть. Опыт тоже есть. А про спор, raxxla так же писал, что тема проекта - на выбор, а так же использование тобой библиотек - по сугубо общему решению
Кошмар, все страницы не осилил.
А можно поинтересоваться у уважаемых защитников C++ геймдева, над какими проектами им в жизни пришлось поработать.
Я от себя вставлю еще немного насчет производительности и всякого. Я уже несколько лет занимаюсь геймдевом и графикой, поработал в двух компаниях, где в качестве основного языка для разработки движка/игр использовался именно C++ (об утилитах мы не говорим, да). Я вполне нормально знаю C++ (хорошо я тут побоюсь говорить), по крайней мере на уровне "Прочитал Майерса и Александреску, все понял и понравилось". Так вот, к чему это я. С Xna я начал возиться сразу после ее выхода, т.к. все больше и больше разочаровывался в языке C++, который мне тогда казался идеальным средством сделать как можно больше незаметных ошибок (несмотря на мой тогдашний более-менее солидный опыт). Но речь не о том, что С++ - плохой язык. Не надо нам тут резни. Речь о том, что с тех пор, как я начал писать графические приложения с использованием Xna, я как будто чувствовал, что мед льется на душу. Простой и понятный код, удобный инструментарий. Время разработки ускорилось, пожалуй, раза в два. Именно поэтому я до сих пор продолжаю пользоваться Xna.
Теперь что касается производительности. Да, при определенных условиях managed код медленнее unmanaged. Однако существуют и такие условия, при которых управляемый код работает быстрее (вспомним хотя бы про сверхбыстрый аллокатор памяти). Это уже вопрос культуры и опыта программирования. Еще пара нюансов - почти все приложения, с которыми я работаю, - GPU-bounded. В них падение производительности в 35% (откуда кстати цифра?) почти не оказывает влияния на суммарное время обработки одного кадра, т.к. процессор все равно какое-то время простаивает. "А как же физика?!" - крикните вы. А физику никто и не заставляет писать на .NET/C#. Я вот пользуюсь Ageia PhysX (благо интегрировать unmanaged код в managed очень просто и удобно), и никакого дискомфорта не испытываю.
Уфф, написал. Привет всем знакомым тут, кстати =)
Уфф, написал. Привет всем знакомым тут, кстати =)
Ну вот я уже давно так чувствую, что кто-то кинул клич "там нашу любимую XNA бьют!" и сюда повалила куча людей защищать эту самую XNA. Нехорошо, товарищи, защитники C++'а никого не зовут, в их рядах только люди, имеющие за плечами опыт общения с форумом. А новички на форуме даже правила и немного предшествующих постов с замечаниями модератора не осиливают.
Это я к тому, что опять пойдёт по новой всё уже пройденое. Потому предостерегу от ответов на пост, однако его удалять не буду - как сигнал всем последующим защитникам XNA. Однако повторения буду пресекать нещадно, а то тема вскоре забьётся однотипными постами без капли полезной информации. И тогда не обессудьте.
На все Ваши вопросы ответы могут быть найдены в теме, особенно если Вы правильно поймёте собственно тему. Тут XNA никто не гнобит как глупость. Тут обсуждаются совершенно конкретные вещи относительно революционности XNA в отношении разработки игр (причём профессиональной в-основном), и я прошу придерживаться этой темы. В частности, выше был задан вопрос, на который ответ так и не был получен:
Чего такого есть в XNA, что не было до неё и что привлечёт к ней серьёзные игровые компании?
Простите, по этому вопросу ссылаться на личный опыт (и тем более предпочтения!) бессмысленно. Обсуждаются только конкретные факты как то результаты тестов и т.п.
И ещё. Если ни у кого не будет возражений, я тему переделаю. Постараюсь объективно учесть все доводы в пользу революционности и полезности XNA, и против неё, и организую новую тему (более широкую, но и более жёстко модерируемую).
Возражения/предложения/замечания пока допускаю писать здесь, только учтите, что я их буду добавлять в этот пост, а сами сообщения удалять.
Feanor62rus
24.12.2007, 18:41
На счет C# я совершенно не понимаю его защитников. Да, хороший, удобный, понятны язык. Я сам на нем работаю, но я пишу несложные офисные программы с использованием SQL. Но я почемуто понимаю, что это бестолково использовать для игр. Насчат XNA я не знаю, сам не использовал. Да и в геймдеве(любительском) я моделер а не прогер. Как говорится - время покажет. Может быть и хорошая штука, но уж очень это напоминает попытку microsoft тупо подмять под себя весь игровой рынок. Это настораживает.
Что же до профессионалов. Вот это истина в первой инстанции. И они не используют C#, только С++. Им конечно проще у них штат большой. На фоне этого вопли фанбоев смотрястя особо бессмысленными. Все орут, что на C# можно написать чуть ли не крайсис. Ну дай бог - напишите и я вам поверю.
Ну вот я уже давно так чувствую, что кто-то кинул клич "там нашу любимую XNA бьют!" и сюда повалила куча людей защищать эту самую XNA.
Я тоже заметил)) Сразу 3 человека с регой 23.12.2007 и парой постов за душей сразу в пекло)) Очень интересно.Я конечно не модератор, но вабще я думаю, что тему давно пора закрывать. Ибо она себя исчерпала еще на первых двух страницах. Все важное было сказанно именно тогда, все, что свыше либо перефразировка, либо тоже самое. Спорить можно еще бесконечно долго. Все равно все остались при своих.
Биться головой о стену непонимания и нежелания понять я больше не собираюсь. Я устал, я ухожу©.
За сим все.
PS: Это было мое последнее слово в этой теме.
PSS: До встречи в соседних ветках.
Люди, извините... реально забыл провас.... =)
А учебнек по руцкаму асилить, как и посты между 1 и 6 строницей, осилить так и не смог...
Разбираясь с кешками Java и C#(ну ладно... .NET(ну ладно... Mono)), понил что реализации канешна хорошие, только вот могло быть и лутше... =)
Не буду вдаватся в подробности, как, и насколько. Вынужден скозать, что именно изза этих "могло быть и лутше" нету бесспорного премушества managed платформ(Я и о яве тоже). Премушества есть, над C++, это и безопасность(Некокда не уделял раньше этому внимания)(безопасность во всех смыслах - безопасность целевой платформы, безопасность от ошибок кодера(всмысле не 100% безопасность)), это и скорость(При условии ОЧЕНЬ хорошего кодинга - К сожелению таково кодинга я неувидил даже в коде от M$), это и X-platform. Насчет последнего, относительно Xna&C# - ну не сошлось... очень жаль... иначе действительно "революция" ;)
Блин. Лень песать. Если чо не стыкуется - пинайте.
ЗЫ. Кстати привет, знакомый ;)
ЗЫЫ. О скорости - а вот физику желательно песать на unmanaged... =)
Что же. Судя по всему, Feanor62rus прав. Как будет время - постараюсь сделать отдельную тему уже конкретно про сравнение XNA и всего остального в различных планах.
А пока что рекомендую всем её поклонникам создать тему конкретно о XNA (не о противостоянии с чем-то, а просто о XNA - где скачать, как поставить, какие у кого проблемы и прочее) и в ней обсуждать данный продукт.
vBulletin® v3.8.0, Copyright ©2000-2025, Jelsoft Enterprises Ltd.