С# и 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. Может просто С++ выучить не могите? м?

Всё. Холивар. С++ намного быстрее. На 35%. Это не моя цифра - это microsoft. Учи матчасть %)

Судя по вашей речи - вы не имеете никакого отношения к программерам. "С++ медленнее С#" - бред! Код исполняемый в интерпритаторе не может быть впринципе быстрее бинарного.

О, да! Еще один "великий программер" пришел всех учить!
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#.


Итог - сам учи матчасть


Про бесконечный цикл спасиб :) . Я же написал что этот байт код компилируется в найтив в стартапе (AOT). И значит никакого байт кода. Ну если только метаданные да и только если вас вдруг приспичит юзать
System.Reflection

Два года???? :lol:
О, ну тогда не нам, жалким ламерам, программирующим по восемь лет, Вас учить! Не подскажите, какой институт окончили, или Вы еще в школе?
А теперь о том, почему C# в принципе не может быть быстрее кода на C++:
1) Уборка памяти: как может код, который постоянно обходит все объекты и проверяет, не достигло ли количество ссылок на них 0, может быть быстрее кода, этого не делающего?
2) Как может код, компилирующийся во время выполнения (почти интерпритация!) может быть быстрее кода, этого не делающего?
3) Как может код, в котором все функции виртуальные, быстрее кода, в котором это не так?
4) Да, и еще вопрос вдогонку: как вообще может программа, использующая куда больше библиотек, чем c-шная, быть быстрее ее?

Ну два года я просидел по 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

Да ну? В таком случае, эта оптимизация должна не просто сводить количество дополнительных действий к нулю, а делать его отрицательным!
О! Оптимизирующийся под машину юзера код. Смешно :lol: . Во-первых, мне крайне интересно, что он вообще может использовать, кроме количества ядер процессора. А использование количества ядер процессора требует распараллеливание. А распараллеливание - штука черезвычайно сложная, на должном уровне ее только человек может сделать. Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода. А ведь на ее переписывание при появленнии новой модели тоже время нужно. Кстати, откуда эта утилита будет знать, а нужна ли вообще юзеру такая "оптимизация"? К примеру, хочу ли я, чтобы архивирующийся WinRAR жрал ресурсы с обоих ядер моего двухядерника, или я на втором проце в кваку поиграть хочу? Так что такая утилита должна быть не просто "умной" - она должна чуть ли не сильным AI быть! Что-то я не слышал про получение первой премии Тьюрига...
Про использовании разрядности процессора: оно приносит пользу только в специфических задачах, и их вполне можно изначально скомпилить в двух вариантах. К тому же я не совсем понимаю, как вообще можно написать, например, сетевое приложение, не зная, сколько в каком типе бит у тебя будет. Будешь слать по сети вроде 32-х битное число, а оно - опа! - 64-х битным станет. А откуда компилятору знать, что в нем у тебя не может быть числа, больше чем 1000000, чисто по конструкции программы?
Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец! Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы и т.п., и это много на что влияет. Да, C++-код оптимизироваться на машине юзера не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше.
Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике.
А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет.
Возраст - да. Образование - нет. Гении всегда есть, но их мало, и не надо приводить единичные примеры. И на вопрос об образовании ты не ответил.

Набор интструкций, кстати, у современных процессоров почти одинаков. И еще мне интересно, откуда эта утилита будет узнавать о выходе новых процессоров - получается, что она устареет сразу после своего выхода.

Чет ты гониш. Я же не сказал что под конкретную модель подстраивается. Эт происходит так:

Win32: я загружаю ехе, тут флаги клр есть.
CLR: это флаги джита
JIT: нашли самого левого. О юзера 32 risc проц есть SSE,SSE2,MMX,3DNOW! итд. Буду оптимизить под нехо.

"Набор интструкций, кстати, у современных процессоров почти одинаков."

не спорю - а как насчет расширений? Как об этом узнает прога на С++?

"Оптимизация кода на машине юзера теряет смысл хотя бы потому, что ее конфигурация не постоянна. Регулярно меняются драйверы, устройства, ОС, наконец!"

Драйверы тут не причем, устройства тоже, и вообще что мешает сделать так что-бы при изменении конфигурации, прога меняла свою нативный образ? Да и почему ты не упомянул статический C++? :)

"Такая программа перед каждым запуском должна перекомпилироваться, да и во время работы тоже, потому что постоянно меняется окружение, другие программы"

Другие программы - нет, дригие либы - да. Только есть одно но - либы в .net на много отличаются от с++.

"а, C++-код оптимизироваться не может, но его, во-первых, можно изначально скомпилировать под различные конфигурации, и ставить юзеру в зависимотсти от его конфигурации соответствующий экзешник, а во-вторых, такую оптимизацию на должном уровне написать практически невозможно по причинам, указаным выше."

Вот вот оптимизироватся неможет... Хош сказать что ты должен сделать
столько версий что-бы удолетворяло обсолютно всем конфигурациям?

Да и ктому же про конфигурации. Где ещё как не .net ты можеш одну прогу запускать как на Linux так и на Windows. Да и ктомуже как ты будеш давать всем свои "разные конфигурации" разным пользователям если твоя прога распростроняется посредством диска. Кстати ты смотрел на размер ексешника .NET? Так вот посмотрите.

"А ты хоть знаешь, что такое виртуальная функция? Судя по всему, нет."

- Судя по всему, нет - это судя по чему?

В .NET не так всё "виртулизировано" :) как кажется.

"Кстати, оптимизация C++ - программ во многом базируется на вещах, с которыми в C# играться нельзя - например, на адресной арифметике."

В С# можно игратся с адресной арфмитикой. Читай доки

Во-первых, пользуйся цитатой! Невозможно понять, где цитата, а где ответ на нее!
Эти расширения есть почти на каждом современном проце. Что же касается различий - их использование можно зашить в DLL библиотеки, так как они узкоспециализированны. По той же причине не надо оптимизировать C++-программу под все возможные конфигурации - достаточно скомпилить несколько вариантов DLL-библиотек. Для того их и придумывали.

То есть оптимизация идет только под процессор? И не важно, как и чем он забит помимо программы?
Как я уже говорил, такую оптимизацию сделать нереально хотя бы потому, что эта задача почти приравнивается к искуственному интеллекту. Такие ходы, как при оптимизации на C++, ни одна автоматическая система не повторит.
Только если в сторону тормознутости. Не забывай, .NET исполняется Framework'ом, а Framework на чем написан? На C++ или другом полностью компилируемом языке. И как могут его либы быть качественнее C'шных?
Как уже писал выше, достаточно использовать разные библиотеки. Кстати, такую систему вполне реально реализовать в отрыве от C# для C++.
Размер екзешника такой как раз потому, что программа на C# тормознутие программы на C++ и требует выполнения байт-кода Framework'ом. Касательно Framework на Linux: многое, доступное под Windows, под ним работать не будет. К тому же, если программа пишется грамотно на C++, то она будет компилироваться как под Linux, так и под Windows, почти без изменений в коде.
Интересно, как это - при наличии только виртуальных функций "не все виртулизировано"?
Да, и тут еще один вопросец назрел:
Программа на C# компилируется в байт-код. Даже если он будет у юзера на машине компилироваться в двоичный код, все равно юзеру ты даешь байт-код. А теперь внимание, вопрос:
Что мешает юзеру оказаться хакером, перегнать твой байт-код назад в C# (по ассемблерному коду код на C++ восстановить практически нереально, а по байт-коду код на исходном языке - элементарно) и посмотреть в нем все твои программистские секреты, отключить любую самую хитрую регистрационную систему и защиту от копирования, да и просто найти твои ошибки, наконец? И использовать все это в своих грязных целях, бесповоротно запоров твою программу? Взломав компьютеры всех юзеров, ею пользующихся? За пару часов написав кряк? Вставив в нее вирус? Так что программа в байт-коде - мечта хакера. Не нужно часами копаться в ассемблере и ловить прерывания! Пара секунд - и программа предстает перед ним в своем исходном виде, готовая к любому вмешательству!

Итог: программа на C# медленне программы на C++ хотя бы в силу своей конструкции. Оптимизация не может ничего дать, кроме незначительного выигрыша, из-за сложности самой задачи. Программа на C# практически элементарно взламывается и модифицируется (и я не говорю уже про Framework - т.е. систему с закрытыми исходниками - от которого все зависит! Если в нем будет закладка, баг, дыра - конец всем C#-программам!
Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.
Да ладно? В языке без возможности работы с памятью? Мы точно об одном и том же говорим?

Оптимизация зависит от памяти, от проца, и не много от ОС. Там оптимизация зависит какбы от контрольных точек.
Допустим тебе надо перемножить флоаты. Если SSE будет то код будет вместе с этими SSE.
А теперь скажи на чем написан твой C++ компилятор :)
Ладно можно но сложнее чем для С#
а ты слашал про Obfuscator'ы?
[quote]Вывод: ты можешь быть прав только в случае, если Майкрософт заставит всех писать только под .NET, и не найдется никого, решившегося реализовать похожие возможности для C++ (для которого они реализуются проще). Надеюсь, что этого не случится.[/qoute]
Ты хоть слышал про Singularity - нет? почитай. Про баг в .net framework, это странно но ещё не одного бага с framework'ом небыло.
Да ты уверен? А про 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; }
}
}
}
Я не уверен что этот код работет правильно - но дело в том что поинтеры там есть.

Ась? о_О Чики - пуки. Бубль - гум. OpenGL теперь оказывается ламерский продукт. Надо известить моего закодычного дружбана Джонни. Который Кармак. А то этот ламер совсем обнаглел - использует понимаешь ли опенгл... Ты парень чего "того"? Самый быстрый апи называть опущением? о_О

pokibor в отличие от тебя программист и высказывает факты, а ты нахватался зивини меня дешёвых статей с сомнительных сайтов и пытаешься до всех донести...

Значит он медленнее директа по определению. Вотттактавот.

Я и говрю: все это сводится к написанным под тот или иной вариант функциям. Так на любом языке писать можно. И получится, кстати, быстрее, потому как там будет все с умом сделано под конкретный случай, а не под общий, как тут.
Это ты к чему? Ты утверждал, что C#'е либы быстрее C'шных. Я опроверг это. Ты мне в ответ какой-то глупый вопрос задал. C++'е компиляторы пишутся, как ни странно, на том же C++. Также как, например, Паскаль: спера был написан его компилятор (на чем-то, от Паскаля отличном), потом переписан на самом Паскале и скомпилирован этим компилятором - это обычная практика - писать компилятор на самом языке. Но вот для C# она не проходит, т.к. он компилирует в промежуточный код... То есть компилятор C#, конечно, можно переписать на C#, а вот .NET - бессмысленно. И потому либы .NET в приципе не могут быть быстрее C'шных.
Не-а. Проще. Так как имеем дело с ассемлерными инструкциями, а не с байт-кодом. Ассемблер - самый простой язык, на нем писать медленнее, а не труднее...
Не забывай, у нас этот байт-код будет компилировать FrameWork. Соответственно, как бы там все не было запутано, оно в равной мере отразится как на хакере, так и на Framework, причем в равной мере. Возможно, Obfuscator'ы замедлят появление дизассемблера, но ненадолго. А ведь их применение еще более замедляет выполнение кода.
Читал. И мне смешно. Это с какой же скоростью это чудо будет работать? Да не особо быстрый Windows по сравнению с этой ОС будет как заяц по сравнению с черепахой! Microsoft опять пытается выехать на своем монополизме на рынке ОС, но вовсе не факт, что у нее получится. Во-первых, подходит Google со своей бесплатной осью, которая базируется на Windows, а не начинает все с чистого листа, во-вторых, вряд ли пользователи, если они не дураки, захотят замедлить свой комп и сделать его уязвимым для хакерских атак (байт-код!) непонятно ради чего, в-третьих это чудо выйдет непонятно когда. Похоже, что ты начитался рекламных статеек от Майкрософта и начинаешь кричать всем, что "давайте поддержим дядю Билли!", хотя его за такие дела пора заставить на ассемблере программировать для стиральных машин! :sml:
Это не значит, что их там нет. Впрочем, с такой открытостью кода проще искать баги в программах, чем в Framework.
Слыхал. Только смысла в нем? Его использование превращает язык в C++ с чуть другим синтаксисом и более тормознутым выполнением. И все. Ты, помнится, отсутствие необходимости работы с памятью выводил в преимущесива. Вот и не противоречь себе же.
Работает - не работает - не важно. Важно то, что с их использованием язык перестает быть собой и становится очевидно хуже C++. Так что их в расчет не берем.

Я да я знаю. Не ты мне сказал что Framework написан на С++. А ведь C++ компилятор тоже написан на С++. И в чем разница?

Да на асм писать легко, но это-же дело вкуса. Например мне нравится IL Asm.

Так если не ошибаюсь Dotfuscator был разработан припомоши МС.Надо его юзать.



Эх читать до конца никто не учил? Этот код будет компилироватся во время установки. Да это займёт время. Компилятор называется Bartok.

А ты читай http://blogs.zdnet.com/Murphy/index.php?p=459

Да не хрена - байт-код байт-код читай выше

Это точно.

Да приводил, и я не противоречю себе. Необходимости нет - возможность есть.

А в делфи тоже есть поинтеры. :)

Ты что-то уже совсем потерял нить нашей дискуссии. Это ты вообще к чему? Я все упомянутые примеры приводил в доказательство того, что C# в приницпе не может работать быстрее C++, ты какой-то оффтоп начал писать.
И чем это поможет? Опять никаких противоречий со сказанным мною нет. Как замедлял работу, так и будет замедлять. Как код был прост ко взлому хакерами, так и останется.
Никогда не поверю, что Micro$oft, известная своей любовью к закрытым исходникам, будет поставлять ОС пусть даже в байт-коде! А если и вправду будет, то ой как хакеры порадуются! :lol:
"Вы все еще не в белом? Тогда мы идем к Вам!" - вот что-то вроде этого. Больше походит на громкое реламное сообщение.
Вот именно что читай выше - как не запутай байт-код, он байт-кодом останется. Так что - ломаем, братцы! А написаная таким образом система будет медленной потому, что C# медленнее C++, чего ты так и не опроверг.
Опять бессмысленные сообщения. В компилируемых в двоичный код языках ссылки и адресная арифметика - основа динамичекого выделения памяти, в C# - абсолютно чуждый элемент, использование которого начисто убивает смысл C#.

P.S. Хотя, если все сказанное Knott и представителями мелкомягких правда, похоже, Microsoft отказалась от изначальной идеи Windows в пользу Linux! Ведь если не брать в рассмотрение язык - действительно получается система с практически открытыми исходниками, которую компилирует сам пользователь. И по сути единственным слабым местом становится как раз медлительность языка (что, впрочем, скорее реверанс в сторону неопытных программистов), причем оно вполне может быть преодолено поставкой с сисемой, кроме компилятора C#, нормального компилятора C++ в двоичный код (а какая разница - из байт-кода или из исходного компилировать программу)? Вот только, похоже, при обновлении чего-то в компьютере (а то и просто при появлении нового драйвера) систему придется перекомпилять заново (а как еще - она же "оптимизируется" как-то. Правда, непонятно, как.)...
Впрочем, в любом случае профессиональные программы как на C/C++ писались, так и будут продолжать писаться. Ибо в них обычно задействуются такие ресурсы, что малейшее замедление из-за сомнительных достоинств смерти подобно.
В общем, на революцию (а тем более в игростроении - отрасли, в которой конкуренция по ресурсам наиболее жесткая) не тянет. Совмещение идей Java и Linux - еще куда ни шло, но не более.

Вот письмо, присланное в нашу студенческую рассылку человеком по имени Алексей Лебедев. Отличный ответ на приведенное в начале этой темы высказывание:
Жаль, что Knott покинул форум. Было бы очень интересно узнать, что он может возразить Страуструпу...

Знаю С++ 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 "норм работает" я уже имел счастье наблюдать. Так и не поиграл дольше часу, ожидая "норм работающего" патча. Ну а каких-то ускорений в случае NWN2 не заметил.
Впрочем, к теме это не слишком относится. Как я уже говорил, C# замедляет программы сами по себе. Конечно, на нём есть возможность использовать unsafe-код, да. Но тогда какой смысл в использовании C# как такового?

И при этом просто C разрабатывался таким образом, чтобы предоставлять все даваемые ассемблером возможности для оптимизации, а C++ от него это унаследовал. Простите, но сравнивать по скорости пары C++/ассемблер и C#/C++ просто некорректно. Вы бы ещё Prolog/ассемблер сюда добавили. C# даёт в нагрузку к себе уборку памяти и framework, С++ не даёт в нагрузку к себе ничего.

Да ну? Я как погляжу на современную игровую индустрию - почему-то ребята гонятся за скоростью своих приложений. Иными словами, намерено затормаживать игру будет только глупый человек. Потому что те, кто код свой ради XBOX не затормаживал, обойдут его по всем критериям - и по графике, и по физике, и по AI.
Что же XNA удобнее и быстрее - попробуйте мне ещё доказать, ибо под C++ сейчас столько движков и наработок у всех имеется, что преимущества C# в скорости разработки мне не совсем понятны. Работа с памятью упрощена? И что? Нормальный программист delete где нужно и так писать не забывает, а не нормальный и в C# кучу ошибок наделает.
Microsoft, конечно, известна своим упорством в делании денег. Однако сейчас, похоже, уже не так ситуация, когда она может выиграть. Сравните продажи/использование Висты и XP. Ох, как M$ Висту продвигали! DirectX 10! Давайте все переходите под висту, пишите под Висту! И что? Да плюнули разработчики игр на Висту, к счастью! А некоторые и DirectX в гробу видали - под OpenGL пишут.
Так что M$ в кои-то веки дали по носу с её инициативами.

И ещё ответьте: Вы читали интервью Страуструпа чуть выше? В кратце - для C++ реализованы дополнительные примочки, добавляющие в него преимущества C#. А теперь вопрос - так ёлки-палки, почему ими никто не пользуется, если это так "удобно" и "экономически выгодно", а C#'пом все вдруг вдохновятся, выкинут все движки/библиотеки на C++ и строем пойдут под XNA писать, а? Из-за XBOX? А не слишком ли это глупо - писать заведомо тормознутые игры только из-за приставки, опять же заведомо более тормознутой, нежели компьтер?

Не могу не согласиться.:wnk: Я ведь не говорю, что c# работает быстрее, здесь c++ в фаворе. Каждый выбирает, что нравится, есть же те, кто на бэйсике пишут.
Да, что-то последние проекты так и летают... Последней реально оптимизированной игрой бала Half-Life 2, а остальные делают так, лишь компилировалась.
То же, помниться, было с ХР. Все говорили, что тормозит и никому она не нужна, но сейчас почти все под ней сидят.:wnk:
Sorry, всемени нету. Продолжение следует...

Ну, на бейсике коммерческие игры никто не делает. Всё-таки при их разработки значима не только скорость собственно разработки, но и скорость работы.

Опять не могу согласиться! Конечно, известные игры часто делают спустя рукова, но хитами такие не становятся. А вот неизвестную игру так делать - путь к поражению.
И опять же к медлительности - не забываем, C# сам по себе замедляет игру при том, что основные процедуры давно уже упакованы в библиотеки. Я хочу сказать, что все те же тормоза при разработке на C# останутся + добавятся ещё тормоза языка. И какой смысл в C# тогда?

В случае XP под неё все достаточно быстро перешли, и там майкрософт эксклюзив пробить не пыталась.

Жду конкретных возражений.

Ну тут и баталия однако =) Я программирование знаю плохо но меня почему то больше убедил pokibor
=)

Согласен.
После 4 патча у меня всё нормально работало.
Ну на счёт оптимизации. Помимо желания у разработчиков игр за спиной издательство, которому только деньги нужны. Соответственно это резко ограничивает время разработки.

такой вопрос: идёт ли работа DirectX под Framework через байт-код? Т.е. основная нагружаемая часть железа в играх - видео карты, процы же редко сильно нагружаются, а если игра через XNA идёт медленней только на процессоре, а на видео карте не отражается, то проблем нету и я могу плюнуть на относительную тормознутость. А вот если отражается на видео карте, то XNA говно полюбэ, ведь разрабочики всегда выжимают всё до последней капли из ведео карты(

Очевидно, что частично. Иначе как через байт-код, программа под Framework работать не может. С другой стороны, реализовывать типовые функции из DirectX через байт-код было бы очень тупо даже для майкрософта.

ДА НУ??? То-то игры за тормознутость даже на топовом железе ругают... :lol:
Через видеокарту идут только достаточно низкоуровневые операции плюс шейдеры. Всё остальное грузит процессор. А игра - это, вообще-то, не только графика. Это ещё и физика, и огромные объёмы памяти. А память у нас в C# с автосборщиком. И вот этот автосборщик должен постоянно проверять, а нельзя ли очистить вот эти полтысячи ссылкок? А может ту тысячу отчистить? Догадываетесь, из-за чего будут программы тормозить? И даже всеобщий переход на физические ускорители и (о, Боже!) ускорители AI ситуацию с памятью не спасёт, ибо данные-то игровые в родимой ОЗУ хранятся, а там у нас сборочка памяти работает-с.
И скажите мне честно: Вы планируете на физический ускоритель и ускоритель AI переходить, а? Не думаю.

Щаз! Просто запустите Готику 3 на каком-нибудь старом Пентиуме, а потом уже будете говорить о плевках на относительную тормознутость.
"Система всегда тормозит со скоростью самого медленного своего компонента".

Разработчики выжимают всё до последней капли из всего, откуда только могут её выжать. Если Вы не в курсе, именно мощь процессора стоит на пути улучшения искуственного интеллекта и физики игры. Физические ускорители пока проваливаются, а об ускорителях AI ничего, кроме туманных проектов, и не слышно.

на своём core 2 duo ни разу не наблюдал загрузку проца выше 60% даже в крайзисе. все тормоза в играх решаются ослаблением графики, что не должно влиять на нагрузку проца значительно.

А, ну Вы бы ещё на Cray'е протестировали. :lol: Создатели игр, как правило, редко ориентируются на топовое железо, а стараются заставить игру работать на менее мощной конфигурации.
Далее, насчёт ослабления графики - это зависит от реализации этой самой графики. Конечно, использованием топовой видекарты с последней версией шейдеров можно несколько разгрузить процессор, но всё-таки конфигурации у пользователей, как правило, сбалансированные. Ну и к тому же шейдеры - это отдельная статья программирования, не имеющая отношения к основному языку написания программы.
Кстати, Вы не думали, что в некоторых случаях, ослабляя графику, снимаете нагрузку именно с процессора, который вынужден тратить время на софтовую эмуляцию отстуствующих в видеокарте возможностей, а?

Ну и жду возражений на остальные аргументы, особенно по поводу памяти. Да и по поводу физики с AI тоже не помешает. В Кризис я, правда, не играл (и не собираюсь), но ещё не видел игры с нормально реализованным AI, а физика была нормально реализована только в специальных демках, только на то и рассчитаных. Это при том, что все алгоритмы для улучшения и того, и другого уже давно известны. А всё почему? Да как раз потому что если ЭТИМ загрузить процессор, то он загнётся всё считать. Потому сейчас и особо не разгоняются в этом плане, особенно по статье AI.

Далее, не лишне Вам будет напомнить, что Core 2 Duo он как бы немного двухядерный, а для получения максимальной выгоды от второго ядра в случае одного приложения нужно это самое приложение особо оптимизировать. Так что Ваши 60% могут быть не следом того, что Кризис не может загрузить процессор на все 100%, а следом плохой оптимизации под двухъядерный процессор. Только и всего.

Не стоит ориентироваться на видеокарты прошлого поколения, подавляющее большинство видеокарт сегодня имеют аппратную поддержку всех технологий для игр, имеющихся в момент выпуска видеокарты. Если запускать игру при высоких настройках на видеокарте 2х летней давности, то это проблема запускающего.
их нет.
а я не про это говорил, я говорил, что если переделать игру под Framework, то из-за несильно возросшей нагрузке процессора тормозов не будет, т.к. он очень сильно не нагружается из-за слабого ИИ и физики. В данный момент процессор не так сильно нагружен, но и не выдержит всех обсчётов физики и ИИ, а вот работу через Framework справится. Он же не каждые 10 секунд проверяет ощистку памяти. Да и не совсем это байт-код, он всё-таки компилируется перед запуском из MSIL в машинные коды процессора.

Это не проблема запускающего, а убытки издателя, который стремится впихнуть как можно лучшую графику в как можно меньшие требования. Далее, насчёт того, какие технологии поддерживаются в современных видеокартах, хотелось бы знать Ваш опыт написания шейдеров. Дело в том, что шейдеры накладывают приличные ограничения на обрабатываемое собой. Всё, что в них не укладывается, идёт в нагрузку на процессор.
А насчёт "Не стоит ориентироваться на видеокарты прошлого поколения" Вы скажите издателям игр. К счастью, пока они думают несколько иначе, а не заставляют всех повально на сверхновые железяки переходить.

А смысл продолжения спора, если часть контраргументов не опровергнута?

Точку зрения "давайте оставим технологии всё как есть, перейдём на фреймворк и будем радоваться жизни" будете издателям говорить.
Нет, конечно, если написать на Framework какой-нибудь Quake 3, он, конечно, полетит и на семпроне. Вот только такая игра провалится в конкурентной борьбе.
Железо, к сожалению, развивается медленнее алгоритмов, и зачастую как раз под них, как показала практика.
И насчёт двухядерника тоже возражений нет? Просто я не вижу реальных доказательств, что в сбалансированной конфигурации процессор играет меньшую роль, нежели видеокарта.

А если он не каждые 10 секунд будет проводить очистку памяти, то она очень скоро банально забьётся ненужным для игры в данный момент мусором. Отлично - будем покупать в 2 раза больше ОЗУ, чем реально требуется игре. Это при том, что Вашему Кризису 2 гига рекомендуется. Значит, потребуется четыре. Одному ему. Весело. На цивилизованом западе, где игры покупаются честно, даже тамошние богачи разорятся так своё железо обновлять.

О, ну если этот байткод будет компилится в машинные коды процессора, то я с чистой совестью запущу какого-нибудь "Ведьмака" и подожду полчаса до запуска игры, пока код соизволит скомпилится. Зато потом буду радоваться жизни. До следующего запуска.
Нет, я всё-таки ещё надеюсь добиться у Вас объяснений, что же такое даёт C#, чего не даёт C++ и что позволит ему одержать верх.
Сборщики памяти для C++ есть (ими никто не пользуется). Библиотеки те же самые, что и для C#, есть. Так что же такое эта XNA даёт (кстати, она вроде как на DirectX 10, а потому по определению работает медленнее этого самого DirectX 10, уже не говоря про быстрый OpenGL), что игры будут под неё писаться в условиях противостояния красот и фишек? Ответ X-BOX не принимается т.к. насчёт заведомой тормознутости приставки по сравнению с компьютером опять же возражений не было.

издатель ориентируется на игроков своей страны, а это, в основном, западные игроки, которые не сидят с одной видеокартой по 3 года.
небольшой есть, просто посмотрел ради интереса, но серьёзно не занимаюсь.
ещё при появлении Hyper-Threading 3 года назад многие игры начали обзаводится работой в 2х потоках, даже патчами, врядли эта тенденция остановилась.
мой друг года 2 назад, очень комфортно играл в современные игры на GeForce 6200 и P3 1.0 GHz, в то время, когда у меня стояла GeForce 5500 и P4 3.06 GHz и игры шли с более низким качеством.
игры под X-BOX360 идут под .NET и запускаются не пол часа, хотя идут под более медленной системой. Да и падение производительности максимум 10%, иначе игр под .NET вообще бы не было
Но появляется мультиплатформенность, позволяющая играть на других осях, виндовс обязана своей популярностью именно играм, так вполне можно будет запустить игру с одного диска и под линуксом и под маком.

ЗЫ соре за даблпостинг, на клаве какая-то кнопка начала "отправлять быстрый ответ"

Верно-верно. Это в-основном западные казуальные игроки, которые не могут сами заменить видеокарту, у которых кроме компьютера ещё и приставки есть, у которых вообще цены повыше чем у нас будут... И которые именно что сидят с одной видеокартой по три года хотя бы потому, что не так интерисуются компьютером.
И в то же время есть хардкорщики и пресса, которые в играх разбираются и которые могут обеспечить достаточную рекламу и раскрутку игры (рекламную компанию Halo 3 не каждый может позволить). То есть нужно угодить и технологиями, чтобы игру расхвалили, и достаточно низкими системными требованиями, чтобы она шла у как можно большего круга обывателей.
Кстати, вот интересно - почему мы считаем, что Запад поголовно как сыр в масле катается? Это вовсе не так. Уровень жизни там выше, да. Но не будем забывать, что у нас многие люди вообще и компах только в новостях слышали.

Честно говоря, это и видно.

Оптимизация под два потока вовсе не так проста, как кажется.

Года два назад? Это при том, что для вышедшего в 2004 году Half-Life уже требовался минимум 1.2 ГГц процессор, а разработчики занижать требования ох как не склонны? И физика, и AI нормально работали? И почему я банально не верю...

Они компилируются в код ядра, да? :eek: И не тратят на это времени? Ага, как же.
А как насчёт того, что по данным Майкрософта ( http://forum.igromania.ru/showpost.p...28&postcount=2 ) замедление 35%, а?
А хороших передовых не тормозящих игр под .NET и нет. Ну а сапёра какого на C# в пример приводить как-то несерьёзно. :lol:
Так игры и на Basic'е есть. Будем кричать, что Basic C++ рвёт на запчасти теперь?

Ага, сейчас пойду ставить на компьютер мак специально чтобы погонять под ним в квейк какой. Виндоус, как не печально, прочно укрепился на роли популярной домашней системы, иначе бы игры преимущественно под него не писали.
Далее, запуск под Линуксом и Маком - это лишь теория, т.к. под ними ещё должен появится не только базовый фреймворк, но и DirectX (при том, что 10 вроде как для висты эксклюзив пока... или уже нет?, а XNA на десятке), и всё прочее...
Между тем вот незадача - C++ сам по себе кроссплатформенный язык, а OpenGL есть под тем же линуксом. То есть можно перенести игру с OpenGL без серьёзных перемен в коде. Однако ж почему-то под OpenGL не таки много игр делают (кстати, вот это зря!). Так может, дело не в мультиплатформенности?
Ну и насчёт того, что XBOX медленнее компа я уже говорил, да и Вы это сами написали.

CMogilko

Давай подождем пока со спором. Ты еще не знаешь многого. Когда будем проектировать движок, ты сам многое поймешь. Сейчас ты просто не совсем себе предстваляешь, как работает двигатель игры и как именно он использует ресурсы процессора и видеокарты. Поэтому порой пишешь не совсем правильные ыещи и пытаешься всё под одну гребенку загрести (что не получится - есть там куча неочевидных нюансов, влияющих на производительность). Поэтому мы с Покибором и затеяли написание учебного проекта - игры.

pokibor

Давай лучше статьи писать:) А то тут спор глухого с немым получается:)

Не могу не высказаться по этому поводу.
Сам себе противоречишь: сначало говоришь, что все крупные разработчики гонятся за скоростью, а теперь приводишь такие игры. Хотя 3-я готика с последним патчем на рекомендуемой конфигурации и не тормозит (по крайней мере у меня)
Да вы что? Кто плюнул? Кармак?
Опятьже Кармак и некоторые энтузиасты. Да и вообще, все известные игры на огл сделаны восновном на кармаковском движкеОсновное отличие С++ от С - это поддержка ООП (ктобы этого не знал?)
И говорить, что самое главное в движке - ООП, это бред. Есть и неооп движки.
-----
Если виста тормозит на вашем компьютере, то это не значит, что Виста - говно.
И разработчики современных игр не учитывают, что у пользователя видеокарта 10 лет не менялась.Однако прогресс давит на разрабтчиков. Если бы все ориентировались только на скорость то 3D графики так бы и не появилось.И чегоже печального. Чтобы говорить, что гейц дурак, нужно как минимум быть умнее его ). А вы наверное создали свою ОС, которая лучше Виндовс?
А что разработка игры - это просто и легко. К томуже если это даст хоть 5 фпс, это того стоит. и современные приложения делают обычно больше 2-х потоков.
-----
Никто и не спорит, что С++ быстрее С#, но говорить, что последний - говно и никто не будет на нем писать как минимум глупо. Игры и движки на нем делают и есть готовые. А если вам хочется оптимизации, пишите под DOS, он вообще не больше 1мб памяти ест, вот только боюсь проблемы будут.
Почемуже на С# будут писать? Может потому что в это вбухивает MS? Или они просто не имели дело с pokibor'ом? =)
Неужто нужно быть гением, чтобы понимать как работает движок?

serializer, во-первых, попрошу воздержаться от бранных слов. Во-вторых, [CCCP] Monster про спор немого с глухим написал верно, так что воздержусь от своих комментариев, особенно после Вашей последней фразы, отлично Вас иллюстрирующей. В-третьих, перечислите игры "только под DirectX 10 и Висту" (как и хотела M$) и тогда поймёте, кто именно на неё плюнул. В-четвёртых, я и сам на C# пишу. Удивлены? А я пишу, потому что всякую мелочь на нём писать действительно быстрее и удобнее, нежели на Visaul C++ под Win 32. Там есть быстрый и удобный конструктор оконных приложений и нет глюков Борландовского Builder'а. Но вот писать на нём серьёзную игру мне в жизни в голову не придёт по указаным выше причинам. И по ним же это не будет быстрее и удобнее, нежели на C++.
И перечитайте название темы: "С# и Xna - революция в игросторении". Речь идёт конкретно об игростроении, причём в-основном о серьёзных коммерческих играх.
P.S. А статьи я пишу, только медленно. Сейчас вот хочется собрать небольшую программу по нечёткой логике. Кстати, собираю я её на C#, ибо для небольших оконных приложений он вполне удобен. Вот так.

pokibor
Я написал свои коментарии и четко их аргументировал.
Отвечаю вопросы:

Вот уж не думал, что это может так обидеть другого человека, а темболее и "иллюстрировать" меня.
Естественно, что на заре ДХ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 - факт. Кармак далеко не самый глупый человек, его движки вроде как покупают за боооольшие деньги.
Про ООП Вы ответили на какой-то выдуманный собой вопрос, моего же аргумента и краем не коснулись.

Это не ко мне. Хотя я бы её не закрыл в любом случае. Писать есть чего, людей, разбирающихся на должном уровне в теме, нет.

Если это Вам действует на нервы, то опять же см. про иллюстрацию. Я собеседников на форумах привык уважать и обращаться к ним соответсвующе. На "ты" я только с теми, кого хорошо знаю.

pokibor
Пишу последний, надеюсь, пост в этой теме:
1 . Будут писать только потому что МС так надо. И МС вложит масимум сил и денег для этого.
2 . 3 . Про ООП я взял это из темы "Проектируем ядро игры"
4 . Вот именно, что все огл игры основаны на кармаковском движке. Покупают? Unreal Engine 3 (это тот что с ДХ10) тоже покупают и по статистике гораздо больше.
5 . Очевидно, что API, основанное на СОМ объектах будет медленнее
6 . "разбирающихся" в чем? вы хотите найти людей, которые смогут оспорить ваше мнение. Тогда на gamedev.net или подобные сайты. А здесь вы таких точно не найдете.
7 . Если для вас Ты - это оскарбление, то с вами я буду на ВЫ.

А вот это утверждение абсолютно бездоказательно и пока что ни капли не подтверждено.
Если по этому вопросу мы согласны, тогда какого ответа Вы от меня ожидаете?
Тогда и цитату оттуда приводите. Я пока не понимаю, как Ваш ответ к текущей теме относится.
А подавляющее большинство игр написано на C++. Если брать Вашу логику - то вопрос о C# вообще закрыт по умолчанию.
А я и не спорю, что на DirectX 9 (вот про 10 не надо! см. ситуацию с Кризисом по ссылкам) больше игр, нежели на OpenGL. Вы, похоже, забыли исходную фразу.

Играет роль не только COM, но и аппаратная реализация - в частности, у славящейся этим NVidia.

Стоп-стоп-стоп. Перечитайте-ка первый пост. Тему я создал? Это я изначальное мнение о "революции в игростроении" оспариваю. Если Вы не можете моё оспорить - это не значит, что другие не смогут. Сюда ходят и грамотные люди - [CCCP] Monster, например. Или Вы считаете себя самым умным человеком на этом форуме?
А на gamedev'е скорее с моим мнением согласятся, а не оспорят его.

Лично для меня "ты" это не оскорбление, поэтому можете обращаться ко мне как угодно. Однако у меня есть своё мировоззрение, по которому я ко всем недостаточно знакомым людям обращаюсь на "вы".

pokibor
ох... Чувствуется мне доночи здесь сидеть чтоб вы поняли мои слова.
Посмотрите в интерете - что сделала МС для продвижения висты: начиная от обильного пиара, зпканчивая специальным специальным сертиыфикатом поддержки висты. (тема закрыта)

Да прочитайте мои слова! Что мне оспаривать. То что С++ быстрее # , давно доказано. А оспаривает пусть автор темы. Я оспариваю лишь то, что "C# и виста мастдай"
насчет [CCCP] Monster
Он сюда заглядывал толко ничего не писал.(тема закрыта)
Возможно вы преставляете меня дураком, я себя уникумом несчитаю. (тема закрыта)Если вы скажете что все должны перестать писать на C#, только потомучто он медленнее, то врядли.
Опятьже посмотрите движки на С# (тема закрыта)
[CCCP] Monster
была о медлительности с#, а стала о том, что C# говно и не надо на нем писать
pokibor
fixed

pokibor
serializer

Я вот вообще не понял, о чем был спор

Смотрю, смотрю, и вижу, чем эти усилия закончились. Из всех моих друзей на Висте никто не сидит, в Висте куча багов, постоянно уязвимости находят, DirectX 10 реально ни одно игре не нужен, "купленно" нужен лишь немногим играм... Именно что тема закрыта. Micro$oft в кои-то веки промахнулся. Вовремя Билли слинял с руководящего поста. :lol:

:eek: :eek: :eek:
Простите? Вы точно нигде описку не допустили? C# быстрее С++? :eek: Тогда ещё раз ссылки на доказательства ("давно доказано"?), пожалуйста.
C++ быстрее C# по работе кода (на 35%) и равен ему по скорости - для разработке игр, в которых всё равно интерфейс свой, а не стандартный. А с учётом имеющихся наработок на C++ - даже по скорости разработки игр он быстрее.

Тогда ссылку, где я это говорил. И где вообще кто-нибудь это говорил. C# разумен только для разработки оконных приложений, не слишком требовательных к ресурсам. Про Висту промолчу из цензурных и оффтопных соображений. Пока ни капельки не ощутил необходимости и желания переходить на неё с XP. Как и любой из моих друзей.
А движки и на Прологе можно сделать. Вон на бейсике есть. Будете и про бейсик также спорить?

pokibor

Директ Х 10 дает возможность пользоваться аппаратной поддержкой геометрических шейдеров - это его единственное сильно отличие от 9-го. Правда, ведутся работы для адаптации интерфейсов для XP.

Кстати, в отличие от историков и политиков, у программеров есть мощное оружие для спора, железные факты. Пишем код в обоих технологиях, делающий в принципе одно и то же. Берем таймеры выского разрешения и анализируем. И конфу машины, на которой проводились испытания не забудьте.

Кстати, задач рекомендую разных понаделать. Математических, выборки, прохода массива с несколькими условными преходами в теле цикла и т.д.

Кстати, о SSE1 оптимизациях забываем. Они позволяют, воспользовавшись 128-битными регистрами математического сопроцессора, считать за один машинный такт 4 числа с плавающей точкой в формате 32 bit IEEE. С# в силу своих особенностей использовать эти оптимизации пока не в состоянии.

И кстати, по контексту, Покибор не говорил, что Си Шарп вообще не достоин использования. Он говорил, что такие сложнве и требовательные к ресурсам приложения, как современные игры, писать на Си Шарпе, использующем ДотНет как основу, было бы не разумно.

Я бы выделил вот так. Последние расширения OpenGL, кажется, дают тоже самое и не требуют Висты. Кстати, фраза "ведутся работы для адаптации интерфейсов для XP" меня умиляет. Майкрософт осознаёт провал своих планов с популяризацией Висты по ходу дела.

XNA на dx9 пока работает.
Сейчас делают dx10.1 в котором, как обещают :wnk:, устранят основные глюки и тормоза dx10.
Вообще, меня, наверное, не так поняли. Я не говорю, что XNA уделает связку C++ + (калабур:wnk: ) dx или OpenGL. Просто появилась реальная альтернатива этой паре. Это не тормоза типа GLScene или Dark Basic. На предтече XNA, MDX, выпущена NWN2. Пример NWN2 доказывает, что на .NET можно делать коммерчески успешные продукты и оправдывает существование XNA.
Хотя, в сегодняшнем виде, XNA пригодна только для casual проектов.

Чем же она реальная, эта альтернатива?
:lol: Извините, но после такого сравнения с Вами говорить не о чем. Сравнить далеко не лучшие движки "для самых маленьких" с XNA и делать из этого какие-то выводы... это признак из разряда "слышал звон..."

Простите??? Каким боком NWN2 связана с .NET? Инструментарием? Да я в курсе, что инструментарий у NWN2 на .NET написан. Это как раз и проходит по статье оконных приложений, не слишком требовательных к ресурсам... точнее, как раз из-за того, что он на .NET, редактор NWN2 и любит кушать.
В основе NWN2 лежит Electron engine, построенный на старом Aurora Engine, который уж точно с .NET никак не связан. Единственно, что в NWN2 может быть написано на .NET - некая внешняя обёртка, т.к. движок довольно специализирован под RPG. Если XNA будет настолько крутой, что предложит все необходимые процедуры для любого жанра, причём на уровне скорости специализированного движка, то я готов взять свои слова о ней обратно. Но пока что позволю предположить, что универсальный быстрый движок под любой жанр - это нечто из области фантастики, тем более в исполнении Micro$oft.

А с этим я и не спорю, но в теме заявляется "С# и Xna - революция в игросторении". Так что о создании клонов Lines и тетриса речи не идёт.

Я каким-то образом открыл в netreflector'е либы nwn2, хотя не все. Там были классы дла магической и ролевой систем, а так же, не помню точно, что-то связанное с рендером. Не спорю, может, вы и правы.

Я сравнивал движки не на C++ с XNA. Это все известные мне доступные движки из этого рода. Если вам известны какие-то другие, напишите, плиз, буду благодарен.

Бысторотой? Нет. Удобством? Дело вкуса. Легкостью? Как посмотреть. Реальность альтернативы я рассматриваю, прежде всего, исходя из наличия, или нахождения в стадии разработки, коммерческих проектов, основанных на данной альтернативной технологии. А такие есть: к примеру http://www.visual3d.net/.

Я не знаю ни одного нормального движка, написаного не на C++. Наверное, поэтому серьёзные игры пишут именно на C++, а не на чём-то другом, как Вы считаете? Стало быть, если Вы сравниваете XNA с этими отсталыми движками, то она автоматически идёт в их категорию - используемых новичками в казуальных проектах движков. Что ж, такой роли XNA я не отрицал, для написания проектов уровня Quake 2 по графике она подходит и даже тормозить не будет. Но вот на "революцию в игростроении" такое применение XNA как-то не тянет...

Так есть и на бейсике игры, и на Blitz3D (тоже ещё тот смех). Хоть один известный тайл либо компанию назовите. А коммерческими и казуальные проекты являются. В общем, см. выше. В категории движков для самых маленьких как раз майкрософтовского продукта не хватало...

Knott
Насчет XNA. XNA действительно полезная утилита.Конечно же в ней легко работать(у меня XNA нету,но знаю по обзорам).Но с её установкой куча возни. Хоть мне и 10 лет,скажу,что лучше использовать OpenGL 2.0.

из серии "Слышал звон, но не знаю где он". В ХНЕ копаюсь около 2-х недель
нет никаких проблем с установкой кроме криворукости и невнимательности. Ваше утверждение по поводу OGL2.0 смешно.

ну а теперь обо всем по порядку :D

быть может, в плане понимания внутреннего устройства игрового механизма

Всякие споры о том, программы на каком языке написаны, на шарпе, или на плюсах - это очередной бессмысленный спор. pokibor, некоторые люди языки программирования знают и по 10 лет, и код пишут не ахти какой. На личном опыте убедился. Преподаватель паскаля в нашем городе в престижнейшем учебном заведении вместо цикла в 25 повторов написал в коде программы 25 конструкций if then else.

И про нативный vs IL код. Выскажу свое мнение. Процессору нет разницы на чем написана прога, на шарпе, па плюсах, на асме, или вообще на перфокартах. Процессор машинный код выполняет, который ему готовит транслятор(Прошу прощения за грубость в определениях). И пофиг, что программы на шарпе грузятся чуть подольше.

Кстати, а Вы не сталкивались с проблемами утечки памяти?(об очистке ее чуть пониже).
Так вот, таких проблем нет в .NET, т.к. во время "компиляции" на машине конечного пользователя происходит оптимизация именно для его машины.

Как раз для обучения программированию шарп очень подходит в силу своей легкости в понимании. Человек сразу учится ООП, а значит, очень велик шанс что в его коде по мере роста опыта будет расти и качество. И не будет такого бардака, который можно написать в делфи, плюсах, или перфокартах.

В интернете где то статью читал, в ней было сказано примерно следущее "Если Ваш компьютер тормозит - купите новый компьютер", а еще там было сказано "Выполняйте только те задачи, которые от вас требует задача", и еще там было сказано "Компилятор лучше знает, когда производить сборку мусора и очистку памяти, оставьте это на его совести". Последняя цитата сказана к тому, что в плюсах Вы можете после каждой опирации выполнять сборку мусора. Но подумайте, в плюсах процесс сборки мусора - это команды, это процессорное время, и далеко не факт, что Ваша забота о памяти нужна будет конечному пользователю. Напишите блокнот с офигенно хорошо продуманным механизмом работы с памятью, но кому он нужен, когда есть Word? пусть он ресурсов ест больше, пусть он грузится дольше, но зато он много чего умеет, так что аргумент "Он не умеет работать с памятью" не уместен.
Имхо в самом начале получения программерского опыта нужно получать и осваивать азы технологии программирования, а не очистку памяти, поэтому шарп как нельзя кстати подходит для этих целей.
ps// Уф.. написал много чето.. иду дальше...
Нет, ну это просто смешно, простите, без слез прочитать это не получилось. .NET FRamework - Он один. Это проще говоря библиотека классов, коих во фрэймворке тысячи. Какакая бы конфигурация компьютера у пользователя ни была, фрэймворк останется один. Если программа написана с использованием стандартных средств .NET, в сам эхешник попадут описания только классов и методов, которые основаны на уже существующих классах платформы .NET В этом плане Win32 приложения проигрывают, и ненадо спорить, я лет 7 на делфи кодил, знаю с++, подключение любого хедера к проекту вызывало прибавление в "весе" конечного эхешника, т.к. эти нативные компиляторы для каждой проги вешают оди и те же включения. Представь себе 20 программ написанных на .net Framework 2.0, общий вес которых максимум 200 кб без использования графики и нестандартных методов. Размер дистрибутива .NET 2.0 - примерно 20 МБ. А теперь возьмите 20 нативных Win32 приложений. В каждом из них куча повторяющегося мусора. Конечно, можно писать только с использованием WinAPI, но это как то... мягко говоря сразу в проигрыше по сравнению с разработками на шарпе и .NET. Опять же, это все мое имхо.

А кто мешает систему защиты на с++ написать?

А кому этот самый юзверь плохо сделает, когда прогу запорет? себе разве что.

А как он взломает компьютеры? каким способом? Если, я, скажем, тот же самый блокнот написал на шарпе, в котором работы с сетью нет как таковой, то КАК можно будет взломать комп? силой мысли только если.

Ага, изменить то можно, а вот контрольная сумма md5 или sha1 совпадать не будет.

Раз уж вы заговорили про шейдеры, то вы наверняка в курсе, что XNA устроен таким образом, что отрисовка графики происходит используя шейдеры. А что такое шейдеры? чето все говорят, пиксельные шейдеры, вершинные... Шейдеры - это программы, которые исполняются непосредственно графическим процессором, а не ЦПУ. Шейдеры придумали чтобы графика рисовалась быстрее, а не физику или ИИ считать.

в оффициальном руководстве написано что требуется 3 гб оперативки м 768 мб видеопамяти

Прошу прощения, но пока читал эту тему, такое ощущение сложилось что Вы просто папа в программировании. В Шарпе одна отладка только чего стоит, я уже молчу о некоторой кроссплатформенности. Кстати, о кроссплатформенности. На компьютере у меня установлен WindowsXP. У меня есть КПК с ОС Windows Mobile 5.0, так же мобильный телефон с ОС Windows Mobile 5.0. Решил написать для телефона свой ирц клиент. Начал отлаживать его, сначала реализовал работу с сокетами, потом UI. В итоге, 1 раз нажав на F5(Build and Run) получился эхешник, который запускается и КОРРЕКТНО РАБОТАЕТ на смартфоне, кпк, и компьютере. А ВАМ слабо ТАКОЕ на Ваших этих плюсах?.
А в плюсах есть сериализация?
А рефлексия?
Кстати, об отличиях шарпа и плюсах можно почитать здесь

у бокса характеристики железа по сравнению с компьютером(в дальнейшем ББ) ниже, да и у ps3 тоже, однако работают они в разы быстрее чем комп. на пк в ос встроены кучи сервисов, драйверов, программ. Запуская игру на ББ он(ББ) помимо обработки игровых данных еще и все сервисы операционной среды обслуживать должен, которые между прочим так же едят память.
Игровая приставка устроена проще. Там нет никаких вордов, нету интернет эксплореров, нету звукозаписывающих программ, или программ для записи диском\эмуляции дисков. Там реализован базовый функционал, которого достаточно для того, чтобы запускались игры и воспроизводился медиа контент. Больше и не требуется.

Вас никто не заставляет использовать ОС Windows. линукс и макинтош последнее время набирают популярность

кстати, вот несколько полезных ссылок о .NET:
http://www.interface.ru/fset.asp?Url...t/mic_net1.htm
http://msdn2.microsoft.com/ru-ru/net...83(en-us).aspx
http://www.statmod.ru/3-5/programmin...apov/index.htm

ну и еще добавлю.
Каждый выбирает то, что ему больше нравится. Нравится тебе - пиши хоть на асме(вспомните kkrieger-beta.exe весом в 65 кб, и который вобрал в себя все самые современные рюшечки по тем временам).
Может быть с++ действительно чем то хорош, но полтора года занимаясь кодингом на языке C#, плюсы вспоминаю как страшный сон.
В перспективности C# сомневаться нет смысла, сомниваетесь? посмотрите какие деньги им платят.
Вы можете сидеть на своих плюсах и месяц вылавливать глюк с утечкой памяти, ибо где то неправильно указатель поставили, или рендерер писать.
В современном ритме жизни не имеет значения, сколько лет ты знаешь плюсы, асм, пролог, меркури, или 001111011011. Главное - RAD. Опять сомниваетесь? тогда почему придумали VCL в делфи и билдере? Можно сидеть и париться с апи пытаясь нарисовать окошко с текстовым полем и кнопкой ОК внутри, только надо ли оно, когда можно парой-тройкой кликов реализовать это все ВИЗУАЛЬНО.
C# является одним из представителей высокоуровневых RAD языков.
C# легко читаем
C# легко усвояем
Я не сомневаюсь в том, что на шарпе, а точнее на платформе .NET в скором времени начнут появляться довольно неплохие игры.

Если еще что нибудь вспомню - напишу.

Как средство разработки игр для начинающих XNA - очень хороший вариант. Она в первую очередь ведь и рассчитана на студентов и энтузиастов. Я очень сомневаюсь что те, кто сейчас известен такими играми как HalfLife, HalfLife2, Crysis прям с первой попытки писали нечто напоминающее игры с суперсовременной меганавороченной графикой. И вообще, разве графика в играх главное??

pps// то, что в шарпе пишится 1 строчкой кода, на плюсах иногда минимум в 2 строчки выходит.

А может напишите, почему? OpenGL (так, на минуточку) - самый быстрый API для трёхмерной графики. А какие преимущества у DX10, на котором XNA построена?

Во-первых как модератор прошу воздержаться от спорных в плане цензурности выражений. Тут Вам не башорг.
Во-вторых, имейте уважение к собеседнику и правильно пишите ники.
В-третьих, по существу:
Про то, кто какой код пишет, Вы абсолютно не в тему. Мы обсуждаем не криворукость отдельных программистов, а достоинства сред разработки/языков/компиляторов/библиотек.
Далее, последнее утверждение демонстрирует Вашу абсолютную некомпетентность в рассматриваемом вопросе. Процессору, конечно, нет разницы, какой код выполнять. Зато юзеру есть разница, что код на C# выполняется Framework'ом, и в нём производится автоматическая сборка мусора в памяти, что вылевается в 35%'ое замедление программ на C# по сравнению с аналогичными на C++. Учите матчасть, уважаемый, прежде чем других в некомпетентности обвинять.

Нет, не сталкивался. В своих программах, по крайней мере, потому что умею их отлаживать. А если кто-то не умеет - это, извините, их проблемы. Такие люди и на C# с кучей ошибок напишут.
Так вот, в .NET таких проблем нет ценой замедления работы программы (см. выше про сборку мусора), а "оптимизация под конечную машину" - это чушь и рекламный трюк Micro$oft. Мне ещё никто толком не смог объяснить, под что там она оптимизируется и каким образом ей это удаётся.

Как раз для обучения он не подходит в силу отсутствия заботы о памяти. Программист сразу расхолаживается, а потом, когда у него просят написать быстрый код на C++ и появляются те самые утечки памяти - просто потому, что бедняга не привык её очищать.
А то, что C++ - эталон в плане ООП, Вы слышали? В C# ООП практически чисто C++'ное.

Ага, так и хочется добавить "спонсор статьи - Micro$oft", ибо так оно и есть. Перечитайте только заголовок темы, там немного об играх как бы говорится. Стало быть, Вы утверждаете, что "если для Crysis на C# требуется суперкомпьютер - купите его, это ваши проблемы"? Ну-ну, а теперь идите объяснять это же миллионам пользователям. И что же это злобные игроманцы в своих статьях неимоверно тормозящие игры обругивают... Наверное, не хотят купить компьютер помощнее, не слушают увещиваний Micro$oft'а. Уууу, нехорошие!
А про цитатку - этого добра у нас тоже навалом. Вон почитайте Страуструпа где-то в теме.
Далее, Вы опять забыли, что мы говорим об играх, у которых не бывает моментов простоя программы, ибо игровой цикл бегает постоянно. Так что Вы опять отлично продемонстрировали свою абсолютную некомпетентность в рассматриваемом вопросе.

Вы хоть поняли, что написали, и что сказал я? Вы целиком подтвердили мои слова, и не опровергли моего утверждения, что отчасти из-за этого программы на C# тормознутие программ на C++. Да, проги на C++ больше размером (этого никто не отрицает), но при современных масштабах, да ещё В ИГРАХ, когда ресурсы занимают несколько гигабайт, прибавление в весе экзешника хоть десятка мегабайт ничего не значит.
Или, может, Вы будете утверждать, что чем программа меньше, тем быстрее она выполняется? Тогда я рассмеюсь Вам в лицо и в который раз отправлю учить матчасть.:lol:

А Вы опять не поняли написанного. Учите... ага, именно её, родную, матчасть. Речь идёт о том, что код дизассемблируется в два счёта. Какая система защиты, Вы о чём? Хаккер вскроет Вашу игру и выкинет из неё код вызова любой системы защиты. Или Вы предлагаете, чтобы система защиты динамически распаковывала зашифрованный экзешник на C# при каждом запуске? Первое место в конкурсе "как затормозить игру" присуждается (барабанная дробь!) noLove! Ура, товарищи!

Нет, Вам. Потому что хаккер взламывает вашу программу и пользуется результатами. Итог - хорошо если просто пиратское распространение повсеместное. А если найдена уязвимость похлеще - ждите исков от разъярённых пользователей на возмещение ущерба.

Вы опять-таки в тему посмотрите. Мы про игры говорим. Впрочем, на Ваш вопрос я отвечу. Он украдёт все Ваши коммерческие тайны и вытащит наружу все недочёты. В серьёзных компаниях это - многомиллионые убытки.

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

Не поверите, я это знаю, т.к. сам писал диплом на тему разработки игр. А вот Вы явно опять не поняли, что я написал. XNA не может всё обрабатывать через шейдеры хотя бы потому, что не всё в этих шейдерах быстро реализуется, и не всё поддерживается. Например, шейдеры до версии 3.0 совершенно не поддерживают циклы. Как Вам такое ограничение? Я уж не говорю, что если вывод всей, абсолютно графики идёт через шейдеры помимо пользователя, то итог - замученный графический процессор, тогда как центральный отдыхает в теньке. В программе всё должно быть сбалансированно, а система тормозит со скоростью самого медленного своего компонента. Вы забыли эту истину.

Ещё лучше. Значит, ошибка в данных на этом форуме. Я, если что, в Кризис не играл и играть не собираюсь. Ну да не суть. Вы только подтвердили мои слова своим утверждением.

А пока я читал Ваше сообщение, изобилующие принципиальными ошибками, у меня такое ощущение сложилось, что так оно и есть.

Ну, кросплатформенность у него в пределах Windows (на Линусе - урезанная версия, про приставки я не говорю, т.к. они заведомо тормознутее компа). Код на C++ тоже кроссплатформенный, да будет Вам известно. Только его компилить надо, и учитывать, какие библиотеки где есть. Ну так C# тоже, положим, не без библиотек существует.
Мне такое не слабо, повторюсь, дело в библиотеках. Вся штука в том, что если такое есть на C# - значит возможно и на C++, ибо сам .NET-то не на себе же написан, а на том самом C++. Вот так-то. Значит, везде, где кроссплатформенностью обладает C#, ею будет обладать и C++, вопрос только в получении библиотек (если их M$ прячет, то альтернатив куча) и в компиляции (ну так это не проблема, подождать повторной сборки ради скорости работы).
Сериализация, простите, штука в C++ как бы встроенная, Вы, по ходу дела, не совсем её значения понимаете.
Насчёт рефлексии - поясните, что Вы имеете в виду, а то у меня складывается стойкое ощущение как раз того самого "слышал звон..." с Вашей стороны.

А о том, почему C# не нужен - почитать у Страуструпа выше в теме. Уж он-то действительно "папа в программировании".

И что дальше? Приставки, работающие лет по пять на одном и том же железе объективнее медленнее обновляемых компов если не сразу после своего выхода, то уж через полгода после него - точно, даже с учётом всех дополнительных "тормозов" от ОС (которая, надеюсь, всё-таки не Виста) и прочего. Плюс Вы не понимаете, что Framework на XBOX будет требовать примерно такой же универсализации доступа к оборудованию, как и на компьютере. Приставки "относительно быстрее" только за счёт тонкой оптимизации игр под себя, т.ч. и в плане памяти. C# убьёт такую возможность.

И к чему это замечание? Программы-то я пишу для большинства, как программист. Если бы Вы были правы, то Вы бы, кстати, противоречили самому себе, ибо под линукс полноценного Framework'а нет, он пока здорово порезанный.

Поздравляю, Вы сейчас доказали то, с чем никто и так не спорил, а я - писал прямым текстом - что C# идеально подходит для написания небольших офисных приложений. К сожалению, при написании серьёзных игр все перечисленные Вами преимущества C# не работают, ибо игры пишутся на основе кучи библиотек и движков, игры требовательны к быстроте своего кода (с чем у C# принципиальные проблемы) и игры обладают собственным интерфейсом, про стандартные компоненты в них можно забыть. Так что перечитайте-как ещё раз название темы и больше не оффтопьте.

Как я и писал - XNA является майкрософтовским вариантом движка "для самых маленьких". К сожалению, эта тема у нас о профессиональном игрострое. Вы же можете идти в тему, например, о Game Maker'е и там доказывать состоятельность XNA как продукта в подобном классе. Тогда у Вас есть неплохие шансы.

Зато работает гораздо быстрее, ибо C# вызывает те же самые 2 строчки кода на C++, но через кучу дополнительных функций. Что же касается скорости написания кода - для кого делались библиотеки и директивы препроцессора?

Да кто тебе сказал что ХНА на дх10??? погугли на эту тему хотя бы раз

мы обсуждаем это из за вашей твердолобости. Тема топика какая была? правильно, про XNA в играх. а Вы начали тут лечить про утечку памяти

Юзеру абсолютно нет разницы. Прога работает - и ладно. Современные компьютеры достигли таких мощностей, что это как вы говорите "35% замедления" почти не заметно.


Ты плохо знаешь .NET если говоришь так

Ага, тебя через неделю после того как ты начал плюсы изучать попросили написать игровой движок, или субд.

С++ - набор процедур и функций. так называемое ООП ложится целиком и полностью на плечи программиста.
Шарп - большая библиотека классов. В каждом классе есть свои свойства, методы, делегаты, события. Т.е. с самого начала программист подхватывает этот принцип, что все разложено по полочкам, и он знает что и где искать.

противоречишь себе т.к.
ты оффтопишь с самого начала топика

Если напишут крайзис на шарпе - в него в любом случае будут играть. И никому не нужно будет этого объяснять. Пусть он на плюсах написан, для него и сейчас требуется суперкомпьютер, однако играет народ.

У не воспринимаю культ личности как таковой. Я не знаю этого человека, где то слышал, но не знаю кто такой. Пусть он хоть папа римский будет

Сам светишь неграмотностью. Если нет простоя => нет автоматической уборки памяти => делай выводы

Тормознутость шарпа в том, что у него есть единая библиотека классов?
а чем плюсы лучше? у них ведь тоже mfc есть.
Расскажи пожалуйста по подробнее механизм выполнения программы на шарпе написанной и на плюсах, чтобы я наконец понял каким боком общая библиотека классов замедляет выполнение программы.

В лицензии моего ПО будет написано "Использование отладчиков и дизассемблеров запрещено. Если контрольная сумма Вашей копии не совпадает с контрольной суммой программы оригинала, разработчик данного ПО не несет никакой ответственности за возможную порчу, или утрату информации, либо другого рода убытки"

На этот случай люди придумали авторские права. Отсудить эти убытки при желании не составит много проблем. Хотя с нашим законодательством....

ПО уже написано, и распространяется. Пиратство сейчас оффициально сводится на НЕТ. Придет проверка из налоговой, или ФСБ, что вы им скажете?

Пусть видеокарта рендерит картинку. Какая разница, замученная она или нет. Процессору помимо графики своих проблем хватает.
Какой бы ни был урезаный .NET на *никс системах, рано или поздно он будет полноценным, ибо время идет, люди ведут работы над портированием.
Про приставки. Может быть конфигурация железа у них слабее компа, зато производительность у них бОльше, и не надо здесь пытаться спорить. Хотя бы потому, что Sony и MS очень много денег вложили в исследования в этой области, и им наверняка лучше вас известно, как будет лучше.
Проги написанные на шарпе тоже нужно компилить, но о библиотеках заботится CLR а не программист. Программисту только нужно указать требуемое пространство имен.
Выложите пожалуйста свою какую нибудь программу, самую простую, которая показывает сообщение "Hello world!". Я попробую ее запустить на всех своих девайсах. Запустится она только на ББ, ибо на PPC и Smartphone другая архитектура.
Кстати, среда разработки Microsoft Visual Studio, по крайней мере версии 2005 и выше на шарпе написаны.

При написании программ обычно для каждой задачи создаю свой класс. Например, класс, в котором хранятся все настройки программы. Этих настроек, скажем, пунктов 15. Как в плюсах узнать значение каждой переменной этого класса? А если моя прога вырастит до 50 параметров?
В шарпе код нужно будет написать 1 раз, и не важно, вырастит прога, или наоборот уменьшится.

Приставки быстрее, потому что им нужно только игровой контент воспроизводить и не беспокоиться о том, что кто то проводит сканирование портов, либо нужно забэкапить документы пользователя, либо нужно распаковывать какие то архивы, либо с бубном танцевать.
Приставки делают то, для чего они были созданы - игры, и не больше

Мастер оффтопа здесь Вы. С самого начала

Эта тема у нас называется "С# и Xna - революция в игросторении".

цитата из книги C# и платформа .NETpokibor, все же рекомендую изучить спецификации .NET

Ммм... дайте подумать... Micro$oft, который всё кричал, что XNA с DX10 будет. Значит, ещё не...? Собственно, с точки зрения моего вопроса до лампочки, ещё на DX9 она или уже на DX10, ибо отличия их (ну, кроме геометрических шейдеров, которые и в OpenGL есть) нужно с лупой искать.
Так я жду описания преимуществ XNA и на чём там она построена над OpenGL.

Так, ещё один переход на личности - и рейтинг поставлю. Про Ваши умственные качества я молчу.Укажите-ка мне мою цитату, которая, якобы, не в тему.

Приехали! Юзеру нет разницы, с какой скоростью работает игра. Круто. :lol: Наверное, Вы являетесь счастливым обладателем суперкомпьютера дома.
Выделю. Возможно, устрою опрос согласных с таким утверждением. Ибо я от него укатился под стол.

Так соизвольте мне разъяснить мою ошибку. Перечислите пункты оптимизации, ссылочки можете дать. Пока что факты - это 35%'ое замедление, а вот оптимизации что-то не видно. Уж не буду судить о своём знании .NET, но вот плохое знание Вами архитектуры компьютера - доказано (хотя бы вышестоящее утверждение - повторюсь, что же это в Игромании часто ругают игры за тормоза?)

Нет, меня потом попросят писать игровой движок или СУБД, а я в работе с памятью ничего не смыслю. Вот тут-то и будет C# обруган, и не раз. У меня есть опыт осваивания Pascal'а после QBasic'а. Скажу честно - лучше бы я это майкрософское убожество не изучал вообще. Ибо долго вникал в тонкости работы с памятью (а в Pascal'е они ещё не чета C'шным!).

Вы знаете хотя бы, что такое STL? Подскажу: библиотека классов. Видимо, Вы какой-то не тот C++ изучали, что остальные программисты...

Нет, я говорю применительно к играм. Если Вы скажете, что "достоинства сред разработки/языков/компиляторов/библиотек" не влияют на разработку игр, то в копилке Ваших замечательных высказываний будет прибавление. Причём достоинства сред разработки и пр. слабо зависят от мастерства программиста, а вот Вы говорите сугубо об индивидуальном мастерстве.

Ну-ну, как играть в то, что не запускается либо безбожно тормозит? К сожалению, у не каждый является сыном миллионера, чтобы позволить себе покупать под каждую топовую игру новый суперкомпьютер. Вы хоть задумайтесь, не от нечего делать компании стараются оптимизацией заниматься, а ради расширения круга потребителей.

Ага, ну вот тут-то всё и объясняется. Вы верите майкрософтовским рекламным статейкам больше, чем известнейшему в программировании человеку. Верно, это не культ личности. Это культ компании. Конкретной компании с названием Micro$oft.

:lol:
Кошмар... такого бреда я от Вас не ожидал. Что самое весёлое, написано абсолютно верно. И в очередной раз иллюстриует Вашу вопиющую неграмотность. Ибо отсутствие уборки памяти и есть её утечка.

Прочитайте внимательно мой пост. Тормознутость шарпа в том, что у него
1) автоматическая сборка мусора в памяти либо инициированная программистом, но опять же уборка ВСЕЙ памяти разом
2) интерпретируемый Framework'ом байт-код.
Где хоть одно слово про библиотеку классов?

См. выше. Программу на шарпе берёт Framework, тащит из неё байт код и исполняет его, периодически сканя память и очищая из неё всё ненужное.
Программу на C++ исполняет непосредственно процессор, и она сама заботится об уборке своей памяти именно тогда (для каждого отдельного кусочка выделенной памяти), когда это нужно.

Обрадую Вас - дизассемблирование программ и без того сейчас запрещено. Однако почему-то хакеров это не слишком останавливает, к играм есть уйма no-cd, тот же World of Warcraft постоянно ломают. А Вы упрощаете хакерам жизнь, т.к. они могут восстановить исходный код на высокоуровневом языке, а не копаться в ассемблере. И если они найдут уязвимость - при чём тут контрольная сумма? Просто в один прекрасный день Ваша программа с той же самой контрольной суммой отформатирует всем пользователям диски.
Я уж не говорю о том, что после каждого выпущенного Вами обновления его просто-напросто будут ломать по новой, и у пользователей всегда будет самая свежая взломанная версия Вашей программы, за которую они не заплатили ни копейки и с которой Вы ничего сделать не сможете, ибо хакер будет знать Ваш код едва ли не лучше Вас самих.

Ага, только есть одна маленькая проблема. Как я уже говорил, дизассемблирование противозаконно. А без него Вам трудно будет получить доказательства своей правоты. А доказательства, полученные противозаконным путём, не считаются. Вот так вот. И с суда Вас выгонят в шею, я уже не говорю о том, что одно малюсенькое изменение Вашего кода - и укравший Ваши секреты вообще оставит Вас с носом даже при наличии законного разрешения на дизассемблирование.

По домам ходит ФСБ, ищет пиратские копии игр? Пойду им чайку приготовлю. :lol:

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

Скажите, когда выйдет DirectX под Linux? Я что-то вообще не слышал, чтобы M$ как-то поддерживала Linux, ибо M$ это невыгодно. Следовательно, полноценного .NET под *nix не появится никогда.

Я уже написал за счёт чего у них производительность кажется больше. Жду конкретных возражения. И по поводу того, что .NET требует универсальности - тоже.

А Вам трудно перекомпилить один код с подключением разных библиотек, чтобы получить выигрыш в 35% скорости? :eek:
Среда программирования майкрософтовская, так что не удивительно. И не показательно, ибо оболочка среды программирования - это как раз категория далеко не требовательного к ресурсам ПО. Вот когда 3D MAX, например, на шарпе напишут - поговорим.

И что, я не совсем понимаю? Вы что ли variant-переменные имеете в виду? Ну так под C++ они тоже есть. Или что-то ещё? Поконкретнее, пожалуйста, в чём Вы видите недостаток C++. В класс новые члены спокойно можно добавить.

И что? Где тут возражение против требуемой Framework'ом универсализации доступа и отсутствия возможности оптимизации по памяти? А ведь при такой программы нельзя выжать из приставки все соки...

Доказательства? А то ж я это могу как клевету расценить. Только в лику или можете жалобу на меня подать с обоснованием.

Вот именно. Никакой революцией ни C#, ни XNA не являются. Движков "для самых маленьких" достаточно, и ещё один продукт среди них - это не тянет на революцию (а "Революция (от позднелат. revolutio — поворот, переворот, превращение, обращение) — глобальное качественное изменение в развитии природы, общества или познания, сопряжённое с открытым разрывом с предыдущим состоянием.")

Ммм... И что это доказывает?
Это лишь говорит, что приложение собирается во время работы! При том, что код на C++ уже собран. Нет, я бы понимал, если бы код на C# на конечной машине сразу преобразовывался в набор платформенно-зависимых инструкций (честно говоря, я понимал слова Knott'а так). Но приведёная Вами цитата только показывает лишние тормоза в процессе, не более того. Кэш-то у нас не резиновый, а игре на каждой итерации игрового цикла нужно выполнять целый спектр действий. Иными словами, приведёная Вами цитата только показывает, что C# на игры не рассчитан вообще, а более-менее подходит лишь для небольших приложений, часто выполняющих одни и те же методы.
Я уж не говорю, что программа на C++ изначально собрана и ей никакого кэша с платформенно-зависимым кодом не требуется - он и так весь платформенно-зависимый.
А Вам рекомендую изучить работу компьютера вообще и исполнение кода Framework'ом в частности.

Knott, не спорь со стариками, у них опыта много больше... Ты то, что говоришь откуда знаешь? В книжках прочитал, или в инете... Если ты считаешь, что программисты, которые практикуются уже десят лет читали меньше тебя, или вообще ничего не читали, ты глубоко ошибаешься... Они видели то, что не видел ты... Лучше используй их как учителей, а потом...

В любом случае, тов. Knott прав.
Ни для кого не секрет, что XNA разрабатывается с упором на разработчиков любителей\энтузиастов и студентов. Начинать программирование с простого , и постепенно переходя к сложному - это очень хорошая тактика. XNA отлично подходит для нее

В чём? В том, что C# и XNA - революция в игрострое? Вы так и не показали, в чём его революционность.

Как уже было показано, для программирования сложных приложений, кушающих ресурсы по-максимуму, XNA не подходит в силу своей тормознутости. Профессиональный геймдевелопинг XNA не изменит, пусть хоть все любители поголовно перейдут на неё, ибо издатели будут требовать и красивую графику, и корректную физику, и хорошую скорость работы одновременно. Пользующиеся XNА'ой энтузиасты просто-напросто будут вынуждены перейти на C++ под ударани судьбы в их лице. Так в чём там революционность XNA, ещё раз спрашиваю?

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

Как я понял, в общих чертах, тут ктото пытается доказать pokibor'у о том, что C# и XNA является жутко революционной и крутой штукой? Если так, то у вас ниче не получится. Ну хотябы по тому, что он железобетонно прав. C# проигоывает С++ добрые 30% производительности, и хоть ты усрись, но ниче с этим поделать нельзя. Утверждения о том, что эти 30% никому не нужны просто смешны. Насчет XNA я не уверен, поживем - увидим. Но слишком уж это похоже на желание Microsoft срубить бабла. Я считаю, что чем проще среда, тем она менее функциональна и на ней труднее сделать чтото действительно сложное. Хотя я сам щас работаю на C#, но мы то пишем по сути не сложные офисные приложения, там C# действительно удобнее и разница в производительности не так заметна. Но использовать это для игр - извращение. Хотя как первый этап в игрострое для молодого студента, может и сойдет.

pokibor а ты пробовал XNA на вкус?
JITter кэширует все вызовы методом, так что поначалу может ты и заметишь какие нибудь тормоза, в чем я сомневаюсь, но в дальнейшем - он будет работать с такой же скоростью как и твой любимый плюсплюс

вот здесь наглядно расписана эта твоя фобия про GC.

Ты играешь в игры в бэкграунде, или в спящем режиме компа? можт научишь?

Жесть :D
 

pokibor - модератор мог бы вести себя по скромнее ;)

XNA и C# - действительно революция. И я уверен, что в скором времени крупные конторы перейдут именно на XNA. Утверждение что C# прямо таки сильно отстает от С++ - неверно. Учитывайте факт о том, сколько десятков лет совершенствовались компиляторы С++'ные и сколько C# - это раз, второе: оптимизация .Net, действительно существует. Воть:XNA, крутая вещь только в прямых руках. Пара бенчмарков 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
Нужно время, чтобы на XNA начали делать действительно быстрые игры. Должно сложится правильное мнение "как" именно делать игры на .Net. Вы мне покажите тесты, доказывающие это. Словами я бросаться тоже умею. C# уже вплотную подходит к С++. Разница в скорости, в среднем, 3-5%. Но никто не отбирает у вас права оптимизировать. Но только не забывайте, что используя C# вы получаете комфорт, простоту, быстроту разработки. Просто на С++ прогят профи, вот и выходят такие крутые игры, да и материала полно. Так что утверждая что-то, у вас быть должно что нибудь, закрепляющее это.

А как будто профи делать больше нечего, кроме как сидеть в неудобной и непонятной среде? Вот они и не слазят с С++ именно из за его скорости.
Был бы C# действительно так быстр, как ты утверждаешь, то профи давным давно бы сидели на нем, однако же этого не произошло. Где тесты в 3D приложениях?
Кстати в одном из тестов есть:
___________________double math
Visual C++___________6.4
Visual C#____________17.7
Это довольно важно в 3D и как видим тут просто пропасть.

У меня достаточно опыта, чтобы понять недостатки XNA, не пробуя её на вкус. Вы, надо думать, на C++ игр тоже не писали. А вот я - писал дипломный проект.

Это - бред в случае игры, и выше я написал, почему. Впрочем, даже если он закэширует весь код программы, и пусть даже этот код будет оптимизирован по полной - он не достигнет результата C++ из-за уборки мусора.

Спасибо. Отличная ссылка. Особенно мне понравилась фраза, смысл которой Вы, судя по всему, не поняли:
Операция сборки мусора достаточно дорогостоящее удовольствие. Во время ее выполнения все потоки приложения приостанавливаются.
То есть играете Вы в Quake, и тут - раз! - потоки приостановились, ибо мусорок решил кто-то убрать. Пусть даже на десятую долю секунды (а ведь программа памяти мнооого кушает! По 512 метрам поди пройдись, а тот же Кризис 3 гига жрёт, как Вы же говорили...). Но, как знают игроки, подобный тормоз не просто глаза режет - он смерти подобен. Ибо за эти доли секунды средней руки снайпер из вас отбивную сделает. Занавес.

А у Вас привычка - задавать странные вопросы? Ибо вопрос этот ничего общего к моим постам не имеет. Если Вы что-то не поняли (а опыта у Вас, как я уже понял, нет) - спрашивайте прямо.

JohnK, Вы, как и noLove, не можете понять одной вещи: игры - приложения специфические. C# может не отставать от С++ в офисных программах, он даже может делать его в специально оптимизированных тестах - но в играх он будет безнадёжно отставать. Почему - почитайте хотя бы http://www.rsdn.ru/article/devtools/perftest.xml.
Посмотрите на тест с древовидной сортировкой (Tree sort). Вот где выходит наружу наличие в C# сборщика памяти.
Процитирую:
Давайте даже представим, что это всё реализовано идеально и без ошибок. Но ёлки-палки! Нынешние игры жрут по 2-3 гигабайта памяти, когда же Вы это поймёте! В них память всегда будет висеть рядом с пределом, а сборщик будет постоянно (подчёркиваю - постоянно! Т.к. память висит у предела) бегать по этим трём гигабайтам (!!!) и пытаться там что-то освободить.
Только из одного этого примера видно, что для игр C# не подходит в принципе, и если у Вас нет чего возразить именно на ситуацию со сборкой памяти (а это вывод, подчеркну, из заявления о работе сборщиков, т.е. именно того, что должно быть в идеале), то уж признайте - написанные на C# Crysis и иже с ним будет тормозить безбожно просто потому, что постоянно будет пахать сборщик памяти.
В C++ же есть возможность оптимизации по памяти, inline-функции и соответствующая оптимизация и т.п., чего в C# просто быть не может.

Я не исключаю, что в простых приложениях с объёмом памяти в 50-100 мегабайт C# будет не уступать C++, и плевать даже на ситуацию с double math преснопамятным (хотя, как верно заметил Feanor62rus, все 3D-вычисления именно таковыми и являются). Но чисто из-за огромной потребности профессиональных игр в памяти сборщик мусора для них является катастрофой и гигантским тормозом.
Если Вы этого не понимаете - Вы не знаете азы программирования, а делаете поверхностные выводы из статей, даже не задумываясь над их содержанием.

напиши на заборе об этом, чтобы стать реально крутым, здесь я только понты вижу, и ни бОльше. Сейчас куча народу поступает в универы на пристрижные специальности типа информационных технологий, автоматизация, и т.д. и лишь единицы из этих выпускников реально что то могут.


А ты явно статью до конца не дочитал. Там вроде ясно расписаны моменты, провоцирующие запуск 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. И попробуйте игроку объяснить, что такое сборщик мусора и почему их убили из-за тормоза в тот момент, когда он этот мусор собирал.
Вы сами себе противоречите. Вы фактически сейчас казали, что XBOX не поддерживает спецификацию .NET. Учитывая, GC есть даже в мобильных устройствах (см. статейку noLove), могу с уверенностью заявить - Вы ошибаетесь.

XNA для .NET только :Ъ
да и к тому же писать на шарпе горадо приятнее. КОд получается легко читаем и легко усвояем
а ты сам веришь в то что написал? я лично нет. Любую игру сверни, а потом переключись на нее, она тоже будет тупить.
А чтобы не провоцировать GC еще раз повторяю, ненужные объекты нужно удалять ручками. GC при этом не сработает

могу с уверенностью заявить что ты не знаешь о чем говоришь

Опять двадцать пять... По второму кругу пошли. Код может умещаться хоть в одну строчку, но излишних потребностей в памяти и тормознутости это не изменит.
Я сейчас нашёл одну статейку про разработку игр на XNA. Так вот, там единственный аргумент в её пользу состоял как раз таки в том, что код на ней, видите ли, получается короче. Ну так код с использованием движка (напр. Irrlicht) получается столь же коротким и понятным. И что дальше?
P.S. При заходе на третий круг у меня лопнет терпение и я просто буду удалять уже рассмотренные вещи.

Верю, иначе бы не писал. А вот Вы то ли не можете, то ли не хотите понять написанного. При чём тут "сверни/разверни"? Я говорю о том, что вызов GC будет пробегать по 3 гигам памяти и без всяких сворачиваний тормозить игру непосредсвенно в её процессе.
При удалении объектов вручную, ещё раз повторяю, код будет unsafe и мало чем отличаться от C++'ого кроме отсуствия оптимизации. В чём тогда преимущество C#? Какая мне разница, выделять и очищать память на C++ или делать то же самое на C#?

Ну так объясните мне, чего я не знаю. Кажись, M$ заявлял, что программы на C# и XNA будут на XBOX работать. Но как же они могут работать, если на PC есть GC и его можно использовать, а на XBOX его нет? :eek:

А не много ли на себя берете? Может вы сначала ознакомитесь с программированием на XNA? У хкоробки есть сборщик, просто он вызывается очень часто, поэтому приходится писать аккуратно ( читай не мусорить ) и удалять некоторые объекты самостоятельно.Какой еще unsafe? object.Dispose(); - и всё тут. Повторю еще раз: то, что вы пробовали XNA/C# год - два назад не означает, что ничего не изменилось.

этот ваш ирич - готовый движок, или полуготовый. хна - нет, это даже не движок. это набор пространств имен и классов.

А при том что просто так GC Тоже не врубается. Такого не будет, что сидиш играешь в кваку, и он врубился до тех, пока ты его сам не попросишь, или пока не произойдет одно из описанных четырех событий.

ты такой умный, а ты знаешь что такое IDisposible?

О-па! Так-так-так! Ну-ка, объясните-ка мне тогда, что такое движок, почему Irrlicht - готовый движок, а XNA - нет. :lol:
Ибо Irrlicht это как раз и есть, говоря Вашим языком, набор пространств имён (irr; irr::core; irr::gui; irr::io; irr::scene; irr::video) и классов/интерфейсов (IrrlichtDevice, IVideoDriver, ISceneNode, vector3d ...).
Уж тут то не надо пытаться со мной спорить, ибо я на Irrlicht писал, а Вы его, судя по всему, в глаза не видели.
Если Вы думаете, что Irrlicht - это конструктор по типу GameMaker'а, то крупно заблуждаетесь.

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

ООО, Вы хоть по C# хелп читали (кстати, Вы ещё и название интерфейса неправильно написали. Оно через 'a' пишется)? Процетирую MSDN:
Этот Ваш интерфейс IDisposable обеспечивает уничтожение не относящихся с GC объектов, таких как дескрипторы открытых файлов, потоков, окон. ВСЁ! К освобождению выделенной под класс памяти он не имеет ни малейшего отношения, она всё равно убирается GC.
Мда... И Вы ещё обвиняете меня в незнании C# и XNA... А то что прямым текстом в MSDN написано, не прочитали.

Уж разрешите поправлю коллегу. Он, кстати вполне прав, но раз уж вы так придирчевы, то знайте: XNA это фреймворк, т.е. не GAPI, но и не двиг. А про ирлича вы отожгли, тов. модератор.Сыграйте в XNARacer например, может вы перестаните нести подобный бред. Всё печетесь о каких то тормозах при переборе гигов памяти - на игре ясно видно.Без комментариев. :lol:

XNA - такой же фреймворк, как Irrlicht - компилятор. Это, как достаточно верно выразился noLove, суть есть надстройка над DirectX в своей графической части, набор классов. Irrlicht - то же самое: библиотека, содержащая набор классов и функций для облегчения написания игровых приложений. Не более того.
Если Вы возражаете, распишите-как по-подробнее отличия XNA от Irrlicht. Кроме того, что Irrlicht позволяте писать как под C++, так и имеет .NET-версию, в отличие от чисто .NET'ной XNA.

Простите, XNARacer - это вершина игростроя, по-Вашему? Мы тут, если Вы не в теме, говорим о революции в игростроении. Что на XNA можно делать игры вроде бы никто и не возражал. А вот что на ней можно делать топовые игры - очень даже. Сыграйте в Crisys. Он, как заявил noLove (так что претензии к нему, а не ко мне) 3 гига памяти требует. И посмотрите результаты провала C#'а в Tree Sort'е по приводимой мной ссылке выше, и их обоснование. Вот поэтому-то я и говорю и тормозах C# и гигах памяти.
А то так и я могу тетрис на Прологе написать и говорить Вам: "Смотрите! Он работает без тормозов на передовом Пне/Атлоне! Prolog - вот лучший язык для игростроя! Все переходим на него!"
Уж извольте прокомментировать. Этот текст взят из 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. Если что - реализация грамотная без сарказма (если реализовывать иным образом - то объект спокойно может "потеряться", к примеру, если сам на себя ссылается). Вот только опять же для сложных приложений плохо подходящая.

Нет, не много. Репутация является зеркалом того, как другие пользователи относятся к вашей персоне. Если вы пишете откровенную ерунду, либо не понимаете с первого раза, или просто своими постами вызываете отрицательные эмоции, пользователи вполне могут высказать свое отношение к вам с помощью репутации. Участвуя в дискуссии, модератор работает, как обычный пользователь, и поэтому вполне может поставить вам плюс или минус в репутацию, как любой другой пользователь на этом форуме, если сочтет нужным. ПОэтому в данном случае претензии безосновательны. На этом думаю оффтоп закончить.

Даже если бы они были, что вы собрались комментировать? Человек привел вам отрывок из MSDN, выделил главное, перевел на русский. Вы ставите пометку "без комментариев" к официальной документации?

если ты думаешь что XNA - конструктор по типу GameKakera тоже ошибаешься. в ХНЕ нету готовых классов игры, там нету классов гуя, сцены и прочего, там это все самому писать надо.


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


а никто его не мешает к managed Объектам прикрутить

ты уж определись, о чем ТЫ говоришь, о GC, или о революции в игрострое.
XNARacer - наглядный пример игры на платформе .NET XNA, там есть все, современная графика, звук, физика, игровая логика. Оно летает при всем при этом


ой, а в плюсах будто бы не надо все вручную писать

***
Всякие готовые GAPI на плюсах пользовать бред. Для этих так называемых супермегапроектов. ибо эти GAPI - очередная прослойка => очередные тормоза.

pokibor, а ты уычавствовал в создании "вершин игростроя"?

IDisposable - мечта pokibor

Я это говорил? Я представляю, что такое XNA, можете не волноваться. Сцена - понятие довольно абстрактное, чтобы Вы могли говорить, что её в XNA нет. GUI в Irrlicht тоже никто самому писать не мешает (я Вам даже больше скажу - в Irrlicht нужно писать свой GUI, ибо стандартный... скажем так, имхо убог.
Но факт в том, что Irrlicht даёт полный спектр классов для доработки движка на любом уровне. И он, в отличие от XNA, open source (откуда, собственно, этот любой уровень и берётся).

Дальше у Вас идёт цитата моих слов в текте Вашего поста... к чему это, не понял. Наверное, ошибка... Потрудитесь перечитать свой пост после его публикации.
И какой тогда смысл? Половина объекта будет managed и будет убираться сборщиком мусора, половина - unmanaged и будет убираться Dispose. Вы, кажется, не поняли, что Dispose работает в полном отрыве от сборщика мусора. Либо - либо, а попытки совместить приведут к тому, что у Вас в объекте будут недостатки обоих подходов - т.е. жуткие руковывороты с Dispose и лишние затраты памяти/её уборка GC.
О революции в игрострое говорит тема, а GC не даёт C# и XNE быть революцией. Не только он, конечно (и что это про double math заглохло? Нет возражений?), но в частности.
Я повторю, вменяемую игру можно хоть на прологе с юзанием библиотек написать, и существование этой игры вовсе не будет доказательством революционности языка. Пока что я не видел в магазинах ни одной игры, написанной на XNA. А мы всё-таки говорим о профессиональном игрострое.
В плюсах деструктор вызывается автоматически и не ведёт к конфликтам с автоматически убираемой памятью, а также извращений с отловом исключений.
В таком случае бредом является и использование DirectX, а уж XNA как надстройки над ним - и подавно. Не смешите народ такими заявлениями!
GAPI - это сборник часто употребляемых функций, не более того. Вас никто не заставляет пользоваться только его средствами от начала и до конца. Вы всегда можете открыть исходный код (Irrlicht - open source, а вот XNA - нет...) и поменять там что нужно, или просто частично использовать стандартные функции, а частично - непосредственно DirectX или OpenGL-функции. C# и XNA такого выбора не дают.
К чему вопрос? Нет, не участвовал. Однако я писал диплом на соответствующую тему и защитил его с отличной оценкой (это если говорить о заслугах, причём отдельно замечу, что этот разговор начали ВЫ, а не я). Вы, надо думать, и этим похвастаться не можете.
За меня о моих мечтах говорите? IDisposable - это мой ночной кошмар. Деструктор, который нужно вызывать ручками, да ещё следить, чтобы он не дай Бог не стал конфликтовать с автоматической сборкой, отлавливать все исключения... Нет, спасибо. Моя мечта уже реализована в C++.
И в последний раз - просьба мой ник не искажать. Я над Вашим не издеваюсь.

в ХНЕ нЕчего править. ТАм долго базовые классы. Например, описание структуры Vector3, Texture, Texture2D, Texture3D, VertexBuffer, и так далее.

Профессиональные геймдевелоперы здесь не сидят, и врядли будут сидеть. А То, что ты называешь потенциальными геймдевелоперами - так они на геймдеве сидят, а здесь это так... для виду...

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

В Irrlicht есть все эти классы, плюс ещё немного более высокоуровневых. Ими никто пользоваться не заставляет, можете использовать только базовые и самостоятельно писать рендер. Причём какие-то моменты можно брать из исходников самого Irrlicht (ах, как мне нравится Вам повторять, что он open source и знать, что по этой части Вам мне даже потенциально нечего возразить! :Grin: Извините, отвлёкся).
Ну а по остальному спасибо [CCCP] Monster, он ответил. Вообще, прошу меня простить, но спорить в ближайшее время буду куда менее активно. Ибо (1) надоедает одно и то же повторять и (2) мне уже давно пора продолжать писать своё произведение, а это время...

а что в хне в исходниках искать? как выглядит структура Vector3 ? или че?
рефлектор в зубы и вперед!

ps// игрострой как кто то уже упоминал - это искусство, большинство современных игры - не искусство, а графические навороты, ну и немножко типасюжета. А еще интересно, че там такого эти разработчики пишут, что один тока эхешник весит 75 мег.
Будь ты хоть дважды папой в своем языке программирования, однако, если не придерживаться некоторых правил, то хоть на асме пиши - все равно фигня получится, и даже все его преимущества перед ЯВУ не помогут. Так же и с любым языком программирования. На этом шарпе если умело написать игру, и пусть ты его так нелюбишь из за GC, она по производительности любую твою игру только так уделает, и не важно что у нее математика с плавающей запятой в 3 раза медленней, и что там GC. Если уметь это делать - то просто пофиг будет на все это

noLove
1) Открытые исходники позволяют поправить ошибки, изменить глубинные рассчёты с целью увеличения быстродействия и т.п. Если в XNA нечего править таким образом, то спрашивается, накой она вообще нужна? А Майкрософт доступа к своему детищу никогда не даст.
2) Опять... Ещё одно повторение пройденного материала - буду тереть посты. Ибо мы говорим о профессиональном геймдеве, где работают профессионалы. И у них как раз профессионален и код на C#, и код на C++. Стало быть, им как раз есть разница в скорости double math, GC и всего прочего. А уж учитывая, что деструкторы в C++ реализованы в разы лучше Dispose в C#... Ваши претензии вообще теряют смысл.
И откуда Вы 75 метров экзешник взяли? Сейчас посмотрел у Ведьмака - 10 метров. Причём туда ещё защита вся входит.
Впрочем, могу сказать, откуда могли взяться 75 метров. От оптимизации. От раскрытия C++'ых inline-функций. Это, если что, не программист пишет, а компилятор делает. А код подобные фичи ускоряют многократно (см. тесты по моей ссылке, там как раз хорошо сказано про эту возможность C++).

как мелкософт скажет - так оно и будет. Скажут писать на шарпе - будут писать на шарпе, или же просто перейдут на *никс системы

если они будут спонсировать разработчиков, то - да
такого никогда не будет(во всяком случае в ближайшие лет 15 точно), MS скорее цены убавит на винды, чем даст людям перейти на никсы.

noLove
Ну Micro$oft сказал "Все переходите на Висту!" - результат что-то не слишком впечатляет. Micro$oft сказал "Нет пиратству!" - сейчас отдаёт IE7 обладателям пиратских виндов, опасаясь совсем проиграть в гонке браузеров. Micro$oft - это ещё не весь рынок компьютерных систем, а то сейчас бы за написания игр под Windows ему бы отчисления делали. Думаете, будь у M$ такая возможность ввести подобную практику, они бы отказались?
Вот придёт Google со своей бесплатной ОС, тогда и посмотрим, насколько M$ у нас крут.
И, кстати, подобный пост граничит с оффтопом.

Интересно тут у вас...
Как я понял, основная тема холивара это скорость работы приложения .NET, а точнее эти пресловутые 35%, все остальное GC, вызов деструкторов, циклические ссылки, утечки памяти, это все вытекает из проиводительности. Моя точка зрения, что XNA вполне жизнеспособная технология и эти 35% при текущем положении дел не являются помехой. Посмотрите на производителей процесоров, в один прекрасный день они сказали, "сорри пацаны, но больще наращивать мощность проца мы не могем, но вот вам пока два, а там посмотрим...". Как известно на XBOX 360 стоит 3 двухядерных процессора и в приложениях .NET один из них как раз занимается сборкой мусора, так что приведенный пример со внезапной смертью в Quake из-за лага вследствие сборки мусора считаю несостоятельным. На рынке уже в свободном доступе 4-х ядерные процессоры и это не конец (кстати GC можно перевести в режим работы с 4 процессарами). Но в несомненный плюсы C# и XNA могу записать скорость разработки приложений, думаю с этим возражений-то не будет?
И в завершении всего один вопрос, почему соверемнные игры не пишут на ассемблере, ведь он по определению быстрее С++?

И всё бы хорошо, вот только товарищ noLove, сам того не ведая, дал нам в руки лишний козырь, преведя ссылку на статейку, говорящую, что во время работы GC всем потокам в приложении надлежит остановиться. Это раз.
Далее, 35%'ов-то никуда не деваются. При толковом распараллеливании (мы же о профессионалах говорим) все процессоры будут заняты игровым делом (физикой, AI, прочим...). А значит, эти самые 35% никуда не денутся.
И мы ещё не говорим о памяти, которую наличие GC (просьба не забывать) забивает напрочь. Чисто по своей конструкции и желанию вызываться пореже.

Будут. Тут тот же самый noLove сказал, что XNA более низкоуровнева, нежели движки. Следовательно, с её использованием возиться придётся более, чем юзая движки вроде Irrlicht'а. А своих наработок у компаний сейчас хватает. Даже новые движки появляются на базе старых.
И я опять не упоминаю про кривейший Dispose (Господи, как же нам, противникам XNA, помог её сторонник - noLove!), с которым мороки в разы больше, чем с C++'ыми деструкторами

Потому что C++ обеспечивает оптимизацию почти до уровня ассемблера, чего C# позволить не в состоянии. В C++ можно сделать функции inline, использовать адресную арифметику... В общем, возможностей куча. Игры же как разрабатывают - сперва пишут от начала до конца, а потом оптимизацией занимаются.

Еще один!!! Да откуда вы беретесь то такие? ТЫ пройдись сначала по форуму и почитай че люди говорят об оптимизапции в послених NextGen играх! По всему форуму одно только нытье о тормозах! В топике о крайсиса радуются прибавлению даже 5 FPS. А вы говорите 35% фигня?! Ну ну... поменьше бы таких людей как вы в геймдев.
Там 1 трехъядерный, ЛОЛ. Бегом учить матчасть!
На эту тему можно долго спорить. Но ответь мне, почему же на C# до сих пор профессионалы не пишут игр!!!??? Почему? А?
Вот вы все трубите "можно сделать крайсис на C#", но почему его всеже не сделали на нем? Если, как вы говорите, это так удобно?
Просьба воздержаться от спорных в плане цензурности выражений.
Хорошо, больше не буду))

Фейл. Эх, я б тебе еще один минус влепил бы, но прости, не могу, уже ставил.

Тоесть вы утверждаете, что все прелести и удобства C# это гениально, а прелести С++ это фуфло и они только плодят ламеров? Очень своеобразная позиция. Ты уже похоже сам не замечаешь того, что защищая свой любимый # ты скатываешься до откровенного моразма.

ХНЕ примерно 1 год. Еще немножко, и будут писать, обязательно будут.

И то что мелкомягкие скажут писать на шарпе - разработчики будут писать на шарпе, никуда они не денутся. Иначе, почему нет фотошопа для *никс систем? премьера нету? те же самые игры пишут для винды. Вы злесь включая вашего главаря покибора умные самые - додумаетесь к чему это я написал

Ждем.... с нетерпением. И вабще я в данный момент не о хне говорил а о C#. Во-первых они так не скажут. Во-вторых, им это никогда не позволит антимонопольный комитет. В-третих, как они могут их принудить? Как?
Вот, к примеру, стал я разработчиком. Кто меня может принудить писать на #? И самое главное как? Да если я захочу я буду хоть на VB писать, хоть на ныне мертвом языке АДА, никакой Билли меня не заставит.
И почему же нету? Неужто Билли запретил?
Ты написал какуюто ересь понятную только тебе, научись правильно излагать мысль.

если человек пишет на С++ это вовсе не означает что у него прямые руки..

как вариант разрешения данного спора (на чем проще делать игры) - есть предложение забацать соревнование. выбираем игру и делаем ее, одна команда пишет ее на С++ а я пишу ее на шарпе.

я могу дать вам фору - команда С++ может состоять из 3 человек, я же буду один.

результат - время реализации работоспособной игры.
плюс к тому что я вас уделаю, могу гарантировать что ХНА-шный её вариант будет максимум на 10% медленнее) а не 35% :Grin:

Так как ХНА это враппер для DX то Главное условие - прямое использование АПИ (выбирайте любой: GL или DX). т.е. готовые движки нельзя а то дай вам волю и деньги так вы UE3 станете юзать дабы не остаться в дураках.

О себе - мне 30, программирую 16 лет, из них работаю программистом 13 лет, из них в геймдеве 8 лет. Начинал еще со спектрума (бейсик, ассемблер), потом были совковские ЭВМ (бейсик, ассемблер, С) как появились писюки - перешел на них (бейсик, паскаль, С++, Шарп), щас на шарпе работаю (геймдев), уже 6 лет, перешел на него с С++. и возвращаться не собираюсь.

Без этого соревнования - данный спор это просто слова. не важно кто и что защищает..

Ну так что, детишки, поиграем? Кто примет вызов?

В конце один небольшой факт -

13-го декабря вышла ХНА (2.0). и за первые ДВА дня пакет был скачан порядка миллиона раз.

уж не думает ли кто из С++ гулага, что этот миллион человек (а на данный момент уже больше) — полные недотепы и только вы одни самые умные?

Непомню такого ажиотажа вокруг какой-либо технологии связанной с геймдевом. Вывод из всего этого прост — в ближайшие годы геймдев разработчикам, пишущим на С++, придется сильно потесниться на этом рынке.. (надеюсь что они вообще не вымрут, как динозавры когда-то)

Я предлогаю афтору чёнить сделать на этом мега языке С# , а потом говорить что тут быстрее... С++ быстрее на порядок...

А вот всяческим DarkBasic'ам и прочим Blitz3D уже гораздо больше лет. Но на них как писали исключительно любительские проекты, так и пишут. Откуда увереность в том, что XNA не постигнет их участь?

Ну во-первых, многие игры есть в вариантах и для Linux. Сейчас вон собирают подписи, чтобы под Linux Fallout 3 сделали...
Далее, то, что игры пишут под систему от Micro$oft, вовсе не значит, что M$ всем диктует условия. Одно дело, если под новой супер-системой (Vista на это звание не тянет) вообще не будет иных компиляторов, кроме C# (но это - чистой воды бред, т.к. если под ту систему придётся переписывать ВСЕ СУЩЕСТВУЮЩИЕ приложения, у меня есть боооольшие сомнения, что такая система вообще продастся хоть парой экземпляров). А если написаные на C++ программы будут работать, то о каком диктате со стороны M$ может идти речь?


raxxla
Вообще-то честность подобного соревнования не проверишь никак. Это раз. Про скорость я уже говорил про существующие наработки. Это два. Миллионы человек - это любители, и студенты, для которых XNA - в самом деле весьма лакомый кусочек. Мы же говорим о профессиональном геймдеве. Это три. И четыре - сравнивать XNA с использованием чистого DX или OpenGL некорректно. XNA - специализированный инструмент для разработки игр. DX и OpenGL - нет.
А про спор, значица, возразить нечего в поддержку XNA и C#? То есть мы во всём были правы?

вы, конечно во всем правы, но истина дороже..

Миллионы человек - это любители, и студенты - это точно, в яблочко, и я один из них, у меня даже высшего образования нет (бросил институт), вам нестоит бояться такого как я, просто примите вызов и не нада юлить. а то я начну думать что вы просто в свое свободное время разводите демагогию по поводу никчемности шарпа в геймдеве..

Согласен, но мы тут обсуждаем языки программирования, а не людей, которые на них пишут. Ведь так?Не знаю как к этому отнесутся другие участники, но омне лично не досуг тратить уйму времени(во время сессии), я еще и работаю. Так что, я пас. Считаю сей акт меряния пиписьками абсолютно безсмысленным. С++ обьективно лучше и этот факт уже доказан любовью к нему со стороны профессионалов.
Слушай, а если ты пишешь игры уже 6 лет, то неужели тебе нечего нам показать. Ты покажи игру которая у тебя уже есть, я тебе лично скажу что ты крут если оно так и есть. И еще... Раз вы работаете в геймдеве, то хотябы поделитесь в какой конторе и какие игры у вас за душой. Просто наших толковых игр - по пальцам пересчитать, ивот незадача, они все писаны на С++. Мне очень интересно воочию увидеть красивую, нетормозную, профессиональную игру написаную на C#. Требую, чтобы вы мне ее показали. Иначе я вас считаю вруном.

я работаю щас тут - 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, что не было до неё и что привлечёт к ней серьёзные игровые компании? Отвечайте.

Если вы придете комне, то я скажу что ХНА использовать вы должны потому что ее использую я. и этого будет достаточно. так как вы пришли именно комне.

Незнаю, сходите на сайт огра, посмотрите, поделитесь с нами инфой..

Хорошо, если вы примите вызов - вам будет разрешено использовать сторонние библиотеки (обсудим какие именно..)

У ХНА есть миллион студентов и я один из них, хотите знать что это значит? - примите вызов.

На всех форумах по всему инету народ гонит на шарп, заставляя дотнетчиков защищаться, при этом нападающие и не подозревают о том что сами защищаются (атака - лучший способ зашиты).

Вы нас боитесь, а мы вас - нет..

Веская причина. А если я кроме Вас приду ещё к другому человеку, и он использует C++? И как мне понять, кто из Вас прав? Наверное, всё-таки потребуется описание каких-то преимуществ...
Зачем так далеко... в Google по всяческим запросам, связанным с XNA, около 2 миллионов количество. По "ogre 3d" - столько же. А ведь есть ещё и другие движки... Так что по такой логике выходит, что огр - конкурент XNA...

Это значит, что вменяемого ответа нет. Спасибо, я понял. Собственно, так я и думал.
Ммм... Возможно, потому, что C++ проверен временем, а C# и XNA - только лишь претендуют на его лавры? Слишком много было попыток выгнать С++ с пьедестала. Итог: C# - лишь очередная. Может быть, и удачная (на этот счёт мы и спорим).
Атака - лучший способ защиты, верно. Но почему тогда дотнетчики не атакуют? От бесстрашия ли? Или просто потому, что нечем атаковать-то?

Возможно вы правы, если вы действительно собираетесь придти комне - я основательно подготовлюсь и неразочарую вас.

Потому что им незачем это делать, они знают что если спор дойдет до реального дела, то народ из С++ сообщества предпочтет отсидеться в сторонке..

зачем тогда дотнетчикам тратить время впустую?

я могу на любом из форумов, где идут подобные холивары, запостить предложение о таком же соревновании и везде, я почти уверен, будут похожие ответы - мне некогда, это все фигня, С++ все равно круче..

Ну, учитывая, что сейчас передовые коммерческие игры (а не всякие показные гоночки) всё-таки на C++ разрабатывают, то на отсиживание в сторонке это не тянет. Вот когда будет реальная игра по типу Кризиса, Старкрафта там второго и т.п. разработана на C# - тогда можно говорить про отсиживание в сторонке. А пока что в профессиональном геймдеве (повторюсь, спор у нас о нём, XNA как движок для начинающих уже тут вроде признали) C# зубов не показывал.
А C++'совикам? И тему-то эту, кстати, дотнетчик создал, прошу заметить, а не C++'овик, "опасающийся за любимый язык".

это только вопрос времени. ведь С++ уже более 30 лет..

автор темы, в первом, посту просто поделился новой информацией. на него тут же набросились и пошло-поехало. все являются участниками этого спора - в одинаковой мере.

Я нехочу тратить время на аргументы, я хочу доказать свою точку зрения на деле. Это дело принципа и ради того чтобы поставить вас на место я готов взять отпуск на несколько дней (девушка моя меня прикончит, но оно стоит того).

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

Либо вопрос отсутствия этих зубов.
Как модератор попрошу воздержаться от выдвижения аргументов, предполагающих проверку будущим временем. Это почти флуд.
Он в категоричной форме заявил о революционности C# и XNA.
Если все являются участниками в одинаковой мере, то при чём тут споры о защите и нападении?
И вообще надо потихоньку прекращать всё, что граничит с оффтопом.
Можете посоревноваться с ребёнком и вчистую победить его. Ибо никакой исход спора ничьей правоты не докажет, всегда можно будет списать на личное умение и на случайные факторы. Вот если бы сражались, например, 10 команд C++ и 10 - C#, да ещё специально отобранных - тогда можно было бы что-то говорить. А так...

Все это на самом деле полная фигня. Все эти споры я имею в виду. Понимаешь, если посадить за руль копейки пилота ралли, а за руль мерса какого-нибудь чайника. То скорее всего победит профессионал. Но вот только копейка то от этого лучше не станет. Как была ведром с болтами так им и останется. Я к чему клоню... бестолку устраивать подобное соревнование. Все сведется к соревнованию по программированию. Да, это выявит кто лучший прогер. Но спор о том, что лучше C# или С++ так и останется висеть в воздухе.
Если уж есть такое желание, то можно попытаться всем вместе замутить, ну не игру если времени нет, то хотябы демосцену с одними и теми же моделями, текстурами и абсолютно одинаковыми алгоритмами(разработанными вместе) на двух разных языках и просто сравнить показатель FPS. Остальное просто безсмысленно.

Вас победить мне будет намного проще чем даже ребенка. Потому что даже дети не говорят таких нелепостей. Где мы возьмем 10 команд? может тогда уж и бил гейтцу позвоним? А что, нам ведь не слабо, мы ведь центр мироздания, мы ведь С++ знаем..

Вы заранее уверенны в моей нечестности - нехорошо, господин модератор.

Feanor62rus - У вас есть конкретная идея? выкладывайте. если у вас напряги со свободным временем - мы можем не учитывать его вообще. Давайте, сделаем одно и тоже и просто сравним ФПС.

Если Вы так истолковали мои слова - лучше переосмыслите их. Только такой спор может дать объективный ответ. Если мы не можем его устроить (я разве предлагал?) - значит не судьба нам найти правду таким способом. Зачем тратить время на что-то, бессмысленное изначально?

Надеюсь, оффтоп на этом прекратится.

Всем привет!!! Я мало имею отношения к разработке игр, или каких либо других приложений для РС, поскольку пишу проги для цифровой обработки сигналов, и в основном на ассемблере, потому что хорошее быстродействие на другом языке получить несколько трудновато. Там очень много используются языки С и С++, но в любом случае, быстрее, чем хорошо написанной на ассемблере проги ничего из того, о чем вы тут говорите, работать не будет.
Далее, по поводу того, что С# вообще и XNA Game Studio в частности - это попытка попрать чей-то там пьедестал, и только, это чепуха. Microsoft сейчас очень уверенно продвигает сей продукт, поскольку разработка игр под ее консоль X-Box 360 будет проводиться в основном на XNA. Далее, .NET и С# - это НЕ ИНТЕРПРЕТАТОРЫ, это вам не бейсик. Это проги, которые компилируются непосредственно перед выполнением, т.е. после компиляции исполнимый код грузится в память и работает как любой другой ЕХЕ-шник, скомпиленный бог знает когда бог знает кем. Единственная разница, компилирование происходит под конкретный конфиг, т.е. оптимальнее, чем на конкретном железе. Пример, кто-то пишет прогу на машине типа Р-600 для использования ее на C2D. И вы хотите сказать, что она будет оптимально скомпилена??? Ой как не уверен.
Уважаемый K.A.I.N., вы бы хоть почитали тему! Всё, что Вы сказали, уже было сказано. Кое-что - по нескольку раз. Так что живите настоящим днём. :wnk:
Флуд удалён. Все вопросы - в личку. Тут только процитирую причину: "Никакой конкретики либо возражений." Повторение приведёт к получению баллов. Лишь посоветую ещё раз перечитать первую страницу темы и подумать, почему крупные компании не поставляют свой софт open source с компиляцией его на машине пользователя.
Pokibor

Например, какие из известных игр есть для линукс? Quake3 & Quake4 не предлагать.



А зачем им принуждать? просто в их новой ОС не будет привычного Win32 API и все.
Про антимонопольный комитет. Вы знаете, США от MS получает очень хорошие деньги в виде налогов хотя бы, вроде бы, чуть меньше 1 трети. К тому же, MS занимаются написанием военных программ для армии США.
Кстати, девелоперы могут перейти на OpenGL, он ведь кроссплатформенный в отличие от DX

Ты не прав. Раз вы все тут говорите что плюсы круче шарпа в геймдеве, значит вы должны знать, как, а самое главное, на чем работают эти игры.

XNA для шарпа, это то же самое что и DirectX API для С++. Так что, с помощью XNA хоть что можно делать. (XNA - то, во что перерос MDX)

Значит так. noLove и всем остальным. Делаю последнее китайское предупреждение. КОНЧАЕМ ОФФТОП И ФЛУД. Если хочется/нужно поофтопить немного - к вашим услугам тег спойлера. По личным вопросам - ЛС. Если всё будет продолжаться в такой форме, как оно есть сейчас - обещаю, я буду тереть целые посты вместе со всей инфой в них и ставить предупреждения. И не говорите потом, что я затыкаю рот своим противникам. В особо критическом случае обещаю закрыть тему на неопределённый срок.

Точно сказать не могу, т.к. этим вопросом не интересовался, да и к спору он имеет отношение постольку посколько. Однако всё, что использует OpenGL, спокойно под Linux перекомпилируется. Также гляньте список по http://en.wikipedia.org/wiki/Linux_games в графе "Linux versions".
Правда, тут, конечно, нужно оговориться, что многие компании просто не видят необходимости выпускать Linux-версии, т.к. под Linux'ом есть очень неплохие эмуляторы, позволяющие запустить какой-нибудь WoW без всяких проблем.



Ммм... А как же совместимость со старыми программами?
Нет, честное слово, подобная Ваша уверенность в том, что M$ может просто так взять и в очередных виндах не сохранить совместимость с программами для предыдущих меня просто забавляет! Покупатели такие Винды просто не купят. А M$ вылетит в трубу со всеми её миллионами.
А если совместимость будет - тогда почему не будут работать новые игры, написанные на всё том же C++ с тем же Windows API?

Вот не надо! XNA - специализированный продукт для разработки игр:
DirectX - библиотека, используемая далеко не только в играх. В ней куда более общие функции. Если XNA - то же самое, что DX, только под C# - то в чём её преимущество перед DX? Или DirectX M$ писать не умели и криво сделали, а к изданию XNA вдруг научились? Вы противоречите сами себе.

Про директХ то же самое можно написать. Хну тоже куда угодно прикрутить без проблем
Как говорил тов. raxxla, XNA - это .net прослойка над DirectX, или врапперы, как хочешь. Хну придумали для наибольшей совместимости при кодинге графике для ББ и коробки, чтобы облегчить портирование

Кошмар, все страницы не осилил.

Теперь что касается производительности. Да, при определенных условиях managed код медленнее unmanaged. Однако существуют и такие условия, при которых управляемый код работает быстрее (вспомним хотя бы про сверхбыстрый аллокатор памяти). Это уже вопрос культуры и опыта программирования. Еще пара нюансов - почти все приложения, с которыми я работаю, - GPU-bounded. В них падение производительности в 35% (откуда кстати цифра?) почти не оказывает влияния на суммарное время обработки одного кадра, т.к. процессор все равно какое-то время простаивает. "А как же физика?!" - крикните вы. А физику никто и не заставляет писать на .NET/C#. Я вот пользуюсь Ageia PhysX (благо интегрировать unmanaged код в managed очень просто и удобно), и никакого дискомфорта не испытываю.

Уфф, написал. Привет всем знакомым тут, кстати =)

На все Ваши вопросы ответы могут быть найдены в теме, особенно если Вы правильно поймёте собственно тему. Тут XNA никто не гнобит как глупость. Тут обсуждаются совершенно конкретные вещи относительно революционности XNA в отношении разработки игр (причём профессиональной в-основном), и я прошу придерживаться этой темы. В частности, выше был задан вопрос, на который ответ так и не был получен:

И ещё. Если ни у кого не будет возражений, я тему переделаю. Постараюсь объективно учесть все доводы в пользу революционности и полезности XNA, и против неё, и организую новую тему (более широкую, но и более жёстко модерируемую).
Возражения/предложения/замечания пока допускаю писать здесь, только учтите, что я их буду добавлять в этот пост, а сами сообщения удалять.

Мое последнее слово в этой теме))
 

На счет C# я совершенно не понимаю его защитников. Да, хороший, удобный, понятны язык. Я сам на нем работаю, но я пишу несложные офисные программы с использованием SQL. Но я почемуто понимаю, что это бестолково использовать для игр. Насчат XNA я не знаю, сам не использовал. Да и в геймдеве(любительском) я моделер а не прогер. Как говорится - время покажет. Может быть и хорошая штука, но уж очень это напоминает попытку microsoft тупо подмять под себя весь игровой рынок. Это настораживает.
Что же до профессионалов. Вот это истина в первой инстанции. И они не используют C#, только С++. Им конечно проще у них штат большой. На фоне этого вопли фанбоев смотрястя особо бессмысленными. Все орут, что на C# можно написать чуть ли не крайсис. Ну дай бог - напишите и я вам поверю.

Я тоже заметил)) Сразу 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 - где скачать, как поставить, какие у кого проблемы и прочее) и в ней обсуждать данный продукт.