xna performance

[benyamin_pc]

سرعت اجرای برنامه های نوشته شده توسط xna نسبت به directx و opengl چطوره؟
وقتی باهاش برای ویندوز موبایل و ایکس باکس مینیویسن باید سرعت خوبی داشته باشه وگرنه تو دیوایس ها و کنسول ها سرعتو الکی پایین نمیارن پس تو ویندوزم باید خوب باشه؟
توی dx sdk های جدید دیگه dx با c# یا همون managed رو مایکروسافت برداشته و بیشتر بجاش xna رو رفرنس میده این یعنی دیگه نمیشه با کلاسهای dx توی c# کدی زد؟تو کارهای صوتی و تصویری که تو c# به کمک dx میزدیمو میشه با xna هم زد؟

[hi.alir]

سرعت اجرای برنامه های نوشته شده توسط xna نسبت به directx و opengl چطوره؟ وقتی باهاش برای ویندوز موبایل و ایکس باکس مینیویسن باید سرعت خوبی داشته باشه وگرنه تو دیوایس ها و کنسول ها سرعتو الکی پایین نمیارن پس تو ویندوزم باید خوب باشه؟
به خاطر MSIL رو ویندوز یکم کندتر هست. در واقع XNA همون API های directx 9.0 رو استفاده میکنه. ( می تونید سورسش رو ببینید تا بفهمید دقیقا چه میکنه )


توی dx sdk های جدید دیگه dx با c# یا همون managed رو مایکروسافت برداشته و بیشتر بجاش xna رو رفرنس میده این یعنی دیگه نمیشه با کلاسهای dx توی c# کدی زد؟
شدنش که میشه ولی وقتی XNA هست چرا managed directx؟


تو کارهای صوتی و تصویری که تو c# به کمک dx میزدیمو میشه با xna هم زد؟
بله میشه زد. البته xna یکم امکانات بیشتری داره و یه مقدار ساده تر هست.

ولی در کل باید بگم که XNA برای بازی های آرکید خوبه و در همون حد جواب میده، مثل limbo, super meat boy و اینا. برای بازی ای مثل Battlefield 3 حتی فکرش رو نکنید.

XNA نسبت به directx چند تا مشکل داره:
اول اینکه زیر dx10 هست. یعنی امکاناتش فقط در حد dx9 هست و از تکنلوژی های جدیدی که تو dx10 و 11 افزوده شده نمی تونید استفاده کنید.
چون یه کتابخونه ی دیگه روی directx 9 هست و در دات نت، نسبت به خود dx9 کندتر هست.

البته باید بگم که از اختلاف سرعت بین سی شارپ و سی پلاس پلاس چشم پوشی کردم.

در مورد opengl هم اطلاعات چندانی ندارم ولی باید سریع تر از xna باشه. البته این رو هم فراموش نکنید که کد زدن با دات نت یا همون xna به منزله ی فراموش کردن سایر پلتفرم هاست، البته خب تو ایران چندان فرقی نداره!

[benyamin_pc]

اون مشکل ساپورت امکانات جدید توی xna که صد در صد حل میشه چون کلا مایکروسافت داره دولوپراشم علاوه بر ویندوز فون و کنسولاش به xna ارجاع میده و ساپورت خفنی هم رو xna گذاشته و وقتی هم داره از خود dx توی xna استفاده میکنه پس سرعتشم باید همون باشه چون اگه ما هم با dx بنویسیم بهتر از xna در نمیاد! اون فقط اومده دستورها و کلاس های ساده ای در اختیار ما گذاشته که به بهترین نحو با dx میشده نوشت! حتی از اینکه ما بخاهیم باهاش بنویسیم!
پس با این تفاوت نباید سرعتش بد باشه چون اکثر بازی های سنگینو با dx مینویسن در صورتی که بعضی ها معتقدن open gl سرعت بیشتری داره پس باید منتظر بود بازی های جدیدو با xna بزنن
محیط کد هم زیاد فرق نداره c++ باشه یا c# چونکه اونا از cpu استفاده میکنن نه gpu . فقط اون رابطی که از gpu استفاده میکنه مهمه چقد optim باشه وگرنه اصلا managed code معرفی نمیشد

[hi.alir]

پس چرا سوال می کنی؟

[seyedof]

اون مشکل ساپورت امکانات جدید توی xna که صد در صد حل میشه چون کلا مایکروسافت داره دولوپراشم علاوه بر ویندوز فون و کنسولاش به xna ارجاع میده و ساپورت خفنی هم رو xna گذاشته و وقتی هم داره از خود dx توی xna استفاده میکنه پس سرعتشم باید همون باشه چون اگه ما هم با dx بنویسیم بهتر از xna در نمیاد! اون فقط اومده دستورها و کلاس های ساده ای در اختیار ما گذاشته که به بهترین نحو با dx میشده نوشت! حتی از اینکه ما بخاهیم باهاش بنویسیم!
پس با این تفاوت نباید سرعتش بد باشه چون اکثر بازی های سنگینو با dx مینویسن در صورتی که بعضی ها معتقدن open gl سرعت بیشتری داره پس باید منتظر بود بازی های جدیدو با xna بزنن
محیط کد هم زیاد فرق نداره c++ باشه یا c# چونکه اونا از cpu استفاده میکنن نه gpu . فقط اون رابطی که از gpu استفاده میکنه مهمه چقد optim باشه وگرنه اصلا managed code معرفی نمیشد

سلام
اولا شما اگر خودتون نتیجه رو میدونید پس چرا سوال کردید؟
1) اینکه مایکروسافت چکار میکنه اصلا ملاک تصمیم گیری نیست. مایکروسافت کارهای اشتباه هم زیاد میکنه که بعد یک مدت برمیگرده مثلا یه مدت روی VB خیلی تبلیغ و سرمایه گذاری کرد و خیلی ها هم مثل شما فکر کردند و به اون سمت رفتن، پس باید گیم ها هم با VB نوشته میشد؟
2) اینکه چه زبانی برای چه کاری خوبه به عوامل زیادی بستگی داره. این بحث خیلی تکراریه و بارها توی همین انجمن مطرح شده و البته به دلیل بدیهی بودن توی فرومهای خارجی خیلی کمتر از این بحثها میبینید. من فقط خیلی خلاصه میگم اینکه میشه یه چیزی رو با یک زبونی نوشت دلیل نمیشه که اینکار اشتباه نیست. مثلا نرم افزار حسابداری رو مسلما میشه با اسمبلی هم نوشت ولی هیچ آدم عاقلی اینکار رو نمیکنه. زبان C++ استاندارد برنامه نویسی سطح پایین و برنامه های سیستمی است و حتما هم خوب جواب داده که اینهمه سال داره استفاده میشه. بحث سرعت و غیره رو پیش نمیکشم ولی دقت کنید که اکثر SDK ها و Middleware های دنیا که برای بازی سازی هستند برای C++ توسعه داده میشن و استفاده اوونها در سایر زبانها و محیطها عمدتا دردسر داره. دلیلش هم واضحه چون C++ فعلا زبان استاندارد گیم نویسی است. C# برای Application و برنامه هایی که UI زیاد دارن مناسبتره، بعضی از موتورهای گیم خارجی هم خود موتورشون رو با C++ مینویسن و ابزارهاش مثل Level Editor رو با C# چون توسعه UI و داشتن کنترلهای پیچیده یه جورایی توی C# راحتتره.
3) سرعت گیم فقط به DirectX و OpenGL نیست. عوامل خیلی زیاد دیگه هم هست که موتورهای بازی رو CPU Bound و Memory Bound میکنه. از طرفی باز هم ابزارهای مختلفی مثلا از شرکت Intel وجود داره برای بهینه سازی کد و... که برای C++ هستند و الزاما از C# سریعتر خواهد بود. سرعت فقط مختص Runtime Library زبان نیست، هر چند که همون رو هم اینتل براش پکیج هایی داره که جایگزین کتابخونه های خود VC میشه و سریعترشون میکنه. شما باید ساختارهای داده ای مختلف و تاکید میکنم عملیات حافظه ای بهینه داشته باشید که توی اینها سرعت C و C++ ثابت شده است.
4) اگر میخواهید بازی کوچک بنویسید (یا نسبتا کوچک) میشه با xna کار کنید و C# ولی برای ساخت بازیهای بزرگ اصلا توصیه نمیشه کما اینکه همین الان هم توی دنیا اینکار رو نمیکنند مثالش هم بازیهای معروفی است که بچه ها نام بردند.
5) من این بحث رو ادامه نمیدم و از مدیر انجمن هم خواهش میکنم قبل از اینکه بحثهای بیهوده تکراری که جواب واضحی داره و دلایلش هم قبلا ذکر شده و اصلا حتی فکر کردن هم نمیخواد و با یک نگاه به بازیهای خارجی میشه به همین نتیجه رسید، و معمولا هم این بحث با مقاومت روبرو میشه و فکر میکنند تعصب یا زور در کاره (که اینطور نیست واقعیت اینه)، این تاپیک رو قفل کنند.

ممنون علی

[pswin.pooya]

در ابتدا بايد بگم كه كاملا با آقاي سيداف موافقم واقعا اين شكل بحثها بيخوده و بارها مطرح شده. من نه تنها تو اين انجمن با اين مشكل رو به رو هستم توي انجمن سيستم عامل هم مشكل C# رو دارم و به شكل باور نكردني افرادي رو ميبينم كه ميخوان با C# سيستم عامل بنويسن (بگذريم)

توي برنامه هاي realtime به حداكثر سرعت ممكن نياز هست (مربوط به بحث بلادرنگ)‌ و از اونجا كه بازيها برنامه هاي بلادرنگ نرم هستند بايد سريعترين گزينه ها رو انتخاب كرد. سريعترين گزينه توي هر ماشني زبان ماشين هست كه اصطلاحا بهش ميگن اسمبلي متاسفانه چون كد اسمبلي ديگه بهينه نميشه و معمولا برنامه نويسها هيچ وقت بصورت بهينه كد نمي زنن و همچنين هزينه ساخت برنامه به زبان اسمبلي بسيار بالاست كسي نمياد با اسمبلي بازي بسازه نزديكترين گزينه به اسمبلي زبان C هست كه كد بخوبي توسط كامپايلر بهينه سازي ميشه و هزينه توليد به مراتب كمتره. اما از مدل شي گرا به صورت ذاتي پشتيباني نمي كنه به همين دليل هم خيلي ها باهاش بازي نميسازن (چون يكسري از APIها مثل DX و Phsix شي گرا هستند) جان كارمك كه بازي معروف Doom رو ساخته خودش از اين زبان استفاده ميكنه. نزديكترين گزينه موجود به C زبان C++ هست كه شي گرايي رو ساپورت ميكنه پس در نتيجه ايده آل ترين هم از نظر معيارهاي مطرح شده هست.

مشكل زبانهاي كه به CIL كار ميكنن (مثل جاوا و سي شارپ) وجود ماشين مجازي مابين ماشين و كد اجرايي است كه در نتيجه باعث كند شدن ذاتي برنامه ها ميشن مخصوصا برنامه هايي كه مرتبا با منابع سيستمي سرو كله ميزنن (مثل بازيها)‌ . بخاطر بحث ريل تايم بازيها امكان حركت به سمت اينجور زبانها وجود نداره. (توي پرو‍ه هاي تجاري واقعي) هرچند كه پيشرفت سخت افزار باعث شده كه بشه بازيهاي سه بعدي تجاري رو با اين زبانها ساخت اما همزمان با پيشرفت نيازها هم افزايش پيدا كرده و همين افزايش باعث ميشه كه هميشه اين زبانها چند قدم از زبانها سيستمي عقبتر باشن مثلا فرض كن اگر سطح بازيها مثل بازيهاي 2005 مي موند و ديگه پيشرفت نمي كرد توي 2010 و يا چند سال بعد از اون مي شد برنامه هاي ريل تايم و يا بازيهاي قابل قبول با C# ساخت اما الان حتي بازهاي امسال رو نميشه با دو سال قبل مقايسه كرد چه برسه پنج، شيش سال پيش


هر چند که همون رو هم اینتل براش پکیج هایی داره که جایگزین کتابخونه های خود VC میشه و سریعترشون میکنه. شما باید ساختارهای داده ای مختلف و تاکید میکنم عملیات حافظه ای بهینه داشته باشید که توی اینها سرعت C و C++ ثابت شده است

من كامپايلر اينتل رو دارم متاسفانه سرعتش از VC 2010 كمتره و در حدود سرعت GCC هست. (شايد هم من نتونستم درست ازش كار بكشم.)

[benyamin_pc]

نه اصلا بحث تعصبی در کار نیست!
فقط داریم چیزائی که هستو یکم مقایسه می کنیم
البته ی چیزائی هست که تو بحث هم آقای پویا هم سیده عزیز خودتون هم بهش اشاره کردین و اون اینه که همیشه با بهینه ترین نیاز نیست کد زد
مثل نوشت بازی با اسمبلی و استفاده از وقفه ها و رجیسترهای کارت گرافیک!!
ی چیزائی بعضی وقتا کار رو سریع تر می کنن اما سرعتشون زیاد تفاوت نداره و می صرفه که اون کارو با اون انجام داد چون وقت کمتر تلف میشه و حتی تو کار میشه کمتر به جزئیات توجه کرد و بیشتر روش تمرکز کرد و حرفه ای تر کار کرد
نمونش فلشو در نظر بگیرین تا قبل از اینکه کلاس های کار با 3D رو خودش توسعه بده من خودم با ماتریس ها کار می کردم و حتی ی بازی 3D ماشین خیلی ساده ساختم اما خیلی دردسر داشت و وقت گیر!
حتی یاد گیری و کار کردن باهاش . اما الان با کلاسهای موجود به راحتی میشه همون کارو کرد!
حتی خیلی ها معتقدن که opengl سرعتش نسبت به dx بیشتره اما اکثر بازی ها با dx و c++ هستن
نوشتن بازی با xna چندتا ویژگی داره که یکیش ساده بودنشه حداقل یکی دیگش اینه که هم برای xbox360 هم pc و هم windows phone میشه نوشت
در مقابل کاهش چند درصدیه سرعت نسبت به umdx چیزائی داره که احتمال داره بتونه برا خودش جا باز کنه
ولی مایکروسافت چرا باید برای کنسولش هم از این استفاده کنه؟ کنسولی که تکتازه! اگه قراره سرعت اجرای بازی ها رو به شدت پایین بیاره و سخت افزار کنسولش لازم باشه تغییر چشم گیر کنه تا بتونه بازی هائی در رده بهترین کنسول های دنیارو همچنان ران کنه؟

[سپول]

آقای benyamin شما اطلاعات کافی نداری ولی اومدی دوباره مثل 200 تا تاپیک قبلی (اگه یه سرچ بزنی قبل پست بد نیست) همونارو دوباره می گی.
xna برای بازی های خیلی سبک و اونهایی که توان پردازشی بالا نمی خوان خوب هستند همونطور که بقیه هم گفتن چون یک زبان میانی هست مانند اسکریپت. در بازی ها هم بیشتر از اون چیزی که شما فکر می کنید توان پردازشی لازمه، فرقشون هم مثل اسمبلی نیست!!! کامپایلر C++ در واقع همون کد اسمبلی (+ زبان ماشین) تولید می کنه اما کامپایلر C# زبان میانی تولید می کنه، این قضیه از زمان Visual basic هم بود و چیز جدیدی نیست.

در xbox هم همون C++ استفاده می شه، در معدود بازی های xbox live مثل بازی های پک من و مار و پله و این چیزها از XNA هم استفاده کردند اون هم دلیلیش اینه که مایکروسافت این قابلیت گذاشته که گیم سازها به این زبان (که ساخته خودشون هست و پول ازش در میارن) کشیده بشن.

زبان استاندارد بازی سازها C++ هست برین کمی در اینترنت جستجو کنید و لطفا عبارات "XNA is the best" ، "XNA is faster than C" و اینجور چیزها رو هم نزینید که نتیجه ای که خودتون می خواهید توی یک سایت در و پیت پیدا کنید. مثل سوالی که اینجا کردید، .. اول سوال می کنی، بعد بحث می کنه که نه اون بهتره ؟ واقعاً چرا سوال کردی ؟ همون اول می گفتی حرفت رو دیگه.

لطفا این تاپیک رو قفل کنید تا ایشون دوباره تکرار مطالب 200 تا پست قبلی رو نکرده.

[pswin.pooya]

حتی خیلی ها معتقدن که opengl سرعتش نسبت به dx بیشتره اما اکثر بازی ها با dx و c++ هستن

اين مقايسه كاملا اشتباه. سرعت OpenGL و يا كارايي اون بشدت وابسته به درايور شركت توليد كننده پردازنده گرافيكي هستش. مثلا همين دو سه روز پيش ATI درايورهاشو ارتقاع داد و سرعت OpenGL نسبت به قبل توي شيدر مدل 5 چند برابر شد با اينكه با همون كارت گرافيك قبل از اين ماجرا سرعت GL با همون مثال يه چيزي جدود چهار برابر كمتر از dxبود.
به غير از اين مساله. مشكل ديگه توي نحوه پياده سازي هست. يعني با اينكه از نظر مفهموي پياده سازيهاي dx و gl يكي هستند اما در عمل تفاوتهاي زيادي هست كه رعايت كردن و يا پياده سازي به سبك يكي از اين دو API ميتونه به نحوه پياده سازي اون يكي API از نظر كارايي صدمه بزنه. پس در نتيجه هيچ وفت نميشه سرعت اين دو API رو با هم مقايسه كرد.


xna برای بازی های خیلی سبک و اونهایی که توان پردازشی بالا نمی خوان خوب هستند همونطور که بقیه هم گفتن چون یک زبان میانی هست مانند اسکریپت. در بازی ها هم بیشتر از اون چیزی که شما فکر می کنید توان پردازشی لازمه، فرقشون هم مثل اسمبلی نیست!!! کامپایلر C++ در واقع همون کد اسمبلی (+ زبان ماشین) تولید می کنه اما کامپایلر C# زبان میانی تولید می کنه، این قضیه از زمان Visual basic هم بود و چیز جدیدی نیست.
كاملا موافقم فقط بايد اين رو هم اضافه كنم كه تمام زبانهاي سطح بالا يكسري كد اضافي توليد ميكنن. خوشبختانه ميشه داخل C/C++ تا حدي اين كدها رو تحت كنترل گرفتش مثلا براي فراخواني توابع يكسري كد اضافه ميشه ( به عنوان مثال توي استاندارد cdecl پارامترها داخل پشته وارد ميشن و شماره اونها داخل ebx گذاشته ميشه) و زمان خروج هم يكسري دستور ديگه (مثلا توي همون cdecl مقدار برگشتي داخل eax گذاشته ميشه) خب اين مساله بايد حتما وجود داشته باشه اما داخل تابع زير هيچ كدوم از اينها بدرد نمي خوردن:


void myFunc()
{
printf("salam");
}

تا اونجا كه من ميدونم تقريبا تمام كامپايلرهاي معروف C/C++ قابليت تعريف توابع nacked رو دارن كه ميتونه اين حجم اضافي كد رو حذف كنه.

و البته كنترلهاي بيشتر كه لازمه برنامه نويسي سيستمي هست. مثلا نمونه اون همون _cdecl هست كه باعث ميشه رفتار پيش فرض از stdcall به cdecl تغيير كنه خب اين لازمه برقراري ارتباط با ابزارهاي جانبي هست. مثلا فرض كن قرار با يه درايور داخل سيستم عامل x ارتباط برقرار كني. كامپايلر شما با استاندارد stdcall كار ميكنه و درايور مقصد با cdecl در نتيجه امكان فرخواني توابع درايور براي شما وجود نداره. اين مبحث شايد توي بايسازي مخصوصا داخل ويندوز چندان پيش نياد و بروز نكنه اما بطور يقيين داخل موارد ديگه مثل طراحي سيستم عامل ها و يا بازيسازي رو پلتفرمهاي ديگه خودش رو بروز ميده.

برنامه نويسي سيستمي تحت C/C++ بيشتر از يك ترجيح بنا به دلايل زيادي يك اجبار هست. اجباري كه برنامه نويسهاي C/C++ ازش شكايتي ندارن و باهاش حال ميكنن و برنامه نويسهاي زبانهاي ديگه هي سعي ميكنن توجيح كنن كه اين شكلي نيست. من نمونه اون رو هم گفتم (داخل تالار سيستم عامل مي تونيد اين مطلب رو ببينيد)‌.

با اينكه C/C++ سريعترين گزينه ها بشمار ميرن هنوز برنامه نويسهاي بازي از مشغول بدون مواردي مثل CPU و يا حافظه شاكي هستند و كم ميارن چه برسه برن دنبال گزينه اي مثل C# كه به مراتب كندتر هست. اصولا برنامه نويسهاي مبتدي اعتقاد دارن كه سرعت پردازنده ها به ميزان كافي بالا رفته كه نبايد نگران اين چيزها بود اما برنامه نويسهاي حرفه اي بزرگترين مشكلشون همين مساله هست و دليل اون هم اينه كه سرعت رشد نيازها خيلي بيشتر از سرعت رشد سخت افزارها شده. و هميشه برنامه نويسها از روز اول تا امروز با محدوديتهاي سخت افزاري درگير بودن و توي اين چند دهه شما نمي تونيد روزي رو پيدا كنيد كه سرعت سخت افزار به اندازه كافي بالا رفته باشه كه برنامه نويسها هيچ محدوديتي نداشته باشن.

مثلا يه زماني تصور يك پردازنده mobil با سرعت 100 مگاهرتز يك توهم به شمار ميرفت (شايد دو دهه پيش و يا كمتر) ولي امروز پردازنده هاي موبايل 1.2GHz هم نمي تونن درست و حسابي جواب نيازها رو بدن اين مقدار توي سال 2000 براي يه PC قابل قبول بود ولي حتي كم كم ديگه براي گوشي همراه يا PDA و هرچيز ديگه كم هست.خود من يه زماني كارت گرافيكيم 2mb بود و باهاش fifa 98 رو باز ميكردم حالا 512 هم جواب نميده. يا ميزان RAM كامپيوترم 32 بود حالا سيستم عامل خودم كه هنوز ناقصه حداقل 4 مگ رم فقط براي راه اندازه اوليه ميخواد

[benyamin_pc]

آقای سپول جان چه مایکروسافت بخاطر پول چه هر گزینه دیگه ای اگه بستر بازی سازی بهتری آماده کنه شما مشکلی دارین؟؟ !!!
چندبار هم دوستان این جمله رو تکرار کردن که اگه خودت میدونی چرا پرسیدی.خوب تحقیق کردم و به این نتیجه رسیدم که xna مطمئنا جایگاه ویژه ای پیدا خواهد کرد
زمانی هم که مایکروسافت ویندوز فون سون رو معرفی کرد کمپانی های گوشی سازی از سیستم عاملش بخاطر نیازهای بالای سخت افزاری که لازم داشت استقبال نکردن اما کم کم قضیه برعکس شد و به سرعت بستر سخت افزاری گوشی هاشونو برای این سیستم عامل بالا بردن
اگه یک بیسی بالا بره به شرط منافع دراز مدت این تغییر با بررسی دقیق صورت می گیره و بحث منو شما نیست! اینکه c# کد میانی تولید میکنه و تحت فریم ورکی که اون در زمان اجرا میاد اون کد رو اجرا میکنه بحث جدیدی نیست که من اطلاعاتم کم باشه و محدود به .net هم نبوده و نیست. الان دیگه ی کاره تکنیکی شده و حتی adobe هم air رو به همون سمت داره میبره
ضمنا من قصد اینو ندارم که بگم xna جای umdx رو قراره کاملا بگیره ! من هم با mfc و هم با c# و هم با air و as انواع برنامه هارو نوشتم و به سرعته اونو و میزان مصرف cpu کاملا آشنام و قرار نیست این مطلب اثبات شه که قراره xna کاملا umdx را حذف کنه اما مطمئنا جایگاه خودشو که بسیار تو زمینه بازی سازی تاثیر گذار میشه تا چند سال دیگه پیدا می کنه و کمپانی های کوچک تر با هزینه بسیار کمتر بازی های لایت تری نسبت به بازی های بزرگ دنیا تولید می کنند و میتونه توی زمینه های دیگه ای هم غیر از بازی سازی شدیدا تاثیر گذار باشه
یه چیزم در نظر بگیرین که حد فاصله بین بازی هایی که همین الان توی کمپانی های کوچیک ساخته میشه (مثل کمپانی های بازی ایرانی) با بازی های حرفه ای دنیا اونقدر زیاده اونقدر زیاده که صدبرابر این نگرانی که سر performance ایکس ان ای میخاستن داشته باشن اگه با همین xna توسعه داده شده بود از بازی که تولید شده با همین performance فعلیشون بهتر میشد که بدتر نمیشد!!

[pswin.pooya]

تا چند سال دیگه پیدا می کنه و کمپانی های کوچک تر با هزینه بسیار کمتر بازی های لایت تری نسبت به بازی های بزرگ دنیا تولید می کنند
واقعا نمي دونم xna چه ربطي به هزينه بازي داره. آقا اگر يكي ميخواد هزينه بازيش رو كاهش بده كافيه از يه موتور آماده استفاده كنه كه 100 برابر از يه چيزي مثل C# و xna راحتره و هزينه رو كمتر ميكنه به غير از اون لازم نيست با سرعت افتضاح دات نت هم سر كله بزنه (كاش قضيه دات نت فقط به سرعتش ختم مي شد). من منكر اين نيستم كه دات نت هزينه توليد رو كاهش ميده اما توي كار حرفه اي اونم بازيسازي اين معني نداره كه طرف كارايي فداي هزينه كنه



یه چیزم در نظر بگیرین که حد فاصله بین بازی هایی که همین الان توی کمپانی های کوچیک ساخته میشه (مثل کمپانی های بازی ایرانی) با بازی های حرفه ای دنیا اونقدر زیاده اونقدر زیاده که صدبرابر این نگرانی که سر performance ایکس ان ای میخاستن داشته باشن اگه با همین xna توسعه داده شده بود از بازی که تولید شده با همین performance فعلیشون بهتر میشد که بدتر نمیشد!!
آقا هر موقع تو اين تيمها وارد شد مشكلات رو ميبيني از دور نظر دادن راحته


زمانی هم که مایکروسافت ویندوز فون سون رو معرفی کرد کمپانی های گوشی سازی از سیستم عاملش بخاطر نیازهای بالای سخت افزاری که لازم داشت استقبال نکردن اما کم کم قضیه برعکس شد و به سرعت بستر سخت افزاری گوشی هاشونو برای این سیستم عامل بالا بردن
ظاهرا فقط براي C# تعصب نشون نميدي كلا مايكروسافتي هستي. ميتوني توجيح كني كه چرا همه دارن ميرن سراغ سيستم عاملهاي لينوكس بيس:
htc-> android
LG-> android
SAMSUNG-> android
NOKIA-> mameo
apple -> IOS

من بعيد ميدونم MS بتونه توي بازار گوشي جايي براي خودش باز كنه. (كلا به اين بحث ربطي ندراه). قضيه اون نيازهاي سخت افزاري هم چرته نيازهاي سيستم عامل اندرويد و IOS با سون فون يكيه.

كلا از خواب مايكروسافتي (خرگوشي) بيدار شدن سخته. بهتره ما هم بيخود فك نزنيم

[benyamin_pc]

ظاهرا فقط براي C# تعصب نشون نميدي كلا مايكروسافتي هستي. ميتوني توجيح كني كه چرا همه دارن ميرن سراغ سيستم عاملهاي لينوكس بيس:
htc-> android
LG-> android
SAMSUNG-> android
NOKIA-> mameo
apple -> IOS




تعصب توی صحبت های شما دیده میشه من طرفداری از مایکروسافت نکردم دوسته عزیز جملات قبلمو دوباره بخونین متوجه میشین اما شما مشخصه بدجور از طرفدارای این صحبتهای قدیمی که یکی بگه مایکروسافت شما بگین ی چیز دیگه هستین که به سیستم عامل ios و android و maemo میگین لینوکس بیس!!!!!

یه سری هم به سایتهای گوشی بزنین تا حداقل تعصب الکی نشون ندین نوکیا چندین وقته که ی قرار داد بزرگ تجاری با مایکروسافت امضا کرده قراره سیمبیان بزاره کنار و ویندوز فون 7 بیاره بجاش اینم ی گوشیش http://gsm.ir/news_details.php?id=9528

فقط خاستم بگم بیس اگه توی سخت افزار یکم بالا بره شاید به کارایی ساده تر و بهتر برسه و صرف کنه و کاری با مایکروسافت و کمپانی دیگه نداشتم بی خیال واقعا بحث از مسیرش کاملا خارج شد

[betisa]

جناب pswin.pooya (http://barnamenevis.org/member.php?34511-pswin.pooya) قطعا در مورد سیستم های عامل دانش و تجربه زیادی دارن و من به دانش و تجربه ایشون احترام می گزارم اما عقیده من اینه که مطمعنا مایکروسافت که میشه بگیم بزرگترین شرکت نرم افزاری دنیاست هیچ وقت سرمایه و وقتش رو برای چیزی نمیزاره که محکوم به شکست هست. و این رو با XBox ثابت کرد.( با این ک در سه سال اول تولید Xbox مایکروسافت در حال ضرر دادن بود الان هیچ کس نمیتونه سود سرشاری که ازاین موضوع میبره رو انکار کنه). در مورد سیستم عامل موبایل و XNA هم مایکروسافت همین جور داره عمل میکنه. در ضمن این که ما به عنوان برنامه نویس باید ابزاری رو که باهاش کارمی کنیم باید به خوبی بشناسیم تا محدودیت هاش و همچنین مزیت هاش رو بشناسیم و بدونیم که چه چیزی رو کجا استفاده کنیم.

من روی هیچ ابزاری تعصب ندارم و سعی میکنم از بهترین ابزار(البته در توان خودم یعنی این که دانش خودم) بهترین بهره برداری رو بکنم.

و اما #C و ++C
هر کدوم از اون ها برای کار خواصی طراحی شدند. و دلیل نمیشه چون یکی راحت تره بهتره والبته این رو هم بگم که #C در جای خودش بهترینه اما جای اون برای بازی سازی (حجیم و بزرگ) و نوشتن سیستم عامل نیست. همون طور که نوشتن یک برنامه کاربردی تجاری حجیم کار ++C نیست. چون به صرفه نیست.(حالا برنامه کاربردی کمی کند تر اجرا بشه و ..) زیاد مهم نیست مهم اینه که شرکت بتونه محصول رو به سرعت وارد بازار بکنه. البته منظور من از برنامه های کاربردی حجیم برنامه های مثل 3dmax , photoshop و برانامه های این چنینی نیست چون اون ها اگر بیش از بازی نباشن کمتر هم نیستن.

[pswin.pooya]

Betisa:
با تشكر از شما. فكر كنم منظور شما از برنامه هاي تجاري پايگاه داده يا برنامه هاي سودمند كوچيك باشه. من حرف شما رو قبول دارم C# بر اينكار ايده آل هست اما منتهاي كار اينه كه توي اين زمينه هم C++ با استاندارد C++ CIL پيشرفت كرده. اين استاندارد كه ماله مايكروسافت هست اجازه ميده كه از تمام امكانات دات نت دقيقا مشابه C# استفاده كرد (من دوستام بهش ميگيم برنامه نويسي Darg&Drop )‌. كلا اگر با برنامه هاي بزرگ تجاري حتي ديتا بانك ها هم كار كرده باشيد متوجه ميشيد كه تاخير زيادي داخل اونها وجود داره كه بيشتر اين قضيه بر ميگرده به ديتا بانك و نه زبان برنامه نويسي و حتي GUI به همين دليل هم هست كه اونجا سرعت اين برنامه ها طرح نميشه بلكه امكانات جانبي توي اونها در نظر گرفته ميشه. خب براي اين موضوع هم فعلا دات نت شاخ اين قضيه هست. اما اگر روزي رو تصور كنيد كه سرعت ديتا بانك مطرح نباشه (كه تقريبا محال هست) اون وقت نظرها در مورد سرعت GUI هم تغيير ميكنه و حتي براي كاربرها سرعت و تيك هاي لحظه اي كه رو شاخ برنامه هاي دات نت هست مطرح ميشه.

در مورد سرمايه گذاري ها هم بايد بگم همه ما سرمايه گذاريهاي اشتباه زيادي از رو از MS ديديم و همينطور برنامه ها و زبانهاي پركاربردي رو هم كه از رده خارج شدن. مساله اي كه هست اينه كه MS با وجود اين سرمايه گذارها هنوز خط مش قديمي خودش يعني پشتيباني هرچه بهتر از C++، MFC و حتي DX رو ادامه ميده بنظر من اين قضيه دو تا دليل داره:
1. وجود جايگزين براي زيانهايي مثل C#
2. حفط مشترهايي كه از زبانهاي غير مايكروسافتي استفاده ميكنن.

اگر بخوام دليل اول رو توضيح بدم: بايد بگم كه در درجه اول خود MS هم از آينده بي خبر هست و تجربه هاي شكستهاي تلخي رو داشته پس در نتيجه سعي ميكنه كه هميشه براي خودش يك راه در رو هم بذاره. مثلا اگر MS ساپورت C++ و يا MFC رو قطع كنه فورا همه متوجه C# ميشن و از اون استفاده ميكنن اما اگر توي اين بين يه شركت مثل اينتل ساز مخالف بزنه و مثل الان كامپايلر خودش رو بسازه اون وقت برنامه نويسهاي C++ كه از VS استفاده مي كردن سوئيچ ميكنن به اينتل و در آينده اين اينتل هست كه تصميم ميگيره كه خط مش نرم افزارهاي ويندوز چه شكلي باشه نه MS چون خود MS هم ميدونه كه تقريبا 90 درصد برنامه هاي حرفه اي دنيا مثل فتوشاپ، مكس، مايا و آفيس و .... با C++ توليد ميشن پس بهتره كه يه ساپورت خيلي مناسب رو از اين زبان داشته باشه تا بتونه تو مشخص كردن مسير آينده دخالت بيشتري كنه.