जावा में केवल कुछ वीडियो गेम क्यों लिखे गए हैं? [बन्द है]


171

जावा में लिखित कई वाणिज्यिक, 3 डी वीडियो गेम (यादृच्छिक ओपन सोर्स 2 डी वाले नहीं) क्यों नहीं हैं? सिद्धांत रूप में, यह बहुत मायने रखता है: आपको उत्पादकता में वृद्धि और क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन लगभग मुफ्त में, अन्य चीजों के साथ, जैसे कि जावा पुस्तकालयों की विशाल राशि, और अंतर्निहित कचरा संग्रह (हालांकि मैं मानता हूं) अगर बाद की बात अच्छी है तो मुझे यकीन नहीं है)। तो इसका उपयोग शायद ही कभी क्यों किया जाता है? मैं केवल जावा प्लेटफॉर्म के लिए लिखे गए कुछ लोकप्रिय वाणिज्यिक खेलों के बारे में सोच सकता हूं।

क्या यह प्रदर्शन के कारण है? यदि ऐसा है, तो अधिकांश जीपीयू वैसे भी नहीं उठाया जाएगा?



1
पुन: mm mm; मैं कुछ सदमे में हूँ कि THAT गेम ने "सर्वश्रेष्ठ ग्राफिक्स" पुरस्कार जीता, 2005 में भी ...
CloudyMusic

2
हाँ, लेकिन अधिकांश "वास्तविक खेल" प्रबंधित नहीं किए जाते हैं। सही में? वे पुराने स्कूल c / c ++ में बने हैं?
हार्डवेयरगुई

14
Runescape जावा में लिखा है।
गेमफ्रीक

44
जावा में Minecraft लिखा है!
डेग्रीविस

जवाबों:


155

खेल विकास की दुनिया एक मजेदार है: एक तरफ, वे अक्सर नए विचारों को स्वीकार करने के लिए जल्दी होते हैं, दूसरी तरफ, वे अभी भी पत्थर की उम्र में हैं।

सच्चाई यह है कि, .NET / Java / C / C ++ के अलावा किसी भी चीज़ पर स्विच करने में शायद ही इतना प्रोत्साहन हो।

अधिकांश गेम कंपनियां अन्य कंपनियों से गेम इंजन के कुछ हिस्सों को लाइसेंस देती हैं। इन भागों को C ++ में लिखा गया है, और यद्यपि आपके पास स्रोत तक पहुंच हो सकती है, इसलिए आप इसे पोर्ट कर सकते हैं, जो बहुत प्रयास करता है (और निश्चित रूप से, लाइसेंस को इसकी अनुमति देने की आवश्यकता है)।

साथ ही, C ++ में बहुत सारी विरासत कोड पहले से मौजूद हैं। यदि पिछली परियोजनाओं के कोड का पुन: उपयोग किया जा सकता है (यदि आप सीक्वल लिख रहे हैं), तो यह कि एक ही भाषा के साथ चिपके रहने के पक्ष में और भी अधिक मायने रखता है, बजाय इसे एक नई भाषा में लिखने के (और अधिक तब से जब आप संभावित रूप से पुन: प्रस्तुत करेंगे। एक टन बग जो आपको इस्त्री करने के लिए समय बिताने की आवश्यकता होगी।

अंत में, यह गेम के लिए 100% C ++ में लिखा जाना दुर्लभ है - बहुत कुछ स्क्रिप्टिंग भाषाओं का उपयोग करके किया जाता है, चाहे वे कस्टम हों या केवल मौजूदा भाषाओं को एकीकृत कर रहे हों (Lua इन दिनों अधिक लोकप्रिय लोगों में से एक है)।

जहां तक ​​कचरा संग्रहण का सवाल है, तो यह एक समस्या हो सकती है। समस्या इतनी अधिक नहीं है कि यह मौजूद है, यह अधिक है कि यह कैसे काम करता है - कचरा संग्रहकर्ता को गैर-अवरुद्ध होना चाहिए (या कम से कम केवल बहुत संक्षेप में ब्लॉक करने की गारंटी दी जाए), क्योंकि यह केवल 10 सेकंड के लिए गेम फ्रीज होने के लिए अस्वीकार्य है यह सभी आवंटित मेमोरी को स्कैन करता है यह देखने के लिए कि क्या मुक्त किया जा सकता है। मुझे पता है कि जब यह मेमोरी से बाहर चलने के करीब होता है (और कुछ गेमों के लिए, तो यह होगा) जावा जावा काफी हद तक घुट जाता है।

आप जो कुछ भी कर सकते हैं उसमें आप थोड़ा अधिक प्रतिबंधित हैं: रनवे के ओवरहेड के कारण आप हार्डवेयर का पूरी तरह से दोहन नहीं कर सकते। कल्पना कीजिए कि क्रिसिस को जावा में लिखा जा रहा है ... भले ही यह केवल दृश्यमान अंतर है, यह सिर्फ एक ही नहीं होगा (मुझे यकीन है कि आपको इसे चलाने के लिए कोर i7 की आवश्यकता होगी।)।

इसका मतलब यह नहीं है कि इन भाषाओं का खेल विकास में अपना स्थान नहीं है - और नहीं, मैं सिर्फ टूल प्रोग्रामिंग की बात नहीं कर रहा हूं। अधिकांश खेलों के लिए, आपको 3D गेम सहित C ++ से प्राप्त होने वाले अतिरिक्त प्रदर्शन की आवश्यकता नहीं है, और यदि आप इसे स्क्रैच से लिख रहे हैं, तो यह XNA जैसी किसी चीज़ का उपयोग करने के लिए सही अर्थ बना सकता है - वास्तव में, ए अच्छा मौका होगा।

जहाँ तक वाणिज्यिक खेलों का सवाल है - क्या RuneScape की गिनती होती है? यह अच्छी तरह से वहाँ बाहर सबसे रसीला जावा खेल हो सकता है।


16
जाहिर है आप जेवीएम पर क्राइसिस नहीं चलाएंगे; नरक, अगर आपने असेंबली भाषा में उस गेम को कोडित किया है तो आपको इसे पूर्ण सेटिंग्स पर चलाने के लिए सुपर कंप्यूटर की आवश्यकता होगी। लेकिन उत्कृष्ट अंतर्दृष्टि के लिए +1, धन्यवाद।
साशा चोडगोव

15
आप Runescape के साथ अवास्तविक टूर्नामेंट 3 या Crysis की तुलना नहीं कर सकते। यदि ग्राफिक गुणवत्ता एक चिंता का विषय है, तो आपको कम स्तर की भाषा के साथ जितना संभव हो उतना कम ओवरहेड के साथ छड़ी करने की आवश्यकता है। बेशक, इंडी या गेम्स के लिए जहां ग्राफिक्स मुख्य विक्रय बिंदु नहीं हैं, जावा C / C ++ का एक उत्कृष्ट विकल्प है।
गुइसिम

6
@ GuiSim: अधिकांश खेलों के लिए, ग्राफिक्स गुणवत्ता एक प्रमुख विक्रय बिंदु नहीं है। केवल एक मुट्ठी भर गेम हैं जो मैं सोच सकता हूं कि ग्राफिक्स को दिमाग में बनाया गया था (मैं क्राइसिस के बारे में सोच रहा हूं, लेकिन हाफ-लाइफ 2 और साथ ही)। मुझे नहीं लगता कि अधिकांश गेम डेवलपर्स ग्राफिक्स के बारे में इतना ध्यान रखते हैं, जब तक कि वे "अच्छे पर्याप्त" हैं (अधिकांश अन्य खेलों के साथ बराबर पर उर्फ)।
साशा चेदिगोव

4
ग्राफिक्स वास्तव में भाषा के साथ बहुत कम है। भौतिकी, एआई, हाँ। ग्राफिक्स, नहीं।
जूलियनआर

10
@ जूलियनआर एक दृश्य को कुशलतापूर्वक प्रस्तुत करने के लिए तैयार करने और बनाए रखने के लिए एक महत्वपूर्ण कार्यभार हो सकता है, इसलिए ग्राफिक्स के लिए भाषा और संबंधित भाषा ओवरहेड मायने रखती है।
KSchmidt

95

मुझे लगता है कि जॉन कार्मैक ने इसके साथ सबसे अच्छा कहा:

सबसे बड़ी समस्या यह है कि जावा वास्तव में धीमा है। एक शुद्ध सीपीयू / मेमोरी / डिस्प्ले / संचार स्तर पर, अधिकांश आधुनिक सेलफोन को गेम बॉय एडवांस्ड की तुलना में बेहतर गेमिंग प्लेटफॉर्म होना चाहिए। जावा के साथ, अधिकांश फोन पर आपको एक मूल 4.77 mhz आईबीएम पीसी के सीपीयू पावर के बारे में छोड़ दिया जाता है, और हर चीज पर घटिया नियंत्रण होता है। [... स्निप ...] लिखो-एक बार चलाओ-कहीं भी। हा। हा हा हा हा हा। हम अभी केवल चार प्लेटफ़ॉर्म पर परीक्षण कर रहे हैं, और एक भी जोड़ी में ठीक वैसा ही नहीं है। सभी वाणिज्यिक खेलों को प्रत्येक (अक्सर 100+) प्लेटफ़ॉर्म के लिए अलग-अलग संकलित और संकलित किया जाता है। पोर्टेबिलिटी भयानक प्रदर्शन के लिए एक औचित्य नहीं है।

( स्रोत )

दी, वह मोबाइल प्लेटफ़ॉर्म के बारे में बात कर रहा था, लेकिन मैंने जावा के साथ इसी तरह की समस्याओं को सी ++ पृष्ठभूमि से आने के रूप में पाया है। मुझे याद है कि मैं अपनी शर्तों पर स्टैक / हीप पर मेमोरी आवंटित करने में सक्षम हूं।


60
यह उद्धरण 2005 से था। तब से जावा तकनीक और सेलफोन शक्ति दोनों में काफी सुधार हुआ है। सेलफोन गेमिंग बनाम पीसी गेमिंग की तुलना सेब की तुलना संतरे से की जा रही है।
क्रिस डेल

78
जॉन कार्मैक ने कहा। मामला समाप्त।
गुइसिम

41
मैं बस असहज हो जाता हूं जब मैं पढ़ता हूं "जावा वास्तव में धीमा है"। यह कहने जैसा है कि $ 100k स्पोर्ट्स कार की तुलना में $ 50k स्पोर्ट्स कार धीमी है। ज़रूर, यह धीमा है, लेकिन 90% समय, यह जो काम करता है वह अभी भी महान है और आधी कीमत पर है;) कोई लौ युद्ध का इरादा नहीं था। मैं सहमत हूं कि उपरोक्त कारण हैं कि क्रिसिस और जैसे गेम जावा में क्यों नहीं लिखे गए हैं।
रोस

17
@ क्रिस डेल, यह जावा के प्रदर्शन के साथ पूरे मुद्दे को रेखांकित करता है। क्या जावा प्रदर्शन में सुधार हुआ है? नहीं, सेल फोन बस तेज हो गया। खेल यथार्थवाद की सीमाओं को धक्का देने वाले होते हैं, और इसलिए हार्डवेयर की सीमाओं को धक्का देते हैं, और आपके प्रदर्शन के 30-% 40% दूर फेंकने से पहले आपने कोड की एक पंक्ति भी अस्वीकार्य लिखी है।
cgp

8
मुझे यह विवाद बहुत अजीब लगता है। जावा एमई एंड्रॉइड में जावा के समान नहीं है और पीसी पर जावा के समान नहीं है। जावा एमई आमतौर पर जेवीएम के साथ आने के लिए फोन निर्माताओं पर निर्भर करता था। कुछ ने अच्छा काम किया, कुछ ने नहीं किया। कोई आश्चर्य नहीं कि कार्मैक उनके बारे में शिकायत कर रहा था। Android का अपना VM है जो JVM नहीं है। और इसमें कुछ गंभीर मुद्दे हैं (मेरे दृष्टिकोण से)। ओरेकल का हॉटस्पॉट वीएम दोनों मामलों से पूरी तरह से अलग है। यदि लोग इन सभी चीजों की तुलना करते हैं, तो केवल एक चीज जो मैं निष्कर्ष निकाल सकता हूं, वह यह है कि वे नहीं जानते कि वे किस बारे में बात कर रहे हैं।
मैल्कम

54

एक बात के लिए, जावा में ऑपरेटर की ओवरलोडिंग की कमी गणित के सभी को बनाती है जो आपको एक काम करने वाले ग्राफिक्स पाइपलाइन को प्राप्त करने के लिए बहुत ही कष्टप्रद और पढ़ने में कठिन है।

मैट्रिक्स गुणन और चक्करदार वैक्टर के सभी से आपको निपटना बहुत आसान है, यदि वे अच्छी तरह से बनाए गए गणितीय अभिव्यक्तियों के बजाय ऑब्जेक्ट-ओरिएंटेड अभिव्यक्तियों का अनुसरण करना बहुत आसान है

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

यह सिर्फ भयानक है। गणित ऐसा नहीं लगना चाहिए।


19
मुझे याद है कि '96 में मुझे लगता है कि यह था, सन के कुछ डिजाइनर बर्कले में जावा पर एक प्रस्तुति दे रहे थे। विलियम काहन ( en.wikipedia.org/wiki/William_Kahan ) उन्हें इस मुद्दे पर श * टी दे रहा था। :)
जेपी अलीटो

13
मुझे लगता है कि ऑपरेटर को किसी भाषा में ओवरलोडिंग की अनुमति नहीं देने का एक अच्छा कारण है: लोगों को इसका उपयोग करने से रोकना। यह एक शक्तिशाली उपकरण है और गणित के लिए बहुत अच्छा है, लेकिन बाकी सब चीजों के लिए खतरनाक है। कोडर के रूप में आलसी होते हैं, वे इसे कोड को छोटा करने के लिए मिसयूज करते हैं, और जिस क्षण लोग एक फ़ंक्शन के साथ चलने वाले नक्शे को गुणा करना शुरू करते हैं, या यहां तक ​​कि जब सभी अंकगणितीय ऑप्स कार्यों के लिए परिभाषित होते हैं, तो कोड पठनीयता लगभग 0. और पहुंचने वाली होती है। हाँ, मैंने काफी समय पोर्टिंग कोड की तरह खर्च किया है। : -S यह एक डिजाइन विकल्प है। और डिजाइन विकल्प हमेशा विवादित होते हैं।
back2dos

19
कुछ बुरे सेब के लिए हर किसी को सज़ा दें? यह एक कारण है जो मुझे C # पसंद है। अगर मुझे वास्तव में ऑपरेटर की जरूरत है तो यह वहां पर है।
कैओसपांडियन

1
असल में, ऑपरेटर ओवरलोडिंग ओओपी डिज़ाइन (वैक्टर, मेट्रिसेस, कॉम्प्लेक्स नंबर) में 2-3 अलग-अलग स्थितियों के लिए वास्तव में उपयुक्त है। अधिकांश अन्य स्थितियों में, यह बहुत शिथिल रूप से परिभाषित है और केवल मैला कोड, कमजोर वाक्यविन्यास और खराब प्रलेखन की ओर जाता है, यहां तक ​​कि उन लोगों से भी जो इसे उपयोग करना जानते हैं। मुझे लगता है कि सूर्य ने जावा में इसका उपयोग नहीं करने का विकल्प चुना है, और मुझे लगता है कि यह एक वैध निर्णय है।
अक्टूबर

1
@MMJZ: लैम्बडा एक्सप्रेशन का ऑपरेटर ओवरलोडिंग के साथ क्या करना है?
साशा चोडगोव

26

मुझे लगता है कि .NET के पास बहुत सारे समान मुद्दे हैं जो जावा के पास हैं। Microsoft ने XNA :-) के साथ डेवलपर्स के लिए मार्केटिंग में बेहतर काम किया है


10
XNA भी आपके .NET अनुप्रयोग को XBox में तैनात करना संभव बनाता है। मैंने जावा के लिए कुछ भी सहज नहीं देखा है।
स्ट्रिपिंगवर्यर

आप Zune पर भी तैनात कर सकते हैं।
cbeuker

एक पुराने सवाल का थोड़ा, लेकिन सिर्फ अपडेट करने के लिए, आप अब विंडोज फोन के लिए XNA गेम भी लिख सकते हैं :-)
जोएल मार्टिनेज

3
@JoelMartinez एक और अपडेट: विंडोज फोन 8 के लिए XNA गेम लिखना संभव नहीं है।
टॉमस आंद्रले

@ तोमा अब WP8 के लिए मोनोगेम गेम लिखना संभव है
एलेक्स लपा

17

पहले छोटे अंक:

  • जावा से किसी भी उत्पादकता को बढ़ावा देना काल्पनिक है। वाक्यविन्यास लगभग C ++ के समान है, इसलिए आप स्मृति प्रबंधन और मानक पुस्तकालयों से बचत पर वास्तव में बैंकिंग हैं। पुस्तकालयों में गेम डेवलपर्स की पेशकश करने के लिए बहुत कम है और कचरा संग्रह के कारण स्मृति प्रबंधन एक विवादास्पद मुद्दा है।

  • क्रॉस-प्लेटफ़ॉर्म "मुफ्त" के रूप में आपको लगता है कि अच्छा नहीं है क्योंकि कुछ डेवलपर्स ओपनजीएल का उपयोग करना चाहते हैं और कई प्रमुख प्लेटफार्मों में शायद अपने मूल पुस्तकालयों के लिए एक अच्छा जावा कार्यान्वयन या आवरण की कमी है, चाहे ग्राफिक्स, ऑडियो, नेटवर्किंग, आदि के लिए।

लेकिन मुख्य रूप से, मुद्दा बैकवर्ड संगतता है। गेम डेवलपर्स सी से सी और सी से विधानसभा में शुद्ध रूप से चले गए क्योंकि माइग्रेशन मार्ग सुचारू था। प्रत्येक अंतर पिछले के साथ निकटता से जुड़ा हुआ है, और उनके सभी पिछले कोड नई भाषा में प्रयोग करने योग्य थे, अक्सर एक एकल संकलक के माध्यम से। इसलिए प्रवास उतना ही धीमा या उतना ही तेज था जितना आप पसंद करते हैं। उदाहरण के लिए, हमारे पुराने हेडर में से कुछ का आज भी #ifdef WATCOMC हैमें, और मुझे नहीं लगता कि किसी ने एक दशक या उससे अधिक समय में यहां वाटक कंपाइलर का उपयोग किया है। पुराने कोड में बड़े पैमाने पर निवेश होता है और प्रत्येक बिट को केवल आवश्यकतानुसार बदल दिया जाता है। बिट्स और टुकड़ों को एक गेम से दूसरे गेम में बदलने और अपग्रेड करने की प्रक्रिया कहीं भी व्यावहारिक नहीं है अगर आप ऐसी भाषा में बदल गए हैं जो आपके मौजूदा कोड के साथ मूल रूप से इंटरप्रेट नहीं करता है। हां, C ++ / Java इंटरऑपरेबिलिटी संभव है, लेकिन केवल "C C के एक बिट के साथ C" लिखने या C में asm ब्लॉक एम्बेड करने की तुलना में बहुत अव्यावहारिक है।

खेल डेवलपर्स की पसंद की भाषा के रूप में C ++ को सुपरसीड करने के लिए, इसे दो चीजों में से एक करना चाहिए:

  1. मौजूदा विरासत कोड के साथ आसानी से अंतर करने योग्य हो, इस प्रकार निवेश को संरक्षित करना और मौजूदा पुस्तकालयों और उपकरणों तक पहुंच बनाए रखना, या
  2. डिमॉस्ट्रैबली एक उत्पादकता को बढ़ावा देने के लिए पर्याप्त रूप से सामने दिखाती है कि आपके सभी कोड को पुन: लिखने की लागत (या फिर उस भाषा से इस्तेमाल किए जा सकने वाले पुन: प्रयोज्य घटकों में इंटरफेस को फिर से बनाना) कवर से अधिक है।

विशेष रूप से, मुझे नहीं लगता कि जावा उनमें से किसी से मिलता है। एक उच्च-स्तरीय भाषा 2 को मिल सकती है, अगर कोई अग्रणी होने के लिए पर्याप्त बहादुर है। (ईवीई ऑनलाइन शायद सबसे अच्छा उदाहरण है जो हमारे पास पायथन का उपयोग करने योग्य है, लेकिन जो मुख्य पायथन भाषा के एक कांटे का उपयोग करता है, प्रदर्शन के लिए कई सी ++ घटक हैं, और यहां तक ​​कि आधुनिक शब्दों में एक काफी अवांछनीय खेल के लिए है।)


बस जोड़ना चाहता था, ईवीई ऑनलाइन एक 'ऑनलाइन' स्पेस सिमुलेशन है, जहां अधिकतम बनाम अधिकतम खिलाड़ी बनाम खिलाड़ी की लड़ाई आम है, जिसे प्रदर्शन के मामले में एक मांग परिदृश्य के रूप में गिना जा सकता है। यद्यपि यह गति गहन भाग C / C ++ में लिखे गए हैं, यह अभी भी खेलों में एक उच्च स्तरीय भाषा (पायथन) का उपयोग करने की चुनौतियों पर एक दिलचस्प अध्ययन है।
हकन डेरिल

हालांकि, याद रखें कि मल्टीप्लेयर सर्वर-साइड गेम्स में प्रदर्शन एकल-प्लेयर क्लाइंट-साइड गेम्स में प्रदर्शन के लिए थोड़ा अलग मैट्रिक्स द्वारा मापा जाता है - पूर्व थ्रूपुट के साथ अधिक चिंतित है, विलंबता के साथ बाद वाला।
काइलोटन

हां, यह सच है, लेकिन उस लड़ाई में स्क्रीन पर 2000+ जहाज, 2000+ प्रोजेक्टाइल (मिसाइल, एनिमेशन के साथ), विस्फोट आदि शामिल हैं जिनमें कुछ भारी ग्राफिक्स प्रदर्शन की आवश्यकता होती है। वैसे भी, विस्तृत जवाब के लिए धन्यवाद, यह अभी भी सच है।
हकन डेरिल

1
अगर आपको लगता है कि C & Java सिंटैक्स समान हैं और इसलिए प्रदर्शन के लिए कुछ संबंध हैं, तो आप वास्तव में समझ नहीं पाते हैं कि क्या चल रहा है। संभवतः C रनटाइम में कैसे तय कर सकता है कि किसी दिए गए फ़ंक्शन को एक ही पैरामीटर के साथ बार-बार कॉल किया जा रहा है और मापदंडों में विचलन होने पर फ़ंक्शन कॉल को बनाए रखते हुए पूरे फ़ंक्शन कॉल को एक स्थिरांक के साथ बदल दिया जाता है? मैं यह नहीं कह रहा हूँ कि रनटाइम हमेशा बेहतर होता है या अल्विअस बदतर होता है, बस इसका कोई संबंध नहीं है जो भी वाक्य रचना के लिए है!
बिल के

1
@BillK - आप गलत प्रतीत होते हैं। मैंने सिंटैक्स का उल्लेख केवल 'उत्पादकता' के संदर्भ में किया है - 'प्रदर्शन' के लिए नहीं। यह सही है कि जेआईटी अनुकूलन जावा को सिद्धांत रूप में तेज बना सकता है, लेकिन व्यवहार में ऐसा नहीं होता है, कम से कम गेम सॉफ्टवेयर में नहीं।
काइलोटन

12

मैं सिम्स 3 खेल रहा हूं, और मैंने चारों ओर कुछ प्रहार किया। ग्राफिक्स इंजन C ++ है, जबकि स्क्रिप्टिंग और व्यवहार इंजन C # / मोनो है। तो जबकि C ++ में महत्वपूर्ण बिट्स के लिए समय है, अन्य सामान जैसे ।डूलेशन, गेम लॉजिक, AI एक ऑब्जेक्ट ओरिएंटेड प्रबंधित भाषा में है।


5
और फिर मैक संस्करण के लिए, वे एक संशोधित वाइन वर्चुअल मशीन के अंदर पूरी चीज को हिलाते हैं। अभी भी तेजी से यह सीधे जावा में होगा मुझे लगता है :-)
बेन गोटो

10
शराब एक आभासी मशीन नहीं है, यह एक रनटाइम लाइब्रेरी है जो विंडोज रनटाइम लाइब्रेरी के व्यवहार की नकल करती है। इसलिए नाम (वाइन इज़ नॉट ए एमुलेटर)।
नैट सीके

2
यह खेल में बहुत आम है, अक्सर तर्क जो समय-आलोचनात्मक नहीं है, वह किसी प्रकार की स्क्रिप्टिंग भाषा में लिखा जाता है, आमतौर पर लुआ या पायथन।
KSchmidt

यह वैनिला मोनो नहीं है, हालांकि। ईए को काम करने के लिए पूर्णकालिक कस्टम सीएलआर पर काम करने वाली एक विशेष टीम की आवश्यकता थी।
क्रैशक्रेट्स

4
बस एक पक्ष ध्यान दें कि सिम्स 3 उत्कृष्ट कंप्यूटर पर भी अंडरपरफॉर्मिंग के लिए कुख्यात है।
लोटस नोट्स

12
  • क्या गेमिंग इंजन / लाइब्रेरी के कोई अच्छे पोर्ट हैं?
  • कई C / C ++ डेवलपर्स, विशेष रूप से विंडोज पर (जहां अधिकांश वाणिज्यिक गेम लिखे गए हैं) विज़ुअल स्टूडियो से परिचित हैं। आईडीई में कोई तुलना नहीं है।
  • सामान्य तौर पर, जावा को ठोस टाइपिंग के कारण व्यवसायों को बेच दिया गया है और इसमें स्मृति प्रबंधन मुद्दों के न होने की धारणा है।
  • और हां, जावा अभी भी एक धारणा से ग्रस्त है कि यह धीमा है, और यह स्मृति प्रबंधन खराब है, और खेलों के लिए, यह संभवतः कार्य के लिए बीमार है। जैसा कि कुछ अन्य जवाबों में कहा गया है, कचरा संग्रह बस इसे काटने के लिए नहीं जा रहा है जब आप वास्तविक समय के उच्च-प्रदर्शन आवश्यकताओं के साथ काम कर रहे हैं। वीडियो गेम सीपीयू और जीपीयू को उनकी सीमा तक धकेलते हैं।

1
बोल्ड टेक्स्ट के लिए +1। लोगों को यह महसूस नहीं होता है कि जब आपका गेम 20 एफपीएस पर चल रहा है, तो यह अक्सर 20 एफपीएस पर हार्डवेयर बाध्य होता है। यह वास्तव में 30+ एफपीएस को प्राप्त करना चाहता है .. लेकिन यह नहीं हो सकता।
ग्यूसीम

मुझे नहीं लगता कि यह सिर्फ जीसी है जो समस्या प्रदर्शन के लिहाज से अच्छा है ... और न ही धीमे स्टार्टअप चरण के साथ युग्मित भी ... यह सामान्य प्रदर्शन के मुद्दे हैं, लेकिन यह सिर्फ मेरे लिए है।
रोजरपैक

2
मुझे लगता है कि इस बिंदु पर मैं अतीत की तुलना में सहमत होने की अधिक संभावना है। जेवीएम के अनुकूलन में सुधार हुआ है; हालाँकि, जावास्क्रिप्ट और अन्य की तरह शिथिल टाइप की भाषाओं के प्रदर्शन में सुधार के मामले में, जावा की तुलना में प्रदर्शन बहुत अक्षम्य है। जावा के प्रदर्शन के लिए बहुत सारे माफी देने वाले हैं। (लेकिन अंत में कथित प्रदर्शन यह सब मायने रखता है) '
सीजीपी

10

खेलों के लिए जावा और अन्य वर्चुअल मशीन भाषाओं का उपयोग न करने के सबसे बड़े कारणों में से एक कचरा संग्रह के कारण है। यही बात .NET के लिए जाती है। कचरा संग्रह ने एक लंबा रास्ता तय किया है और अधिकांश प्रकार के अनुप्रयोगों में महान काम करता है। हालांकि कचरा संग्रह करने के लिए, आपको कचरा इकट्ठा करने के लिए आवेदन को रोकना और बाधित करना होगा। जब संग्रह होता है तो यह आवधिक अंतराल का कारण बन सकता है।

जावा में रियलटाइम एप्लिकेशन के लिए समान समस्या है। जब कार्यों को एक विशेष समय पर चलना चाहिए, तो कचरा संग्रह सम्मान जैसे एक स्वचालित कार्य होना मुश्किल है।

ऐसा नहीं है कि जावा धीमा है। यह है कि realtime कार्यों को संभालने में जावा अच्छा नहीं है।


1
हालाँकि, यदि आप एक नए वातावरण में जावा को पोर्ट करने के लिए इतनी दूर जा रहे हैं, तो आप कचरा कलेक्टर के लिए अपना खुद का शेड्यूलर लिख सकते हैं। स्मृति को किसी भी तरह से पुनः प्राप्त किया जाना है, और एक वास्तविक समय के वातावरण में, आपके पास अपने जीसी को शेड्यूल करने का विकल्प हो सकता है ... दोनों दुनिया के सर्वश्रेष्ठ। मुझे इस बिंदु पर वापस जाना है कि जावा को किसी आर्किटेक्चर पर पोर्ट करने का कोई कारण नहीं है कि आप उन चीजों को कर सकें जो आप करना चाहते हैं जब सी / सी ++ पहले से ही आपके लिए उन चीजों को करता है। जावा अन्य स्थानों पर चमकता है।
सैन जैसिंटो

5
यह 1990 का दशक नहीं है। कम ठहराव के लिए तैयार किए जाने पर अब गारबेज कलेक्टर बहुत अच्छे हैं।
टॉम हॉल्टिन -

8

एक बड़ा कारण यह है कि वीडियो गेम को अक्सर, कई बार हार्डवेयर के प्रत्यक्ष ज्ञान की आवश्यकता होती है, और वास्तव में कई आर्किटेक्चर के लिए कोई महान कार्यान्वयन नहीं है। यह अंतर्निहित हार्डवेयर आर्किटेक्चर का ज्ञान है जो डेवलपर्स को गेमिंग सिस्टम से प्रदर्शन के प्रत्येक औंस को निचोड़ने की अनुमति देता है। जब आप गेमिंग प्लेटफ़ॉर्म पर जावा पोर्ट करने के लिए समय लेंगे, और तब उस पोर्ट के शीर्ष पर एक गेम लिखेंगे जब आप गेम लिख सकते हैं?

संपादित करें: यह कहना है कि यह "गति" से अधिक है या "सही लाइब्रेरी नहीं है" समस्या है। वे दो चीजें इस के साथ हाथ से चली जाती हैं, लेकिन यह "मैं एक प्रणाली कैसे बनाऊं जैसे कि सेल मेरे जावा कोड को चलाया जाता है? वास्तव में कोई अच्छा जावा कंपाइलर नहीं हैं जो पाइपलाइन और वैक्टर का प्रबंधन कर सकते हैं। जैसे मुझे चाहिए .. "


7

प्रदर्शन का मुद्दा पहला कारण है। जब आप क्वेक इंजन ( http://www.codemaestro.com/reviews/9 ) में हाइपर ऑप्टिमाइज़्ड C ++ कोड देखते हैं , तो आपको पता चलता है कि वे वर्चुअल मशीन के साथ अपना समय बर्बाद नहीं करेंगे।

यकीन है कि कुछ .NET गेम हो सकते हैं (जो लोग हैं; मैं रुचि रखता हूं। क्या वास्तव में सीपीयू / जीपीयू-इंटेंसिव वाले कुछ हैं?), लेकिन मुझे लगता है कि यह अधिक है क्योंकि बहुत से लोग एमएस प्रौद्योगिकियों के विशेषज्ञ हैं और लॉन्च होने पर माइक्रोसॉफ्ट का अनुसरण करते हैं। उनकी नई तकनीक।

ओह और क्रॉस-प्लेटफॉर्म सिर्फ वीडियो गेम कंपनियों के दिमाग में नहीं है। लिनक्स बाजार का लगभग 1% है, मैक ओएस कुछ% अधिक है। वे निश्चित रूप से सोचते हैं कि यह विंडोज-केवल प्रौद्योगिकियों और डाइरेक्ट्रीज जैसे कि डायरेक्टएक्स को डंप करने के लायक नहीं है।


3
"क्रॉस-प्लेटफॉर्म सिर्फ वीडियो गेम कंपनियों के दिमाग में नहीं है" - इसीलिए मैं उन कंपनियों का पूरा सम्मान करता हूं जो ऐसा करती हैं। :)
साशा चोडगोव

मैं निश्चित रूप से क्रॉस-प्लेटफॉर्म और ओपन-सोर्स दोनों के लिए प्रतिबद्ध होने के लिए कार्मैक का आभारी हूं। मैंने बस कहा कि ज्यादातर कंपनियां क्या सोचती हैं।
केस्पैक

1
यह सच है। आप लिनक्स में पोर्ट किए गए बहुत सारे लोकप्रिय वीडियो गेम नहीं देखते हैं। :(
साशा चोडगोव

क्रॉस-प्लेटफॉर्म सिर्फ ओएस पार नहीं है। PS3, Xbox 360, Wii के बारे में सोचो।
जूलियनआर

"वे एक आभासी मशीन के साथ अपना समय बर्बाद नहीं कर रहे हैं।" en.wikipedia.org/wiki/Quake_III_Arena#Virtual_machine , Carmack ने गेम लॉजिक के लिए अपना स्वयं का निर्माण किया।
जेम्स मैकमोहन

4

आप पूछ सकते हैं कि वेब एप्लिकेशन C या C ++ में भी क्यों नहीं लिखे गए हैं। जावा की शक्ति इसके नेटवर्क स्टैक और ऑब्जेक्ट ओरिएंटेड डिज़ाइन में निहित है। बेशक C और C ++ के पास भी है। लेकिन कम अमूर्त पर। यह नकारात्मक कुछ भी नहीं है, लेकिन आप हर बार पहिया को मजबूत नहीं करना चाहते हैं, क्या आप?

जावा में कोई प्रत्यक्ष हार्डवेयर एक्सेस नहीं है, जिसका अर्थ है कि आप किसी भी ढांचे के एपीआई के साथ फंस गए हैं।


जावा "
जेएनआई

4
... और पोर्टेबिलिटी खो देते हैं जब आप इसे पर हैं!
LiraNuna

1
जब आप जेएनआई का उपयोग करते हैं तो आप वास्तव में बहुत पोर्टेबिलिटी नहीं खोते हैं। बशर्ते कि आप अभी भी उन प्लेटफार्मों पर देशी पुस्तकालयों को संकलित करने में सक्षम हैं जिन्हें आप समर्थन करना चाहते हैं, इसका मूल रूप से मतलब है कि आपको केवल इन सभी के बजाय अपने कोड का 1% पोर्ट / री-कंपाइल करना होगा। जावा के पोर्टेबिलिटी से आपको अभी भी बहुत लाभ मिलता है।
bgroenks

4

प्रदर्शन और खराब जेवीएम अनुकूलन के बारे में गलत धारणाएं मेरा अनुमान होंगी। मैं प्रदर्शन के बारे में गलत धारणाएं कहता हूं क्योंकि C ++ गेम के कुछ जावा पोर्ट हैं जो उनके C ++ समकक्षों (J2 2 देखें) की तुलना में तेजी से प्रदर्शन करते हैं। असली समस्या, IMHO, यह है कि कई जावा प्रोग्रामर रक्तस्रावी किनारे के प्रदर्शन पर इतना ध्यान केंद्रित नहीं करते हैं, क्योंकि वे कोड के उपयोग और समझने / बनाए रखने में आसानी के साथ हैं। सी / सी ++ चीजों पर आप अनिवार्य रूप से एक उच्च स्तर की विधानसभा भाषा में कोडिंग कर रहे हैं और इसके बारे में हार्डवेयर के करीब है जैसा कि आप असेंबली या स्ट्रेट मशीन कोड में लिखे बिना प्राप्त कर सकते हैं।


यदि यह "असेंबली में लिखे बिना प्राप्त किए जा सकने वाले हार्डवेयर के करीब है", तो जावा इसे हरा नहीं पाएगा, जब तक कि आपकी कोडिंग भयानक न हो। आप हार्डवेयर के जितना करीब होंगे, आप उतनी ही तेजी से प्राप्त कर पाएंगे।
जोश जॉनसन

4

विकिपीडिया पर गेम इंजनों की सूची प्रोग्रामिंग गेम के साथ कई गेम इंजनों को सूचीबद्ध करती है, जिनमें वे लिखे गए हैं।

कई जावा गेम इंजन सूचीबद्ध हैं।

कुछ लिंक पर क्लिक करने से आप जावा में लिखे गए गेम और डेमो के उदाहरणों तक पहुंच जाएंगे। यहाँ एक जोड़ी है:

कुछ खेलों और स्थितियों के लिए, जावा का व्यापार-व्यवहार स्वीकार्य हो सकता है।


मुझे पता है कि खेल जावा में लिखे गए हैं। लेकिन Minecraft और Runescape के अलावा, जावा प्लेटफॉर्म के लिए बहुत कम मुख्यधारा के व्यावसायिक खेल लिखे गए हैं। जावा में कितने AAA शीर्षक लिखे गए थे? और इतना कम क्यों? इसलिए मेरा सवाल है।
साशा चोडगोव ने

3

.NET निश्चित रूप से कुछ ऐसे ही मुद्दे हैं जो जावा के गहन 3 डी प्रदर्शन की बात है। जब 3 डी हैवी ऑपरेशन के साथ काम करने की बात आती है तो Microsoft ने पुस्तकालयों के विकास में बहुत अधिक समय और पैसा लगाया है।

(... व्यक्तिगत रूप से, मुझे भी लगता है कि जब उन्होंने डायरेक्टएक्स और .NET के बीच के जादू की बात की थी, तो उनका पैर ऊपर था)


2
  1. जावा धीमा है, अधिकांश भारी उठाने को GPU द्वारा नियंत्रित नहीं किया जाता है। अभी भी एनीमेशन, भौतिकी और एआई सीपीयू को मार रहा है, जो सभी बहुत समय लेने वाले हैं।

  2. जावा कंसोल पर मौजूद नहीं है, और वाणिज्यिक खेलों के लिए कंसोल एक प्रमुख लक्ष्य हैं। यदि आप पीसी पर जावा का उपयोग करते हैं, तो आप उचित समय और बजट के भीतर कंसोल में पोर्ट करने की अपनी क्षमता को समाप्त कर रहे हैं।

  3. खेल उद्योग में अधिक अनुभवी कोडर में से कई जावा लोकप्रिय होने से बहुत पहले सी और सी ++ का उपयोग करते रहे हैं। ऊपर दिए गए दो बिंदु इसके लिए योगदान कर सकते हैं, लेकिन मुझे उम्मीद है कि कई पेशेवर गेम कोडर्स वास्तव में जावा को अच्छी तरह से नहीं जानते हैं।

  4. मिडिलवेयर के बारे में किसी और की बात अच्छी थी, इसलिए मैं इसे अपने उत्तर में जोड़ रहा हूं। विशेष रूप से C / C ++ के साथ लिंक करने के लिए बहुत सारी विरासत कोड और मिडलवेयर लिखे गए हैं, और अंतिम बार मैंने जांचा था कि जावा में अच्छी इंटरऑपरेबिलिटी नहीं है। अधिकांश कंपनियों के लिए जावा का उपयोग करने से बहुत सारे कोड बाहर हो जाते हैं, जिनमें से अधिकांश का भुगतान एक तरह से या किसी अन्य तरीके से किया जाता है।


3
आप GPU को बहुत अधिक लोड करने के लिए JavaCL, JOCL या APARAPI का उपयोग कर सकते हैं।
अक्टूबर

2

वास्तव में, प्रबंधित कोड के लिए 3 डी गेम करना बहुत संभव है, समस्या बैक इंजन है। .Net के साथ, एक संक्षिप्त अवधि के लिए, Microsoft द्वारा DirectX 9 में एक प्रबंधित DirectX आवरण था। यह अमूर्तता से पहले था जो अब XNA है।

डायरेक्टएक्स एपीआई, नेट गेम्स के लिए कुल पहुँच दी जा रही है एक इलाज का काम करते हैं। सबसे अच्छा उदाहरण मुझे पता है कि www.entombed.co.uk है, जो VB.Net में लिखा गया है।

दुर्भाग्य से, जावा पक्ष में, यह गंभीरता से कमी है - मुख्य रूप से इस कारण से कि डायरेक्टएक्स जावा के लिए उपलब्ध नहीं है, और गेम प्रोग्रामर डायरेक्टएक्स एपीआई को जानते हैं और समझते हैं - जब आप डायरेक्टएक्स पर वापस लौटेंगे तो एक और एपीआई क्यों सीखें?


2

गेम मार्केटिंग एक वाणिज्यिक प्रक्रिया है; प्रकाशक चाहते हैं कि उनके निवेश पर कम जोखिम वाले प्रतिफल हों। इसके परिणामस्वरूप, आमतौर पर प्रौद्योगिकी चालबाज़ियों (अपवादों के साथ) पर ध्यान केंद्रित किया जाता है, जो उपभोक्ता विश्वसनीय रिटर्न का उत्पादन करने के लिए खरीदेंगे - ये लेंस चमक या उच्च संकल्प जैसे सतही दृश्य प्रभाव होते हैं। ये प्रभाव विश्वसनीय हैं क्योंकि वे बस प्रसंस्करण शक्ति में वृद्धि का उपयोग करते हैं - वे हार्डवेयर का उपयोग करते हैं / मूर का नियम बढ़ता है। इसका तात्पर्य यह है कि C / C ++ - java का उपयोग आमतौर पर इन लाभों का फायदा उठाने के लिए हार्डवेयर से बहुत अधिक अलग होता है।


1

मुझे लगता है कि गति अभी भी मुद्दा है। क्रॉस प्लेटफ़ॉर्म एक ऐसा मुद्दा बनने जा रहा है जब से आपको पता नहीं है कि कोड लिखते समय 3D कार्ड क्या उपलब्ध है? क्या जावा में 3 डी क्षमताओं की ऑटो खोज का समर्थन करने के लिए कुछ भी है? और मुझे लगता है कि wii, Xbox, और ps3 के बीच एक खेल को आसान बनाने के लिए उपकरण हैं, लेकिन महंगा मैं शर्त लगा सकता हूं।

पीएस 3 में जावा है, ब्लू रे सपोर्ट के माध्यम से। Bd-j साइट की जाँच करें।


1

यहां तक ​​कि .Net प्लेटफ़ॉर्म पर लिखे गए गेम अक्सर मेमोरी और बस तक सीधी पहुंच जैसी गति के लिए अत्यधिक अनुकूलित होते हैं। .Net सी / सी ++ का उपयोग करने की अनुमति देता है और इसे सी # जैसी उच्च स्तरीय भाषाओं के साथ मिलाता है।

गेम डेवलपमेंट स्टूडियो अक्सर हार्डवेयर विक्रेताओं के साथ मिलकर काम करते हैं, जो उनके उत्पादों के निम्न स्तर के इंटरफेस तक पहुंच प्रदान करते हैं। यह एक दुनिया है, जहां आपको डिवाइस संचार के लिए एएसएम और सी का उपयोग करना होगा। एक आभासी वातावरण इन प्रोग्राम भागों को धीमा कर देगा।

वैसे भी, आधुनिक 3 डी गेम वास्तव में उच्च स्तर की भाषाओं का उपयोग करते हैं। अक्सर, आपको लुआ या पायथन जैसी भाषाओं में लिखे गए खेल तर्क मिल जाएंगे। लेकिन ठेठ 3 डी गेम के कोर (I / O, थ्रेड्स, टास्क शेड्यूलिंग) अगले 25 वर्षों के लिए निम्न स्तर की भाषाओं में लिखे जाएंगे या जब तक कि डिवाइस अपने आप (जो आएंगे) अमूर्त और वर्चुअलाइजेशन की अनुमति नहीं देते हैं।


1

मैं preexisting / लाइसेंस कोडबेस, प्रदर्शन, आदि के तत्वों का लाभ उठाने के बारे में अन्य पदों से सहमत हूं।

एक चीज जो मैं जोड़ना चाहता हूं, वह यह है कि वर्चुअल मशीन के जरिए नॉटी डीआरएम ट्रिक खींचना कठिन है।

इसके अलावा, मुझे लगता है कि वहाँ एक हब्रीस घटक है जहाँ परियोजना प्रबंधक सोचते हैं कि वे सभी उपकरणों के साथ सी + + के साथ स्थिर / विश्वसनीय कोड बना सकते हैं, जैसे कि उनके उपकरणों और संसाधनों पर पूर्ण नियंत्रण, सभी नकारात्मकताओं के बिना BUT जो कि उनकी प्रतिस्पर्धा को जटिल और सीमित कर देते हैं क्योंकि "हम ' होशियार फिर से वे कर रहे हैं "।


0

Jagex द्वारा Runescape को जावा में लिखा गया है, "वीडियो गेम" टैग विशेष रूप से इसे ऑन-लाइन गेम होने पर लागू नहीं कर सकता है, लेकिन इसका एक अच्छा पालन होता है।


क्षमा करें, लेकिन यह वास्तव में मेरे प्रश्न का उत्तर नहीं देता है।
साशा चेदिगोव

2
लेकिन सवाल का अंधा बयान इस धारणा की ओर जाता है कि जावा में कोई भी खेल नहीं लिखा गया है, जहां एक सफल मामला है।
मार्क शुलथिस

0

यह इसके बारे में बहुत पहले से ही बात की गई थी, यू विकी के कारणों पर भी पा सकते हैं ...

  • खेल इंजन और सभी गहन सामान के लिए सी / सी ++।
  • खेल में स्क्रिप्टिंग के लिए लुआ या पायथन।
  • जावा - बहुत खराब प्रदर्शन, बड़ी मेमोरी उपयोग + यह गेम कंसोल पर उपलब्ध नहीं है (यह कुछ बहुत ही सरल गेम के लिए उपयोग किया जाता है (हाँ, Runescape यहां गिना जाता है, यह बैटलफील्ड या क्राइसिस या और क्या है) सिर्फ इसलिए नहीं हैं क्योंकि वहाँ हैं बहुत सारे प्रोग्रामर जो इस प्रोग्रामिंग लैंग्वेज को जानते हैं)।
  • सी # - बड़ा मेमोरी उपयोग (यह कुछ बहुत ही सरल गेम के लिए उपयोग किया जाता है, क्योंकि बहुत प्रोग्रामर हैं जो इस प्रोग्रामिंग भाषा को जानते हैं)।

और मैं अधिक से अधिक जावा प्रोग्रामर सुनता हूं जो लोगों को यह समझाने की कोशिश करते हैं कि जावा धीमा नहीं है, यह स्क्रीन पर एक विजेट बनाने और विजेट पर कुछ ASCII वर्णों को खींचने के लिए धीमा नहीं है, नेटवर्क के माध्यम से डेटा प्राप्त करने और भेजने के लिए (और यह है) C / C ++ के बजाय इस स्थिति (नेटवर्क डेटा हेरफेर) में इसका उपयोग करने की सिफारिश की गई है ... लेकिन जब गणित की गणना, मेमोरी आवंटन / हेरफेर और इस अच्छे सामान की बहुत गंभीर चीजें आती हैं, तो यह धीमी गति से होता है।

मुझे MIT साइट पर एक लेख याद है जहां वे दिखाते हैं कि C / C ++ क्या कर सकता है यदि आप भाषा और संकलक सुविधाओं का उपयोग करते हैं: एक मैट्रिक्स गुणक (2 मैट्रिक्स), जावा में 1 कार्यान्वयन और C / C ++ में 1 कार्यान्वयन, C / C ++ सुविधाओं के साथ। और उपयुक्त संकलक अनुकूलन सक्रिय किया गया, C / C ++ कार्यान्वयन जावा कार्यान्वयन की तुलना में ~ 296 260 गुना तेज था।

मुझे उम्मीद है कि अब आप समझ गए होंगे कि लोग खेलों में जावा के बजाय C / C ++ का उपयोग क्यों करते हैं, जावा में Crysis की कल्पना करते हैं, इस दुनिया में कोई भी ऐसा कंप्यूटर नहीं होगा जो यह संभाल सके कि ... + कचरा संग्रह विजेट के लिए ठीक काम करता है जिसने सिर्फ एक छवि को नष्ट कर दिया लेकिन यह अभी भी वहां कैश्ड है और इसे साफ करने की जरूरत है, लेकिन खेलों के लिए नहीं, निश्चित रूप से, यू में हर कचरा संग्रह सक्रियण पर और भी अधिक अंतराल होंगे।

संपादित करें : क्योंकि किसी ने लेख के लिए कहा था, यहाँ, मैंने इसे प्राप्त करने के लिए वेब संग्रह में खोज की, मुझे आशा है कि आप संतुष्ट हैं ... एमआईटी केस स्टडी

और जोड़ने के लिए, नहीं, गेमिंग के लिए जावा अभी भी एक भयानक विचार है। अभी कुछ दिनों पहले एक बड़ी कंपनी है कि मैं उनके गेम क्लाइंट को जावा से C ++ में फिर से लिखना शुरू नहीं करूंगा क्योंकि एक बहुत ही सरल गेम (ग्राफिक्स के संदर्भ में) शक्तिशाली nVidia GT 5xx और 6xxx वीडियो कार्ड के साथ i7 लैपटॉप को गर्म कर रहा था ( एनवीडिया ही नहीं, यहाँ बिंदु यह है कि यह शक्तिशाली कार्ड जो अधिकतम सेटिंग्स को नए गेम में संभाल सकते हैं और इस गेम को नहीं संभाल सकते हैं) और मेमोरी की खपत ~ 2.5 - 2.6 जीबी रैम थी। ऐसे सरल ग्राफिक्स के लिए इसे मशीन के एक जानवर की आवश्यकता होती है।


10
आप आधुनिक जावा रनटाइम और वर्चुअल मशीन के बारे में स्पष्ट रूप से बहुत कम जानते हैं। आपके द्वारा उल्लिखित लेख एक दशक पहले या उससे अधिक होने की संभावना से अधिक है, निश्चित रूप से कोई भी नहीं जान सकता क्योंकि आपने इसे उद्धृत नहीं किया था। जावा की आपकी धारणा पुरानी है।
bgroenks

2
ठीक है कि अध्ययन से साबित होता है कि बड़े पैमाने पर मैट्रिक्स गुणा करने के लिए जावा सी को खो देता है जब डेटा का उपयोग करने के लिए 2-आयामी सरणी का उपयोग किया जा रहा है। हाँ मुझे लगता है कि यह भी होगा। और अगर यह वास्तव में आपके लिए एक समस्या है, जो मुझे संदेह है कि यह होगा, इसलिए आपको जेएनआई है। सरणियों के लिए ओवरहेड की जाँच करने की सीमा उस स्थिति में बढ़ जाती है, हालांकि उसके जावा कोड को काफी बेहतर परिणामों के लिए अनुकूलित किया जा सकता था। इसी तरह, मैं JIT की उनकी समझ पर सवाल उठाता हूं जब वह कहता है, "तेज संकलन = उत्पन्न सर्वोत्तम कोड नहीं।" अन्यथा साबित करने के लिए आईबीएम के विनिर्देश पढ़ें।
bgroenks

3
जावा खेल के विकास के लिए एक बुरा विकल्प नहीं है। वहाँ बहुत सारे सफल गेम हैं जो जावा चलाते हैं। आमतौर पर, आपको वास्तव में सर्वोत्तम परिणाम प्राप्त करने के लिए मूल कोड (विशेषकर LWJGL और ऐसे) के साथ थोड़ी सी मदद की आवश्यकता होती है। लेकिन अगर मुझे केवल 100% के बजाय अपने कोड का 1% पोर्ट करना और फिर से प्राप्त करना है, तो यह मेरे लिए बहुत बड़ी बात है।
bgroenks

1
@broroenks "100%" - ऐसा लगता है कि आपको C / C ++ के बारे में कोई पता नहीं है ... और एक गेम बनाते समय आप हमेशा क्रॉस-प्लेटफॉर्म लाइब्रेरी (दूसरों के लिए SDL और एक गुच्छा) या फ्रेमवर्क (उदाहरण के लिए Qt) का उपयोग कर सकते हैं। उदाहरण के लिए: ईए Qt का उपयोग पूरी तरह से हर गेम के लिए करता है ... Qt जावा की तुलना में अधिक क्रॉस-प्लेटफ़ॉर्म है और यह देशी कोड के लिए संकलित है।
लिलियन ए। मोरारू

2
जब आपके पास Qt है तो मैं वास्तव में जावा में बिंदु नहीं देखता। मुझे Qt कोड अधिक स्पष्ट, समझने और जावा कोड से बनाए रखने में आसान लगता है। जब मैं अपने दोस्तों से पूछता हूं कि उन्हें C ++ से इतना डर ​​क्यों है तो वे हमेशा मुझे बताते हैं कि वे पॉइंटर्स से नफरत करते हैं और याददाश्त को कम करना सुनिश्चित करते हैं। ऐसा लगता है कि बहुत से लोग C ++ में शेयर्ड_एप्ट्र के बारे में नहीं जानते हैं ... मेरे लिए, क्यूटी और सी # .NET / C ++ .NET में लिखना सबसे अच्छा है। जावा कोड आमतौर पर अपवाद हैंडलिंग के साथ बहुत फूला हुआ है, आमतौर पर पुरानी लाइब्रेरी हैं। (यह केवल सर्वर की ओर से बाकी पर अच्छा कर रहा है ... बाकी) और अक्सर पुराना प्रलेखन।
लिलियन ए। मोरारू
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.