a5k - FPGA पर पोर्ट किया गया Another World / Out of This World

 (github.com/sylefeb)
1 पॉइंट द्वारा GN⁺ 2023-07-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Another World / Out of This World के VM, blitter और rasterizer को मानक CPU के बिना FPGA हार्डवेयर में लागू करने वाला व्यक्तिगत homage प्रोजेक्ट है
  • मुख्य डिज़ाइन में VM को एक वास्तविक custom processor के रूप में बनाया गया है, और frame buffer के बीच copy/fill संभालने वाला blitter, polygon ड्रॉ करने वाला rasterizer, तथा display refresh को एक साथ बाँधने वाला SOC शामिल है
  • Lattice UP5K का 128KB SPRAM 4-bit 320x200 frame buffer के 4 सेट के लिए उपयुक्त है, और प्रत्येक 32KB SPRAM block एक frame buffer के अनुरूप होने वाली memory layout बनाता है
  • गेम डेटा स्टोरेज में शामिल नहीं है, और data package तथा bitstream का उपयोग करने के लिए BANK01~BANK0D और MEMLIST.BIN को GAMEDATA फ़ोल्डर में कॉपी करना होगा
  • चलाने का तरीका simulation और वास्तविक बोर्ड, दोनों के लिए है
    • simulation के लिए Silice इंस्टॉल करने के बाद make simul1 से intro चलाया जा सकता है
    • हार्डवेयर के लिए icebreaker + VGA PMOD, mch2022 badge, ULX3S HDMI समर्थित हैं
    • prebuilt bitstream शामिल है, लेकिन गेम डेटा अलग से चाहिए
  • VM execution में SPI memory से instruction और operand लाए जाते हैं, और latency कम करने के लिए पहले 64 byte को छोटे BRAM cache में पढ़ा जाता है
  • graphics path में 4 frame buffer, double buffering, vblank अवधि के दौरान access restriction, तथा blitter और rasterizer के frame buffer access arbitration का उपयोग होता है
  • rasterizer, Another World के convex polygon को horizontal span के रूप में ड्रॉ करता है, और transparency effect के लिए मौजूदा pixel value को पढ़कर संशोधित कर सकता है या किसी दूसरे source frame buffer से pixel कॉपी कर सकता है
  • text rendering और part 6 की कुछ background के लिए, बचे हुए LUT budget की सीमा के कारण ROM में पहले से rendered pixel buffer संग्रहीत किए जाते हैं और op_drawString path से कॉपी किए जाते हैं
  • बताई गई सीमाओं और बाकी काम में sound·music का अभाव, part के हिसाब से अलग bitstream और data pack की आवश्यकता, पूरे गेमप्ले की validation अधूरी होना, मूल गेम से तेज timing adjustment, और part connection के तरीके की खोज शामिल है
  • लाइसेंस: Silice design के लिए MIT License, documentation के लिए CC BY-NC-SA 4.0, modified C++ port के लिए मौजूदा GPL बरकरार, और गेम डेटा copyright के अधीन है

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

1 टिप्पणियां

 
GN⁺ 2023-07-16
Hacker News की टिप्पणियां
  • बचपन में Sega Genesis पर Out of this World खेलते हुए मुझे लगता था कि graphics इससे बेहतर हो ही नहीं सकते
    Sega पर ऐसे पूरी तरह animated cutscene मैंने पहली बार देखे थे और वे वाकई कमाल के थे। जाहिर है graphics बेहतर हुए, लेकिन मुझे लगता है कि Another World आज भी कलात्मक रूप से पूरी तरह टिकता है। इसका style बहुत अलग है, और करीब एक साल पहले जब मैंने इसे फिर से खेला तो यह अब भी प्रभावशाली लगा
    कई puzzles काफी हद तक trial-and-error जैसे हैं और game भी बेहद छोटा है, फिर भी मैं इसमें कुछ बदलना नहीं चाहूंगा। Another World के fans को मैं Flashback: The Quest for Identity भी सुझाऊंगा। उसमें भी वैसी ही cinematic vibe है; शुरुआत में मुझे ज्यादा पसंद नहीं आया था, लेकिन पिछले 10 सालों में यह धीरे-धीरे ज्यादा अच्छा लगने लगा
    • मुझे Flashback सच में बहुत पसंद है। Cyberpunk setting मेरे taste की है, backgrounds खूबसूरत हैं और कहानी भी शानदार है
      फिर भी Another World एक कला-कृति है। game poster oil painting जैसा दिखता है और वाकई बहुत सुंदर है [1]
      [1] http://www.anotherworld.fr/download/AnotherWorld_Poster.jpg
    • Flashback इतना पसंद था कि मैंने इसे expert difficulty पर अंत तक clear करने की कोशिश की, लेकिन आखिरी हिस्से के आसपास अटक गया और slime man को हरा नहीं पाया
    • Genesis version काफी देर से आया था। 1991 में release के तुरंत बाद मैंने Amiga version खेला था और वह पूरी तरह चौंका देने वाला था; उससे पहले मैंने ऐसा कोई game नहीं देखा था
    • Sega पर मैंने पहले Flashback खेला था और तुरंत पसंद करने लगा। बाद में जब Out of this World खेला तो उसमें डूबने में थोड़ा समय लगा, लेकिन दोनों ही बेहतरीन कलाकृतियां हैं
    • Flashback Delphine Software का काम है, और detective game Cruise for a Corpse में भी कुछ वही polygon technology इस्तेमाल हुई थी
  • साथ में देखने लायक सामग्री:
    cyxx का Amstrad CPC के लिए Infernal Runner reverse engineering और JavaScript port. यह Another World के creator का काम है और दोनों virtual machine architecture का उपयोग करते हैं: https://github.com/cyxx/infernal_js
    Norbert Kehrer की The Virtual Machine Architecture of Infernal Runner presentation. German talk है, English slides के साथ: https://media.ccc.de/v/vcfb20_-146-en-202010111400-_th...
    The Story of Another World on the Amiga | MVG: https://www.youtube.com/watch?v=0iz9PJbs5rE
    Another World का Nintendo 64 port: https://github.com/jnmartin84/aw64
    Another World का PlayStation 1 port: https://github.com/fgsfdsfgs/rawpsx
  • अगर HDL भ्रमित कर रहा है, तो यह लेखक की custom language है: https://github.com/sylefeb/Silice/tree/master
    यह Verilog में compile करने वाला compiler देता है, और उसके output को मौजूदा design flow में डाला जा सकता है
  • intro शानदार था। तब भी, जब सिर्फ PC speaker था और sound card नहीं था
    पहली action से ही तैरकर भागना पड़ता है, और उसके बाद शेर जैसी creature से बचना पड़ता है—यह अब तक के सबसे कठोर game experiences में से एक है। इस game को सिर्फ 1 minute खेलो, फिर भी यह जिंदगी भर याद रह जाता है
    • लगता है मैंने कुछ minutes से ज्यादा, शायद ज्यादा से ज्यादा कुछ hours खेला था और progress भी लगभग नहीं हुई थी, लेकिन वह intro और पहली escape आज तक यादों में दर्ज है
      उस समय के हिसाब से इस game के dramatic camera effects सचमुच title की तरह किसी दूसरी दुनिया जैसे लगते थे
    • मैंने यह game खुद कभी नहीं खेला, लेकिन video game magazine के साथ आए promotional VHS tape के 2-minute scene ने ही 30 साल तक दिमाग में जगह बना ली
      cover art भी शानदार है
    • शेर जैसी चीज से नए दोस्त द्वारा बचाए जाने के तुरंत बाद game में आने वाला “dialogue” भी कभी नहीं भूल सकता
      konanaka beetzai! motsuubo! /wave
    • सिर्फ intro ही नहीं, यह भी चौंकाने वाला था कि पूरा game एक floppy disk में समा गया था
    • मुझे भी ठीक वैसा ही याद है कि करीब 1 minute खेलकर अटक गया था। 25 साल बाद फिर खेला और अंत तक clear किया; reaction speed barrier पार कर लें तो यह शानदार और यादगार game है
  • Another World के original developer ने GDC retrospective talk दिया था, और GDC talks में भी वह काफी अच्छा है:
    https://www.youtube.com/watch?v=JFaOYYSxSEA
    मेरी याद में वे कुछ development tools भी दिखाते हैं; virtual machine bytecode में animations को line-by-line सीधे edit करने और step execution करने का तरीका भी दिखता है
  • सोचता हूं 90s में पूरे game के लिए virtual machine कितनी common थी। यह game मुझसे भी पुराना है, तो उस समय PC पर virtual machine layer से performance loss काफी बड़ा नहीं होता होगा?
    • Amiga, x86(DOS), Mac, और ढेरों machines पर वही software चलाना कहीं ज्यादा महत्वपूर्ण था
      आज 80s के explosive growth दौर की तुलना में machine types कम हैं। आज भी अधिकांश “software” को web browser द्वारा interpreted JavaScript माना जा सकता है। 80s में भी portability की समस्या थी, बल्कि तब खुद interpreter बनाना पड़ता था, इसलिए यह और कठिन था
      लगता है कई, शायद ज्यादातर video games Doom या high-performance 3D graphics से पहले virtual machine में लिखे जाते थे। console games performance की वजह से शायद C या assembly में रहे होंगे

उस समय “computer” games IBM PC के standard बनने से पहले के थे, या कम-से-कम PC के जीतने और Microsoft के dominate करने से पहले के। Amiga, PC-98, IBM PC, Mac वगैरह में से कौन जीतेगा, यह पता न होने की स्थिति में virtual machine बनाना reasonable था, और SCUMM तुरंत याद आता है

  • फिर भी, ऐसी special-purpose virtual machine से Elite जैसा कुछ नहीं बनाया गया था
    portability भी महत्वपूर्ण थी, लेकिन उस दौर में जब Moore’s law पूरी रफ्तार से चल रहा था और platforms की उम्र मानो एक दिन की होती थी, virtual machine compression का असर भी देती थी। पूरी तरह compiled binary disk या tape space और RAM बहुत ज्यादा खा सकती थी
    इसके उलट, एक बहुत छोटी virtual machine ऐसी custom language बना सकती थी जिसे मौके पर interpret किया जाए, और जब हर kilobyte बचानी पड़ती थी, तब इससे जगह काफी घट जाती थी। print "Hello world!" और basic compiled binary के size के फर्क के बारे में सोचिए। text adventure चाहे कितना भी तेज हो, अगर वह X KB में फिट नहीं होता तो कोई फायदा नहीं था
  • assembly language के स्वर्णकाल में business software में भी virtual machines आम थीं। अलग-अलग systems को target करने वाले standards-compliant C compilers तब या तो अभी मौजूद नहीं थे या बहुत महंगे थे, इसलिए अलग-अलग systems पर port करना आसान हो जाता था
  • Infocom Z-Machine, Wizardry का interpreted Pascal code, SCUMM, Sierra AGI और SCI, Another World, Horrorsoft games जैसी शुरुआती virtual machines की तरकीब यह थी कि उन्होंने अच्छी तरह समझ लिया था कि बन रहा game मुख्य रूप से “content delivery device” है
    text और graphics assets बहुत थे और computation अपेक्षाकृत सरल था। authoring constraints hardware से सिर्फ input/output और data compression के लिहाज से जुड़े थे, और interpreter द्वारा चलाया जाने वाला code आम तौर पर एक बार चलने वाला “scene initialization” और थोड़े animation timers भर होता था
    उलटी दिशा का idea arcade games में, और बाद में Doom और Quake जैसी चीजों में ज्यादा साफ दिखता है। game जो simulate करता है वह hardware से कहीं ज्यादा गहराई से जुड़ा होता है, और scene definition “यहां monster रखो और वहां health item रखो” जैसी होती है, इसलिए वह script logic से ज्यादा map data जैसी बन जाती है
  • यह इस पर निर्भर करता है कि “पूरे game की virtual machine” को आप कैसे देखते हैं। Infocom के adventure games अपना सारा game code virtual machine पर चलाते थे, और Sierra व LucasArts के graphic adventures भी ऐसा ही करते थे
    बेशक, बाद वाले दोनों कुछ native graphics primitive operations का इस्तेमाल करते थे
  • ऐसा लगता है जैसे Only Amiga makes it possible को 30 साल बाद FPGA ने replace कर दिया हो
  • “[transparency] rasterizer में complexity जोड़ती है। [color value] का सिर्फ एक bit flip करने के लिए उस position पर pixel की पिछली value जाननी पड़ती है” वाला हिस्सा Amiga जैसी planar graphics इस्तेमाल करने पर मिलने वाले तीन फायदों में से एक के करीब है
    bitplanes इस्तेमाल करें तो video memory को फिर से पढ़ने की जरूरत नहीं होती। मान लीजिए top bit केवल transparency effect के लिए है और span को वैसे ही डाल दीजिए
    बाकी दो फायदे हैं: planes को एक-दूसरे के relative move करके शानदार moiré effects बना पाना, और 8 colors (3 bits per pixel) या 32 colors (5 bits per pixel) जैसी awkward color depths में, जो byte या nibble में ठीक-ठीक fit नहीं होतीं, memory और bus bandwidth efficiency अच्छी होना
  • इस thread की वजह से आखिरकार मैंने मान लिया कि मैं यह game खुद solve नहीं कर पाऊंगा और YouTube पर playthrough video देखा। वह 22 मिनट का था। मुझे लगता है मैं बस एक बार शेर के पास से आगे निकल पाया था