2157
Маленькі секрети Великої економіки
Чому 16 байтів достатньо, щоб зберегти гру, і інші дрібниці
П'ятдесят і сто років відтепер програмісти все ще мають таку ж проблему: вони пропустимуть кількість наявної пам'яті для реалізації все, що вони хочуть.
25 років тому, ігрові патрони містять 64-128 кілограмів пам'яті, але якось достатньо, щоб відповідати грі на десятки годин гри. Сьогодні 128 кілбайтів є розміром невеликого зображення JPEG, і який доступний в сучасному домашньому комп'ютері, в епоху Super Mario Bros. не сниться.
На часі була музика, звуки, хороша графіка. Так, деякі можуть бути зроблені за допомогою того, що вже в ігровій консолі або комп'ютері, але в основному повинні піти на різні трюки, щоб відповідати в цих скромних можливостей величезна кількість звуків, музики, анімації, зображень і ігрових алгоритмів. Як це зробити розробники тих років?
Головний секрет: ігри були написані на компіляторі, тобто необхідно практично безпосередньо вказувати на процесор, які операції повинні виконуватися. Це як причина, так і ефект: важко працювати на великих проектах, написаних на такому низькому рівні.
Ще одна маленька деталь: багато програмного забезпечення повинні бути написані таким чином, щоб він був редагований і виправлений іншим програмістом після того, як ви. Розробники ігор для Atari 2600, Sega Master System, NES і SNES, і навіть для пізніших консолей пізніх 90-х, таких як PlayStation 1 або Nintendo 64, не було нічого турбуватися про: чому б хтось поза командою знає, як працює продукт? Після релізу нічого не можна закріпити, патч на патроні не буде рулон. Навпаки це було бажано, щоб уникнути будь-яких хакерів, які випустили обманні системи, такі як Game Genie. Ігри мали майже повний контроль консолі без будь-яких операційних систем, тому для багатошарової архітектури немає необхідності, що набивається на всі сучасні продукти для поліпшення незалежності від програмного забезпечення та апаратного забезпечення.
Основні методи включають в себе максимальний результат коду, той же функціонал, який використовується і знову. Те ж саме з даними: AI, графіка, музика, звуки, тільки трохи змінено для створення ілюзії різноманітності. Ігри можуть генерувати код і дані, необхідні для виконання, але це зроблено знеболювання важко. Уникають незрівняні великі масиви. Вони часто записують власні бібліотеки.
До переваг 8-бітної адресної площі. Якщо ви хочете писати 3 біти, ви втратите лише 5, не 27, як на 32-розрядному процесорі. (При цьому, 64-розрядні програми майже завжди більше 32-бітних програм.) Трохима 16 кольорів не займає багато місця, блок 20 × 20 пікселів зажадає тільки 1⁄2 × 20 × 20 = 200 байтів. У одному циклі процесора можна обробити 2 пікселів.
Графіка була низькою роздільною здатністю і двовимірною. Але можна було засвоювати відчуття з псевдо-3D або 2.5D. Найвідоміша модель 2.5D - 1984 Радний Racer. The 1992 Lotus Esprit Challenge (праворуч) є досить чуйним.
р.
2.5D елементи відомі першочергові пагони Doom і Wolfenstein 3D. Поїзд: Втеча до Нормандії (1987) для Commodore 64
Музика була створена на літа, вона не зберігалася в записаній формі - для неї просто не буде достатньо місця. Іноді були винятки, але вони тільки ілюструють недосвідченість для того, щоб зберегти звуки гри у вигляді аудіозапису. Уосьма частина 512-kilobyte Sonic the Hedgehog патрон, сама перша гра серії синього їжака з 1991 року, приймала цей звук, що триває один або два секунди. Для того, щоб ім'я видавця була відтворена на старті.
Прикладом такої музики є формат MIDI, хоча ігри часу працювали на значно меншому рівні. Замість нот використовується порядок візерунків, що вимагає значно менше пам'яті. Ось приклад того, що ви можете зробити з одноплатним звуком.
The Legend of Zelda, перший з легендарних серіалів про летючого хлопчика в зеленій шапці, за 1986 рік був величезною грою, яка навіть мала підійти на дорогий картриджі стільки, скільки 128 кілограмів. Сьогодні цей малюнок звучить смішно, але гра дійсно велика: він складається з одного великого суперсвіту і двох темних тем, кожен з яких був двічі розміром суперсвіту. Зображення натискаються.
Перший трюк відразу видно: від стандартної сітки буде віджимати максимум. Підземелля складається з 16 × 16 = 256 екранів, суперсвіт 16 × 8 = 128. Таким чином, дані, на яких екран є Link, підходять в одному байті: 4 біти для кожного з координат, в той час як для світу один з біт не використовувався. Цікаво, що другий підземелля синій район у вигляді літери L не вписується в простір, виділене до нього, тому його додаткові два екрани розташовані зліва.
Якщо ви уважно дивитесь, кожен екран є матрицею. Секрани над світом і темземцями лікувалися по-різному. На екрані над світом знаходиться сітка 16х11 плиток, кожен з яких може бути земля, пісок, камінь, кущ, вода, водоспад, могильник, сходи, міст / гавань, люка або отвір в стіні, плюс кілька варіантів спеціальних прикрас - дерева і в'їздів до підземелля, які лікувалися особливим чином.
Крім землі, не використовували більше 3 плитки, тому два байти, розбиті на 4-бітні гальки, досить зберігати інформацію про те, які види плитки повинні бути на екрані. Кожна плитка вимагає лише 2 біти даних. В результаті кожен екран вимагає 44 байти даних (і два байти для зберігання інформації про використовувану плитку). В цілому суперсвіт підходить всього за 6 кілограмів.
Більшість екранів використовують білий, коричневий або зелений, і деякі коричневі на зелені, зелені на коричневому або білому на коричневому. Два кольори можна використовувати в якості кольору зовнішньої рами і кольором внутрішніх елементів. Тільки 6 варіантів, які підходять в трьох бітах або нібеля (гальф байт).
Кожен з темних кімнат – 12х7 сітківка вмісту. Але цей простір був вирізаний особливим чином: майже всі номери, крім спеціальних (вхідів, кінцевих номерів та інших) не більше одного типу бар'єру. Це означає, що зберігати всю інформацію потрібно тільки трохи за плитку, байт за стовпчик і 12 байтів за номер.
У нас є 12 додаткових біт. Вам необхідно зберігати інформацію про кожну з стін (звідти, 3 види дверей, точку для бомби, протяжний прохід). 6 варіантів × 4 стіни = 24, що, все підходить в 5 біт. Крім того, необхідно зберігати інформацію про тип бар'єру: камінь, статуя, вода / lava, пісок або смарагість, яка займає 3 біти. Останні 4 біти визначають колірну гамму приміщення. Кожна колірна гамма визначається байтом (2 варіанти 16 кольорів).
Отже, для зберігання всього світу гри через багато хитрощів, деякі кілограми йдуть.
Консервація також є прикладом різних хитрощів. 4 біти використовуються для зберігання інформації про бомби, друга половина байта використовується для зберігання інформації про кількість ключів (до 7). Стрілки і гроші використовують однакову номінальну вартість, тому кожен постріл 255 можливих витрат. Вся опція виділена для зберігання інформації про кількість штук Trifors, так як необхідно враховувати порядок їх збору.
Є 8 скарбів у використанні, але один має три рівні і інші два рівні. Є 6 "пасних" скарбів, які, наприклад, дозволяють пересуватися на воді або перемістити важкі камені, і один з них також має два рівні. Нарешті, посилання може мати або бронза, білий, або чарівний меч, або він може бути незрівняний. В цілому, можна мати 22 різних елементів в інвентарі, які зажадають 3 байти в магазин, але залишаться стільки, скільки 2 біт.
Ви можете мати до 16 контейнерів серця (4 біт) з різним рівнем зайнятості (4 біт). Половина серця вважається одним з решти біт від інвентаризації. Нарешті, перший квест може бути завершений або ні, що вимагає іншого біту.
У шести бітах ви можете встановити 26 літер, 10 цифр і декількох спеціальних символів. В якості 8 символів зарезервовані на ім'я збереження, які зберігаються в 6 байтах. Японська версія мала використовувати повний спектр ASCII, тому є максимальна довжина 6 символів. Byte переходить в координацію екрана у вищевказаному світі або темземелля, один,байт на інші різні дані.
Таким чином, збереження гри підходить в 16 байтах.Це не просто збереження, він підписаний текстом. Для порівняння цього простору достатньо для 8 циліндричних символів в UTF-8. І сьогодні розробники ігор дуже багато, щоб вмістити свої заощадження в кластери файлової системи, але 16 байтів є просто помилкою для сучасного програмного забезпечення та передачі даних.
Для PlayStation 1 також мали свої особливості. оперативна пам'ять була основною проблемою, потім – тільки консоль мала 2 мегабайти пам'яті, тому довелося піти божевільні кроки. На рівні з більш ніж 10 мегабайтів даних, які повинні бути завантажені динамічно, уникаючи частоти кадрів нижче 30 Гц.
Щоб зробити це, було написано гарну сторінку системи swap, які завантажили шматки 64 кілограмів, як гравець прогресував через карту. Він був написаний таким чином, що навіть при швидкості приводу 300 кілограмів на секунду, все було завантажено часом, ігровий характер з'явився в даній області карти.
Для зберігання ігрових ресурсів (окреми, фактури, моделі, код) в цих шматках 64 кілограмів було написано упаковку утиліти. Деякі рівні ледь підходять, тому утиліта використовується в різних алгоритмах - першого вбрання, кращого вбрання та інших. Після розгляду декількох спроб було обрано оптимальний варіант. Проблема складалася тим, що з зміною дизайну рівня, змінилися можливості упаковки даних, що пов'язано з складністю математичного компонента процесу - це важко пояснити художникам, які раптом захотіли переокремити щось. Найбільша проблема залишалася оптимізацією коду на C і монтажнику, але в кінці все вписується в краватку — було всього 4 байти вільного простору від двох мегабайтів оперативної пам'яті.
1984 р. Відновлює автомобілебудування мало. Графіка гри дивиться як показано нижче. Велика частина екрана була виділена під рівномірно блакитною зоною неба.
Цей використовувався творцем гри British Jeff Crammond. Він використовував цю область даних відео пам'яті для зберігання досить великого шматка коду, для якого було дуже мало місця на BBC Micro. Ця область була пофарбована в синій, тому гравець не знає про це, якщо гра закінчилася помилкою - тоді екран був наповнений деякими видами сміття.
Багато з цих хитрощів все ще використовуються сьогодні, хоча потужність побутових комп'ютерів і ігрових консолей зросла на багатьох замовлень величини.
З нитки Quora.
Джерело: geektimes.ru/post/242152/
П'ятдесят і сто років відтепер програмісти все ще мають таку ж проблему: вони пропустимуть кількість наявної пам'яті для реалізації все, що вони хочуть.
25 років тому, ігрові патрони містять 64-128 кілограмів пам'яті, але якось достатньо, щоб відповідати грі на десятки годин гри. Сьогодні 128 кілбайтів є розміром невеликого зображення JPEG, і який доступний в сучасному домашньому комп'ютері, в епоху Super Mario Bros. не сниться.
На часі була музика, звуки, хороша графіка. Так, деякі можуть бути зроблені за допомогою того, що вже в ігровій консолі або комп'ютері, але в основному повинні піти на різні трюки, щоб відповідати в цих скромних можливостей величезна кількість звуків, музики, анімації, зображень і ігрових алгоритмів. Як це зробити розробники тих років?
Головний секрет: ігри були написані на компіляторі, тобто необхідно практично безпосередньо вказувати на процесор, які операції повинні виконуватися. Це як причина, так і ефект: важко працювати на великих проектах, написаних на такому низькому рівні.
Ще одна маленька деталь: багато програмного забезпечення повинні бути написані таким чином, щоб він був редагований і виправлений іншим програмістом після того, як ви. Розробники ігор для Atari 2600, Sega Master System, NES і SNES, і навіть для пізніших консолей пізніх 90-х, таких як PlayStation 1 або Nintendo 64, не було нічого турбуватися про: чому б хтось поза командою знає, як працює продукт? Після релізу нічого не можна закріпити, патч на патроні не буде рулон. Навпаки це було бажано, щоб уникнути будь-яких хакерів, які випустили обманні системи, такі як Game Genie. Ігри мали майже повний контроль консолі без будь-яких операційних систем, тому для багатошарової архітектури немає необхідності, що набивається на всі сучасні продукти для поліпшення незалежності від програмного забезпечення та апаратного забезпечення.
Основні методи включають в себе максимальний результат коду, той же функціонал, який використовується і знову. Те ж саме з даними: AI, графіка, музика, звуки, тільки трохи змінено для створення ілюзії різноманітності. Ігри можуть генерувати код і дані, необхідні для виконання, але це зроблено знеболювання важко. Уникають незрівняні великі масиви. Вони часто записують власні бібліотеки.
До переваг 8-бітної адресної площі. Якщо ви хочете писати 3 біти, ви втратите лише 5, не 27, як на 32-розрядному процесорі. (При цьому, 64-розрядні програми майже завжди більше 32-бітних програм.) Трохима 16 кольорів не займає багато місця, блок 20 × 20 пікселів зажадає тільки 1⁄2 × 20 × 20 = 200 байтів. У одному циклі процесора можна обробити 2 пікселів.
Графіка була низькою роздільною здатністю і двовимірною. Але можна було засвоювати відчуття з псевдо-3D або 2.5D. Найвідоміша модель 2.5D - 1984 Радний Racer. The 1992 Lotus Esprit Challenge (праворуч) є досить чуйним.
р.2.5D елементи відомі першочергові пагони Doom і Wolfenstein 3D. Поїзд: Втеча до Нормандії (1987) для Commodore 64
Музика була створена на літа, вона не зберігалася в записаній формі - для неї просто не буде достатньо місця. Іноді були винятки, але вони тільки ілюструють недосвідченість для того, щоб зберегти звуки гри у вигляді аудіозапису. Уосьма частина 512-kilobyte Sonic the Hedgehog патрон, сама перша гра серії синього їжака з 1991 року, приймала цей звук, що триває один або два секунди. Для того, щоб ім'я видавця була відтворена на старті.
Прикладом такої музики є формат MIDI, хоча ігри часу працювали на значно меншому рівні. Замість нот використовується порядок візерунків, що вимагає значно менше пам'яті. Ось приклад того, що ви можете зробити з одноплатним звуком.
The Legend of Zelda, перший з легендарних серіалів про летючого хлопчика в зеленій шапці, за 1986 рік був величезною грою, яка навіть мала підійти на дорогий картриджі стільки, скільки 128 кілограмів. Сьогодні цей малюнок звучить смішно, але гра дійсно велика: він складається з одного великого суперсвіту і двох темних тем, кожен з яких був двічі розміром суперсвіту. Зображення натискаються.
Перший трюк відразу видно: від стандартної сітки буде віджимати максимум. Підземелля складається з 16 × 16 = 256 екранів, суперсвіт 16 × 8 = 128. Таким чином, дані, на яких екран є Link, підходять в одному байті: 4 біти для кожного з координат, в той час як для світу один з біт не використовувався. Цікаво, що другий підземелля синій район у вигляді літери L не вписується в простір, виділене до нього, тому його додаткові два екрани розташовані зліва.
Якщо ви уважно дивитесь, кожен екран є матрицею. Секрани над світом і темземцями лікувалися по-різному. На екрані над світом знаходиться сітка 16х11 плиток, кожен з яких може бути земля, пісок, камінь, кущ, вода, водоспад, могильник, сходи, міст / гавань, люка або отвір в стіні, плюс кілька варіантів спеціальних прикрас - дерева і в'їздів до підземелля, які лікувалися особливим чином.
Крім землі, не використовували більше 3 плитки, тому два байти, розбиті на 4-бітні гальки, досить зберігати інформацію про те, які види плитки повинні бути на екрані. Кожна плитка вимагає лише 2 біти даних. В результаті кожен екран вимагає 44 байти даних (і два байти для зберігання інформації про використовувану плитку). В цілому суперсвіт підходить всього за 6 кілограмів.
Більшість екранів використовують білий, коричневий або зелений, і деякі коричневі на зелені, зелені на коричневому або білому на коричневому. Два кольори можна використовувати в якості кольору зовнішньої рами і кольором внутрішніх елементів. Тільки 6 варіантів, які підходять в трьох бітах або нібеля (гальф байт).
Кожен з темних кімнат – 12х7 сітківка вмісту. Але цей простір був вирізаний особливим чином: майже всі номери, крім спеціальних (вхідів, кінцевих номерів та інших) не більше одного типу бар'єру. Це означає, що зберігати всю інформацію потрібно тільки трохи за плитку, байт за стовпчик і 12 байтів за номер.
У нас є 12 додаткових біт. Вам необхідно зберігати інформацію про кожну з стін (звідти, 3 види дверей, точку для бомби, протяжний прохід). 6 варіантів × 4 стіни = 24, що, все підходить в 5 біт. Крім того, необхідно зберігати інформацію про тип бар'єру: камінь, статуя, вода / lava, пісок або смарагість, яка займає 3 біти. Останні 4 біти визначають колірну гамму приміщення. Кожна колірна гамма визначається байтом (2 варіанти 16 кольорів).
Отже, для зберігання всього світу гри через багато хитрощів, деякі кілограми йдуть.
Консервація також є прикладом різних хитрощів. 4 біти використовуються для зберігання інформації про бомби, друга половина байта використовується для зберігання інформації про кількість ключів (до 7). Стрілки і гроші використовують однакову номінальну вартість, тому кожен постріл 255 можливих витрат. Вся опція виділена для зберігання інформації про кількість штук Trifors, так як необхідно враховувати порядок їх збору.
Є 8 скарбів у використанні, але один має три рівні і інші два рівні. Є 6 "пасних" скарбів, які, наприклад, дозволяють пересуватися на воді або перемістити важкі камені, і один з них також має два рівні. Нарешті, посилання може мати або бронза, білий, або чарівний меч, або він може бути незрівняний. В цілому, можна мати 22 різних елементів в інвентарі, які зажадають 3 байти в магазин, але залишаться стільки, скільки 2 біт.
Ви можете мати до 16 контейнерів серця (4 біт) з різним рівнем зайнятості (4 біт). Половина серця вважається одним з решти біт від інвентаризації. Нарешті, перший квест може бути завершений або ні, що вимагає іншого біту.
У шести бітах ви можете встановити 26 літер, 10 цифр і декількох спеціальних символів. В якості 8 символів зарезервовані на ім'я збереження, які зберігаються в 6 байтах. Японська версія мала використовувати повний спектр ASCII, тому є максимальна довжина 6 символів. Byte переходить в координацію екрана у вищевказаному світі або темземелля, один,байт на інші різні дані.
Таким чином, збереження гри підходить в 16 байтах.Це не просто збереження, він підписаний текстом. Для порівняння цього простору достатньо для 8 циліндричних символів в UTF-8. І сьогодні розробники ігор дуже багато, щоб вмістити свої заощадження в кластери файлової системи, але 16 байтів є просто помилкою для сучасного програмного забезпечення та передачі даних.
Для PlayStation 1 також мали свої особливості. оперативна пам'ять була основною проблемою, потім – тільки консоль мала 2 мегабайти пам'яті, тому довелося піти божевільні кроки. На рівні з більш ніж 10 мегабайтів даних, які повинні бути завантажені динамічно, уникаючи частоти кадрів нижче 30 Гц.
Щоб зробити це, було написано гарну сторінку системи swap, які завантажили шматки 64 кілограмів, як гравець прогресував через карту. Він був написаний таким чином, що навіть при швидкості приводу 300 кілограмів на секунду, все було завантажено часом, ігровий характер з'явився в даній області карти.
Для зберігання ігрових ресурсів (окреми, фактури, моделі, код) в цих шматках 64 кілограмів було написано упаковку утиліти. Деякі рівні ледь підходять, тому утиліта використовується в різних алгоритмах - першого вбрання, кращого вбрання та інших. Після розгляду декількох спроб було обрано оптимальний варіант. Проблема складалася тим, що з зміною дизайну рівня, змінилися можливості упаковки даних, що пов'язано з складністю математичного компонента процесу - це важко пояснити художникам, які раптом захотіли переокремити щось. Найбільша проблема залишалася оптимізацією коду на C і монтажнику, але в кінці все вписується в краватку — було всього 4 байти вільного простору від двох мегабайтів оперативної пам'яті.
1984 р. Відновлює автомобілебудування мало. Графіка гри дивиться як показано нижче. Велика частина екрана була виділена під рівномірно блакитною зоною неба.
Цей використовувався творцем гри British Jeff Crammond. Він використовував цю область даних відео пам'яті для зберігання досить великого шматка коду, для якого було дуже мало місця на BBC Micro. Ця область була пофарбована в синій, тому гравець не знає про це, якщо гра закінчилася помилкою - тоді екран був наповнений деякими видами сміття.
Багато з цих хитрощів все ще використовуються сьогодні, хоча потужність побутових комп'ютерів і ігрових консолей зросла на багатьох замовлень величини.
З нитки Quora.
Джерело: geektimes.ru/post/242152/
