تذكير بالأمور المطلوبة الآن مع الطلبات الجديدة:
* الكود الجديد لدعم التحكمات كما يجب، مع دعم الـ gamepad :   سلوان هلالي.
* إضافة وهج أبيض بشكل فلاش متكرر عند جمع آخر جوهرة (كما في الجزء الثاني) :  أحمد عز.
 
أرجو ممن يود أن يستلم مهمة أيضاً في الـ ++C أن يخبرني بذلك الآن...
 
يمكنكم إرسال الكود الجديد لي مباشرة إما كبريد شخصي، أو كمرفقات في الردود، وأنا سأقوم بإدراجها في آخر نسخة وطرحها للبقية.

انا اقوم الآن بقراءة الكود ومحاولة فهمه, لدي سؤال لا يتعلق بالمهام المطلوبة, لماذا تم إستخدام fixed point بدل float؟
يا ترى هل السبب هو تحسين الأداء؟ (معالجاتنا هذه الأيام تستطيع القيام بعمليات float بسرعة جيدة جداً)
أم يمكن لأجل التخلص من مشاكل الـ precision في الـ float؟
 
أيضاً, واجهني مصطلح لم أراه سابقاً, وهو "XFer", من جولة بحث سريعة توصلت إلى شبه إستنتاج إنه يعني "transfer", ولكن يبدو إن هنالك شئ آخر بخصوصه.
 
سأقوم اليوم بتطبيق نظام الإدخال الجديد, ولكن حتى الآن لم أقرر كيفية إرتباطه باللعبة, إما بإستخدام إستدعاءات مبعثرة بشكل مماثل لما هو موجود الآن أم هل من الأفضل تطبيقه بإستخدام نظام Event Based (تطبيق class خاص يمكن الوراثة منه ويتم عن طريقه إرسال أحداث الإدخال للكائنات التي يتم تسجيلها كمستلمات للإدخال Even Listeners), انا متأكد من وجود طرق أخرى قد تكون أفضل بالنسبة لحالتنا هنا, ...
 
بإنتظر إفكاركم بخصوص الموضوع, إن لم أتوصل لطرق أفضل سأقوم بتطبيق إحدى الطريقتين أعلاه بعد أن أنهي قراءتي للكود.

سؤال ممتاز، وإجابتك الثانية هي الصحيحة. تقوم اللعبة بعمل مقارنات مساواة بين قيم الإحداثيات، وكما نعلم فإن هذه المقارنات غالباً ما تكون غير دقيقة في متغيرات float. الأمر الآخر هو أن اللعبة الأصلية طبعاً تم برمجتها على معالج لا يدعم متغيرات float أساساً، لذا فقد تم استخدام fixed على سبيل التكافؤ☺
عندما ننظر إلى هذه التفاصيل، يخطر ببالنا كيف أن المبرمجين السابقين كانوا أذكياء جداً بعكس ما يعتقد بعض الناس بأن تقدمنا التقني يعني أننا أذكى منهم... لكن دعونا من الفلسفة الآن☺

 


نعم بالضبط. XFer تم استخدامها لاختصار عبارة Transfer في بداية أسماء إجراءات قراءة البيانات من الملفات إلى البنى البرمجية في اللعبة.
داخلياً، تقوم إجراءات XFer في مكتبة CoreLib بنداء fread لقراءة معلومات اللعبة من الملفات كما ذكرنا سابقاً. والإخوة في الـ#C سيكون لهم صولات وجولات مع هذه الإجراءات عما قريب إن شاء الله...

 


الأمر بين يديكم تماماً. أرجو أن تتناقشوا فيما بينكم وتعتمدوا الطريقة التي تجدونها مريحة لكم... وأنا هنا أطالع الاقتراحات وسأصوت عليها بنفسي أيضاً☺

السلام عليكم


تم بحمد الله تنفيذ المطلوب وهو يعمل عندى بدون مشاكل سأضع في النهاية بعد شرح الكود في المرفقات الملفات التى تم التعديل فيها

الكود فكرته مأخوذة من الطريقة التى يحدث بها وميض الفلاش لعدة ثوانى كما يحدث عند اختيار أمر من القائمة الرئيسية للعبة

تم اضافة الكود  كالتالى ولمن يريد الشرح سأقوم بذلك:

- في الملف chamber.h تم اضافة الاتى:

// new code
// this code added to the end of the class declaration
private:
	int m_iBlinking;
	// end new code

- في الملف chambers.cpp في الـ constructor

// new code
	m_iBlinking = -1;
// end new code

و فى الدالة void Chamber::Tick(void)

void Chamber::Tick(void)
{
	for (UINT i=0;i<m_lstcollectables.size();i++)>
		m_lstCollectables[i]->Tick();

	// new code
	if (m_iBlinking > 0)
		m_iBlinking--;
	// end new code

	for (DWORD i=0;i<m_agates.size();i++)>
		m_aGates[i].Tick();
}

يمكنكم بمثل الطريقة ايجاد باقي تعديلات الكود فقط عن طريق البحث عن الكلمة الاتية
// new code
حيث ان كل تعديل في الكود قد وضعته كالتالي:

// new code

// new code modification here

// end new code

ان شاء الله سأقوم أخى وسام بارسال الملفات الجديدة للعبة على بريدك والتى تحتوى على التعديل الجديد بعد اضافة الوهج الابيض عند
اخذ اخر جوهرة فى كل مرحلة كما هو المطلوب وأيضا تم الغاء تفاعل اللعبة مع مدخلات المستخدم عندما لا تكون نشطة

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

لدي سؤال. عند بناء الكود وتنفيذ اللعبة، هل لاحظ أحدكم أنها تعمل أبطأ بكثير من النسخة الأصلية التي طرحناها في البداية؟ (هذا ما يحدث لدي هنا على الأقل)
 
ملاحظاتي على ميزة الفلاش الأبيض:
 
* حبذا لو يتم تسريع الوميض وتقصير مدته. أعتقد أن فترة ظهور لثانية واحدة (أو حتى أقل قليلاً) مع تسريع الوميض بمقدار الضعف سيكون أفضل. ترك التأثير يعمل لمدة طويلة قد يجلب الصرع، لذا فلندعه محدوداً قدر الإمكان.
 
* فكرة وضع تعليقات حول إضافاتك الشخصية في الكود ممتازة. وأشجع الجميع على تبنيها، ويفضل توضيح الاسم ضمن التعليق أيضاً لنعرف من غير ماذا.
 
* أعتقد أن وضع الميزة في كود الحجرة ليس بأفضل خيار. بهذا الشكل لن يظهر المؤثر بشكل كامل عند الانتقال بين الحجرات أثناء حدوث الفلاش. كما أن هذا القرار قد يضطرك إلى إجراء تغييرات أكثر من اللازم. أقترح التفكير بوضع الميزة في كود الهرم مثلاً ليعمل في بداية الإجراء Draw وقبل أن يتم نداء إجراءات القص (ChamberClipBegin).
 
* ما هو سبب وضع المتغير m_iBlinking ضمن قسم الـ private؟
 
* طريقة تهيئة قيمة المتغير m_iBlinking تختلف عن طريقة تهيئة بقية المتغيرات في الـ class. لماذا؟
 
* لا داعي لوضع كود إيقاف عمل اللعبة عندما تصبح بالخلفية حيث أن سلوان سيتكفل بالموضوع الآن.
 
وتحياتي!

السلام عليكم

بصراحة لم الاحظ ذلك عندى

بالنسبة للتحكم في معاملات التأثير يمكننا تغيير القيمة المبدئية للمتغير m_iBlinking بدلا من القيمة الافتراضية 2 * GAME_FPS
أيضا يمكننا تقليل الفارق بين كل ومضة فيها اللون الابيض وبين اللون الاصلى بتغيير القيم التى فى السطر التالى:

bool bRenderBlinking = bBlinking && ( ((m_iBlinking/5) & 1) ? true : false );

يمكن تغيير ال 5 لنحصل علي تسريع لعملية ظهور الوميض او زيادتها لتسريع الوميض (يمكنك أخى وسام أن تختار
 قيمة مناسبة لتضعها فى الكود النهائى


ليس هناك سبب رئيسى - يمكننا التغاضى عن ذلك ووضعه مع باقى المتغيرات فى قسم ال protected

أيضا مرة أخرى ليس هناك سبب سوى أنى أردت أن أميز الكود المضاف بطريقة تهيئة غير الافتراضية فى الكود الاصلى مع أنى سمعت أو
قرأت من زمان أن تهيئة المتغيرات فى ال constructor initializer أسرع من تهيئته داخل ال constructor نفسه

عموما شكرا جزيلا أخى وسام على التعليق
وأتمنى ان كنت تقصد أن أغير فى الكود حسب التعليق الذي قمت حضرتك بوضعه أم مجرد هذا التعليق للافادة
واسف على سوء فهمى
وجزاكم الله خيرا
والسلام عليكم

السلام عليكم

اليكم الان التعديل النهائى لكود ال blinking بعد أخذ تعليقات الاستاذ وسام
الكود فى المرفقات يحتوي فقط علي التعديل النهائى
فقط استبدل الملفات المرفقة بالملفات الموجودة في اللعبة واعد بنائها واذا كان هناك مشاكل ارجو التنبيه وعذرا

وجزاكم الله خيرا
 والسلام عليكم

السلام عليكم,
تم بحمد الله إستكمال النسخة الأولية من نظام الإدخال الجديد.
الملفات المضافة والمعدلة موجودة في المرفقات, بالإضافة إلى تعديلات الأخ أحمد (الـ blinking).
 
أعتذر لتأخري عن إستكمال النظام ولكن هنالك عدة مصاعب إضطررت إما الإلتفاف حولها أو إيجاد حل لها, وهذه الأشياء هي التي تأخذ الوقت, مثلاً لم أجد طريقة مباشرة للحصول على window handler أو hWnd التابعة لنافذة اللعبة حيث إن كود صناعة النافذة موجود في داخل CoreLib.
لذلك فقد جربت عدة طرق إستخدمت أخيراً دالة FindWindow وتمرير إسم النافذة الكامل للحصول على الـ Handler, الذي يجب أن أمرره للـ DirectInput عندما أصنع Device.
 
أما من ناحية تصميم النظام نفسه, فقد حاولت أن أصممه بطريقة تعطي أكبر مرونة ممكنة, طبعاً ذلك أدى إلى بعض التعقيدات في الكود الذي في صورته الحالية هنالك مجال جيد لتحسين الأداء فيه وكذلك فإنه يحتاج تنظيف إن صح التعبير, عن طريق إيجاد طريقة أفضل لترتيب البيانات الداخلية بدل إستخدام map و multimap.
 
الميزة الرئيسية للنظام هي إمكانية تسجيل تحكمات اللعبة المحددة لعدة مفاتيح في نفس الوقت, سواءاً من لوحة المفاتيح أم من الـ gamepad, ثم يمكن فحص التحكم بشكل موحد على الـ action بدل المفاتيح الفردية, أي إن هنالك ميزة محدودة للقيام بعملية action mapping.
عذراً لست جيداً في الشرح, سأعطي مثالاً, إذا أردنا إضافة تحكم يجعل الشخصية تمشي لليسار, ونريد أن نجعل المفاتيح التي تقوم بهذه العملية هي مفتاح التحرك لليسار على لوحة المفاتيح, ومفتاح الـ NumPad4, ومفتاح التحرك لليسار على الـ gamepad, فإننا نقوم أولاً بتعريف enum يمثل الـ action:

 

enum GameControl
{
    GameControl_Left,
};

 
ثم قبل البدء باللعبة تعيين المفاتيح المطلوبة للحدث أعلاه:

InputManager::Instance->KeyboardAssignControl(GameControl_Left, DIK_LEFT);
InputManager::Instance->KeyboardAssignControl(GameControl_Left, DIK_NUMPAD4);
InputManager::Instance->JoystickLeftAssignControl(GameControl_Left); 

 
يمكن الآن في اللعبة فحص ما إذا كان أحد المفاتيح أعلاه في وضع Down عن طريق الحدث مباشرة:

 

if( InputManager::Instance->ControlDown(GameControl_Left) )
    WalkLeft();

 
هذه الطريقة تتيح إمكانية تعديل المفاتيح بسهولة تامة أثناء التنفيذ (يمكننا مثلاً وضع إختيار في القائمة الرئيسية لتغيير توزيع مفاتيح الـ gamepad).
 
هنالك عدد من الأشياء التي إخترت إستخدامها لأسباب خاصة, مثلاً, عند إدخال الباسوورد فإن إستخدام النظام بالطريقة أعلاه ليس فكرة جيدة (إضافة 26 حدث/مفتاح والقيام بـ 26 مقارنة للحصول على المفتاح المضغوط) لذلك فقد نفذت طريقة ثانوية لقراءة الحروف والأرقام بالتحديد مخصصة لإستخدامها في الكتابة, يتم إسترجاع الحروف عن طريق رسالة WM_CHAR من الـ Message Procedure و"حقنها" في نظام الإدخال, يمكن للعبة أن تفحص ما إذا كان هنالك حرف قد تم حقنه وإسترجاع الحرف مباشرة, إخترت إستخدام WM_CHAR لأن هذه الرسالة تعيد معلومات إدخال تخضع مباشرة لإعدادات المستخدم المحلية في الوندوز (مثلاً لوحة مفاتيح مختلفة أو مفتاح مضغوط مع Shift أو ما شابه) كذلك فإن المعلومات تحترم الـ Repeat frequency المحددة في إعدادات لوحة المفاتيح, يمكنكم فحص ذلك عن طريق ضغط مفتاح لحرف وإبقاءه مضغوطاً أثناء كتابة الباسوورد (تلاحظون إن الحرف الأول يظهر, ثم بعد فترة زمنية معينة يبدأ بالتكرار بإستمرار).
 
إعتبروا هذا النظام في صورة نموذج أولي, أرحب بأي إقتراحات أو ملاحظات أو... تأنيب ;-)
وسأستمر في تحسينه إلى حد الوصول إلى شئ مستقر ومناسب.
 
معلومات عن الكود المضاف:
=================
قمت بإضافة ملفين جديدين للمشروع (Input.h and Input.cpp) لا تنسوا إضافتهما, كذلك فالمشروع يحتاج أن يرتبط الآن بمكتبتان إضافية (dinput.lib and dxguid.lib) وهي موجودة أصلاً في مجلد المكتبات مع كود اللعبة الأصلي.
في بداية ملف Input.h قمت بعمل ربط للمكتبتان بإستخدام #pragma, يمكنكم التخلص من ذلك وإضافة المكتبتين من إعدادات المشروع (تذكروا إضافتها لـ Debug and Release).
 
-----------------------------
بالمناسبة, لقد إستخدمت أداة جميلة جداً لعمل Merge بين تعديلاتي وتعديلات الأخ احمد, وهي مجانية بالكامل وتجعل العملية سريعة وبدون أخطاء, هذا موقع البرنامج إذا أراد احد ما إستخدامه:
http://winmerge.org/
 
تحياتي لكم.

تباً. لقد سقط هذا الإجراء سهواً. آسف لذلك، وإن كان هناك بالفعل طرق أقل هكرنة لتحقيق الهدف (مثل استقبال القيمة من الـ Window Procedure، أو سحبها من Direct3D). المهم، الكود المرفق يحتوي تعديلاتك مع نسخة جديدة من CoreLib تدعم الحصول على الـ HWND لنافذة اللعبة.
 
التصميم جيد. لكن كود كتابة الأحرف لكلمة السر يبدو وكأنه خرق للنظام الجميل الذي قمت أنت بتصميمه. أرجو أن يقترح بقية الأعضاء تصميماً لهذه النقطة.
 
المشكلة الكبرى لدي هي أن اللعبة لم تعد تعمل عن طريق لوحة المفاتيح. يبدو أن الـ device دائماً في حالة ضياع، ولا يمكن إعادة التحرز عليها (acquire) بسبب خطأ Access Denied   :|  هذا على الأقل ما كنت أراه في الـ Debugger.
الاستثناء الوحيد هو أنها تعمل في شاشة كلمة السر. وهنا لدينا بضع أخطاء أيضاً، فكلمات السر لم تعد تعمل إلا لو كنت تستخدم زر Shift أو Caps Lock. أعتقد أن استخدام WM_CHAR ليس ضرورياً هنا، فالحالة محدودة جداً. والسبب الآخر هو في حال كون المستخدم قد حدد اللغة العربية مثلاً كلغة افتراضية لجهازه، فإنه لن يستطيع إدخال كلمة السر أبداً إلى أن يغير اللغة، وبرأيي هذا تعقيد ليس له مبرر قوي.
 
أما بالنسبة لكود الـ joystick، فلسبب ما اللاعب دائماً يسير نحو اليسار، وتوزيع الأزرار يحتاج إلى تعديل ليصبح أكثر راحة (كنت أجرب على Xbox360 Controller).
 
أرجو أن يقوم بعض الأعضاء بتجريب الكود لديهم ورؤية إن كانت اللعبة تعمل بالكيبورد أم لا...
 
الكود المعدل في المرفقات...
 
شكراً...

 
شكراً على إضافة إجراء إسترجاع HWND☺



 
لدي طرق بديلة سأجربها, لم أستخدم أحداث DirectInput لأن أسماء مفاتيح الحروف (من نوع _DIK) مبعثرة وليست كسلسلة واحدة, وأردت تلافي قراءة جميع الحروف كل عملية Update, يمكن مؤقتاً إستلام معلومات المفاتيح بصيغة (_VK) من خلال WM_KEYDOWN بدل WM_CHAR, ولكني سأحاول إيجاد طريقة يمكن خلالها الإعتماد على DirectInput بالكامل.



ذلك غريب! إنها تعمل لدي على لوحة المفاتيح من دون مشاكل, سأرى ما يمكن عمله بهذا الخصوص, إذا كان لديك الـ DXSDK هل يمكنك تشغيل الـ Keyboard sample التابع لـ ++DInput/C لمعرفة إن كانت نفس المشكلة تتكرر؟ لأن الكود هناك مشابه لما هو موجود في اللعبة.


أعتذر لذلك.. كان خطأ مني, كان يجب أن أقوم بتغيير الحروف إذا إستلمتها من small إلى capital, لقد عدلت الكود ووضعت ملف الـ StateFlow.cpp المعدل في المرفقات.أما من ناحية WM_CHAR فيبدو إن ذلك لم يكن قراراً جيداً, وانا الآن عازم على إيجاد طريقة أستخدم فيها DirectInput فقط.



 
لم أعتقد إن هناك احد سيجرب الـ XBox360 Controller :)
هنالك مشاكل معروفة بين Xbox Controllers و DirectInput, وأعتقد إن ذلك هو سبب إستحداث XInput للتعامل معها خصيصاً, سأرى ما يمكن القيام به بهذا الخصوص.

أرجو أن يقوم بقية الأعضاء بتجريب كود الإدخال الجديد والتبليغ عن أي مشاكل مع الكيبورد او الـ joystick.
 
وشــــكراً لكـــــم