التجاوب والدقة (الاستجابة والدقات)
كيف يُبقي Easelt واجهتك الرسومية مطابِقة بالبكسل لـ MTA:SA على كل شاشة.
في Easelt Builder، لا يُثبَّت التخطيط أبدًا على البكسل — فكل موضع وحجم يُخزَّن كـ كسر من الشاشة بين 0 و1، تمامًا مثل كود dxDraw المكتوب بإتقان. هذه الفكرة الواحدة هي ما يتيح لك تصميم واجهة رسومية مرة واحدة، بأي دقة، وأن تظهر بشكل صحيح على شاشة كل لاعب في MTA:SA.
كسور، لا بكسلات
بدلًا من أن تتذكر أن لوحة ما تقع عند 768px، فإنك تصفها بأنها *بنسبة 40% عرضًا* على الشاشة. قيمة x تساوي 0.40 تعني 40% من الحافة اليسرى، وقيمة y تساوي 0.30 تعني 30% نزولًا من الأعلى، وعرض قيمته 0.20 يعني أن العنصر يشغل خُمس عرض الشاشة. لأن هذه الكسور نسبية، فإنها تصف التخطيط نفسه بغض النظر عن حجم الشاشة الفعلي — وهذه هي بالضبط طريقة كتابة مبرمج MTA:SA الحريص لكود dxDraw يدويًا.
تتراوح الكسور من 0 (الحافة اليسرى أو العليا) إلى 1 (الحافة اليمنى أو السفلى). القيمة 0.5 هي المنتصف تمامًا على ذلك المحور.
كيف تحوّل المعاينة الكسور إلى بكسلات
تُعرَض لوحة المعاينة في فضاء بكسلات اللعبة بأي دقة تختارها. لوضع عنصر ما، يضرب Easelt Builder كل كسر في أبعاد اللعبة — وهذا مطابق تمامًا للحسابات التي يُجريها MTA داخليًا، لذا فما تراه هو ما ترسمه اللعبة.
- موضع البكسل =
fraction * gameWidth(أوgameHeightللمحور الرأسي). - المقياس العام
S = gameHeight / 1080يوسّع عرض الخطوط وأحجام النصوص بحيث تبقى الخطوط والتسميات صحيحة بشكل متناسب عند أي دقة. - لأن كليهما يستخدم الصيغ نفسها مثل MTA:SA، فإن الموضع على الشاشة في المحرر يساوي الموضع داخل اللعبة.
المقياس S مرتبط بمرجع ارتفاعه 1080 بكسل. عند 1080p، يكون S = 1؛ وعند 4K (ارتفاع 2160)، يكون S = 2، لذا يتضاعف حجم الخطوط والنصوص لمطابقة الشاشة الأكثر كثافة.
محدِّد الدقة
يوجد محدِّد الدقة في الشريط العلوي ويتحكم في حجم لوحة المعاينة. تبديل الدقة يغيّر أبعاد اللوحة بينما تبقى كسورك ثابتة — لذا يحتفظ كل عنصر بالموضع النسبي نفسه، ويظل موضعه على الشاشة مساويًا لموضعه داخل اللعبة.
تغيير الدقة لا يحرّك عناصرك أبدًا بالمعنى النسبي — تتغير أبعاد اللوحة فقط. الكسور هي مصدر الحقيقة.
مثال محلول
إليك العنصر نفسه — المثبَّت عند x = 0.40, y = 0.30 — محلولًا إلى بكسلات عند دقتين مختلفتين. لاحظ كيف لا تتغير الكسور أبدًا، بل تتغير فقط قيم البكسل الناتجة عنها.
| الكسر | عند 1920×1080 | عند 3840×2160 (4K) |
|---|---|---|
| x = 0.40 | 0.40 × 1920 = 768 px | 0.40 × 3840 = 1536 px |
| y = 0.30 | 0.30 × 1080 = 324 px | 0.30 × 2160 = 648 px |
| scale S = gameHeight / 1080 | 1080 / 1080 = 1.0 | 2160 / 1080 = 2.0 |
يقع العنصر عند 40% عرضًا و30% نزولًا على كلتا الشاشتين — متطابق بصريًا — بينما تنمو البكسلات الأساسية ومقياس النص/الخط مع الدقة.
ما الذي يُصدَّر
عند التصدير، تخرج الإحداثيات بـ صيغة الكسور نفسها التي صمّمت بها، مضروبةً في حجم الشاشة الحيّ. فعنصر عند x = 0.40, y = 0.30 يُصدَّر على النحو التالي:
local sx, sy = guiGetScreenSize()
dxDrawRectangle(0.40 * sx, 0.30 * sy, --[[ width, height, ... ]] )يقرأ السكربت المُصدَّر حجم الشاشة الحقيقي عبر guiGetScreenSize() ويحافظ على كسورك سليمة، لذا يبدو الكود المُولَّد مثل كود dxDraw المكتوب يدويًا الذي كنت ستكتبه بنفسك.
التكيّف أثناء التشغيل
يمكن للاعبين تغيير دقة الشاشة داخل اللعبة أثناء تشغيل موردك. للتعامل مع ذلك، يستمع السكربت المُصدَّر أيضًا إلى `onClientRestore` ويعيد حساب sx وsy والمقياس العام كلما استُعيدت الشاشة — بحيث تعيد الواجهة الرسومية ترتيب نفسها وتبقى صحيحة حتى لو تغيّرت الدقة أثناء التشغيل.
لأن الكسور ثابتة ويُعاد حساب sx وsy وS عند onClientRestore، فلن تحتاج أبدًا إلى شحن تخطيطات منفصلة لدقات منفصلة.
الخلاصة
صمّم مرة واحدة بأي دقة، صحيح على الجميع. خزّن التخطيط ككسور، ودع المعاينة تحلّها إلى بكسلات اللعبة بحسابات MTA نفسها، واختر أي دقة تريد التصميم بها، وصدّر كودًا يعيد حساب نفسه أثناء التشغيل. تبدو واجهتك الرسومية نفسها لكل لاعب، بغض النظر عن شاشته.