[شبه مكتمل] : المرحلة الأولى: تطوير وحدة Core

أود أن أوضح أكثر ما قاله الأخ الشمري بخصوص عمليات transformation، في العالم ثلاثي الأبعاد، لا يمكن التحريك بطريقة مباشرة (أي player.x += amount) لأن الأشكال عبارة عن مثلثات لها رؤوس ذات إحداثيات ثابتة (لا يمكن لـ OpenGL أو Direct3D تغييرها تلقائياً).

هنالك طريقتان عمليتان لتنفيذ الـ transformation:

1. تحديث إحداثيات كل رأس يدوياً كل إطار، وهي طريقة سيئة برأيي، لأن هنالك أشياء لا يمكن عملها بسهولة مثلconcatenation

2. استخدام مصفوفات التحويل من ما يؤدي إلى ترك مهمة الـ transformation لـ OpenGL/Direct3D وكارد الشاشة، وذلك بالطبع هو الحل المثالي الذي يبدو إننا نسير بإتجاهه. :)

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

بخصوص الهيكل الفعلي لـ Matrix فلا مشكلة بالنسبة لي سواءاً column-major أو row-major، يمكن التحويل بينهم بسهولة كما تفضلتم.

@ محمد علاء:

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

الشمري كتب:

- سؤال :

هل هناك فرق بين عملية ضرب نقطة في مصفوفة أو متجه في مصفوفة .. transformVector أو transformPoint .

في حالة النقطة، حاصل الضرب يحسب بطريقة مباشرة.

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

معلومات إضافية:

- مقالة أعجبتني تشرح بشكل تطبيقي كيفية استخدام المصفوفات للتحويل على فلاش (نفس المبدأ تماماً).

- شرح التحويل على كارد الشاشة، الفصل الرابع من كتاب The Cg Tutorial.

اقتباس

ما المقصود بـ seed ؟

المقصود بـ Seed هو رقم يعتمد عليه مولد الارقام العشوائية لتوليد اﻷرقام العشوائية

اقتباس

النسخه التى صنعتها جميله و لكن لماذا لم تعتمد فيها على الـ Templates . ايضا ما المقصود بـ seed ؟

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

أما seed فقد وضّح الأخ أحمد المقصود بها ، حيث خوارزمية توليد الاعداد العشوائية تعتمد على seed number لتوليد عدد عشوائي مختلف كل مرّة .

اقتباس

في حالة النقطة، حاصل الضرب يحسب بطريقة مباشرة.

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

شكرا على التوضيح أخ سلوان .. لم أتصوّر أن الفرق بهذه الصورة ..

بالنسبة لنظام المصفوفات :

خلدون + أحمد : column-major .

محمد علاء + الكون : row-major .

سلوان : لافرق .

رأيي السابق قلته .. وهو اني أميل لصالح row-major مع أنّي لم أستخدمه من قبل :D .. تعوّدت على column-major .

لذلك النظام سيكون row-major order ,

تقريباً انتهينا والحمدلله .. رحلة شاقّة :D .. لكنها ممتعة مع فريق رائع .

سيتم جمع شتات المواصفات في ملفات ..ورفعها كمرفقات وفي svn في المجلد specification .

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

اقتباس

هل أنت متأكد ؟ يبدو لي أنها تتبع نفس نظام Direct3D أي Row-Major .. ومش متأكد طبعا .

لا لست متأكد ولا أدري بناء على ماذا وضعت هذه المعلومه!! :lol:

اقتباس

هل هناك فرق بين عملية ضرب نقطة في مصفوفة أو متجه في مصفوفة .. transformVector أو transformPoint .

رياضيا ليس من المفروض أن يكون هنالك فرق

اقتباس

- عندما نستخدم Scale فاننا نقوم بتحجيم الشكل الثنائي البعد ( أي أننا نكبّر أبعاده أو نصغرها ) ، هل سيتشوّه الشكل .. الجواب :

اذا كانت صورة ( أي اكساء ) .. فانه حتماً سيحصل شيء من التشوّه .. لكن باستخدام تكبير أو تصغير بمقدار مناسب لن يحدث هذا التشوّه ..

طبعا هنا لايوجد شيء اسمه صورة vector في محركات الألعاب .. نحن نستخدم صورة عادية Raster Image

عموما .. نحن نسمح بهذه الخدمة .. فمن أراد أن يستخدمها فليستخدمها .

ولكن إذا كان هنالك Polygon مكون من Vectors طبعا و تم عمل Scale له سوف تتم العملية بشكل جيد.

معلومات إضافية :) :

/index.php?showtopic=192774

ما المدة الزمنية التي سوف نبدأ خلالها التطوير إن شاء الله ؟

اقتباس

سيتم جمع شتات المواصفات في ملفات ..ورفعها كمرفقات وفي svn في المجلد specification .

متى سيتم وضعها ؟؟

الليلة ان شاء الله ..

هل سيكون هناك نص إختباري (test script) لعمل الإختبارات على الكود أم سيترك هذا للمطور؟

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

و الله ولى التوفيق

اقتباس

هل سيكون هناك نص إختباري (test script) لعمل الإختبارات على الكود أم سيترك هذا للمطور؟

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

الخطوة الثالثة : مناقشة الخوارزميات والأفكار وكتابة الكود Implementation

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

core.zip

أما svn ، فحاولت رفعها الى المجلد standards الخاص بالـمواصفات .. ولكن تظهر أيقونة غريبة بعد اضافة الملف add .. لا أعرف ماهو المقصود بها :

ولايظهر أثر للملف في svn في source forge .

الاخ : محمد علاء أو الاخ : سلوان .. أتمنى من أحدكما أن يحاول رفع المجلد core داخل المجلد standards ..

( في حال رفع المواصفات )

يمكن معاينتها من هنا ( شكرا للاخ سلوان ) :

http://andalus-engine.svn.sourceforge.net/...gine/standards/

أو استيرادها svn :

https://andalus-engine.svn.sourceforge.net/...gine/standards/

الان :

• كل عضو يرغب في المشاركة يحدد قائمة بالكلاسات Classes التي يرغب بكتابتها ( أي عدد من الفئات Classes .. ترغب بها وتحدد اللغة التي تريد مثل : الجافا أو السي بلس أو كليهما ) .
  
• يجب أن يعرف نسبة كبيرة من الـ Methods المكونة للكلاس مثلا ..75% من الدوال المكونة للكلاس Class .. يعني مو شرط يعرف كل شيء عن الكلاس .
  
• كل مبرمج سيحصل على قطعة من الكعكة :D .. سيحصل على فئة واحدة One Class أو فئتين Two Classes ... بناء على حجم الكلاس و خبرة المبرمج وعدد الأعضاء المشاركين في البرمجة .. توزيع المهام مهمة صعبة محرجة -_- .. لكن الضرورة تقتضي ذلك .. / المهم ..كل مبرمج يحدد ما يريد وسنحاول معاً أن نتقاسم العمل .
  اذا كان عدد المبرمجين يفوق العدد المطلوب .. فانه سيتم توزيع المهام وفقاً لخبرات الأعضاء و/أو أي الاعضاء قام بكتابة الرد أولاً .. طبعا خبرة العضو مقدمة على الأسبقية :D .
  
• تقسيم العمل الهدف منه مشاركة الجميع وتقليل وقت كتابة الكود وأن يكتب الكود بأفضل طريقة ممكنة
  
• يجب أن تخضع عملية كتابة الكود للعرف البرمجي الذي اتفقنا عليه في مرحلة التخطيط أي نتبع نفس code convention .
  
• كل مبرمج يضيف تجارب على الفئة التي قام بعملها .. لايجب ان تكون تجارب تجارب دقيقة .. حيث نحن الان في مرحلة pre alpha ..
  
• مثال :
  مبرمج تم اسناد مهم Point2D له .. في لغة الجافا و لغة السي بلس بلس معاً :
  1- عليه أن يقوم بعمل Implementation للفئة Point2D ويكتبها بنفس المقاييس التي اتفقنا عليها ، وفي حال وجود أي مشكلة أو شيء غير مفهوم ، يطرح مشكلته في هذا الموضوع لنتشارك في حلّها .
  2- يضيف ملف اخر للتجارب باسم testPoint بحيث تحوي على دالة Method فيها كل التجارب .. ( ممكن تحوي الدالة على دوال أخرى فرعية اذا أردت تقسيم العمل ) .. بهذا الشكل :
  

  void testPoint2D()
  {
  	Point2D<int> p1,p2;
  	.
  	.
  	.
  	print ( p1.x , p1.y);
  	.
  
  	.
  
  	. p1.add( p2);
  
  	print ( p1.x , p1.y);
  
  }

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

للتذكير بالـ code convention:

• 
  
• اسم الملف يكون بنفس اسم الكلاس Class و بنفس حالة الأحرف تماما ، فلو كان اسم Class هو Point2D يكون اسم الملف Point2D .
  
  
• الجافا والسي شارب تتبعان أسلوب كتابة الأكواد الأصلي في اللغة .
  
  
• للغة السي بلس :
  
• تسمية المتغيرات والدوال والأصناف
  
  
  namespace Andalus
  {
  namespace Gfx
  {
  class Graphics
  {
  virtual void drawPoint(int x,int y ,Color color)=0;
  };
  class D3dGraphics : public Graphics
  {
  private:
  Color pointColor;
  int xPos;
  int yPos;
  void _privateFunction();
  public:
  void drawPoint(int x,int y,Color color)
  {
  const int MAX_XPOS = WINDOW_WIDTH ;
  int tempVariable = 0;
  int i,j,k;// counters
  this->pointColor = color;
  this->xPos = x;
  this->yPos = y;
  .
  .
  .
  }
  };
  }//gfx
  }//andalus
  

  
  

• كل كلاس class يكون في ملف مستقل ( ملف header للتعريف فقط وخالي من أي implementation قدر الامكان وملف source لكتابة الكود ) , ويكون اسم الملف مطابق تماما لاسم الكلاس حتى بحالة الاحرف.
  
• يتم حراسة ملف الهيدر بالـ preprocessor بهذا الشكل :
  

  #ifndef GFX_Graphics_H
  #define GFX_Graphics_H
  .
  .
  #endif

  
  

• يتم تنظيم الكود و يتم استخدام الأقواس { } دائما مع for او if حتى لو كان الكود مكون من سطر واحد و ذلك لوجود ملاحظات فوق الكود و ايضا لتسهيل قرائة الكود، ايضا يمكنك استخدام تلك الأقواس فقط مع بعض الأكواد لتجميعها و ذلك لتنظيم الكود.
  
• اسماء الفئات و الـ strcut و enum و union كلها تبدأ بحروف كبيره و بدون استخدام بادئة , وجميعها تكون داخل namespace معين.
  
• اسماء المتغيرات تبدأ بحروف صغيره و اى كلمه تليها بدأ بحروف كبيره.
  
• اسماء الدوال تبدأ بحروف صغيرة و اسماء المعاملات تكون بحروف صغيره دائما.
  
• يتم تعريف المتغيرات قبل استخدامها و يتم كتابة ملاحظات فوقها لسبب تعريف هذا المتغير و فيما استخدامه
  
• سيتم استخدام الكلمة interface للدلالة على الواجهات , والكلمة pure للدلالة على pure funcion , هكذا :
  

الشمري كتب:

أما svn ، فحاولت رفعها الى المجلد standards الخاص بالـمواصفات .. ولكن تظهر أيقونة غريبة بعد اضافة الملف add .. لا أعرف ماهو المقصود بها :

ولايظهر أثر للملف في svn في source forge .

الاخ : محمد علاء أو الاخ : سلوان .. أتمنى من أحدكما أن يحاول رفع المجلد core داخل المجلد standards ..

تم رفع الملفات، يرجى عمل Update في مجلداتكم المحلية (من الأفضل أن تصبح هذه عادة :) ، كل مرة يبدأ أحدكم العمل يقوم بعمل Update أولاً لكي يعمل على آخر إصدار).

التغييرات لن يتم رفعها للسيرفر تلقائياً، وهذه ميزة مفيدة لأنك تستطيع أن تغير في الملفات كما تشاء حتى تصل للشكل النهائي وبعد ذلك تقوم برفعها عن طريق الأمر Commit.

علامة "+" الزرقاء تعني إن الملفات قد تمت فعلاً إضافتها لديك ولكن محلياً (أي لم يتم رفع التغييرات للسيرفر)، كل ما تحتاج القيام به بعد ذلك عمل Commit لإضافة الملفات الجديدة للسيرفر.

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

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

-----------------------------------------

@ الشمري:

من جهة code convention هنالك نقطة إضافية أتمنى أن تذكرها وهي طريقة تسمية ملفات الكود نفسه، إن ذكرت هذه النقطة سابقاً فلا تهتم.

بارك الله فيك أخ سلوان .. عمل رائع ,

اقتباس

من جهة code convention هنالك نقطة إضافية أتمنى أن تذكرها وهي طريقة تسمية ملفات الكود نفسه، إن ذكرت هذه النقطة سابقاً فلا تهتم.

يبدو لي أن هذه النقطة موجودة في مكان ما ..

عموما ، اسم الملف دائما = اسم الكلاس Class بنفس حالة الأحرف تماما . ( سأحرر المشاركة السابقة للتأكيد على ذلك ) ,

نسيت أن اذكر قائمة بالكلاسات التي بامكاني تطويرها :

- Poin2D

- Vector2D

- Matrix3x3

- Random

- Rectangle

بلغة الجافا ولغة السي بلس ..

بانتظار بقية الاعضاء .

أرحب بالعمل فى الفئات التاليه

 

Math

Point2D

Line2D

Circle

Rectangle

Vector2D

Triangle

Matrix3x3

يعنى ممكن تقول كلهم ماعدا Random :D

انا راجعت الملفات و لقيت كام نقطه محتاجين يتعدلوا وهم (فى الأغلب كلهم اخطاء كتابيه اثناء تجميع الملفات)

- النوع Line2D و Triangle المفترض انهم template لكن انت مصرح عنهم بشكل عادى فى حين ان الدوال داخلهم بتستخدم النوع T.

- كل الفئات بشكل عام تحتوى على بعض الدوال التى من المفترض ان لها نوع template بالإضافه للنوع الذى يتم تمريره للفئه و لكن فى حالتنا هذه نجد انك قد حذفت كل الأنواع الإضافيه ماعدا النوع الخاص بالفئه.

- داخل النوع Matrix توجد الداله determined و التى قمت بتعريفها كأنها void فى حين انها من المفترض ان تعود بقيمة المصفوفه و هى المفترض ان تكون float و ليس void.

- داخل النوع Matrix توجد الداله transformPoint و التى تأخذ معامل من النوع Point و اجد انك قد كتبت ملاحظه انها تختلف عن المتجه طبقا لكلام الأخ سلوان. ما خشيناه قد وقعنا فيه و هو الإلتباس بين النقطه و المتجه، قلنا و على الرغم من أن الإثنين يحتووا على نفس العدد من المتغيرات إلا أنه منطقيا كل واحده لها استخدام فمثلا لن يطلب منك تدوير نقطه و لكن سيطلب منك تدوير متجه حيث ان النقطه هى مكان شئ ما، اما المتجه فهو اتجاه هذا الشئ دعونا لا نخلط الأمور ايضا دعونا لا ننظر لمحتوياتهم و لكنا ننظر لإستخداماتهم.

- داخل النوع Matrix نسينا اضافة الداله Shear و التى تغير محتويات عناصر القطر الرئيسى فقط داخل مصفوفة الوحده.

- داخل النوع Matrix يوجد مشيد غير مفهوم و هو الذى يأخذ مصفوفة احادية البعد، فعلى اى اساس سيتم توزيع قيمهم داخل المصفوفه؟.

- داخل النوع Point (و يمكن تطبيق هذا السؤال ايضا على باقى الأنواع) توجد الدوال Add و sub هل داخل الـ c++ سيتم تحويلهم للعلامات الرياضيه ام سيتركوا كما هم حيث إذا كان سيتم تحويلهم فلا داعى من النسخ الـ static حيث ان السابقين سيقوموا بنفس الوظيفه.

- داخل النوع Rectangle اوصى جدا جدا بتغير المسمى bottom إلى down حيث ان المتغيرات ستصف النقطه العليا باليسار top-left (داخل الإحداثى الديكارتى) و النقطه السفلى باليمين down-right و بالتالى المسمى bottom سيسبب تشتت حيث انه مبهم قليلا.

- داخل النوع Line2D الداله slopeBetweenPoints تعود بـ double و كنا قد اتفقنا على ان النوع العشرى الذى سيتم التعامل به هو float لإن التعامل معه اسرع من double.

- داخل النوع Random توجد داله واحده فقط لـ seed مع العلم انه توجد ايضا دالة generateFloat و قد نحتاج لوضع قيمه عشريه مبدئيه بدلا من رقم صحيح.

هذه الملحوظات يمكن اخذها فى الإعتبار الأن او يمكن تطبيقها داخل اصدارات احدث من المحرك (لقد كتبتهم هنا حتى لا انساهم)

* عدم وجود 4 نقاط يصفوا مكان النوع Rectangle سيمنع دورانه اى اننا لا نستطيع عمل rotate له ابدا

* توجد بعض الدوال التى قد نضيفها فيما بعد مثل move و rotate للخط و المثلث و المستطيل: و بالنسبه لـ rotate يمكن تحديد النقطه التى نريد عمل له rotate حولها و بالنسبه لـ move يمكن تحديد المحور الذى نريد تحريك عليه بقيمه سالبه او موجبه لأعلى و اسفل و اليمين و اليسار.

سأنتظر الردود و بعدها ساقوم بإضافتهم داخل svn بعد تعديل ما سنتفق عليه.

يبدو انى بشارك على طول بعد ما بيتم التنفيذ، عموما برضه هعمل update للملفات :D بس بعد ما نتفق على الملاحظات الموجوده بالاعلى

اه نسيت انا اعمل بالـ Cpp.

و الله ولى التوفيق

ما شاء الله .. أخ محمد .. تستحق لقب عين الصقر :) .. عن جدارة ... ماشاء الله تبارك الله ..

كل النقاط التي ذكرتها هي أخطاء لذلك قم بتعديلها بشكل مباشر على svn ، وسأقوم باعادة رفعها في المرفقات في المشاركة السابقة ..

باستثناء النقاط التالية .. فعلتها عن عمد :

اقتباس

- كل الفئات بشكل عام تحتوى على بعض الدوال التى من المفترض ان لها نوع template بالإضافه للنوع الذى يتم تمريره للفئه و لكن فى حالتنا هذه نجد انك قد حذفت كل الأنواع الإضافيه ماعدا النوع الخاص بالفئه.

فكرت في هذه النقطة كثيرا ، حيث أنك تكتب شيء شبيه بالتالي /

class Line2D<T>
{
	 template <typename S>
	static Point2D<S> func( Point2D<S> p1)
}

- المبرمج النهائي ، يجب عليه أن يحدد النظام الذي سيسير عليه integer أو float أو double .. الخ .

فلا أرى أن يتم خلط float مع int مثلا .. لأنه سينتج لدينا نتائج مختلفة بسبب اختلاف الأنواع ، ممكن نضطر أن نعمل cast لبعضها .

لذلك المبرمج لايجب أن يكتب شيء كهذا :

Line2D <int> line;
Point2D < float > point;
line.func<float>(point);

السبب الاخر ، هل لغات البرمجة الأخرى مثل الجافا تدعم خلط أكثر من نوع في نفس الكلاس ؟

السبب الأخير ، قمت بالبحث في محركات مشهورة .. ووجدتها تعتمد على نوع واحد تسميه مثلا T في كل الكلاس ، لذلك استخدم T في كل برنامجك .

هذا ما استنتجته .. هل هناك من يعرف شيء عن هذه النقطة ؟

اقتباس

- داخل النوع Matrix توجد الداله transformPoint و التى تأخذ معامل من النوع Point و اجد انك قد كتبت ملاحظه انها تختلف عن المتجه طبقا لكلام الأخ سلوان. ما خشيناه قد وقعنا فيه و هو الإلتباس بين النقطه و المتجه، قلنا و على الرغم من أن الإثنين يحتووا على نفس العدد من المتغيرات إلا أنه منطقيا كل واحده لها استخدام فمثلا لن يطلب منك تدوير نقطه و لكن سيطلب منك تدوير متجه حيث ان النقطه هى مكان شئ ما اما المتجه فهو اتجاه هذا الشئ دعونا لا نخلط الأمور ايضا دعونا لا ننظر لمحتوياتهم و لكنا ننظر لإستخداماتهم.

نعم .. كلامك صحيح .. لكن وجدت محرك مثل ogre و irrlich يستخدمون Vector هكذا transformVector .. بينما في الرابط الذي وضع الاخ سلوان ، يوجد فرق بين transformVector .

فقلت في نفسي .. أظن المحركات لاتهتم كثيرا .. فهي عندما تضع vector تقصد نقطة عادية ..

لكن لامانع .. يمكنك أن تختار نوع معين مثل Vector أو Point، لحل هذا الاشكال ، مع أني أميل الى Vector لانه هو الاكثر استخداما حسب ما رأيت في محركات الالعاب ، حتى لو كان هناك اختلاف بين Point و Vector .. لذلك اختر الحل المناسب .

اقتباس

- داخل النوع Matrix نسينا اضافة الداله Shear و التى تغير محتويات عناصر القطر الرئيسى فقط داخل مصفوفة الوحده.

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

اقتباس

- داخل النوع Matrix يوجد مشيد غير مفهوم و هو الذى يأخذ مصفوفة احادية البعد، فعلى اى اساس سيتم توزيع قيمهم داخل المصفوفه؟.

نسيت أن اشرح هذه النقطة .

في الكلاس matrix قمت بتحويل members من متغيرات مثل m11 , m12 , m13 .. الى مصفوفة من 9 خانات هكذا :

T m[9]

والسبب .. هو أن المصفوفة اكثر مرونة من المتغير ، حيث يمكن عمل loop بسهولة .. أو استخدامها مثلا مع memcpy .

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

شاهدت محركات الالعاب تعتمد على المصفوفة لتمثيل الماتركس .

بالنسبة للمشيد .. الذي يستقبل مصفوفة احادية البعد .. ببساطة .. تنسخ محتويات المصفوفة الموجودة في البارمترات في المصفوفة m ( والتي هي member ) ,

لتصبح المصفوفة هكذا :

[ m[0]  m[1]  m[2]]   
[ m[3]  m[4]  m[5]]   
[ m[6]  m[7]  m[8]]

اقتباس

- داخل النوع Point (و يمكن تطبيق هذا السؤال ايضا على باقى الأنواع) توجد الدوال Add و sub هل داخل الـ c++ سيتم تحويلهم للعلامات الرياضيه ام سيتركوا كما هم حيث إذا كان سيتم تحويلهم فلا داعى من النسخ الـ static حيث ان السابقين سيقوموا بنفس الوظيفه.

نعم .. كلامك صحيح .. ولكن هذا كان مما توصلنا اليه ..

عدّل كما تراه مناسب .

اقتباس

- داخل النوع Rectangle اوصى جدا جدا بتغير المسمى bottom إلى down حيث ان المتغيرات ستصف النقطه العليا باليسار top-left (داخل الإحداثى الديكارتى) و النقطه السفلى باليمين down-right و بالتالى المسمى bottom سيسبب تشتت حيث انه مبهم قليلا.

لا أرى ذلك اخ محمد ..

صحيح أني سيء بالانجليزية :) .. لكن bottom عكسها top أما كلمة down عكسها up .

أي كلاس Rectangle ستجد أن كلمة bottom متعلقة به .. انظر مثلاُ للتركيب RECT في Win32 APIs .

لذلك هذه التسمية الصحيحة .

اقتباس

- داخل النوع Line2D الداله slopeBetweenPoints تعود بـ double و كنا قد اتفقنا على ان النوع العشرى الذى سيتم التعامل به هو float لإن التعامل معه اسرع من double.

صحيح .. غيرها ..

اقتباس

* عدم وجود 4 نقاط يصفوا مكان النوع Rectangle سيمنع دورانه اى اننا لا نستطيع عمل rotate له ابدا

نعم صحيح .. لكن يمكن بسهولة استخراج هذه النقاط لو احتجنا لها عن طريق :

 	[ByVal] Point2D<T> getUpperLeftPoint();
	[ByVal] Point2D<T> getLowerRightPoint();
		[ByVal] Point2D<T> getLowerLeftPoint();
	[ByVal] Point2D<T> getUpperRightPoint();

اقتباس

* توجد بعض الدوال التى قد نضيفها فيما بعد مثل move و rotate للخط و المثلث و المستطيل: و بالنسبه لـ rotate يمكن تحديد النقطه التى نريد عمل له rotate حولها و بالنسبه لـ move يمكن تحديد المحور الذى نريد تحريك عليه بقيمه سالبه او موجبه لأعلى و اسفل و اليمين و اليسار.

هذه من مهام matrix ، حيث يمكننا اضافة دوال مثل trandformRectangle و transformTriangle .. الخ ...

انظر irrlicht :

http://irrlicht.sourceforge.net/docu/class..._c_matrix4.html

لكن هل ترى أن نضيفها الان ؟

أوافق .. لكن لا أدري عن اراء بقية الاخوان ..

اقتباس

نعم .. كلامك صحيح .. لكن وجدت محرك مثل ogre و irrlich يستخدمون Vector هكذا transformVector .. بينما في الرابط الذي وضع الاخ سلوان ، يوجد فرق بين transformVector .

فقلت في نفسي .. أظن المحركات لاتهتم كثيرا .. فهي عندما تضع vector تقصد نقطة عادية ..

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

اقتباس

أرى ذلك اخ محمد ..

صحيح أني سيء بالانجليزية regular_smile.gif .. لكن bottom عكسها top أما كلمة down عكسها up .

أي كلاس Rectangle ستجد أن كلمة bottom متعلقة به .. انظر مثلاُ للتركيب RECT في Win32 APIs .

لذلك هذه التسمية الصحيحة .

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

اقتباس

اقتباس

عدم وجود 4 نقاط يصفوا مكان النوع Rectangle سيمنع دورانه اى اننا لا نستطيع عمل rotate له ابدا

نعم صحيح .. لكن يمكن بسهولة استخراج هذه النقاط لو احتجنا لها عن طريق :

[ByVal] Point2D<T> getUpperLeftPoint();
	[ByVal] Point2D<T> getLowerRightPoint();
		[ByVal] Point2D<T> getLowerLeftPoint();
	[ByVal] Point2D<T> getUpperRightPoint();

اخى عبد الله انظر هذه الصوره

فى الصوره السابقه قمت بصنع مستطيل بإستخدام الفئه الخاصه بنا و النقاط من P1 إلى P2 تمثل الكائن Point2D الذى يحتوى على العناصر top و left و bottom و right.

بعد ذلك افترضت وجود الداله move و قمت بتحريك المتسطيل لأعلى بعدها افترضت وجود الداله rotate داخل المستطيل و قمت بتدويره لذا عملية التدوير لها حالتين:

1 - إذا كنا نستخدم المتغيرات top و left و bottom و right فكل ما سيحدث هو اعادة تحجيم للمستطيل (النسخه الخضراء) حيث اننا لدينا top و left و bottom و right و هما يحددوا النقطه العلويه باليسار و النقطه السفليه باليمين و لكن لا وجود للنقطتين الأخرين و بالتالى فعملية التدوير فى هذه الحاله ما هى إلا عملية تحجيم للمستطيل فقط. و لإثبات كلامى بعد تدوير المستطيل قم بمحاولة رسمه و ستجد ان امامك مستطيل قاعدته دائما (او سقفه) يوازى المحور X.

2 - الحاله الثانيه وجود الأربع نقاط داخل المستطيل و الذين يصفوا موقع كل ركن من اركانه للمحور X و Y، فعند التدوير كل واحده منهم ستأخذ موقع جديد (النسخه السوداء الموجوده فوق الخضراء) لذا عند محاولة رسم الخطوط من النقطه P1 إلى النقطه P4 ستجد مستطيل تم تدويره اى ان قاعدته او سقفه لا يوازى المحور X.

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

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

اقتباس

ولكن هل ترى أن نضيفها الان ؟

أوافق .. لكن لا أدري عن اراء بقية الاخوان ..

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

و الله ولى التوفيق

Muhammad alaa كتب:

هذه الملحوظات يمكن اخذها فى الإعتبار الأن او يمكن تطبيقها داخل اصدارات احدث من المحرك (لقد كتبتهم هنا حتى لا انساهم)

* عدم وجود 4 نقاط يصفوا مكان النوع Rectangle سيمنع دورانه اى اننا لا نستطيع عمل rotate له ابدا

* توجد بعض الدوال التى قد نضيفها فيما بعد مثل move و rotate للخط و المثلث و المستطيل: و بالنسبه لـ rotate يمكن تحديد النقطه التى نريد عمل له rotate حولها و بالنسبه لـ move يمكن تحديد المحور الذى نريد تحريك عليه بقيمه سالبه او موجبه لأعلى و اسفل و اليمين و اليسار.

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

لا شك إنك سمعت من قبل بمصطلحي الفضاء المحلّي وفضاء العالم (Local Space and World Space)، ببساطة هنالك مرحلتين في كل مرحلة يمتلك الشكل موقعاً مختلفاً... في المرحلة الأولى يكون الشكل في مكانه المحلي بالنسبة لنقطة الأصل وإحداثيات كل نقطة له ثابتة ولا تتغير في الحالات الإعتيادية.

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

ينطبق نفس الكلام على أي شكل، وهذه هي قوة المصفوفات وإلا لماذا سنصدع رؤوسنا بها إن لم تكن لها فائدة قيّمة؟ ;)

يمكنك قراءة أي كتاب حول رياضيات الألعاب او الرسوميات لتتعمق أكثر حيث هنالك عدد آخر من المصفوفات التي تؤثر على الشكل وليس فقط مصفوفة التحويل للعالم، مثلاً مصفوفة الكاميرا والتي تعرّف موقع الكاميرا ويمكنها أن تتحكم بالمشهد ككل سواءاً حركة أو دوران أو zoom، وهنالك مصفوفة الإسقاط التي تحدد نسبة الإسقاط ومجال النظر، وهي جميعها ستستخدم في محرّك الأندلس في حالة OpenGL و Direct3D.

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

كما إني لا أشك إن هنالك من كتب دروساً جيدة حول هذا الموضوع هنا في المنتدى.

اقتباس

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

لابأس .. يبقى لدينا mutiply التي تستقبل vector وتعيد vector ( النسخة التي وضعتها أنت اخ محمد ) .. وهي الأصلية ، وبقية الدوال التي اضفتها بنفسي وهي transformPoint احذفها من النسخة 0.1 ( قد تعود يوماً ما :D ) .

عموما .. كان الهدف أن يصبح لدينا هذه الدوال في Matrix :

transfromPoint

transformRectangle

transformTriangle

transformLine2D

الخ ..

حيث المصفوفة ستقوم : بتدوير أو ازاحة أو تحجيم النقاط المكونة للشكل . ( حسب نوع المصفوفة سيتغير موقع النقاط )

لذلك وكما قال الاخ سلوان ، لاحاجة إلى أن نضيف شيء مثل rotateTriangle ; لأنك ستكتب شيء هكذا :

Matrix3x3 m;
m.identity();
m.rotate(45);
m.translate(x,y);
Rectangle rect(10,10,20,20);
rect = m.transformRectangle(rect);

ستقوم الدالة tranformRectangle باستخراج كل نقطة على أنها Point2D أو Vector2D حسب ما تريد ... ومن ثم تستدعي transformPoint لتقوم باللازم .

هذه فكرة عامة .. أذكر أني جربتها ، ونجحت .. فهي فكرة بسيطة .

اقتباس

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

اذا حصلت على نقطتين تستطيع الحصول على باقي النقاط .

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

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

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

ما رأيكم هل يبدأ الـ Implmentation؟

اقتباس

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

اخى سلوان، انا درست برمجة الالعاب من فتره طويله و لفتره طويله و لكن من منظور ثلاثى الأبعاد و مشكلتى هى انى لا استطيع اعادة هيكلة الرياضيات التى كنت اطبقها على شكل له طول و عرض و ارتفاع على شكل له طول و عرض فقط.

ارجو ان تعذرنى فإن ذاكرتى اصبحت ضعيفه تلك الأيام من كثرة العمل لذا صحح لى ان اخطئت

اقتباس

لا شك إنك سمعت من قبل بمصطلحي الفضاء المحلّي وفضاء العالم

اخى سلوان اقرأ معى هذا الإقتباس

اقتباس

لتقوم بتدوير مجموعة من رؤوس سطح موجود فى نظام إحداثى ثنائى الأبعاد، سنقوم بإستخدام المعادلات التالية لكل نقطة على حدى :

NewX = OldX × cos (θ) −OldY × sin (θ)
NewY = OldX × sin (θ) + OldY × cos (θ)

فى المعادلات السابقة، OldY ،OldX هما البعدين Y ،X للرأس التى سنديرها، و الدلتين Sin ،Cos هما دوال رياضيه و أسمائهما هى Cosine و Sine أما الرمز θ فيسمى بـ Theta و تمثل الزاوية التى سنقوم بإدارة الرأس إليها و تعطى قيمة لها بإستخدام Radians - و هو نظام يسمى بالزاوية النصف قطرية و فيه تمثل الزاوية برقم عشرى - و ليس بنظام قياس الدرجات Degrees، و السبب فى ذلك هو ان معظم مكتبات الـ 3D و منها الـ DirectX تستخدم النظام Radians لحساب الزوايا.

هذا الإقتباس من ترجمتى للفصل الأول لكتاب Graphics Programming with DirectX9 لـ GameInstitute (يمكنك تحميله من هنــا - الإقتباس من صفحة 28)

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

لهذا لابد من وجود اربعة رؤوس للمستطيل و ليس اثنان.

اقتباس

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

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

و الله ولى التوفيق

اقتباس

ما رأيكم هل يبدأ الـ Implmentation؟

نعم .. ولكن ننتظر بقية الاعضاء .. ممكن هناك من يرغب باختيار كلاس معين ، حتى يتم توزيع الكعكة بشكل عادل ;) .

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

لننتظر حتى المساء ، ليشاهد الاعضاء التطوّرات ..

هل ترغب يتطوير شيء اخ سلوان .. ان كنت تملك شيء من الوقت .

Muhammad alaa كتب:

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

لهذا لابد من وجود اربعة رؤوس للمستطيل و ليس اثنان.

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

أما المستطيل فيمكن أن يمثل نافذة، صندوق للتعرف على التصادم (bounding box)، مساحة منتظمة من الشاشة مثلاً ساحة اللعب، وليس مختصاً تحديداً بتمثيل المستطيلات المرسومة، لذلك من الأفضل تبسيطه قدر الإمكان للمستخدم، ولهذا تجد 95% من المكتبات والأنظمة تمثله باستخدام نقطتان (سواء left/top/right/bottom أو x/y/width/height) و 100% من المكتبات التي استخدمتها، أمثلة:

ClanLib: Rect and Quad

HGE: Rect and Quad

Irrlicht: Rect

Ogre3D: Rectangle Rectange2D TRect

Windows API: RECT System.Windows.Rect

wxWidgest: wxRect

Muhammad alaa كتب:

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

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

لماذا نستعجل؟ أم هل تود إنهاء المحرك في إسبوع؟ ;)

لدينا وقت لكل شيء، وفي هذه اللحظة، لنركز على تصميم مكتبة رياضية مبسّطة عامة.

أتمنى أن لا تكون تضايقت مني بسبب هذا النقاش؟

الشمري كتب:

هل ترغب يتطوير شيء اخ سلوان .. ان كنت تملك شيء من الوقت .

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

اقتباس

أتمنى أن لا تكون تضايقت مني بسبب هذا النقاش؟

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

اقتباس

أنت تخلط بين مفهومين

اقتباس

الـ Rect له استخدامات كثيرة غير الرسم، وهنالك هيكل مشابه مخصص تحديداً للرسم كما جرت العادة، ويسمى Quad

لقد كتبت كلام كثير بهذه المشاركه و لكنى حذفته لأنى لاحظت فعلا انى اخلط بين الـ Rectangle و الـ Size و الـ Quad.

صحح لى ان كنت مخطئ:

الـ Rectangle : يستخدم فى وصف مساحة على الشاشه و يتيح التعامل معها كأن تعرف هل هى خاليه ام لا او تدمجها مع Rect اخر، بإختصار التعامل مع المستطيلات البسيطه و التى تمثل بمساحه و نقطة بدء.

الـ Size : يستخدم للتعبير عن طول و عرض و يمكن ان يستخدم ضمنيا داخل الـ Rect.

الـ Quad : و يستخدم فى تمثيل رؤوس المستطيل الذى يحتوى شئ سيتم رسمه هذا بالإضافه للرؤوس نفسها التى يمكن التحكم التحكم فيها.

و الله ولى التوفيق

الفئات التي أستطيع عملها

Line2D
Point2D
Rectangle
Triangle
Circle
Matrix3x3
Vector2D

اللغة المستخدمة الجافا

النوع الذي سوق أعمل معه float

السلام عليكم

ماشاء الله الشباب لم ينامو..:)

دخلت لأقرأ التطورات بشكل سريع، وسوف ارد مساء اليوم (بسبب الدوام) عن الكلاسات التي سوف أقوم ببرمجتها إن شاء الله، طبعا سوف أعمل على نسخة ال C#.

بالتوفيق