שְׁאֵלָה:
כיצד מכשירים כמו ה- Game Boy Advance משיגים את קצב המסגרות שלהם?
MalphasWats
2018-12-18 01:01:02 UTC
view on stackexchange narkive permalink

תכננתי מכשיר משחק כף יד משלי המבוסס על מיקרו בקר AVR ותצוגת OLED קטנה.

התחלתי עם צג מונוכרום בגודל 128x64 פיקסלים ויכול לצייר אליו בנוחות מעל 60 פריימים לשנייה.

לאחרונה עיבדתי אותו לשימוש בכדי להשתמש ב- RGB OLED, 128x128 פיקסלים מבלי לחשוב יותר מדי רק כדי לגלות שאוכל להשיג רק כ -4 FPS. לאחר מחשבה ושיקום מחדש זהיר אני יכול להשיג את זה עד ~ 12fps אם לא אכפת לי יותר מדי לעשות שום דבר אחר!

השאלה שלי היא - איך מכשיר כמו GBA (Game Boy Advance) השיג קצב פריימים של כמעט 60fps? חשבתי שיהיה לי 'מעבד גרפי' נפרד אבל הבנתי שעדיין אהיה לי צוואר בקבוק להעביר את נתוני התצוגה לכך.

גם תהיתי לגבי השימוש בממשק המקבילי בעל 8 סיביות, שרוב המסכים הללו נוטים להיות, מה שעשוי להאיץ אותי פי 8, אלא שממשקי MCU מודרניים אינם נוטים להיות עם ממשקים מקבילים לחומרה כמו עבור סדרתי. ודופק קצת יאכל הרבה מהעלייה המהירה.

אילו אפשרויות אחרות קיימות?

כרגע אני משתמש ב- ATmega1284P המחובר לבקר OLED SSD1306 באמצעות USART-SPI. זו הגרסה המונוכרומית.

המסך הצבעוני היה SSD1351, לא במקור מחובר ל- SPI חומרה. לא הייתי משוכנע שזה ישפיע מספיק , זה פשוט איטי מדי בסך הכל

אני יודע שאני יכול לקבל MCUs מהירים יותר, אבל אני רוצה לדעת אילו אפשרויות אחרות אוכל לחקור - מעבד GBA איטי בהרבה מ- 1284 שלי!

* "אני עדיין הייתי מצוואר בקבוק ומעביר את נתוני התצוגה לזה." * ל- DSI יש ארבעה נתיבים כל אחד עד 1.2 ג'יגה-סיביות.את שאר החישובים אני משאיר לך.
* "אני עדיין הייתי מצוואר בקבוק ומעביר את נתוני התצוגה לזה." * האם אתה מתכוון שאתה מאמין שהיית צוואר בקבוק מעביר נתונים למעבד הגרפי, או מהמעבד הגרפי לתצוגה?
בדיוק כמו כל גרפיקה בכל מכשיר משחק וידאו, יש זיכרון שיעסוק בגרפיקה.לפי אתר [זה] (https://www.coranac.com/tonc/text/hardware.htm), יש מיקום כתובת עבור גרפיקה, סאונד וכו '. הוראות יישמרו שם.בהנחה שאין הרבה נתונים שיצרו התנגשויות עם זמן הביצועים, הוא יפעיל את ההוראות האלה כדי לטעון את הנתונים הגרפיים בקלות.
נראה כי לרוב התגובות חסר ההבדל העיקרי בין מערכות אלה עם ממשקי מסך רוחב פס גבוה, וניסיון הפוסטר עם תצוגה ממשק * סיבית * קצת.
לא צריכה להיות בעיה אם ה- OP משתמש בציוד SPI היקפי לחומרה עם DMA או דומה להפעלת התצוגה .. אם כי אני מודה שלא בדקנו זאת.שכחנו לשאול איזה ARV וגליון נתונים.
קנו את התצוגה ללא הבקר עליו והכינו בקר משלכם
ובכן מה צוואר הבקבוק שלך שהופך אותו ל -4 FPS בלבד?רוב הסיכויים שאין ל- GBA את צוואר הבקבוק הזה.
@immibis: כמעט בוודאות איזה בקר נוראי מבוסס I2C או SPI.דברים של הוביסטים מלאים בדברים איטיים יקרים מדי כאלו שאפשר להשיג מסך אייפון מקפיא של 400+ dpi במחיר של 20 דולר בגלל חסכוניות בקנה מידה.
@R .. אני רק רוצה לציין שהסיבה לבקרי התחביבים האלה היא כך שהם יוכלו להתממשק כמעט לכל מעבד, מכיוון שאתה גורם לו להישמע כאילו הם חסרי תועלת.לא תוכל להתממשק למסך אייפון בקלות, אם בכלל.זה כנראה מתחבר למעבד גרפי ייעודי ואולי מותאם אישית.
@immibis: עבור רוב המסכים הללו, אתה רק צריך בקר שיכול להפיק MIPI DSI.ישנם מכשירי תחביבים מסחריים ארוזים לכך (למשל להמרה מ- HDMI), או שאתה יכול לנהוג אם עצמך עם FPGA.
לדוגמא ראה https://hackaday.com/2014/08/19/a-mipi-dsi-display-shieldhdmi-adapter/ ודיון על הדברים הנוראיים באיכות התחביבים בתגובות.(לא חשבתי על זה בעת כתיבת האמור לעיל, פשוט מצאתי את זה עכשיו בגוגל)
אני לא חושב של- GBA היו 60fps, נכון?האם זה לא היה רק 30?
AililvgfiiCMT 59.7fps
חָמֵשׁ תשובות:
Mr.Mindor
2018-12-18 07:19:55 UTC
view on stackexchange narkive permalink

תשובות אחרות מכסות את שאלתך די טוב ברמה מופשטת (חומרה), אך בעל ניסיון אמיתי עם ה- GBA במיוחד חשבתי שהסבר מפורט יותר עשוי להיות שווה.

ל- GBA היו מצבי ציור והגדרות רבים שניתן להשתמש בהם כדי לשלוט על האופן שבו המעבד הגרפי פירש את זיכרון ה- RAM לווידאו, אך דבר אחד לא היה מנוס: קצב המסגרות. המעבד הגרפי צייר למסך בלולאה קבועה כמעט (להלן בהמשך). (זה כנראה הסיבית הרלוונטית ביותר לשאלתך.)

זה ימשוך קו אחד בכל פעם תוך הפסקה קצרה מאוד בין כל אחד מהם. לאחר ציור השורה האחרונה למסגרת זה ייקח הפסקה שווה בערך לזמן שלוקח לשרטט 30 קווים. ואז התחל מחדש. התזמון של כל שורה והתזמון של כל מסגרת נקבעו מראש והוגדרו באבן. בהרבה מובנים המעבד הגרפי היה באמת המאסטר של אותה מערכת והיית צריך לכתוב את המשחקים שלך סביב ההתנהגות שלו, כי הוא ימשיך לעשות את מה שהוא עשה בין אם אתה מוכן ובין אם לא.

בערך 75-80% מהזמן הוא דחף באופן פעיל למסך. אילו שיעורי פריימים היית יכול להשיג אם היית עושה את אותו הדבר?

ש- 80% מהזמן היה גם מה שהיה למעבד לעבד קלט משתמשים, לחשב את מצב המשחק ולהעמיס ספריטים / אריחים לאזורים של VRAM שהיו כרגע מחוץ למסך (או לפחות לא נכללים בקו הנוכחי המצויר ).

20% בין המסגרות היו כל מה שהמעבד היה צריך לשנות את הגדרות הווידאו או ה- RAM שישפיעו על כל המסגרת הבאה.

בסוף כל שורה, המעבד הגרפי ישלח הפרעת סנכרון קו למעבד.ניתן להשתמש בהפרעה זו לשינוי הגדרות בכמה ספריטים, או בכמה שכבות רקע (כך ניתן להשיג אפקט כמו זרקור חרוטי, על ידי שינוי הגודל והמיקום של אחת המסכות המלבניות בין כל קו שצויר.מבחינת החומרה כל אותם אזורים מלבניים.).עליכם להקפיד לשמור על עדכונים אלה קטנים ולסיים לפני שהמעבד הגרפי יתחיל לצייר את השורה הבאה או שתוכלו להשיג תוצאות מכוערות.כל זמן שעיבד את ההפרעות הללו גם נחתך לכדי 80% מזמן העיבוד של המעבד ...

עבור משחקים שהפיקו את המרב מהמערכת הזו, מעבד ומעבד גרפי מעולם לא לקחו הפסקה אמיתית;כל אחד מהם רדף אחר השני סביב הלולאה ועדכן את מה שהאחר לא מסתכל כרגע על.

ברוך הבא ונאמר היטב.
כמה מערכות "חדשות" כמו ה- Nintendo DS עברו את מגבלת המסגרות הקבועה על ידי הוספת ה- VCOUNT רישום כדי לעכב את המסגרת הבאה למשך זמן הניתן להגדרה (בדרך כלל כדי לעזור למשחקים מרובי משתתפים לסנכרן).
pjc50
2018-12-18 01:29:53 UTC
view on stackexchange narkive permalink

המאפיין העיקרי של כל קונסולות המשחקים שהבדילו ביניהן ממחשבים אישיים מוקדמים ולמעשה מכל המחשבים הביתיים (1) היה sprites חומרה .

מדריך התכנות המקושר של GBA מראה כיצד הם פועלים מנקודת מבט המעבד הראשית.מפות סיביות המייצגות נגן, רקע, אויבים וכו 'נטענות באזור זיכרון אחד.אזור זיכרון אחר מציין את מיקום הספריטים.אז במקום שיהיה צורך לכתוב מחדש את כל זיכרון הווידיאו בכל פריים, שלוקח הרבה הוראות, המעבד צריך רק לעדכן את מיקום הספריטים.

לאחר מכן מעבד הווידאו יכול לעבוד פיקסל אחר פיקסל כדי לקבוע איזה ספרייט לצייר בנקודה זו.

עם זאת, הדבר דורש זיכרון RAM בעל יציאה כפולה המשותף בין השניים, ולדעתי ב- GBA מעבד הווידאו נמצא על אותו שבב כמו מעבד ה- ARM הראשי והמעבד Z80 המשני.

(1) יוצא מן הכלל הבולט: Amiga

רק חן - במשחקי הארקייד המוקדמים היו ספריטים ב- ROM המשויך למעבד הגרפי, ולא זיכרון RAM בעל יציאה כפולה.אין לי מושג אם זה היה המקרה גם בקונסולות המוקדמות, אם כי בהחלט ניתן היה לעשות זאת כך.
@TimWescott ל- GBA היו מצבי ציור מרובים ואין לי ניסיון עם רובם, אז זה אולי לא נכון באופן אוניברסלי, אבל אני לא חושב שלאף אחד מהמצבים האלה הייתה גישה ישירה ל- ROM (על מחסנית): בדרך כלל כל האריחיםהיה צריך להעביר / sprite / palette data מה- ROM לזיכרון הווידאו והמעבד הגרפי עבד עליו משם.
@Mr.Mindor מצטער אם לא הייתי ברור - אני לא מתיימר לדעת על האופן שבו GB או GBA עשו זאת.רק הגבתי על משחקי הארקייד המוקדמים של נינטנדו בסוף שנות ה -70 ותחילת שנות ה -80, שכולנו תהינו איך בכל זאת הם עשו את זה.
@TimWescott: אני חושב שהדבר נכון גם לגבי ה- NES, אם כי ה- ROM המדובר היה ממוקם בתוך ה- Game Paks.
TimWescott
2018-12-18 01:25:18 UTC
view on stackexchange narkive permalink

"השאלה שלי היא - איך מכשיר כמו GBA השיג קצב פריימים של כמעט 60fps?"

כדי לענות רק על השאלה, הם עשו זאת עם מעבד גרפי.אני די בטוח ש- Game Boy השתמש בגרפיקה של ספרייט.ברמה העליונה זה אומר שהמעבד הגרפי מקבל טעינה של דברים כמו תמונה של רקע, ותמונה של מריו, ותמונה של פרינסס אפרסק וכו '. ואז המעבד הראשי מוציא פקודות כמו "הראה את הרקע שקוזז על ידיהרבה ב- x ו- y, כיסוי תמונת מריו מס '3 במיקום x, y זה "וכו'. לכן המעבד הראשי בהחלט לא מתייחס לצייר כל פיקסל, והמעבד הגרפי הוא בהחלט לא מודאג מחישוב המצב שלמִשְׂחָק.כל אחד מהם מותאם למה שהוא צריך לעשות, והתוצאה היא משחק וידאו די טוב בלי להשתמש בכוח חישוב רב.

לקרוא לזה "מעבד גרפי" מגזים במה שהוא עושה, מה שמרמז שזה מעין מעבד משלו.זה רק בקר וידאו, שהוא בעצם סוג מסובך של רצף.כאשר הוא מונה פיקסלים אופקיים ואנכיים, הוא מביא נתוני כותרת ו / או ספרייט, מכניס אותם לרשמי משמרות ומשלב את הפלט של רושמי המשמרות לפיקסל פלט.היא לא מסוגלת להפעיל תוכנית כמו מעבד גרפי "GPU" בפועל.
old_timer
2018-12-18 03:24:43 UTC
view on stackexchange narkive permalink

ל- GBA היה מעבד די איטי. ה- ARM7 נחמד מאוד; הם פשוט הפעילו את זה לאט ולא נתנו לו כמעט שום משאבים.

יש סיבה שהרבה משחקי נינטנדו באותה נקודה ולפני כן היו מגילות צד. חוּמרָה. הכל נעשה בחומרה. היו לך מספר שכבות של אריחים בתוספת ספריט אחד או יותר והחומרה עשתה את כל העבודה כדי לחלץ פיקסלים מהטבלאות האלה ולהניע את התצוגה.

אתה בונה את האריח שהוגדר מלפנים ואז היה לך זיכרון קטן שהיה מפת אריחים. רוצה שהאריח השמאלי התחתון יהיה אריח 7? שמים 7 במיקום הזיכרון הזה. רוצה שהאריח הבא יהיה אריח 19? בערכת האריחים אתה שם שם 19 וכן הלאה עבור כל שכבה שהפעלת. עבור sprite, אתה פשוט מגדיר את כתובת x / y. אתה יכול גם לבצע שינוי גודל וסיבוב על ידי הגדרת כמה רושמים והחומרה דואגת לשאר.

מצב 7, אם אני זוכר נכון, היה מצב פיקסל, אבל זה היה כמו כרטיס מסך מסורתי שבו אתה שם בתים שמכסים את הצבע לפיקסל והחומרה דואגת לרענון הווידאו. אני חושב שתוכל לפינג פונג או לפחות כשהיה לך מסגרת חדשה אתה יכול להעיף אותם, אבל אני לא זוכר נכון. שוב, המעבד היה חסוי למדי באותו יום ואילך ולא היו לו יותר מדי משאבים מהירים. אז בעוד שמשחקים מסוימים היו במצב 7, הרבה היו גלילי צד מבוססי אריחים ...

אם אתה רוצה פיתרון שקצב פריימים גבוה, עליך לתכנן את הפתרון. אתה לא יכול פשוט לקחת כל תצוגה ישנה שתמצא ולדבר איתה דרך SPI או I²C או משהו כזה. שים לפניו לפחות מסגרת מסגרת אחת, באופן אידיאלי שניים, ויש שליטה בשורה ועמודה במידת האפשר בתצוגה זו.

במספר התצוגות שאני חושד שאתה קונה יש בקר שעליו אתה באמת מדבר. אם אתה רוצה ביצועי סוג GBA / קונסולה אתה יוצר / מיישם את הבקר. או שאתה קונה / בונה עם GPU / שבב וידאו / לוגיקה, ומשתמש ב- HDMI או ממשק משותף אחר לצג מלאי.

רק בגלל שלאופניים יש צמיגים ושרשרת והילוכים זה לא אומר שהם יכולים ללכת מהר כמו אופנוע.עליך לתכנן את המערכת שתענה על צרכי הביצועים שלך, מקצה לקצה.אתה יכול לשים את גלגל האופניים על האופנוע הזה, אבל הוא לא יופיע כרצונך;כל הרכיבים צריכים להיות חלק מהתכנון הכללי.

אסטרואידים עבדו גם ככה;זה נדרש רק 6502 אחד. הגרפיקה הווקטורית נעשתה בלוגיקה נפרדת;ה- 6502 שלח מחרוזת זעירה של נתונים לבקר הגרפיקה הווקטורית, שהשתמש ב- ROM ובנתונים אלה כדי לבצע את תכנון ה- xy של הקורה ו- z, להפעלה / כיבוי ... בחלק מהסטנדאפים היו מעבדים נפרדים לטיפול באודיו ווידאו בנפרדהמעבד המחשב את המשחק.כמובן שכיום הסרטון מטופל על ידי כמה מאות, אם לא אלפי, מעבדים נפרדים מהמעבד הראשי ...

אני נשבע שאני זוכר ש- mode7 הוחלף על ידי שיווק כתגובה ל"מצב ההיפר "של סגה או משהו ... אולי" סופר FX? "https://en.wikipedia.org/wiki/Mode_7
https://www.coranac.com/tonc/text/bitmaps.htm#sec-modes אולי זכרתי את זה לא נכון אני חושב אולי על מצב 5, או על אחד ממצבי מפת הסיביות, יש כמה מצבי אריח עם ספריטים ומצב או מצבים של מפת סיביות / באגר.אולי יש 7. לא ידע על זה שקישרת אבל טוב לדעת.
הממ קורא יותר על מצב 7 וזה לא רק מצב.בכל מקרה ל- GBA יש מצבי אריחים ומצבי מפת סיביות שהם איטיים יותר מכיוון שאתה צריך להיות אחראי על כל פיקסל שבו מצבי האריחים בייט אחד במפת האריחים מייצרים פיקסלים רבים.הם גם מינו את גודל האוטובוסים (רוחב) ומהירות הזיכרון, ודבר מטמון של צינור רום כדי לעזור להוציא דברים (הוראות) מהר יותר קצת.אבל מהיום הראשון התאמצתם להשיג תוכנה שתפעל במהירות נאותה ולמרבה המזל ההיגיון טיפל ברוב עבודות הווידיאו.
אם אתה מסתכל על התצוגות שאתה קונה בעלות ממשקי 8 סיביות או 4 סיביות או ממשקי SPI או i2c המקבילים אלה בדרך שלך לביצועים, אתה רוצה את התצוגה הגולמית ללא אותם בקרים ואז תוכל לשלוט באופן ניהול התצוגה, בנה Framebuffer או שניים כדי שתוכל לפינג / פונג וממשק מהיר מהמעבד שלך ל- Framebuffer.בהנחה שתתחיל עם תצוגה מהירה מספיק מלכתחילה.
bobflux
2018-12-18 01:29:07 UTC
view on stackexchange narkive permalink

כיצד התקן כמו GBA קצב פריימים של כמעט 60fps?

חומרה.

יש לו זיכרון גרפי, שעשוי לחלוק את אותו אוטובוס כמו זיכרון התוכנית / נתונים ... או שהקטע החשוב הוא שיש לו מעבד גרפי שקורא את הזיכרון 60 פעמים בשנייה ושולח את הנתונים אל LCD באמצעות ממשק מותאם אשר נועד לעשות זאת ביעילות.

אתה יכול לעשות את אותו הדבר עם כל מיקרו-בקר מודרני המצויד בציוד היקפי "ממשק LCD", למשל LPC4330 אם כי זה עשוי להיות מוגזם. כמובן שתזדקק לפאנל LCD תואם.

עם מיקרו-בקרים מהירים מודרניים (כלומר, ARM ולא AVR) ומסך כה זעיר, ככל הנראה לא תזדקק לספריטים או לבליטר כדי להאיץ את פעולות הגרפיקה. עם AVR של 8 סיביות זה עשוי להיות איטי.

אבל לא משנה המעבד, קצת דופק את הממשק לתצוגה הולך להישאב.

אני מאמין ש- Atari 2600 השתמש במנגינת סיביות במעבד כדי לשלוח את התמונה לטלוויזיה. זה קצת מיושן.

אפילו ל- 2600 היו ספריטים של חומרה, אם כי מספר מוגבל מאוד (שני נגנים ושני כדורים לדעתי)
@pjc50, לאטרי 2600 * היו * סוגים של חומרה.כמו כל חלק אחר בתת-המערכת הגרפית, הם היו עצמים חד-ממדיים.אם המתכנת רצה משהו אחר מלבד סט קווים אנכיים, התוכנית נדרשה לעדכן את הספריטים לאחר שכל שורה נמשכה למסך.
@Mark: 2600 בהחלט היו sprites חומרה.החומרה שלטה רק במיקום אופקי, אך ספריטים ב- 2600 אפשרו למשחקים לייצר משחקים שהיו צבעוניים בהרבה מכל מתחרותיה.


שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 4.0 עליו הוא מופץ.
Loading...