С# и Xna - революция в игросторении. - Страница 4

JohnK · 20.12.2007, 21:43

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

XNA и C# - действительно революция. И я уверен, что в скором времени крупные конторы перейдут именно на XNA. Утверждение что C# прямо таки сильно отстает от С++ - неверно. Учитывайте факт о том, сколько десятков лет совершенствовались компиляторы С++'ные и сколько C# - это раз, второе: оптимизация .Net, действительно существует. Воть:

Цитата:

being a professional C# programmer since .Net 1.0 Beta I can tell you a few tidbits about Managed code and C# compared to native C++.

When working with out-of-the-box namespaces in C#, you come across a lot of iterators. Iterators create clones of objects (a pointer object pointing to the real object) to be used in loops and such. By eliminating the need for LinkedList<T> and the like, you can achieve code speeds that are very close to C++. You can go even further if you know what you are doing and give into the world of pointers in C# to make it EQUALLY AS FAST AS C++.

I've written a Motion Capture Detection system using C# and in C++ (originally in C++) and I acheieve the SAME performance in C# (using pointers in unsafe code) as I do in C++.

Like many people have stated above. The speed decrease in Managed code lies in the fact that .Net has to get a pointer to the object to be used in the Managed Memory pools. Getting these pointers can be costly for high-performance code and would be better left to you.

A List<Model> is slower to iterate through than an unsafe { List<Model*> } however, you can really damage your system if you don't take care of your pointer objects or mess up on pointer math. Use with caution. This is how I am able to manage over 4,000 models at ~1200 poly each on screen in my game engine (running at 900fps with vsync off and all that jazz).

XNA, крутая вещь только в прямых руках. Пара бенчмарков C#:
http://www.grimes.demon.co.uk/dotnet/man_unman.htm
http://www.osnews.com/story.php/5602...File-IO/page3/
http://blogs.msdn.com/ricom/archive/...ry-reader.aspx
Нужно время, чтобы на XNA начали делать действительно быстрые игры. Должно сложится правильное мнение "как" именно делать игры на .Net.

Цитата:

XNA не подходит в силу своей тормознутости.

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

**Feanor62rus** · 20.12.2007, 22:11

Цитата:

Сообщение от JohnK

Просто на С++ прогят профи, вот и выходят такие крутые игры, да и материала полно.

А как будто профи делать больше нечего, кроме как сидеть в неудобной и непонятной среде? Вот они и не слазят с С++ именно из за его скорости.
Был бы C# действительно так быстр, как ты утверждаешь, то профи давным давно бы сидели на нем, однако же этого не произошло.

Цитата:

Сообщение от JohnK

http://www.grimes.demon.co.uk/dotnet/man_unman.htm
http://www.osnews.com/story.php/5602...File-IO/page3/
http://blogs.msdn.com/ricom/archive/...ry-reader.aspx

Где тесты в 3D приложениях?
Кстати в одном из тестов есть:
___________________double math
Visual C++___________6.4
Visual C#____________17.7
Это довольно важно в 3D и как видим тут просто пропасть.

**pokibor** · 20.12.2007, 22:38

Цитата:

Сообщение от noLove

pokibor а ты пробовал XNA на вкус?

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

Цитата:

Сообщение от noLove

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

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

Цитата:

Сообщение от noLove

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

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

Цитата:

Сообщение от noLove

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

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

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

Цитата:

В новые языки/платформы типа C# и Java встроены модные ныне «сборщики мусора». Это программные сущности, призванные радикально ускорить выделение и освобождение небольших кусков памяти (так присущих ООЯ). Нам говорят примерно следующее: GC (сокращение от Garbage Collector) вообще не занимается лишним освобождением памяти. Вернее, он пытается отложить этот неприятный (для него) момент на как можно более поздний срок. Т.е. пока есть свободная память, ее будут занимать, занимать и занимать, а когда память иссякнет, или когда процессор будет менее загружен, начнется процесс сборки мусора.

Давайте даже представим, что это всё реализовано идеально и без ошибок. Но ёлки-палки! Нынешние игры жрут по 2-3 гигабайта памяти, когда же Вы это поймёте! В них память всегда будет висеть рядом с пределом, а сборщик будет постоянно (подчёркиваю - постоянно! Т.к. память висит у предела) бегать по этим трём гигабайтам (!!!) и пытаться там что-то освободить.
Только из одного этого примера видно, что для игр C# не подходит в принципе, и если у Вас нет чего возразить именно на ситуацию со сборкой памяти (а это вывод, подчеркну, из заявления о работе сборщиков, т.е. именно того, что должно быть в идеале), то уж признайте - написанные на C# Crysis и иже с ним будет тормозить безбожно просто потому, что постоянно будет пахать сборщик памяти.
В C++ же есть возможность оптимизации по памяти, inline-функции и соответствующая оптимизация и т.п., чего в C# просто быть не может.

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

noLove · 20.12.2007, 23:08

Скрытый текст:

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

Скрытый текст:

А ты явно статью до конца не дочитал. Там вроде ясно расписаны моменты, провоцирующие запуск GC.

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

**pokibor** · 20.12.2007, 23:57

Цитата:

Сообщение от noLove

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

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

Цитата:

Сообщение от noLove

А ты явно статью до конца не дочитал. Там вроде ясно расписаны моменты, провоцирующие запуск GC.

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

Цитата:

Сообщение от noLove

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

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

noLove · 21.12.2007, 02:24

этот GC вызывается в тех случаях, которые описаны в статье, 3 и 4 пункты - это криворукость программиста.

А удалять объекты в шарпе никто не запрещал, GC здесь не при чем

JohnK · 21.12.2007, 02:24

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

**pokibor** · 21.12.2007, 09:37

noLove
Сколько раз Вам повторять, чтобы Вы поняли? C# - это тот самый GC. Он записан в спецификации. Всё остальное - это, извините, unsafe. А unsafe - это C++. Какое у C# будет преимущество перед C++, если писать unsafe-коды, не подскажите?
Проблема не в том, когда вызывается GC, а в том, что когда он это делает, он пробегается по целым 3-4 гигам памяти и её чистит. А в Вашей же статье написано, что все остальные потоки на это время приостанавливаются... То есть и рендеринг, и физика, и AI. Привет, тормозам.

Скрытый текст:

Цитата:

Сообщение от JohnK

Я вижу сборщик мусора - это единственный контр-аргумент.

Наверное, единственный, который Вы увидели или по которому у Вас есть что сказать. Вторым по серьёзности идёт double math - чуть выше написано. А дальше ещё много чего можно вставить. Принципиальное отсуствие inline'ов, например. Когда язык донельзя виртуализирован - это весело, я вам скажу.

Цитата:

Сообщение от JohnK

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

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

Цитата:

Сообщение от JohnK

Тем более XBOX360 имеет никакующий сброщик, вот и приходится аккуратно писать.

Вы сами себе противоречите. Вы фактически сейчас казали, что XBOX не поддерживает спецификацию .NET. Учитывая, GC есть даже в мобильных устройствах (см. статейку noLove), могу с уверенностью заявить - Вы ошибаетесь.

noLove · 21.12.2007, 09:52

Цитата:

Сообщение от pokibor

noLove
Сколько раз Вам повторять, чтобы Вы поняли? C# - это тот самый GC. Он записан в спецификации. Всё остальное - это, извините, unsafe. А unsafe - это C++. Какое у C# будет преимущество перед C++, если писать unsafe-коды, не подскажите?

XNA для .NET только :Ъ
да и к тому же писать на шарпе горадо приятнее. КОд получается легко читаем и легко усвояем

Цитата:

Сообщение от pokibor

Проблема не в том, когда вызывается GC, а в том, что когда он это делает, он пробегается по целым 3-4 гигам памяти и её чистит. А в Вашей же статье написано, что все остальные потоки на это время приостанавливаются... То есть и рендеринг, и физика, и AI. Привет, тормозам.

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

Цитата:

Сообщение от pokibor

могу с уверенностью заявить - Вы ошибаетесь.

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

**pokibor** · 21.12.2007, 10:01

Цитата:

Сообщение от noLove

XNA для .NET только :Ъ
да и к тому же писать на шарпе горадо приятнее. КОд получается легко читаем и легко усвояем

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

Цитата:

Сообщение от noLove

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

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

Цитата:

Сообщение от noLove

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

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

JohnK · 21.12.2007, 10:05

Цитата:

А поставил за конкретное непонимание основ программирования

А не много ли на себя берете?

Цитата:

Вы сами себе противоречите. Вы фактически сейчас казали, что XBOX не поддерживает спецификацию .NET. Учитывая, GC есть даже в мобильных устройствах (см. статейку noLove), могу с уверенностью заявить - Вы ошибаетесь.

Может вы сначала ознакомитесь с программированием на XNA? У хкоробки есть сборщик, просто он вызывается очень часто, поэтому приходится писать аккуратно ( читай не мусорить ) и удалять некоторые объекты самостоятельно.

Цитата:

При удалении объектов вручную, ещё раз повторяю, код будет unsafe и мало чем отличаться от C++'ого кроме отсуствия оптимизации

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

noLove · 21.12.2007, 10:19

Цитата:

Сообщение от pokibor

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

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

Цитата:

Сообщение от pokibor

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

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

Цитата:

Сообщение от pokibor

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

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

**pokibor** · 21.12.2007, 10:37

Цитата:

Сообщение от noLove

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

О-па! Так-так-так! Ну-ка, объясните-ка мне тогда, что такое движок, почему Irrlicht - готовый движок, а XNA - нет.

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

Цитата:

Сообщение от noLove

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

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

Цитата:

Сообщение от noLove

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

ООО, Вы хоть по C# хелп читали (кстати, Вы ещё и название интерфейса неправильно написали. Оно через 'a' пишется)? Процетирую MSDN:

Цитата:

IDisposable Interface
Defines a method to release allocated unmanaged resources.
...
The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used, however, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.

Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed.

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

JohnK · 21.12.2007, 11:35

Уж разрешите поправлю коллегу. Он, кстати вполне прав, но раз уж вы так придирчевы, то знайте: XNA это фреймворк, т.е. не GAPI, но и не двиг. А про ирлича вы отожгли, тов. модератор.

Цитата:

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

Сыграйте в XNARacer например, может вы перестаните нести подобный бред. Всё печетесь о каких то тормозах при переборе гигов памяти - на игре ясно видно.

Цитата:

Этот Ваш интерфейс IDisposable обеспечивает уничтожение не относящихся с GC объектов, таких как дескрипторы открытых файлов, потоков, окон. ВСЁ! К освобождению выделенной под класс памяти он не имеет ни малейшего отношения, она всё равно убирается GC.

Без комментариев.

**pokibor** · 21.12.2007, 11:45

Цитата:

Сообщение от JohnK

Уж разрешите поправлю коллегу. Он, кстати вполне прав, но раз уж вы так придирчевы, то знайте: XNA это фреймворк, т.е. не GAPI, но и не двиг.
А про ирлича вы отожгли, тов. модератор.

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

Цитата:

Сообщение от JohnK

Сыграйте в XNARacer например, может вы перестаните нести подобный бред. Всё печетесь о каких то тормозах при переборе гигов памяти - на игре ясно видно.

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

Цитата:

Сообщение от JohnK

Без комментариев.

Уж извольте прокомментировать. Этот текст взят из MSDN. Что такое MSDN и кто его писал Вы, надеюсь, знаете. А там прямо написано: "Defines a method to release allocated unmanaged resources." И что относится к unmanaged resources, там тоже написано: "unmanaged resources such as window handles, or open files and streams". Возражения? Сошлётесь на ошибку в MSDN?

Сейчас по-подробнее прочитал про IDisposable - чуть со стула со смеху не свалился. Я то по простоте душевной думал, что он только для определённого класса объектов. Оказалось - нет, M$ расщедрилась на возможность сделать класс unmanaged. После чего мы, правда, терям все достоинства автоматической сборки мусора, взамен получая кучу проблем.
Начнём с того, что наследование от IDisposable требует нехилых трудозатрат, т.к. нужно вручную вызывать Dispose() всех предков и обрабатывать все исключения, которые ими возвращаются, да ещё и необходимо ручками прописывать работу с любым классом, являющимся unmanaged.
Далее, если есть два класса - один unmanaged, другой - managed и они как-то связаны (а в игре все объекты тесно связаны) - то всё очень-очень печально, ибо проверки прописывать замучаешься. Значит, половину игры нужно делать unmanaged. При том, что долбаний с Dispose куча (не в пример нормальным деструкторам в C++).
Итог?
1) IDisposable порождает проблемы похлеще, чем C++'ные деструкторы, т.е. ухудшает код по сравнению с C++ (кто там хвастался, что на C# код понятнее?)
2) Он не даёт никаких преимуществ по сравнению с C++, зато убивает преимущества GC
3) Его нужно везде прописывать ручками. При этом замечу, что автоматическая сборка памяти всё равно никуда не девается и исправно жрёт свои ресурсы. Хотя бы на определение, а есть ли ей смысл сейчас вызываться (т.е. производительность всё равно страдает).
Такими темпами мы придём к необходимости писать на C# в стиле C++. Вперёд! Осталось совсем немного - признать необходимость юзания unsafe-кода (хотя unmanaged - это по сути и есть unsafe, ибо он опасен утечкой всех unmanaged ресурсов, которые C#-писатели освобождать не привыкли).

Я в шоке... Сейчас почитал про реализацию GC - ещё на пару минут жизнь себе продлил. Он-то, оказывается, реализован очень-очень грамотно. Он не считает ссылки на объект, а по дереву объекты обходит. И объект не нужен, если его нельзя достичь из корневого узла. А это ещё какое замедление алгоритма, особенно в сложных приложениях вроде игр, где дерево имеет кучу длинных ветвей...
P.S. Если что - реализация грамотная без сарказма (если реализовывать иным образом - то объект спокойно может "потеряться", к примеру, если сам на себя ссылается). Вот только опять же для сложных приложений плохо подходящая.

**[CCCP] Monster** · 21.12.2007, 12:00

Цитата:

А не много ли на себя берете?

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

Цитата:

Без комментариев.

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

noLove · 21.12.2007, 15:58

Цитата:

Сообщение от pokibor

О-па! Так-так-так! Ну-ка, объясните-ка мне тогда, что такое движок, почему Irrlicht - готовый движок, а XNA - нет.

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

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

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

Скрытый текст:

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

Цитата:

Сообщение от pokibor

Простите, XNARacer - это вершина игростроя, по-Вашему? Мы тут, если Вы не в теме, говорим о революции в игростроении.

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

Скрытый текст:

Цитата:

Сообщение от pokibor

Сейчас по-подробнее прочитал про IDisposable - чуть со стула со смеху не свалился. Я то по простоте душевной думал, что он только для определённого класса объектов. Оказалось - нет, M$ расщедрилась на возможность сделать класс unmanaged. После чего мы, правда, терям все достоинства автоматической сборки мусора, взамен получая кучу проблем.
Начнём с того, что наследование от IDisposable требует нехилых трудозатрат, т.к. нужно вручную вызывать Dispose() всех предков и обрабатывать все исключения, которые ими возвращаются, да ещё и необходимо ручками прописывать работу с любым классом, являющимся unmanaged.
Далее, если есть два класса - один unmanaged, другой - managed и они как-то связаны (а в игре все объекты тесно связаны) - то всё очень-очень печально, ибо проверки прописывать замучаешься. Значит, половину игры нужно делать unmanaged. При том, что долбаний с Dispose куча (не в пример нормальным деструкторам в C++).
Итог?
1) IDisposable порождает проблемы похлеще, чем C++'ные деструкторы, т.е. ухудшает код по сравнению с C++ (кто там хвастался, что на C# код понятнее?)
2) Он не даёт никаких преимуществ по сравнению с C++, зато убивает преимущества GC
3) Его нужно везде прописывать ручками. При этом замечу, что автоматическая сборка памяти всё равно никуда не девается и исправно жрёт свои ресурсы. Хотя бы на определение, а есть ли ей смысл сейчас вызываться (т.е. производительность всё равно страдает).
Такими темпами мы придём к необходимости писать на C# в стиле C++. Вперёд! Осталось совсем немного - признать необходимость юзания unsafe-кода (хотя unmanaged - это по сути и есть unsafe, ибо он опасен утечкой всех unmanaged ресурсов, которые C#-писатели освобождать не привыкли).

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

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

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

IDisposable - мечта pokibor

**pokibor** · 21.12.2007, 16:20

Цитата:

Сообщение от noLove

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

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

Дальше у Вас идёт цитата моих слов в текте Вашего поста... к чему это, не понял. Наверное, ошибка... Потрудитесь перечитать свой пост после его публикации.

Цитата:

Сообщение от noLove

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

И какой тогда смысл? Половина объекта будет managed и будет убираться сборщиком мусора, половина - unmanaged и будет убираться Dispose. Вы, кажется, не поняли, что Dispose работает в полном отрыве от сборщика мусора. Либо - либо, а попытки совместить приведут к тому, что у Вас в объекте будут недостатки обоих подходов - т.е. жуткие руковывороты с Dispose и лишние затраты памяти/её уборка GC.

Цитата:

Сообщение от noLove

ты уж определись, о чем ТЫ говоришь, о GC, или о революции в игрострое.

О революции в игрострое говорит тема, а GC не даёт C# и XNE быть революцией. Не только он, конечно (и что это про double math заглохло? Нет возражений?), но в частности.

Цитата:

Сообщение от noLove

XNARacer - наглядный пример игры на платформе .NET XNA, там есть все, современная графика, звук, физика, игровая логика. Оно летает при всем при этом

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

Цитата:

Сообщение от noLove

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

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

Цитата:

Сообщение от noLove

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

В таком случае бредом является и использование DirectX, а уж XNA как надстройки над ним - и подавно. Не смешите народ такими заявлениями!
GAPI - это сборник часто употребляемых функций, не более того. Вас никто не заставляет пользоваться только его средствами от начала и до конца. Вы всегда можете открыть исходный код (Irrlicht - open source, а вот XNA - нет...) и поменять там что нужно, или просто частично использовать стандартные функции, а частично - непосредственно DirectX или OpenGL-функции. C# и XNA такого выбора не дают.

Цитата:

Сообщение от noLove

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

К чему вопрос? Нет, не участвовал. Однако я писал диплом на соответствующую тему и защитил его с отличной оценкой (это если говорить о заслугах, причём отдельно замечу, что этот разговор начали ВЫ, а не я). Вы, надо думать, и этим похвастаться не можете.

Цитата:

Сообщение от noLove

IDisposable - мечта pokibor

За меня о моих мечтах говорите? IDisposable - это мой ночной кошмар. Деструктор, который нужно вызывать ручками, да ещё следить, чтобы он не дай Бог не стал конфликтовать с автоматической сборкой, отлавливать все исключения... Нет, спасибо. Моя мечта уже реализована в C++.
И в последний раз - просьба мой ник не искажать. Я над Вашим не издеваюсь.

noLove · 21.12.2007, 17:51

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

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

**[CCCP] Monster** · 21.12.2007, 18:04

Цитата:

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

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