اگه ی موی کلیپ بخایم ببینیم به کدوم موی کلیپه دیگه هیت میشه اما موی کلیپای دیگمون خیلیییییی زیاد باشن چجوری میشه فهمید اگه به یکیشون هیت شد فلان کارو بکنه؟ یه چیزی مثل e.target تو کلیک که برای کلیک رو هر موی کلیپیه
یعنی به صورت خطی ؟ از اول همشونو چک کردی و همینکه به اونی که هیت داره رسیدی break کردی ؟البته شاید راههای بهتری هم باشه ...راههایی که به جای اینکه کارها خطی باشه- (O(n)- بشه راحت تر با مختصات و اینا درش آورد ...
راه زیاده اما نمیخاستم حسابی وقت گیر شه وگرنه میشه خیلی کارا باهاش کرد . اما cpu رو هم بیشتر درگیر میکنن . و کلی برنامه نویسی !
با شی که دارین ی هیت پوینت بذارین روی نقطه های حساسی که میخاین و اشیای دیگرو تو یه شی که اونو با شی خودتون میخاین هیت پوینتش کنین قرار بدین. به همین سادگی . در واقه کاریه که خوده فلش میاد میکنه اما اگه بخاهیم باهاش حسابی کار کنیم میشه از draw api استفاده کرد و اتچ چیلد . کارای دیگه ای هم میشه کرد که هی مصرفه cpu رو افزایش میدن
منم یه کارایی تو این مایه ها کردم .
اگه می شد تعیین کرد که یه شی به خصوصی ، الان به چه شیی برخورد کرده البته بدون محاسبه تک تک برخورد ها ، خیلی عالی می شد . یعنی از یه حالت event یا حالت محاسبه همه برخورد ها رسیدن به اولین برخورد در حلقه for به حالت اینکه دقیقا بگیم این شی به این شی من خورده . یعنی به جای n محاسبه ، 1 محاسبه . البته می شه با تعیین محدوده شی به خصوص و اینکه در چه مختصاتی هست ، پی به این برد ولی مثلا یه روش مستقیمی بود که با کوچکترین محاسبه بشه این کار رو کرد .... البته با oop یه راههایی تو ذهنم هست که شاید یه سمپل به زودی گذاشتم ... موفق باشی ...
ی مشکلی که هست اینه که حالا برخوردو دتکت کردیم اما اگه موقه برخورد دوتا شی بهم بخاهیم از تو رفتن جلوگیری کنیم و در واقه rigid رو پیاده کنیم بستگی به سرعته حرکته اونها داره و اگه از 1 بیشتر باشه یکم سخت میشه ! چون فرض کنیم ی شی تو موقعیت x=18 باشه و دیگری توی x=50 و با سرعت 10X به سمت اون در حرکت. حالا وقتی به x=20 رسید هنوز به x=18 نرسیده و برخوردی نیست اما به محضی گام بعدیو برداشت به x=10 میرسه و حالا برخورد رخ داده اما توی اونم رفته و ماهم برای پس زدنش باید 10x اونو دور کنیم که باعث میشه 2X ازش دور بمونه !! حالا اگه 1X 1X اونو دور کنیم تا موقعی که از جسم بیرون بره چون اون داره با سرعت 10X باز میاد به طرفش کم کم باعث میشه نرم بره توی شی و ازش رد شه !
برای کالیژن دتکت ی راه بسیار عالی که وجود داره و فکر می کنم موتورها هم از همین استفاده کنند مپ کردنه . و طبقه مپ از draw api استفاده کنیم . حالا مپه هر آبجکت دستتونه و به راحتی میتونین بهترین کالیژن دتکتو با دقته باور نکردنی بسازین . برای ریجید هم فکر کردم : بهترین راه که بازم فکر می کنم موتورها باز همینو استفاده کنند حفظ مختصاته لوکالیتی طبقه مپه . چون در مرحله قبل مپه هر آبجکتو ساختین حالا می تونین هر نقطه که به سمتتون اومدو به بیرون حل بدین و این باعث تو رفتگیه اون نقطه روی جسمی میشه که دارین از خودتون دورش میکنین پس باید چیکار کرد که جسمتون مثل ژله ی نقطش هی تو نره و اون اینه که نقاط دیگه اون جسم هر لحظه دارن باهم خودشونو چک می کنن و اگه ی نقطه تو رفت اونای دیگم همونقدر تو برن پس جسم به حالت سخته خودش بر میگرده و کلا دور میشه اما ما فقط ی نقطرو دور کردیم و این باعثه این هم میشه که اگه ی جسم روی جسمه دیگه ای بیافته به طرفی پرت شه چون اون جسمه زیری اونو در راستای مشخصی دورش نکرده بلکه فقط نقاطی رو به سمتی دور کرده و بقیه جسم به حالت سخت از اون نقاط پیروی کردن و میشه باهاش فیزیکو ادامه داد
ی چیزی که هست اینه که چون خوده swf از خاصیت وکتور پیروی می کنه و در زمان کامپایل هم چیزی رو به پیکسل تبدیل نمی کنه و خوده swf ی فرمته وکتور هست تمام اون مپ ها رو داره . و ما نمی تونیم داشته باشیم . و نمی تونیم برای یک شکل که میکشیم برنامه ای بنویسیم و باید موی کلیپ شه اما خود فلش اگه با e.target کار کرده باشین می بینین که خوده اشکال رو هم به اسم instance میشناسه و طبیعیه که بشناسه . پس ما باید خودمون اول مپ تعریف کنیم بعد بکشیمش که مپشو داشته باشیم و بعد موی کلیپش کنیم و این دوباره کاریه چون swf همه اینارو خودش دوباره دارتشون . و غیر از دوباره کاری که حجمو الکی بالا میبره باعث کند شدن میشه چون سرعته رسمه اشکال توسط فلش پلیر از اونی که بیاد دستوره مارو بخونه و تو ماشینه مجازیش تبدیل کنه و بعد بفهمه این دستوره رسمه و بعد شکل رو رسم کنه خیلی بیشتره و این یعنی اینکه اگه چیزی مثل box2D تو خوده فلش از اول تعریف شده بود سرعتو خیلی میتونست بالا ببره و همین توی 3D هم صادقه چون اونجام ماتریس ها مپ هاموننو هی رسمشون میکنیمو ماتریسه دورانو توش ضرب می کنیم که یکم بچرخه باز رسم میکنیم و... یعنی اونجام همش رسمه و این یعنی موتور 3D که داره با خوده فلش توسعه داده میشه دنیای 3D که تا کنون از فلش دیده بودیمو کاملا متحول میکنه مخصوصا اینکه موتورهای 3D که تا کنون برای فلش بود زیاد نمیتونستن از GPU استفاده کننن بجز دستورائی که خود فلش مثله Clone ساخته و از GPU استفاده می کنه
در مورد اون سرعت و اندازه ، فک کنم اگه قرار باشه لحظه ای برخورد ها رو چک کنیم ، می تونیم در لحطه ای که برخورد رخ داد و شی اول داخل شی دوم رفت ، بگیم که به نسبت نقطه ثقل مرکزیش اگه محاسبات نشون دادند که یکی داخل دیگری هست ، پس یه جوری ست کنیم که به نسبت نقطه مرکزی ، دقیقا رو دیگری باشه ... الباقی نوشته هاتونو هم وقت کردم می خونم اگه جوابی داشته باشم و کمکی در حد بضاعت داشته باشم و ایده جدید تری ، بهتون خبر می دم . هنوز نوشته هاتونو چون وقت ندارم نخوندم ولی باید مفید باشه ...
تا الان چند بار دیدگاهمو بهش عوض کردم و هردفم با ی شیوه قشنگی جلو می رفتم که با ظاهر خیلی تکنیکی میامد اما این آخریم به هم گره خورده و همین الان تصمیم گرفتم کلا از اول با ی دیدگاه دیگه بنویسم !!
ساختنه چیزی مثله box2D مطمئنا خیلییییی زیباستو حال میده و هر دیدگاهی برای حله این مسائله واقعا پیچیده که به ارائه بدیم و به چیزی برسه خیلیییی شیرینه اما جدا ساخته چیزی مثله Box2D کاره الکی اصلا نیست و کسانی که این کارو می کنن باید دوره اکادمیک که تجربه چندین ساله دانشمندانه طراحه بازیرو دیده باشن و نباید از خودشون در بیارن چون هرچیم شیوه هاشون قشنگ باشه باید انواع شیوه ها بررسی شه و بدونه پیشینه ای که نتایجو در اختیارشون گذاشته باشه کاره تقریبا نشدنیه که تو چند سال کسانی این کارو بکنن . شما فرض کن ی چیزی که ساده به نظر میادو مثله ساخته ی بازی تتریسو انجام بدین . بعد شروع به کار کنین بدونه هیچ تجربه قبلی . انواع شیوه های قشنگم مختون بهتون بده اما وقتی وارد عمل میشین میبینین مثله ی مز میمونه که اگه از قبل میدونستین میرفتین سره نقطه اصلی و شاید زمانه زیادی با انواعه شیوه های بسیار قشنگو به کار گرفته باشین اما ی شیوه شاید نه چندان قشنگ شمارو به جواب میرسونه
