dark-hammer engine

[سپول]

اولین نسخه موتور سورس باز dark-hammer آماده شد.
این نسخه 0.1.0 هست که هنوز خیلی کار داره در واقع پایه موتور. سیستم رندر و کتابخانه core هست. با زبان C نوشته شده و فعلا در سیستم عامل های linux و windows اجرا می شه. از API های OpenGL3.0+ و DirectX11 برای رندر استفاده می کنه. ادامه کد ها رو هم بیشتر از پروژه hmrengine استفاده خواهم کرد.
لایسنس هم BSD هست که عملا می تونین هر کاری با سورس می خواهین انجام بدین ولی فقط ذکر نام کنید. (که همون هم از ۹۰٪ برنامه نویسان ایرانی انتظار نمی ره)

خود موتور فروم داره ولی اگر سوالی به زبان فارسی داشتین در همین تاپیک مطرح کنید. چون اون فروم به زبان انگلیسی هست. این تاپیک رو هر از گاهی سر می زنم.
امیدوارم این پروژه بعد از سالها صحیح و خطا بگیره و برنامه نویس های مختلف رو جذب کنه.
این هم لینک های به درد بخور :



Forums – http://www.hmrengine.com/forums
Wiki – https://bitbucket.org/sepul/dark-hammer/wiki/Home
Source – https://bitbucket.org/sepul/dark-hammer/src
Binary samples – https://bitbucket.org/sepul/dark-hammer/downloads
Project home – https://bitbucket.org/sepul/dark-hammer
Developer blog – http://www.hmrengine.com/blog

[pswin.pooya]

سلام سپهر

سورس موتور رو فعلا نديدم اما با توجه به شناختي كه نسبت به شما دارم، ميدونم يه كار تميز و حرفه اي رو ارائه دادي. من شخصا شايد اختلاف نظر زيادي با شما داشته باشم اما كارهاي شما رو كاملا قبول دارم و ميدونم كه از نظر فني يكي بهترين كارها رو داخل كشور انجام ميدين. اميدوارم مثل هميشه موفق باشيد. البته با توجه به تلاش و پشت كار زياد شما اين امر كاملا بديهي هست.

[Sepehr M]

ایول دمت گرررم...
بالاخره چیزی که منتظرش بودم رو دادی بیرون...دستت درد نکنه...
فقط یه سوال کوچولو...چرا C؟
چرا با ++C کار نکردی؟البته اینو قبلا گفته بودی که C رو بیشتر ++C قبول داری...ولی دلیل تاکیدت روی زبون C رو میشه بگی؟؟؟آخه من تو همین راه از خیلی ها سوال کردم که اکثرا ++C رو توصیه میکردن...
بازم ممنون بابت این پروژه ات...مرسی... :قلب:

[سپول]

سلام سپهر

سورس موتور رو فعلا نديدم اما با توجه به شناختي كه نسبت به شما دارم، ميدونم يه كار تميز و حرفه اي رو ارائه دادي. من شخصا شايد اختلاف نظر زيادي با شما داشته باشم اما كارهاي شما رو كاملا قبول دارم و ميدونم كه از نظر فني يكي بهترين كارها رو داخل كشور انجام ميدين. اميدوارم مثل هميشه موفق باشيد. البته با توجه به تلاش و پشت كار زياد شما اين امر كاملا بديهي هست.

ممنون. حال دادی ولی نمیشه بهش موفقیت گفت چون هنوز خروجی خاصی از موتورهایی که ساختم درست نشده. دلیلش هم بر می گرده به خودم که هیچ وقت از طراحی ها راضی نبودم و ایده آل من نبوده. شاید اگه شخص دیگه ای بود و این ایده آل گرایی مسخره رو کنار می گذاشت با همون نسخه موتور ۵ سال پیش یک بازی درست می کرد. که شاید کار بهتری هم بود. در هر صورت آخر سر بر می گرده به انتخابی که کردم. در هر صورت فکر می کنم سورس باز کردن این کار آخر این خوبی رو داره که پایه اش در حدی خوب هست که اگه من هم به خاطر عوضی بودنم ادامه ندادم، برنامه نویس های دیگه اون رو ادامه بدن.

[pswin.pooya]

دلیلش هم بر می گرده به خودم که هیچ وقت از طراحی ها راضی نبودم و ایده آل من نبوده.
این خاصیت برنامه نویس های قوی و حرفه ای هست که هیچ وقت نمی تونن ارضا بشن. حتی کاری رو که خودشون انجام دادن نمی تونه راضی شون کنه. شاید دلیلش اینه که براشون فقط خروجی و جواب گرفتن مهم نیست، نحوه انجام کار هم براشون اهمیت داره.

[سپول]

ایول دمت گرررم...
بالاخره چیزی که منتظرش بودم رو دادی بیرون...دستت درد نکنه...
فقط یه سوال کوچولو...چرا C؟
چرا با ++C کار نکردی؟البته اینو قبلا گفته بودی که C رو بیشتر ++C قبول داری...ولی دلیل تاکیدت روی زبون C رو میشه بگی؟؟؟آخه من تو همین راه از خیلی ها سوال کردم که اکثرا ++C رو توصیه میکردن...
بازم ممنون بابت این پروژه ات...مرسی... :قلب:

انتخاب زبان C دلایل زیادی داره،‌ و بحث های زیادی هم تو این قضیه مطرح هست،‌ می تونی یک سرچ بزنی و خودت ببینی. ولی سیستم کار من اینجوری بود که به تدریج و در طی نوشتن چند موتور نصفه نیمه به این نتیجه رسیدم.

اولا کلی از این مساله در آخر بر می گرده به قضیه سلیقه برنامه نویس. نکته اصلی اینه که یک برنامه نویس خوب می تونه با C++ برنامه ای سریع و بسیار تمیز بسازه و بالعکس یک نفر دیگه با همون زبان و حتی C می تونه گندی به بار بیاره که از هر زبان اسکریپتی سرعتش کمتر و طراحیش بدتر باشه.
تجربه خود من اینجوری بود که اولین باری انجینی که نوشتم (عکس ها و ویدیو های قدیمی در سایت موجود هست)‌ . با زبان C++ و با استفاده از انواع و اقسام مدل های شی گرایی و دیگر امکانات این زبان بود. در نسخه بعدی این سیستم رو قوی تر کردم و از سیستم پلاگین با استفاده از شی گرایی و وراثت،‌ stl و object model و exception اینجور چیزها در طراحی استفاده کردم ولی با شکست مواجه شدم. توی دو نسخه بعدی یواش یواش امکانات زبان C++ رو کنار گذاشتم تا حدی که در نسخه آخر hmrengine تقریبا به جز namespace و کلاس های abstract و کلاس های ساده که سیستم های اصلی رو در بر می گرفت،‌ از هیچ کدام از امکانات C++ استفاده نمی کردم که راضی کننده ترین کدی بود که زده بودم (هنوز هم به نظرم خوبه). ولی در نوشتن dark-hammer و با آشنا شدن با linux devloper community و همینطور خواندن نظر linux torvalds و mike acton (برنامه نویس insomniac games) به این نتیجه رسیدم که بهتر هست کلا بیخیال C++ بشم و پروژه رو محدود به C کنم که اصلا هم پشیمون نیستم.

قطعا توی اینترنت سرچ کنی مطالب مشابه زیادی رو می بینی ولی یک سری دلایلی که تو تجربه خودم بهش رسیدم رو می نویسم:

* در زبان C نزدیک ترین رابطه رو با سخت افزار دارید و دقیقا می دونید که کد شما چه کاری انجام خواهد داد وقتی که کامپایل بشه. این خیلی عامل مهمی توی نرم افزارهایی هست که سرعت توشون نقش مهمی رو داره. بر خلاف C++ که لایه های مختلف روی کد شما میاد و کامپایلر اونها رو از کد شما مخفی می کنه و نمی دونید چه خبره ... به عنوان مثال operator ها . constructor و destructor ها . و object hierarchy رو به اینها اضافه کنید تا ببینید که ظاهر کدی که می نویسید چقدر با اون چیزی که برای ماشین کامپایل می شه فرق می کنه.
*‌ زبان C بسیار ساده هست و به راحتی می شه اون رو خواند. شما فقط با function و struct سر و کار دارید. هم تکلیف خودتون معلومه هم کسی که اون رو می خونه.
*‌ دیباگ کردن برنامه های C راحتتر هست.به عنوان مثال وفتی شما از object hierarchy و virtual function استفاده می کنید، برای trace کردن کد باید تمام این لایه ها رو طی کنید و خیلی مواقع کلی وقتتون رو می گیره که فقط کدی که خطا ایجاد می کنه رو توی این لایه ها پیدا کنید.
* کامپایل برنامه های C می تونه خیلی سریعتر باشه:‌ اولا کامپایلرهای C به طور کلی سریعتر هستند. دوما اینکه شما با استفاده از forward declaration (چیزی که در کدهای من زیاد می بینید) می تونید کلی زمان کامپایل رو کاهش بدید.
*‌ برنامه های C بسیار portable تر هستند:‌ کامپایلرهای بهینه شده C تقریبا برای هر سخت افزار و پلتفرم ای که فکرش رو بکنید موجود هست مثل microcontroller ها. در ضمن برای برنامه های C به راحتی میشه binding به زبان های دیگه و اسکریپت ها درست کرد. در حالی که این مورد در زبان C++ مشکلتر هست.
*‌ زبان C++ دست شما رو برای خرابکاری و نوشتن کد کثیف و کند خیلی بازتر می گذاره. در حالی که ممکن هست فکر کنید برنامه ای که نوشتید خیلی "خوشگل و تمیز" هست و از انواع کلاس ها، exception و مدل های سوسول بازی دیگه استفاده کردید ولی عملا کدی که کامپایل می شه یک کد کند و افتضاح هست و همینطور به سختی دیباگ و maintain می شه. البته شکی نیست که کد تمیز و سریع هم می شه با C++ نوشت. ولی قضیه اینه که C++ دست شما رو برای خرابکاری بیشتر باز می گذاره.
* زبان C کتابخانه هایی مثل boost و stl نداره و شما مطمعن هستتید که کسی از اونها استفاده نخواهد کرد.

دلایل دیگه هم داشت از جمله امکان راحتتر نوشتن برنامه های cache friendly و data-oriented که اونها رو از مطالب mike acton یاد گرفتم
تنها چیزی که شاید کمی نیاز داشتم template ها بود که باز هم با استفاده از void pointer ها و مدل های ساده دیگه کارم رو راه انداختم.

تقریبا بیشتر برنامه های سیستمی که احتیاج به سرعت دارند با زبان C نوشته می شوند. مثل linux kernel،‌ windows kernel. موتورهای بازی مثل quake3 (که سورسش موجود هست). احتمالا موتور بازی های دیگه هم مانند شرکت insomniac باید همینطور باشه. ولی شکی نیست به خاطر محبوبیت زبان C++ در حال حاضر بیشتر استودیو ها با این زبان کار می کنند.

نظرات یک سری از کار درست های برنامه نویس هم راجع به C++ اصلا مثبت نیست.
نظر linus torvalds سازنده linux راجع به این زبان (با همون لحن تندش)‌:
http://harmful.cat-v.org/software/c++/linus

مقاله mike acton به نام typical C++ bullshit:
http://macton.smugmug.com/gallery/8936708_T6zQX#593426709_ZX4pZ

در مقابل مثل versus های دیگه این بحث طرافداران برعکس هم داره :
http://unthought.net/c++/c_vs_c++.html

یا جان کارمک که سالها C کار حرفه ای بوده جدیدا در یکی از tweet های خودش گفته که : یک برنامه نویش بد با C++ کد بسیار افتضاحتری از C می تونه بزنه ولی یک برنامه نویس خوب با C++ می تونه کد بهتری نسبت به C بزنه.
(می شه گفت از نظر اون من در برنامه نویس بد قرار می گیرم)‌ ولی باز با تمام احترامی که کارمک برای من داره و هم با تجربه شخصی و سلیقه خودم و این نکته که کارمک بهترین موتورهای خودش رو با زبان C نوشته و نه با C++. روی حرفش حساب نمی کنم. و به شخصه صحبت های mike acton و linus torvalds رو خیلی دوست داشتم چون بیشترش تجربه شخصی من در شکست هایی که در نوشتن کد خوب داشتم بود.

جواب طولانی شد ولی شاید به درد یک سری بخوره ...

[Sepehr M]

ممنون...خیلی مفید بود...

[pswin.pooya]

سلام سپهر

تقریبا میشه گفت با تمام حرف هایی که میزنی موافق هستم. منتها :

C مثل لینوکس شبیه یه گرگ می مونن اگر بتونی درست تربیتش کنی کاملا تحت کنترل هستن و بشدت قوی اما برعکس اون هم وجود داره. اگر کوچیکترین اشتباهی بکنی میتونه غیر قابل جبران باشه. از اونجا که C بشدت به سخت افزار نزدیک هست. استثناءها و ایرادات و تفاوتهای سخت افزاری رو هم به دنبال خودش یدک می کشه. همین مساله باعث شده که برنامه نویسهای حرفه ای به سراغش برن.

یه نمونه بارز داخل توابعی هست که float رو برگشت میدن. فرض کن می خوای یه اشاره گر به تابع داشته باشی که برای انواع مختلف تعریف ها به کار بره. تو همچین حالتی داخل C از void* و داخل C++ از قالب ها (معمولا) استفاده میشه. خب مشکل اینجا ایجاد میشه که اگر شما بخوای اون تابع رو فراخوانی کنی داخل هر پلتفرم سخت افزاری رفتار متفاوتی رو از کامپایلر می بینی. مثلا ممکنه که x86 از کمک پردازنده x87 استفاده کنه و یا اینکه یه پردازنده DSP ذاتا اعشاری باشه. یا اصلا داخل همون خانواده x86 هم تفاوتهای رفتاری زیادی وجود داره. نتایج تمام اینها منجر به بازگشت دادن مقدار اشتباه توسط این نمونه از توابع داخل برخی از سیستم ها میشه. حالا مثلا اگر از قالبهای C++ استفاده بکنید (مثلا برای ساخت فانکتور) این رفتار رو خود کامپایلر کنترل میکنه. زبانهایی مثل C# و یا جاوا سعی میکنن یا استفاده از CLI از اینجور موارد پرهیز کنن.

یه مورد دیگه مربوط به استانداردهای برنامه نویسی هست. ما یکسری مدل برنامه نویسی داریم که معروف ترین اونها عبارتند از:


structured programming
object oriented programming
aspect oriented programming

هر کدوم از اینها مفاهیم خاصی رو مطرح میکنن که توی مدلهای قبلی به شکل کامل قابل پیاده سازی نیست. مثلا با زبان C هم میشه شی گرایی کرد ( ساختارها رو میشه به عنوان اشیاء طراحی و کنترل کرد) اما C نمی تونه تمام مفاهیم شی گرایی رو مورد پوشش قرار بده و با C++ میشه تا حدودی برنامه نویسی مفهوم گرا انجام داد اما باز هم به همین شکل نمیشه تمام مفاهیم رو پیاده سازی کرد. توی برخی از پروژه ها لازمه که از سبک خاصی از برنامه نویسی تبعیت بشه. اما مساله که مطرح هست مدلهای 2 و 3 به موارد انتزاعی و ایده آل نزدیک هستن و برنامه نویسی ساخت یافته به واقعیت برنامه نویسی.

متاسفانه C++ یه دیزاین گنگ یا نسبتا گنگ نسبت به بعضی از موارد مثل عملگرها و سازنده ها داره (یا حداقل از نظر من) اما باز هم قابلیت انعطافی رو فراهم میکنه که رسیدن به اون داخل C به راحتی امکان پذیر نیست.

[مصطفی ساتکی]

C مثل لینوکس شبیه یه گرگ می مونن اگر بتونی درست تربیتش کنی کاملا تحت کنترل هستن و بشدت قوی اما برعکس اون هم وجود داره. اگر کوچیکترین اشتباهی بکنی میتونه غیر قابل جبران باشه. از اونجا که C بشدت به سخت افزار نزدیک هست. استثناءها و ایرادات و تفاوتهای سخت افزاری رو هم به دنبال خودش یدک می کشه. همین مساله باعث شده که برنامه نویسهای حرفه ای به سراغش برن.

با این حرف موافق نیستم چون بالاخره مشخصه سورسی که تولید میشه روی چه پلتفرمی قرار اجرا بشه.
من با خیلی از انجین ها تو linux کار می کنم که هنوز نسخه ویندوزی ندارند تا چه برسه به اینکه رو هر سخت افزاری کار کنه



اما باز هم قابلیت انعطافی رو فراهم میکنه که رسیدن به اون داخل C به راحتی امکان پذیر نیست.
با این حرف هم موافق نیستم به نظرم کسی که سراغ Ansi C میاد تکلیفش مشخصه اینقدر performnce براش ارزش داشته که انتخابش به این سمت بوده برای کارهای سیستمی تولید هر نوع انجین به نظرم C99 بهترین گزینه هستش چون واقعاً تو پایین ترین لایه اصلاً نیازی به کلاس نیست حداقل من بدون هیچ مشکلی کارها را انجام میدم و با open source هایی هم که به اینصورت هستند راحتترم .البته برای راحتی کاربر برنامه نویس میشه wrapper هایی را با کلاس ها تولید کرد تا راحتر بتونه از کتابخانه یا انجین موردنظرش استفاده کنه.
متاسفانه آمار و ارقام که برای benchmark بعضی از کتابخانه Open source وجود که از زمان شروع استفاده از C++ به مرور زمان performance در نسخه های جدیدتر پایین بوده البته نمیشه گفت مقصر C++ بوده ولی میشه گفت developer های Ansi C دید بهتری نسبت به سخت افزار دارن مثل تکنیک unroll و alignment که از cache L1 به بهترین نحو استفاده می کنن وقتی کد می نویسن به کد ماشین تولید شده هم دقت زیادی دارن

[pswin.pooya]

با این حرف موافق نیستم چون بالاخره مشخصه سورسی که تولید میشه روی چه پلتفرمی قرار اجرا بشه.
من با خیلی از انجین ها تو linux کار می کنم که هنوز نسخه ویندوزی ندارند تا چه برسه به اینکه رو هر سخت افزاری کار کنه

توي مرحله اول بايد بگم كه برنامه نويس ها گاها برنامه هايي مي نويسند كه وابسته به سيستم عامل هست و نه پلتفرم سخت افزاري. اين برنامه نويس هست كه مشخص ميكنه برنامه اون بايد چه شكلي باشه. تو مرحله دوم فكر كنم شما منظور من رو اشتباه متوجه شديد، گفته هاي من با مثال شما هيچ تناقضي نداره.


مشخصه سورسی که تولید میشه روی چه پلتفرمی قرار اجرا بشه.
شما با اين حرفتون كل ذات طراحي لينوكس و C رو زير سوال برديد. داخل لينوكس مواردي مثل سيستم فايل و يا خروجي، ورودي و خطاي استاندارد براي همين طراحي شدن كه شما لازم نباشه بدونيد كه سخت افزار مقصد شما چي هست. ( يا حداقل تا مرحله كامپايل). بر فرض كه مي دونيد دقيقا چي هست ( فرض كن x86) حالا چند تا سوال مطرح ميشه:

1. چند بيني هست ( مشكل هميشه x86)?
2. از كدوم يكي از افزونه ها پشتيباني مي كنه (‌MMX، SSE و ... )
3. ....

فرض كن حتي جواب موارد بالا رو هم مي دونيد. مثلا 32 بيتي، از هيچ كدوم و ...

حالا سوال هاي ديگه كه مطرح ميشه:

1. فركانس كاري چقدر هست؟‌ ( x86 فركانس رو گزارش نمي كنه) ( مثلا ميخواي تخميل در مورد الگوريتمت بزني)
2. ميزان حافظه موجود چقدر هست؟ ( داخل x86 يه متد استاندارد براي اندازه حافظه وجود نداره)
3. ساعت سيستم چند هست؟‌ ( لازم هست مشكل Y2K رو ياد آوري كنم )
4 . ...

گاها اين استثناء ها اينقدر زياد هست كه حتي الگوريتم هاي مختلف برخورد با اونها با مشكل روبه رو ميشه. مثلا براي حل مشكل فركانس تروالدز الگوريتم BogoMips رو ارائه كرد كه با روي كار اومدن پردازنده هايي كه فركانس متفاوت در زمان اجرا دارن شكست خورد و در نتيجه يه قسمت بزرگ از سيستم هاي زمان خودش مشكل پيدا كردن.


من با خیلی از انجین ها تو linux کار می کنم که هنوز نسخه ویندوزی ندارند تا چه برسه به اینکه رو هر سخت افزاری کار کنه
دوست من كامپايلر GCC پورت ويندوزي نداره اما با يه قسمت برزگ از پلتفرمهاي سخت افزاري روز كار ميكنه.


با این حرف هم موافق نیستم به نظرم کسی که سراغ Ansi C میاد تکلیفش مشخصه اینقدر performnce براش ارزش داشته که انتخابش به این سمت بوده برای کارهای سیستمی تولید هر نوع انجین به نظرم C99 بهترین گزینه هستش چون واقعاً تو پایین ترین لایه اصلاً نیازی به کلاس نیست حداقل من بدون هیچ مشکلی کارها را انجام میدم و با open source هایی هم که به اینصورت هستند راحتترم .البته برای راحتی کاربر برنامه نویس میشه wrapper هایی را با کلاس ها تولید کرد تا راحتر بتونه از کتابخانه یا انجین موردنظرش استفاده کنه.

بازهم تو مرحله اول بايد مشخص كنم كه مشخص كارايي (performance) با انعطاف پذيري (flexibility) دو مورد كاملا متفاوت هستند. مثالهاي خيلي زيادي رو ميشه زد كه سيستم هايي كارايي بالا دارن اما قابليت انعطاف بالا ندارن. معيارهاي زيادي ديگه اي براي سيستم ها مثل قابليت اطمينان (reliability) و ... وجود داره كه كلا مباحث جدا از هم هستن. و اينها بيشتر مربوط به نرم افزار و كدينگ هست تا زبان برنامه نويسي.

از نظر كارايي زبان C/C++ رو اگر با مدلهاي يكسان استفاده بكنيد برابر هستند (مثل هردو ساختيافته و يا شي گرا )‌ اما اگر با مدلهاي جدا مثلا ساخيافته براي C وشي گرا براي C++ يك اشتباه بزرگ رو انجام دادين. چون كلا سبك برخورد با مساله شما فرق كرده.

[سپول]

من که حرف های پویا رو نفهمیدم چیه و از اصطلاح ها و توضیحات سر در نیاوردم. ولی اونهایی رو که حدودا فهمیدم جواب می دم!


C مثل لینوکس شبیه یه گرگ می مونن اگر بتونی درست تربیتش کنی کاملا تحت کنترل هستن و بشدت قوی اما برعکس اون هم وجود داره. اگر کوچیکترین اشتباهی بکنی میتونه غیر قابل جبران باشه. از اونجا که C بشدت به سخت افزار نزدیک هست. استثناءها و ایرادات و تفاوتهای سخت افزاری رو هم به دنبال خودش یدک می کشه. همین مساله باعث شده که برنامه نویسهای حرفه ای به سراغش برن.

زبان C مثل CPP چیزی نیست که استثناءها و تفاوت های سخت افزاری رو یدک بکشه ! توی جفتشون شما یک پلتفرم سخت افزاری دارین که همون نوع cpu و بقیه خصوصیات سخت افزار که گفتی هست. یکی هم سیستم عامل که یک سری API به شما می ده که باهاش کار می کنین. چون کد شما در c یا cpp به کد native تبدیل می شه پس برای هر پلتفرم شما باید تفاوت ها رو هم در نظر بگیرید، چه در سخت افزار و چه در API. دیگه این مورد که توی C و CPP و هر کامپایلری که کد native خروجی می ده فرقی نمی کنه که.
بله اگر منظور شما فرق C با جاوا باشه درسته چون جاوا کلا روی VM اجرا می شه و یک لایه بین سیستم عامل و زبان برنامه نویسی قرار می گیره ولی این فرق بین C و CPP نیست.


دوست من كامپايلر GCC پورت ويندوزي نداره اما با يه قسمت برزگ از پلتفرمهاي سخت افزاري روز كار ميكنه.
من تا حالا امتحان نکردم خودم، ولی تا اونجا که می دونم پورت ویندوز هم داره و اسمش mingw هست.
http://mingw.org/

[orache]

سلام ببین میتونی مراحل کارتو بهم بگی اخه منم مدتهاست دوست دارم یه انجین بازی سازی بسازم یه انجین الکی برای سر گرمی نه یه انجین توپ!!
بیشتز خوشم میاد با اگری و یا اون یکی که الان یادم نیست همون که باهاش وار کراfت رو ساخته بودن و یا با xna بسازم میتونی مراحل کار رو بهم بگی یعنی تو کجا باید درست کنم چجوری پیش برم و... ممنون

[mohamad.zakery]

منم با حرفهای پویا موافقم
اما
چرا بعضی ها C++ را نمی پسندن؟

دلیل مشخص مشخصه!!!

برای شی گرا کد زدن شما باید از منطق شی گرایی استفاده کنی، اما

مهم ترین نکته اینه که باید دید شی گرا داشته باشی!!!

چون خیلی ها دید شی گرا ندارند، زبانهای Oop براشون قابل هضم نیست یا نمی پسندن!!!

[مصطفی ساتکی]

!

چون خیلی ها دید شی گرا ندارند، زبانهای Oop براشون قابل هضم نیست یا نمی پسندن!!!
دوست عزیز خود من 15 ساله کد میزنم 8 سالشو object oriented کار کردم صحبت بلد بودن نیست تو برنامه سیستمی و سطح engine به سبک C99 بهتر جواب میده

[سپول]

سلام ببین میتونی مراحل کارتو بهم بگی اخه منم مدتهاست دوست دارم یه انجین بازی سازی بسازم یه انجین الکی برای سر گرمی نه یه انجین توپ!!
اول این تاپیک رو بخون
http://tinyurl.com/8vme8uk
اگه بعدا سوالی برات پیش اومد بپرس

...
آقا انگار طبق معمول بحث داره خارج می شه از موضوع. بیخیال...

[H_G_G_I]

سلام
اقا من فقط تونستم 3dParty رو کامپیل کنم
انجین با VS10 کامپیل نمیشه !!!!!!!!
کامپیلر اینتل رو از کجا بیارم ؟ هرچی گشتم نبود ! قبلنا یکی دان کرده بدم نصب نمیشد !
راستی ادیتور داره ؟ یا فقط کتابخونست ؟
فیزیک و .. داره یا فقط رندره ؟
حالا اینارو خودم می بینم !
کامپیل رو چی کار کنم ؟ کامپایل شدش رو ندارید ؟
GCC دارم . با اون چه طور کامپیل کنم !
اکلیپسم دارم ولی پروژه انجین رو باز نمیکنه ! یه کمکی کنید من همیشه با کامپایل کردن در گیرم !
-
-
-
راستی موفق باشی !
خوب کاری کردی که کد بازش کردی دمت گرم ! یه بنده خدایی مثل من می گه دستش دردنکنه !

[pswin.pooya]

زبان C مثل CPP چیزی نیست که استثناءها و تفاوت های سخت افزاری رو یدک بکشه ! توی جفتشون شما یک پلتفرم سخت افزاری دارین که همون نوع cpu و بقیه خصوصیات سخت افزار که گفتی هست. یکی هم سیستم عامل که یک سری API به شما می ده که باهاش کار می کنین. چون کد شما در c یا cpp به کد native تبدیل می شه پس برای هر پلتفرم شما باید تفاوت ها رو هم در نظر بگیرید، چه در سخت افزار و چه در API. دیگه این مورد که توی C و CPP و هر کامپایلری که کد native خروجی می ده فرقی نمی کنه که.

من يه نمونه خيلي ساده رو مثال زدم.

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


دوست عزیز خود من 15 ساله کد میزنم 8 سالشو object oriented کار کردم صحبت بلد بودن نیست تو برنامه سیستمی و سطح engine به سبک C99 بهتر جواب میده
نمي دونم شما چه نسبت به C مخصوصا استاندارد C99 تمايل داريد اما تا اونجا كه من مي دونم ديد قالب داخل برنامه نويسي انجين مخصوصا انجينهاي بازي به سمت شي گرايي هست و حتي كارمك هم كه نسبت به C تعصب خاص داشت الان داره از C++ استفاده مي كنه.

[سپول]

@H_G_G_I:
متاسفانه کامپایلر ویژوال استودیو پشتیبانی خوبی از زبان C و مخصوصا C99 نداره و نخواهد داشت و باید کامپایلر intel رو نصب کنید. این کامپایلر هم در اینترنت ریخته . دنبال intel ComposerXE-2011 به بالا بگیردید.
فعلا که پروژه تازه استارت خورده و فقط سیستم های اولیه و یک رندر اولیه رو داره. کم کم پیشرفت می کنه.
gcc اگه داری راحتترین راهش کامپایل توی لینوکس هست. کافیه در لینوکس gcc و cmake رو داشته باشی و چندتا command (بدون نیاز به Ecipse) رو اجرا کنی.
برای راهنمای بیشتر کامپایل اینجا رو بخون :
https://bitbucket.org/sepul/dark-hammer/wiki/getting-started.wiki

eclipse هم من دو تا سیستم لینوکس دارم روی هیچ کدومش مشکل نداره. من روی eclipse juno باز می کنم نسخه شما رو نمی دونم.

@pswin:
من که باز هم منظور شما رو متوجه نشدم. نکته اینجا بود که در برنامه نویسی برای سخت افزار دو زبان C و C++‎ حداقل فرقی با هم ندارند چون جفتشون کامپایلر native استفاده می کنند و از API های سیستم عامل استفاده می کنند. api سیستم عامل هم که در هر سیستم عاملی به زبان C هست. شاید منظور شما استفاده api های جانبی مثل stl و boost و tbb یا حتی مثلا Qt باشه که مثلا برای زبان CPP می سازند.

آقا حالا بیخیال C vs CPP . هر کی یه عقیده ای داره. توی برنامه نویس ها هم تفاوت عقیده هست و یک سری برنامه نویس های مدرن بازیساز این عقیده شما رو که object oriented برای بازی سازی بهتره رو ندارند. (لطفا لینک های قبلی که گذاشتم رو بخونید). من خودم ترجیح می دم فقط در موارد سطح بالاتر مانند GUI از زبان های object oriented و به طبع CPP استفاده کنم (که اون هم از python استفاده می کنم). به نظر من اگه کسی بخواد در سطح پایین و سیستمی کد بزنه C زبان خیلی خوبی هست و اگر هم می خواهید سطح بالا کد بزنید چرا خودتون رو درگیر CPP کنید ؟ خوب زبان هایی که برای این منظور درست شدن و مفاهیم object oriented رو درست تر پیاده کردن و در ضمن garbage collection هم دارند رو کار کنید مثل python یا java و C#‎. باز هم این نظر منه ... ربطی به اینکه اون بهتره یا این نداره !

حالا جدا از این حرف ها من الان با سرعت در opengl مشکل دارم. نمی دونم در استفاده از API مشکل دارم یا طراحی state system ام اشتباهه. کلا کندتر اجرا می شه برنامه opengl چه در لینوکس چه در ویندوز.
کلا من در طراحی سیستم رندر با هر دو این api ها به طور دقیق آشنا شدم و الان می تونم بگم واقعا directx11 جز در مواردی خاص، api واقعا بهتری هست. (با اینکه دوست داشتم opengl بهتر باشه به خاطر multiplatform بودنش) ولی opengl هنوز خیلی عقبه ...

[pswin.pooya]

حالا جدا از این حرف ها من الان با سرعت در opengl مشکل دارم. نمی دونم در استفاده از API مشکل دارم یا طراحی state system ام اشتباهه. کلا کندتر اجرا می شه برنامه opengl چه در لینوکس چه در ویندوز.

سلام
مشكلتون رو بگيد تا حلش كنيم. در حقيقت چون روي OpenGL3 تمركز داريد از يه سبك كاملا جداي OpenGL داريد استفاده مي كنيد و امكان داره بخاطر استفاده از دستورهاي قديمي به مشكل برخورده باشيد. يه مورد ديگه ميتونه از كارت گرافيك شما (اگر اشتباه نكنم ATI بود) باشه. معمولا ATI ساپورت خوبي از GL رو ارائه نمي ده.
مي تونيد براي پيدا كردن اشتباه هاي كدينگ OpenGL و يا اندازه گيري كارايي از gdebugger استفاده بكنيد. كه با يه سري راهنمايي باعث افزايش سرعت و كارايي ميشه. اصولا OpenGL سرعتش بيشتر هست. توي تست هاي خود من و بعضي از شركتهاي معروف هم مثل id و valve اين شكليه :
http://blogs.valvesoftware.com/linux/faster-zombies/

كلا اخيرا توجه شركتهاي بازي سازي داره به سمت GL جذب ميشه يكي از بزرگترين دليل هاي اون هم stableتر بودن و كارايي OpenGL هست. حتي يه مدت هم unreal مي گفت در حال حاضر كردن يه پورت OpenGL براي انجينش هست و در آخر هم كه بازي Rage با سرعت و كارايي بالاش يجورايي همه چيز رو مشخص كرد.


کلا من در طراحی سیستم رندر با هر دو این api ها به طور دقیق آشنا شدم و الان می تونم بگم واقعا directx11 جز در مواردی خاص، api واقعا بهتری هست. (با اینکه دوست داشتم opengl بهتر باشه به خاطر multiplatform بودنش) ولی opengl هنوز خیلی عقبه ...
تا اونجا كه من مي دونم شما از OpenGL 3 استفاده كرديد كه در زمان خودش با DX 10 مقايسه مي شده و نه 11 بعدا OpenGL4 iتقريبا همزمان با DX 11 منتشر شد. كه فعلا آخرين ويرايش هم OpenGL 4.3 هست.
در مورد عقبتر بودن كه همه مخصوصا nvidia نظر عكس رو دارن حتي يكبار اين قضيه رو به صورت يكسري اسلايد داخل يه كنفرانس مطرح كرد. و تايم لاينهاي تكنلوژي رو داخل اين دو بررسي كرد. به عنوان مثال تا اونجا كه مي ميدونم الان از نظر شيدرها OpenGL يك واحد بيشتر از DX داره كه بعضي ها ميگن احتمالا مبناي شيدر مدل 6 ميشه:
http://www.geeks3d.com/20120806/opengl-4-3-compute-shaders-details/

و يكسري از الحاقي هاي جديد:

http://www.geeks3d.com/20120806/opengl-4-3-and-opengl-es-3-0-adaptive-scalable-texture-compression-extension-astc/
http://www.geeks3d.com/20120920/programmable-blending-on-mobile-and-desktop-gpus-opengl/


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

[سپول]

@pswin:
مشکل من با سرعت ربطی به بهتر بودن یا بدتر بودن api نداشت. مسلما من یک کار اشتباهی دارم انجام می دهم در opengl. و گرنه نباید اینجوری باشه. مشکل من با خود api هست.

من به خوبی با نقاط قوت و ضعف opengl آشنا هستم. و با api 4.2 هم کار می کنم و از api قدیمی استفاده نمی کنم. کلا فکر می کنم اشتباه من الان یا در map کردن بافر هست یا مدیریت کردن state ها (به خاطر اینکه بین dx و gl همخوانی داشته باشه) که باید بیشتر روش کار کنم.

شاید شما با dx11 خیلی تجربه ندارید ولی باید بگم که opengl به طور مشهودی از روی این api الگو برداری کرده (چون سخت افزارها اول برای dx11 اومدن) و در واقع ناچار بوده.. در خیلی جاها هم همچنان عقب هست و می تونم توضیح هم بدم که کجاها هست.
در اینکه opengl پشتیبانی اش از پلتفرم های مختلف خوب هست که شکی نیست. از این نظر عالی هست و همین هم باعث می شه همیشه برای یک سری پلتفرم ها تنها گزینه باشه ولی این دلیل نمیشه که بهتر باشه. در واقع الان من به راحتی می تونم بگم که dx11 ساختار بهتری داره.

valve قطعا می تونه سرعت بهتری از gl بگیره چون با سازندگان سخت افزار کار می کنه و مهندس های قوی تری داره. ولی dx11 اینقدر api خوبی هست که شما بدون نیاز به منابع خاصی که valve داره می تونید راحتتر عمل کنید. نکته همینجاست که تا خودتون با جفتش کار به طور جدی کار نکنید متوجه نمی شید.

قضیه عقبتر بودن مربوط به extension های عجیب و غریب opengl نمی شه. چون جز در دمو های nvidia در جای دیگه استفاده نمی شه! صحبت راجع به اینه که برای کاری که شما از سخت افزار عمومی می خواهید چجوری جواب می ده !!!‌
در ضمن اون لینکی که معرفی کردی مربوط به shader6.0 نیست بلکه compute-shader هست که در نسخه 4.3 معرفی شده (که درایور من هنوز هم ساپورت نمیده!!)‌ در حالی که compute-shader رو dx11 از همون ابتدا داشت . یعنی ۲-۳ سال پیش و حتی بازی هایی مثل battlefield3 هم از شیدر هاش استقاده می کنند. حالا نمی دونم جلو بودن رو به چی می گی.

توی این تجربه اونقدر مثال هست که می تونم بزنم که opengl چقدر عقب هست ... که خوشبختانه خودت هم یکیش رو ناخواسته مثال زدی.

اولین چیزی که توی ذوق می زنه بی نظمی این api هست که تکلیفش با خودش معلوم نیست. برای هر کاری چند روش معرفی شده که مسلما یکیش بهترین هست ولی منابع درستی از اونها موجود نیست. api هنوز یک library رسمی از khornos نداره که تکلیف ما معلوم باشه و راحت باهاش کار کنیم. هنوز باید به کتابخانه های 3rdparty مثل glew یا موارد مشابه برای لود کردن api رجوع کنیم که هر کدوم هم مشکلاتی دارند.

directx11 سیستم multi-thread برای اعمال دستورهای گرافیکی رو پیاده کرده که می تونید دستور ها رو در thread های دیگر ببرید که متاسفانه opengl هنوز هم همچین سیستمی نداره و همین باعث شده که سازندگان کارت گرافیک درایورهای خودشون رو برای این موضوع بازنویسی نکنند.

directx از نسخه ۸ و ۹ می تونست شیدرها رو بصورت offline کامپایل کنه که هنوز هم شما در GLSL همچین امکانی رو ندارید. کامپایل offline مزیت های خیلی زیادی داره از جمله اینکه کامپایلر می تونه زمان بیشتری صرف کنه و کد رو بهینه تر کنه. در ضمن شما سورس شیدر رو با برنامه بیرون نمی دید و همچنین وقتی برای کامپایل در زمان اجرای برنامه صرف نمی کنید! در ضمن می دونید که کد کامپایل شده شما چون یک استاندارد خاص داره کیفیت کد کامپایل شده روی کارت ati با nvidia فرقی نمی کنه و هزار دلیل دیگه... این نکته ای که می گم مربوط به ۶-۷ سال پیش هست که هنوز opengl نتوسته با سازندگان سخت افزار سرش به توافق برسه.
در ضمن HLSL همچنان تمیزتر هست نسبت به GLSL. شما مجبور نیستید برای لینک کردن متغیرهای مشترک بین شیدر ها حتما از اسم های برابر استفاده کنید و برای این منظور semantic ها رو به کار برده.. یا اینکه مثلا هنوز در GLSL ارتباط sampler و texture مانند directx9 یک به یک هست که در dx10+ اینجوری نیست.

opengl هنوز از state object ها مثل rasterizer state و blend state که باعث می شه شما گروهی از state هارو یکجا به کارت گرافیک بدهید ساپورت نمی کنه که directx10 هم این خصوصیت رو داشت.

شما فقط تعداد api call ها در directx و opengl رو با هم مقایسه کنید ببینید چقدر شما در opengl بیشتر توابعش رو صدا می زنید اون هم به خاطر طراحی این api هست.

قاعدتا شرکت های خفن که منابع قوی دارند و با سازندگان سخت افزار کار می کنند به خاطر باز بودن opengl بیشتر می تواندد روش مانور بدهند ولی ما بدبخت ها و خیلی از برنامه نویس های دیگه دسترسی به اون منابع رو نداریم. و api می خواهیم که به بهترین نحو کارمون رو راه بندازه و document درستی و استاندار درستی هم داشته باشه که opengl هیچ کدوم از اینها رو به خوبی directx نداره.

در مورد ابزار هم من با gdebugger کار می کنم. فکر کنم شما با pix کار نکردید و نمی دونید که چقدر این ابزار (که برای directx هست) بهتر از gdebugger هست.

بر خلاف شما من تعصب خاصی روی هیچ کدوم از این api ها ندارم. و حتی دوست دارم opengl بهتر باشه چون دیگه زحمت سر و کله زدن با directx رو هم به خودم نمی دادم. ولی متاسفانه هنوز اینجور نیست و opengl با اینکه به خاطر open بودن و openglES و چیزهای دیگه در حال رشد هست ولی هنوز به باحالی directx11 نیست.

[سپول]

مشکل سرعت رو پیدا کردم. توی یکی از flag های map کردن در opengl بود. (GL_MAP_UNSYNCHRONIZED_BIT)
متاسفانه یک سوتی دیگه که این احتمالا از داریور هست چون در directx شما معادل همین flag رو نمی گذارید و باعث می شه درایور به خوبی خودش sync کنه و مشکلی پیش نمیاد. ولی حداقل در درایور من که اینجوری نیست و باید با وجود این پارامتر sync کردن cpu و gpu رو خودم مدیریت کنم وگرنه رندر ممکنه بریزه به هم.

[pswin.pooya]

در ضمن اون لینکی که معرفی کردی مربوط به shader6.0 نیست بلکه compute-shader هست که در نسخه 4.3 معرفی شده (که درایور من هنوز هم ساپورت نمیده!!)‌ در حالی که compute-shader رو dx11 از همون ابتدا داشت . یعنی ۲-۳ سال پیش و حتی بازی هایی مثل battlefield3 هم از شیدر هاش استقاده می کنند. حالا نمی دونم جلو بودن رو به چی می گی.
اگر منظور شما دایرکت کامپیوت هست. باید بگم قضیه فرق داره. اینجا از شیدرهای پردازشی برای تولید خروجی گرافیکی بصورت مستقیم استفاده میشه و جزء پایپ لاین شیدر هست و نه جزی جدا.



directx11 سیستم multi-thread برای اعمال دستورهای گرافیکی رو پیاده کرده که می تونید دستور ها رو در thread های دیگر ببرید که متاسفانه opengl هنوز هم همچین سیستمی نداره و همین باعث شده که سازندگان کارت گرافیک درایورهای خودشون رو برای این موضوع بازنویسی نکنند.

چند تا الحاقی چند سال ‍پیش برای همین منظور معرفی شد که یکی از اونها ARB_SYNC هست که سال ۲۰۰۹ معرفی شد. و بعد با OpenGL 3.2 وارد هسته شد:
http://www.opengl.org/registry/specs/ARB/sync.txt

البته خود من تا حالا از این مورد استفاده نکردم.



directx از نسخه ۸ و ۹ می تونست شیدرها رو بصورت offline کامپایل کنه که هنوز هم شما در GLSL همچین امکانی رو ندارید. کامپایل offline مزیت های خیلی زیادی داره از جمله اینکه کامپایلر می تونه زمان بیشتری صرف کنه و کد رو بهینه تر کنه. در ضمن شما سورس شیدر رو با برنامه بیرون نمی دید و همچنین وقتی برای کامپایل در زمان اجرای برنامه صرف نمی کنید! در ضمن می دونید که کد کامپایل شده شما چون یک استاندارد خاص داره کیفیت کد کامپایل شده روی کارت ati با nvidia فرقی نمی کنه و هزار دلیل دیگه... این نکته ای که می گم مربوط به ۶-۷ سال پیش هست که هنوز opengl نتوسته با سازندگان سخت افزار سرش به توافق برسه.

این مورد قبلا بصورت الحاقی وجود داشت اما از ویرایش ۳.۲ جزء هسته شده.


در ضمن HLSL همچنان تمیزتر هست نسبت به GLSL. شما مجبور نیستید برای لینک کردن متغیرهای مشترک بین شیدر ها حتما از اسم های برابر استفاده کنید و برای این منظور semantic ها رو به کار برده.. یا اینکه مثلا هنوز در GLSL ارتباط sampler و texture مانند directx9 یک به یک هست که در dx10+ اینجوری نیست.

این دلیل شما برای تمیزتر بودن هست؟!!!

از ویرایش شمازه ۳ به بعد شما همچین کاری رو نباید بکنید. حتی اگر بکنید هم اشتباه هست. و حتی مثل دایرکت هم لازم نیست کاربرد رو مشخص کنید. (شما این کار رو می تونید در زمان لینک برنامه انجام بدید.) در ابتدا این مورد از نظر من خیلی بیخود بود اما بعدا متوجه شدم که برای انعطاف بیشتر طراحی شده و حتی جایی به درد من خورد که خودم هم باور نمی کردم. و ارتباط سمپلر وتکسچر یک به یک نیست. البته نمی دونم اگر هم باشه چه ایرادی داره. شما اصولا باید به هر سمپلر یک تکسچر رو اختصاص بدید.

البته به تازگی شما احتیاج به بایند کردن تکسچر هم ندارید:
http://www.geeks3d.com/20120511/nvidia-gtx-680-opengl-bindless-textures-demo/



قاعدتا شرکت های خفن که منابع قوی دارند و با سازندگان سخت افزار کار می کنند به خاطر باز بودن opengl بیشتر می تواندد روش مانور بدهند ولی ما بدبخت ها و خیلی از برنامه نویس های دیگه دسترسی به اون منابع رو نداریم. و api می خواهیم که به بهترین نحو کارمون رو راه بندازه و document درستی و استاندار درستی هم داشته باشه که opengl هیچ کدوم از اینها رو به خوبی directx نداره.

نمی دونم تا حالا چیزی در مورد OpenGL registry شنیدید یا نه.

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


simics
ns 2, 3
خود یونیکس و لینوکس
...

مثلا کل ایران رو بگردید شاید ده نفر هم ‍پیدا نکنید که simics و یا ns رو بلد باشن اما شرکتهای بزرگی مثل اینتل از simics برای ساخت پردازنده پنتیوم ۴ استفاده کردن و می کنن و شاید قشری که با اونها داره کار میکنه کم باشه اما آینده رو اونها دارن تصویر می کنن. در حقیقت اونها اقلیت ۲۰ درصدی جامعه هستن که نتیجه ۸۰ درصدی رو دارن.


در پایان سپهر همنطور گفتم که مهم نیست که چی هست و چی میشه و کی چه شکلی داره استفاده میکنه. مهم اینه که کی لبه های تکنلوژی رو داره مشخص میکنه حالا به قول شما این لبه ها می خواد در قالب الحاقی های عجیب قریب OpenGL باشه و یا در قالب سیستم یکپارچه منظم دایرکت!!! که چی. من شما چی کار کردیم. در حقیقت تا زمانی که خودمون نتونیم اونجا باشیم یک کاربر هستیم و حکمی که ما برای اونها داریم حکمی هست که بازیکن ها برای برنامه نویسها دارن.


آقا حرف شما قبول OpenGL عقب هستُ امیدوارم این شکلی این بحث بیخود قدیمی تموم شه.



در پایان سپهر هیچ وقت با اطمینان نگو من کاملا api رو میشناسم خود جان کارمکش هم همچین ادعایی رو نداره.

[سپول]

@pswin:

اگر منظور شما دایرکت کامپیوت هست. باید بگم قضیه فرق داره. اینجا از شیدرهای پردازشی برای تولید خروجی گرافیکی بصورت مستقیم استفاده میشه و جزء پایپ لاین شیدر هست و نه جزی جدا.
باید دوباره بگم که قضیه فرقی نداره. انگار اصلا نوشته های من رو نمی خونی. چون اطلاعاتت که متاسفانه همه اشتباه هست. انگار فقط برای کل کل داری جواب می دی.

اولا یک لینکی خودت گذاشتی و گفتی که opengl شیدر 6.0 رو پشتبانی می کنه که من هم جوابت رو دادم که اونی که توی لینک آورده شده شیدر 6.0 نیست و همون compute-shader هست (direct-compute اسم api اش هست). اتفاقا compute-shader توی dx11 هم خروجی گرافیکی میده و باهاش ۲-۳ سال پیش deferred renderer هم نوشتن توی بازی battlefield3 و دموی unreal4 هم استفاده شده. جزپی از pipeline شیدر هم هست اتفاقا!!!


چند تا الحاقی چند سال ‍پیش برای همین منظور معرفی شد که یکی از اونها ARB_SYNC هست که سال ۲۰۰۹ معرفی شد. و بعد با OpenGL 3.2 وارد هسته شد:
http://www.opengl.org/registry/specs/ARB/sync.txt

البته خود من تا حالا از این مورد استفاده نکردم.

اگه شما استفاده نکردی اتفاقا اینی که می گی رو من استفاده کردم . باز هم این اون چیزی نیست که من گفتم. اگه با dx11 کار کرده باشی (که فکر نکنم) در dx11 شما command buffer داری که می تونی اونها رو در thread های جدا (هر دستور گرافیکی) رو اجرا می کنی و بعدا دست خودت هست که اینها رو می دی به درایور به صورت multithread اجرا می کنه. اونی که شما نوشتی مربوط می شه به sync کردن cpu و gpu و معمولا در map و streaming کابرد داره.
جز یکی از خصوصیات api dx11 همین خاصیت multithread هست. که در opengl هم در wishlist قرار گرفته :
http://www.opengl.org/wiki/User_Wish_List


نمی دونم تا حالا چیزی در مورد OpenGL registry شنیدید یا نه.
ای وای. حتی دیگه تابلو ترین اشکالات opengl هم قبول نداری ..
آره شنیدم خودم با همون header ها کار می کنم
اون فقط یک هدر فایل هست که می گیری و هیچ نوع لینکی به function های opengl نمی ده و همه رو باید خودتون لود کنید. که معمولا از کتابخانه های third-party استفاده می کنند ... که هر کدوم هم یک جنگولک بازی در میارن سر این موضوع. دیگه دمش گرم بیاد اون header هم نده ...
هنوز یک راهکار و sdk درست و رسمی برای این مورد نیست در opengl و می تونید انواع loader ها و مشکلاتش رو توی خود لینک سایت opengl ببینید.
http://www.opengl.org/wiki/OpenGL_Loading_Library

مثلا در glew شما اول باید context رو درست کنید و بعد function ها رو لود کنید. حالا می خواهید ARB_debug_output رو داشته باشید . ولی باید اول dummy context (یک طراحی بد دیگه!)‌ رو درست کنید . function ها رو لود کنید و سپس دوباره debug context رو لود کنید. اینجاست که مشکل مرغ و تخم مرغ رو پیدا می کنه و دقیقا همین مشکل رو من با glew داشتم.
اتفاقا این thread هم همین موضوع رو مطرح کرده :
http://www.opengl.org/discussion_boards/showthread.php/173511-GLEW-and-ARB_debug_output-problem
به این میگن کثافت کاری !!!


(در مورد offline compile)‌ این مورد قبلا بصورت الحاقی وجود داشت اما از ویرایش ۳.۲ جزء هسته شده.
متاسفانه انگار شما در مورد خود api opengl که تبلیغش هم می کنی به نظر نمیاد اطلاعات کافی داشته باشی.
اونی که شما دیدی (که فکر کنم منظورت glUseProgram باشه) هم من الان توی انجین استفاده می کنم و برای استفاده از شیدر باینری هست ولی offline compile نیست و موقع اجرای برنامه باید یک بار توسط درایور شیدرها رو کامپایل کنی و cache کنی و دوباره با این دستور لود کنی. که برای هر نسخه از درایور و کارت گرافیک باید این عمل صورت بگیره (یعنی روی کامپیوتر کاربر)
offline compile یعنی اینکه مثل directx شما یک فرمت bytecode استاندارد داشته باشی که روی هر سخت افزار و کارت گرافیکی یک جور کار کنه. این مورد هم در wishlist opengl هست (جز موارد مهمی هم هست) :
http://www.opengl.org/wiki/User_Wish_List#Offline_GLSL_shader_compilation.


از ویرایش شمازه ۳ به بعد شما همچین کاری رو نباید بکنید. حتی اگر بکنید هم اشتباه هست. و حتی مثل دایرکت هم لازم نیست کاربرد رو مشخص کنید. (شما این کار رو می تونید در زمان لینک برنامه انجام بدید.) در ابتدا این مورد از نظر من خیلی بیخود بود اما بعدا متوجه شدم که برای انعطاف بیشتر طراحی شده و حتی جایی به درد من خورد که خودم هم باور نمی کردم. و ارتباط سمپلر وتکسچر یک به یک نیست. البته نمی دونم اگر هم باشه چه ایرادی داره. شما اصولا باید به هر سمپلر یک تکسچر رو اختصاص بدید.
دقیقا نشانه تمیزتر بودن هست. اولا منظور من از اسم یکسان برای انتقال متغیر از vertex-shader به pixel-shader هست . نه ورودی vertex-shader (که باز هم dx این هم بهتر مدیریت می کنه چون با کد vertex-shader همخوانی می ده input-element هارو).
اون قضیه که یک به یک چه ایرادی داره هم بر می گرده به تمیز تر بودن طراحی. sampler یک state هست و texture حافظه. این دوتا نباید یکی باشند. شما "اصولش" اینه که بتونید یک sampler داشته باشید (مثلا linear sampling) و در شیدر به ۱۰ تا texture وصلش کنید و باهاش بخونید. یا در یک جای شیدر با linear sampling از شیدر بخونید و جای دیگه مثلا point sampling از همون شیدر ...
به این میگن cleaner design !!!


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


آقا حرف شما قبول OpenGL عقب هستُ امیدوارم این شکلی این بحث بیخود قدیمی تموم شه.
ایول دمت گرم. نه اتفاقا اختیار داری .. "حرف شما قبول" opengl جلو هست ... lol (چه خوب بود توی یک پستت کلا همین جمله رو می نوشتی به جای این همه جواب های ...)

من هم امیدوارم با این بحث هایی که ظاهرا شما با جواب های خفنتون کش دادین تموم بشه و مجبور نشم هی بیام اینجا وقت تلف کنم. انگار دارم با طرفدار تیم فوتبال بحث می کنم....


ر پایان سپهر هیچ وقت با اطمینان نگو من کاملا api رو میشناسم خود جان کارمکش هم همچین ادعایی رو نداره.
آفرین همینجور کش بده قضیه رو ... اولا کسی نگفت که کاملا api رو میشناسه. گفتم با شناختی که از جفتشون دارم نظرم اینه حالا شما قبول نداری دلیل نداره جبهه بگیری و به زور هم که شده google سرچ کنی و جواب بدی.
در ضمن هر کی می تونه نظرش رو بگه کارمک هم ۱۰۰ بار از این نظر ها داده تو اینترنت یه سرچی بزن...

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

[pswin.pooya]

اگر شما به این میگید هدر فایل، دیگه تکلیف مشخصه. به شما کتاب جعفر نژاد برای C++ (دایتل رو براتون سنگینی میکنه) رو می تونم معرفی کنم. و یا قبل از اون می تونید کتاب "مهارتهای کامپیوتر یک" رو مطالعه کنید:

http://www.opengl.org/registry/


اصولا این ریجیستری شامل داکیومنت ها و سندهای مشخصه و فایلهای هدر هسته ها و الحاقی ها و ... هست. که داخل اون قسمت داکیومنتهاش هر الحاقی رو با جزئیات کامل شرح داده.

[سپول]

@pswin:
ok آقا باشه ...

جدا از این کل کل ها... کسی سوالی داشت بپرسه.

[kochol]

سلام
من یه سوال داشتم این gfx_cmdqueue دقیقا برای چی هست؟

[سپول]

gfx_cmdqueue یک جور آبجکت برای نگه داشتن command queue های کارت گرافیک هست.
در directx11 می تونید در چند thread دستورهای draw رو اجرا کنید اما هر کدوم با context های جدا (این قابلیت هنوز در opengl وجود نداره !) این امکان رو می ده در برنامه های multi-thread با چند thread رندر کنید.
فعلا یک gfx_cmdqueue بیشتر نمی سازم ولی در دیزاین گزاشتم که بعدا چند تا از اینها داشته باشم.

[سپول]

ورژن 0.2.0 هم تمام و سورس ها همراه با یک باینری تست بر روی bitbucket گذاشته شد.
https://bitbucket.org/sepul/dark-hammer/downloads
این فقط یک برنامه تست نورپردازی هست، برای استفاده بهتر از امکانات موتور فایل readme درون بسته رو بخونید

یک سری امکانات اضافه شده به این نسخه شامل
Deferred renderer
Scene management
Sse optimzed frustum culling
Lua scripting
Profiler and memory monitor

این موتور در لینوکس و ویندورز قابل کامپایل و اجرا هست. و با opengl و directx کار می کنه .
سخت افزاز هم باید کارت های گرافیک directx10 یا opengl 3.3 به بالا داشته باشی

[سپول]

آپدیت جدید برای موتور dark-hammer :
در این آپدیت بیشتر امکانات گرافیکی اضافه شده، پروژه سرعت گرفته و تا 3-4 ماه دیگه اگه مشکلی پیش نیاد، شروع می کنم به استارت زدن برای یک خروجی درست حسابی همراه با مدل ها و آرت های طراحی شده توسط خودم.

امکانات اضافه شده در نسخه 0.3.0 :
- سایه های کاملا دینامیک و Cascaded مناسب برای زاویه دید first-person یا third-person. بهینه شده توسط geometry-shader، گوشه های ثابت و PCF فیلتر
- SSAO بهینه شده با قابلیت رندر در رزلوشن پایین تر و bilateral upsample
- نورپردازی HDR همراه با tonemapping
- ابزار وارد کردن مدل کاملتر شده با امکان ساختن texture های بهینه (compressed) به صورت اتوماتیک
- ابزاری برای pak کردن فایل ها همراه با compression جهت در دسترس نبودن و سرعت بهتر و حجم کمتر
- FXAA anti-aliasing

برای دانلود دموی نسخه کنونی به این لینک مراجعه کنید :
http://www.hmrengine.com/blog/?page_id=528

برای کامپایل در linux هم که به آدرس زیر برید و فایل های مدل و texture رو از آدرس زیر بگیرید :
https://bitbucket.org/sepul/dark-hammer
http://www.hmrengine.com/demos/media-0.3/media.pak

در صورت اجرای برنامه با زدن کلید ~ کنسول برنامه رو بیارید و با زدن help در کنسول امکانات مختلف رو امتحان کنید
در ضمن می تونید ابزار مانیتورینگ انجین رو با استفاده از یک browser و وصل شده به آدرس http://localhost:8888 در هنگام اجرای موتور، حافظه و زمان های اجرا رو مشاهده کنید.

فعلا

[HasanP2P]

سلام.
خوب من تازه این تاپیکو دیدم و الان کلی سوال برام پیش امده. قبل از اینکه بپرسم بگم که نگران نباشید سوالاتم آموزشی نیست یعنی نمیخوام بگم اینو چجوری ساختی؟ اونو چجوری ساختی؟ و ... پس ادامه پستمو با خیال راحت بخونید:چشمک:
من یک نگاه کلی روی قسمتی از سورس ها (مثلا ایجاد پنجره و چندتا دیگه) کردم. چیز هایی که تا الان متوجه شدم اینه که شما از الگوهای مالتی پلتفرم استفاده نکردی (حالا به هر دلیلی) و مثلا برای ایجاد پنجره 2 تا پیاده سازی و اینترفیس متفاوت تعریف کردی که احتمالا کاربر موقع کامپایل باید خودش تعیین کنه که کدوم بدرد پلتفرمش میخوره و اونو برای کامپایل انتخاب کنه.
اگر این گفته من درست هست و من درست متوجه شدم به نظرم این ساختار برای اپن سورس بودن و گسترش یافتن (توسط دیگران) زیاد جالب نمیتونه باشه!
خوانایی کدها در حدی نیست که حتی افراد متوسط هم مثلا با 2 بار مرور متوجه بشن. اسم متغییر ها خییلی مختصر شده. کامنت زیادی من تو همین چند قسمت از سورسی که دیدم به چشمم نخورد.
کلا میشه گفت برای گسترش دادن توسط افراد دیگه به نظرم زیاد رادست نیست.
-------
دمویی که گذاشته بودید رو من تست کردم.
برای رندر از تعداد زیادی نزدیک 20 ترد استفاده شده بود که اگر درست باشه برام سواله که این تعداد ترد دقیقا چه کاری رو انجام میدن؟
سوالات دیگه ایی هم دارم که در پستهای بعد میپرسم.
تشکر از اینکه وقت گذاشتید و پست منو خواندید.

[سپول]

من یک نگاه کلی روی قسمتی از سورس ها (مثلا ایجاد پنجره و چندتا دیگه) کردم. چیز هایی که تا الان متوجه شدم اینه که شما از الگوهای مالتی پلتفرم استفاده نکردی (حالا به هر دلیلی) و مثلا برای ایجاد پنجره 2 تا پیاده سازی و اینترفیس متفاوت تعریف کردی که احتمالا کاربر موقع کامپایل باید خودش تعیین کنه که کدوم بدرد پلتفرمش میخوره و اونو برای کامپایل انتخاب کنه.
اولا ممنون که کد ها رو نگاه انداختی ..
در مورد ساختن پنجره بله فایل ها جدا هست، و اینترفیس هاشون فرق داره. از اونجا که کلا پارامترهای ورودی و کل کد در پلتفرم های دیگه (در این مورد) فرق داره. حرف شما هم درست هست باید یک لایه high-level تر روی این ها درست کنم که کار رو راحتتر کنه.
در مورد جاهای دیگه این مورد رعایت شده و کلا اینترفیس ها یکی هست. می تونید به بقیه کدهای کتابخانه core نگاهی بندازید. برای عوض کردن platform هم کافیه preprocessor رو عوض کنید. مثلا برای ویندوز از _WIN_ یا برای لینوکس از _LINUX_ استفاده کنید و کد رو کامپایل کنید.


خوانایی کدها در حدی نیست که حتی افراد متوسط هم مثلا با 2 بار مرور متوجه بشن. اسم متغییر ها خییلی مختصر شده. کامنت زیادی من تو همین چند قسمت از سورسی که دیدم به چشمم نخورد.
کلا میشه گفت برای گسترش دادن توسط افراد دیگه به نظرم زیاد رادست نیست.
آره، می شه حدس زد خوندن این کد برای خیلی ها سخت باشه. مخصوصا کسانی که از پیش زمینه object-oriented و زبان های دیگه مثل java یا C#‎‎‎‎‎‎‎ وارد C/C++‎‎‎‎‎‎‎ شدن.
کدها 90 درصد با زبان C خالص نوشته شده و مفاهیم object-oriented و C++‎‎‎‎‎‎‎ به هیچ وجه استفاده نشده. معمولا خیلی از برنامه نویس ها کدهای خوشگل C++‎‎‎‎‎‎‎ رو دوست دارند. ولی این هم بر می گرده به سلیقه و پیش زمینه افراد. و همینطور بحث اینکه کدوم بهتر است.
ولی این کدهایی که می بینی تا به حال تمیزترین و بهترین کدهایی بوده که نوشتم. (از نظر خودم)
می تونی کدهای قبلی من رو بفرستم ببینی که احتمالا از نظر شما اونها خیلی بهتر هست چون از مفاهیم object-oriented - namespace - template و خیلی چیزهای دیگه استفاده شده همراه با اسم های کامل و همه اون چیزهایی که برنامه نویس های آکادمیک دوست دارند.
دلیل هاشم که چرا اینجوری می نویسم و کامنت های بی مورد و الکی نمی نویسم زیاد هست بعضی هاشو تو همین تاپیک توضیح دادم بقیه هم اگه علاقه داشتی توضیح می دم. ولی من این کد هارو سریعتر می نویسم، سریعتر باگ می گیرم و همینطور راحتتر می تونم maintain کنم و چیزی بهشون اضافه یا کم کنم بدون اینکه درگیر اسم و فایل و کلاس و ارث بری و درگیری های دیگه باشم.

من کلا بیشتر از سبک برنامه نویسی برنامه نویسهای unix و همینطور linus torvalds پیروی می کنم.
این هم guideline اش :
https://www.kernel.org/doc/Documentation/CodingStyle

و quote ای از linus راجع به نام گذاری :



C is a Spartan language, and so should your naming be. Unlike Modula-2
and Pascal programmers, C programmers do not use cute names like
ThisVariableIsATemporaryCounter. A C programmer would call that
variable "tmp", which is much easier to write, and not the least more
difficult to understand.



در هر صورت آخر بر می گرده اینکه شما مفاهیم و فلسفه کد زنی C++‎‎‎‎‎ رو بیشتر دوست داری یا C و برنامه نویس های unix ای رو. چون سلیقه این دو گروه کاملا با هم فرق داره. کسانی که مفاهیم C++‎‎‎ و شی گرایی رو بیشتر علاقه دارند کدهای موتور irrlicht و ogre رو پیشنهاد می کنم مخصوصا irrlicht که خیلی خوندنش آسون هست. یا در پروژه های ایرانی موتورهای kge و seganx که جفتشون C++‎ و تمیزتر و خواناتر از کدهای من هستند.


برای رندر از تعداد زیادی نزدیک 20 ترد استفاده شده بود که اگر درست باشه برام سواله که این تعداد ترد دقیقا چه کاری رو انجام میدن؟
سوالات دیگه ایی هم دارم که در پستهای بعد میپرسم.
اشتباه می کنی. در حال حاضر انجین اصلا multi-thread نیست و فعلا فقط یک thread درست می کنه اون هم در نسخه development اش برای وب سرور (دیباگ، پروفایلر...). در نسخه 0.5 مالتی ترد به صورت گسترده پیاده خواهد شد. احتمالا اون ترد هایی که دیدی تو دیباگر ویژوال استودیو بوده که کتابخانه هایی ویندوز مثل socket و اینها درست می کنند.

[HasanP2P]

فرض کنید من به عنوان یک برنامه نویس ++C/C الان قصد دارم که انجین شما رو که (اپن سورس) هست گسترش بدم و طبق معمول یک انتظار منطقی و درستی از انجین شما دارم و اون اینه که کدها خوانا (برای من) و کامنت کافی داشته باشه (باز هم برای من و اشخاص دیگه ایی غیر از خود شما) مثل تمام پروژه های موفق اپن سورس باشه. ولی وقتی کدهارونگاه میکنم متوجه میشم که انتظاری که داشتم درست نیست. یعنی شما "بیشتر برای کامپایلر کد نوشتی تا برای من گسترش دهنده". بعد شما دلیلی میاری مبنی بر اینکه کدها استایل linux ـی دارند اما شما پیش بینی کردید که آیا گسترش دهندگان هم این سبک و استایل رو قبول دارند یا نه؟
نهایتا میخوام بگم که شاید کدتون کارایی بیشتری داشته باشه نسبت به نمونه تمیزتر (که باز هم نمیشه با اطمینان گفت حداقل تا زمانی که کاملا دو نمونه پروفایل بشه و کامل بررسی بشه) اما باید یک بالانسی هم بین تمیزی و کارایی باشه که گسترش دهنده ترقیب بشه در غیر اینصورت میشه گفت شما یک مخزن اپن سورس رو بیخود و بی جهت اشغال کردی.
در رابطه با کامنت گذاری هم که ارتباطی با کارایی نداره باز هم شما صرفه جویی کردی!
من قصد گسترش انجین شما رو دارم و توان این کارو هم دارم حتی در شرایط حال حاضر ولی حق خودم دونستم که به عنوان گسترش دهنده این سوالات و درخواست هارو از شما بکنم و مطمئنن اگر قانع بشم انجین شمارو گسترش خواهم داد.

[سپول]

به به، یک برنامه نویس اصیل دیگه ...


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


من قصد گسترش انجین شما رو دارم و توان این کارو هم دارم حتی در شرایط حال حاضر ولی حق خودم دونستم که به عنوان گسترش دهنده این سوالات و درخواست هارو از شما بکنم و مطمئنن اگر قانع بشم انجین شمارو گسترش خواهم داد.

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

[HasanP2P]

آقا چرا ناراحت میشی. من فقط یه چیزی لفظی گفتم وگرنه به قول معروف مال پدرم که نیست اصلا هرکی یه مخزن باید واسه خودش داشته باشه.(به من چه مربوطه)
من میخواستم یه کمکی کنم که به نظر شما نیازی به کمک نداری.
آقا بد نگفتم که, میگم یکم خوانا تر بشه حداقل یه نفر (خودم) حاضرم گسترشش بدم یعنی احساس میکنم ارزششو داره که گسترش پیدا کنه ولی گویا جواب شما اینه : همینی که هست!
در کل سلاح مملکت خویش خسروان دانند. امیدوارم که موفق باشید و کارتون خوب پیش بره. عذر خواهی میکنم اگر ناراحتتون کردم. دیگه هیچ حرفی برای گفتن ندارم چون فکر میکنم تاپیک منحرف میشه.

[UfnCod3r]

اقا من دمو وین رو دان کردم .
FPS 22 بود :متعجب:
گرافیکمم Geforce GT 520
باوا من با همین گرافیک بازی ها می کنم.

درضمن میشه یکی موتور رو برا MSVCPP10 کامپایل کنه .:قلب:
این کامپایلر اینتل رومن نتونستم بگیرم .:ناراحت:
GCC و .. هم نمیخوام .

@HasanP2P (http://barnamenevis.org/member.php?285184-HasanP2P)
اره انصافا یکم نا مفهومه ولی اگه کامنت خوبی داشته باشه بهتر میشه .
البته من خودم هیچی رو با سی++ عوض نمیکنم وگرنه با کله می رفتم سمت drak-hamer . بهر حال هرکس ی علاقه ای داره دیگه
حالا شما همچین میگی کد ها نامفهومه انگار اگه کد های هرموتوری رو ببنی در جا می فهمی .:قهقهه: :لبخند: :بامزه: :چشمک: :لبخندساده: :شیطان: :قلب:

ببخشید من وارد بحث مهندسین گرامی شدم :خجالت: :لبخند:

[سپول]

یک دلیل اصلی که سرعت پایینی داری کارت گرافیکت هست که ضعیف ترین کارت در سری خودش هست. و برای deferred rendering مناسب نیست.
مورد دیگه مربوط به اون مدل مجسمه هست که هر کدوم 60 هزار مثلث دارند و اصلا بهینه نیستند. حالا این رو اگه با سایه رندر کنی چیزی حدود 2 میلیون مثلث در هر فریم می کشه که واسه این صحنه بسیار زیاد هست.
در هر صورت نسخه بعدی بسیار بهینه تر خواهد بود به خاطر متدهای جدیدی مانند occlusion culling و lod که دارم پیاده می کنم.
یک نگاهی به کارتت در مقایسه با بقیه بنداز :
http://www.videocardbenchmark.net/gpu.php?gpu=GeForce+GT+520
شما فعلا می تونی فایل test-win.json رو ادیت کنی و رزولوشن رو بیاری پایینتر

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

کدهای موتور هم دلیل اصلیش که نا مفهوم هست اینه (که چند بار گفتم) با C نوشته شده و برنامه نویس های C++‎‎‎ عادت ندارند. یک دلیل دیگه هم اینه که مثل بیشتر موتورهای سورس باز انجین "آموزشی" نیست و باید حرفه ای عمل کنه. در نتیجه مفاهیم معمول در اون جور دیگه پیاده شده. یک نگاهی به کدهای doom3 یا quake3 بندازید متوجه می شوید چی می گم.
در مورد داکیومنت هم خوب معلومه هنوز داکیومنت نداره... نسخه هنوز به 0.5 هم نرسیده ... کامنت ها هم فقط به درد خودم می خوره که بتونم جاهای مختلف کد رو پیدا کنم. کامنت هایی doxygen یا مربوط به اینترفیس بعد از نهایی شدن یک سری چیزها باید نوشته بشه. و گرنه هر تغییری که بدم باید هر روز داکیومنت عوض کنم.

[سپول]

به اتمام نسخه 0.4.0 نزدیک می شم و یک ویدیو دیگه از یکی از امکانات جدید این نسخه رو گذاشتم :

ویدیو اول مربوط به تولید محتوا و سیستم بارگزاری اتوماتیک هست.
توی آپارات هم گذاشتم ولی بهتره اگه می تونین ویدیو utube رو ببینید چون کیفیت بهتری داره (HD) :
http://www.aparat.com/v/RgWx1
https://www.youtube.com/watch?v=exOkFoyiCb0

ویدیو دوم هم در مورد occlusion culling با استفاده از cpu و SSE ، برای حذف اشیائی که دیده نمی شه:
http://www.aparat.com/v/8b1UY
https://www.youtube.com/watch?v=Onvsn-N7Ruk

بزودی باینری نسخه 0.4.0 هم آپلود می کنم.

[SeganX]

آقا دمت گرم
خیلی عالیه
اینکه گذاشتی تو آپارات هم خیلی خوبه. درسته که کیفیتش خیلی پایین تره ولی میشه دید.
منتظر باینری ها هم هستیم

[saied_hacker]

1- دوست عزیز اگه منابعی رو که معمولا ازشون استفاده کردی/میکنی رو بگی ( میدونم یه جای خاص نیست اما معمولا یکسری جاهیا خاص وجود دارن دیگه ) ممنون میشیم :)
2- حدودا چقدر زمان براش گذاشتی

( توی پست اول بگی چه بهتر همه ببین )
ممنون

[UfnCod3r]

خیلی عالی بود :کف::تشویق:
الان ک همه قند شکناخرابه نمیشه رفت یوتیـــــــــــــــــــــ می تونین با این سایت فیلمو دانلود کنید و ببنید dirpy.com
اگه میشه برای این نمونه جدید ی محیط خیلی بزرگ با کلی مدل و .. درست کن occlusion culling هم ک داری بزار ببینیم چطور می شه :لبخند: مدل هم ک زیاد داری :چشمک:

[mohammadali1375]

ایول خیلی خوشم اومد :لبخند:
راستی این occlusion culling رو سطوح غیر مسطح هم (مثل terrain ) هم به همین خوبی جواب میده ؟
این لود اوتوماتیک , اوتوماتیک بودنش یه طرف سرعتش منو کشته :لبخند:

[alimka]

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

[سپول]

دوست عزیز اگه منابعی رو که معمولا ازشون استفاده کردی/میکنی رو بگی ( میدونم یه جای خاص نیست اما معمولا یکسری جاهیا خاص وجود دارن دیگه ) ممنون میشیم
منبع اصلی جدی google بوده.

بقیه منابع :
http://www.opengl.org/wiki/Main_Page
DirectX SDK documentation

کتابهای زیر هم پیشنهاد می کنم:
Math Primer for game developers
GPU Gems 3
Game Engine Architecture

منابع جزئی برای الگوریتم ها، یا کد رو در خود کد بصورت comment لینکش رو نوشتم.
ولی اصل قضیه google هست. کافیه بدونید چی می خواهید و دنبالش بگردید.


حدودا چقدر زمان براش گذاشتی
این پروژه تقریبا 1 سال هست که استارت خورده، ولی 4-5 ماه اول سرعت کمی داشت از اونجا که بیشتر روی انجین قبلی کار می کردم و همینطور پروژه های دیگه ای داشتم.
ولی شاید 6 سالی هست که در این زمینه تجربه و مطالعه می کنم. خیلی از الگوریتم ها، طراحی انجین و متد ها رو از قبل نوشته بودم یا می دونستم.


اگه میشه برای این نمونه جدید ی محیط خیلی بزرگ با کلی مدل و .. درست کن occlusion culling هم ک داری بزار ببینیم چطور می شه مدل هم ک زیاد داری
اون مدل هایی که لینکش رو دادی رو هنوز نتوستم دانلود و ازشون استفاده کنم، در نسخه بعدی سعی می کنم از اونها هم استفاده کنم، متاسفانه اکانت rapidshare ام تموم شده.
برای دموی 0.4 یک اسکریپت نوشتم که تعداد بیشتری مدل و نور رو ادغام می کنه و محیط بزرگتر هست. اما هنوز تنوع مدل ندارم، و همینطور مدل ساز با من همکاری نمی کنه که بتونیم یک محیط واقعی درست کنیم. فعلا تست هام رو با نوشتن اسکریپتهای ساده انجام می دم.


راستی این occlusion culling رو سطوح غیر مسطح هم (مثل terrain ) هم به همین خوبی جواب میده ؟
بله، تنها نکته occ culling اینجاست که مدل ساز باید یک مدل بسیار low-poly از مدل درست کنه، برای terrain مثلا می تونه به جای تپه و کوه حتی یک مکعب بگذاره ... مدل سازی برای occ culling به قدری راحته که یک برنامه نویس هم می تونه انجام بده.
یک نکته مثبت middle-ware هایی مثل umbra3 اینه که مش های occ culling رو به صورت اتوماتیک درست می کنند (اگر 10 هزار دلار می خواهید خرج کنید)


داداش یه خروجی هم میگرفتی یا لااقل تو یه فایل زیپ کلشو واسه دانلود میزاشتی تا بشه ازش استفاده کرد
خروجی به صورت باینری تا دو روز دیگه آماده می شه. اما سورس کل پروژه هم در دسترس هست، می تونید خودتون هر موقع بگیرید، کامپایل کنید و نتیجه رو ببینید.

[orache]

سلام خیلی حال کردم
فقط 2 تا سوال البته شاید کمی خنده دار به نظر برسه
1 - اون کنسول رو چجوری ساختی همون که بهش دستور میدی رو ؟
2 - اون خط های کمکی رو همون خط های شطرنجی رو با چه دستوری ساختی ؟؟ با line ؟ بعدا وقتی حرکت میکنی واسه تو پرش نداره اونی که من یک الگوریتم براش نوشتم که با line درست شده خیلی خیلی میلرزید اصلا خط هاش موج مینداخت توش اگه میشه بگو چجوری ساختی
ممنون

[UfnCod3r]

@سپول
اقا می گم شما ک همه چی اضافه کردی ی سیستم LOD هوشمند هم درست کن براش :تشویق: ن ازینا ک طرف باید بره توی 3 دی مکس و ازمدلش چند تا با کیفیت های مختلف بسازه
مثلا توی یکی از سمپلهای نسخه جدید OGRE اگه دیده باشی طوریه ک بر اساس فاصله راس ها ادقام میشه مثلا 10 تا مثلث کنار هم رو می کنه 1 مثلث طوری ک تکسچر و .. هم بهم نریزه
اگه اینو هم ب موتورت اضافه کنی دیگه عالی میشه:کف:
راستی شما قصد اضافه کردن فیزیک و صدا رو هم داری یا فقط می خوای رو رندر کار کنی ؟:متفکر:

[orache]

dark hammer engine نوشته انجینه اگه برای رندر بود میشد render ware حالا نمیدونم ولی به اسم که باید شامل تمامی چیزای یک انجین باشه

[سپول]

اقا می گم شما ک همه چی اضافه کردی ی سیستم LOD هوشمند هم درست کن براش ن ازینا ک طرف باید بره توی 3 دی مکس و ازمدلش چند تا با کیفیت های مختلف بسازه
این تکنیک الان پیاده سازی شده و با باینری خواهید دید.


dark hammer engine نوشته انجینه اگه برای رندر بود میشد render ware حالا نمیدونم ولی به اسم که باید شامل تمامی چیزای یک انجین باشه
عجله نکن. تو نسخه 0.5 فیزیک و پارتیکل سیستم هم اضافه می شه.


اون کنسول رو چجوری ساختی همون که بهش دستور میدی رو ؟
چیز خاصی نداره، موتور یک سیستم رسم دو بعدی داره که باهاش فونت، مستطیل و این چیزها رو می کشی. (gfx-canvas) بقیه اش می شه برنامه نویسی UI ساده. برای مطالعه بیشتر سورس های فایل های console.c و debug-hud.c رو یک نگاه بنداز.


اون خط های کمکی رو همون خط های شطرنجی رو با چه دستوری ساختی ؟؟ با line ؟ بعدا وقتی حرکت میکنی واسه تو پرش نداره اونی که من یک الگوریتم براش نوشتم که با line درست شده خیلی خیلی میلرزید اصلا خط هاش موج مینداخت توش اگه میشه بگو چجوری ساختی
با line هست. اون جدول رو با یک الگوریتم ساده مختصات خط ها رو مثلا با واجد 5.0 گرد می کنید. یعنی مثلا مختصات شروع خط باشه 3.5، 0، 0 . این مختصات تبدیل می شه به 5.0، 0، 0.
باز هم باید کد رو بخونی، فایل gfx-canvas.c تابع gfx_canvas_grid.

[orache]

اها یه سوال دیگه تو اصلا از کتابخانه ی sdl برای ساخت انجین استفاده کردی یا نه ؟؟

[سپول]

اها یه سوال دیگه تو اصلا از کتابخانه ی sdl برای ساخت انجین استفاده کردی یا نه ؟؟
نه، از sdl یا چیز دیگه ای استفاده نشده
ولی برای رابط کاربر ابزارها کلا از Qt و Python و شاید .NET (که کاربر amiv.v در حال کار و تحقیق روش هست) استفاده خواهد شد.

[سپول]

نسخه 0.4 هم آماده شد. این نسخه بیشتر بر روی سرعت و متدهای بهینه سازی تمرکز داشت.
تغییرات جدید در این نسخه :


occlusion culling: متدی کاملا داینامیک و بهینه سازی شده توسط SSE4.1 (و قابلیت اجرا بر روی پرادزشگر های پایین تر و AMD که SSE4 ندارند) برای حذف اشیائی که دیده نمی شوند. (ویدیو: http://www.aparat.com/v/8b1UY)
Uniform grid partitioning: متدی برای تقسیم بندی صحنه به قسمت کوچکتر جهت مدیریت سریعتر روی اشیاء.
Discrete LOD: تغییر کیفیت و یا رندرینگ اشیاء (نور، مدل، ...) براساس فاصله تا دوربین، با امکان تعریف scheme های مختلف برای دسته ای اشیاء.
Hot-loading: پردازش و لود اتوماتیک تمامی resource ها (مدل، اسکریپت، تکسچر ...) در صورت تغییر فایل اصلی (ویدیو: http://www.aparat.com/v/RgWx1)
بهینه سازی سیستم اسکریپت با lua
شروع بایندینگ برای زبان python برای گسترش بهتر موتور و ساختن ابزارها با رابط کاربری


باینری برای ویندوز هم آماده هست و بر روی کارت ATI 5950، و پردازشگر Intel Core2 Quad تست شده (خواهشا با سخت افزار ضعیف مخصوصا کارت گرافیک های intel اجراش نکنین) :
http://hmrengine.com/demos/dark-hammer-0.4.0-win-x86-bin.zip

ویدیو جدید هم آپلود کردم که ابزار پروفایل و مانتیورینگ حافظه رو نشون می ده :
http://www.aparat.com/v/CXS7U

در دمو، یک اسکریپت سنگین رو اجرا می کنم که حدود 150 مدل رو در یک مسیر محاسبه می کنه و حرکت می ده . این کار در اصلی به عهده خود انجین باید باشه (که هم سرعت بیشتر داشته باشه و هم درون یابی صورت بگیره جهت روان حرکت کردن). ولی با اسکریپت انجام دادم برای استرس گذاشتن و تست اسکریپت ها.

کد اسکریپت که در دمو می بینید به شکل زیر هست :



core.printcon("loading scene ...")

s = eng.scene()
s:clear()

s:createModel("ground", "test-data/plane.h3dm")

-- place houses on the elipse
house_cnt = 30
delta = 2*math.pi/house_cnt
alpha = 0
for t=1, house_cnt do
x = 100*math.sin(alpha)
z = 20*math.cos(alpha)
h = s:createModel("house" .. t, "test-data/house.h3dm")
h:move(x, 0, z)
h:rotate(0, core.randRangeFloat(0, 360), 0)
alpha = alpha + delta
end

path = {
core.vec3(-62.400684, 9.764269, -30.181873),
core.vec3(-22.908751, 5.574275, -36.407116),
core.vec3(12.721034, 7.617999, -32.171288),
core.vec3(25.004932, 6.156801, -41.141724),
core.vec3(51.172447, 5.933318, -28.525585),
core.vec3(93.80822, 4.819061, -33.434326),
core.vec3(124.887253, 6.7191, 5.68144),
core.vec3(97.621857, 10.731023, 23.264616),
core.vec3(15.508122, 10.229074, 30.396282),
core.vec3(-59.962864, 4.42202, 37.74939),
core.vec3(-105.928719, 9.922335, 17.078924),
core.vec3(-122.609703, 6.607499, -7.886065)
}

objects = {
"test-data/barrel.h3dm",
"test-data/wagon.h3dm",
"test-data/booth.h3dm"
}

length = 60
frame_cnt = 12
update_interval = 16
ft = length/frame_cnt
pos = core.vec3()
objmap = {}

function get_nextframe(frame, cnt)
r = (frame + 1) % (cnt + 1)
if r == 0 then
r = 1
end
return r
end

function get_random_color()
c = 255*core.randFloat() + 128
if c > 255 then
c = 255
end
return c
end

-- move objects along the path (timer event)
function follow_path(id)
local ent = objmap[id]
local obj = ent[1]
local t = ent[2]

t = math.fmod(t, length)
local frame = math.floor(t/ft) + 1
local prev_frame = frame - 1
if prev_frame == 0 then
prev_frame = frame_cnt
end

local next_frame = get_nextframe(frame, frame_cnt)
local next_frame2 = get_nextframe(next_frame, frame_cnt)

local i = (t - ((frame - 1)*ft))/ft
obj:move(pos:cubic(path[prev_frame], path[frame], path[next_frame], path[next_frame2], i))
t = t + (update_interval/1000)
ent[2] = t
end

-- create objects with a timer
obj_cnt = 0
obj_max = 150
function spawn_object(id)
obj_cnt = obj_cnt + 1

local toss = core.randRangeInt(1, 100)
if toss > 92 then
obj = s:createModelLod("statue" .. obj_cnt, "test-data/statue.h3dm", "test-data/statue-md.h3dm", "test-data/statue-lo.h3dm")
else
if toss > 75 then
obj = s:createPointLight("light" .. obj_cnt)
obj:setcolor("light", "color", get_random_color(), get_random_color(), get_random_color(), 1)
obj:setf("light", "atten_far", 5)
obj:setf("light", "intensity", 2)
else
objfile = objects[core.randRangeInt(1, 3)]
obj = s:createModel("obj" .. obj_cnt, objfile)
end
end

-- spawn at start path and random rotation
obj:move(path[1])
obj:rotate(core.randRangeFloat(0, 360), core.randRangeFloat(0, 360), 0)

if obj_cnt >= obj_max then
eng.removeTimer(id)
end

local tid = eng.addTimer(update_interval + core.randRangeFloat(0, 6), "follow_path")
local ent = {[1]=obj, [2]=0, [3]=light}
objmap[tid] = ent
end

eng.addTimer(1000, "spawn_object")

eng.setSunDir(1, -0.5, 0)
eng.setSunIntensity(0.8)




برای اطلاعات بیشتر در مورد API اسکریپت به این لینک بروید (که به مرور کاملتر می شه) :
https://bitbucket.org/sepul/dark-hammer/wiki/lua-reference-guide.wiki

[orache]

یه سوال داشتم
میدونی این انجین های خارجی رو چند نفره ساختن ؟؟ مثلا همین ogre 3d یا irrlicht یا idtech اینا رو چند نفره ساختن ؟؟
موتور بازی سازی dark hammer قدرت ساخت یک بازی fps رو داره یا نه ؟؟

[سپول]

موتور dark-hammer "قراره" که واسه همین سبک ساخته بشه، بر خلاف انجین های سورس باز generic مثل همین ogre، من خیال دارم سبک رو محدود کنم و تمرکز رو روی همین سبک بگذارم تا بشه بهتر بهینه سازی کرد. ولی همونطور که می بینی تازه اول راهه

[orache]

من ولی هنوز موندم چجوری میشه چند نفره موتور رو ساخت مثلا 20 نفر پای یک انجین ؟؟ هرکی باید کد رو خودش بنویسه تا بفهمه چی نوشته دیگه مثلا اگه یک نفر شیدر رو بسازه یک نفر مثلا کل برخورد و فیزیک رو اینا رو چجوری میتونن با هم ارتباط برقرار بدن ؟؟
.
راستی لول ادیتور موتور رو چی ادیتور سیمرغ رو 1 نفره ساختن ولی فکر نکنم ادیتور انجین هایی مثل udk و frostbite رو یک نفره ساخته باشین اطلاعاتی داری ؟؟
اکثر انجین ها رو برای ساخت بازی استراتژی میذارن فکر کنم چون قدرت گرافیکیشون کمه درسته ؟؟
.
تو میخای موتور رو برای بازی fps درست کنی اونوقت opengl یک خورده برای این کار ضعیف نیست ؟؟ یه تحقیقی که 5 دقیقه ای انجام دادم تمامی انجین ها یا با دایرکت ساخته شدن یا با دایرکت و جی ال فکر نکنم جی ال به تنهایی کیفیت داشته باشه http://content.gpwiki.org/index.php/Game_Engines
میشه با دایرکت ایکس یک نفره کار کرد ؟ تا اینجای کار رو تکی رفتی درسته تا اخر میخای یک نفره کار کنی سر خود انجین یا نه ؟؟
ببخشید که اینقدر سوال شد ولی میدونین انجین های بزرگ مثل یو دی کا و یا یونیتی رو چند نفره ساختن ؟؟
ممنون

[UfnCod3r]

تو میخای موتور رو برای بازی fps درست کنی اونوقت opengl یک خورده برای این کار ضعیف نیست ؟؟

ارسال اول رو بخون گفته با DX11 , OGL3
فکر کنم اینجا جای بحث دایرکت خوبه یا جی ال نیست :لبخندساده:

[سپول]

DirectX و OpenGL بحثش اول تاپیک بود. اونها رو بخون.

[orache]

فکر نکنم OpenGl به پای direct x برسه تقریبا اکثر انجین ها با دایرکت ایکس ساخته شدن و همه ی بازی هارو دایرکت ایکس پشتیبانی میکنه و سخت ابزار های گرافیکی رو هم همچنین direct x و مکمل اون یعنی nvidia ساپورت میکنه ولی microsoft تو کارش اوله فکر نکنم کسی به پاش برسه
ببین اینجا دیگه نمیتونم حرف بزنم چون به موتور dark hammer مربوط نمیشه پ خ میدم
ممنون

[سپول]

لطفا سوالات مربوط به انجین رو اینجا مطرح کن و سوال های دیگه رو بگذار واسه تاپیک های دیگه.

[orache]

ببخشید این اخرین حرفی که دارم تو این تاپیک میزندم (ربطی به عنان نداره )
مایکروسافت تو هیچ کارش جز xna اخر نیست
تو IDE حرف اولو میزنه .. تو زبون برنامه نویسی حرف اولو میزنه ... تو ساخت قطعات کامپیوتری و سخت ابزاری حرف اولو میزنه تو ریزپردازنده ها حرف اولو میزنه کلیات سیستم PDA و PPC رو مایکروسافت راه انداخته .. بهترین و کمسوخت ترین کنسول بازی سازی رو مایکروسافت ساخته .. بهترین و پرطرفدار ترین API گرافیکی رو مایکروسافت ساخته API ای که حداکثر 4 درصد از سی پیو استفاده میکنه ... از نظر رندر هم با API مایکروسافت (DIRECT ) حرف اولو میزنه این حقیقت تو نرم افزار های 3DSMAX و MAYE و انجین بازی سازی UDK و S2 کاملا پیداست
ممنون

[SIAMKOGAMES]

سلام اولین پست من تو این سایت بد از 6 سال......

باید گفت کار شما بسیار جای قدر دانی و حمایت رو داره اما چون اینجا ایرانه ما از شما قدردانی میکنیم و آرزوی

بهترین ها برای شما...ای کاش بچه های 3D هم اینجا بودن شما ها رو حمایت میکردن....:لبخندساده:

[سپول]

ویدیو جدید در مورد تست های اولیه فیزیک در موتور dark-hammer :
هم اکنون پایه اولیه فیزیک تموم شده، rigid body (فیزیک اجسام صلب) به طور کامل پیاده شده ؛ همراه با بایندینگ های اسکریپت، کامپوننت و export و import مش های collision و مشخصات rigid body.
موتور فیزیک physx 3 هست و چون abstract شده امکان اضافه و عوض کردن موتور فیزیک هم در آینده وجود داره.

آپارات: http://www.aparat.com/v/rxoy8
یوتیوب: https://www.youtube.com/watch?v=EhOq-hct-Ek

[سپول]

آپدیت جدید برای موتور dark-hammer :


نسخه اولیه وبسایت موتور راه افتاد : http://www.hmrengine.com/
انجین به نسخه 0.4.6 ارتقا پیدا کرده و ساختاری کاملا multi-platform داره
موتور فیزیک Physx3 همراه با پشتیبانی از اجسام صلب
Attachment ها برای چسباندن اشیاء (فیزیکی و غیر فیزیکی) به یکدیگر
Trigger ها و امکان استفاده از آنها در اسکریپت
از تغییرات بنیادی در کد عوض شدن سیستم build از CMake به Waf هست
ساپورت پلتفرم Mac OSX. هم اکنون موتور قابل کامپایل و اجرا روی پلتفرم های linux، windows و OSX می باشد.


در ضمن دو برنامه نویس دیگه وارد پروژه شدند، از اونجا که این پروژه هنوز به نسخه اول هم نرسیده و باعث جذب برنامه نویس های علاقمند شده (بدون ساپورت مالی) دمشون هم گرم :


امین ولینژاد: که عضو همین فروم هم هست و هم اکنون در حال ساختن پورت .NET این موتور و همینطور کار بر روی طراحی و پیاده سازی یک سری ابزارهای گرافیکی هست که در وبلاگ می تونید پروسه کار رو دنبال کنید. https://bitbucket.org/Amin67v/sharphammer
دیوید باشت: برنامه نویسی فرانسوی که حدود 2 ماه پیش وارد پروژه شد و موتور رو به OSX پورت کرد، همواره هم کار می کنیم با هم که اشکالات جزئی رو در OSX بگیریم.

[orache]

شاید باورت نشه سپول ولی من امروز صبح به سایت انجین سر زدم دیدم هنوز همونطوری مونده بعد از گذشت چندین ماه 1 روز نشده اپدیت شد ممنون دمت گرم
راستی میشه از تمامی کد های انجین استفاده کرد ؟؟ یعنی میتونم کد هاشو عوض کنم و به موتور خودم پیوند بدم ؟؟ البته موتور که نه یک چیز کوچیک که 20 هزار خطم براش کد ننوشتم هنوز اره میشه این کار رو کرد ؟؟ البته برای جاذبه فیزیک دارم که بولت باشه ولی فکر کنم فیزیک تو انویدیاست
راستی اون ادیتور که همون اول بلاگ هست رو با mfc ساختی ؟؟
در ضمن اون عکسی که از گذاشتی رو عوض کن چون اصلا به صفحه ی اول انجین نمیاد http://www.hmrengine.com/#

[سپول]

شاید باورت نشه سپول ولی من امروز صبح به سایت انجین سر زدم دیدم هنوز همونطوری مونده بعد از گذشت چندین ماه 1 روز نشده اپدیت شد ممنون دمت گرم
راستی میشه از تمامی کد های انجین استفاده کرد ؟؟ یعنی میتونم کد هاشو عوض کنم و به موتور خودم پیوند بدم ؟؟ البته موتور که نه یک چیز کوچیک که 20 هزار خطم براش کد ننوشتم هنوز اره میشه این کار رو کرد ؟؟ البته برای جاذبه فیزیک دارم که بولت باشه ولی فکر کنم فیزیک تو انویدیاست
راستی اون ادیتور که همون اول بلاگ هست رو با mfc ساختی ؟؟
در ضمن اون عکسی که از گذاشتی رو عوض کن چون اصلا به صفحه ی اول انجین نمیاد http://www.hmrengine.com/#


مرسی
اون ادیتور با .net نوشته شده که امین ولینژاد ساخته

[orache]

میشه لطف کنین یک نشانی چیزی از این امین ولنژاد به من بدین ؟؟ خیلی ممنون

[SeganX]

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

[emadacx]

سلام

من وقتی می خوام انجین رو با (4.2) gcc کامپایل کنم، خطا میده که اعلان متغیر ها تو حلقه for فقط تو C99 مجازه!
می دونید مشکل از کجاست؟



----------------------------------------------
و میشه بگید منظورتون از linux developer community کدوم انجمن بود؟
چون من که سرچ کردم هزارتا انجمن لینوکس بود!!!

[سپول]

من وقتی می خوام انجین رو با (4.2) gcc کامپایل کنم، خطا میده که اعلان متغیر ها تو حلقه for فقط تو C99 مجازه!
می دونید مشکل از کجاست؟
باید با


-std=gnu99

کامپایل کنی.
اگه همون فایل readme رو که اینجا هست :
https://bitbucket.org/sepul/dark-hammer

بخونی، باید موتور رو با سیستم waf بیلد کنی، خودت بصورت دستی با gcc کامپایل نکن چون دهنت سرویس می شه.

منظورم از linux developer community همون جامعه برنامه نویسهای لینوکس هست، سایت خاصی نیست.