Amiga पर एनिमेशन “woosh” स्क्रीन कोड करना
(dansalva.to)- Magicore Anomala 1985 में लॉन्च हुए Amiga की graphics और sound क्षमताओं से full-screen CG और anime-style transitions लागू करता है, लेकिन game engine के अंदर RAM layout, screen split और sprite constraints को साथ-साथ हल करना पड़ता है
- सामान्य Amiga 500 configuration में graphics और sound के लिए इस्तेमाल हो सकने वाली Chip RAM सिर्फ 512KB होती है, इसलिए 320x240, 32-color CG का 48KB uncompressed आकार बड़ा बोझ बन जाता है
- CG को ZX0 compression से लगभग 8KB तक घटाकर expansion RAM में रखा जाता है, और display से ठीक पहले Chip RAM में decompress करते हुए मौजूदा 48,000-byte screen memory को reuse किया जाता है
- Transition effect copper द्वारा किसी खास scanline पर hardware registers बदलने और bitplane DMA को off/on करने के तरीके से बनाया जाता है; CPU हर frame में split width के मुताबिक copperlist values adjust करता है
- Background की motion lines के लिए Amiga sprites की color, reuse और bitplane dependency constraints को bypass करना पड़ता है; attached sprites, dummy control bits, 1 bitplane बनाए रखना और
BPLMOD1adjustment इसके मुख्य उपाय हैं
Amiga 500 में full-screen CG डालने की RAM समस्या
- Magicore Anomala का target platform सामान्य Amiga 500 है, जिसकी configuration 512KB Chip RAM और 512KB expansion RAM है
- Amiga chipset graphics और sound output के लिए सिर्फ Chip RAM का उपयोग कर सकता है
- Expansion RAM तक केवल CPU access कर सकता है, इसलिए इसे graphics/sound के लिए सीधे इस्तेमाल करना मुश्किल है
- Full-screen character graphic (CG) 320x240 bitmap की 32-color image है, और uncompressed स्थिति में 48KB लेती है
- Common assets, level data और screen memory allocation तक को देखते हुए 48KB बड़ा overhead है
- हाल में जोड़ा गया asset compression support ZX0 compression format का उपयोग करता है
- Compressed CG लगभग 8KB तक घट जाती है
- Level assets load करते समय compressed CG को expansion RAM में रखा जाता है
- Display से ठीक पहले इसे Chip RAM में decompress किया जाता है
नया 48KB Chip RAM सुरक्षित न रखने का तरीका
- CG के लिए अलग से खाली 48KB Chip RAM ढूंढने के बजाय, मौजूदा screen memory के कुछ हिस्सों को reuse किया जाता है
- Room background image
- Hazard objects render करने के लिए screen layer
- Textbox screen area
- ये तीन memory areas RAM में contiguous हैं, और इनका कुल आकार 48,000 bytes है, जो CG के सटीक आकार से मेल खाता है
- Room background image को CG display खत्म होने के बाद restore किया जा सकता है, इसलिए overwrite करने में समस्या नहीं है
- CG decompression में लगभग 500ms लगते हैं, लेकिन इसे cutscene flow में डालकर loading जैसा दिखने से बचाया जाता है
- Magicore Anomala का gameplay proof-of-concept video YouTube पर देखा जा सकता है
Screen split effect और copper का उपयोग
- शुरुआत में vertical wipe transition पर विचार किया गया था, लेकिन इसे अच्छा दिखाने के लिए हर scanline पर color palette adjust करने वाला gradient चाहिए था
- यह माना गया कि केवल copper से एक horizontal blank में सभी 32 colors set करना कठिन होगा
- “racing the beam” से निपटना नहीं चाहते थे, इसलिए screen split effect चुना गया
- Screen split effect आम viewers को अधिक शानदार दिखता है, और Amiga का copper practically ऐसे effects के लिए design किया गया हो, वैसे काम करता है
- इसी तरह का effect Amiga Workbench में built-in होने का उदाहरण इस video में देखा जा सकता है
- Implementation में Amiga की दो capabilities साथ में इस्तेमाल होती हैं
- Copper CPU के parallel अपनी command list चलाता है और किसी specific screen line पर hardware registers बदल सकता है
- Screen pointer को hardware register से set करके screen memory को Chip RAM में किसी भी location पर बदला जा सकता है
bitplane DMA रोककर फिर आगे draw करना
- उदाहरण के लिए, अगर main screen memory
0x20000से शुरू होती है, तो आम तौर पर copper bitplane DMA register में यही address set करता है- Bitplane activate करने पर DMA उस memory area को क्रम से पढ़ते हुए screen पर draw करता है
- जब हर horizontal line
0x100bytes लेती है, तब screen pointer को0x20800पर set करने से screen 8 lines ऊपर scroll हुई लगती है- क्योंकि screen का start point memory में 8 lines नीचे चला गया होता है
- Split का upper half इसी तरीके से ऊपर scroll किया जाता है
- Split point पर copper bitplane DMA को बंद करता है और background color को red में बदलता है
- Bitplane-related hardware registers उस क्षण effectively रुक जाते हैं
- Split के lower side तक पहुंचने पर background color restore किया जाता है और bitplane DMA फिर से on किया जाता है
- Screen रुकी हुई position से फिर आगे draw होती है, लेकिन actual display position और नीचे हो जाती है
- हर frame CPU split की current width के अनुसार
vs_TCopTopऔरvs_TCopBottomको adjust करता है- Upper split के लिए screen pointer adjustment भी साथ में होता है, लेकिन code example में शामिल नहीं है
“woosh” motion lines के लिए sprite workaround
- Anime-style background की motion lines sprites से draw की जाती हैं
- Sprites screen memory से स्वतंत्र रूप से draw और move हो सकते हैं, इसलिए इस use case के लिए suitable हैं
- हालांकि Amiga sprites में constraints बहुत हैं और इन्हें handle करना जटिल है
-
Color constraints
- Sprites bitplane के साथ color palette share करते हैं, इसलिए mumkin हो उतने कम colors इस्तेमाल करने पड़ते हैं
- Motion lines सिर्फ 3 colors इस्तेमाल करती हैं, जिससे CG के लिए 28 colors और background के लिए 1 color बचता है
- Amiga में हर sprite pair अलग palette color range उपयोग करता है
- पहले दो sprites colors 16-19 का उपयोग करते हैं
- अगले दो sprites colors 20-23 का उपयोग करते हैं
- दो sprites को attach करने पर वे 16-color palette वाले एक sprite की तरह काम करते हैं और colors 16-31 इस्तेमाल कर सकते हैं
- Motion lines 4 attached sprites का उपयोग करती हैं, और graphics में केवल colors 29-31 इस्तेमाल करती हैं
-
एक ही sprite graphic को कई positions पर इस्तेमाल करना
- Sprite graphic के पहले 4 bytes position और height निर्दिष्ट करने वाले control bits होते हैं
- एक ही graphic को कई positions पर draw करना हो तो यह structure समस्या बन जाता है
- Hardware register से sprite control bits सीधे set करने की कोशिश की गई, लेकिन उन्हें screen पर दिखाया नहीं जा सका
- Amiga sprite DMA bitplane DMA की तरह sprite data pointer को follow करते हुए screen पर draw करता है
- समाधान 4-byte के 8 fake sprites बनाने का है
- ये fake sprites केवल control bits रखते हैं
- सभी sprite pointers को पहले fake sprites पर set किया जाता है
- लगभग line 19 पर sprite DMA pointer देखकर control bits load करता है
- उसके बाद सभी pointers को actual “motion line” graphic पर बदल दिया जाता है
- परिणामस्वरूप DMA अलग-अलग positions पर sprites draw करने के लिए loaded state में रहते हुए same graphic का उपयोग करता है, और यह switch copperlist में handle होता है
bitplane बंद करने पर sprites भी गायब हो जाने की समस्या
- CG के screen top तक पहुंचने से पहले screen के ऊपरी हिस्से और CG start point के बीच खाली जगह होती है
- इस समय bitplane को on रखेंगे तो screen पर garbage data draw होगा
- उस area में bitplane बंद करना चाहिए ताकि DMA garbage data न पढ़े
- समस्या यह है कि bitplane बंद करने पर sprites भी draw नहीं होते
- इससे motion lines केवल CG की boundary के अंदर ही दिखती हैं
- समाधान bitplane को पूरी तरह बंद न करके केवल 1 bitplane on रखना और screen pointer को empty data पर set करना है
- Screen पर कुछ draw तो होता है, लेकिन अंततः कुछ दिखाई नहीं देता
- पूरे blank screen की जरूरत नहीं है
- 1-bit pixel मानक पर 320 pixels की एक line 320 bits, यानी 40 bytes होती है
BPLMOD1को-40पर set करने से हर line के बाद pointer 40 bytes पीछे लौटकर वही 40 bytes बार-बार draw करता है- Screen के safety margin में शुरुआती 40 bytes खाली रखना पर्याप्त है
परिणाम और बाकी छोटे काम
- शुरुआत में RAM requirement की वजह से यह पक्का नहीं था कि ऐसे CG को game में डालना संभव होगा या नहीं, लेकिन data compression implement करने के बाद overhead काफी reasonable level का निकला
- Magicore में अतिरिक्त visual embellishments जोड़ना संभव हो गया
- कुछ छोटे tasks अभी भी बचे हैं जिन्हें cover नहीं किया गया
- जैसे 100px motion line के screen से ऊपर निकल जाने के बाद उसका lower part अचानक गायब न हो, यह समस्या
- यह effect blitter का बिल्कुल इस्तेमाल नहीं करता
- Blitter से जुड़ी बात Getting clever with the Amiga blitter में cover की गई है
- Amiga, जैसे 1980 के दशक के अंत में लोगों को प्रभावित करता था, वैसे ही आज भी color graphics display capability से लोगों को प्रभावित कर सकने वाला platform बना हुआ है
1 टिप्पणियां
Hacker News की राय
“Racing the beam” का मतलब क्या है, यह अब बिल्कुल समझ में आता है। पहले हम vsync किए गए routine की शुरुआत और अंत में beam का रंग अलग-अलग बदल देते थे, ताकि हिसाब लगा सकें कि हर frame में कितनी scanlines जितना CPU time इस्तेमाल किया जा सकता है।
याद है, इस काम के लिए इस्तेमाल होने वाला address $dff180 था। यह color palette 0 था, इसलिए bitmap area के बाहर screen के किनारों पर भी हमेशा दिखता था।
वह तरकीब भी हमने internet के बिना, पूरी तरह लोगों से सुन-सुनकर सीखी थी, और मुझे नहीं पता था कि आज भी लोग उस chipset से और performance निकालने की कोशिश कर रहे हैं।
आजकल demoscene करीब 2017 से अविश्वसनीय रूप से बेहतर हो गया है, और मुझे कुछ ऐसे पसंदीदा works मिलते हैं जो सिर्फ trapdoor memory लगे हुए basic Amiga 500 पर चलते हैं।
https://www.youtube.com/watch?v=2jciCr8zEhw
https://www.youtube.com/watch?v=iD9xk3SDSYc
https://www.youtube.com/watch?v=pYtleuGV7ok
https://www.youtube.com/watch?v=E0OzX7plbeY
https://www.youtube.com/watch?v=rIV4AhfugIs
सच में उत्सुकता है कि Amiga पर game बनाने के लिए समय निकालने वाले लोग कौन हैं। युवा लोगों को शायद ऐसे पुराने computers में दिलचस्पी न हो, और जो लोग इनके साथ बड़े हुए वे परिवार और काम में व्यस्त होंगे।
व्यस्त न भी हों, तो भी उतने ही मज़ेदार और modern sensibility बनाए रखने वाले projects बहुत हैं। फिर भी यह वाकई कमाल है।
अब मैं full-time indie game developer के तौर पर काम करता हूँ। Amiga game बनाना मेरे लिए लगभग जीवनभर का सपना था, और अब लगता है कि मेरे पास उसे पूरा करने की skill है।
मैं दिखाना चाहता हूँ कि आज के tools और व्यापक रूप से उपलब्ध knowledge का उपयोग करके, modern design principles वाले game experience के जरिए, कभी बेहद पसंद किए गए classic hardware में नई जान फूंकी जा सकती है।
अगर जीवन की हर चीज़ को career से जोड़ दें, तो पूरी जिंदगी ही काम बन जाती है।
यह वैसा ही है जैसे पूछना कि Photoshop होते हुए oil painting क्यों सीखते हो, या Tesla होते हुए vintage car restore क्यों करते हो।
Region switch mod काफी जटिल है, क्योंकि इसमें दो VIC-II और दो oscillators के बीच switch करना पड़ता है। मेरे पास MSX2 भी है; बहुत ज़्यादा इस्तेमाल नहीं किया, लेकिन उसका charm बहुत है।
ऐसी machines पर सच में code लिखने का समय निकालना मुश्किल है, लेकिन मुझे लगता है कि ज्यादातर working लोगों के hobbies की तरह, inspiration आने पर रातें और weekends लगाने की बात है।
retrocomputing एक आकर्षक और rewarding hobby है। बस मेरी शिकायत time से ज्यादा parts जुटाने की कीमत और कठिनाई से है।
Computer market में “antique” या “vintage” label लगी किसी भी चीज़ को महंगे में बेचने वाले लोग बढ़ गए लगते हैं, यह अफसोस की बात है।
उम्र में बड़े लोगों के बारे में सीधे कहना मुश्किल है, लेकिन अब भी Commodore 64 demos बनाने वालों में कुछ लोग बचपन से फिर जुड़ने की चाह से प्रेरित लगते हैं।
Bonzai और Pretzel Logic का अपेक्षाकृत हाल का demo “Mojo” लगभग ऐसी कहानी खुद ही सुनाता है। demoscene work में “serious” storytelling करने की कोशिश थोड़ी cringe लगती है, फिर भी उसमें अपनापन है, इसलिए अच्छा लगता है।
यह बहुत time लेने वाली hobby है, लेकिन अगर सच में समय निकालना चाहें तो आखिर रास्ता मिल ही जाता है।
[1]: https://csdb.dk/release/?id=232966, https://www.youtube.com/watch?v=HXi3oJ9huiI
[1] https://retro.moe/2024/02/04/bluepad32-v4-0/
[2] https://www.youtube.com/watch?v=Nj5fZlt_834
https://www.udemy.com/course/programming-games-for-the-atari...
सोचा था work from home करने से ज्यादा खाली समय मिलेगा, लेकिन असलियत वैसी नहीं निकली। फिर भी किसी दिन काम आगे बढ़ाना है।
मैं हमेशा सोचता था कि Amiga पर Japanese console-style game कैसा दिखता, और यह कि Amiga की performance कम थी या ज्यादातर games का design ही मेरी पसंद का नहीं था।
Bonk को Factor 5 ने शानदार तरीके से port किया था, लेकिन वे लोग लगभग जादूगर थे।
“साधारण Amiga 500 में 512KB Chip RAM और 512KB expansion RAM होती है” वाला हिस्सा थोड़ा गलत है। Basic A500 में सिर्फ 512KB Chip RAM थी।
कई users ने A501 RAM expansion जोड़ा, जिससे 512KB Fast RAM और मिली जिसे graphics hardware सीधे access नहीं कर सकता था।
इसे Fast RAM कहा जाता था, लेकिन expansion structure की वजह से यह असली Fast RAM से धीमी थी।
ज्यादातर A500 owners के पास 512KB trapdoor expansion था। Monkey Island जैसे games समेत बहुत सारा software कुल 1MB RAM के बिना नहीं चलता था।
आजकल open hardware designs पर आधारित सस्ते trapdoor expansions खूब उपलब्ध हैं, जो 1.5MB Slow RAM, कुल 1MB बनाने वाली 512KB Chip RAM, और RTC तक देते हैं।
ऐसी constraints के भीतर coding करने में अविश्वसनीय रूप से खींचने वाली कोई बात है।
IE देखकर अच्छा लगा। Amiga में उसे गहराई से उतरते देखना अच्छा है।
मुझे ऐसा लगता है कि बहुत लोगों ने जिस Amiga से खेला, वह मेरे वाले Amiga से अलग था। अच्छे दिखने वाले games ज़रूर थे, लेकिन Nintendo NES में भी थे, और मैं दोनों को इतनी भावुकता से याद नहीं करता।
फिर भी यह दिखाना कि ऐसी animation कैसे बनाई गई, बहुत शानदार है।
Amiga सचमुच सब कुछ समेटे हुए system था। Advanced 32-bit CPU, graphics acceleration, बेहतरीन audio, और NES से literally 256 गुना RAM थी।
SNES भी करीब नहीं आया, और Sega Saturn era तक मुझे Amiga से आगे निकलने वाली machine नहीं दिखी।
https://www.youtube.com/watch?v=4SB20aFHc08