السلام عليكــم ورحمـة الله وبركاتــه
 
اعتذر ان كان الموضوع ليس مكانه المناسب






هذه النسخة تجريبية .. وحافلة بالأخطاء .. وتحتاج للاختبار على أكثر من جهاز (Hardware ) وعلى أكثر من نظام ( حاليا Windows) وعلى أكثر من مترجم ( حاليا VC6 - VC8 - VC9 ), كما تحتاج لعدد من التطبيقات (Demo) و الألعاب, وهذا ما سيتم في النسخة النهائية 0.1 final realse فضلت نشر هذه النسخة الان , لأني لا أملك الوقت لتطوير شيء حتى انتهاء الدراسة.

جميع ما سأذكره هنا هو موجود في ال Manual مع المحرك , بالتفصيل
---------------------------------------------------------------------------------------------------------------------------------

تحميل المحرك

http://code.google.com/p/atomic-engine/


شكرا جزيلا لكل من ساعدني من أعضاء :
الفريق العربي للبرمجة
الشبكة العربية لمطوري الألعاب

الهدف :

ليس الهدف من المحرك منافسة Irrlicht أو Ogre بكل تأكيد , إنما هو هدف تعليمي ( وأحد خيارات مشروع التخرج ان شاء الله ) .

ماوراء الأكمة :
 
اسم المحرك كان من اقتراح أحد الزملاء في الثانوية قبل سنوات ( الغامدي) ..طلبت منه اسم للمحرك فاقترح اسم Atomic حيث تلك الكلمة كانت للتو ضمن مقررنا الدراسي في اللغة الانجليزية .. طبعا كان الاقتراح على سبيل التهكم ..


خصائص و مميزات المحرك :
للاطلاع على امكانيات المحرك ( لا توجد مميزات الان .. ) .. قم بالتوجه الى المجلد bin الموجود داخل مسار المحرك .. وقم بتشغيل التطبيقات الواحد تلو الاخر .. ,
نظام التشغيل :
Windows XP ( نظامLinux بالإمكان دعمه ولكن لانعدام خبرتي في هذا النظام , جعل من الصعب تطوير نسخة له, كل ما يحتاج المحرك للعمل على Linux هو توفير المكتبات مثل Devil - freetype الخ .. وبعض التعديلات البسيطة في خيارات المترجم وسيكون المحرك بعدها جاهز للعمل على النظام .. أقدّر لأي شخص المساعدة في هذه النقطة )
المترجم :
( تم تجربة المحرك على Visual Cpp 6 و Visual Cpp 8 و Visual Cpp 9 وهو يعمل بدون مشاكل ..بالنسبة للمترجم VC6 يظهر الكثير من التحذيرات .. بسبب تقادم المترجم ..وعدم تحديث المكتبات مثلSTL ) , المترجم GCC غير مدعوم حاليا
المحرك يعتمد على مفهوم OOP في تصميمه, ويعتمد على نوعين من Design Patterns : Factory , Singleton .
القراءة والكتابة من والى الملفات , ودعم ال Serialization بشكل مبسط .

إمكانيات الرسم:
- رسم الأشكال الأساسية بالإضافة إلى رسم الأشكال المعقدة , الألوان... الخ...
- دعم الشفافية وازالة الالوان الغير مرغوب فيها بالاعتماد على عدة تقنيات مثل Color Key , Mask ...
- رسم النصوص , وقراءة ملفات الخطوط ttf.

الاكساء و الصور :
- دعم الإكساء ( البسيط) , دعم عدد كبير من الصور BMP,JPG,TGA,PNG ...

الأصوات:
- تشغيل الملفات الصوتية من نوع wav .
 
 



 







 





 
- الرجاء قراءة المزيد من خلال ملف التعليمات في doc مع المحرك ,
- في حال مواجهة أي مشكلة أو العثور على أي خلل اخباري ومساعدتي ,
- أسعد كثيرا بأي مساعدة من أي شخص ,

أتمنى التعليق والمشاركة ,

هل هناك موقع آخر يمكن تحميل الكود/الأمثلة منه؟
الـ code.google.com الوغد يرفض أن يخدم سوريا 😲  (لأسباب.. احم احم)
(على الأقل sourceforge.net لا يتصرف بهذه الحماقة)

تفضل اخى وسام هذا رابط اخر من رفعي انا 😄 😄
اتمنى يكون شغال عندك 😒
وايضا الرابط لعيون اخوى الشمري😄
http://www.4shared.com/file/76769806/30d2c049/age_v01alpha.html

يشرفني مشاركتك أخي  وسام و Mr-X ,
اعتذر عن التأخر في رفع الملف , وذلك بسبب البطء الشديد في النت خلال الايام الماضية بسبب الكوابل البحرية , حاول تحميله من الرابط الذي رفعه الاخ Mr-X , وسأقوم بكل الأحوال برفع المحرك على Sourceforge حال تحسن النت عندنا ( ان شاء الله)
 
وشكرا على التشجيع 😄

الحمدلله , رفعت الملف ,
https://sourceforge.net/projects/atomic-engine/
 
كان  sourceforge معقدني قليلا ,

السلام عليكم،
 
لقد ألقيت نظرة على ملفات وأمثلة المحرك، وبداية أقول ما شاء الله عمل ممتاز.
 
من أكبر ميزات الكود هو أنه مكتوب بطريقة ناضجة ومتمكنة. المبرمج الذي يهتم بوضع const على البارامترات والإجراءات بشكل صحيح لهو مبرمج جدير بالاحترام حقاً. 😄
 
يبدو واضحاً أيضاً وجود نظام عام يوجه هندسة المحرك، إلا أنني لم أستطع تقدير فكرة الكلاسات المجردة (abstract classes) والتي تشكل الواجهة التي يتعامل من خلالها المستخدم مع المحرك. هذا الفكرة قد تكون جيدة في لغة مثل #C، لكن في ++C فإنها غالباً لا تعني سوى المتاعب. 😖
 
عند النظر إلى كود الأمثلة نجد أنه بسيط، وهو مؤشر على نجاح التصميم.
 
على اعتبار أن هذه النسخة مجرد طرح أولي، فإننا نستطيع نسبة مجموعة من الأسئلة القائمة إلى هذا السبب. لكن لا ضير في ذكر هذه الملاحظات كي لا تسقط سهواً من النسخة النهائية:
 
* كلاس Point2 لا لزوم له في وجود Vector2، فكلاهما يعبر عن نفس المعلومات.
 
* أعتقد أن فكرة إضافة إجراءات virtual إلى كلاس المتجه (Vector2 و Vector3) هي فكرة صعبة الهضم. فأنت تدفع 4 بايتات إضافية لكل متغير من هذا النوع، وطبعاً المجسمات كلها مؤلفة من نقاط متجهات ثلاثية الأبعاد، فلمجسم مكون من ألف نقطة، فأنت تضيف 4000 بايت إلى الـ 12000 بايت الضرورية للتعبير عن نقاط المجسم.
 
* أخطاء تنظيمية طفيفة مثل بعض الكلاسات المكتوبة في ملفات تحمل اسماً لا يدل على المحتوى بشكل دقيق.
 
 
أود أن أسأل، لماذا تعتمد المحركات أكثر من بنية تحتية؟ مثلاً في حالة محركك يا الشمري، لديك D3D و SDL. لماذا؟ ألا يفي أحدهما بالمهمة؟
 
شكراً...

وعليكم السلام ,

لا تعلم مدى السعادة التي أشعر بها , لأني لم أتوقع الاهتمام بالمحرك من شخص عادي فما بالك بشخص متمكّن ( ما شاء الله ) .

-


أحاول أن أعزل المحرك عن الاعتماد على أي مكتبة , فمثلا , توجد واجهة اسمها UImage .. والتي كان بالامكان وضعها كـ ( كلاس) عادي , لكن لأني اعتمدت على المكتبة DevIL حاليا , ولأني سأعتمد على مكتبة أخرى (  شاء الله ) ففضلت تحويلها الى واجهة .. وعمل Implementation جديد في كل مرة أرغب في ذلك , واسحب ذلك على باقي الواجهات ( URender ) حاليا OpenGL ومستقبلا ممكن DX , و UDevice حاليا Win32 API و SDL ومستقبلا ممكن Linux API ..مثلا , وهكذا ,

بمعنى أعتمد كثيرا على ما يسمّى بال Factory و ما شابهها من Patterns , ومتأثر كثيرا بلغة الجافا .

لكن يبدو أني بالفعل أكثرت منها .. حتى ال FileStream عبارة عن واجهة☺ ,

-






ماشاء الله , ملاحظتك دقيقة أخي , وهي أحد الامور التي لم أقتنع بها للأمور التي ذكرتها , السبب الذي جعلني أقوم بذلك هو أن USerializable الواجهة التي من خلالها أعمل Serialization لل Objects عبارة عن واجهة , فأي كلاس يريد دعم Serialization فهو يجب أن يرث هذه الواجهة ويعمل لها Implementation . .  لذلك أنا أمام حلين :

1- أن أغيّر طريقة ال Serialization  ( شرحت لي سابقا الطرق لذلك ).
2- بدلا من أن يرث كل كلاس من USerializable حتى يعمل Implement للدالتين writeObject و readObject .. أقوم باضافة هاتين الدالتين مباشرة على كل كلاس بدون virtual ..  وبالتالي سأتخلص من المشكلة التي ذكرتها في تحليلك , ولكن سأفقد طعم البرمجة الكائنية الموجودة في الجافا و #C !

ولكن سأطبق توجيهاتك ان شاء الله في الاصدار القادم .





بلى , يفي , ولكن أضفت SDL فقط لانظمة التشغيل الأخرى .. حيث في الويندوز يتم الربط بين Win32 API و OpenGL و في الانظمة الاخرى أعتمد على SDL من أجل الربط فقط بين النظام و OpenGL .. ولكن أعترف أن هذه خطوة متقدمة وغير مفيدة الان , ولكن بما أنها سهلة , ففضلت القيام بها . وقس ذلك على باقي أجزاء المحرك ( مثلا توفير بنية تحتية لدعم OpenGLو D3D على حد سواء , أحاول دائما أن أعزل المحرك عن نظام التشغيل و المكتبات الخاصة بنظام تشغيل معيّن حتى أضمن استمرار المحرك مستقبلا .
قد يكون هذا غير مفيد لمحرك صغير , ولكن هو مجرد محاولات , لمحاكات المحركات الموجودة .


بقية نصائحك سأطبقها ان شاء الله في الاصدار القادم ,
جزاك الله خير
😄