วิธีจัดการกับภาพขนาดใหญ่โดยพลการในเกม 2D?


13

คำถาม

เมื่อคุณมีเกม 2D ที่ใช้ภาพที่มีขนาดใหญ่มาก (ใหญ่กว่าฮาร์ดแวร์ของคุณสามารถรองรับได้) คุณจะทำอย่างไร อาจมีวิธีแก้ปัญหาที่น่าสนใจสำหรับปัญหานี้ซึ่งไม่เคยเกิดขึ้นกับฉันมาก่อน

ฉันกำลังทำงานกับผู้สร้างเกมผจญภัยกราฟิก ผู้ชมเป้าหมายของฉันคือผู้ที่มีประสบการณ์การพัฒนาเกม (และการเขียนโปรแกรม) เพียงเล็กน้อยหรือไม่มีเลย หากคุณทำงานกับแอปพลิเคชันเช่นนี้คุณไม่ต้องการให้มันจัดการกับปัญหาภายในแทนที่จะบอกให้คุณ "แยกภาพของคุณออก"

บริบท

เป็นที่ทราบกันดีว่าการ์ดกราฟิกกำหนดข้อ จำกัด เกี่ยวกับขนาดของพื้นผิวที่สามารถใช้ได้ ตัวอย่างเช่นเมื่อทำงานกับ XNA คุณจะถูก จำกัด ขนาดพื้นผิวสูงสุดที่ 2048 หรือ 4096 พิกเซลขึ้นอยู่กับโปรไฟล์ที่คุณเลือก

โดยทั่วไปแล้วสิ่งนี้จะไม่ก่อปัญหามากในเกม 2D เพราะส่วนใหญ่มีระดับที่สามารถสร้างจากชิ้นส่วนที่เล็กกว่า (เช่นแผ่นกระเบื้องหรือสไปรต์ที่ถูกเปลี่ยนรูป)

แต่ลองคิดถึงเกมผจญภัยกราฟิก point'nclick แบบคลาสสิค (เช่น Monkey Island) ห้องพักในเกมผจญภัยกราฟิกมักจะได้รับการออกแบบโดยรวมโดยมีส่วนที่ทำซ้ำได้น้อยหรือไม่มีเลยเหมือนกับจิตรกรที่ทำงานในแนวนอน หรืออาจเป็นเกมเช่น Final Fantasy 7 ที่ใช้ฉากหลังที่มีการแสดงผลขนาดใหญ่

ห้องเหล่านี้บางห้องมีขนาดใหญ่พอสมควรซึ่งมีความกว้างตั้งแต่สามหน้าจอขึ้นไป ตอนนี้ถ้าเราพิจารณาภูมิหลังเหล่านี้ในบริบทของเกมความละเอียดสูงที่ทันสมัยพวกเขาจะเกินขนาดพื้นผิวที่รองรับสูงสุดได้อย่างง่ายดาย

ตอนนี้ทางออกที่ชัดเจนของเรื่องนี้คือการแบ่งพื้นหลังออกเป็นส่วนย่อย ๆ ที่พอดีกับความต้องการและวาดมันเคียงข้างกัน แต่คุณ (หรือศิลปินของคุณ) จะต้องเป็นคนที่แยกพื้นผิวทั้งหมดของคุณหรือไม่

หากคุณกำลังทำงานกับ API ระดับสูงมันอาจจะไม่พร้อมที่จะรับมือกับสถานการณ์นี้และทำการแยกและประกอบพื้นผิวภายใน (ไม่ว่าจะเป็นกระบวนการก่อนอย่างเช่น Pipeline ของเนื้อหา XNA หรือรันไทม์)

แก้ไข

นี่คือสิ่งที่ฉันคิดจากมุมมองการใช้งาน XNA

เอนจิ้น 2D ของฉันต้องการฟังก์ชั่นย่อยของ Texture2D เพียงเล็กน้อยเท่านั้น ฉันสามารถลดมันลงไปที่อินเทอร์เฟซนี้ได้จริง:

public interface ITexture
{
    int Height { get; }
    int Width { get; }
    void Draw(SpriteBatch spriteBatch, Vector2 position, Rectangle? source, Color  color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth);
}

วิธีการภายนอกเดียวที่ฉันใช้ที่อาศัย Texture2D คือ SpriteBatch.Draw () ดังนั้นฉันจึงสามารถสร้างสะพานเชื่อมระหว่างพวกเขาโดยการเพิ่มวิธีการขยาย:

    public static void Draw(this SpriteBatch spriteBatch, ITexture texture, Vector2 position, Rectangle? sourceRectangle, Color color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth)
    {
        texture.Draw(spriteBatch, position, sourceRectangle, color, rotation, origin, scale, effects, layerDepth);
    }

สิ่งนี้จะช่วยให้ฉันใช้ ITexture interchangibly ทุกครั้งที่ฉันใช้ Texture2D มาก่อน

จากนั้นฉันสามารถสร้างการใช้งานสองแบบที่แตกต่างกันของ ITexture เช่น RegularTexture และ LargeTexture ที่ซึ่ง RegularTexture จะห่อ Texture2D ธรรมดา

ในทางกลับกัน LargeTexture จะเก็บรายการของ Texture2D แต่ละรายการที่ตรงกับหนึ่งในชิ้นส่วนที่แยกของภาพเต็ม ส่วนที่สำคัญที่สุดคือการเรียก Draw () บน LargeTexture ควรจะสามารถนำการแปลงทั้งหมดมาใช้และดึงชิ้นส่วนทั้งหมดราวกับว่ามันเป็นเพียงภาพเดียวที่ต่อเนื่องกัน

ในที่สุดเพื่อให้กระบวนการทั้งหมดโปร่งใสฉันจะสร้างคลาสโหลดเดอร์แบบรวมพื้นผิวที่จะทำหน้าที่เป็นวิธีการจากโรงงาน มันจะใช้เส้นทางของพื้นผิวเป็นพารามิเตอร์และส่งกลับ ITexture ซึ่งอาจเป็น RegularTexture หรือ LargeTexture ขึ้นอยู่กับขนาดภาพเกินขีด จำกัด หรือไม่ แต่ผู้ใช้ไม่จำเป็นต้องรู้ว่ามันคือใคร

overkill หรือเสียงไม่เป็นไร?


1
ถ้าคุณต้องการแยกภาพให้ขยายขอบเขตของ Content ไปที่การเขียนโปรแกรม มีฟังก์ชั่นบางอย่างที่ไม่ครอบคลุมทุกสถานการณ์และในบางจุดคุณจะต้องขยายมันออกไป การแยกเสียงแบบส่วนตัวเป็นการแก้ปัญหาที่ง่ายที่สุดในขณะที่คุณสามารถจัดการเรียงลำดับภาพแผนที่แบบเรียงต่อกันซึ่งมีทรัพยากรมากมาย
DMan

การทำบนท่อเนื้อหาเป็นวิธีที่เหมาะสมที่สุด แต่ในกรณีของฉันฉันจำเป็นต้องโหลดอิมเมจของฉันที่รันไทม์และฉันก็จัดการกับวิธีแก้ไขปัญหารันไทม์ (ซึ่งเป็นเหตุผลที่ฉันถามคำถามนี้เมื่อวานนี้) แต่ความงามที่แท้จริงมาจากการใช้ "แผนที่ย่อย" นี้และทำให้มันทำงานเหมือนพื้นผิวปกติ เช่นคุณยังสามารถผ่านไป spritebatch การวาดและคุณยังสามารถระบุตำแหน่ง, การหมุน, ขนาด, src / สี่เหลี่ยมปลายทาง ฯลฯ ฉันมีครึ่งหนึ่งโดยขณะนี้ :)
เดวิด Gouveia

แต่ความจริงจะบอกฉันอยู่ในจุดที่ฉันสงสัยว่าทั้งหมดนั้นมีค่าจริงหรือถ้าฉันเพียงแค่ควรแสดงคำเตือนให้ผู้ใช้บอกเขาว่าขนาดภาพสูงสุดที่รองรับคือ 2048x2048 และทำได้ด้วย
David Gouveia

มันขึ้นอยู่กับคุณเกี่ยวกับการออกแบบจริงๆ หากคุณเสร็จสิ้นโครงการและคุณไม่สามารถเลื่อนไปมาระหว่างห้องได้จะดีกว่าถ้าไม่มีตัวแก้ไขที่อนุญาตให้คุณเลื่อนพื้นผิวขนาดใหญ่: D
Aleks

การซ่อนไว้ใน API ดูเหมือนเป็นวิธีที่ดีในการทำให้ชีวิตของผู้เขียนเกมง่ายขึ้น ฉันอาจนำไปใช้ในคลาส Polygon (Sprite) และ Texture ไม่ใช่กรณีพิเศษที่เป็นภาพขนาดเล็ก แต่ควรทำให้เป็นไทล์ที่ 1x1 ดังนั้นพื้นผิวเป็นกลุ่มพื้นผิวที่อธิบายกระเบื้องทั้งหมด & จำนวนแถว / คอลัมน์ ระดับรูปหลายเหลี่ยมจากนั้นดูข้อมูลนี้เพื่อแยกตัวเองและวาดแต่ละกระเบื้องด้วยพื้นผิวที่เหมาะสม ด้วยวิธีนี้มันเป็นคลาสเดียวกัน คะแนนโบนัสถ้าคลาสสไปรต์ของคุณดึงแผ่นกระเบื้องที่มองเห็นได้เท่านั้นและกลุ่มพื้นผิวจะไม่โหลดพื้นผิวจนกว่าจะมีความจำเป็น
uliwitness

คำตอบ:


5

ฉันคิดว่าคุณอยู่ในเส้นทางที่ถูกต้อง คุณต้องแยกภาพออกเป็นชิ้นเล็ก ๆ เมื่อคุณสร้างผู้สร้างเกมคุณไม่สามารถใช้ขั้นตอนการผลิตเนื้อหาของ XNA ได้ หากผู้ผลิตของคุณเป็นเหมือนเครื่องมือที่จะยังคงต้องการให้นักพัฒนาใช้ Visual Studio ดังนั้นคุณต้องสร้างกิจวัตรของคุณเองเพื่อแยก คุณควรพิจารณาการสตรีมชิ้นส่วนก่อนที่จะเป็น visizble เพื่อที่คุณจะได้ไม่ จำกัด จำนวนหน่วยความจำวิดีโอที่ผู้เล่นควรมี

มีเทคนิคบางอย่างที่คุณสามารถทำได้โดยเฉพาะสำหรับเกมผจญภัย ฉันจินตนาการว่าเกมผจญภัยคลาสสิคคุณจะมีพื้นผิวไม่กี่เลเยอร์เพื่อให้ ... ตัวละครของคุณสามารถเดินอยู่หลังต้นไม้หรืออาคาร ...

หากคุณต้องการให้เลเยอร์เหล่านี้มีเอฟเฟ็กต์พาราลิกซ์ดังนั้นเมื่อคุณแยกกระเบื้องของคุณให้ข้ามโปร่งแสงทั้งหมดเพียงครั้งเดียว ที่นี่คุณต้องคิดขนาดของกระเบื้อง ไทล์ขนาดเล็กจะเพิ่มการจัดการค่าใช้จ่ายและการโทร แต่จะมีข้อมูลน้อยลงซึ่งไทล์ขนาดใหญ่จะเป็นมิตรกับ GPU มากกว่า แต่จะมีความโปร่งแสงมาก

หากคุณไม่มีเอฟเฟ็กต์พาราลิกซ์แทนที่จะครอบคลุมทั้งฉากด้วยภาพยักษ์ 2-4 ภาพที่มีความลึก 32 บิตคุณสามารถสร้างความลึกเพียง 32 บิต และคุณสามารถมีเลเยอร์ปากกาหรือความลึกซึ่งจะมีเพียง 8 บิตต่อพิกเซล

ฉันรู้ว่ามันฟังดูยากที่จะจัดการสินทรัพย์โดยผู้พัฒนาเกมไม่ใช่ แต่จริงๆแล้วมันไม่จำเป็นต้องเป็น ตัวอย่างเช่นหากคุณมีถนนที่มีต้นไม้ 3 ต้นและผู้เล่นวิ่งไปข้างหลังต้นไม้ 2 ต้นและด้านหน้าต้นไม้ต้นที่สามและส่วนที่เหลือของพื้นหลัง ... เพียงแค่สร้างเค้าโครงฉากตามที่คุณต้องการในเครื่องมือแก้ไขของคุณ สร้างขั้นตอนจากผู้สร้างเกมของคุณคุณสามารถอบภาพยักษ์เหล่านี้ (กระเบื้องเล็ก ๆ ของภาพใหญ่)

เกี่ยวกับเกมคลาสสิคทำอย่างไร ฉันไม่แน่ใจว่าพวกเขาอาจใช้กลอุบายแบบซิมเมอร์ลาร์ แต่คุณต้องจำไว้ว่าในขณะที่หน้าจอมีขนาด 320x240 เกมนั้นมี 16 สีซึ่งเมื่อใช้พื้นผิวแบบ palattelized ให้คุณเข้ารหัส 2 พิกเซลในไบต์เดียว แต่นี่ไม่ใช่วิธีการที่สถาปัตยกรรมปัจจุบันทำงานดังนั้น: D

โชคดี


ขอบคุณมากความคิดที่น่าสนใจมากที่นี่! ฉันเคยเห็นเทคนิค stencil layer มาก่อนใน Adventure Game Studio สำหรับใบสมัครของฉันฉันกำลังทำสิ่งต่างไปเล็กน้อย ห้องพักไม่จำเป็นต้องมีภาพพื้นหลังหนึ่งภาพ แทนที่จะมีจานสีของภาพที่ผู้ใช้นำเข้าและเลเยอร์พื้นหลัง / เบื้องหน้า ผู้ใช้มีอิสระในการลากและวางชิ้นส่วนในห้องเพื่อสร้าง ดังนั้นถ้าเขาต้องการเขาก็สามารถแต่งมันออกมาเป็นชิ้นเล็ก ๆ ได้โดยไม่ต้องสร้างวัตถุเกมแบบไม่โต้ตอบ แม้ว่าจะไม่มี Parallax เนื่องจากมีเพียงสองชั้นเท่านั้น
David Gouveia

และฉันได้ดูไฟล์ข้อมูลสำหรับ Monkey Island Special Edition (HQ remake) ทุกฉากหลังจะถูกแบ่งออกเป็น 1024x1024 ชิ้นอย่างแน่นอน (แม้ว่าส่วนใหญ่ของรูปภาพจะไม่ได้ใช้งาน) อย่างไรก็ตามตรวจสอบการแก้ไขของฉันสำหรับสิ่งที่อยู่ในใจเพื่อให้กระบวนการทั้งหมดโปร่งใส
David Gouveia

ฉันอาจเลือกสิ่งที่สมเหตุสมผลมากกว่าเช่น 256x256 วิธีนี้ฉันจะไม่เสียทรัพยากรและหากตัดสินใจใช้งานการสตรีมในภายหลังจะโหลดชิ้นงานที่สมเหตุสมผลมากขึ้น บางทีฉันอาจจะอธิบายไม่ดีพอ แต่ฉันแนะนำว่าคุณสามารถอบเกมวัตถุเล็ก ๆ เหล่านี้ให้กลายเป็นพื้นผิวขนาดใหญ่ได้ สิ่งที่คุณจะบันทึกคือในกรณีที่คุณมีพื้นหลังขนาดใหญ่พิกเซลทั้งหมดจะถูกปกคลุมด้วยวัตถุคงที่ด้านบน
Aleks

ฉันเห็นดังนั้นผสานวัตถุคงที่ทั้งหมดเข้ากับพื้นหลังแล้วแยกและสร้างแผนที่พื้นผิว ฉันยังสามารถอบทุกอย่างลงในแผนที่พื้นผิวหลังจากฝึกคิด นั่นเป็นความคิดที่ดีเช่นกัน แต่ฉันจะทิ้งไว้ทีหลังเพราะตอนนี้ฉันไม่มีขั้นตอน "บิลด์" เช่นตัวแก้ไขและไคลเอนต์เกมทำงานบนเอ็นจิ้นเดียวกันและรูปแบบข้อมูลเดียวกัน
David Gouveia

ฉันชอบวิธี stencil แต่ถ้าฉันทำเกมตัวแก้ไขเกมผจญภัยฉันอาจจะไม่ใช้มัน ... อาจเป็นเพราะถ้าฉันสร้างเครื่องมือแบบนี้ฉันจะให้นักพัฒนาเกม มันมีข้อดีข้อเสีย ตัวอย่างเช่นคุณสามารถใช้รูปภาพอื่นที่บิตสามารถกำหนดทริกเกอร์ต่อพิกเซลหรือถ้าคุณมีภาพเคลื่อนไหวน้ำบางส่วนคุณสามารถ stencil ได้อย่างง่ายดาย หมายเหตุ: ข้อเสนอแนะที่แปลกประหลาดที่ไม่เกี่ยวข้องกันหนึ่งข้อจะดูที่แผนภาพสถานะ / กิจกรรม UML สำหรับการเขียนสคริปต์
Aleks

2

ตัดมันทิ้งเพื่อไม่ให้มีขนาดใหญ่ตามที่คุณต้องการอีกต่อไป ไม่มีเวทย์มนตร์ เกม 2D เก่าเหล่านั้นทำอย่างนั้นหรือแสดงผลเป็นซอฟต์แวร์ซึ่งในกรณีนี้ไม่มีข้อ จำกัด ด้านฮาร์ดแวร์เกินขนาด RAM สิ่งที่น่าสังเกตก็คือเกม 2D เหล่านั้นส่วนใหญ่ไม่มีพื้นหลังขนาดใหญ่พวกเขาแค่เลื่อนช้าๆเพื่อให้พวกเขารู้สึกว่าใหญ่มาก

สิ่งที่คุณต้องการทำในผู้สร้างเกมผจญภัยกราฟิกของคุณคือเตรียมรูปภาพขนาดใหญ่เหล่านั้นไว้ล่วงหน้าในขั้นตอน "build" หรือ "รวม" ก่อนที่เกมจะถูกบรรจุไว้ให้ทำงาน

หากคุณต้องการใช้ API และไลบรารีที่มีอยู่แทนที่จะเขียนด้วยตัวคุณเองฉันขอแนะนำให้คุณแปลงรูปภาพขนาดใหญ่เหล่านี้เป็นรูปแบบเรียงต่อกันระหว่าง "สร้าง" และใช้เครื่องมือเรียงซ้อน 2D ซึ่งมีจำนวนมาก

หากคุณต้องการใช้เทคนิค 3 มิติของคุณเองคุณยังอาจต้องการแยกออกเป็นแผ่นกระเบื้องและใช้ 2D API ที่เป็นที่รู้จักและออกแบบมาเป็นอย่างดีในการเขียนไลบรารี่ 3 มิติของคุณเองด้วยวิธีนี้คุณรับประกันได้ว่าจะเริ่มด้วย การออกแบบ API ที่ดีและการออกแบบน้อยกว่าที่คุณต้องการ


การทำมันในช่วงเวลาการสร้างนั้นเหมาะอย่างยิ่ง ... แต่ตัวแก้ไขของฉันยังใช้ XNA สำหรับการเรนเดอร์ไม่ใช่แค่เอนจิ้น ซึ่งหมายความว่าเมื่อผู้ใช้นำเข้ารูปภาพและลากเข้าไปในห้อง XNA ควรจะสามารถแสดงผลได้แล้ว ดังนั้นดิลมาขนาดใหญ่ของฉันคือจะทำการแยกในหน่วยความจำเมื่อโหลดเนื้อหาหรือบนดิสก์เมื่อนำเข้าเนื้อหา นอกจากนี้การแบ่งภาพออกเป็นหลาย ๆ ไฟล์ก็หมายความว่าฉันต้องการวิธีการเก็บสิ่งต่าง ๆ เหล่านี้ในขณะที่การทำในหน่วยความจำขณะใช้งานจริงนั้นไม่จำเป็นต้องเปลี่ยนแปลงไฟล์ข้อมูลของเกมเลย
David Gouveia

1

หากคุณคุ้นเคยกับรูปสี่เหลี่ยมในการฝึกสายตาฉันได้ใช้วิธีการที่ตัดภาพขนาดใหญ่ที่มีรายละเอียดออกเป็นภาพเล็ก ๆ ที่ค่อนข้างคล้ายกับสิ่งที่พิสูจน์ / แสดงภาพของควอดทรีดูเหมือน อย่างไรก็ตามฉันถูกสร้างขึ้นมาเพื่อตัดพื้นที่โดยเฉพาะที่สามารถเข้ารหัสหรือบีบอัดแตกต่างกันไปตามสี คุณสามารถใช้วิธีนี้และทำสิ่งที่ฉันอธิบายเพราะมันมีประโยชน์

เมื่อทำการตัดเวลาพวกเขาจะต้องใช้หน่วยความจำเพิ่มเติมชั่วคราวและทำให้เวลาในการโหลดช้าลง ฉันจะบอกว่ามันขึ้นอยู่กับว่าคุณใส่ใจเรื่องพื้นที่เก็บข้อมูลจริงหรือความเร็วในการโหลดของเกมที่ผู้ใช้สร้างขึ้นด้วยโปรแกรมแก้ไขของคุณ

โหลด / รันเวลา:วิธีที่ฉันจะไปเกี่ยวกับการโหลดเป็นเพียงการตัดมันเป็นชิ้นขนาดพอดี คิดเป็นพิกเซลหนึ่งชิ้นที่ถูกต้องที่สุดหากเป็นจำนวนคี่ แต่ก็ไม่มีใครชอบภาพที่ถูกตัดโดยเฉพาะผู้ใช้ที่ไม่มีประสบการณ์ซึ่งอาจไม่รู้ว่ามันไม่ได้ขึ้นอยู่กับพวกเขาเลย ทำให้ครึ่งกว้างหรือครึ่งหนึ่งของความสูง (หรือ 3rds, 4ths อะไรก็ได้) เหตุผลที่ไม่ได้เป็นสี่เหลี่ยมหรือ 4 ส่วน (2 แถว 2 คอลัมน์) เป็นเพราะมันจะทำให้หน่วยความจำเล็กลงเพราะคุณไม่ต้องกังวลทั้ง x และ y ในเวลาเดียวกัน (และขึ้นอยู่กับว่าภาพนั้นมีขนาดใหญ่เท่าใดมันอาจสำคัญมาก)

Before Hand / Automatically:ในกรณีนี้ฉันชอบความคิดที่จะให้ผู้ใช้มีทางเลือกในการเก็บมันไว้ในภาพเดียวหรือจัดเก็บเป็นชิ้นแยกต่างหาก (หนึ่งภาพควรเป็นค่าเริ่มต้น) การจัดเก็บภาพเป็น. gif จะใช้งานได้ดี ภาพจะอยู่ในไฟล์เดียวและแทนที่จะเป็นเฟรมภาพเคลื่อนไหวแต่ละภาพจะเป็นเหมือนไฟล์บีบอัดที่เก็บถาวรของรูปภาพเดียวกันทั้งหมด (ซึ่งเป็นสิ่งที่. gif เป็นหลักอยู่แล้ว) มันจะช่วยให้ง่ายต่อการขนส่งทางกายภาพของไฟล์โหลดได้ง่าย

  1. มันเป็นไฟล์เดียว
  2. ไฟล์ทั้งหมดจะมีการจัดรูปแบบเกือบเหมือนกัน
  3. คุณสามารถเลือกได้อย่างง่ายดายว่าเมื่อใดและถ้าจะตัดเป็นพื้นผิวแต่ละแบบ
  4. มันอาจจะง่ายกว่าในการเข้าถึงแต่ละอิมเมจถ้าพวกเขาอยู่ใน. gif ที่โหลดเดียวเพราะมันไม่จำเป็นต้องยุ่งมากกับไฟล์ภาพในหน่วยความจำ

โอ้และถ้าคุณใช้วิธีการ. gif คุณควรเปลี่ยนนามสกุลไฟล์เป็นอย่างอื่น (.gif -> .kittens) เพื่อความสับสนน้อยลงเมื่อไฟล์. gif เคลื่อนไหวเหมือนไฟล์ที่ใช้งานไม่ได้ (ไม่ต้องกังวลกับความถูกต้องตามกฎหมายของ. gif เป็นรูปแบบเปิด)


สวัสดีและขอบคุณสำหรับความคิดเห็นของคุณ! ขออภัยถ้าฉันเข้าใจผิด แต่ไม่ใช่สิ่งที่คุณเขียนเกี่ยวกับการบีบอัดและการจัดเก็บเป็นหลัก ในกรณีนี้ทั้งหมดฉันจริงๆกังวลเกี่ยวกับการเป็นผู้ใช้แอพลิเคชันของฉันเป็นสามารถนำเข้าใด ๆของภาพและเครื่องยนต์ (ใน XNA) เป็นความสามารถในการโหลดและการแสดงใด ๆภาพที่รันไทม์ ฉันสามารถแก้ไขมันได้ง่ายๆโดยใช้ GDI เพื่ออ่านส่วนต่าง ๆ ของภาพลงในพื้นผิว XNA แยกจากกันและห่อไว้ในชั้นเรียนที่มีลักษณะการทำงานเหมือนพื้นผิวปกติ (เช่นสนับสนุนการวาดและการแปลงโดยรวม)
David Gouveia

แต่ด้วยความอยากรู้คุณสามารถอธิบายเพิ่มเติมเกี่ยวกับเกณฑ์ที่คุณใช้ในการเลือกพื้นที่ของภาพในแต่ละส่วนได้หรือไม่
David Gouveia

บางส่วนอาจอยู่เหนือหัวของคุณหากคุณมีประสบการณ์น้อยในการจัดการภาพ แต่ที่จริงแล้วฉันอธิบายการตัดภาพออกเป็นส่วน ๆ และใช่จุด. gif นั้นอธิบายทั้งที่เก็บข้อมูลและการโหลด แต่มันมีความหมายว่าเป็นวิธีที่คุณสามารถตัดภาพแล้วเก็บไว้ในคอมพิวเตอร์ว่ามันเป็นอย่างไร หากคุณบันทึกเป็น gif ฉันกำลังบอกว่าคุณสามารถตัดเป็นภาพแต่ละภาพแล้วบันทึกเป็น gif แบบเคลื่อนไหวโดยภาพแต่ละภาพจะถูกบันทึกเป็นเฟรมภาพเคลื่อนไหวแยกต่างหาก มันใช้งานได้ดีและฉันยังเพิ่มคุณสมบัติอื่น ๆ ที่อาจช่วยด้วย
Joshua Hedges

ระบบควอดทรีตามที่ฉันอธิบายไว้เป็นข้อมูลอ้างอิงทั้งหมดเนื่องจากเป็นที่ที่ฉันได้รับแนวคิด แม้ว่าแทนที่จะเป็นคำถามที่ใช้งานได้สำหรับผู้อ่านที่อาจมีปัญหาคล้ายกันเราควรใช้การส่งข้อความส่วนตัวหากคุณต้องการทราบข้อมูลเพิ่มเติม
Joshua Hedges

Roger ฉันมีส่วนเกี่ยวกับการใช้เฟรม GIF เป็นที่เก็บถาวรของแปลก ๆ แต่ฉันก็สงสัยเช่นกันว่า GIF นั้นเป็นรูปแบบที่จัดทำดัชนีโดยมีจานสี จำกัด หรือไม่ ฉันสามารถเก็บภาพ RGBA 32bpp ทั้งหมดในแต่ละเฟรมได้หรือไม่ และฉันคิดว่ากระบวนการของการโหลดมันจะซับซ้อนยิ่งขึ้นเนื่องจาก XNA ไม่สนับสนุนสิ่งนี้
David Gouveia

0

นี่จะฟังดูชัดเจน แต่ทำไมไม่แยกห้องของคุณเป็นชิ้นเล็ก ๆ ล่ะ? เลือกขนาดตามอำเภอใจที่จะไม่ชนหัวกับการ์ดกราฟิกใด ๆ (เช่น 1024x1024 หรืออาจใหญ่กว่า) และแบ่งห้องของคุณออกเป็นหลายชิ้น

ฉันรู้ว่านี่เป็นการหลีกเลี่ยงปัญหาและโดยสุจริตนี่เป็นปัญหาที่น่าสนใจในการแก้ไข อย่างไรก็ตามนี่เป็นวิธีแก้ปัญหาเล็กน้อยซึ่งอาจใช้เวลาพอสมควรสำหรับคุณ


ฉันคิดว่าฉันอาจจะพูดถึงเหตุผลบางอย่างในหัวข้อนี้ แต่เนื่องจากฉันไม่แน่ใจว่าฉันจะทำซ้ำ โดยพื้นฐานแล้วมันไม่ใช่เกม แต่เป็นผู้สร้างเกมสำหรับบุคคลทั่วไป (คิดว่าอยู่ในขอบเขตเดียวกับผู้สร้างเกม RPG) ดังนั้นแทนที่จะบังคับให้มีการ จำกัด ขนาดพื้นผิวเมื่อผู้ใช้กำลังนำเข้าเนื้อหาของตัวเอง การแยกและการเย็บโดยอัตโนมัติอยู่เบื้องหลังโดยไม่ต้องรบกวนรายละเอียดทางเทคนิคของข้อ จำกัด ขนาดพื้นผิว
David Gouveia

โอเคนั่นสมเหตุสมผลแล้ว ขออภัยฉันเดาว่าฉันพลาด
ashes999
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.