2 ডি গেমের কোনও বস্তু কি নিজেকে রেন্ডার করতে হবে?

16

আমি একটি 2 ডি রাস্তার যোদ্ধার মতো খেলা তৈরি করছি যা টাইল ভিত্তিক নয়। সাধারণত লোকেদের পরামর্শ দেয় যে সত্তা কোনও রেন্ডারকারীকে দেওয়া হবে যা তাদের রেন্ডার করে, তারা তাদের রেন্ডার করে না, তবে মনে হয় এটি বিপরীতটি আরও ভাল is

একজনের অপরটির চেয়ে কেন ভাল?

ধন্যবাদ

c++ rendering

— jmasterx
সূত্র

আপনি কেন মনে করেন যে বিপরীতটি আরও ভাল?

1

@ মার্টিন কারণ যেহেতু বস্তুটি যেভাবেই কোনও বিটম্যাপটি ব্যবহার করতে ইঙ্গিত দিবে, তবে কেন কেবল বস্তু-> রেন্ডার () করবেন না;

— jmasterx

11

বিবেচনা একটি দম্পতি:

যেমনটি আপনি উল্লেখ করেছেন, প্রতিটি স্প্রিটকে কোন বিটম্যাপটি ব্যবহার করতে হবে সে সম্পর্কে "ইঙ্গিত" দিতে হবে, তবে সত্তাটি যদি নিজেকে রেন্ডার করতে হয়। সেই 'ইঙ্গিত' কী হবে? যদি এটি প্রতিটি স্প্রাইটের জন্য আলাদা বিটম্যাপ, স্প্রাইট শিট ইত্যাদির ... একটি রেফারেন্স হয়, তবে আপনি প্রয়োজনের চেয়ে বেশি মেমরি ব্যবহার করতে পারেন, বা সেই স্মৃতি পরিচালনা করতে সমস্যায় পড়তে পারেন। পৃথক রেন্ডারারের একটি সুবিধা হ'ল যে কোনও সম্পদ পরিচালনার জন্য আপনার কাছে কেবল একটি শ্রেণি দায়বদ্ধ। এটি বলেছিল, এসএফ 2-এর মতো লড়াইয়ের খেলায় আপনার কাছে কেবল দুটি স্প্রাইট থাকতে পারে;)
অন্য কোথাও উল্লিখিত হিসাবে, আপনি যখনই নিজের গ্রাফিকাল এপিআই পরিবর্তন করতে চান, আপনাকে আপনার সমস্ত স্প্রাইটের কোড পরিবর্তন করতে হবে।
কিছু গ্রাফিকাল প্রসঙ্গের রেফারেন্স ছাড়া খুব কমই রেন্ডারিং করা হয়। সুতরাং হয় একটি গ্লোবাল ভেরিয়েবল রয়েছে যা এই ধারণাকে উপস্থাপন করে, বা প্রতিটি স্প্রাইটের রেন্ডার (গ্রাফিকাল কনটেক্সট সিটিএক্স) এর সাথে একটি ইন্টারফেস রয়েছে। এটি গ্রাফিকাল এপিআই এবং আপনার গেমটির যুক্তি (যা কিছু লোক অপ্রীতিকর দেখতে পাবে) মিশ্রিত করে এবং সংকলনের সমস্যার কারণ হতে পারে।
আমি ব্যক্তিগতভাবে দেখতে পেয়েছি যে পৃথক সত্তা থেকে রেন্ডারিংকে আলাদা করা আপনার গেমটিকে এমন একটি সিস্টেম হিসাবে দেখার দিকনির্দেশের একটি আকর্ষণীয় প্রথম পদক্ষেপ যা অগত্যা গ্রাফিক্সের প্রয়োজন হয় না। আমার অর্থ হ'ল আপনি যখন রেন্ডারিংয়ের বাইরে চলে যান তখন আপনি বুঝতে পারেন যে অনেকগুলি গেমপ্লে একটি "গ্রাফিকবিহীন বিশ্বে" ঘটে থাকে যেখানে সত্তাগুলির সমন্বয়কারী, তাদের অভ্যন্তরীণ রাজ্যগুলি ... ইত্যাদিই গুরুত্বপূর্ণ। এটি স্বয়ংক্রিয় পরীক্ষা, আরও ডিকোপল্ড সিস্টেম ইত্যাদির দরজা উন্মুক্ত করে ...

সব মিলিয়ে, আমি এমন সিস্টেমগুলিকে পছন্দ করি যেখানে রেন্ডারিং একটি পৃথক শ্রেণীর দ্বারা করা হয়। এর অর্থ এই নয় যে আপনার স্প্রাইটে এমন কিছু বৈশিষ্ট্য থাকতে পারে না যা "গ্রাফিকলি সম্পর্কিত" (অ্যানিমেশন নাম, অ্যানিমেশন ফ্রেম, উচ্চতা এক্স প্রস্থ, স্প্রাইট আইডি ইত্যাদি ...) হতে পারে, যদি এটি রেন্ডারকে লেখার জন্য সহজ বা আরও দক্ষ করে তোলে।

এবং আমি জানি না যে এটি 3 ডি-তে প্রযোজ্য কিনা (যেখানে আপনি মেসের ধারণা এবং যে স্থানাঙ্ক পরিবর্তনগুলি ব্যবহার করবেন তা সম্ভবত আপনার 3D এপিআইয়ের সাথে আবদ্ধ হবে; তবে x, y, h, w কোনও 2D এর চেয়ে অনেক বেশি স্বতন্ত্র এপিআই)।

আশা করি এটি সাহায্য করে।

— phtrivier
সূত্র

11

আপনি যখন রেন্ডারিং সিস্টেমটি আঁকেন তখন তার নিয়ন্ত্রণে থাকতে চান। পরিবর্তে স্প্রাইটস রেন্ডারিংয়ের নিয়ন্ত্রণে থাকলে আপনি প্রচুর দক্ষতা লাভ এবং নমনীয়তার উপর onিলা করেন। আমি মতামত দিচ্ছি যে ক্লিনার কোডের নিয়ন্ত্রণ ফলাফলের মধ্যে রেন্ডার সিস্টেম থাকার কারণে।

কেন্দ্রীভূত রেন্ডারিং এর কিছু সুবিধা:

জেড-অর্ডারিং:
গেমের অবজেক্টগুলি যদি রেন্ডারিংয়ের জন্য নিজেরাই দায়বদ্ধ থাকে তবে আপনাকে নিশ্চিত করতে হবে যে আপনি তাদেরকে সঠিক ক্রমে কল করেছেন। অন্যথায় পটভূমি অবজেক্টগুলি অগ্রভাগের বস্তুগুলির উপরে আঁকা হতে পারে।
সিস্টেমটি নিয়ন্ত্রণে রাখার সাথে সাথে, এটি সমস্ত রেন্ডার অবজেক্টগুলিকে বাছাই করতে পারে, রেন্ডার সময়ে ওভারল্যাপগুলি সনাক্ত করতে পারে এবং কেবল সেগুলি রেন্ডার করতে পারে বা সবগুলি একসাথে অর্ডার করে দেয়। মুল বক্তব্যটি এখনই সহজেই সিদ্ধান্ত নেওয়া যেতে পারে।
ব্যাচিং:
রেন্ডার সিস্টেমটিকে নিয়ন্ত্রণে রাখার অনুমতি দেওয়ার অন্যান্য স্পষ্ট সুবিধা হ'ল ব্যাচিং। এখানে আবার রেন্ডার সিস্টেমে ব্যাচ স্প্রাইটের বিকল্পটি শেয়ারকে একটি রচনা সরবরাহ করে। এটি একটি কল দিয়ে সবকিছু রেন্ডার করতে ত্রিভুজ স্লাইসিং ব্যবহার করতে পারে । এটি কিছু রেন্ডার গণনার ক্যাশে রাখতে সক্ষম হতে পারে। বা এটি কেবল প্রতিটি স্প্রিটকে সেই অভিনব স্টাফগুলির কোনওটির সাথে বদলে দিতে পারে। (দ্রষ্টব্য: প্রতিটি বস্তু যখন নিজেই রেন্ডার করে তখন এটি সম্ভব ব্যাচ হয় তবে সমস্যা কম দক্ষ এবং আরও জটিল)।

গেমের বিষয়গুলিকে রেন্ডার সিস্টেমের সাথে আঁকতে চান এমন স্প্রিটগুলি নিবন্ধ করার জন্য এটি যেভাবে আমি আমার গেমগুলিতে এটি প্রয়োগ করি। যখন অবজেক্টটি আর প্রত্যাশিত জিনিসটি আঁকতে চায় না তখন এটি স্প্রিটের নিবন্ধন করে, বা এটি নিষ্ক্রিয় হিসাবে চিহ্নিত করে।

যা বলেছে। যদি আপনার গেমের বিষয়গুলি সব উপায়ে নিজেকে রেন্ডার করা সহজ হয় তবে সেভাবে করুন। একটি নিখুঁত আর্কিটেকচারের চেয়ে অগ্রগতি করা এবং কিছু / আঁকানো আরও অনেক বেশি গুরুত্বপূর্ণ।

— deft_code
সূত্র

জেড-অর্ডারিং সম্পর্কে যদি বস্তুগুলি নিজেরাই আঁকতে পারে কোনও সিস্টেম তাদের অঙ্কন পদ্ধতিতে কল করার আদেশ সম্পর্কে সিদ্ধান্ত নেয়? আমার অর্থ কেন্দ্রীভূত বনাম অ কেন্দ্রীভূত জেড-অর্ডারিংয়ের ক্ষেত্রে কোনও পার্থক্য নেই।

— গরিলাএপ

3

দাবি অস্বীকার: আপনার প্রশ্নটি খুব বেশি বিস্তারিত দেয় না তাই আমি একটি সাধারণ নীতি দিয়ে সাড়া দিচ্ছি। যদি আমি আপনার ব্যবহারকে ভুল বুঝি বা 'রেন্ডার' করি তবে দয়া করে আমাকে ক্ষমা করুন।

দৃশ্যে বিভিন্ন অভিনেতাকে রেন্ডার করার জন্য আমি সাধারণত একটি বাহ্যিক অবজেক্ট ব্যবহার করি দৃশ্যের স্তরের বৈশিষ্ট্য এবং পৃথক পৃথক অভিনেতার অবজেক্টগুলির বাইরে পদ্ধতিগুলি ap দৃশ্যের অবজেক্টগুলিতে কেবল অভ্যন্তরীণ পদ্ধতি এবং বৈশিষ্ট্য থাকতে হবে; তারা নিজেরাই এবং তারা কী করে তা কেবল তাদেরই জানা উচিত। সম্ভবত, তারা গেমের অন্যান্য বিষয়গুলির পাশাপাশি ব্যবহারকারীর ইনপুট দ্বারা প্রভাবিত হবে। এটি কীভাবে / স্ক্রিনে রেন্ডার হয় তা প্রভাবিত করবে। একজন 'ডিরেক্টর অবজেক্ট' উদাহরণস্বরূপ, 'ডাব্লু' কিপ্রেসটিকে ঝাঁপ দেওয়ার জন্য অনুবাদ করতে পারে, তারপরে অভিনেতাটিকে বস্তু বলতে পারেন tell জাম্প ()। এই জাতীয় পরিচালক স্তরের যুক্তি অভিনেতাদের দৃশ্যে প্রবেশ করতে বা পুরোপুরি প্রস্থান করতেও বলতে পারে।

চিয়ার্স, ডেভিড

তবে সেই অর্থে পরিচালক কেবল অ্যাক্টন-> সেটভিজিবল (মিথ্যা) বলতে পারেননি; ?

— jmasterx

এমনকি সেটভিজিবল (মিথ্যা) ক্ষেত্রেও এটি একটি বাহ্যিক সত্তা যা অভিনেতার দৃশ্যমান পরিবর্তনশীল পরীক্ষা করে এবং এটি সত্য হলেই এটি সরবরাহ করে রেন্ডারিং করে।

— নাভ

কোনও অভিনেতাকে কেবল অদৃশ্য করে তোলা দৃশ্য থেকে সরিয়ে দেয় না। এছাড়া দুর্ঘটনায় ইত্যাদি অংশগ্রহণ করা বন্ধ করতে হবে

— finnw

3

যদি কোনও দিন আপনি আপনার গেমটিকে একটি আলাদা রেজোলিউশনে (যেমন আইফোন এবং বন্ধুরা) পোর্ট করতে চান তবে কী। সুতরাং, রেন্ডারিং পরিবর্তন সম্পর্কে একটি বিশ্বব্যাপী সম্পত্তি, আপনি কীভাবে সহজেই আপনার কোড আপডেট করবেন?

3

আমি যা ব্যবহার করেছি তা ছিল পর্যবেক্ষক-ভিত্তিক নকশা। আমি যখন ক্লাসের একটি উদাহরণ তৈরি করতে চাই যখন আমি রেন্ডার করতে চাইতাম, তারপরে এটির একটি পয়েন্টার কেন্দ্রীয় রেন্ডারার শ্রেণিতে সংরক্ষণ করা হয়েছিল। আপনি যখন কল করবেন RenderFrame()তখন রেন্ডারারের কাছে ইতিমধ্যে বিদ্যমান বিদ্যমান সমস্ত বস্তু রয়েছে যা করার জন্য তাদের বৈশিষ্ট্যগুলি সরবরাহ করতে এবং এটি অ্যাক্সেস করা দরকার। ক্লাসগুলি তাদের কোনও ধারণা ছিল না যে তারা আদৌ উপস্থাপন করতে চলেছে। এই API টি সুন্দর এবং পরিষ্কার এবং ব্যবহারে সহজ ছিল।

— DeadMG
সূত্র

1

+1 আকর্ষণীয়। গ্রাফিক্সের জন্য ভিজিটর প্যাটার্নটি ব্যবহার করার সময় আমি শব্দটির জন্য এই পদ্ধতির ব্যবহার করেছি । আমি ভেবেছিলাম এটি শব্দের জন্য আরও বোধগম্য হয়েছে কারণ গ্রাফিক্স এবং এআই একই ঘড়িতে চলাকালীন অডিও মিক্সারটি অন্যটিতে চলছে তাই কোনও ইভেন্টের মডেল আরও সহজ। এছাড়াও যদি কোনও মুভমেন্ট ইভেন্ট (যা কোনও অডিও চ্যানেলের প্যান / রেভারব পরিবর্তিত করে) কয়েক মিলিসেকেন্ড দেরীতে আসে তবে এটি সমালোচনামূলক নয় যদি কোনও স্প্রিট ভুল অবস্থায় আঁকা হয়।

— ফিনউইউ

2

আপনার কোড বজায় রাখা এবং প্রসারিত করা কতটা সহজ তা সাধারণভাবে সর্বদা এটি। আগামীকাল আপনি বুঝতে পারেন যে আপনি বর্তমানে যে গ্রাফিক্স এপিআই ব্যবহার করছেন তা পছন্দ করেন না এবং আপনি পরিবর্তন করতে চান। আপনি কি এখন আপনার সমস্ত অবজেক্ট ক্লাসের মধ্যে দিয়ে যেতে হবে এবং সমস্ত কিছু পরিবর্তন করতে হবে, বা আপনার কি এখনও প্রকল্পের একটি কেন্দ্রীয় পয়েন্টে আপনার কোডটি পরিবর্তন করতে হবে?

আপনি যখন রেন্ডার () র কল করেন তখন এটি আপনার বস্তুগুলি আসলে কী করছে তার উপর নির্ভর করে। যতক্ষণ না তারা কেবল আপনার গ্রাফিক্স ইঞ্জিনের কাছে পদ্ধতি কলগুলি গুটিয়ে রাখে ততক্ষণে এটি পুরোপুরি ঠিক আছে, কারণ লজিকস <-> গ্রাফিক্সের পার্থক্য এখনও দেওয়া হবে।

উদাহরণস্বরূপ, যদি আপনার রেন্ডার () পদ্ধতিগুলি মূলত সুবিধা-পদ্ধতি হয় এবং এর মতো কিছু দেখায়:

void MyClass::render(const Graphics &g)
{
    g.draw(this);
}

অথবা

void MyClass::render()
{
   mySprite->render();
}

অথবা

void MyClass::render()
{
    mySprite->UseShader(thatshader);
    mySprite->render();
}

বা তার কাছে, আমি মনে করি এটি কোনও সমস্যা নয়।

— TravisG
সূত্র