در چه مواردی قدرت و انعطاف پذیری Visual C++6 از VB6 بیشتر است؟
و در کل موارد ضعف VB6 چه چیزهایی هستند؟
Printable View
در چه مواردی قدرت و انعطاف پذیری Visual C++6 از VB6 بیشتر است؟
و در کل موارد ضعف VB6 چه چیزهایی هستند؟
این که کامپایلر 10 سال قبل VC++6 را با VB6 مقایسه می کنید، نشاندهنده این است که تاپیک زیر که به صورت اعلان هم هست شامل حال شما می شود:
تفکرات اشتباه در مورد VC++6
پس ابتدا حتما آن را به طور کامل مطالعه کنید.
پس حالا سوال شما باید به این شکل باشد:
"در چه مواردی قدرت و انعطاف پذیری ++C توسط Visual C++2005/2008 از VB6 بیشتر است؟ (بدون دات نت)"
- دسترسی مستقیم به API های سیستم عامل و در نتیجه نهایت کارآیی (در صورت نیاز به این کارآیی بالا مثلا در نرم افزارهای گرافیکی)
- توابع VB6 به خاطر اینکه معمولا یک wrapper برای توابع native سیستم عامل بودند، در اکثر موارد سرعتی کمتر از ++C داشته است (منظور نرم افزارهای بسیار ساده نیستند)
- امکان ترکیب کدهای Native (بدون دات نت) نوشته شده توسط ++C با قابلیت های .Net توسط C++/CLI در صورت نیاز
- VB6 کم کم از دور خارج خواهد شد و جای خود را به نسخه VB.Net خواهد داد. (در حال حاضر دیگر بر روی نسخه های جدید windows mobile پشتیبانی نمی شود)
- همه موارد فوق به کنار، سختی کار با آن چندین برابر VB می باشد.
پاورقی: دقت کنید که Visual basic.Net بحث متفاوتی دارد و مقایسه آن با ++VC بحث دیگری هست که موارد فوق در مورد آن صادق نیست و با توجه به طرفداران زیاد آن تقریبا به راحتی به جواب نخواهید رسید!
دلیل اینکه VC++2008 را ذکر نکردم این بود که شنیده بودم سرعت اجرای کدها مخصوصا" توی بازی سازی در VC++6 از همه بالاتر است
یکی دیگر اینکه مگه کامپایلر VC++2008 را از اول نوشته اند؟اما microsoft گفته که فقط C# از ابتدا نوشته شده و اونهای دیگه دست کاری شده Compiler های قبلی هستند
اما اینکه گفتین می توان در بعضی موارد از امکانات دات نت داخلش استفاده کرد یعنی بعد هم برای اجرا به Frame work نیازی ندارد؟و سرعت اجرای دستورات توسط Clr پایین نمی آید؟همانند کدهای خود دات نت که از کد های Native سرعت پایین تری دارند به خاطر نحوه اجرای آنها توسط Clr
در حال حاضر VC++6 دیگر از طرف مایکروسافت پشتیبانی نمی شود و SDK های جدید نیز بر روی آن قابل نصب نیستند. و بسیاری از کتابخانه های مختلف موجود نیز آن را پشتیبانی نمی کنند.
توجه داشته باشید که VC++6 به طور پیش فرض قابلیت های 10 سال اخیر که به ویندوز 2000 ، XP و Vista اضافه شده است را ندارد و همین طور بهینه سازی های انجام شده در کتابخانه های ++C/C را که سرعت را افزایش داده است.
درست هست که مسائلی هنوز ایراداتی دارد مانند intellisense ، اما زیاد به این مسائل جزئی که مثلا گفته می شود سرعت اجرای کدها کمتر است اصلا فکر نکنید این تفاوت ها آنقدر اندک هست که به نسبت قابلیت های جدید اصلا به حساب نمی آید، کسانی که چنین پیشنهادی انجام می دهند یا برنامه نویس به روزی نیستند یا اصلا ++C زبان اول برنامه نویسی آن ها نیست و تسلطی بر آن ندارند. (متاسفانه در کشور ما هم این موضوع گوش به گوش انتقال داده می شود )
یک موتور خوب بازی نیازمند استفاده از جدیدترین SDK هست تا مشکلات و ناسازگاری ها برطرف شود، حتی کتابخانه های گرافیکی نیز نیازمند کامپایلرهای جدید و SDK جدید سیستم عامل هستند.نقل قول:
مخصوصا توی بازی سازی
در حال حاضر در حوزه بازی های کامپیوتری (و همین طور نرم افزارها) تنها کسانی از VC++6 استفاده می کنند که سال ها قبل بازی خود را نوشته اند (مثلا با DX8 یا DX7 ) و هنوز جهت پشتیبانی می خواهند آن را update کرده و bug آن را بر طرف کنند.
اگر پروژه را بر مبنای CLR تغییر دهید و کامپایل کنید؛ آنگاه برنامه شما هم دات نتی می شود و نیاز به .Net Framework خواهد داشت. (در هر صورت این امکان اختیاریست)نقل قول:
یعنی بعد هم برای اجرا به Frame work نیازی ندارد؟و سرعت اجرای دستورات توسط Clr پایین نمی آید
الان چه زبانی سرعتش مخصوصا" تو بازی سازی بالاتره؟
در بحث بازی و ساخت نرم افزارها با performance بالا بدون شک ++C (به صورت native در هر سیستم عامل).
C++2008?
.
ما چیزی به نام برنامه نویسی ++Visual C یا C++2008 نداریم.
++visual C فقط یک کامپایلر هست که با آن می توانیم به شیوه ها و با کتابخانه های مختلف برنامه نویسی کنیم.
برای بازی ها باید از شتابدهنده های گرافیکی مثل DirectX یا OpenGL استفاده کرد و برای ارتباط با سیستم عامل و ساخت پنجره و غیره در ویندوز بهترین شیوه و بالاترین Performance برای برنامه نویسی مستقیم Win32 API هست که با هر نسخه ای از ++Visual C که می خواهید می تواند انجام شود و حتی می توانید به جای ++VC از ++minGW/DevC نیز استفاده کنید. در سایر سیستم عامل های نیز به همین شکل بهترین راه استفاده از API های سطح پایین سیستم هست.
این شیوه تمامی توسعه دهندگان بازی در دنیا بوده و هست.
پس به این فکر نکنید که کدام نسخه کامپایلر VC را استفاده کنید، بلکه به این فکر کنید که در ویندوز می خواهید به سراغ MFC بروید یا win32 و یا به دنبال کتابخانه های cross-platform
با تمام این احوال تو چند تا کتاب و همچنین بعضی سایتهای اینترنتی خوندم که می گفت سرعت اجرای کد برای بازی سازی توسط یک کامپایلر زیاد مهم نیست و حتی می گفت از لحاظ تکنیک های برنامه سازی و سادگی کار و احتمال کمتری برای بروز خطا C#.net که به نظر ما بدترین گزینه است بهترین گزینه می باشد
و تاکید فراوانی بر روی مهاجرت از C++ به کدهای CLr کرده بود
اما نمونه های کار شده خود Microsoft را در DirectXsdk دیدم که با C# و C++ بازی های سه بعدی ساخته بود اما سرعت اجرای بازی های مشابه C++ با C# قابل مقایسه نبود و می شد گفت C# اصلا" به درد نمی خورد؟این چجوریه پس؟
"عطر آن است که خود ببوید نه آنکه عطار بگوید"
Managed DirectX (با CLR) به خاطر سرعت پایین آن فورا از دور خارج شد و کنسل شد و مایکروسافت شروع به ارائه XNA کرد که از لحاظ سرعتی بهتر از Managed DirectX هست .
اما با این وجود حتی 0.01% توسعه دهندگان حرفه ای دنیا نیز به سمت آن نرفته اند و در حوزه حرفه ای تا کنون کاربران کمی داشته است.
.Net هر چقدر که توانسته هزاران هزار نفر را در توسعه نرم افزار به سمت خود بکشد، اما نتوانسته در حوزه بازی سازی حرفه ای جای چندانی باز کند، شاید در آینده ...
افرادی که برای تفریح می خواهند برنامه نویسی بازی کنند، XNA یک گزینه خوب برای آن ها هست تا در کارها سرعت ببخشد.
پس حالا که سرعت اجرای کدها در پروژه های Mfc VC++2008 از همه بالاتر است و قابل مقایسه با سایرین نیست چرا Microsoft گفته در ادامه مسیر تنها زبانی که 100% ساپورت می شود C# است و Vb هم شاید ساپورت شود؟
----------------------------------
داخل mfc2008 چرا وقتی می خواهیم برای یک دکمه event تعیین کنیم که در آن حالت کد بنویسیم انقدر eventها ی آن کم است؟
دوستان و عزیزان من فقط در جهت تایید اطلاعاتی که Nima_NF دادند میخواستم مجددا" تاکید کنم که تفاوت زیادی از نظر پرفورمنس بین نسخه های بالاتر C++ (البته MFC) وجود نداره و برای بازی سازی هم گزینه های خوبی هستند.
برای مثال موتور قدرتمند CryEngine 1 در سال 2004 که بازی FarCry هم بر اساس آن توسط شرکت آلمانی CryTek با زبان C++ 2003 MFC نوشته شده بود. و البته نسخه دوم همین موتور که سال پیش عرضه و بهترین موتور از نظر تکنیکال شناخته شد و بازی Crysis هم بر اساس آن ساخته شده بود با استفاده از C++ 2005 MFC نوشته شده بود. زیبایی و قدرت بازی که مد نظرتون هست؟! اگر نیست یک سری به گوگل بزنید و سرچ کنید.
در مورد XNA هم خود ماکروسافت آنقدر بزرگش نکرده که ما بخواهیم از حرفه ای نبودنش ایراد بگیریم. با عرضه XNA Framework خود ماکروسافت اعلام کرد که این هسته را فقط در جهت بازی های ساده و سبک Xbox Live (دقت کنید که حتی به Xbox 360 هم اشاره نکرده و بازی های ساخته شده را فقط در حد Xbox 360 Live گزارش کرده) و ویندوز توسط دانشجویان و علاقه مندان عرضه کرده است. هدف ساخت یک محصول قدرت یک محصول رو نشون میده و نمیشه به علت اینکه هدف ساخته شدن یک محصول چیز دیگری بوده اون را مجازات کرد.
موفق باشید.
اولا واقعا از مقاله آقای نیما تحت عنوان "مقاله: برنامه نویسی ++C/C از نوع Native یا managed ؟ "
تشکر می کنم
لینک دانلود تولکیت های Cross-platform را میشه بذارین؟
این طریقه کد نویسی native داخل mfc project و ارتباط آن از طریق cli با کدهای دات نت به چه شکل
است؟و آیا سرعت اجرای کل برنامه به این روش پایین نمی آید؟یا فقط قسمتی که از کد دات نت استفاده
کرده سرعتش پایین می آید و کدهایی که native بوده اند با همان سرعت قبلی اجرا می شوند؟
اون فیلم 250MB رو با این 900byte در ثانیه دانلود کنیم؟
میشه بگین تو فیلم در مورد آینده C++ چی گفته؟یه خلاصه کلی در موردش
و آیا در آینده قرار نیست با C# و طریقه خاص خودش بشه یه Native project تو لید کرد؟
در مورد آینده ++C در سوال 8 و 9 آن مقاله، سیاست مایکروسافت توضیح داده شد.نقل قول:
آیا در آینده قرار نیست با C# و طریقه خاص خودش بشه یه Native project تو لید کرد؟
#C از آنجا که مبتنی بر .Net هست پس به صورت Native نمی تواند باشد (Native = اجرای مستقیم کدها توسط CPU و در نتیجه نهایت کارآیی و سرعت) و البته نمی تواند جای Native هم قرار گیرد چرا که در بحث هایی که به تاخیر زمانی پایین نیاز دارد مشکل ایجاد خواهد کرد.
در گوگل اولین گزینه سایت آن هاست:نقل قول:
لینک دانلود تولکیت های Cross-platform را میشه بذارین؟
http://www.wxwidgets.org/downloads/
http://www.gtk.org/download.html
http://trolltech.com/downloads
در این مورد هنوز نتوانستم به نتیجه قطعی برسم، چیزی که تا کنون دیدم در کل برنامه تاثیر گذار بود.نقل قول:
این طریقه کد نویسی native داخل mfc project و ارتباط آن از طریق cli با کدهای دات نت به چه شکل است؟و آیا سرعت اجرای کل برنامه به این روش پایین نمی آید؟
اما برنامه های بزرگی مثل 3ds max با پشتیبانی .NET عرضه شده اند که فقط بخشی از آن مبتنی بر CLR هست و در بخش های دیگر هیچ تاثیری ندارد.
در C# هم می شود کد Unmanage نوشت و بخشی از کد را native تولید کرد این تکنیک بهتر از نوشتن کد توسط mfc و ارتباط آن با .net نیست؟نقل قول:
#C از آنجا که مبتنی بر .Net هست پس به صورت Native نمی تواند باشد
یک توصیه به شما می کنم، اگر می خواهید وارد دنیای .Net شوید به سراغ همان #C بروید. (که از مزایا و معایب آن آگاه هستید)
اگر به خاطر سرعت با ++C می خواهید Native برنامه بنویسید کلا زیاد به دات نت فکر نکنید.... C++/CLI هم بسیار مشکل تر هست، هم ابزار و اسناد کمتری برایش ساخته می شود.
C++/CLI برای این توسعه داده می شود که دست برنامه نویسان را باز بگذارد تا اگر واقعا نیازمند قابلیت های دات نت هستند از آن بی بهره نمانند و بتوانند برنامه های Win32 و MFC کنونی خود را با قابلیت های دات نت ترکیب کنند.
من مشکلم با .net اصلا" Framework و چیزهایی تو این مایه ها نیست فقط سرعت همین
برای همین می خواستم بدونم بجای ایجاد MFC اگه از unmanage داخل C# استفاده کنیم سرعتش با MFC یکی میشه؟
دلیل این ادعا به نظر من مربوط به مسائل بازار می شود.
معمولا هم توجیه به این صورت است که:
در قسمت گرافیک بازی، که کل کار به عهده سخت افزار و HAL و کتابخانه های مربوطه مثلا در ویندوز DirectX و OpenGL و همچنین موتور گرافیک است. بنابراین زبان برنامه نویسی تاثیری بر این قسمت ندارد.
در قسمت Physic هم تقریبا کارها دارند به سخت افزارهای سفارشی واگذار می شوند و یا کتابخانه های قوی و سریع آماده ای وجود دارند. بنابراین زبان برنامه نویسی تاثیری بر این قسمت ندارد.
در قسمت هوش مصنوعی هم می توان این طور حساب کرد که کتابخانه های آماده با Performance بالا وجود دارند که زبان برنامه نویسی فقط باید قادر باشد که از آن استفاده کند.
در واقع اگر توجه کرده باشید زبان برنامه نوسی در این پروسه فقط نقش چیدن قطعه ها را در کنار هم بازی می کند و دیگر هیچ.
اما تمام مسائل بالا فقط در صورتی درست است است که تمام کار برنامه نویسی برای بازی عبارت باشد از چیدن قطعات کنار یکدیگر که این در واقعیت و به تجربه صحت ندارد.
اگر نگاهی به دنیای واقعی بازیها و شرکتهای بازی سازی واقعی و کشمکش و جدالشان با بازار و سخت افزار و رقابت با یکدیگر بیندازید و ترفندهایی که هر روز اختراع می کنند تا بازیهایشان دارای نیازمندی های سخت افزاری کمتری باشند و با سرعت بیشتری اجرا شوند متوجه می شوید که حتی با وجود رشد سریع سخت افزارها، هنوز راه بسیار طولانی مانده تا دنیای بازیها به واقعیت نزدیک شود. پس معقول نیست که شرکتها زبانی مثل ++C را که یک زبان بسیار قدرتمند با انعطافپذیری و سرعت بالا و دارای قدرت دسترسی مستقیم و سریع به منابع سیستمی و سطحوح بالاتر و بخصوص دارای قدرت دسترسی مستقیم به حافظه است و همچنین یک زبان علمی و کاربردی استاندارد و محبوب در دنیاست و منابع بسیار برای آن وجود دارد و هر روزه بوجود می آید و ... را ول کرده به یک زبان که بعد از به اصطلاح کامپایل، تازه تبدیل به یک IL می شود و این IL باید در اولین شروع اجرا توسط JIT به کد ماشین تبدیل شود و در این پروسه تقریبا همه کار Optimization بر عهده ماشین است و برنامه نویس اختیاری ندارد روی آورند. دست کم کسانی مثل من که در زمینه هوش مصنوعی برای بازیها مطالعه کرده باشند آگاهند که چه سختیهایی در سر راه سرعت اجرای الگوریتمها وجود دارد و سرسختانه میکوشند که سرعت اجرا را هرچقدر کم هم شده افزایش دهند نه کاهش.
اگر اینطور نبود چندین سال پیش JAVA زبان استاندارد بازی نویسی دنیا میشد.
تمام اینها نظر و تجربه من است.
دوست عزیز داخل #C هیچ Unmanaged ای وجود نداره، بلکه توسط #C فقط می توانید با استفاده از کتابخانه ها، فضای نام و روشهای مبتنی بر Interop ، از کتابخانه های Native نوشته شده توسط زبانهای دیگر مثل ++C و یا C و ... استفاده کنید.نقل قول:
نوشته شده توسط benyamin_pc
در ضمن برنامه هایی وجود دارند که باینری MSIL تولید شده را به یک باینری ماشین تبدیل می کنند. به این صورت که باینری MSIL و تمامی نیازمندیهای آن در Net Framework. را گرفته و به کد ماشین تبدیل می کنند. که این کار در کل بیهوده است. زیرا اولا فقط حجم فایلهای روی سیستم با تکرار کدها را افزایش می دهد و در ضمن سرعت اجرای برنامه نیز به دلایلی که اگر خواستید می نویسم تغییری نمی کند.
اگه در زمینه بازی سازی انقدر فاصله بین قدرت mfc در vC++ و دیگر زبانها می باشد لطفا" یک لینک به یک ebook از آموزش mfc در VC++2008 برام بفرستید
ببینید ربطی به MFC نداره. MFC فقط یه کتابخانه رابط کاربر و شبکه و پایگاه داده و ... است که با زبان ++C نوشته شده و از کامپایلر ++VC استفاده می کنه، همین.
در ضمینه بازی نویسی اصلا احتیاجی به MFC نیست.
مسئله اصلی خود زبان ++C است که امکان استفاده و دسترسی مستقیم از منابع سیستمی و حافظه رو میده و منابع آماده زیادی در دنیا براش وجود داره. در ضمن در ++C روشهای Optimization قوی که به صورت استاتیک و در سطح کد و کتابخانه و کامپایل و همچنین Dynamic و Runtime وجود داره که باور کنید این روشها تا حد بسیار بسیار زیادی روی زبانهای مبتنی بر VM مثل #C و JAVA قابل اعمال نیست.
اصلا ++C و کتابخانه های استانداردش با رویکرد کامل به Performance و چیزهای دیگر طراحی شده اند. اما زبانهای مبتنی بر Net. از ابتدا با رویکرد به Productivity و راحتی برنامه نویس و توسعه سریع و foolproof بودن طراحی شده اند.
البته باید بگم برنامه نویسهای با تجربه ++C در این زمینه ها هم هیچگونه مشکلی ندارد.
جمله آخر شما یعنی اگر تجربه لازم را کسب کنیم فرقی نداره با سی شارپ بازی 3بعدی بسازیم یا با VC++ البته یه چیزی شبیه این حرف تو یه کتاب ساخت بازی 3بعدی هم بود که البته اون می گفت نیازی به تجربه هم نیست چون همه کارها رو خود سی شارپ می کنه و با C++ خیلی سخت تر میشه این کارها رو کرد که باید تجربه زیادی داشت تا اشتباه نشه
اما در کل اگه سرعت زیاد سی پلاس پلاس واقعا" تو ساخت بازی خیلی می تونه تاثیر گذار باشه شفاف بیان کنید
اینکه گفتم mfc منظورم این نبود که mfc یه زبان جداس و می دونم که از کامپایلر سی پلاس پلاس استفاده می کنه اما بلاخره یادگیری آن با خود سی پلاس پلاس و یا proje های win32 سی پلاس پلاس فرق داره
و می خواستم تو اون زمینه ebooki راهنمایی چیزی بشم
آخه C++ رو بلدم همون آبی که مال جعفر نژاد هست همین طور سی جعفر نژاد همون سبز اما با اینا نمیشه تو mfc کد نوشت و باید چیزهای خودش رو یاد بگیرم
اما برای بازی سازی مگه برای ارتباط با Direct x نباید از VC++ استفاده کرد؟اونم پروژه mfc?لطفا" یکم تو این زمینه شفاف سازی کنید ممنون
دوست عزیز جمله آخر من در مورد Productivity و راحتی برنامه نویس و توسعه سریع و foolproof بودن که از خواص زبانها و کتابخانه های مبتنی بر Net. است بود نه درباره Performance و Code Level Optimization که از خصوصیات ++C هستند.
در ضمن برتری زبانها و کتابخانه های مبتنی بر Net. بیشتر در برنامه نویسی UI و توسعه سریع و بیشتر برنامه های مبتنی بر Database و فرمها نمود پیدا می کنند و در زمینه بازی نویسی نه تنها کارها رو راحت تر نمی کنند(توضیح میدم) بلکه سخت تر هم می کنند.
توضیح: مثلا از دید کسی که هیچ چیز در مورد DirectX نمیدونه و یا نمیتونه نمی تونه از COM Object ها استفاده کنه آره شروع کار کردن با Managed DirectX راحت تره تا اینکه بخواد Instance از COM Interface ها بسازه و Initialize کنه و مواظب Reference Counting باشه و ... ولی توجه کنید این فقط در سطح خیلی مقدماتی و شروع کار با دایرکت ایکسه نه کارهای پیشرفته و بازی نویسی واقعی.
در ضمن من نمی دونم کجای برنامه نویسی با ++C اشتباه میشه؟ من الان 15 ساله دارم از C و ++C استفاده میکنم و فقط اوایل مشکلاتی کمی در زمینه مدیریت درست حافظه داشتم ولی بعد از اون هیچ مشکلی برام پیش نیومده. همه جور برنامه هم از قبیل برنامه های مبتنی بر DataBase و فرم و سیستمی و هوش مصنوعی و بازی و تجاری و آزمایشی و ... هم با C و ++C نوشتم و هیچ مشکلی نداشتم. اگر مشکل مدیریت حافظه و Garbage Collection هستش که برای مدیریت حافظه Smart Pointer های موجود در کتابخانه استاندارد و Boost مشکل رو حل میکنند. در مورد Garbage Collection هم کتابخانه های دیگری وجود دارند که این کار رو انجام می دن. در مورد مدیریت COM Object ها هم VC دارای کلاس ها کمکی مثل CComPtr هستش که مشکل مدیریت COM رو کاملا برطرف میکنه. در ضمن در استاندارد جدید ++C به نام C++0x که قراره C++09 باشه و در سال 2009 منتشر میشه نه تنها امکانات پایه ای Garbage Collection به زبان اضافه شده بلکه امکانات بسیار زیاد دیگری به کتابخانه استاندارد و خود زبان اضافه شده که بیشتر چیزایی که الان مشکل شمرده میشن رو حل می کنه و در ضمن بهبودهایی هم در زمینه Performance مثل RValue Reference ها انجام شده که سرعت اجرا رو باز هم بالاتر از این که هست میبره. پس مشکل کجاست؟
ببینید من با زبان #C و کلا Net. مشکلی ندارم. همین الان دو تا پروژه تجاری دیتابیسی در حال انجام دارم که هر دو تا تحت Net. و با #C و ADO.Net هستند و کلی هم باهاش حال میکنم چون کار رو واقعا راحت و سریع میکنه و در ضمن پشتیبانی و نگهداری از برنامه خیلی راحت تر هم هست.
ولی در زمینه کارهایی که احتیاج به سرعت بالا دارند باور کنید ++C با #C قابل مقایسه نیست. این رو به تجربه میگم. برای نمونه یک پروژه آزمایشی که یه بازی Checkers بود رو انجام داده بودم که کل UI پروژه تحت Net. و Windows Forms بود. در ابتدا به اصطلاح هوش مصنوعی بازی رو که فقط یک الگوریتم Recursive Alpha Beta بود رو هم با #C نوشته بودم. دیدم خیلی کنده و شروع به پیاده سازی الگوریتم توی یک DLL و به کمک ++C کردم. و سپس با کمک Interop از این دو رو به هم ارتباط دادم. باورتون نمیشه حدود 2 برابر افزایش سرعت داشتم. توضیح اینکه من با روشهای جلوگیری از افت سرعت در #C مثل Boxing هم آشنایی دارم و اونها رو مد نظر قرار داده بودم.
در مورد MFC هم تاجایی که من میدونم متاسفانه منابع جدیدی وجود ندارن و شما باید کتابهای قدیمی مثلا برای VC6 رو مطالعه کنید تا با ساختار MFC آشنا بشید و سپس امکانات و تغییرات جدید را مثلا در MSDN جستجو کنید.
کتابی که من سالها پیش برای MFC خوندم اسمش بود Programming Windows With MFC second Edition نوشته Jeff Prosise سال 1999 که اگر بخواید لینک دانلودش رو پیدا می کنم براتون میزارم. اما یادتون باشه که تا حالا تغییرات زیادی بخصوص در Visual Studio 2008 SP1 در MFC صورت گرفته.
در ضمن برای برنامه نویسی بازی شما به هیچ عنوان به MFC احتیاجی ندارید. تنها کاری که MFC در برنامه نویسی بازی برای شما می کند ایجاد پنجره اولیه است که اگر از مستقیما از Win32 برای این کار استفاده کنید کار شما راحت تر هم می شود.
در کل من توصیه می کم برای برنامه نویسی UI معمولی سراغ MFC نروید و از Net. و Windows Forms و یا WPF استفاده کنید. چون کار رو خیلی راحت تر و سریعتر می کنه و در ضمن پشتیبانی و نگهداری برنامه خیلی راحت تر میشه.
با سلام
خیلی عجیبه.یعنی ماکروسافت باز هم دروغ گفت.این شرکت ادا کرده که می توانید بازی های بسیار قدرتمندی با xna در زیر زمین خونتون طراحی و تولید کنید(Xna هم بر روی سی شارپ نسخه اکسپرس نصب می شود)؟؟!!!
بنده و جمعی از دوستان معتقدیم چنانچه برنامه نویس حواسش باشد و بتواند از بهترین الگوریتمها و صحیح ترین روشها استفاده کند می تواند با مجموعه دات نت (پیرو فرمایشات ماکروسافت) بازیهای در حد بسیار خوبی چه از لحاظ سرعت و چه از لحاظ بازده طراحی کند.
چندین پروژه متن باز بازی را در اختیار دارم که با xna طراحی شده است که واقعا از لحاظ سرعت در حد بسیار خوبی قرار دارد.
این برنامه نویس است که پروژه را خلق می کند و زبان برنامه نویسی تنها وسیله است
hectore عزیز در به در دنبال چندتا پروژه xna می گردم میشه این open source ها رو بذاری برا دانلود؟از نظر سایت هم این warez نیست چون open source هست.
lovere از boxing هم استفاده کرده بودین و سرعت باز هم بسیار پایین بود؟boxing تو سرعت خیلی تاثیر داره؟dll رو داخل C# استفاده کردین؟وقتی dll سی پلاس پلاس رو تو C# استفاده کردین سرعتش با اینکه کل کد رو داخل C++ می نوشتین یکی شد؟
پس بهترین گزینه win32 هست؟lovere عزیز اگه ebook 2008 از win32 تحت studio2008 دارین لینکش رو بفرستین ممنون می شم
اما وقتی می خواهیم از direct x sdk استفاده کنیم محیط کاملا" خشک سرعت develope بازی رو پایین نمیاره؟یعنی برنامه نویسی با direct x هم کاملا چشم بسته است؟منظورم اینه که نمیشه objecti چیزی ایجاد کرد و براش کد نوشت؟کد رو می نویسیم و صحنه سازی تو ذهنمون می کنیم آخرش اجراش می کنیم؟