Author: demensdeum

डोंकी हिल्स पिछले एक साल से अधिक समय से स्टीम पर है!

ठीक एक साल पहले यह प्रोजेक्ट स्टीम पेज पर दिखाई दिया था और तब से यह गेम काफी आगे बढ़ चुका है। इस दौरान, डोनकी हिल्स का विकास किस दिशा में होना चाहिए, इसके लिए कई प्रयोग, परिवर्तन और खोजें हुईं।

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

एक अजीब साहसिक कार्य जहां डरावनी हास्य, अन्वेषण और अप्रत्याशित स्थितियों से मिलती है। आपको शहर जाना होगा, वस्तुओं की तलाश करनी होगी, पहेलियों को सुलझाना होगा और धीरे-धीरे उस रहस्य को उजागर करना होगा जो आपको मारिया तक ले जाएगा।

प्रोटोटाइप के अगले प्लेटेस्ट के ताज़ा स्क्रीनशॉट नीचे दिए गए हैं। यह अभी खेल का अंतिम रूप नहीं है, लेकिन आप पहले से ही शहर के माहौल और परियोजना किस दिशा में आगे बढ़ रही है, महसूस कर सकते हैं।

आपकी प्रतिक्रिया सुनने में बहुत दिलचस्पी है! 👀
आपको नई दिशा कैसी लगी? खेल के माहौल और विचारों के बारे में आपकी क्या राय है?

उन सभी को धन्यवाद जिन्होंने डोंकी हिल्स को अपनी इच्छा सूची में जोड़ा, विकास का अनुसरण किया और परियोजना का समर्थन किया ❤️

आगे अभी भी कई प्रयोग, नई यांत्रिकी और अजीब रोमांच बाकी हैं।

https://store.steampowered.com/app/3476390/Donki_Hills/

आधुनिक गेमिंग लैपटॉप के निर्माता अक्सर सिस्टम को कॉन्फ़िगर करते हैं ताकि प्रोसेसर 90 डिग्री तक गर्म हो और यहां तक ​​कि लोड के तहत 100 डिग्री सेल्सियस तक पहुंच जाए। यह समस्या विशेष रूप से गर्मियों में तीव्र होती है जब कठिन खेल या भारी काम वाले कार्य चल रहे होते हैं।

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

विधि बिजली आपूर्ति सेटिंग्स के माध्यम से अधिकतम प्रोसेसर स्थिति को सीमित करने के लिए है:

1. विंडोज़ सर्च या कंट्रोल पैनल के माध्यम से पावर विकल्प खोलें।
2. सक्रिय विद्युत योजना में, अतिरिक्त पैरामीटर बदलने के लिए अनुभाग पर जाएँ।
3. प्रोसेसर पावर प्रबंधन शाखा ढूंढें।
4. अधिकतम प्रोसेसर स्थिति विकल्प का विस्तार करें।
5. प्लग इन के लिए, मान को 100% से 80% या उससे कम में बदलें।

इन सेटिंग्स को लागू करने के बाद, प्रोसेसर स्वचालित रूप से अत्यधिक आवृत्तियों पर ओवरक्लॉक नहीं करेगा जो अतिरिक्त गर्मी उत्पन्न करते हैं। हालाँकि अधिकतम शिखर प्रदर्शन में लगभग 20% की कमी आएगी, प्रोसेसर अब ज़्यादा गरम नहीं होगा। थ्रॉटलिंग के बिना कम आवृत्ति पर स्थिर संचालन 100 डिग्री से कम तापमान पर ओवरहीटिंग के कारण प्रदर्शन में लगातार तेज उछाल की तुलना में सिस्टम के लिए बहुत बेहतर और अधिक आरामदायक है।

प्रत्येक लैपटॉप अद्वितीय है, इसलिए मेरा सुझाव है कि उपयोगकर्ता प्रयोग करें और इष्टतम संतुलन (प्रतिशत) ढूंढें जो ओवरहीटिंग के बिना वांछित प्रदर्शन प्रदान करेगा।

इस पोस्ट में मैं बताऊंगा कि कैसे मैंने Surreal इंजन गेम इंजन को WebAssembly में पोर्ट किया।
https://demensdeum.com/demos/SurrealEngine/”
अवास्तविक इंजन – एक गेम इंजन जो अवास्तविक इंजन 1 की अधिकांश कार्यक्षमता को लागू करता है, इस इंजन पर प्रसिद्ध गेम – अवास्तविक टूर्नामेंट 99, अवास्तविक, ड्यूस एक्स, अनडाइंग। यह क्लासिक इंजनों को संदर्भित करता है जो मुख्य रूप से एकल-थ्रेडेड निष्पादन वातावरण में काम करते हैं।
मूल रूप से मेरे मन में एक ऐसे प्रोजेक्ट को लेने का विचार था जिसे मैं किसी भी उचित समय सीमा में पूरा नहीं कर सका, इस प्रकार मैंने अपने ट्विच अनुयायियों को दिखाया कि ऐसे प्रोजेक्ट भी हैं जिन्हें मैं भी नहीं कर सकता। अपनी पहली स्ट्रीम के दौरान, मुझे अचानक एहसास हुआ कि Emscripten का उपयोग करके Surreal इंजन C++ को WebAssembly में पोर्ट करने का कार्य संभव था।

एक महीने बाद, मैं WebAssembly पर अपना फ़ोर्क और इंजन असेंबली प्रदर्शित कर सकता हूँ:
https://demensdeum.com/demos/SurrealEngine/
नियंत्रण, मूल की तरह, कीबोर्ड तीरों का उपयोग करके किया जाता है। इसके बाद, मैं इसे मोबाइल नियंत्रण (टैची) के लिए अनुकूलित करने की योजना बना रहा हूं, जिसमें सही प्रकाश व्यवस्था और अवास्तविक टूर्नामेंट 99 रेंडर की अन्य ग्राफिक विशेषताएं शामिल हैं।

कहां से शुरू करें?

पहली बात जो मैं कहना चाहता हूं वह यह है कि किसी भी प्रोजेक्ट को Emscripten का उपयोग करके C++ से WebAssembly में पोर्ट किया जा सकता है, एकमात्र सवाल यह है कि कार्यक्षमता कितनी पूर्ण होगी। ऐसा प्रोजेक्ट चुनें जिसके लाइब्रेरी पोर्ट एम्सस्क्रिप्टेन के लिए पहले से ही उपलब्ध हों; Surreal इंजन के मामले में, आप बहुत भाग्यशाली हैं, क्योंकि इंजन SDL 2, OpenAL – का उपयोग करता है। पुस्तकालय. वे दोनों एम्सस्क्रिप्टेन में पोर्ट किए गए हैं। हालाँकि, वल्कन का उपयोग ग्राफिक्स एपीआई के रूप में किया जाता है, जो वर्तमान में HTML5 के लिए उपलब्ध नहीं है, WebGPU को लागू करने के लिए काम चल रहा है, लेकिन यह ड्राफ्ट चरण में भी है, और यह भी अज्ञात है कि पूरी तरह से मानकीकृत होने के बाद Vulkan से WebGPU तक का पोर्ट कितना सरल होगा। इसलिए, मुझे Surreal इंजन के लिए अपना स्वयं का मूल OpenGL-ES/WebGL रेंडरर लिखना पड़ा।

परियोजना का निर्माण

Surreal इंजन में सिस्टम बनाएँ – सीएमके, जो पोर्टिंग को भी सरल बनाता है, क्योंकि एम्सस्क्रिप्टन अपने मूल बिल्डरों को प्रदान करता है – एममेक, एममेक।
Surreal इंजन पोर्ट WebGL/OpenGL ES और C++ में डेथ-मास्क नामक मेरे नवीनतम गेम के कोड पर आधारित था, इस वजह से विकास बहुत सरल था, मेरे पास सभी आवश्यक बिल्ड फ़्लैग और कोड उदाहरण थे।
CMakeLists.txt में सबसे महत्वपूर्ण बिंदुओं में से एक Emscripten के लिए बिल्ड फ़्लैग है, नीचे प्रोजेक्ट फ़ाइल से एक उदाहरण दिया गया है:

set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
-s MAX_WEBGL_VERSION=2 
-s EXCEPTION_DEBUG 
-fexceptions 
--preload-file UnrealTournament/ 
--preload-file SurrealEngine.pk3 
--bind 
--use-preload-plugins 
-Wall 
-Wextra 
-Werror=return-type 
-s USE_SDL=2 
-s ASSERTIONS=1 
-w 
-g4 
-s DISABLE_EXCEPTION_CATCHING=0 
-O3 
--no-heap-copy 
-s ALLOW_MEMORY_GROWTH=1 
-s EXIT_RUNTIME=1")

बिल्ड स्क्रिप्ट स्वयं:

clear
emmake make -j 16
cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html

इसके बाद, आइए index.html तैयार करें, जिसमें प्रोजेक्ट फ़ाइल सिस्टम प्रीलोडर शामिल है। वेब पर अपलोड करने के लिए, मैंने अवास्तविक टूर्नामेंट डेमो संस्करण 338 का उपयोग किया। जैसा कि आप सीएमके फ़ाइल से देख सकते हैं, अनपैक्ड गेम फ़ोल्डर को बिल्ड निर्देशिका में जोड़ा गया था और एम्सस्क्रिप्टेन के लिए प्रीलोड-फ़ाइल के रूप में लिंक किया गया था।

मुख्य कोड परिवर्तन

फिर हमें गेम के गेम लूप को बदलना पड़ा, आप एक अंतहीन लूप नहीं चला सकते, इससे ब्राउज़र फ़्रीज़ हो जाता है, इसके बजाय आपको emscripten_set_main_loop का उपयोग करने की आवश्यकता है, मैंने इस सुविधा के बारे में अपने 2017 नोट में लिखा था ” target=’_blank’>SDL C++ गेम्स को HTML5 (Emscripten) में पोर्ट करना”
हम while लूप से बाहर निकलने के लिए कोड को if में बदलते हैं, फिर हम गेम इंजन के मुख्य वर्ग को प्रदर्शित करते हैं, जिसमें गेम लूप होता है, वैश्विक दायरे में, और एक वैश्विक फ़ंक्शन लिखते हैं जो वैश्विक ऑब्जेक्ट से गेम लूप चरण को कॉल करेगा:

#if __EMSCRIPTEN__
#include <emscripten.h>
Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
void emscripten_game_loop_step() {
	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
}
#endif

इसके बाद, आपको यह सुनिश्चित करना होगा कि एप्लिकेशन में कोई पृष्ठभूमि थ्रेड नहीं हैं; यदि हैं, तो एकल-थ्रेडेड निष्पादन के लिए उन्हें फिर से लिखने के लिए तैयार हो जाएं, या एम्सस्क्रिप्टन में phtread लाइब्रेरी का उपयोग करें।
Surreal इंजन में बैकग्राउंड थ्रेड का उपयोग संगीत चलाने के लिए किया जाता है, मुख्य इंजन थ्रेड से वर्तमान ट्रैक, संगीत चलाने की आवश्यकता या उसकी अनुपस्थिति के बारे में डेटा आता है, फिर बैकग्राउंड थ्रेड म्यूटेक्स के माध्यम से एक नई स्थिति प्राप्त करता है और नया संगीत बजाना शुरू कर देता है, या रुक जाता है। प्लेबैक के दौरान संगीत को बफ़र करने के लिए बैकग्राउंड थ्रेड का भी उपयोग किया जाता है।
पाथ्रेड के साथ एम्सस्क्रिप्टेन के लिए सररियल इंजन बनाने के मेरे प्रयास असफल रहे, क्योंकि एसडीएल2 और ओपनएएल पोर्ट बिना पाथ्रेड समर्थन के बनाए गए थे, और मैं संगीत के लिए उनका पुनर्निर्माण नहीं करना चाहता था। इसलिए, मैंने लूप का उपयोग करके पृष्ठभूमि संगीत स्ट्रीम की कार्यक्षमता को एकल-थ्रेडेड निष्पादन में स्थानांतरित कर दिया। C++ कोड से pthread कॉल्स को हटाकर, मैंने बफ़रिंग और संगीत प्लेबैक को मुख्य थ्रेड में स्थानांतरित कर दिया, ताकि कोई देरी न हो, मैंने बफ़र को कुछ सेकंड तक बढ़ा दिया।
आगे, मैं ग्राफिक्स और ध्वनि के विशिष्ट कार्यान्वयन का वर्णन करूंगा।

वल्कन समर्थित नहीं है!

हाँ, Vulkan HTML5 में समर्थित नहीं है, हालाँकि सभी मार्केटिंग ब्रोशर Vulkan के मुख्य लाभ के रूप में क्रॉस-प्लेटफ़ॉर्म और व्यापक प्लेटफ़ॉर्म समर्थन प्रस्तुत करते हैं। इस कारण से, मुझे सरलीकृत OpenGL प्रकार – के लिए अपना स्वयं का मूल ग्राफ़िक्स रेंडरर लिखना पड़ा। ईएस, इसका उपयोग मोबाइल उपकरणों पर किया जाता है, कभी-कभी इसमें आधुनिक ओपनजीएल की फैशनेबल विशेषताएं शामिल नहीं होती हैं, लेकिन यह वेबजीएल को बहुत अच्छी तरह से पोर्ट करता है, जो कि एम्सस्क्रिप्टेन लागू करता है। सबसे सरल जीयूआई डिस्प्ले के लिए बुनियादी टाइल रेंडरिंग, बीएसपी रेंडरिंग लिखना और मॉडल + मैप रेंडर करना दो सप्ताह में पूरा हो गया। यह शायद परियोजना का सबसे कठिन हिस्सा था। Surreal इंजन रेंडरिंग की पूर्ण कार्यक्षमता को लागू करने के लिए अभी भी बहुत काम बाकी है, इसलिए कोड और पुल अनुरोधों के रूप में पाठकों की किसी भी मदद का स्वागत है।

OpenAL समर्थित!

बड़ी किस्मत यह है कि Surreal इंजन ऑडियो आउटपुट के लिए OpenAL का उपयोग करता है। OpenAL में एक सरल हैलो वर्ल्ड लिखने और इसे Emscripten का उपयोग करके WebAssembly में इकट्ठा करने के बाद, मुझे यह स्पष्ट हो गया कि सब कुछ कितना सरल था, और मैंने ध्वनि को पोर्ट करना शुरू कर दिया।
कई घंटों की डिबगिंग के बाद, यह स्पष्ट हो गया कि एम्सस्क्रिप्टेन के ओपनएएल कार्यान्वयन में कई बग हैं, उदाहरण के लिए, जब मोनो चैनलों की संख्या को पढ़ना शुरू किया जाता है, तो विधि एक अनंत संख्या लौटाती है, और अनंत आकार के वेक्टर को प्रारंभ करने का प्रयास करने के बाद, C++ अपवाद वेक्टर::लेंथ_एरर के साथ क्रैश हो जाता है।
हम मोनो चैनलों की संख्या को 2048 तक हार्डकोड करके इससे निजात पाने में कामयाब रहे:

		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);

#if __EMSCRIPTEN__
		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
#endif

क्या कोई नेटवर्क है?

Surreal इंजन वर्तमान में ऑनलाइन खेल का समर्थन नहीं करता है, बॉट्स के साथ खेलना समर्थित है, लेकिन हमें इन बॉट्स के लिए AI लिखने के लिए किसी की आवश्यकता है। सैद्धांतिक रूप से, आप Websockets का उपयोग करके WebAssembly/Emscripten पर एक नेटवर्क गेम लागू कर सकते हैं।

निष्कर्ष

अंत में, मैं यह कहना चाहूंगा कि पुस्तकालयों के उपयोग के कारण Surreal इंजन की पोर्टिंग काफी सुचारू हो गई, जिसके लिए Emscripten पोर्ट हैं, साथ ही Emscripten पर WebAssembly के लिए C++ में एक गेम को लागू करने का मेरा पिछला अनुभव भी है। विषय पर ज्ञान के स्रोतों और भंडारों के लिंक नीचे दिए गए हैं।
एम-एम-एम-राक्षस हत्या!
इसके अलावा, यदि आप प्रोजेक्ट में मदद करना चाहते हैं, अधिमानतः वेबजीएल/ओपनजीएल ईएस रेंडरिंग कोड के साथ, तो मुझे टेलीग्राम में लिखें:
https://t.me/demenscave

लिंक

https://demensdeum.com/demos/SurrealEngine/

https://github.com/demensdeum/SurrealEngine-Emscripten

https://github.com/dpjudas/SurrealEngine

जब दो डिवाइस NAT या सख्त फ़ायरवॉल के पीछे होते हैं और एक दूसरे को सीधे “देख” नहीं सकते हैं, तो वीपीएन मानक समाधान प्रतीत होता है। लेकिन एक पूर्ण विकसित L3 सुरंग (जैसे वायरगार्ड या ओपनवीपीएन) अक्सर अनावश्यक होती है: इसके लिए रूट अधिकारों की आवश्यकता होती है, वर्चुअल इंटरफेस स्थापित करना पड़ता है, और मौजूदा मार्गों के साथ टकराव हो सकता है।

ऐसे मामलों में, छेनी का उपयोग करना सुविधाजनक है – एक टीसीपी/यूडीपी सुरंग जो HTTP के शीर्ष पर चलती है और डेटा ट्रांसफर के लिए वेबसॉकेट का उपयोग करती है। इस नोट में मैं दिखाऊंगा कि एक इंटरमीडिएट सर्वर के माध्यम से एक क्लाइंट से दूसरे क्लाइंट तक पोर्ट को “फॉरवर्ड” कैसे किया जाए।

यह कैसे काम करता है?

स्थिति की कल्पना करें: आपके पास क्लाइंट A (उदाहरण के लिए, आपका होम सर्वर), क्लाइंट B (आपका कार्य लैपटॉप) और सार्वजनिक IP पते वाला एक VPS है। ग्राहक ए और बी वीपीएस तक पहुंच सकते हैं, लेकिन एक दूसरे को नहीं।

अग्रेषण योजना इस प्रकार होगी:
1. क्लाइंट ए वीपीएस से जुड़ता है और सर्वर पर एक “रिवर्स” पोर्ट खोलता है। अब सर्वर के पोर्ट X पर आने वाली हर चीज़ क्लाइंट A के पोर्ट Y पर जाती है।
2. क्लाइंट बी वीपीएस से जुड़ता है और पोर्ट Z को अपनी स्थानीय मशीन से सर्वर के पोर्ट X तक अग्रेषित करता है।
3. परिणामस्वरूप, क्लाइंट B localhost:Z तक पहुंचता है और क्लाइंट A:Y पर समाप्त होता है।

यह दृष्टिकोण उन मामलों में समाधानों में से एक है जहां वीपीएस के साथ संचार एल 3 परत को लागू नहीं करता है या ग्राहकों के बीच रूटिंग को कॉन्फ़िगर करने की कोई क्षमता नहीं है। हम विशेष रूप से एप्लिकेशन और पोर्ट स्तर पर काम करते हैं।

चरण 1: सर्वर प्रारंभ करें

अपने VPS पर, बस Chisel को सर्वर मोड में चलाएँ। क्लाइंट को सर्वर साइड पर पोर्ट खोलने की अनुमति देने के लिए <कोड>–रिवर्स ध्वज की आवश्यकता होती है।

chisel server --port 8080 --reverse

चरण 2: क्लाइंट ए (स्रोत) को कनेक्ट करना

मान लीजिए कि क्लाइंट ए पोर्ट 3000 पर अपने स्थानीय वेब सर्वर तक पहुंच खोलना चाहता है। वह वीपीएस से जुड़ता है और कहता है: “सर्वर पर पोर्ट 2000 रिजर्व करें और इसे मुझे 3000 पर अग्रेषित करें।”

chisel client vps-ip:8080 R:2000:127.0.0.1:3000

अब वीपीएस (लूपबैक इंटरफ़ेस पर) पर पोर्ट 2000 क्लाइंट ए की ओर ले जाता है।

चरण 3: क्लाइंट बी (उपभोक्ता) को कनेक्ट करना

अब क्लाइंट बी इस संसाधन तक पहुंचना चाहता है। यह उसी वीपीएस से जुड़ता है और अपने स्थानीय पोर्ट 8080 को सर्वर के पोर्ट 2000 पर भेजता है।

chisel client vps-ip:8080 8080:127.0.0.1:2000

तैयार! अब, जब आप क्लाइंट बी पर http://localhost:8080 खोलेंगे, तो आप क्लाइंट ए पर चल रही सेवा देखेंगे।

सुरक्षा और बारीकियाँ

चिसेल --auth ध्वज के माध्यम से प्रमाणीकरण का समर्थन करता है, जिसे सार्वजनिक सर्वर के माध्यम से काम करते समय अत्यधिक अनुशंसित किया जाता है। आप ट्रैफ़िक को एन्क्रिप्ट करने के लिए टीएलएस प्रमाणपत्र का भी उपयोग कर सकते हैं।

इस दृष्टिकोण का मुख्य लाभ यह है कि TUN/TAP डिवाइस और जटिल रूटिंग टेबल की कोई आवश्यकता नहीं है। यह एक स्ट्रिप-डाउन सुरंग है जो बिल्कुल एक काम करती है: वेबसॉकेट कनेक्शन के माध्यम से बंदरगाहों को बांधती है। यदि आप पोर्ट 443 के माध्यम से काम करने के लिए चिसेल को कॉन्फ़िगर करते हैं तो यह कॉर्पोरेट प्रॉक्सी के माध्यम से भी काम करता है।

आउटपुट

छेनी विशिष्ट नेटवर्क कार्यों के लिए एक उपयोगिता है। जब आपको एक पूर्ण वीपीएन स्थापित किए बिना अलग-अलग नोड्स के बीच पोर्ट को अग्रेषित करने की आवश्यकता होती है, तो रिले सर्वर के माध्यम से आगे और पीछे सुरंगों का संयोजन पूरी तरह से व्यवहार्य समाधान बन जाता है।

लिंक

https://github.com/jpillora/chisel

आप कोड पर काम करने, परिकल्पनाओं को समझने, स्थितियों को समायोजित करने में घंटों बिताते हैं, लेकिन बग अभी भी पुन: उत्पन्न होता है। परिचित लग रहा है? हताशा की इस स्थिति को अक्सर “भूत शिकार” कहा जाता है। ऐसा लगता है कि प्रोग्राम आपके सुधारों को नज़रअंदाज़ करते हुए अपना जीवन जी रहा है।

इस स्थिति के लिए सबसे आम – और सबसे कष्टप्रद – कारणों में से एक है एप्लिकेशन में पूरी तरह से गलत जगह पर त्रुटि की तलाश करना।

“झूठे लक्षणों” का जाल

जब हम कोई त्रुटि देखते हैं, तो हमारा ध्यान उस स्थान पर जाता है जहां उसने “शूट” किया था। लेकिन जटिल प्रणालियों में, जहां बग होता है (क्रैश या गलत मान) घटनाओं की एक लंबी श्रृंखला का अंत मात्र है। जब आप अंत को ठीक करने का प्रयास करते हैं, तो आप लक्षणों से लड़ रहे हैं, बीमारी से नहीं।

यही वह जगह है जहां फ़्लोचार्ट अवधारणा आती है।

यह वास्तविकता में कैसे काम करता है

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

इस संरचना को समझे बिना, डेवलपर अक्सर अंधेरे में टटोलता रहता है। स्थिति की कल्पना करें: आप तर्क को एक शर्त शाखा में संपादित करते हैं, जबकि एप्लिकेशन (मापदंडों के एक निश्चित सेट के कारण) एक पूरी तरह से अलग शाखा में जाता है जिसके बारे में आपने सोचा भी नहीं था।

<ब्लॉककोट>
परिणाम: आप एल्गोरिथम के एक हिस्से में “परफेक्ट” कोड फिक्स पर घंटों बिताते हैं, जो निस्संदेह, एल्गोरिथम के दूसरे हिस्से में समस्या को ठीक करने के लिए कुछ नहीं करता है जहां यह वास्तव में विफल रहता है।

<घंटा />

बग को हराने के लिए एल्गोरिदम

बंद दरवाजे पर पिटाई रोकने के लिए, आपको निदान के प्रति अपना दृष्टिकोण बदलना होगा:

• परिणाम ट्री में स्थिति ढूंढें:कोड लिखने से पहले, आपको बिल्कुल वही पथ निर्धारित करना होगा जो एप्लिकेशन ने लिया है। किस बिंदु पर तर्क ने गलत मोड़ ले लिया? किस विशिष्ट स्थिति (राज्य) के कारण समस्या उत्पन्न हुई?
• पुनरुत्पादन 80% सफलता है: यह आमतौर पर परीक्षकों और स्वचालित परीक्षणों द्वारा किया जाता है। यदि बग “फ़्लोटिंग” है, तो संयुक्त रूप से स्थितियों की खोज करने की प्रक्रिया में विकास शामिल है।
• जितना संभव हो उतनी जानकारी का उपयोग करें: लॉग, ओएस संस्करण, डिवाइस पैरामीटर, कनेक्शन प्रकार (वाई-फाई/5जी) और यहां तक ​​​​कि एक विशिष्ट दूरसंचार ऑपरेटर स्थानीयकरण के लिए महत्वपूर्ण हैं।

त्रुटि के क्षण का “फ़ोटोग्राफ़”

आदर्श रूप से, इसे ठीक करने के लिए, आपको बग पुन: उत्पन्न होने के समय एप्लिकेशन की पूर्ण स्थिति प्राप्त करने की आवश्यकता है। इंटरेक्शन लॉग भी अत्यंत महत्वपूर्ण हैं: वे न केवल अंतिम बिंदु दिखाते हैं, बल्कि संपूर्ण उपयोगकर्ता पथ भी दिखाते हैं (विफलता से पहले कौन सी कार्रवाइयां हुईं)। इससे यह समझने में मदद मिलती है कि एक समान स्थिति को दोबारा कैसे बनाया जाए।

भविष्य की युक्ति: यदि आप किसी जटिल मामले का सामना करते हैं, तो स्थिति दोबारा होने की स्थिति में कोड के इस अनुभाग में विस्तारित डिबग लॉगिंग जानकारी जोड़ें।

<घंटा />

एआई के युग में “मायावी” स्थिति की समस्या

एलएलएम (बड़े भाषा मॉडल) का उपयोग करने वाली आधुनिक प्रणालियों में, शास्त्रीय नियतिवाद (“एक इनपुट, एक आउटपुट”) का अक्सर उल्लंघन किया जाता है। आप बिल्कुल वही इनपुट डेटा पास कर सकते हैं, लेकिन एक अलग परिणाम प्राप्त कर सकते हैं।

ऐसा आधुनिक उत्पादन प्रणालियों की गैर-नियतिवाद के कारण होता है:

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

ऐसी परिस्थितियों में, “उसी स्थिति” को पुन: उत्पन्न करना लगभग असंभव हो जाता है। परीक्षण के लिए केवल एक सांख्यिकीय दृष्टिकोण ही आपको यहां बचा सकता है।

<घंटा />

जब तर्क विफल हो जाता है: स्मृति समस्याएं

यदि आप “असुरक्षित” भाषाओं (C या C++) के साथ काम कर रहे हैं, तो बग मेमोरी करप्शन के कारण हो सकता है।

ये सबसे गंभीर मामले हैं: एक मॉड्यूल में त्रुटि दूसरे में डेटा को “ओवरराइट” कर सकती है। यह पूरी तरह से अस्पष्ट और पृथक विफलताओं की ओर ले जाता है जिन्हें सामान्य एप्लिकेशन लॉजिक का उपयोग करके पता नहीं लगाया जा सकता है।

वास्तुकला स्तर पर अपनी सुरक्षा कैसे करें?

ऐसे “रहस्यमय” बग से बचने के लिए, आपको आधुनिक तरीकों का उपयोग करना चाहिए:

• मल्टीथ्रेडेड प्रोग्रामिंग पैटर्न:स्पष्ट सिंक्रनाइज़ेशन दौड़ की स्थितियों को समाप्त कर देता है।
• थ्रेड-सुरक्षित भाषाएँ: उपकरण जो संकलन समय पर मेमोरी सुरक्षा की गारंटी देते हैं:
  • जंग: स्वामित्व प्रणाली मेमोरी त्रुटियों को समाप्त करती है।
  • स्विफ्ट 6 कंकरेंसी:मजबूत डेटा अलगाव जांच।
  • एरलांग: अभिनेता मॉडल के माध्यम से पूर्ण प्रक्रिया अलगाव।

सारांश

बग को ठीक करना नया कोड लिखने के बारे में नहीं है, बल्कि यह समझने के बारे में है कि पुराना कोड कैसे काम करता है। याद रखें: आप उस शाखा को संपादित करने में समय बर्बाद कर सकते हैं जिसे प्रबंधन छूता भी नहीं है। सिस्टम की स्थिति रिकॉर्ड करें, एआई गैर-नियतिवाद के कारक को ध्यान में रखें और सुरक्षित उपकरण चुनें।

(और ऐसे समाधान कैसे बनाएं जो अपडेट के बाद भी काम करते रहें)

“ऐप्स केवल सार्वजनिक एपीआई का उपयोग कर सकते हैं और उन्हें वर्तमान शिपिंग ओएस पर चलना चाहिए।” ऐप्पल ऐप समीक्षा दिशानिर्देश

यदि आपने कभी किसी नए ढांचे के साथ काम करना शुरू किया है और खुद को यह सोचते हुए पाया है: “अब मैं खुद ही सब कुछ समझ लूंगा, दस्तावेज पढ़ना बहुत लंबा है,” आप निश्चित रूप से अकेले नहीं हैं। हममें से कई लोगों में स्वाभाविक खोजी प्रवृत्ति होती है: पहले प्रयास करें, और उसके बाद ही निर्देशों को देखें। और यह बिल्कुल सामान्य है.

हालाँकि, इस स्तर पर बहक जाना और ऐसी स्थिति में पहुँचना आसान हो सकता है जहाँ कोड बढ़िया काम करता है, लेकिन शायद सिस्टम की गैर-स्पष्ट विशेषताओं पर निर्भर करता है।

कभी-कभी केवल “इसे स्वयं ही समझ लेना” पर्याप्त क्यों नहीं होता?

फ्रेमवर्क, विशेष रूप से बंद फ्रेमवर्क, जटिल और बहुस्तरीय सिस्टम हैं। वे अक्सर आंतरिक तर्क और अनुकूलन छिपाते हैं:

*सार्वजनिक दस्तावेज़ीकरण में वर्णित नहीं हैं;
*इस बात की गारंटी न दें कि व्यवहार भविष्य में भी बना रहेगा;
* नए संस्करण जारी होने के साथ बदल सकता है;
* इसमें डेवलपर्स को ज्ञात विशेषताएं शामिल हो सकती हैं जिन्हें अभी तक ठीक नहीं किया गया है।

जब हम सहज ज्ञान से कार्य करते हैं, तो दस्तावेजी नियमों के बजाय यादृच्छिक अवलोकनों पर वास्तुकला का निर्माण करने का जोखिम होता है। यह कोड को अपडेट के प्रति अधिक संवेदनशील बना सकता है।

दस्तावेज़ीकरण एक सीमा नहीं है, बल्कि एक विश्वसनीय समर्थन है

फ़्रेमवर्क डेवलपर हमारी सहायता के लिए मैनुअल बनाते हैं। दस्तावेज़ीकरण के अंतर्गत कार्य करते हुए, हमें मिलता है:

* स्थिरता;
* सहायता;
* पूर्वानुमेय सिस्टम व्यवहार।

इन सीमाओं से परे जाकर, हम अतिरिक्त जोखिम उठाते हैं, और ऐसे कोड को बनाए रखना अधिक कठिन हो जाता है।

प्रयोग? निश्चित रूप से। लेकिन सीमाओं की समझ के साथ.
किसी डेवलपर में जिज्ञासा होना एक महान गुण है। नई चीज़ों की खोज करना और उन्हें आज़माना नितांत आवश्यक है। लेकिन यहाँ एक छोटी सी इच्छा है:

प्रयोग करने का सबसे आरामदायक तरीका सर्वोत्तम प्रथाओं पर भरोसा करना है।

दस्तावेज़ीकरण एक मानचित्र है जो दिखाता है कि कौन से पथ सबसे सुरक्षित हैं और रचनाकारों द्वारा समर्थित हैं।

एक बाहरी परिप्रेक्ष्य: विशेषज्ञ की सलाह

हम अक्सर अनुभवी सहकर्मियों से सीखते हैं:

*वे उपयोगी पाठ्यक्रम संचालित करते हैं,
*सम्मेलनों में बोलें,
*अद्भुत किताबें और ब्लॉग लिखें,
* उनके अनूठे दृष्टिकोण को साझा करें।

उनमें से कई सचमुच मूल्यवान अनुभव साझा करते हैं। लेकिन यह याद रखने योग्य है: यदि लेखक के दृष्टिकोण आधिकारिक दस्तावेज़ीकरण के विपरीत हैं, तो वे नाजुक हो सकते हैं।

ऐसे “अनुभवजन्य पैटर्न” कभी-कभी:

* केवल ढांचे के एक विशिष्ट संस्करण पर काम करें;
* अद्यतनों के प्रति संवेदनशील;
* असामान्य परिस्थितियों में अप्रत्याशित व्यवहार कर सकता है।

समुदाय से सीखना महान और लाभदायक है। लेकिन किसी भी सलाह, यहां तक ​​कि सबसे आधिकारिक सलाह को भी हमेशा आधिकारिक मैनुअल के साथ सावधानीपूर्वक जांचा जाना चाहिए।

SOLID के बारे में थोड़ा

SOLID सिद्धांतों के तीन विचार इस दृष्टिकोण को पूरी तरह से पूरक करते हैं:

* खुला/बंद सिद्धांत: सार्वजनिक एपीआई के माध्यम से व्यवहार को बढ़ाने का प्रयास करें और, यदि संभव हो तो, छिपे हुए कार्यान्वयन पर निर्भर न रहें।
* लिस्कोव प्रतिस्थापन सिद्धांत: अनुबंध पर भरोसा करें, विशिष्ट कार्यान्वयन पर नहीं। अन्यथा, हुड के नीचे परिवर्तन अप्रत्याशित कठिनाइयों का कारण बन सकता है।
* निर्भरता व्युत्क्रमण: विवरणों पर नहीं, अमूर्तताओं पर निर्भरताएँ बनाएँ।

व्यवहार में, इसका मतलब यह है कि ढांचे के आंतरिक, गैर-दस्तावेज विवरण से बंधा होना सिस्टम को भंगुर बना देता है।
सार्वजनिक इंटरफ़ेस और अनुबंधों के आधार पर, हमें मिलता है:

* फ्रेमवर्क में बदलाव से कोड का बेहतर अलगाव;
* परीक्षण में आसानी;
* वास्तुकला की पूर्वानुमेयता और विश्वसनीयता।

अगर कोई बग है तो क्या होगा?

ऐसा भी होता है कि सब कुछ नियमों के अनुसार किया जाता है, लेकिन परिणाम उम्मीदों के अनुरूप नहीं होता है। ढाँचे विकसित होते रहते हैं और हमेशा सही नहीं होते। इस तरह के मामलों में:

* एक न्यूनतम उदाहरण बनाएं जो समस्या को पुन: उत्पन्न करता हो।
* सुनिश्चित करें कि केवल प्रलेखित एपीआई का उपयोग किया जाए।
* बग रिपोर्ट भेजें – विकास टीम निश्चित रूप से आपके काम की सराहना करेगी और मदद करने का प्रयास करेगी।

यदि उदाहरण वर्कअराउंड पर निर्भर करता है, तो डेवलपर्स के लिए सहायता प्रदान करना अधिक कठिन होगा।

फ़्रेमवर्क से अधिकतम लाभ कैसे प्राप्त करें

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

निष्कर्ष

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

मैनुअल और दस्तावेज़ीकरण उत्कृष्ट समर्थन हैं जो वास्तव में विश्वसनीय समाधान बनाने में मदद करते हैं।

स्रोत

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM

इस नोट में, मैं Linux पर iOS के लिए C++ SDL एप्लिकेशन बनाने, सशुल्क Apple डेवलपर सदस्यता के बिना IPA संग्रह पर हस्ताक्षर करने और जेलब्रेक के बिना macOS का उपयोग करके इसे एक साफ़ डिवाइस (iPad) पर इंस्टॉल करने की प्रक्रिया का वर्णन करूंगा।

सबसे पहले, आइए Linux के लिए बिल्ड टूलचेन इंस्टॉल करें:
https://github.com/tpoechtrager/cctools-port

टूलचेन को रिपॉजिटरी से डाउनलोड करना होगा, फिर इंस्टॉलेशन पूरा करने के लिए गोडोट इंजन वेबसाइट पर दिए गए निर्देशों का पालन करें:
https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

फिलहाल, आपको cctools-port बनाने के लिए Xcode dmg डाउनलोड करना होगा और वहां से sdk को कॉपी करना होगा। इस चरण को macOS पर पूरा करना आसान है; बस स्थापित Xcode से आवश्यक sdk फ़ाइलों की प्रतिलिपि बनाएँ। सफल असेंबली के बाद, टर्मिनल में क्रॉस-कंपाइलर टूलचेन का पथ शामिल होगा।
इसके बाद, आप iOS के लिए SDL एप्लिकेशन बनाना शुरू कर सकते हैं। चलिए cmake खोलें और C++ कोड बनाने के लिए आवश्यक परिवर्तन जोड़ें:

SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
SET(CMAKE_LINKER arm-apple-darwin11-ld)

अब आप सेमेक का उपयोग करके संकलन कर सकते हैं और बना सकते हैं, लेकिन क्रॉस-कंपाइलर टूलचेन में $PATH जोड़ना न भूलें:

PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin

फ्रेमवर्क और एसडीएल के साथ सही लिंकिंग के लिए, हम उन्हें सीएमके में लिखते हैं, उदाहरण के लिए गेम स्पेस जगुआर की निर्भरताएँ:

target_link_libraries(
${FSEGT_PROJECT_NAME}
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
)

मेरे मामले में, SDL, SDL_Image, SDL_mixer लाइब्रेरीज़ को स्टैटिक लिंकिंग के लिए पहले से ही macOS पर Xcode में संकलित किया गया है; फ्रेमवर्क Xcode से कॉपी किया गया। libclang_rt.ios.a लाइब्रेरी भी जोड़ी गई है, जिसमें iOS-विशिष्ट रनटाइम कॉल शामिल हैं, उदाहरण के लिए isOSVersionAtLeast। ओपनजीएल ईएस के साथ काम करने के लिए एक मैक्रो शामिल है, जो एंड्रॉइड के समान मोबाइल संस्करण में असमर्थित कार्यों को अक्षम करता है।
सभी निर्माण समस्याओं को हल करने के बाद, आपको हाथ के लिए असेंबल की गई बाइनरी मिलनी चाहिए। इसके बाद, आइए जेलब्रेक के बिना डिवाइस पर असेंबल बाइनरी चलाने पर विचार करें।
MacOS पर, डेवलपर प्रोग्राम के लिए भुगतान किए बिना, Xcode इंस्टॉल करें, Apple पोर्टल पर पंजीकरण करें। Xcode में एक खाता जोड़ें -> प्राथमिकताएँ -> खाते, एक रिक्त एप्लिकेशन बनाएं और वास्तविक डिवाइस पर बनाएं। असेंबली के दौरान, डिवाइस आपके निःशुल्क डेवलपर खाते में जोड़ दिया जाएगा। असेंबली और लॉन्च के बाद, आपको संग्रह बनाने की आवश्यकता है; ऐसा करने के लिए, जेनेरिक iOS डिवाइस और उत्पाद चुनें -> पुरालेख। एक बार संग्रह बन जाने के बाद, उसमें से Embedded.mobileprovision और PkgInfo फ़ाइलें निकालें। बिल्ड लॉग से डिवाइस तक, सही हस्ताक्षर कुंजी के साथ कोडसाइन लाइन ढूंढें, एक्सटेंशन ऐप.xcent के साथ एंटाइटेलमेंट फ़ाइल का पथ, इसे कॉपी करें।
संग्रह से .app फ़ोल्डर की प्रतिलिपि बनाएँ, संग्रह में बाइनरी को Linux में क्रॉस-कंपाइलर द्वारा संकलित एक से बदलें (उदाहरण के लिए, SpaceJaguar.app/SpaceJaguar), फिर .app में आवश्यक संसाधन जोड़ें, संग्रह से .app में PkgInfo और एम्बेडेड.mobileprovision फ़ाइलों की अखंडता की जाँच करें, यदि आवश्यक हो तो फिर से कॉपी करें। हम कोडसाइन कमांड – का उपयोग करके .app पर पुनः हस्ताक्षर करते हैं। कोडसाइन को साइन के लिए एक इनपुट कुंजी की आवश्यकता होती है, एंटाइटेलमेंट फ़ाइल का पथ (.plist एक्सटेंशन के साथ इसका नाम बदला जा सकता है)
पुन: हस्ताक्षर करने के बाद, एक पेलोड फ़ोल्डर बनाएं, .app एक्सटेंशन वाले फ़ोल्डर को वहां ले जाएं, रूट में पेलोड के साथ एक ज़िप संग्रह बनाएं, .ipa एक्सटेंशन के साथ संग्रह का नाम बदलें। उसके बाद, Xcode में, उपकरणों की सूची खोलें और नए आईपीए को डिवाइस के अनुप्रयोगों की सूची में खींचें और छोड़ें; Apple कॉन्फिगरेटर 2 के माध्यम से इंस्टॉलेशन इस विधि के लिए काम नहीं करता है। यदि पुन: हस्ताक्षर सही ढंग से किया जाता है, तो नए बाइनरी वाला एप्लिकेशन 7-दिवसीय प्रमाणपत्र के साथ iOS डिवाइस (उदाहरण के लिए, iPad) पर इंस्टॉल किया जाएगा, यह परीक्षण अवधि के लिए पर्याप्त है।

स्रोत

https://github.com/tpoechtrager/cctools-port

https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

https://jonnyzzz.com/blog/2018/06/13/link-error-3/

https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

इस पोस्ट में मैं उबंटू पर MinGW32 टूलचेन का उपयोग करके विंडोज़ के लिए लाइब्रेरी और एप्लिकेशन बनाने की प्रक्रिया का वर्णन करूंगा।
वाइन स्थापित करें, मिंगव:

sudo apt-get install wine mingw-w64

इसके बाद, आप पहले से ही विंडोज़ के लिए C/C++ एप्लिकेशन बना सकते हैं:

# C
i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
 
# C++
i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit

एकत्रित एक्सई को वाइन का उपयोग करके जांचा जा सकता है।
इसके बाद, आइए CMake बिल्ड, CMakeLists.txt फ़ाइल में परिवर्तनों को देखें, बिल्ड फ़ाइल में MinGW विशिष्ट चीज़ें जोड़ते हुए:

if (MINGW32)
set(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
endif()

// для сборки shared dll
elseif (MINGW32)
add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
else()

// обязательно линкуем со всеми зависимостями
if (MINGW32)
target_link_libraries(
                        FlameSteelEngineGameToolkit.dll 
                        -static-libgcc
                        -static-libstdc++
                        SDL2 
                        SDL2_mixer 
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)

set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
        PREFIX ""
        SUFFIX ""
        LINK_FLAGS "-Wl,--add-stdcall-alias"
        POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
        # MinGW generates position-independent-code for DLL by default
)
else()

हम एकत्र करते हैं:

cmake -DMINGW32=1 .
make

आप जो एकत्र कर रहे हैं उसके आधार पर आउटपुट एक डीएलएल या एक्सई होगा। एक कामकाजी उदाहरण के लिए, आप नए क्यूब-आर्ट-प्रोजेक्ट और उसके पुस्तकालयों के भंडार को देख सकते हैं:
https://gitlab.com/demensdeum/cube-art-project

https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

https://gitlab.com/demensdeum/cube-art-project-bootstrap

स्रोत
https://arrayfire.com/cross-compile-to-windows-from-linux/

इस पोस्ट में, मैं CMake और osxcross का उपयोग करके Ubuntu बिल्ड मशीन पर macOS के लिए क्रॉस-प्लेटफ़ॉर्म C++ एप्लिकेशन बनाने का वर्णन करूंगा।
सबसे पहले, osxcross टूलचेन स्थापित करें:
https://github.com/tpoechtrager/osxcross
स्थापना 3 चरणों में होती है, डाउनलोडिंग निर्भरताएँ:

cd tools
./get_dependencies.sh

आधिकारिक Apple वेबसाइट से XCode.xip डाउनलोड करें, फिर XCode से SDK डाउनलोड करें:

./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip

मुझे आशा है कि आपने अंतिम चरण में XCode लाइसेंस अनुबंध पढ़ा होगा? इसके बाद, आवश्यक उपसर्ग के साथ टूलचेन बनाएं:

INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh 

अब आप पिछले चरण की उपसर्ग निर्देशिका से osxcross का उपयोग कर सकते हैं। आइए CMake के लिए एक नया बिल्ड मैक्रो जोड़ें और सभी आवश्यक चीज़ें लिखें:

if (OSXCROSS)
SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER o64-clang)
SET(CMAKE_CXX_COMPILER o64-clang++)
SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
SET(ENV{OSXCROSS_MP_INC} 1)
endif()

डायनामिक लिंकिंग मेरे लिए सफल नहीं रही, इसलिए हम पुस्तकालयों को स्थिर रूप से निर्यात करते हैं:

if (OSXCROSS)
add_library(FlameSteelCore STATIC ${SOURCE_FILES})
else()

इसके बाद, आपको इस तथ्य का सामना करना पड़ सकता है कि आपके पास osxcross के लिए आवश्यक लाइब्रेरी नहीं है, SDL2 का उपयोग करते समय मुझे इसका सामना करना पड़ा। osxcross तैयार लाइब्रेरी पैकेजों का समर्थन करता है – मैकपोर्ट्स। उदाहरण के लिए, SDL2-मिक्सर स्थापित करना:

osxcross-macports -v install libsdl2_mixer

इसके बाद, आप हमेशा की तरह सेमेक-मेक लिंक में लाइब्रेरी/एप्लिकेशन बनाना शुरू कर सकते हैं, यदि आवश्यक हो तो लाइब्रेरी की स्टैटिक लिंकिंग निर्दिष्ट करना न भूलें।

पुस्तकालयों की मैन्युअल असेंबली

वर्तमान में, मुझे स्थैतिक लिंकिंग के दौरान पुस्तकालयों के गलत संग्रह की समस्या का सामना करना पड़ा है; अंतिम एप्लिकेशन बनाते समय मुझे त्रुटि प्राप्त होती है:

file was built for archive which is not the architecture being linked (x86_64)

इस टिकट के समान, हम एक वर्कअराउंड लागू करने में कामयाब रहे जिसके परिणामस्वरूप बिल्ड सही ढंग से पूरा हुआ। आइए स्टैटिक लाइब्रेरी को अनज़िप करें और ओएसएक्सक्रॉस आर्काइवर का उपयोग करके इसे नए सिरे से बनाएं:

ar x ../libFlameSteelCore.a
rm ../libFlameSteelCore.a
x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o

इसके अलावा, जिन समस्याओं पर मैं व्यक्तिगत रूप से विचार करता हूं उनमें से एक सीधे उबंटू पर मैकओएस अनुप्रयोगों को चलाने की क्षमता की कमी है (कम से कम कार्यक्षमता के हिस्से के साथ)। बेशक, एक परियोजना है darling, लेकिन समर्थन अभी भी वांछित होने के लिए बहुत कुछ बाकी है।

स्रोत

https://github.com/tpoechtrager/osxcross

आजकल, आपको क्लाउड सेवाओं पर निर्भर रहने की ज़रूरत नहीं है: आप पूरी तरह से अपने हार्डवेयर पर उच्च-गुणवत्ता वाली छवियां उत्पन्न कर सकते हैं। इस पोस्ट में, मैं वर्णन करूंगा कि ComfyUI का उपयोग करके आपके कंप्यूटर पर आधुनिक FLUX मॉडल को स्थानीय रूप से कैसे चलाया जाए।

ComfyUI नोड-आधारित आर्किटेक्चर का उपयोग करता है। यह आपको इसकी अनुमति देता है:
– पीढ़ी के हर चरण पर पूरी तरह से नियंत्रण रखें।
– आसानी से तैयार “वर्कफ़्लोज़” साझा करें

FLUX एक बड़ा मॉडल है, इसलिए हार्डवेयर आवश्यकताएँ SD 1.5 या SDXL से अधिक हैं:
– वीडियो कार्ड (जीपीयू): 12 जीबी वीआरएएम या उच्चतर (आरामदायक काम के लिए) के साथ एनवीडिया आरटीएक्स। यदि आपके पास 8 जीबी या उससे कम है, तो आपको परिमाणित संस्करण (जीजीयूएफ या एनएफ4) का उपयोग करना होगा।
– रैंडम एक्सेस मेमोरी (रैम): न्यूनतम 16 जीबी (अधिमानतः 32 जीबी और अधिक)।
– डिस्क स्थान: मॉडलों और घटकों के लिए लगभग 20-50 जीबी।

FLUX शुरू करने का सबसे आसान तरीका तैयार टेम्पलेट का उपयोग करना है। बस वर्कफ़्लो विंडो में फ़्लक्स टेक्स्ट टू इमेज खोजें और इंस्टॉल करें।

`टेक्स्ट टू इमेज (फ्लक्स.1 डेव)` नोड में अंग्रेजी में एक संकेत लिखें, रिज़ॉल्यूशन का चयन करें (फ्लक्स 1024×1024 और इससे भी अधिक के साथ अच्छा काम करता है) और RUN दबाएँ।

पहली पीढ़ी में समय लग सकता है क्योंकि मॉडलों को वीडियो कार्ड मेमोरी में लोड किया जाएगा।

https://github.com/comfyanonymous/ComfyUI

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

स्थानीय वाइब कोडिंग के लिए उपकरण

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

हार्डवेयर आवश्यकताएँ

स्थानीय भाषा मॉडल स्मृति गहन हैं:
– वीडियो कार्ड (जीपीयू): 8 जीबी वीआरएएम या उच्चतर के साथ एनवीडिया (7-8 बिलियन पैरामीटर वाले मॉडल के साथ आरामदायक काम के लिए)। भारी मॉडलों के लिए 16 जीबी वीआरएएम की आवश्यकता होगी।
– डिस्क स्थान: विभिन्न डाउनलोड किए गए मॉडलों को संग्रहीत करने के लिए लगभग 500 जीबी।

लिंक को कॉन्फ़िगर करना

सेटअप प्रक्रिया काफी सरल है और टर्मिनल में जटिल हेरफेर की आवश्यकता नहीं है:
1. एलएम स्टूडियो डाउनलोड और इंस्टॉल करें। क्वेन कोडर या gemma3:12b जैसे हल्के मॉडल को खोजने के लिए अंतर्निहित खोज का उपयोग करें।
2. एलएम स्टूडियो में, स्थानीय सर्वर टैब पर जाएं और स्टार्ट सर्वर पर क्लिक करें। डिफ़ॉल्ट रूप से यह `http://localhost:1234/v1` पर प्रारंभ होगा।
3. वीएस कोड खोलें और प्लगइन स्टोर से जारी रखें एक्सटेंशन इंस्टॉल करें।
4. जारी रखें कॉन्फ़िगरेशन फ़ाइल खोलें और `ओपनाई` प्रदाता और एलएम स्टूडियो से अपने स्थानीय सर्वर का पता निर्दिष्ट करते हुए एक नया मॉडल जोड़ें।

फिर आप जारी रखें साइडबार में सीधे अपने स्थानीय एलएलएम के साथ संवाद कर सकते हैं, अपने कोड के बारे में प्रश्न पूछ सकते हैं और नए घटक तैयार कर सकते हैं।

यह क्यों काम करता है?

जैसा कि मैंने पहले लिखा था, एलएलएम फ्लैट संरचना और WET (हर चीज़ दो बार लिखें) कोड के साथ बेहतर करते हैं। जब जटिल आर्किटेक्चर को डिजाइन करने की बात आती है तो स्थानीय पैरामीटर मॉडल GPT-4 जैसे दिग्गजों से कमतर हो सकते हैं, लेकिन वे बॉयलरप्लेट कोड उत्पन्न करने, सरल कार्यों को फिर से तैयार करने और तेजी से प्रोटोटाइप करने में सक्षम हैं।

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

आउटपुट

स्थानीय तंत्रिका नेटवर्क एक प्रोग्रामर को पूरी तरह से बदलने या एक जटिल प्रणाली को डिजाइन करने में सक्षम नहीं हैं। हालाँकि, एलएम स्टूडियो + वीएस कोड + कंटिन्यू का संयोजन क्लाउड सेवाओं से स्वतंत्रता प्रदान करता है और गोपनीयता बनाए रखता है। यदि आप छोटे मॉडलों की सीमाओं को स्वीकार करने और परियोजना वास्तुकला को स्वतंत्र रूप से नियंत्रित करने के इच्छुक हैं तो यह नियमित कार्यों के लिए पूरी तरह से काम करने वाला सहायक उपकरण है।

लिंक

https://code.visualstudio.com/
https://lmstudio.ai/
https://continue.dev/

स्रोत

https://youtu.be/IqqCwhG46jY
https://www.youtube.com/watch?v=7AImkA96mE8

पहले, तंत्रिका नेटवर्क का उपयोग करके वीडियो बनाना रनवे या लूमा जैसी क्लाउड सेवाओं का विशेषाधिकार था। आज, यदि आपके पास आधुनिक एनवीडिया ग्राफिक्स कार्ड है, तो आप सीधे अपने कंप्यूटर पर उच्च गुणवत्ता वाले वीडियो बना सकते हैं। इस पोस्ट में, मैं आपको बताऊंगा कि ComfyUI और प्रभावी LTX-2.3 मॉडल का उपयोग करके स्थानीय वीडियो पीढ़ी कैसे सेट की जाए।

वीडियो निर्माण के लिए उपकरण

काम के लिए हमें आवश्यकता होगी:
– ComfyUI: नोड-आधारित आर्किटेक्चर के साथ एक शक्तिशाली इंटरफ़ेस जो आपको पीढ़ी प्रक्रिया को लचीले ढंग से अनुकूलित करने की अनुमति देता है।
– LTX-2.3: लाइटरिक्स का एक आधुनिक मॉडल, जो अपेक्षाकृत मध्यम वीडियो मेमोरी आवश्यकताओं के साथ सहज और विस्तृत वीडियो बनाने के लिए अनुकूलित है।

हार्डवेयर आवश्यकताएँ

छवियों के साथ काम करने की तुलना में वीडियो बनाना कहीं अधिक संसाधन-गहन प्रक्रिया है:
– वीडियो कार्ड (जीपीयू): 8 जीबी वीआरएएम के साथ एनवीडिया आरटीएक्स 768×512 के रिज़ॉल्यूशन के लिए आवश्यक न्यूनतम है। आरामदायक संचालन और उच्च रिज़ॉल्यूशन के लिए, 16-24 जीबी वीआरएएम होना अत्यधिक वांछनीय है।
– रैंडम एक्सेस मेमोरी (रैम): न्यूनतम 32 जीबी। डाउनलोड करते समय वीडियो मॉडल और VAE बहुत अधिक जगह लेते हैं।
– डिस्क स्थान: मॉडल और संबंधित घटकों के लिए लगभग 500 जीबी।

सेटअप और लॉन्च

ComfyUI में LTX-2.3 लॉन्च करने की प्रक्रिया इस प्रकार है:
1. ComfyUI अपडेट करें: मॉडल अपेक्षाकृत नया है, इसलिए सुनिश्चित करें कि आपके पास इंटरफ़ेस का नवीनतम संस्करण स्थापित है।
2. वर्कफ़्लो स्थापित करें: सबसे आसान तरीका LTX वीडियो के लिए तैयार JSON टेम्पलेट ढूंढना है। वीडियो अव्यक्त स्थान के साथ काम करने के लिए मॉडल को विशिष्ट नोड्स की आवश्यकता होती है।
3. संकेत और पैरामीटर: अंग्रेजी में दृश्य का विवरण दर्ज करें। ध्यान दें कि LTX-2.3 गति को अच्छी तरह से समझता है (उदाहरण के लिए “कैमरा चारों ओर घूमता है”, “तेज गति”)।

LTX-2.3 क्यों चुनें?

LTX-2.3 उल्लेखनीय है क्योंकि यह मालिकाना क्लाउड सेवाओं के बराबर परिणाम देता है, लेकिन स्थानीय रूप से चलता है। यह आपको देता है:
– पूर्ण गोपनीयता: आपके संकेत और जेनरेट किए गए वीडियो अन्य लोगों के सर्वर पर नहीं जाते हैं।
– नियंत्रण: आप प्रत्येक प्रयास के लिए भुगतान किए बिना फ्रेम दर (एफपीएस), रिज़ॉल्यूशन और शीघ्र शक्ति के साथ प्रयोग कर सकते हैं।

स्थानीय वीडियो पीढ़ी अभी भी सक्रिय विकास में है, और LTX-2.3 “होम हॉलीवुड” की दुनिया में एक शानदार प्रविष्टि है।

लिंक

https://github.com/comfyanonymous/ComfyUI
https://huggingface.co/Lightricks/LTX-Video

आजकल, आपको सामग्री बनाने के लिए क्लाउड सेवाओं पर निर्भर रहने की ज़रूरत नहीं है: आप पूरी तरह से अपने हार्डवेयर पर उच्च गुणवत्ता वाला संगीत उत्पन्न कर सकते हैं। इस पोस्ट में, मैं वर्णन करूंगा कि ComfyUI का उपयोग करके आपके कंप्यूटर पर आधुनिक ACE-Step-1.5 मॉडल को स्थानीय रूप से कैसे चलाया जाए।

ComfyUI नोड-आधारित आर्किटेक्चर का उपयोग करता है। यह आपको इसकी अनुमति देता है:
– ऑडियो जेनरेशन के हर चरण को पूरी तरह से नियंत्रित करें।
– आसानी से तैयार “वर्कफ़्लोज़” साझा करें।

एसीई-स्टेप-1.5 संगीत निर्माण के लिए एक उन्नत मॉडल है जिसके लिए महत्वपूर्ण कम्प्यूटेशनल संसाधनों की आवश्यकता होती है। हार्डवेयर आवश्यकताएँ कई सरल सिंथेसाइज़र की तुलना में अधिक हैं:
– वीडियो कार्ड (जीपीयू): उच्च गुणवत्ता पर आरामदायक काम के लिए 8 जीबी वीआरएएम या उच्चतर (12 जीबी+ अनुशंसित) के साथ एनवीडिया आरटीएक्स।
– रैंडम एक्सेस मेमोरी (रैम): न्यूनतम 16 जीबी (अधिमानतः 32 जीबी और अधिक)।
– प्रोसेसर (सीपीयू): AVX/CUDA कंप्यूटिंग के लिए अच्छे समर्थन के साथ आधुनिक मल्टी-कोर प्रोसेसर।
– डिस्क स्थान: मॉडलों और घटकों के लिए लगभग 20-50 जीबी।

ACE-Step-1.5 को चलाने का सबसे आसान तरीका तैयार ऑडियो जेनरेशन टेम्पलेट का उपयोग करना है। बस वर्कफ़्लो विंडो में संगीत टेक्स्ट से ऑडियो खोजें और इंस्टॉल करें।

`प्रॉम्प्ट इनपुट` नोड में शैली और मनोदशा का वर्णन करने वाला एक संकेत लिखें (उदाहरण के लिए, “भारी बास के साथ उत्थान सिंथवेव ट्रैक”)। वांछित अवधि निर्दिष्ट करें और RUN दबाएँ।
पहली पीढ़ी में समय लग सकता है, क्योंकि मॉडलों को वीडियो कार्ड मेमोरी में लोड किया जाएगा और जटिल ध्वनिक पैटर्न को संसाधित किया जाएगा।

https://github.com/comfyanonymous/ComfyUI
https://www.youtube.com/watch?v=UAlLD5fS7-c

यदि आपको चैटजीपीटी जैसा कुछ लॉन्च करने की इच्छा थी और आपके पास एक काफी शक्तिशाली कंप्यूटर है, उदाहरण के लिए एनवीडिया आरटीएक्स वीडियो कार्ड के साथ, तो आप ओलामा प्रोजेक्ट चला सकते हैं, जो आपको अपने स्थानीय मशीन पर तैयार एलएलएम मॉडल में से एक का बिल्कुल मुफ्त उपयोग करने की अनुमति देगा। ओलामा चैटजीपीटी के तरीके से एलएलएम मॉडल के साथ संवाद करने की क्षमता प्रदान करता है; नवीनतम संस्करण में, छवियों को पढ़ने और आउटपुट डेटा को json प्रारूप में प्रारूपित करने की क्षमता की भी घोषणा की गई है।

मैंने प्रोजेक्ट को Apple M2 प्रोसेसर के साथ मैकबुक पर भी चलाया, और मुझे पता है कि AMD के वीडियो कार्ड के नवीनतम मॉडल समर्थित हैं।

MacOS पर इंस्टॉल करने के लिए, ollama वेबसाइट पर जाएँ:
https://ollama.com/download/mac

“MacOS के लिए डाउनलोड करें” पर क्लिक करें, आप ollama-darwin.zip फॉर्म का एक संग्रह डाउनलोड करेंगे, संग्रह के अंदर Ollama.app होगा जिसे “एप्लिकेशन” में कॉपी करने की आवश्यकता है। इसके बाद, Ollama.app लॉन्च करें, सबसे अधिक संभावना है कि इंस्टॉलेशन प्रक्रिया पहले लॉन्च पर होगी। उसके बाद, ट्रे में आपने ओलामा आइकन देखा, ट्रे घड़ी के ठीक बगल में शीर्ष पर है।

उसके बाद, एक नियमित macOS टर्मिनल लॉन्च करें, और किसी भी ओलामा मॉडल को डाउनलोड, इंस्टॉल और चलाने के लिए कमांड टाइप करें। उपलब्ध मॉडलों, विवरणों और उनकी विशेषताओं की सूची ओलामा वेबसाइट पर देखी जा सकती है:
https://ollama.com/search

यदि लॉन्च के समय यह आपके वीडियो कार्ड में फिट नहीं बैठता है तो सबसे कम पैरामीटर वाला मॉडल चुनें।

उदाहरण के लिए, llama3.1:नवीनतम मॉडल लॉन्च करने का आदेश:

ollama run llama3.1:latest

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

सूत्रों का कहना है
https://www.youtube.com/watch?v=Wjrdr0NU4Sk
https://ollama.com

यदि आप वीडियो को स्थिर करना चाहते हैं और कैमरा शेक को दूर करना चाहते हैं, तो `ffmpeg` टूल एक शक्तिशाली समाधान प्रदान करता है। अंतर्निहित फ़िल्टर `vidstabdetect` और `vidstabtransform` के लिए धन्यवाद, आप जटिल वीडियो संपादकों का उपयोग किए बिना पेशेवर परिणाम प्राप्त कर सकते हैं।

काम के लिए तैयारी

शुरू करने से पहले, सुनिश्चित करें कि आपका `ffmpeg` `vidstab` लाइब्रेरी का समर्थन करता है। लिनक्स पर आप इसे कमांड से जांच सकते हैं:

bash  
ffmpeg -filters | grep vidstab  

यदि लाइब्रेरी स्थापित नहीं है, तो आप इसे जोड़ सकते हैं:

sudo apt install ffmpeg libvidstab-dev  

ब्रू के माध्यम से macOS के लिए इंस्टालेशन:

brew install libvidstab
brew install ffmpeg

अब चलिए प्रक्रिया पर आगे बढ़ते हैं।

चरण 1: गति विश्लेषण

सबसे पहले आपको वीडियो की गति का विश्लेषण करना होगा और स्थिरीकरण मापदंडों के साथ एक फ़ाइल बनानी होगी।

ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -  

पैरामीटर:

अस्थिरता: वीडियो शेक स्तर (डिफ़ॉल्ट 5, अधिक जटिल मामलों के लिए 10 तक बढ़ाया जा सकता है)।
सटीकता: विश्लेषण सटीकता (डिफ़ॉल्ट 15)।
ट्रांसफ़ाइल: गति मापदंडों को सहेजने के लिए फ़ाइल का नाम।

चरण 2: स्थिरीकरण लागू करें

अब आप परिवर्तन फ़ाइल का उपयोग करके स्थिरीकरण लागू कर सकते हैं:

ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

पैरामीटर:

इनपुट: परिवर्तन मापदंडों के साथ फ़ाइल को इंगित करता है (पहले चरण में बनाया गया)।
ज़ूम: काले किनारों को हटाने के लिए ज़ूम कारक (उदाहरण के लिए 5 – कलाकृतियों को हटाए जाने तक ऑटो ज़ूम)।

मैं आपके ध्यान में 1936 से एलन ट्यूरिंग के लेख “ऑन कंप्यूटेबल नंबर्स विद एन एप्लीकेशन टू द प्रॉब्लम ऑफ रिजॉल्यूशन” के पहले पन्नों का अनुवाद प्रस्तुत करता हूं। पहले अध्याय में कंप्यूटर का विवरण है, जो बाद में आधुनिक कंप्यूटिंग का आधार बन गया।

लेख और स्पष्टीकरण का पूरा अनुवाद अमेरिकी लोकप्रिय चार्ल्स पेटज़ोल्ड की पुस्तक में पढ़ा जा सकता है, जिसका शीर्षक है “रीडिंग ट्यूरिंग: ए जर्नी थ्रू ट्यूरिंग हिस्टोरिकल आर्टिकल ऑन कम्प्यूटेबिलिटी एंड ट्यूरिंग मशीन्स” (आईएसबीएन 978-5-97060-231-7, 978-0-470-22905-7)

मूल लेख:
https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

समाधान समस्या के अनुप्रयोग के साथ गणनीय संख्याओं पर

ए. एम. ट्यूरिंग

[28 मई 1936 को प्राप्त – 12 नवंबर 1936 को पढ़ें]

“गणना योग्य” संख्याओं को संक्षेप में वास्तविक संख्याओं के रूप में वर्णित किया जा सकता है जिनकी दशमलव भिन्नों के रूप में अभिव्यक्तियाँ सीमित संख्या में गणना योग्य होती हैं। हालाँकि पहली नज़र में यह लेख संख्याओं को गणना योग्य मानता है, एक पूर्णांक चर, एक वास्तविक चर, एक गणना योग्य चर, गणना योग्य विधेय और इसी तरह के गणना योग्य कार्यों को परिभाषित करना और उनका पता लगाना लगभग उतना ही आसान है। हालाँकि, इन गणना योग्य वस्तुओं से जुड़ी मूलभूत समस्याएं प्रत्येक मामले में समान हैं। विस्तृत विचार के लिए, मैंने गणना योग्य संख्याओं को एक गणना योग्य वस्तु के रूप में चुना क्योंकि उन पर विचार करने की विधि सबसे कम बोझिल है। मुझे आशा है कि मैं जल्द ही गणना योग्य संख्याओं और गणना योग्य कार्यों आदि के संबंध का वर्णन कर सकूंगा। साथ ही, गणना योग्य संख्याओं के रूप में व्यक्त वास्तविक चर के कार्यों के सिद्धांत के क्षेत्र में अनुसंधान किया जाएगा। मेरी परिभाषा के अनुसार, एक वास्तविक संख्या गणना योग्य होती है यदि उसका दशमलव प्रतिनिधित्व किसी मशीन द्वारा लिखा जा सकता है।

पैराग्राफ 9 और 10 में मैं यह दिखाने के लिए कुछ तर्क देता हूं कि गणना योग्य संख्याओं में वे सभी संख्याएं शामिल होती हैं जिन्हें स्वाभाविक रूप से गणना योग्य माना जाता है। विशेष रूप से, मैं दिखाता हूँ कि संख्याओं के कुछ बड़े वर्ग गणना योग्य हैं। इनमें शामिल हैं, उदाहरण के लिए, सभी बीजगणितीय संख्याओं के वास्तविक भाग, बेसेल फ़ंक्शंस के शून्य के वास्तविक भाग, संख्याएँ π, ई और अन्य। हालाँकि, गणना योग्य संख्याओं में सभी निश्चित संख्याएँ शामिल नहीं होती हैं, जैसा कि एक निश्चित संख्या के निम्नलिखित उदाहरण से प्रमाणित होता है जो गणना योग्य नहीं है।

यद्यपि गणना योग्य संख्याओं का वर्ग बहुत बड़ा है और कई मामलों में वास्तविक संख्याओं के वर्ग के समान है, फिर भी यह गणना योग्य है। §8 में मैं कुछ ऐसे तर्कों पर विचार करता हूं जो इसके विपरीत तर्क देते प्रतीत होंगे। जब इनमें से किसी एक तर्क को सही ढंग से लागू किया जाता है, तो ऐसे निष्कर्ष निकाले जाते हैं जो पहली नज़र में गोडेल* के समान होते हैं। इन परिणामों का अत्यंत महत्वपूर्ण अनुप्रयोग है। विशेष रूप से, जैसा कि नीचे दिखाया गया है (§11), समाधान समस्या का कोई समाधान नहीं हो सकता।

हाल के एक लेख में, अलोंजो चर्च ने “प्रभावी गणनाशीलता” का विचार पेश किया, जो “कम्प्यूटेबिलिटी” के मेरे विचार के बराबर है लेकिन इसकी एक पूरी तरह से अलग परिभाषा है। समाधान की समस्या के संबंध में चर्च भी इसी तरह के निष्कर्ष पर पहुंचता है। “कम्प्यूटेबिलिटी” और “प्रभावी रूप से गणना योग्य” की समानता का प्रमाण इस लेख के परिशिष्ट में प्रस्तुत किया गया है।

1. कंप्यूटर

हम पहले ही कह चुके हैं कि गणनीय संख्याएँ वे संख्याएँ हैं जिनके दशमलव स्थान परिमित साधनों द्वारा गिनने योग्य होते हैं। यहां एक स्पष्ट परिभाषा की आवश्यकता है। जब तक हम §9 तक नहीं पहुंच जाते, यह लेख यहां दी गई परिभाषाओं को सही ठहराने का कोई वास्तविक प्रयास नहीं करेगा। अभी के लिए, मैं सिर्फ यह नोट करूंगा कि (इसके लिए) तार्किक तर्क यह है कि मानव स्मृति, आवश्यकता से, सीमित है।

आइए वास्तविक संख्या की गणना करने की प्रक्रिया में एक व्यक्ति की तुलना एक ऐसी मशीन से करें जो केवल सीमित संख्या में शर्तों q1, q2, …, qR को पूरा करने में सक्षम है; आइए इन स्थितियों को “एम-कॉन्फिगरेशन” कहें। यह (अर्थात, इस प्रकार परिभाषित) मशीन एक “टेप” (कागज के अनुरूप) से सुसज्जित है। मशीन से गुजरने वाली यह बेल्ट खंडों में विभाजित है। आइए उन्हें “वर्ग” कहें। ऐसे प्रत्येक वर्ग में किसी न किसी प्रकार का “प्रतीक” हो सकता है। किसी भी क्षण, केवल एक ही ऐसा वर्ग होता है, मान लीजिए कि वां, जिसमें वह प्रतीक होता है जो “इस मशीन में है।” आइए ऐसे वर्ग को “स्कैन किया हुआ प्रतीक” कहें। एक “स्कैन किया हुआ पात्र” ही एकमात्र ऐसा पात्र है जिसके बारे में मशीन को, ऐसा कहा जा सकता है, “सीधे तौर पर पता” होता है। हालाँकि, अपने एम-कॉन्फिगरेशन को बदलकर, मशीन उन कुछ पात्रों को प्रभावी ढंग से याद रख सकती है जिन्हें उसने पहले “देखा” (स्कैन किया है)। किसी भी क्षण मशीन का संभावित व्यवहार एम-कॉन्फ़िगरेशन क्यूएन और स्कैन किए गए प्रतीक*** द्वारा निर्धारित किया जाता है। आइए प्रतीकों की इस जोड़ी को qn, “कॉन्फ़िगरेशन” कहते हैं। इस प्रकार निर्दिष्ट कॉन्फ़िगरेशन किसी दी गई मशीन के संभावित व्यवहार को निर्धारित करता है। इनमें से कुछ कॉन्फ़िगरेशन में, जिनमें स्कैन किया गया वर्ग खाली है (यानी, कोई वर्ण नहीं है), मशीन स्कैन किए गए वर्ग पर एक नया वर्ण लिखती है, और इनमें से कुछ कॉन्फ़िगरेशन में यह स्कैन किए गए वर्ण को मिटा देती है। यह मशीन दूसरे वर्ग को स्कैन करने के लिए भी जाने में सक्षम है, लेकिन इस तरह यह केवल दाएं या बाएं बगल वाले वर्ग तक ही जा सकती है। इनमें से किसी भी ऑपरेशन के अलावा, मशीन का एम-कॉन्फ़िगरेशन बदला जा सकता है। इस मामले में, कुछ लिखित वर्ण अंकों का एक क्रम बनाएंगे, जो गणना की जा रही वास्तविक संख्या का दशमलव भाग है। उनमें से बाकी “स्मृति की सहायता” के लिए गलत चिह्नों से अधिक कुछ नहीं होंगे। इस स्थिति में, केवल उपर्युक्त गलत चिह्नों को ही मिटाया जा सकता है।

मेरा दावा है कि यहां जिन ऑपरेशनों पर विचार किया गया है उनमें वे सभी ऑपरेशन शामिल हैं जिनका उपयोग गणना में किया जाता है। मशीन सिद्धांत की समझ रखने वाले पाठक के लिए इस कथन का तर्क समझना आसान है। इसलिए, अगले भाग में मैं “मशीन”, “टेप”, “स्कैन” आदि शब्दों के अर्थ की समझ के आधार पर संबंधित सिद्धांत को विकसित करना जारी रखूंगा।

*गोडेल “प्रिंसिपिया गणित के औपचारिक रूप से अनिर्णीत वाक्यों पर (व्हाइटहेड और रसेल द्वारा 1910, 1912 और 1913 में प्रकाशित) और संबंधित सिस्टम, भाग I,” गणित का जर्नल। भौतिकी, जर्मन में मासिक बुलेटिन संख्या 38 (1931 के लिए, पृ. 173-198)।
** अलोंजो चर्च, “प्राथमिक संख्या सिद्धांत में एक अनिर्णीत समस्या,” गणित के अमेरिकी जे., नंबर 58 (1936), पीपी. 345-363।
*** अलोंजो चर्च, “रिज़ॉल्यूशन समस्या पर एक नोट,” सिम्बोलिक लॉजिक के जे., नंबर 1 (1936), पीपी. 40-41