السلام عليكم .


لا يمكنني تحديد رقم معين لان الامر بيد المستخدم  اذا شاء ينتج مصفوفة بخانتين او بمئة الف ☺ .



اضنها تفوق الدخل الشهري للبرنامج ☺ .
ان عملية البحث تعطل عملية الرم و التحريك ( صور متحركة ) اذ يستلزم علي ان اعيد البحث من البداية في كل دورة من الحلق لايجاد الحركة المرادة رسمها ، طبعا هذا في حالة حركة واحدة لو قمت بطلب 10 حركات فهذا سيف يكلف 10 اضعاف الوقت المستخدم لايجاد عنصر حركة من كل صورة متحركة .

مثال اخر لو كانت الحركة غر حلقية ( Loop ) و تنتهي عند العنصر 21  من الحركة 5 ، فهذا يعتبر تبذيرا كبيرا للوقت .


لم افهم قصدك في هذه النقطة .


اولا لان كل شيئ يمكن تحسينه لكن ليس هذا هو هدفي و انما اسعى لتحينه حتى لا اضيع سلاسة الحركة . فعوض رم 10 صور في الثانية يمكن رس 24 في حالة التحسين .



شكرا لك على الرابط ، ساحاول البحث في الطريقة الثانية التي اقترحتها .


شكرا لكم .

سلام .

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

أعتذر عن التطفل ☺

سأحاول إن شاء الله 😖

تباً مع أنني كنت أستمتع بقراءة مشاركاتك 😄

أقصد كم مرة تنادي هذا الإجراء في الثانية مثلاً؟

ما أحاول الوصول له، هو أن كون عملية ما تأخذ وقتاً طويلاً لا يعني بالضرورة أنها بحاجة لتحسين وإن كان هذا التحسين ممكناً.
علينا دوماً أن نسأل أنفسنا الأسئلة التي طرحتها قبل أن نضيع وقتنا وجهدنا في تحسين إجراء قد لا تكون الفائدة من هذا التحسين مساوية للجهد الضائغ والتقيد المضاف.

السلام عليكم .

في الحقيقة لا اعرف مسبقا عدد المراة التي يتم فيها استدعاء هذا الاجراء ، لكن على الارجح كون استدعاءه مساوي لعدد العناصر الموجودة في الشاشة ( العناصر المتحركة فقط ) .

ساحاول  مجددا و اذا و جدت فكرة ما فساشارككم بها لتحسينها 😄 .




الا اذا كان الامر على حساب الرسم فهذا سيشكل مشكلة ساشرح الامر :

لقد قمت بتقسيم الثانية الى ستين جزءا ، اذا اصغر قيمة يمكن لعنصر الحركة ( Frame ) ان ياخذها هي جزء من الثانية .

فلو كان لدي العناصر التالية :

// groupe , img , x , y , time
[Begin Action 0]
0,0, 0,0, 6 // Frame 01
0,1, 0,0, 1 // Frame 02
0,2, 0,0, 1 // Frame 03
0,3, 0,0, 5 // Frame 04

فسيكون هناك احتمال كبير بعدم احترام التوقيت للعنصرين 2 و 3 .

اظنني ساحاول التلاعب بحجم المصفوفة و المتغير الذي يمسمح بالبحث فيها بالشكل التالي :

int i = 0 ;
int j = 0 ;
int a = 0 ;
int size = strlen ( matrix ) ;


a = (int )( size + 1 )/2 ; 


for ( i = 0 , j = size ; 
      i < a , j > a    ;
      i ++  , j --      ){

  if ( ( matrix [i].id == id ) && ( matrix [j].id == id ) ) {

   // Do something 

}

else printf ( " error : no %s ID \n ", id ) ;

}

الفكرة هي البحث في المصفوفة بتعين مجالات للبحث ، هنا مثلا تم تقسيم المصفوفة الى مجالين يتم البحث فيهما في ان واحد ، اظن ان هذه الطريق ( المؤقتة ) اسرع من البحث الخطي ، هل لكم اقتراحات اخرى ؟

كما قلت سابقا لو كان البحث يتم قبل الدخول في منطق اللعبة ، فلا ابالي بكلفته الزمنية ،لكن بما انه تعلق الامر بالرسم فهذا مختلف قليلا 😄 .

طلب اخر ( اعذروني ☺ ) هل لكم اقتراح هندسة البرنامج بشكل اخر يجعل من عملية التحريك الثنائية اقل كلفة ؟

شكرا لكم جميعا .

سلام 😄 .

السلام عليكم،
لدي ملاحظة أود الإشارة لها، عدد الأطر التي تشكل الحركة يكون قليلاً في معظم الأحيان، لم أشاهد من قبل تغير يصل 60 إطار في الثانية في شكل ثنائي الأبعاد، تردد تغير الأطر عادة ما يتراوح بين 5 و 20 إطاراً في الثانية.
حتى في حالة الفيديو لن تحتاج أكثر من 27 إطاراً، أو لنقل 30.
 
أما بالنسبة للبحث، يمكنك إستخدام مخطط من الحروف أو الأطر صحيح؟ بما إن هنالك عدة أشياء تعاني من نفس المشكلة.
في حالة الحروف، صورة واحدة تحوي جميع الحروف تمثل الـ font مثلاً بدل أن تستخدم صورة لكل حرف، تستطيع تقسيم الصورة بحيث يمكنك تحديد مكان الحرف عن طريق قيمة الأسكي له:
 

 
ثم إستخدام معادلات بسيطة لمعرفة إحداثيات الحرف أو الشكل، في الصورة اعلاه كل حرف يأخذ مساحة 20x20 بكسل، وهنالك 10 أعمدة و10 صفوف (أي مئة رمز) تبدأ الرموز من 32 والذي يمثل زر space.
مثال لإجراء بسيط يحسب الإحداثيات من قيمة ASCII:

// Get character position using it's ASCII value
RECT get_char_rect(unsigned char ascii)
{
	RECT cr;
	ascii -= 32;
	cr.left = (ascii % 10) * 20;
	cr.top = (ascii / 10) * 20;
	cr.right = cr.left + 20;
	cr.bottom = cr.top + 20;
	return cr;
}

 
في هذه الحالة لن تحتاج للبحث أصلاً.
يمكن تطبيق نفس الفكرة تماماً على حركة الصور، ولكن يجب أن يكون رقم كل إطار ثابتاً، أي مثلاً الإطار من 1 إلى 20 يمثل حركة المشي ومن 21 إلى 31 حركة القفز، وبما إن ملفات الصور لن تتغير في جميع الأحوال فمن المقبول تثبيت الأرقام المميزة للصور، بالنسبة لي على الأقل 😏
 
هل فهمت مشكلتك بطريقة صحيح؟ أعتذر إن لم يكن الإقتراح في محله. 😋

السلام عليكم



بلى اخي هناك من يستخدم هذا النمط من التغير و ان كان غير منتشر ، مثال محرك MUGEN لالعاب القتال الثنائية البعد يستخدم نفس النمط
لكن هدفي ليس استعمال هذا النمط من التحديث  بل هو ايجاد طريقة لايجاد اطار الحركة في اسرع وقت حتى لا يؤثر ذلك على تسلسل الحركة .

*ملاحظة : الملفات التي استعملها (sff , air , act ) هي ملفات لهذا المحرك .



استعمل هذه الفكرة ( بالاصح جزءا منها ) حيث انني اجمع جميع الحروف في صورة واحدة ثم في ملف نصي اضع المعلومات الخاصة بكل حرف ،و في النهاية اقوم بتحميل الكل في الذاكرة ... ساحاول تعديل الطريقة مضيفا اليها ما تفضلت بذكره .



نعم اوافقك الرأي هذه الطريقة مستعملة بشكل كبير في الالعاب ... المانع
الوحيد الذي لا يسمح لي بتطبيقها هو انني اقوم بتحميل الصور من ملف خاص و
ليس ملف صور ، هذا الملف يحتوي على عدة معلومات ( مجموعة الصورة ،رقم
الصورة ، احداثيات الصورة ) بالاضافة الى المعلومات الخاصة بالصور لهذا
فان تطبيق هذه الطريقة غير ممكن الان.

 ضف الى ذلك ان لدي 620 صورة مختلفة الحجم  لشخصية واحدة ، لا اظن انه من الحكمة جمعها في صورة واحدة .


اظنك تقصد حجم الاطار او انني لم افهم ما قصدته 😄 .


الى حد كبير 😄 ، الحل لم يقضي على المشكلة نهائيا لكنه امدني بافكار قد تفعل هي ذالك ☺ ... شكرا لك .


سلام