الجمع بين قوة Processing.js وWeb Workers

Question

لقد قمت ببعض القراءة حول مفهومين جديدين (نسبيًا) في لغة Javascript - Web Workers وJohn Resig's Processing.js الرائع (حسنًا، ليس "مفهوم Javascript" جديدًا حقًا، لكنك فهمت فكرتي).توجد بعض الأمثلة الرائعة لكلا التقنيتين على شبكة الإنترنت، ولكنني لم أجد بعد نموذجًا يستخدم كلا التقنيتين بشكل فعال.يبدو الأمر مثيرًا للاهتمام وقويًا جدًا بالنسبة لي، لذلك اعتقدت أنه من الأفضل أن أجربه.

ومع ذلك، لا أستطيع حقًا معرفة أفضل تصميم نصي لدمج الاثنين معًا ...يبدو لي أنه عادة، عند استخدام Processing.js، يتم تعريف بعض الفئات داخل "معالجة التطبيق".يسمح لك باستخدام بناء جملة يشبه Java للقيام بذلك.ومع ذلك، لا يمكن الوصول إلى هذه الفئات إلا من خلال تطبيق المعالجة - وهو أمر واضح.لكن بعد ذلك لدينا العمال...في هذا مثال رائع، يتم تعريف كائن وظيفة Javascript لأول مرة في برنامج نصي منفصل، وإذا كان استخدام العامل مطلوبًا، فإن البرنامج النصي العامل يستورد النموذج الأولي لهذا الكائن ونوع "البراغي" نفسه عليه.

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

هل أطل على شيء ما؟هل أريد شيئًا ليس من المفترض أن يكون؟أم أنني أسيء فهم بعض المفاهيم الأساسية؟

شكرا للمساعدة!

يحرر:

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

دعونا نحاول الخطوط العريضة للعمل مع:لدي فئة "الكرة"، والتي لا تفعل أي شيء إلى حد كبير باستثناء تخزين موضع ثنائي الأبعاد.على كل draw() دورة، Processing.js يدعو لها update() الطريقة التي تجعل الكرة تتخذ موقعًا جديدًا.بعد ذلك، display() تسمى الطريقة، حيث ترسم الكرة دائرة صغيرة على موضعها الحالي.

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

الكل في الكل - فكرة جيدة أم سيئة؟إذا كانت جيدة، أي اقتراحات حول كيفية تصميم هذا؟

Answer 1

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

لذا فإن النموذج الذي تصفه هو بالضبط كيف يفعله المحترفون.

Answer 2

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

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

Answer 3

في هذا المثال، يجب الانتهاء من حساب المواضع قبل سحب الكرة - لذا فإن المعالجة غير المتزامنة لا معنى لها؟

p5 نفسه متزامن للغاية - يوجد مركزي واحد يرسم الطريقة التي تفعل كل الرسم.

كما لا يستطيع عمال الويب الوصول إلى الدوم، لذلك لا يمكن استخدامها للرسم.

بالنسبة للتطبيقات الأكثر تعقيدًا والتي تعتمد على الأحداث مثل الألعاب، يمكن أن تكون هناك استخدامات للعاملين على الويب.

Answer 4

مجرد فكرة...ولكن معالجة الإشارات ما تفعله هو التوصل إلى معدل عينة يقسم الإشارة التناظرية إلى معلومات رقمية.المفتاح هو الاحتفاظ بما يكفي من الإشارة لإعادة إنشاء النسخة الأصلية.مثل الطريقة التي يتم بها نسخ ملفات MP3 من ملفات الموسيقى باستخدام 128، 192، وما إلى ذلك.

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

أعلم أن هذا لا يجيب على أي من أسئلتك حول Processing.js أو Web Workers.مجرد فكرة لمساعدتك على إجراء تلك الحسابات بشكل أكثر كفاءة.

Answer 5

تذكرني هذه الفكرة بدمج فكرة قائمة انتظار مهام Google في Google App Engine.

http://code.google.com/appengine/docs/python/taskqueue/

هذا قد يساعدك.

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

وإذا وصلت إلى نقطة أحتاج فيها إلى أن يقوم الخادم بمعالجة شيء ما أثناء عدم انتظار العميل، فسأستخدم قائمة انتظار المهام