نقاش مفتوح في حزمة المحرك AAnimation

أظن أني سوف أعرف عما تتكلم هذه الحزمه, أنا فعلا أريد المشاركه.....

حرام عليك يا حسام

يبدو لي أنك نسفت الحزمة نسفاً :wacko:

بالإطلاع المبدئي على الحزمة يهيألي أنك لم تبقي حجر على حجر فيها

أنا أصبحت مشتتاً تماماً

بالنسبة لـ AnimationList فصدقني أنا أعرف أنها عائدة لأسباب لا حصر لها

بالنسبة لـ AnimationGroup فهي لم تنتهي أصلاً والغرض منها هو القيام بتوليد أحداث تصادم بين مجموعة من الكائنات المتحركة

بالنسبة لـ AnimationStep فأنا أجد أنه مبدئياً لا مشاكل مما حصل فيها بل يمكن القول أن هذا هو الوضع الأفضل

بالنسبة لإعادة التسمية فأعتقد أنك حسنت كثيراً لأني لا أجيد التسمية أبداً

بالنسبة لهذا المقطع

اقتباس

• لو كانت وظائفه مدمجة في AObject لألغينا الحاجة لأهم الأعضاء البيانية الموجودة فيه: aObject، aObjectTime، aStep وهذا يدل على أنه لا يقوم بوظيفة حقيقية

• لو كانت وظائفه مدمجة لبسطنا الكثير من الكود وألغينا الحاجة إلى الوصول غير المباشر، مثل: SchedulerObject.getAObject() و SchedulerObject.getStep()

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

بالنسبة لهذا المقطع

اقتباس

لا أجد فائدة فعلية لتحقيقه لواجهة Comparable.

فأنا أستخدم Priority Queue في الفئة Scheduler وهي تعتمد على فئة من هذا النوع للقيام بعملية الترتيب

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

على كل نحن كما نحن إلى أن نرى أين ستصل العملية ولن نخسر شيئاً بل سنستفيد سواءاً اتفقنا على التصميم أو لم نتفق

إن اتفقنا على التصميم كان بها ونعمت

إن اختلفنا فهذا دعم للحزمة بكل تأكيد

منور أخ هويدي أنا أرى أن حزمة swing تنقصها عملية تحريك المكونات components لخدمة أنواع معينة من التطبيقات ليست بحاجة إلى محرك ألعاب كامل

لهذا قررت أني سأضيفها لها

تحياتي

أعتذر، لم أكن أرغب بنسف الحزمة !

ووددت لو قمت بإعادة تصميم الحزمة بأقل تغيير ممكن، لكن التغييرات متداخلة وسلاسة التصميم أهم من عدم تغييره :)

هذه بعض الملاحظات التصميمية:

بالنسبة لـ AnimationList:

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

اقتباس

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

سمعت كلامك، لكن هناك بعض الأمور التي احتاجت تغيير جذري وتأثيراته انعكست على باقي الحزمة. فمثلاً بالنسبة لـ:

اقتباس

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

كما ذكرت لك: الميزة الجديدة الرئيسية هي فصل أكواد توليد الحركات والتحكم بها عن كود التحريك الفعلي.

هذا يعني أن المحرك مسؤول عن تحريك الأغراض وفق قائمة من الخطوات بشكل متزامن وتنبيه متنصتي الأحداث ... أما شكل الحركة وتوقيتها وسرعتها وتسارعها ودورانها و .... فهي مهمة الـ AnimationGenerator

اقتباس

إن اتفقنا على التصميم كان بها ونعمت

إن اختلفنا فهذا دعم للحزمة بكل تأكيد

بل سنتفق :lol:

لكني أظنك تنتظر رؤية الميزات الجديدة تعمل ... سيتم هذا قريباً إن شاء الله.

الخطوة التالية:

الخطوة التالية التي سأعمل عليها هي -وكما قلت سابقاً- حذف الفئتين SchedulerObject وScheduler وإعادة دمج وظائفهما مع كل من AObject و AEngine على الترتيب، مع القيام بالتعديلات المناسبة

وهذا الجزء "الأكثر حساسية" من المحرك، ولكنه سهل نسبياً.

يا حسام كان بإمكانك أن تطرح خواطرك ربما يكون لدي بعض الأفكار

بالنسبة لإمكانية جمع الحركات كان بإمكانك أن تجعل للكائن المتحرك الواحد أكثر من AnimationList تنفذ على التوالي

بحيث أن كل مجموعة من الخطوات تمثل حركة

بالعكس هذا يعطيك مرونة أكثر من رائعة

بحيث يمكنك من إصدار أحداث خاصة لكل حركة على حدة

كما يمكنك من العمل على تطوير حركة بعينها دون المساس بباقي الحركات

(أقصد من وجهة نظر المبرمج بإمكانه أن يغير في حدة الحركة الدائرية لتصبح أكثر حدة مثلاً)

دعني أضع بعض النقاط على الحروف

الجدولة هي عملية تحديد من من الكائنات عليه الدور في المرة القادمة عند التحريك

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

ماذا لو قررنا أنه في وجود نوع معين من الكائنات في المحرك

فإنه يجب أن تنهي هذه الكائنات حركتها أولاً ثم تتحرك باقي الكائنات

بمعنى آخر هناك كائنات أكثر أهمية من كائنات أخرى

فكر في المرونة وإمكانية التوسع

قبل أن تفكر في أي شيء آخر

تحياتي

يبدو لي أني أخطأت بالقيام بالكثير من التغييرات دفعة واحدة دون الرجوع لك. :P

وبما أنني لا أريد أن ينتهي بي الأمر إلى تطوير نسخة خاصة من الحزمة لوحدي !! :blink: سأقوم بإعادة التصميم مرة ثانية انطلاقاً من الحزمة الأصلية خطوة بخطوة، ولا نبدأ بخطوة قبل أن نتفق على السابقة.

هل هذا جيد ؟ :lol:

الخطوة الأولى والتي ذكرت سابقاً أنك موافق عليها وهي إعادة التسمية.

الخطوة الثانية هي إعادة هيكلة الفئة Animation لتصبح AStep بحيث تصبح مجرد مغلف wrapper للتغييرات في خصائص المكون المغلف بدوره داخل AObject

أنا أرغب أن يتم تخزين زمن الانتظار قبل تنفيذ الخطوة التالية داخل الخطوة نفسها

وهذا سيتطلب على كل حال إعادة النظر في SchedulerObject و Scheduler

سأرفع الكود غداً إن شاء الله

اقتباس

يبدو لي أني أخطأت بالقيام بالكثير من التغييرات دفعة واحدة دون الرجوع لك.

كل ما هناك أخي حسام أني قتلت الموضوع تفكيراً

والإصدارة التي أمامك أتت بعد إصدارات عديدة لذا فأنا فكرت في الكثير من الأمور

كما أني واجهت الكثير من المشاكل التي أوصلتني إلى التصميم الحالي

اقتباس

وبما أنني لا أريد أن ينتهي بي الأمر إلى تطوير نسخة خاصة من الحزمة لوحدي !!

بالمناسبة لا عيب في أن يكون هناك أكثر من نسخة من نفس الحزمة

خذ عندك الأخ لينكس كمثال

ولو أن حزمتنا (خذ بالك من نا الفاعلين :lol: ) لا تقارن مع صعوبة وتعقيد لنيكس

اقتباس

سأقوم بإعادة التصميم مرة ثانية انطلاقاً من الحزمة الأصلية خطوة بخطوة، ولا نبدأ بخطوة قبل أن نتفق على السابقة.

هل هذا جيد ؟ :lol:

لا مشاكل في أن تقوم بأي شيء

لكن كما قلت لك مسبقاً لا تعطي أحكام مسبقة اسمع مني قد يكون لدي سبب مقنع

اقتباس

أنا أرغب أن يتم تخزين زمن الانتظار قبل تنفيذ الخطوة التالية داخل الخطوة نفسها

وهذا سيتطلب على كل حال إعادة النظر في SchedulerObject و Scheduler

لم أفهم هذه النقطة أعطني مثال بسيط

تحياتي

اقتباس

لم أفهم هذه النقطة أعطني مثال بسيط

انظر إلى الحزمة بعد التعديل، بالتحديد الفئتين AStep و P2PAnimation

لاحظ أن الفئة AStep تحوي:

    private long time = 100l;

    public long getTime() {
        return time;
    }

    public void setTime(long time) {
        this.time = time;
    }

ولاحظ في الـ P2PAnimation :

        // set time
        long steptime = timeForAnimation / asl.size();
        for (AStep as : asl) {
            as.setTime(steptime);
        }

(حيث asl هي قائمة للخطوات)

أي أن التوزيع الزمني للخطوات (في هذه الحالة الزمن بين كل خطوتين متساوي) يتم تخزينه في الخطوة نفسها

وفي المحرك AEngine تحديداً بالـ doAnimation يجب أن يتم قرائة هذه القيمة واستخدامها في معرفة الزمن الواجب إنتظاره قبل البدء

وهذا من شأنه إلغاء أهمية وجود كل من SchedulerObject و Scheduler

حيث يتم اختصار Scheduler إلى دالة getAObjectsReadyToAnimate والتي توضع في الـ AEngine

ولن يعود هناك حاجة للـ SchedulerObject بطبيعة الحال !

____________________

لدي تعقيب على هذه العبارة:

اقتباس

ماذا لو قررنا أنه في وجود نوع معين من الكائنات في المحرك

فإنه يجب أن تنهي هذه الكائنات حركتها أولاً ثم تتحرك باقي الكائنات

أليست هذه مهمة مستخدم الحزمة ! والتي يمكنه القيام بها بسهولة بواسطة التنصت على الحركة ؟!

لم أقتنع بهذه النقطة

ربما استوعبت الفكرة بشكل خاطئ ... لا أدري

ممكن مثال لتوضيح الفكرة ؟

____________________

شكراً على "نا الفاعلين" :lol:

كما قلت لك مسبقاً المرونة تؤدي إلى التعقيد

لماذا تعتقد أني أقوم بفحص الكائنات المتحركة كل مرة أليس من الأسهل علي أن أقوم بتغيير الكائنات المتحركة التي تم تحريكها في آخر مرة

بالطبع المشكلة تكمن في أني أريد أن أتأكد أنه لم يحصل تغيير في حركة الكائنات المتحركة

بمعنى آخر لم يتم إضافة خطوة جديدة على قائمة الخطوات الخاصة بالكائن المتحرك

ما الذي سيحصل لو أضفنا خطوة جديدة

الذي سيحصل أن وقت الخطوات سيتغير كلياً

وهذا يعني بالتالي أني مضطر أن أمر على جميع الخطوات لأغير وقتها

بالتالي هذا يعني أنه لو كان لدي ألف خطوة في كائن متحرك فعلي تغيير وقتها جميعاً

وهذا سيئ جداً

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

وهذا هو الحاصل في schedulerObject

دعني أوضح بمثال

لدينا كائن أ و كائن ب و كائن ج

كائن أ له أولوية في الحركة

لو كان لديه حركات فيجب على المحرك أن يقوم بها أولاً

كيف ستتمكن من إيقاف الكائنات ب و ج عن الحركة والسماح فقط للكائن أ بالحركة

تحياتي

من المهم تصور هيكل عام للحزمة قبل البدء بأي شيء

المرونة قد تؤدي إلى التعقيد، وليس بالضرورة

الزمن الذي نقوم بتخزينه في الـ AStep هو الوقت الواجب إنتظاره قبل البدء بالخطوة التالية

أي أن الأمر نسبي

وأي إضافة أي خطوة لن يؤثر على باقي الخطوات لأن الـ AObject سيكون له زمنه الخاص baseTime ويضاف له زمن كل خطوة بعد تنفيذها

وبالنسبة للأولوية يمكن تحقيق ذلك داخل المحرك أيضاً بقليل من التعديل على الدالة getAObjectsReadyToAnimate والتي أصبحت في موجودة في الـ AEngine

تصميم الحزمة الحالي معقد ومتداخل وأي تغيير في تصميم أي فئة سيؤدي حتماً إلى تغييرات كبيرة في الكثير من الفئات، وهذا مرهق جداً !

بعض الأمور التي لا أراها بمكانها يمكن تعديلها من دون تأثير على باقي الحزمة:

فمثلاً animateComponent في AObject يجب أن تكون في الـ AEngine

الـ AnimationList - AList يجب أن تكون كافة طرائقها تتعامل مع AStep أي من الشكل:

addAStep(AStep aStep);
insertAStep(int index, AStep aStep);

لكن الكثير من الأمور تحتاج إلى تغييرات جذرية !

فالمشكلة الرئيسية هي أن الحركة في الحزمة مصممة لتتم على إتجاه واحد (أفقي أو عمودي) وتغيير هذا يتطلب تغييرات جذرية في الـ AStep و الـ AEngine والـ P2PAnimation والـ AnimationObject على الأقل !!

أسوء ما في الحزمة أن توليد الحركة يتم عبر "قطع" من الكود موزعة على العديد من الفئات، والمزامنة (زمن الانتظار بين خطوتين) ليست مضمنة في مولد الحركة. كما ذكرت لك في المشاركة السابقة لماذا أرى وجوب إعادة النظر في كل من الـ SchedulerObject و Scheduler.

ولهذه الأسباب لم أستطع أن أعيد تصميم "نصف" الحزمة.

التصميم الجديد للحزمة أتي ليحل جميع هذا الأمور دفعة واحدة ! كما أنها تدعم كافة ميزات الحزمة القديمة

وبالنسبة لأحداث التصادم أرى أنه بالإمكان إضافتها بسهولة نسبياً في التصميم الجديد

كما أنه من الممكن إعادة إنشاء الـ AnimationList - AList كفئة منفصلة تغلف قائمة من الخطوات

أقترح أن نكمل التطوير من بدأً من النسخة الجديدة

ما رأيك ؟

جرّب أن تلقي نظرة عن كثب على هذه النسخة من الحزمة حيث تم حذف الـ SchedulerObject و Scheduler بالكامل.

AAnimation + Test (new2).zip

اقتباس

من المهم تصور هيكل عام للحزمة قبل البدء بأي شيء

المرونة قد تؤدي إلى التعقيد، وليس بالضرورة

بالطبع المرونة في حد ذاتها ليست هدف الهدف هو إعطاء مستخدم الحزمة مميزات تغنيه عن القيام بعملية التحريك بدون الحزمة

اقتباس

الزمن الذي نقوم بتخزينه في الـ AStep هو الوقت الواجب إنتظاره قبل البدء بالخطوة التالية

أي أن الأمر نسبي

وأي إضافة أي خطوة لن يؤثر على باقي الخطوات لأن الـ AObject سيكون له زمنه الخاص baseTime ويضاف له زمن كل خطوة بعد تنفيذها

دعنا نفكر بشكل أفضل ماهو الزمن الذي تخزنه في AStep أليس هو مجموع الأزمان ما بين آخر خطوة حصلت والخطوة التي نتكلم عنها

مثال

الكائن المتحرك له 5 خطوات يقوم بها في وضع متكرر

زمنه 100 م ث

آخر خطوة قام بها رقمها 3

الخطوة رقم 5 ماهو الزمن الذي تقترح تخزينه فيها

أليس هو مقدار الزمن الخاص بكل خطوة قبله بمعنى

مقدار الخطوة رقم 1 + ...+مقدار الخطوة رقم 4

خذ عندك السناريو التالي (بالطبع لو كان فرضي صحيحاً)

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

ولنفترض أنه أضافها في البداية

والمحرك الآن يعمل في الخطوة رقم 3

ما الذي سيحصل في الزمن الخاص بالخطوة رقم 4 والخطوة رقم 5

هل سيزيد

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

(عندما يصل إلى نهاية مجموعة الخطوات الخاصة به يعود من البداية)

ما الذي سيحصل عند تنفيذ الخطوات الخطوات من 2 إلى 6؟

أترك لك التعقيب على هذه القضية

اقتباس

وبالنسبة للأولوية يمكن تحقيق ذلك داخل المحرك أيضاً بقليل من التعديل على الدالة getAObjectsReadyToAnimate والتي أصبحت في موجودة في الـ AEngine

هناك قاعدة يعرفها كل من يصمم الحزم

القاعدة تنص على اجعلهم يرثون منك ويعدلون على سلوك حزمتك ولا تضطرهم للإطلاع على شيفرتك والتغيير فيها

الحزم packages وظيفتها الأساسية البحث عن النقاط التي تمثل تعقيد أو مشكلة في الفهم لدى شريحة المبرمجين وتحميل هذا التعقيد على المكتبة المساعدة

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

اقتباس

تصميم الحزمة الحالي معقد ومتداخل وأي تغيير في تصميم أي فئة سيؤدي حتماً إلى تغييرات كبيرة في الكثير من الفئات، وهذا مرهق جداً !

وأنا لم أدعي العكس

أنا لم أقل أن التصميم سهل وأنه لن تحتاج للقيام بشيء

ولم أقل أن هناك فصل كامل جيد بين الفئات

وأنا أعمل منذ بدايتي في الحزمة على محاولة تقليل التعقيد بقدر الإمكان

لكني لا أريد أن أخسر حتى أقلل التعقيد

أنا أستحمل التعقيد حتى يحصل المستخدم للحزمة على أعلى إمكانيات ممكنة

اقتباس

فمثلاً animateComponent في AObject يجب أن تكون في الـ AEngine

هذه النقطة مكررة

ما الذي يجعلك ترى أنها يجب أن تكون في AEngine؟

أنا أرى أن وظيف المحرك هي تنظيم عملية الحركة وإصدار الأحداث اللازمة

لكن فعلياً الحركة نفسها نابعة من الكائن المتحرك نفسه

بالطبع لا أمانع لو كنت تفكر بمنطق آخر لكن لا تجعل هذا مثالاُ على التداخل بين الفئات لأن لدي منطقي الذي أفكر به

اقتباس

الـ AnimationList - AList يجب أن تكون كافة طرائقها تتعامل مع AStep

ربما تكون محق في هذه النقطة

لكني لا أراها مثالاً على تعقيد ولا على تداخل

كل ما هناك أني فكرت لو أني لم أخرج AStep إلى المبرمجين سأقلل عليهم المعرفة التي يحتاجونها ليستخدموا الحزمة

اقتباس

لكن الكثير من الأمور تحتاج إلى تغييرات جذرية !

أنا لا أرى التغييرات الجذرية التي تتكلم عنها لذا من فضلك أخبرني عنها

اقتباس

فالمشكلة الرئيسية هي أن الحركة في الحزمة مصممة لتتم على إتجاه واحد (أفقي أو عمودي) وتغيير هذا يتطلب تغييرات جذرية في الـ AStep و الـ AEngine والـ P2PAnimation والـ AnimationObject على الأقل !!

هذا كلام غير صحيح بدلالة أنه في AnimationType قبل أن تغير الحزمة كان يوجد نوع اسمه vertical_horzintal

وعملية التحريك لا تتم إلا في animateObject وهو المكان الوحيد الذي عليك التغيير فيه لإضافة أي شيء على عملية التحريك

في النهاية لا مانع لدي من المتابعة معك في التصميم الجديد لكني لا أعدك بأن أعتمده كتصميم نهائي وأشارك فيه

لأني فعلياً لا ألمس التعديلات الجذرية الموجودة هنا

بالنسبة للإطلاع على التعديل الأخير فلدي ضغط في الدراسة سأحاول في أقرب وقت أن أطلع عليها

(أعتقد أنه بعد أسبوعين أو ثلاثة)

تحياتي

في التصميم الحديث للحزمة يتم تخزين الزمن اللازم انتظاره قبل تنفيذ الخطوة التالية في الـ AStep -كما ذكرت سابقاً- وليس الزمن من بداية التحريك، وبالتالي لن يتغير شيء عند إضافة أي خطوة في أي مكان. (وهذا أحد التغييرات الجذرية في التصميم!)

وعندما قلت أنه يمكن دعم أولوية التحريك بتعديل بسيط في getAObjectsReadyToAnimate، قصدت تعديل بسيط نحن نقوم به (مصمموا الحزمة)، ولن يضطر المستخدم إلى محاولة فهم الحزمة أبداً !

أما بالنسبة للحركة في إتجاهين، فعندما اختبرت الحزمة تأكدت أن التحريك يتم باتجاه واحد في نفس الوقت، وإن كانت الحركة على محوري الإحداثيات سيتم تنفيذ الحركة الأفقية ثم العمودية (أو بالعكس) وليس الانثنتين سوية !

كما أن مبدأ حساب الخطوات غير صحيح حيث أنه عندما تكون الحركة أفقية وعمودية لا يعني هذا أن الخطوة العمودية أو الأفقية تساوي الخطوة المدخلة من قبل المستخدم (حسب فيثاغورس a^2 + b^2 = c^2)

وعندما ذكرت أن كود توليد الحركة موزع وتغييره يحتاج إلى تغييرات جذرية، فهذا ما اضطريت القيام به عندما حاولت تعديل الفئة AStep إلى ما تراه، ولم أتمكن من إنجازه من دون تغييرات جذرية !

وكيف لم تلمس التعديلات الجذرية، وقد ذكرت سابقاً أني نسفت الحزمة ولم أبقي فيها حجراً على حجر !

حيث تم حذف نصف فئات الحزمة وألغي التعقيد منها وأصبحت أكثر تنظيماً وكل وظيفة منطقية موجودة في فئة واحدة فقط مع دعم كافة إمكانيات الحزمة القديمة.

يبدو أنك لم تلقي نظرة على التعديلات التي قمت بها .... أظن المانع ضيق الوقت.

إذاً اسمح لي أن أشرح لك عن التصميم الجديد، لا تقارنه بالتصميم القديم ... اعتبرها حزمة جديدة كلياً :

الفئة AStep :

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

الواجهة AnimationGenerator:

واجهة يجب تحقيقها من جميع الصفوف التي تقوم بتوليد الحركات (قائمة من AStep) فيها أهم طريقة هي:

public ArrayList<AStep> generate();

الفئة P2PAnimation :

تحقق الواجهة السابقة وتقوم بتوليد قائمة من خطوات الحركة بين نقطتين خلال زمن معين.

الفئة AObject :

وهي فئة تغلف المكون Component الذي سيتم تطبيق التغييرات عليه، تحوي قائمة من خطوات التحريك AStep ومؤشر إلى الخطوة التالية (التي يجب تنفيذها) ومتحول baseTime يعبر عن عمر المكون ويستخدمه الـ AEngine لضبط تنفيذ الحركات.

الفئة AEngine :

وتحوي قائمة من الـ AObject ولها دورين أساسيين:

التحريك الفعلي للـ AObject (وتغيير الأبعاد والشفافية ...) في الوقت المناسب وفق المعلومات المخزنة في قائمة الحركات الموجودة داخل كل AObject

تنبيه متنصتي الأحداث عند حدوث أي منها.

باقي الفئات بسيطة وهي عبارة عن متنصتات على الأحداث أو استثنائات

أو أنها سيتم تنسيقها لاحقاً (مثل ACore)

نعم الأمر بهذه البساطة !

وفقنا الله في دراستنا وأزال عنا الضغط :)

سأستمر بتطوير الحزمة بشكل بطييييئ خلال هذين الأسبوعين أو الثلاثة بانتظارك

سلام

اقتباس

في التصميم الحديث للحزمة يتم تخزين الزمن اللازم انتظاره قبل تنفيذ الخطوة التالية في الـ AStep -كما ذكرت سابقاً- وليس الزمن من بداية التحريك، وبالتالي لن يتغير شيء عند إضافة أي خطوة في أي مكان. (وهذا أحد التغييرات الجذرية في التصميم!)

أريد أن أفهم هذه النقطة (هات مثال عليها) يهيألي أنا نتكلم عن scheduler لكن مدموج مع AEngine

اقتباس

وعندما قلت أنه يمكن دعم أولوية التحريك بتعديل بسيط في getAObjectsReadyToAnimate، قصدت تعديل بسيط نحن نقوم به (مصمموا الحزمة)، ولن يضطر المستخدم إلى محاولة فهم الحزمة أبداً !

يبدو لي أنك أخطأت فهمي أنا أعطيك مثال على الموضوع

لكن هناك آليات كثيرة لعملية الجدولة (اكتب على جوجل Scheduler)

أعتقد أنها نقطة قوة في المحرك أن أمكن المبرمج من عمل الآلية المناسبة له

اقتباس

أما بالنسبة للحركة في إتجاهين، فعندما اختبرت الحزمة تأكدت أن التحريك يتم باتجاه واحد في نفس الوقت، وإن كانت الحركة على محوري الإحداثيات سيتم تنفيذ الحركة الأفقية ثم العمودية (أو بالعكس) وليس الانثنتين سوية !

هذا كلام غير صحيح راجع الدالة animateComponent في الحزمة قبل التعديلات

اقتباس

كما أن مبدأ حساب الخطوات غير صحيح حيث أنه عندما تكون الحركة أفقية وعمودية لا يعني هذا أن الخطوة العمودية أو الأفقية تساوي الخطوة المدخلة من قبل المستخدم (حسب فيثاغورس a^2 + b^2 = c^2)

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

يهيألي أنه واضح للجميع أني لا أتعامل مع الفاصلة العامئة FP فكيف لي أن أطبق فيثاغورس لذا اعتمدت على مسافة منهاتن بدلاً منها

اقتباس

وعندما ذكرت أن كود توليد الحركة موزع وتغييره يحتاج إلى تغييرات جذرية، فهذا ما اضطريت القيام به عندما حاولت تعديل الفئة AStep إلى ما تراه، ولم أتمكن من إنجازه من دون تغييرات جذرية !

أي تغييرات بالضبط حتى أرى إن كان فعلاً لدي مشكلة في التصميم

على حسب علمي أن كل التغييرات التي حصلت هنا تغييرات سطحية مالم تكن تقصد نقل الوقت إليها

في هذه الحالة ستكون ظالماً للتصميم القديم لأنك أزلت فئتين من الأركان فيه ثم تريد أن تكون تغييراتك طفيفة :(

اقتباس

وكيف لم تلمس التعديلات الجذرية، وقد ذكرت سابقاً أني نسفت الحزمة ولم أبقي فيها حجراً على حجر !

حيث تم حذف نصف فئات الحزمة وألغي التعقيد منها وأصبحت أكثر تنظيماً وكل وظيفة منطقية موجودة في فئة واحدة فقط مع دعم كافة إمكانيات الحزمة القديمة.

ما أسهل النسف أخ حسام

لن أرد على هذه النقطة حتى أطلع على الكود الذي كتبته

كما أخبرتك مسبقاً سأكون معك في التطوير خطوة بخطوة بإذن الله

لكني لن أعتمد التصميم ما لم يعطني نفس الأمور التي كان التصميم القديم يعطيني إياها مع تعقيد أقل

تحياتي

اقتباس

ما أسهل النسف أخ حسام

ليس بهذه السهولة ! :happy:

اقتباس

لن أرد على هذه النقطة حتى أطلع على الكود الذي كتبته

كما أخبرتك مسبقاً سأكون معك في التطوير خطوة بخطوة بإذن الله

لكني لن أعتمد التصميم ما لم يعطني نفس الأمور التي كان التصميم القديم يعطيني إياها مع تعقيد أقل

+1

سنكمل نقاشنا بعد تفرغنا من موجة الدراسة هذه :)