बिना किसी खास वजह के JavaScript गेम इंजन को C में पोर्ट करना

 (phoboslab.org)
5 पॉइंट द्वारा GN⁺ 2024-08-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2010 के JavaScript इंजन Impact की संरचना को फिर से जीवित करने वाला high_impact 2D action games के लिए एक C इंजन है, जो Windows·Mac·Linux और Web के लिए WASM को सपोर्ट करता है
  • Impact एक ऐसा इंजन था जिसे iOS द्वारा Flash को बाहर करने के दौर में यह दिखाने के लिए बनाया गया था कि Canvas2D से भी web games संभव हैं, और $99 में बेचने पर इसके 3,000 से अधिक लाइसेंस बिके, जिसके बाद इसे मुफ्त open source के रूप में जारी किया गया
  • नया इंजन tilemap, entity, physics·collision, sprite animation, text, sound को एक साथ जोड़ने वाला एक छोटा framework है और SDL या Sokol backend का उपयोग करता है
  • implementation fixed-size entity storage, QOI/QOA assets, single hunk memory, OpenGL·software renderer, और JavaScript-आधारित Weltmeister level editor के जरिए सादगी बनाए रखता है
  • Biolab Disaster और Drop को मौजूदा JS source के काफी करीब रखते हुए पोर्ट करके चलाया जा सका, और platform·renderer विस्तारों के जरिए इसे कई systems तक बढ़ाया जा सकता है

high_impact का अवलोकन

  • high_impact 2D action games के लिए एक छोटा game engine है
  • यह C में लिखा गया है और Windows, Mac, Linux, Web के लिए WASM में compile होता है
  • यह 2010 के JavaScript game engine Impact से प्रेरित है, और इसका नाम उस समय की ओर इशारा करता है जब C को high-level language माना जाता था
  • इसे MIT license के तहत जारी किया गया है और source GitHub पर उपलब्ध है

Impact बनने की पृष्ठभूमि

  • अप्रैल 2010 में Steve Jobs ने iOS पर Flash को सपोर्ट न करने की सार्वजनिक चिट्ठी “Thoughts on Flash” जारी की
  • उस समय Flash browser plugin-आधारित web games और animation संस्कृति का केंद्र था, और Newgrounds तथा Kongregate जैसी sites Flash content पर बहुत निर्भर थीं
  • Android का Flash support समस्याग्रस्त था, और यह भी माना गया कि Adobe ने mobile में इसकी कमियों को सुधारने के लिए खास प्रयास नहीं किए
  • उस समय यह धारणा थी कि “Flash नहीं तो browser games भी नहीं”, लेकिन Canvas2D API <canvas> पर images और shapes draw कर सकता था
  • Canvas2D को Apple/Safari ने desktop widget rendering के लिए बनाया था, बाद में Google और Mozilla ने इसे सपोर्ट किया, जबकि Microsoft का Internet Explorer पीछे रह गया
  • इसी प्रवाह में Biolab Disaster बनाया गया, और उसके लिए game engine तथा level editor भी साथ में विकसित किए गए

Impact की बिक्री और उपयोग के उदाहरण

  • Impact को code cleanup और documentation के बाद $99 में बेचा गया, और इस paid model के खिलाफ प्रतिक्रिया भी हुई, लेकिन इसके 3,000 से अधिक licenses बिके
  • कई web games Impact से बनाए गए, और यह commercial cross-platform titles में भी इस्तेमाल हुआ
  • अपने जीवनचक्र के अंत में Impact को मुफ्त open source के रूप में जारी किया गया
  • high_impact Impact को फिर से शुरू से बनाने वाला प्रोजेक्ट है, लेकिन JavaScript की जगह C में लिखा गया है

C क्यों

  • C एक सरल लेकिन गहराई वाली language है, और इसे “सीखना आसान, mastery पाना कठिन” जैसे game के स्वभाव से मिलता-जुलता माना गया
  • कई projects के दौरान C में रुचि फिर से बढ़ी
    • JavaScript MPEG1 decoder को single-header pl_mpeg library में पोर्ट किया गया
    • Oculus Rift के लिए Quake में VR implementation जोड़ा गया
    • QOI image format और QOA audio format बनाए गए
    • wipEout को फिर से लिखा गया
  • मूल Impact का आकार Godot, Unreal, Unity जैसे engines से तुलना करने लायक नहीं था, लेकिन यह कई games के लिए एक मजबूत आधार की तरह काम करता था
  • Impact को C में दोबारा लिखना एक मजेदार अभ्यास के रूप में शुरू हुआ

इंजन की संरचना और assets

  • high_impact को यथासंभव सरल रूप में implement किया गया है, और दिशा यह है कि जितना संभव हो उतने कम code से काम हो
  • इसकी basic functionality मूल JavaScript engine जैसी ही है
    • tilemap loading
    • game objects यानी entities का creation·update·drawing
    • entities के बीच physics और collision handling
    • collision map के साथ collision handling
    • sprite sheet animation
    • text output
    • sound effects और music playback
  • यह library से अधिक एक framework के करीब है, और game logic framework के भीतर लिखी जाती है
  • नीचे platform backend है, और अभी यह SDL या Sokol के साथ compile होता है
  • game code एक या अधिक “scene” में रखा जाता है, जहाँ scene function pointers वाला एक struct होता है
    • engine_set_scene(&scene_game) call के बाद engine नया scene सेट करता है
    • scene_game.init() एक बार call होता है
    • scene_game.update() और scene_game.draw() हर frame में call होते हैं
  • tilemap और शुरुआती entities को .json files से load किया जा सकता है या dynamically बनाया जा सकता है
  • level format के रूप में JSON चुनने का कारण मूल Impact के साथ backward compatibility है
  • high_impact images के लिए QOI और sound व music के लिए QOA का उपयोग करता है
    • demo game का Makefile PNG को QOI में और WAV को QOA में अपने आप convert करता है
    • अलग image·sound decoding libraries शामिल करने की जरूरत नहीं पड़ती
  • आगे चलकर अन्य asset formats का support संभव है, लेकिन QOI/QOA की सादगी इस project की दिशा से अच्छी तरह मेल खाती है

entity system

  • सभी entities एक ही entity_t struct शेयर करती हैं, जिसमें वे properties होती हैं जिनकी high_impact को जरूरत होती है, जैसे position, velocity, size
  • सभी entities का byte size समान होने से storage और management सरल हो जाता है
  • entity को move करने के लिए velocity या acceleration सेट करनी होती है, बाकी काम engine संभालता है
  • macros के जरिए base entity struct में game-specific properties जोड़ी जा सकती हैं
    • Biolab Disaster entity type-विशिष्ट structs वाले union का उपयोग करता है
    • Drop में अतिरिक्त properties define करने की जरूरत नहीं है
  • हर entity type के पास function pointers देने वाला entity_vtab_t होना चाहिए
    • update हर frame में call होता है
    • touch तब call होता है जब वह शर्तों के अनुसार किसी दूसरी entity से overlap करे
    • ये सभी entries optional हैं
  • entity storage fixed-size है
    • default active entity count 1,024 है
    • इसे ENTITIES_MAX define से सेट किया जा सकता है
    • engine आसानी से अधिकतम 64k entities तक संभाल सकता है
  • अगर किसी entity reference को एक frame से अधिक समय तक रखना हो तो entity_ref_t का उपयोग किया जाता है
    • entity_ref_t एक struct है जिसमें uint16_t id और index होते हैं
    • इसे entity_by_ref() से फिर pointer में resolve किया जा सकता है
    • इससे उस स्थिति को अलग पहचाना जा सकता है जहाँ उसी storage address पर कोई दूसरी entity आ गई हो
    • uint16_t index के कारण active entities की अधिकतम संख्या 64k तक सीमित है
  • C में simple OOP, classes, single inheritance जैसी संरचनाएँ लागू करना कुछ असहज हो सकता है, लेकिन high_impact इसे जितना संभव हो उतना सुविधाजनक बनाने की कोशिश करता है
  • entity logic को type के अनुसार एक जगह रखने वाला यह “भोला” OOP approach अब तक बनाए गए games में समझने में आसान और उपयोगी साबित हुआ है

collision detection और response

  • सरल collision handling सिर्फ यह जाँचती है कि नई position तक जाया जा सकता है या नहीं, और नहीं होने पर object रुक जाता है, लेकिन तेज objects के साथ इससे अजीब behavior हो सकता है
  • 2D platformer में अगर player जमीन से 16px ऊपर है और अगली movement में जमीन के अंदर चला जाएगा, तो वह हवा में रुककर अगले frame में फिर नीचे आता हुआ दिख सकता है, जो smooth landing जैसा लगता है
  • high_impact entity box को tilemap के against trace करके exact collision point निकालता है
  • यह तरीका साधारण yes/no check से अधिक जटिल है, लेकिन नतीजे बेहतर देता है और slope tiles को भी संभाल सकता है
  • tile से टकराने के बाद बची हुई velocity के साथ दूसरी trace की जरूरत पड़ सकती है
    • उदाहरण के लिए, अगर object तिरछे जमीन से टकराए तो vel.y 0 हो जाएगा, लेकिन vel.x बचा रहेगा ताकि वह जमीन के साथ slide कर सके
  • entities के बीच collisions अलग से संभाले जाते हैं
    • particles tilemap से टकरा सकते हैं लेकिन दूसरी entities से नहीं
    • moving platforms दूसरी entities से टकरा सकते हैं लेकिन collision response से खुद move नहीं होने चाहिए
  • broad phase collision detection entities को pos.x के आधार पर sort करती है
    • पिछली frame से वे अक्सर पहले ही काफी हद तक sorted होती हैं, इसलिए insertion sort की लागत कम रहती है
    • sort के बाद बाएँ से दाएँ sweep करते हुए केवल pos.x से pos.x + size.x के बीच आने वाली entities की जाँच की जाती है
  • यह sweep and prune तरीका तेज है, जब तक कि एक जैसी x position पर बहुत सारी entities overlap न करें
  • stacked box tower जैसी स्थिति में, जहाँ बहुत सारी entities एक ही x position पर इकट्ठी हों, यह worst case बन सकता है
  • vertical shooting game जैसे मामलों में, जहाँ दूसरी axis अधिक उपयुक्त हो, sweep axis को #define ENTITY_SWEEP_AXIS y से बदला जा सकता है

rendering

  • high_impact में अभी OpenGL renderer और एक अधूरा software renderer शामिल है
  • सारी rendering एक बहुत पतले API से गुजरती है, और वास्तविक draw calls एक single function से होती हैं, इसलिए दूसरे backends को implement करना अपेक्षाकृत सरल है
  • अतिरिक्त rendering backends को support करने के लिए मुख्य functions हैं: initialization, cleanup, screen size सेट करना, frame prepare·end, और quad draw करना
  • texture handling के लिए mark, reset, create functions भी चाहिए
  • functionality सरल है, इसलिए सिर्फ quads draw किए जा सकते हैं और shader effects का उपयोग नहीं किया जा सकता, लेकिन इस engine के उद्देश्य के लिए यह पर्याप्त है
  • software renderer 140 lines के code का है और केवल axis-aligned quads को support करता है
  • OpenGL renderer एक frame की rendering को एक ही OpenGL draw call में डालने की कोशिश करता है
    • सभी quads को एक बड़े buffer में इकट्ठा करके glDrawElements() से एक बार में भेजा जाता है
    • texture rebinding से बचने के लिए सभी textures को एक single texture atlas में मिलाया जाता है
  • texture atlas पुराना तरीका है और इसके कुछ नुकसान भी हैं, लेकिन bindless texture हर जगह supported नहीं होने के कारण इसका उपयोग किया गया है
  • high_impact केवल एक single texture atlas को support करता है, लेकिन इसका size #define से सेट किया जा सकता है
    • mobile GPUs आमतौर पर 8k×8k textures support करते हैं
    • आधुनिक desktop GPUs शायद 32k×32k तक support करते हैं
    • Biolab Disaster और Drop 512×512 atlas का उपयोग करते हैं

sound

  • sound output को SDL2 या Sokol संभालते हैं, जबकि engine loading·decoding·multiple sound mixing का काम करता है
  • sound system sample रखने वाले sound_source_t और अभी play हो रही sound को दर्शाने वाले sound_t में बँटी है
  • यह system wipEout rewrite के दौरान बनाए गए system पर आधारित है, और QOA को जरूरत पड़ने पर decompress कर सकता है
  • सब कुछ statically allocated है
    • load किए जा सकने वाले sources की संख्या fixed है
    • एक साथ play हो सकने वाली sounds की संख्या fixed है
    • playback पूरा होने पर sound अपने आप discard होकर फिर reuse हो जाती है
  • sound में volume, left-right panning, और pitch बदली जा सकती है
  • pitch को negative सेट करने पर sound उल्टा play होता है
  • variable pitch के लिए जरूरी resampling low-quality nearest-neighbor interpolation का उपयोग करती है

memory management

  • high_impact का मानना है कि जब game में user-generated assets न हों, तब जरूरी memory की मात्रा का ठीक-ठीक अनुमान लगाया जा सकता है
  • engine “hunk” नाम का एक single byte array statically allocate करता है, और high_impact सिर्फ इसी memory का उपयोग करता है
  • hunk का size #define ALLOC_SIZE से सेट किया जा सकता है
  • hunk में memory दो तरीकों से allocate की जाती है
    • सामने से ऊपर की ओर बढ़ने वाला bump allocator, या arena, game assets·entities·current scene data रखता है
    • अंत से नीचे की ओर बढ़ने वाला temporary allocator malloc() और free() की तरह काम करता है, और image decompress करके GPU को भेजने से पहले जैसे temporary storage के लिए उपयोग होता है
  • bump allocator के पास कई “high water mark” होते हैं और यह खास बिंदुओं पर अपने आप reset हो जाता है
  • bump-allocated memory को explicitly free() करने की जरूरत नहीं होती
  • इसकी conceptual lifetimes game, scene, frame में बँटी हैं
    • पहले scene के set होने से पहले allocate की गई चीजें program के खत्म होने पर ही मुक्त होती हैं
    • scene.load() के दौरान allocate की गई चीजें scene खत्म होने पर मुक्त होती हैं
    • scene के चलने के दौरान allocate की गई चीजें frame के अंत में मुक्त होती हैं
  • entity type-specific load() को पहले चरण में call किया जाता है, क्योंकि पहले से यह पता नहीं होता कि scene में कौन-सी entities इस्तेमाल होंगी
  • अतिरिक्त allocation context को alloc_pool() से wrap किया जा सकता है, जो अंदरूनी रूप से bump_mark() और bump_reset(mark) का shorthand है

Weltmeister level editor

  • मूल Impact में Weltmeister नाम का level editor था, और यह high_impact में भी शामिल है
  • यह अब भी JavaScript में लिखा गया है और मूल source का काफी उपयोग करता है, लेकिन इसे modern browser features के अनुसार अपडेट किया गया है
  • Weltmeister पूरी तरह स्वतंत्र रूप से काम करता है
    • weltmeister.html पर double-click करके level बनाना शुरू किया जा सकता है
    • पहले file load·save के लिए PHP या NodeJS backend API की जरूरत होती थी
    • अब FileSystemAPI के जरिए किसी खास folder तक access permission माँगी जा सकती है
  • Safari और Firefox अभी खास तौर पर showDirectoryPicker() को पूरी तरह support नहीं करते, इसलिए Chrome-आधारित browser की जरूरत होती है
  • Weltmeister C source files को पढ़कर entity types इकट्ठा करता है
  • high_impact ऐसे macros देता है जिन्हें editor समझता है, लेकिन C code में उनका कोई runtime behavior नहीं होता
    • EDITOR_SIZE(X, Y): editor में size, default (8, 8)
    • EDITOR_RESIZE(RESIZE): editor में resize किया जा सकता है या नहीं
    • EDITOR_COLOR(R, G, B): editor में box color, default (128, 255, 128)
    • EDITOR_IGNORE(IGNORE): editor में create किया जा सकता है या नहीं

demo games

  • यह जाँचने के लिए कि high_impact वास्तव में एक game engine की तरह काम करता है, मूल Impact के 2 games को C में port किया गया
  • यह porting मौजूदा JS source का लगभग “लिप्यंतरण” जैसा काम था, और मौजूदा assets दोबारा इस्तेमाल किए गए
  • इस प्रक्रिया का बहुत चुनौतीपूर्ण न होना इस बात का प्रमाण माना जा सकता है कि high_impact ने इरादे के मुताबिक काम किया

  • Biolab Disaster

  • Drop

विस्तारयोग्यता

  • high_impact पारंपरिक game engines की तरह game-specific code को additive रूप में लिखने वाली संरचना अपनाता है
  • engine source को बदलना जरूरी नहीं है, लेकिन इसे इतना सरल रखने की दिशा है कि जरूरत पड़ने पर engine source को सीधे बदला भी जा सके
  • platform और renderer को बाकी code बदले बिना बढ़ाया जा सके, इस तरह से डिजाइन किया गया है
  • रुचि हो तो Vulkan, DirectX, Metal renderers और PSX, N64, Dreamcast जैसे platform backends के लिए pull requests का स्वागत है
  • C में लिखा होने के कारण इसकी दिशा यह है कि यह जहाँ भी संभव हो वहाँ चल सके

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-05
Hacker News की रायें

  • मैंने जो programming काम किए हैं, उनमें जिनसे सबसे ज़्यादा सीखा, उनमें से कई Impact की वजह से थे
    Impact सचमुच अपने समय से बहुत आगे था, और 3000 license holders में से एक होना मेरे लिए गर्व की बात है। यह मेरी अब तक की सबसे अच्छी purchases में से एक था, और मैंने जो इकलौता game ठीक से पूरा करके खत्म किया, वह भी Impact से बनाया था
    मुझे अच्छा लगा कि license में source code शामिल था, और मैंने अपनी ज़रूरतों के हिसाब से engine और editor को खुद modify किया। उसी के असर में मैंने कई साल तक अपना JS game engine बनाया, लेकिन असली game पूरा करना टलता रहा; फिर भी इस process में बहुत कुछ सीखा और game jam के लिए कई games भी बनाए
    Impact के native iOS support, Ejecta, से भी प्रेरणा मिली, लेकिन उस समय Android पर न चलना खलता था, इसलिए webview के बिना Android पर अपना engine चलाने के लिए मैंने V8 के लिए JVM bindings बनाए और WebGL का कुछ हिस्सा implement किया। मैंने जो V8 bindings repository public की थी, वह अनपेक्षित रूप से commercial software में इस्तेमाल होने लगी: https://github.com/namuol/jv8
    Impact के business model से प्रेरित होकर private GitHub repository access बेचने वाला bootstrapped startup भी आज़माया था, लेकिन वह कहानी लंबी हो जाएगी। खैर, Impact को C porting के ज़रिए “modern” web के मुताबिक update होते देखना दिल को अच्छा और खुश करने वाला है। कहना चाहता हूं कि web एक अजीब दौर में है, लेकिन मुझे याद नहीं कि web कभी अजीब न रहा हो

    • चूंकि मूल Impact JavaScript और browser-based engine था, इसलिए लगता है कि Android पर भी इसे simple webview में ठीक चलना चाहिए था

  • CrossCode एक शानदार game है। मुझे पता था कि यह web technologies इस्तेमाल करता है, और Nintendo Switch hardware पर इसका इतना अच्छा performance देना लगातार हैरान करता रहा
    इस engine का भी उसमें कुछ योगदान रहा होगा

    • निष्पक्ष होकर कहें तो CrossCode team ने Impact को सचमुच बहुत ज़्यादा modify किया था। कुछ development streams में Impact के level editor, Weltmeister, का काफी expanded रूप देखा जा सकता है: https://youtu.be/4lZfnM9Ubeo?t=3215
      यही बात इसे और cool बनाती है। अच्छा है कि developer अपने game के हिसाब से engine बदल सकता है, और इसी तरह high_impact को भी “feature-complete” game engine के बजाय एक convenient starting point के रूप में देखना चाहिए
    • Switch porting में, जैसा किसी ने पहले ही कहा, काफी मेहनत लगी थी, और यह standard impact.js से बिल्कुल अलग है
      एक मज़ेदार किस्सा यह है कि हर कोई Switch version चाहता था, लेकिन technical limitations की वजह से team ने जवाब दिया था कि “जब Hedgehags उड़ना सीखेंगे, तब CrossCode Switch पर आएगा”: https://www.radicalfishgames.com/?p=6581
      आखिर जब porting सफल हुई, तो “A switch in attitude” नाम का extra quest जोड़ा गया, और उम्मीद के मुताबिक उड़ते हुए hedgehags दिखाई दिए: https://www.radicalfishgames.com/?p=6668
    • CrossCode को Switch पर port करने की process पर एक presentation है: https://www.youtube.com/watch?v=KfBzlzvt8RU
    • याद के हिसाब से Switch porting के लिए heroic level की मेहनत चाहिए थी

  • “Thoughts on Flash” ने शायद web platform को ठीक उस समय बचाया, जब उसे इसकी सबसे ज़्यादा ज़रूरत थी—यानी जब एक single software का dominance धीरे-धीरे बढ़ रहा था
    उसमें शायद Adobe को लेकर नाराज़गी भी थी, क्योंकि वह Windows के कहीं बड़े user base को प्राथमिकता देते हुए MacOS support को neglect करता दिखता था। उदाहरण के लिए, Mac version हमेशा Windows version से पीछे रहता था
    Jobs को शायद लगा हो कि जितना Apple ने Adobe को संभव बनाया, उतना ही Adobe ने भी Apple में योगदान दिया, लेकिन यह ज़्यादा अनुमान जैसा है। game खुद वाकई polished दिखता है

    • PSP पर भी Flash था और वह काफी ठीक था। सोचता हूं Sony ने उसमें कितनी मेहनत और पैसा लगाया होगा
    • यह लेख देखकर मैं फिर से C से छेड़छाड़ करने लगा। मूल रूप से मैं ECMAScript side का इंसान था और बहुत पहले थोड़ा Lingo किया था, लेकिन low-resource और hardware के करीब चीज़ें मुझे आकर्षित करती हैं
      हालांकि assembly language जितना करीब नहीं; मैं चीज़ों को घटाते हुए ऐसी दिशा में जा रहा हूं जो और गहराई में जाने को प्रेरित करती है

  • corporate job से निकलकर किसी दिन side project में पूरी तरह कूदना चाहने वाले व्यक्ति के तौर पर, मैं paid monetization से self-sustaining बने हिस्से के बारे में और सुनना चाहूंगा
    जो काम मूल रूप से मज़े के लिए करता था, उसके पैसे लेने का विचार अजीब तरह से बोझिल लगता है, लेकिन मुझे यह भी पता है कि वही मुझे पसंद का काम full-time करने दे सकता है

    • अगर यह किसी की समस्या हल करने वाला अच्छा काम है, तो उसके बदले compensation मिलना पूरी तरह उचित है, और शायद आप यह पहले से जानते होंगे
      इसलिए यह समझना अहम है कि यह विचार बोझिल क्यों लगता है। आम वजहों में आसपास के लोगों का अक्सर discourage करना, जो करना चाहते हैं उसे अच्छी तरह execute करने की skill की कमी, मदद मांगने में शर्म या यह लगना कि सामने वाले को परेशानी होगी, अपने काम का मूल्यांकन होने का डर, मौजूदा income से मिलने वाली “security” खोना—खासकर जब dependents हों—शामिल हैं
      ज़्यादातर मामलों में ये कारण बहुत अच्छे कारण कम, और कुछ हद तक recalibration की ज़रूरत ज़्यादा होते हैं; वही “risk” जैसा महसूस होता है, इसलिए comfort zone छोड़ना मुश्किल हो जाता है। ऐसे mindset में हर opportunity risk जैसी दिखती है, इसलिए जो आप सच में करना चाहते हैं उसे शुरू करने का सही समय ढूंढना बहुत मुश्किल हो जाता है
      इससे जुड़ी बात यह है कि जो काम मज़ेदार लगता है उसे बस करना और दुनिया को दिखाना महत्वपूर्ण है, लेकिन उसे livelihood बनाने में बदलना बिल्कुल अलग challenge है। ज़्यादातर लोग पसंद का काम अपना profession नहीं बना पाते, और अगर बना भी लें, तो paying customers की expectations और revenue बनाए रखने का pressure उस प्यार को खत्म कर सकता है। मतलब यह नहीं कि ऐसा न करें; बस कूदने से पहले यह जानना अच्छा है

  • मैं अपने लगभग इस्तेमाल न होने वाले HN account में login करने तक आ गया, क्योंकि कुछ साल पहले Biolab Disaster को बार-बार खेलता था, लेकिन नाम भूल गया था
    यूं अचानक इसे फिर से मिल जाना काफी अजीब और अच्छा लगा

  • आम तौर पर मैं इसे कहीं ज़्यादा नकारात्मक ढंग से कहता था। क्योंकि मेरे हिसाब से “framework” बस ऐसी library है जो दूसरी चीज़ों के साथ अच्छी तरह नहीं घुलती-मिलती
    फिर भी, इसे इतनी समझ में आने वाली सकारात्मक अभिव्यक्ति में सुनना अच्छा लगा

    • मैंने जो व्याख्या सुनी थी, वह कुछ ऐसी थी कि library को मैं call करता हूँ और framework मुझे call करता है
    • मैंने software engineering पढ़ी थी, लेकिन पहली नौकरी में WebObjects पर development करने से पहले library और framework का फर्क ठीक से समझ नहीं पाया था
      एक समृद्ध और अच्छे से designed framework इस्तेमाल करना सुखद था, जो ज़रूरत की 99% चीज़ें वाकई अच्छी तरह संभालता था। अपना code जोड़ना भी अब तक किए development में सबसे आसान में से था, और वह बस ठीक से चल जाता था। जादू जैसा था, और आज भी उसकी याद आती है
    • मुझे अब भी लगता है कि इसमें नकारात्मक पहलू है
      मेरे हिसाब से आदर्श framework अंदर से एक library या साथ मिलकर काम करने वाली libraries का bundle होना चाहिए, और framework वाला स्वभाव जितना हो सके उतना कम होना चाहिए
      उदाहरण के लिए Qt एक framework है और Qt “मुझे call” करता है, लेकिन Qt event loop शुरू किए बिना या QObject के बारे में गहराई से सोचे बिना भी QPainter code चलाया जा सकता है। आदर्श रूप से signals और slots को पूरी तरह अपनाए बिना भी event loop इस्तेमाल कर पाना चाहिए, भले ही usage experience उतना अच्छा न हो
      यह हमेशा संभव नहीं होता और हमेशा मूल्यवान भी नहीं होता, लेकिन बाकी शर्तें समान हों तो मैं framework बिल्कुल न होने को पसंद करूँगा
      game engine में थोड़े framework की ज़रूरत क्यों होती है, यह मैं समझता हूँ। फोन या console जैसे खास platforms के लिए compile करते समय engine को build process में, कभी-कभी libc से जुड़े हिस्सों तक में दखल देना पड़ता है, इसलिए केवल Win32 executable बनाकर उसे PlayStation game नहीं कहा जा सकता

  • QOI lossless file format में 7Zip जोड़ने पर performance lossless PNG से बेहतर होती है। कमाल का काम है

    • BMP के साथ 7Zip लगाने पर भी बेहतर होगा, और शायद फर्क और बड़ा हो सकता है। आखिरकार बात gzip और gzip replacement compressor के फर्क पर आ टिकती है

  • “for No Reason” शायद player की battery life का सम्मान करने के लिए भी रहा होगा

  • memory management वाला हिस्सा मुझे पसंद आया। arena allocation वाकई बेहद सरल है
    मेरा toy web server भी शुरू में arena से शुरू हुआ था, लेकिन जल्द ही समझ आया कि memory को बढ़ाने-घटाने की ज़रूरत ही नहीं है
    अब मैं शुरुआत में ही ज़रूरी memory एक साथ allocate कर देता हूँ, फिर उसे हर module के लिए इस्तेमाल होने वाले टुकड़ों में बाँटता हूँ। programming करते समय हम अक्सर मान लेते हैं कि कभी भी मनमानी मात्रा में memory चाहिए हो सकती है, लेकिन ऐसा ज़रूरी नहीं है
    कई चीज़ों की असल में स्पष्ट limits होती हैं, और बाकी के लिए भी आम तौर पर limits define की जा सकती हैं। उन्हें enumerate करने पर पता चल जाता है कि कितनी memory चाहिए। ऐसी limits के बारे में पहले से सोचना और define करना मज़ेदार है, आत्मविश्वास देता है और स्वस्थ बचत की आदत डालता है

    • जब भी लोग कहते हैं कि std::vector की performance भयानक है, खासकर games में, तो मुझे हमेशा चिढ़ होती है
      खाली vector से शुरू करके memory reserve किए बिना हजारों items जोड़ेंगे तो जाहिर है ऐसा हो सकता है। लेकिन बहुत बार असल में ज़रूरी maximum ढूँढकर पहले से allocate किया जा सकता है, और तब सब ठीक रहता है
    • TigerBeetle database इसी तरीके से बनाया गया है, और यह concept मुझे काफी पसंद है: https://tigerbeetle.com/blog/a-database-without-dynamic-memo...

  • union से polymorphic type का ENTITY data structure बनाने का तरीका मुझे वाकई पसंद आया। design अच्छा है
    C से अब भी छेड़छाड़ करना अच्छा लगता है। यह मेरी पहली सीखी हुई language थी, और कई सालों तक इससे खूब जूझा। मूल लेख में भी कहा गया है, C एक concise language है इसलिए शानदार है, और चाहें तो इसमें जितना चाहें उतना गहराई तक जा सकते हैं
    game में पुराने Commander Keen जैसा vibe था, जो अच्छा लगा, और 3D से पहले के दौर में Carmack जो franchise बना रहे थे, वह मुझे एक समय काफी पसंद थी