Pixi.js: امنح خيارًا لتعيين حدود ثابتة على الحاوية

تم إنشاؤها على ٢٣ سبتمبر ٢٠١٦  ·  15تعليقات  ·  مصدر: pixijs/pixi.js

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

💾 v4.x (Legacy) 🤔 Question

التعليق الأكثر فائدة

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

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

نأمل أن يكون هذا منطقيًا ، ويمنحك مفهومًا سريعًا لكيفية تنظيم الحدود في Pixi.

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

يمكنك أن ترى أنه بعد السحب الأول ، تمتد شبكتك خارج حجم منفذ العرض:

image

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

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

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

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

http://codepen.io/anon/pen/yarVwm؟editors=0010

ال 15 كومينتر

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

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

كيف تقترح أن أنفذ عناصر "خارج الشاشة"؟

لماذا تحتاج الحدود على أي حال؟

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

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

lel.width = wonderfulRectangle.width * 0.8;
lel.height = wonderfulRectangle.height * 0.9;

لماذا لا تستخدمه بشكل ثابت؟ هل يمكنك فقط إعداد شيء عالمي ، مثل هذا:

var globalRect = new PIXI.Rectangle(0, 0, renderr.width/renderer.resolution, renderer.height/renderer.resolution);

تحديث هذا المستقيم في كل تغيير حجم ، والعمل مع ذلك. لماذا تحتاج إلى "lel.width" و "lel.height"؟

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

ما أحاول محاكاته هو سلوك شاشة Android Launcher مع طرق عرض متعددة قابلة للتمرير وشبكة رمز فوق خلفية سطح المكتب.

return new PIXI.Point(snapPosX.clamp(0, target.parent.width), snapPosY.clamp(0, target.parent.height));

ما زلت لا أفهم ماذا تريد. تعمل حدود حاوية PIXI تمامًا كما يفترض أن تعمل. أنت لست أول من ارتكب هذا الخطأ.

يا صانع النفس ، لا يمكنني فعل هذا بعد الآن. هل يمكن لأي شخص فقط إلقاء نظرة على المثال ، وتحريك rageface حوله وإخباري لماذا يحدث هذا الهراء مع الخطوط وما إذا كانت ميزة خلل / مفقودة في PIXI أو إذا كان لدي خطأ في الكود؟

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

كما أن codepen لا يعمل معي بعد الآن ، بطريقة ما اي افكار لماذا؟

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

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

لقد ذكرت أن لدي "خطأ" في الكود الخاص بي. ما هذا الخطأ؟ لقد بحثت جيدًا ولكن لم أجد أي منطق خاطئ.

استخدم بعض المتغيرات العامة بدلاً من "العرض / الارتفاع" التي تتغير. قم بتحديث هذا المتغير عند الحاجة.

var globalRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

إذا كنت تريد الحدود "المحلية" ، فحددها ، لكن لا تستخدم نفس المتغيرات مثل pixi:

container.myRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

الخطأ هو أنه لا يوجد تخطيط في PIXI على الإطلاق. "العرض" و "الارتفاع" لهما معنى مختلف. لا يمكنك تثبيت الحبال الفرعية بارتفاع عرض الأصل ، لأن الطفل يؤثر عليها.

لا توجد طريقة لـ PIXI لمعرفة أنك تريد عرض / ارتفاع مستطيل رسمته داخل الرسومات ، وليس حدود رسومات كاملة (ماذا لو كانت هناك دوائر أيضًا؟) ، وليس حدودًا فرعية. المنطق المعقول الوحيد للحدود هو أخذ كل شيء بداخلها.

تخيل أن لدينا حاوية بها كائنات متحركة ، كل منها (w = 10 ، h = 10) ، واحدة في (0،0) الثانية واحدة في (100000 ، 100000). ما عرض وارتفاع تلك الحاوية؟ أيضًا ، حتى لو قمنا بإصلاح الحدود بطريقة ما ، فماذا ستؤثر؟

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

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

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

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

نأمل أن يكون هذا منطقيًا ، ويمنحك مفهومًا سريعًا لكيفية تنظيم الحدود في Pixi.

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

يمكنك أن ترى أنه بعد السحب الأول ، تمتد شبكتك خارج حجم منفذ العرض:

image

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

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

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

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

http://codepen.io/anon/pen/yarVwm؟editors=0010

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

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

readygosports picture readygosports  ·  3تعليقات

courtneyvigo picture courtneyvigo  ·  3تعليقات

Makio64 picture Makio64  ·  3تعليقات

zcr1 picture zcr1  ·  3تعليقات

gigamesh picture gigamesh  ·  3تعليقات