diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index aa3d5502..657d733b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -194,6 +194,7 @@ Field | Purpose `title` | Full page title shown in the page header and metadata (do not use colons! as it messes with the yaml frontmatter) `category` | Main site grouping such as the games console name or others such as `leak`, `introduction`, `gameengines`, `maths`, or another section-specific category. This can be a single value (`category: leak`) or a list (`category: [leak, snes]`) when a page belongs to multiple categories. `image` | Optional main preview image used by the page and site cards, if there is not a unique one leave it blank and it will be generated based on the category and title, for new pages leave blank (don't include) +`placeholderimages` | Optional list of local repo image paths to blend into the generated placeholder/social image when `image` and `twitterimage` are omitted `twitterimage` | Absolute URL version of the preview image for social sharing, leave blank and it will be generated, if in doubt leave blank (avoid using but don't remove) `permalink` | Final public path for the page (do not end with a trailing `/`; that is legacy format we are moving away from) `breadcrumbs` | Breadcrumb trail shown at the top of the page diff --git a/_config.yml b/_config.yml index 315b0d52..0a3a238e 100644 --- a/_config.yml +++ b/_config.yml @@ -163,7 +163,7 @@ category: image: /public/consoles/Sega Game Gear.png "games": title: Games - image: /public/images/RetroReversingLogoSmall.png + image: /public/consoles/Games.png "gba": title: Nintendo Game Boy Advance image: /public/consoles/Nintendo Game Boy Advance.png @@ -184,7 +184,7 @@ category: image: /public/consoles/Hardware.png "incomplete": title: Incomplete - image: /public/images/RetroReversingLogoSmall.png + image: /public/consoles/PC.png "industry": title: Industry image: /public/consoles/Magazine.png @@ -193,7 +193,7 @@ category: image: /public/consoles/Intellivision.png "introduction": title: Introduction - image: /public/consoles/PC.png + image: /public/consoles/Introduction.png "jaguar": title: Atari Jaguar image: /public/consoles/Atari Jaguar.png diff --git a/_includes/placeholder-post-image.html b/_includes/placeholder-post-image.html index 927cbca5..b6e91821 100644 --- a/_includes/placeholder-post-image.html +++ b/_includes/placeholder-post-image.html @@ -11,17 +11,29 @@ {% else %} {% assign placeholder_category = placeholder_category_raw %} {% endif %} + {% assign placeholder_custom_image_raw = include.post.placeholderimages %} + {% assign placeholder_custom_image_json = placeholder_custom_image_raw | jsonify %} + {% if placeholder_custom_image_json contains '[' %} + {% assign placeholder_custom_image = placeholder_custom_image_raw | first %} + {% else %} + {% assign placeholder_custom_image = placeholder_custom_image_raw %} + {% endif %} {% assign placeholder_category_meta = site.category[placeholder_category] %} {% if placeholder_category_meta == nil %} {% assign placeholder_category_meta = site.category[placeholder_category | downcase] %} {% endif %} {% assign placeholder_category_image = placeholder_category_meta.image %} {% assign placeholder_category_title = placeholder_category_meta.title | default: placeholder_category | replace: '-', ' ' %} + {% assign placeholder_display_image = placeholder_custom_image | default: placeholder_category_image %} + {% assign placeholder_display_alt = placeholder_category_title | default: include.post.title %} + {% if placeholder_custom_image %} + {% assign placeholder_display_alt = include.post.title %} + {% endif %}
{% if placeholder_category %} - {% if placeholder_category_image and placeholder_category_image != '/public/images/RetroReversingLogoSmall.png' %} - {{ placeholder_category_title }} + {% if placeholder_display_image and placeholder_display_image != '/public/images/RetroReversingLogoSmall.png' %} + {{ placeholder_display_alt }} {% endif %} {{ placeholder_category_title }} diff --git a/categories/consoles/GameBoy.md b/categories/consoles/GameBoy.md index e8df051e..230ce59e 100644 --- a/categories/consoles/GameBoy.md +++ b/categories/consoles/GameBoy.md @@ -35,6 +35,7 @@ This page serves two roles. It groups the RetroReversing posts related to the Ga ## Quick Technical Reference The quick reference below is useful when choosing an emulator, debugger, or disassembly target: + Property | Notes ---|--- CPU | Sharp LR35902, an 8-bit CPU with `i8080` and Z80 ancestry @@ -64,11 +65,11 @@ If you want to work from recreated board-level documentation, Gekkio's schematic {% include link-to-other-site.html url="https://github.com/Gekkio/gb-schematics/blob/master/MGB-xCPU/schematic/MGB-xCPU.pdf" description="Recreated schematics for the Game Boy Pocket CPU board, useful for tracing signals and understanding hardware level behaviour." title="Game Boy Pocket Hardware Schematics" %} ## The Ultimate Game Boy Talk -This talk is still one of the best broad introductions to the hardware and the programming model, especially if you want one long-form overview before drilling into specific subsystems: +The video below is still one of the best broad introductions to the hardware and the programming model, especially if you want one long-form overview before drilling into specific subsystems: ## The Game Boy, a hardware autopsy -These two videos are worth keeping together because they focus more on the physical hardware itself than the higher-level architectural write-ups above: +These two videos are worth keeping together because they focus on the physical hardware itself rather than the higher-level architectural write-ups above: @@ -124,7 +125,6 @@ Some game-specific anecdotes are worth keeping because they point to development ## Alien 3 `Alien 3` is a useful reminder of how compressed licensed handheld schedules could be. Jas Austin has said the Game Boy version was written in about five weeks [^1]. -The Game Boy game **Alien 3** was written in only 5 weeks by legendary game programmer **Jas Austin**: ## R-Type @@ -134,7 +134,7 @@ He also described being hired after showing a one-week demo to B.I.T.S, which is -The company **B.I.T.S** obtained the license to develop the Game Boy version of the game but required a programmer to work on the title. **Jas Austin** heard about this through his agency and travelled to London to meet up, he impressed them so much that he was given a development kit and a deadline of a week to come up with a demo! He did such a good job he got a permanent job at **B.I.T.S** [^1]. +The company **B.I.T.S** obtained the license to develop the Game Boy version of the game but required a programmer to work on the title. **Jas Austin** heard about this through his agency and travelled to London to meet up, he impressed them so much that he was given a development kit and a deadline of a week to come up with a demo. He did such a good job he got a permanent job at **B.I.T.S** [^2]. @@ -156,12 +156,12 @@ Nintendo released a Japanese accessory called the Mobile Adapter GB which connec {% include link-to-other-site.html url="https://xcellerator.github.io/posts/tetsuji/" description="TheXcellerator explains how the Mobile Adapter GB works and how it was turned into a route for running custom code years after release." title="Tetsuji - Remote Code Execution on a Game Boy Colour 22 Years Later" %} ## Super Game Boy -The Super Game Boy is important because it effectively embeds Game Boy hardware inside a Super Nintendo cartridge, creating a hybrid environment with its own timing and presentation quirks: +The video below explains how the Super Game Boy embeds Game Boy hardware inside a Super Nintendo cartridge, creating a hybrid environment with its own timing and presentation quirks: {% include link-to-other-site.html url="https://www.youtube.com/watch?v=uaeLY441Fwc" description="A video overview of the Super Game Boy hardware and how Nintendo adapted the handheld for television output." title="Super Game Boy Overview" %} ## Wide Boy 64 -The **Wide Boy 64** was an official but non-retail device used by developers and press to run Game Boy and Game Boy Advance software through an N64 based setup: +The video below covers the **Wide Boy 64**, an official but non-retail device used by developers and press to run Game Boy and Game Boy Advance software through an N64 based setup: {% include link-to-other-site.html url="https://www.youtube.com/watch?v=llIz6qjDfLc" description="An overview of the Wide Boy 64 and why it matters as a rare Nintendo evaluation and capture device." title="Wide Boy 64 Overview" %} @@ -175,13 +175,15 @@ The **GB Booster** was an unlicensed Nintendo 64 accessory in the same broad spa ## Datel Game Booster and GameStudio -Datel also shipped PlayStation accessories for running Game Boy software, including the PlayStation Game Booster and the later `GameStudio` for PlayStation 2: +The video below shows Datel's PlayStation Game Booster: -![Datel GameStudio](https://github.com/RetroReversing/retroReversing/assets/40120498/9026fc2e-7577-447d-94ee-e1643e97aa11) + +The Image below shows the later `GameStudio` accessory for PlayStation 2 also by Datel: +Datel GameStudio ## Dance Dance Revolution Controller for GBC Konami's `Dance Dance Revolution` controller for the Game Boy Color is a useful example of how far the accessory ecosystem stretched beyond normal link cable peripherals: -![Dance Dance Revolution Controller for GBC](https://github.com/RetroReversing/retroReversing/assets/40120498/5de18708-4006-471f-88f4-3864f6a7f34a) +Dance Dance Revolution Controller for GBC --- # Sound @@ -193,9 +195,9 @@ The audio hardware is one of the most technically interesting parts of the platf {% include link-to-other-site.html url="http://www.righto.com/2020/05/reverse-engineering-audio-chip-in.html" description="A transistor level analysis of the Game Boy Color audio amplifier chip, including die photos, schematic reconstruction, and analogue behaviour." title="Reverse Engineering the Audio Amplifier Chip in the Nintendo Game Boy Color" %} -## Synthic: Automatically generate gameboy music using machine learning -This is a very interesting project that played a large set of gameboy games in a custom headless emulator and tracked the audio registers into a text format. They then trained a Machine Learning algorithm on that audio data and used it to generate completely new Game Boy Music! Check it out here: -[jawline/Synthic: Automatically generate gameboy music using machine learning](https://github.com/jawline/Synthic) +## Synthic +`Synthic` played a large set of Game Boy games in a custom headless emulator and tracked the audio registers into a text format. That data was then used to train a machine learning model to generate new Game Boy music: +{% include link-to-other-site.html url="https://github.com/jawline/Synthic" description="A project that records Game Boy audio register activity from emulated play sessions and uses that data to generate new music." title="Synthic" %} --- # Tools and File Formats @@ -209,7 +211,7 @@ Start here if you want a broader survey of Game Boy file structures before drill When dealing with homebrew or unlabeled ROM sets, `gbtoolsid` is a practical first pass because it can often identify the toolchain used to build a Game Boy ROM: {% include link-to-other-site.html url="https://github.com/bbbbbr/gbtoolsid" description="A command line utility for identifying which tools or engines were likely used to build a Game Boy ROM." title="gbtoolsid" %} -### DMG-palette-patcher +## DMG-palette-patcher [MrBlinky](https://github.com/MrBlinky/DMG-palette-patcher) has released a Python tool for patching Original Game Boy (DMG) ROMs to use specific color palettes when played on a Game Boy Color. The script works by modifying the ROM's header-specifically the license code and title checksum-to trick the Game Boy Color's boot ROM into automatically selecting one of 45 built-in color palettes, such as the classic grey theme, rather than the default blue-greenish hues. {% include link-to-other-site.html url="https://github.com/MrBlinky/DMG-palette-patcher" description="MrBlinky has released DMG-palette-patcher, a tool that modifies Game Boy ROM headers to trigger specific built-in color palettes on the Game Boy Color." title="DMG-palette-patcher by MrBlinky" %} diff --git a/categories/games/Games.md b/categories/games/Games.md index 07720d25..8d421f2d 100644 --- a/categories/games/Games.md +++ b/categories/games/Games.md @@ -1,7 +1,9 @@ --- permalink: /games layout: post -category: games +category: +- games +- introduction title: Games specific posts breadcrumbs: - name: Home @@ -38,8 +40,25 @@ We have a specific post that aggregates all our posts on games with debug symbol {% include_cached link-to-other-post.html post="/symbols" %} +--- +# Arcade Games +This section collects our arcade game-specific posts: + +### Batman Forever - The Arcade Game +This post covers the arcade version of **Batman Forever**, focusing on the game itself rather than the wider Midway arcade hardware family. +{% include_cached link-to-other-post.html post="/batman-forever" %} + --- # NES Games +This section collects our NES game-specific posts and source code investigations: + +### Super Mario Bros +This post covers reverse engineering work on the original **Super Mario Bros** for the NES, including analysis and tooling around one of the most studied 8-bit platformers. +{% include_cached link-to-other-post.html post="/super-mario-bros" %} + +### Home Alone 2 +This post covers the recovered **Home Alone 2** NES source code and explains what survives in the archive for researchers interested in late-era commercial NES development. +{% include_cached link-to-other-post.html post="/home-alone-2-nes-source-code" %} ## The Final Fantasy Battle Engine: A Dissection of Physical Attacks [Displaced Gamers](https://www.youtube.com/watch?v=O_CLnBCgJks) has an excellent video dissecting the underlying code, hidden math, and bugs governing physical attacks in the original NES Final Fantasy. The video explores how battle stats like accuracy, critical hit rates, and elemental weaknesses are processed in Assembly, revealing several programming oversights that heavily impact gameplay. It provides a fascinating look into early RPG mechanics and console game reverse engineering. @@ -77,6 +96,136 @@ Critical Engine Bugs & Logic Errors: * **Player Element Nullification:** Weapons with elemental attributes (e.g., Flame Sword) fail to trigger elemental damage bonuses because the combat routine queries the *player character's* element variable (which is nonexistent/null) instead of the *equipped weapon's* variable. * **Stun/Sleep Accuracy Omission:** When an attack target is under Stun or Sleep status, the attacker correctly receives a +25% attack power bonus. However, the logic jump bypasses the instruction to apply the attacker's accuracy stat entirely, locking the base hit chance at a fixed `84%` (168 base / 200). +--- +# Game Boy Games +This section collects our Game Boy game-specific posts and source code investigations: + +### Pokemon Red and Blue +This post covers reverse engineering **Pokemon Red and Blue** on the Game Boy, including community reconstruction work and related historical material about the games' development. +{% include_cached link-to-other-post.html post="/pokemonredblue" %} + +### Pokemon Original Source Code Leak +This post covers the leaked original **Pokemon** source material and explains what it reveals about the early Game Boy-era codebase and development process. +{% include_cached link-to-other-post.html post="/pokemon-original-source-code" %} + +### Zelda Link's Awakening +This post covers the leaked original **The Legend of Zelda: Link's Awakening** Game Boy source code and the value of the archive for studying Nintendo's handheld development workflow. +{% include_cached link-to-other-post.html post="/zelda-links-awakening" %} + +--- +# Game Boy Color Games +This section collects our Game Boy Color game-specific posts: + +### Zelda Link's Awakening DX +This post covers the **Link's Awakening DX** source code materials, showing how the Game Boy Color revision differs from the earlier monochrome release. +{% include_cached link-to-other-post.html post="/zelda-links-awakening-dx" %} + +--- +# Super Nintendo Games +This section collects our Super Nintendo game-specific posts and source code investigations: + +### F-Zero +This post covers the leaked **F-Zero** source code and what it shows about early Super Famicom launch-era game development. +{% include_cached link-to-other-post.html post="/f-zero-source-code" %} + +### Super Mario Kart +This post covers the leaked **Super Mario Kart** source code and the surrounding development files that help document Nintendo's Mode 7 racing workflow. +{% include_cached link-to-other-post.html post="/super-mario-kart-source-code" %} + +### Super Mario Collection / All-Stars +This post covers the source archive for **Super Mario Collection / Super Mario All-Stars**, including how Nintendo adapted earlier NES titles for the Super Nintendo. +{% include_cached link-to-other-post.html post="/super-mario-collection-source-code" %} + +### Star Fox +This post covers the leaked original **Star Fox** source code and the technical context around Nintendo and Argonaut's early polygon pipeline. +{% include_cached link-to-other-post.html post="/star-fox-source-code" %} + +### Star Fox 2 +This post covers the leaked **Star Fox 2** source code and the unfinished but historically important state of the project. +{% include_cached link-to-other-post.html post="/star-fox-2-source-code" %} + +### Wild Trax / Stunt Race FX +This post covers the leaked source code for **Wild Trax / Stunt Race FX**, a useful case study for Super FX-powered racing technology on the SNES. +{% include_cached link-to-other-post.html post="/wild-trax-source-code" %} + +### Yoshi's Island +This post covers the leaked **Yoshi's Island** source code and the implementation details behind one of Nintendo's most visually distinctive 2D platformers. +{% include_cached link-to-other-post.html post="/yoshis-island-source-code" %} + +### The Legend of Zelda - A Link to the Past +This post covers the leaked **A Link to the Past** source code and its importance for understanding large-scale first-party Super Nintendo game development. +{% include_cached link-to-other-post.html post="/zelda-a-link-to-the-past-source-code" %} + +--- +# GameCube Games +This section collects our GameCube game-specific posts: + +### 007 Agent Under Fire +This post covers reverse engineering work on the GameCube version of **007 Agent Under Fire**, with attention to the game's own binaries and assets. +{% include_cached link-to-other-post.html post="/007-agent-under-fire" %} + +--- +# Nintendo 64 Games +This section collects our Nintendo 64 game-specific posts and source code investigations: + +### Super Mario 64 +This post covers **Super Mario 64** reverse engineering, including tools, level work, and analysis tied to the best-known N64 decompilation effort. +{% include_cached link-to-other-post.html post="/super-mario-64" %} + +### Mario Kart 64 +This post covers **Mario Kart 64** specifically, gathering reverse engineering material around the game's code, assets, and mechanics. +{% include_cached link-to-other-post.html post="/mario-kart-64" %} + +### Turok 64 +This post covers the official **Turok** Nintendo 64 source code archive and explains what it reveals about a major commercial western N64 production. +{% include_cached link-to-other-post.html post="/turok64sourcecode" %} + +--- +# PlayStation 1 Games +This section collects our PlayStation 1 game-specific posts: + +### Crash Bandicoot +This post covers the original **Crash Bandicoot** on PlayStation 1, including reverse engineering notes and development context around Naughty Dog's early PS1 technology. +{% include_cached link-to-other-post.html post="/crash-bandicoot" %} + +--- +# Dreamcast Games +This section collects our Dreamcast game-specific posts and source code investigations: + +### Chicken Run +This post covers the recovered **Chicken Run** Dreamcast source code and what it shows about licensed late-era Dreamcast game production. +{% include_cached link-to-other-post.html post="/Chicken-Run-Source-Code" %} + +--- +# PlayStation Portable Games +This section collects our PSP game-specific posts: + +### Saints Row Undercover +This post covers the PSP prototype of **Saints Row Undercover**, including its unusual release history and what can be learned from the surviving build. +{% include_cached link-to-other-post.html post="/psp-saints-row-undercover" %} + +--- +# Multi-platform Games +This section collects game-specific posts that span multiple retail platforms: + +### The Simpsons Hit & Run +This post covers the **Simpsons Hit & Run** source code leak, which is relevant across multiple released platforms rather than belonging to a single console family. +{% include_cached link-to-other-post.html post="/simpsons-hit-and-run-source-code" %} + +--- +# PC Games +This section collects our PC game-specific posts and source code investigations: + +### Planet X3 +This post covers **Planet X3**, a modern MS-DOS strategy game whose tooling and technical design make it relevant to retro PC development research. +{% include_cached link-to-other-post.html post="/planet-x3-dos" %} + +## Deponia Magnet Puzzle Soft-Lock Fix +[Nathan Baggs](https://www.youtube.com/watch?v=lT4McPl5kQU) has a detailed video breakdown about reverse engineering a persistent, game-breaking bug in the point-and-click adventure game **Deponia**. The investigation covers diagnosing a magnet puzzle soft-lock using tools like Ghidra, x64dbg, and RenderDoc to analyze memory and engine behavior. +By discovering an embedded Lua debugger (**mobdebug**) and decompiling the game's bytecode (**LuaJit**), the root cause-a failure to initialize condition states upon reloading-is identified and resolved via custom Lua code injection. + + + --- # All Posts related to Specific Games diff --git a/codex/skills/retroreversing-category-pages/SKILL.md b/codex/skills/retroreversing-category-pages/SKILL.md index 1da88b84..a7fb1622 100644 --- a/codex/skills/retroreversing-category-pages/SKILL.md +++ b/codex/skills/retroreversing-category-pages/SKILL.md @@ -4,30 +4,19 @@ description: "Use when creating or editing RetroReversing category hub pages und --- # RetroReversing Category Pages - Category pages live in `categories/**` and publish to a top-level permalink like `/nes`, `/wiiu`, `/disassemblers`, or `/gdc`. They have two jobs: - * act as the hub/index for a topic (usually a console/tool/company), linking to relevant RetroReversing posts * curate high-quality external sources so the page stands alone as a reference If you are not editing `categories/**`, use the broader `retroreversing-contributing` skill instead. -## Identify the category page type - -Pick the smallest structure that fits: - -* **Hub (preferred for new pages):** short intro + organised internal links + a small curated external list. -* **Reference list:** mostly tables of resources grouped by subtopic. -* **Timeline/index:** lots of items grouped by year/event (example: `categories/misc/GDC.md`). - ## Editing Rules * When extending an older, very large page, avoid sweeping rewrites. Preserve stable headings and refactor incrementally. * Do not remove existing embedded content such as videos, tweets, or other primary-source embeds unless the user explicitly asks for their removal. These embeds often preserve useful technical or historical context. You may move or regroup them into more appropriate sections. ## Frontmatter checklist (category pages) - Follow `CONTRIBUTING.md` frontmatter rules and keep it minimal. Required/typical keys: @@ -51,11 +40,11 @@ Useful/optional keys: * `image:` and `twitterimage:` only when you have a real hero image; otherwise omit ## Minimal starter template - Use this as a starting point for a new console hub page (adjust values; omit optional keys you do not need): ```yaml --- + layout: post permalink: /wiiu title: Nintendo Wii U Reverse Engineering @@ -79,6 +68,7 @@ editlink: ../categories/consoles/WiiU.md excerpt: Awesome list of Nintendo Wii U reverse engineering and dev resources updatedAt: "2026-04-12" --- + ``` Recommended heading skeleton: @@ -104,7 +94,6 @@ Recommended heading skeleton: ## Common H1 sections (recommended) - Across existing category pages (especially `categories/consoles/*.md`), the most common H1 sections are: * `# Introduction` @@ -137,7 +126,6 @@ Common optional H1 sections when the platform/topic needs them: ## Content structure (recommended) - For hub-style pages, follow the newer pattern seen in `categories/consoles/WiiU.md`: * 2-4 sentence **intro** explaining why the category matters and how to use the page. @@ -154,7 +142,6 @@ For hub-style pages, follow the newer pattern seen in `categories/consoles/WiiU. * Prefer short subsections that end in one or more links (internal or external), rather than long essay blocks. ## Console hub extras (NES-style) - `categories/consoles/Nes.md` is a good example of a *fully built-out* console hub. When a console category has enough material, these patterns work well: * **Lead-in before the first H1** - 2 short paragraphs that explain the two roles of the page (internal hub + curated external reference) and how the sections are organised. @@ -165,12 +152,12 @@ For hub-style pages, follow the newer pattern seen in `categories/consoles/WiiU. * `# Reverse Engineering games` Only add these if you have enough links/content to avoid thin sections. * **FAQ-style subheadings** - within an H1 section, use `###` question headings ("How long did it take…?", "What did the SDK look like?") to make the page skimmable; each answer should end in one or more links (internal or external). -* **Primary-source quote blocks** - short `>` quotes are useful for provenance and “why this matters”, backed by a footnote when the quote is evidence. +* **Primary-source quote blocks** - short `>` quotes are useful for provenance and "why this matters", backed by a footnote when the quote is evidence. * **Embedded media (sparingly)** - a teardown / explanation video, tweet, or other primary-source embed can be worth keeping when it teaches a hardware concept or preserves development context; keep the surrounding text tight and technical. * **Preserve existing embeds** - when editing an existing category page, keep embedded videos, tweets, and similar source material unless the user explicitly asks to remove them. Reorganising is fine, deletion is not. -* **Hands-on callouts** - include at least one concrete “try this” (emulator/debugger step, tool invocation, or a small workflow) when the console has established reversing tooling. +* **Hands-on callouts** - include at least one concrete "try this" (emulator/debugger step, tool invocation, or a small workflow) when the console has established reversing tooling. -If a console doesn’t have enough depth yet, prefer the simpler hub pattern (short intro + links + `# All Posts`) rather than forcing these extras. +If a console doesn't have enough depth yet, prefer the simpler hub pattern (short intro + links + `# All Posts`) rather than forcing these extras. Remember the Markdown hygiene rules from `CONTRIBUTING.md`: @@ -182,7 +169,6 @@ Remember the Markdown hygiene rules from `CONTRIBUTING.md`: * Use tables when a list would exceed ~10 items. ## Linking rules - Internal links (to other RetroReversing pages): ```liquid @@ -208,6 +194,9 @@ If its a YouTube video always have an embed and mention the author and content o ``` +## Tweet and Primary-source Embed Rules +If you keep or add an embedded tweet or other primary-source embed, include a short sentence before or after it explaining why it matters. Focus on the technical or historical value of the embed rather than leaving it to stand alone without context. + ## References If the page makes specific historical/technical claims (dates, counts, quotes), add footnotes and end with: `# References` diff --git a/pages/consoles/gameboy/PokemonRedBlue.md b/pages/consoles/gameboy/PokemonRedBlue.md index d7d9e5b3..efc213a8 100644 --- a/pages/consoles/gameboy/PokemonRedBlue.md +++ b/pages/consoles/gameboy/PokemonRedBlue.md @@ -5,8 +5,8 @@ tags: - games - assembly title: Reversing Pokemon Red and Blue (Game Boy) -image: /public/games/pokemonBludeBox.jpg -twitterimage: http://img.youtube.com/vi/0s3z1t5Li5A/0.jpg +placeholderimages: +- /public/games/pokemonBludeBox.jpg videocarousel: - title: Making of Pokemon Red image: http://img.youtube.com/vi/0s3z1t5Li5A/0.jpg @@ -32,7 +32,9 @@ breadcrumbs: url: /gameboy - name: Pokemon Red/Blue Assembly Code (Game Boy) url: # -recommend: gameboy +recommend: +- gameboy +- sourcecode editlink: /consoles/gameboy/PokemonRedBlue.md --- @@ -118,4 +120,3 @@ In the pokered source code the maps are saved as `.blk` files, these files are s [^4]: [The Making of Pokemon Red, Green and Blue - YouTube](https://www.youtube.com/watch?v=0s3z1t5Li5A) [^5]: [An Exclusive Look At Pokémon's Early Design Documents - YouTube](https://www.youtube.com/watch?v=9l8V_eQ6wGQ) [^6]: [What Dreams May Come: Prototype Data for Pokémon Red and Green – Helix Chamber](https://helixchamber.com/2019/02/16/what-dreams-may-come/) - diff --git a/pages/consoles/n64/N64MipsAssembly.md b/pages/consoles/n64/N64MipsAssembly.md index 6aea0e0c..c72f18fb 100644 --- a/pages/consoles/n64/N64MipsAssembly.md +++ b/pages/consoles/n64/N64MipsAssembly.md @@ -112,9 +112,9 @@ ECHO N64 GCC Command Prompt ## Repo Naming Conventions The repo uses simple file naming conventions to separate macros/constants from executable code: -* **`.asm`** - Main program file (entry point + top-level flow). -* **`.INC`** - Variables, constants, and macros (included as source). -* **`.S`** - Function bodies, often called via macros or `jal`. +* `.asm` - Main program file (entry point + top-level flow). +* `.INC` - Variables, constants, and macros (included as source). +* `.S` - Function bodies, often called via macros or `jal`. --- ## Workflow Automation @@ -359,7 +359,7 @@ Once you understand the explicit sequence, you can switch to the repo's macro in ScreenNTSC(320, 240, BPP16, $A010'0000) ``` -That macro writes the same VI registers, but it also documents what the “magic” constants mean (for example, the `VI_TIMING` and `VI_H_VIDEO` fields), which makes it a good long-term reference when you start changing resolution, origin, or scaling. +That macro writes the same VI registers, but it also documents what the "magic" constants mean (for example, the `VI_TIMING` and `VI_H_VIDEO` fields), which makes it a good long-term reference when you start changing resolution, origin, or scaling. ## The Flat Memory Map When the console boots, the BIOS places the [MIPS](#glossary-mips) processor into a 32-bit kernel mode. This provides a 4 Gigabyte (`0x00000000` to `0xFFFFFFFF`) address space. Even though 64-bit mathematics are available, memory addressing remains firmly in 32-bit. @@ -511,7 +511,7 @@ do_Store2Pixels: This is a good template for learning because the delay-slot instruction is a single real instruction (`addi`), not a pseudo-instruction like `li` or `la`, so it cannot expand into multiple instructions and accidentally break control flow. -## Pitfall: `sw` Writes Two Pixels in 16bpp Mode +## Pitfall: sw Writes Two Pixels in 16bpp Mode In `Video006/Video006.asm`, the color is loaded as `lui t0, LIGHT_BLUE16` but the matching `ori` is commented out. That means the lower 16 bits of the store are `0x0000`, so each `sw` writes one LIGHT_BLUE pixel and one black pixel. If you want each `sw` to write two identical 16bpp pixels, pack the color into both halfwords: diff --git a/pages/consoles/psp/PSPSDK.md b/pages/consoles/psp/PSPSDK.md index b34f3abc..be4ba585 100644 --- a/pages/consoles/psp/PSPSDK.md +++ b/pages/consoles/psp/PSPSDK.md @@ -460,7 +460,11 @@ Readme_Sample_Code_Data-Sound-English | .txt | Changelog for the Sound samples
/module
- This folder contains... + This folder contains the PSP runtime modules that ship with the SDK as `.prx` binaries. + These are loadable kernel or user-mode components rather than normal static libraries. + + The table below covers the 35 PRX modules present in the leaked SDK tree. + They include utility libraries, multimedia support such as `libpsmfplayer`, and small diagnostic modules such as `show_macaddr`.
@@ -502,10 +506,24 @@ libsha384 | .prx | Implements the SHA-384 hashing algorithm libsha512 | .prx | Implements the SHA-512 hashing algorithm. psmf | .prx | Provides core functionality for handling PSP Motion Format headers. pspnet_ap_dialog_dummy | .prx | Dummy module for PSP network access point dialogs. -scan | .prx | +scan | .prx | Performs scanning operations (e.g., QR codes or network). show_macaddr | .prx | Displays the device's MAC address. +## What is a PRX file? +On PSP, a PRX file is a relocatable module that the kernel loader can map into memory at runtime. +It is related to ELF, but it is packaged for the PSP module loader rather than as a plain standalone executable. + +That distinction matters because PRX files usually carry: +* **Imports and exports** - Function and variable linkage data so one module can call into another resident library +* **Module metadata** - The module name, attributes, version fields, and startup or shutdown entry points used by the loader +* **Relocations** - Fixups that let the loader place the module at a suitable address in memory + +In practice, a PSP build often starts from ordinary ELF objects and then converts them into PRX modules for loading on hardware or devkit targets. +That is why this SDK ships with tools such as `pspfixup`, `psplibgen`, `prxinfo`, and `psp-prx-strip`. +Those utilities handle PRX conversion, stub generation, inspection, and symbol stripping. + + --- @@ -612,11 +630,6 @@ Patch-Overview-English | .pdf | A patch system is provided that can add or repla Patch-Packaging-English | .pdf | PSP Patch Package Creation Guide Programming-Overview-English | .pdf | PSP Programming Tutorial -The PSP kernel loader can handle two types of object files. One is a relocatable object file format unique to the PSPTM kernel called a PRX file, and the other is a normal ELF executable object file. -Every module that is loaded in memory is identified by a unique 32-bit ID called a module ID. - -A PRX-format module can be used as a resident library. A resident library provides some of its functions to another module. - --- #### Debug_support (/document/pdf/debug_support)
@@ -2000,4 +2013,3 @@ File Name | Extension | Description Makefile | N/A | Used to build the source code in the folder (run make) PSP Samples | .sln | - diff --git a/pages/consoles/wiiU/WiiUNAND.md b/pages/consoles/wiiU/WiiUNAND.md index 59559e35..a42beddf 100644 --- a/pages/consoles/wiiU/WiiUNAND.md +++ b/pages/consoles/wiiU/WiiUNAND.md @@ -60,7 +60,7 @@ The NAND contains the **entire operating system stack**, including: * System firmware (menu, system services) * Security components (encryption keys, signature checks) -Without NAND, the console has **no instructions to execute**, so it cannot boot at all. Unlike systems that rely on removable storage, the Wii U’s internal NAND is mandatory for initialization. +Without NAND, the console has **no instructions to execute**, so it cannot boot at all. Unlike systems that rely on removable storage, the Wii U's internal NAND is mandatory for initialization. ### System updates and installed content System updates are written directly to NAND: @@ -99,7 +99,7 @@ The SLC contains the early boot stages: If anything here is corrupted, the console **cannot boot at all** (hard brick). ### IOSU (system operating environment) -The Wii U runs a subsystem similar to the Wii’s IOS, called **IOSU** which handles: +The Wii U runs a subsystem similar to the Wii's IOS, called **IOSU** which handles: * File system * Permissions * Hardware access @@ -124,7 +124,7 @@ This is one of the most important parts: * Certificates * Signing data used to verify software -These enforce Nintendo’s trust chain: +These enforce Nintendo's trust chain: * Every executable must be signed * Boot stages verify each other * Prevents unauthorized code execution @@ -221,7 +221,7 @@ This Leads to missing games, save data loss and installation failures but typica --- # Security and anti-piracy -The NAND plays a critical role in enforcing Nintendo’s security model: +The NAND plays a critical role in enforcing Nintendo's security model: * Stores **console-unique encryption keys** * Holds signed system titles verified during boot * Prevents unauthorized code execution diff --git a/pages/general/maths/Matrix.md b/pages/general/maths/Matrix.md index 8f0333f4..b8a5b880 100644 --- a/pages/general/maths/Matrix.md +++ b/pages/general/maths/Matrix.md @@ -34,9 +34,9 @@ A matrix is a table of numbers, but in game code the important part is what that Matrices let engines package translation, rotation, scale, camera transforms, and projection into a form that composes cleanly and applies efficiently to many points at once [^1][^2]. Matrices in games usually show up in three common shapes: -* **`3x3`** - Useful for rotation, scale, and basis changes when no translation is needed -* **`4x4`** - The standard choice for full 3D transforms because it can also encode translation and projection through homogeneous coordinates [^1] -* **`4x3`** - A compact affine form used by some SDKs, including the Nintendo DS, when projection is handled separately +* `3x3` - Useful for rotation, scale, and basis changes when no translation is needed +* `4x4` - The standard choice for full 3D transforms because it can also encode translation and projection through homogeneous coordinates [^1] +* `4x3` - A compact affine form used by some SDKs, including the Nintendo DS, when projection is handled separately Matrices are useful for: * **Model transforms** - Move a mesh from local space into world space @@ -54,6 +54,7 @@ If vectors are still new, it helps to read that page first because matrix math b --- ## Core Matrix Concepts + ### Identity matrix The identity matrix is the matrix equivalent of multiplying by `1`. Applying it leaves a vector unchanged, which is why it is the default starting point for many transform pipelines [^1]. @@ -184,9 +185,9 @@ That is why APIs that expose `Before` and `After` variants are useful: they make ### 3x3, 4x3, 4x4, and homogeneous coordinates In game math, matrix size usually tells you what kind of transform is being represented: -* **`3x3`** - Rotation, scale, or basis conversion only -* **`4x3`** - Affine 3D transform, usually rotation/scale plus translation, but not full projective math -* **`4x4`** - Full transform matrix, including projection [^1] +* `3x3` - Rotation, scale, or basis conversion only +* `4x3` - Affine 3D transform, usually rotation/scale plus translation, but not full projective math +* `4x4` - Full transform matrix, including projection [^1] The usual trick behind `4x4` matrices is homogeneous coordinates [^1]. Points get a final coordinate of `w = 1`, while pure directions use `w = 0`. diff --git a/pages/general/maths/Quaternions.md b/pages/general/maths/Quaternions.md index 7f852985..1bef637c 100644 --- a/pages/general/maths/Quaternions.md +++ b/pages/general/maths/Quaternions.md @@ -59,6 +59,7 @@ If you are new to rotation-heavy game math, these are the main terms worth keepi --- ## Core Quaternion Concepts + ### Why games use quaternions The big practical win is that quaternions treat orientation as one object instead of three loosely related angle channels [^1]. That makes them a better fit for camera systems, skeletal animation, aiming, and smooth turning. @@ -229,11 +230,11 @@ Unity is a useful modern reference point because it exposes the same operations It also makes the "tool UI versus engine storage" split very visible, because you often edit rotations in Euler form in the Inspector while `Transform.rotation` is stored as a quaternion internally [^1]. The most common Unity quaternion helpers are: -* **`Quaternion.AngleAxis`** - Build a rotation from an axis and angle [^2] -* **`Quaternion.Slerp`** - Blend smoothly between rotations [^3] -* **`Quaternion.Inverse`** - Compute the opposite rotation [^5] -* **`Quaternion.LookRotation`** - Build an orientation from `forward` and `up` vectors [^6] -* **`Quaternion.ToAngleAxis`** - Convert a quaternion back into axis-angle form [^7] +* `Quaternion.AngleAxis` - Build a rotation from an axis and angle [^2] +* `Quaternion.Slerp` - Blend smoothly between rotations [^3] +* `Quaternion.Inverse` - Compute the opposite rotation [^5] +* `Quaternion.LookRotation` - Build an orientation from `forward` and `up` vectors [^6] +* `Quaternion.ToAngleAxis` - Convert a quaternion back into axis-angle form [^7] [Unity](https://www.youtube.com/watch?v=hd1QzLf4ZH8) provides an intermediate-level tutorial that focuses on how these quaternion helpers appear in day-to-day engine scripting rather than only in pure math form. @@ -396,10 +397,10 @@ ScePspFVector4 *sceVfpuQuaternionToRotYXZ(ScePspFVector4 *pv, const ScePspFQuate {% include rr-tabs.html group="psp-quaternion-group" tabs=psp_quaternion_tabs %} The function names also give away several practical use cases [^10]: -* **`QuaternionApply`** - Rotate vectors directly, which is useful for camera basis vectors, aiming, and transforming local directions into world directions -* **`QuaternionInnerProduct`** - Another name for quaternion dot product, often used to measure orientation similarity or to support interpolation logic +* `QuaternionApply` - Rotate vectors directly, which is useful for camera basis vectors, aiming, and transforming local directions into world directions +* `QuaternionInnerProduct` - Another name for quaternion dot product, often used to measure orientation similarity or to support interpolation logic * **`QuaternionConj` and `QuaternionInverse`** - Expose the common "reverse this rotation" operations explicitly instead of forcing programmers to reconstruct them from scratch -* **`QuaternionFromRotate`** - Builds a quaternion from axis-angle input and normalizes the axis internally, which matches the mental model most developers start from +* `QuaternionFromRotate` - Builds a quaternion from axis-angle input and normalizes the axis internally, which matches the mental model most developers start from * **`QuaternionToRotZYX` and `QuaternionToRotYXZ`** - Convert back to Euler-style forms, and the source includes special handling near singular cases when extracting those angles The PSP header also makes it obvious that quaternion terminology varies. diff --git a/pages/tools/Unity3d_additions2.md b/pages/tools/Unity3d_additions2.md deleted file mode 100644 index 39c275b9..00000000 --- a/pages/tools/Unity3d_additions2.md +++ /dev/null @@ -1,198 +0,0 @@ ---- -layout: post -tags: -- gameengines -- middleware -- unity3d -title: Unity3d - History and Technology behind the engine -category: gameengines -permalink: /unity3d -breadcrumbs: - - name: Home - url: / - - name: Game Engines & Middleware - url: /engines - - name: Unity3d - url: # -recommend: -- middleware -- gameengines -- unity3d -editlink: /tools/Unity3d.md ---- - -# Unity 1.x Historical Overview (Versions 1.0 – 1.6) -Unity 1.x represents the earliest iterations of the Unity game engine, laying the foundation for its editor-centric workflow and multi-platform capabilities. Each minor release in the 1.x cycle introduced significant engine features, editor improvements, and new platform supports relevant to developers. - -Below is a version-by-version breakdown of major changes in Unity 1.0 through 1.6, focusing on engine-level features, Editor UI/UX enhancements, and other developer-facing improvements. - -## Unity 1.0 (June 2005) – Initial Launch on Mac OS X -![Unity 1.0](https://github.com/user-attachments/assets/ba40f015-1774-486f-bf97-25a33a63684f) - -- **Platform Support:** Unity 1.0 launched as a Mac OS X-exclusive engine, with the Unity Editor running only on Mac. It could publish games as standalone Mac OS X applications, as web-embedded applets (via a Mac-only browser plugin), or even as Dashboard Widgets for OS X Tiger [^1] [^2]. (At release, there was **no ability to build Windows executables** – that came later with Unity 1.1 [^2].) -- **Editor and Workflow:** Unity’s design was *editor-first* with a focus on ease of use. The Editor featured a GUI reminiscent of familiar content-creation tools (inspired by apps like Photoshop/Final Cut) to allow drag-and-drop asset import and WYSIWYG scene editing (“What You See Is What You Play” real-time preview) [^3]. This approach – editing in a unified viewport with immediate play testing – set Unity apart from other engines of the time which often lacked an integrated editor. -- **Scripting:** Unity 1.0 included an embedded **Mono runtime**, supporting **C# 1.1** and a custom JavaScript-like language (UnityScript) for game scripting [^1]. (Support for a Python-inspired language called **Boo** was also available in early Unity for .NET enthusiasts [^4].) Scripts were component-based and attached to GameObjects in the Editor. Developers could quickly iterate on gameplay using these high-level languages, which was a major selling point. -- **Engine Features:** Even in 1.0, Unity had a capable 3D engine with support for: - - **Physics:** Integration of the **Ageia PhysX** physics engine for rigidbody dynamics, collisions, and triggers (used to power gameplay in Unity’s demo game *GooBall* [^1]). Ragdoll physics (jointed body simulations) were possible via PhysX, though the tooling for ragdolls would be improved in later versions. - - **Rendering:** An OpenGL-based renderer on Mac supporting dynamic lights, particle systems, and basic shaders. Unity 1.0 allowed programmable shaders via “ShaderLab”, though the initial feature set was modest. Advanced effects like real-time shadows were not yet present (those would arrive in Unity 2.0). - - **Audio:** Basic audio playback support for 3D sound effects and music. -- **Other Features:** Unity 1.0 introduced the core **asset import pipeline** – support for common 3D formats, textures, etc., with updates reflected live in the Editor. It also supported version control of assets externally (though an integrated versioning solution came later). In essence, Unity 1.0 provided the minimal framework needed to build and play a 3D game on Mac, emphasizing a smooth workflow over cutting-edge graphics [^3]. - - -## Unity 1.1 (August 2005) – Windows Publishing & Extensibility -Released just a couple of months after 1.0, Unity 1.1 was a major update aimed at “democratizing” game deployment beyond the Mac: - -- **Windows Standalone Support:** For the first time, developers could deploy Unity games to Windows PCs with a single click [^2]. This opened up the much larger Windows audience. (Notably, this feature was part of Unity “Pro” – the paid tier – along with other high-end features.) -- **Rendering and Graphics:** Introduced several “next-gen” rendering capabilities: - - **Render-to-Texture Effects:** Unity 1.1 added support for camera effects that render to texture surfaces [^2]. This enabled techniques like reflections, refractions, video playback to textures, and other shader-based effects that were previously Pro-only. (Render-to-texture was mentioned as a Pro feature even in 1.0, but 1.1 expanded on it with new effects [^1].) - - **Virtual Displacement Mapping:** New support for **parallax/virtual displacement mapping** was added, allowing more depth detail on textured surfaces without increasing geometry [^2]. This was an early form of enhancing realism via shaders. -- **Physics and Engine:** Unity 1.1 continued to leverage PhysX and improved the **“big game” workflow**: - - It introduced **better handling of large game projects** – the editor and engine were optimized so that even arbitrarily large scenes or games could be edited and tested entirely within Unity without splitting into external tools [^2]. This involved memory and performance tweaks enabling more complex scenes. - - The PhysX integration was refined (e.g., stability fixes and possibly initial support for ragdoll creation, though full ragdoll wizards came slightly later). -- **Networking/Networking API:** Unity 1.1 added an **Asynchronous WWW API** for internet access [^2]. This gave developers a simple way to fetch data from web servers (for example, to pull down asset bundles or high score tables) without blocking the game. While full multiplayer networking would only arrive in Unity 2.0, the addition of `WWW` classes in 1.1 was important for online features. -- **Extensibility – Plugin SDK:** A major addition was the introduction of a **C/C++ Plugin SDK** for Unity [^2] [^1]. This allowed developers to write native code plugins that could be called from Unity scripts. Through this, Unity games could interface with any hardware or libraries not supported out-of-the-box – a critical extension point for advanced developers (e.g., for VR hardware, custom device input, etc.). -- **Editor/UI Improvements:** Unity 1.1 improved overall usability and documentation: - - The **Unity Editor’s workflow** for large projects was enhanced (as noted above), which implicitly improved the UI responsiveness when dealing with many assets or big scenes. - - Documentation saw a boost – a new “30-page scripting tutorial” was included to help newcomers learn Unity’s API, and the manual/examples were greatly expanded [^2]. This was an important usability improvement for developer onboarding. - - Minor editor tweaks and bug fixes (like better compatibility with certain GPUs and browsers) were part of 1.1 as well [^10]. -- **Miscellaneous:** Unity 1.1 was provided as a free upgrade to 1.x users, reflecting Unity’s approach of iterative improvements. Under the hood, it continued to use Mono runtime for scripting (still .NET 1.1 profile at this stage), and the Mac Editor itself saw optimizations in this release. - - -## Unity 1.2 (December 2005) – Graphics Enhancements & Stability -Unity 1.2 arrived at the end of 2005, bringing a host of roughly “10 big new features” that further matured the engine’s graphics and usability: - -- **Full-Screen Post-Processing Effects:** Notably, Unity 1.2 introduced **full-screen motion blur** as a built-in effect [^5]. This allowed developers to enable motion blur on the camera, enhancing the visual fidelity for fast-moving scenes. It was one of Unity’s first built-in post-processing effects, utilizing the render-to-texture infrastructure. -- **Blob Shadows:** Another new feature was *blob shadows* [^5]. This is a technique for inexpensive dynamic shadows – essentially a projected texture under a character to simulate a shadow. Blob shadows provided a performance-friendly way to have characters cast shadows before Unity had full real-time shadow mapping. It was especially useful for older hardware or simple projects. -- **Other Rendering Updates:** In addition to the above, Unity 1.2 likely expanded shader support and rendering options (though not explicitly named in press materials). Developers gained more control over materials and effects. For example, if not already present, **normal mapping** and better specular shading support were solidified in this era, making Unity more competitive in rendering quality for 2005 standards. -- **Physics and Animation:** Unity 1.2 continued improving physics stability. It also laid groundwork for better animation features (though the major overhaul came in 1.5). It’s around this time that features like a built-in **ragdoll construction wizard** might have been introduced, leveraging PhysX to create ragdoll joints easily (this is inferred since by 1.5–1.6 ragdoll and skinned animation features are mentioned as existing). -- **Editor/Workflow:** Focus in 1.2 was also on robustness: - - The editor became **more stable** and **extensible**. The release was described as “more extensible” than before [^5], which may refer to improvements in the newly added plugin API from 1.1 or perhaps internal editor extension points. - - Usability refinements: small editor UI improvements and bug fixes (for instance, fixes for widget deployment and browser issues were rolled into 1.0.3/1.0.4 updates prior to 1.2 [^10], and 1.2 continued in this vein). - - By now, Unity’s documentation and examples were growing, making the learning curve easier for new developers. -- **“Under the Hood” Upgrades:** Although not flashy, Unity 1.2 likely upgraded its Mono runtime or underlying tech for performance. (Mono/.NET remained at version 1.1 profile here; the significant jump to .NET 2.0 came in 1.6.) Unity 1.2’s emphasis was polishing what 1.0/1.1 introduced – resulting in a more robust engine for studios to adopt. - - -## Unity 1.5 (June 2006) – Major Upgrade (Intel Mac Support, New Animation System) -Unity 1.5 was a substantial update that arrived in mid-2006, coinciding with Apple’s transition to Intel Macs and a growing interest in browser gaming: - -- **Universal Binary & Intel Macs:** Unity 1.5 was the first version released as a **Universal Binary on Mac OS X**, meaning the Unity Editor (and runtime) now ran natively on both PowerPC and the new Intel-based Macs [^6]. This was crucial for performance on the latest hardware and ensured Unity took advantage of Apple’s hardware changes with no delay. -- **Windows Web Player Support:** Along with standalone Windows builds (added in 1.1), Unity 1.5 introduced a **Windows Web Player browser plugin** [^6]. This allowed Unity content to run in Windows browsers (Internet Explorer, Firefox, etc.), massively expanding the reach of Unity-made web games. Prior to 1.5, the web player was Mac-only; now Web deployment truly became cross-platform. -- **New Character Animation System:** Unity 1.5 overhauled its animation pipeline. It introduced a more powerful **animation blending and layering system** [^6]. Developers could blend between multiple animations, use additive animations, and organize animations on layers. This enabled smoother character animations (e.g., blending a running animation with a shooting animation). It was a step up from the earlier system which had been more rudimentary. This system laid the groundwork for Unity’s later Mecanim (though Mecanim itself came much later, in Unity 4). -- **Physics and Vehicles:** Unity 1.5 brought specific physics enhancements, notably: - - A dedicated **Wheel Collider** component for vehicle physics [^6]. This made it easier to simulate car wheels with suspension and friction curves. Using the wheel collider and related improvements, developers could create high-speed car physics and racing games more realistically than before. - - General physics stability was improved further, and performance on PhysX was tuned for the new platforms. -- **Graphics and Effects:** A number of rendering improvements were added: - - **Full-Screen Filters:** Unity 1.5 expanded the post-processing effects repertoire with built-in filters like *Noise*, *Glow/Bloom*, and *Contrast Stretch* (auto exposure) that developers could enable on cameras [^6]. These effects improved visual quality (Glow for HDR-like bloom, noise for image grain or visual feedback, etc.). - - **Lightmapping Support:** Unity 1.5 introduced support for **lightmaps** [^6]. This allowed developers to bake static global illumination or lighting onto textures, and then apply those in Unity for better performance and lighting quality. It was an important feature for higher fidelity environments. - - **Font Rendering:** Added support for **dynamic fonts and TrueType typography** in games [^6]. This meant easier text rendering and better-looking in-game text, benefiting UI and HUD design. - - **Terrain Foliage Shaders:** (In the 1.5.x cycle, Unity 1.5.1 specifically added new shaders for terrain grass and foliage rendering [^9], which improved how outdoor environments looked. Terrain as a system was still rudimentary, but these shaders were precursors to the full terrain engine in 2.0.) -- **Asset Import and Pipeline:** Unity 1.5 extended its support for 3D art tools – notably adding **native import support for Cinema 4D files** [^6]. Artists using Cinema 4D could bring their models and scenes into Unity more directly. This was in addition to existing support for Maya, 3ds Max via FBX, etc. -- **Scripting and API:** The scripting capabilities were enriched: - - A **Mesh manipulation API** was added, exposing mesh vertex data to scripts [^6]. This allowed developers to create or modify meshes at runtime (for procedural geometry, deformations, etc.). It opened up more dynamic content possibilities. - - Particle systems and textures also got scripting interfaces in 1.5 [^6], enabling code-driven control of particle emitters and dynamic texture creation or manipulation. - - The underlying Mono runtime might still have been .NET 1.1 in 1.5 (the generics upgrade came in 1.6), but Unity’s scripting API itself grew with new classes for the above features. -- **Documentation and Usability:** Unity 1.5 shipped with **5× more documentation** than before [^6], reflecting a lot of new written material and examples. The user manual and scripting reference were significantly expanded, which greatly benefited developers (especially newcomers). The editor UI itself saw various small improvements to accommodate the new systems (for example, an improved animation editor or property inspectors for new components like wheel colliders and lightmaps). -- **Performance:** As a major update, Unity 1.5 focused on optimization – running the Editor on Intel Macs gave a big speed boost. Also, “under the hood” enhancements (garbage collection tuning, rendering optimizations, etc.) were likely part of this release, given the mention of “over 256 new features and improvements” [^6]. -- Unity 1.5 was a pivotal release that kept Unity modern (with Intel Mac and advanced visuals support) and broadened its appeal through web and Windows reach, all while still being a free upgrade within the 1.x cycle for existing users. - - -## Unity 1.6 (November 2006) – Web Integration & Final 1.x Tweaks -Unity 1.6 was the last major update of the 1.x series, arriving just before Unity 2.0. Its focus was on polishing the web player experience, improving the engine’s integration capabilities, and preparing for the next generation: - -- **Browser Integration (“Website interactivity”):** A highlight of Unity 1.6 was full two-way communication between Unity content and the embedding webpage. The **Unity Web Player plugin could now fully interact with browser JavaScript** and vice versa [^7]. This meant a Unity game running in a webpage could call JavaScript functions on the page (and receive calls from JS), enabling deep integration – for example, custom HTML UI controls affecting the Unity game, or the game sending events/stats back to the page. This feature greatly improved Unity’s usefulness for web-based projects, allowing hybrid HTML5/Unity experiences and better integration with web APIs. -- **Upgraded .NET Scripting Runtime:** Unity 1.6 upgraded its Mono runtime to support **.NET 2.0 features**, including generics. Developers could now use modern C# 2.0 language features (like generics, nullable types, etc.) in their scripts [^8]. This “increased power” under the hood made coding in Unity more robust and aligned with contemporary C# standards (a welcome improvement for reverse-engineers and developers alike, as code could be more complex and still run). -- **Performance and Usability:** Unity 1.6 brought **better performance optimizations** and editor usability tweaks: - - The phrase “increased power, better usability” was used in the release notes [^7]. The engine was refined for speed – one example being more efficient web player download size or performance. It also likely optimized asset loading and memory use, given the push toward larger projects. - - Usability improvements might have included Editor UI refinements in response to user feedback (e.g., more stable manipulation of objects, nicer gizmos, etc.). Although not a UI overhaul, 1.6 would smooth rough edges as the last 1.x version. -- **Networking and Online:** While full networking was slated for 2.0, Unity 1.6.1 (a patch in early 2007) was dubbed “A Better Online Gaming Experience” – it improved on the foundation from 1.6. This suggests Unity 1.6 introduced groundwork for networking or online play improvements. For example, 1.6 may have improved latency/traffic handling for the web player or added features like automatic proxy detection for web builds. Essentially, Unity 1.6 targeted making web-deployed games more seamless for end users (important for adoption in the casual games boom of the time). -- **Final 1.x Feature Set:** By 1.6, Unity’s engine featured: - - Physics with character controllers, ragdolls, and vehicle support (fully leveraging PhysX 2.x capabilities). - - A reliable graphics pipeline with support for multiple lights, basic shadows (blob shadows), lightmaps, and an array of shader effects. - - An extensible plugin system (introduced in 1.1) now proven and used for various integrations. - - Robust scripting with C# (now with .NET 2.0) and JavaScript, and the ability to interface with external libraries or web scripts. - - Deployment to Mac/Windows standalones and web players on both platforms. (No console or mobile targets yet – those would start appearing after Unity 2.x.) -- **Legacy and Transition:** Unity 1.6 was offered with the promise that anyone who bought Unity 1.6 would get a free upgrade to the forthcoming Unity 2.0 [^7]. - -It effectively wrapped up the 1.x line by adding the last set of “nice-to-have” features so that the engine was quite complete for its era. This ensured developers could comfortably finish projects on 1.x or smoothly transition to 2.0. In fact, some aspects of 1.6 (like the web integration and updated Mono runtime) were crucial stepping stones for the big 2.0 release which introduced things like a full terrain engine, real-time shadows, and a Windows version of the Editor. - ---- -# Unity 2.x and 3.x Versions - -## Unity 2.0 (2007) -* **Engine Features:** A major update with 50+ new additions. Unity 2.0 introduced an optimized terrain engine for large 3D landscapes, real-time dynamic shadows (supporting point, directional, and spot lights), and video playback support ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Unity%202,streaming%20and%20compression%2C%20and%20more)) ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Developers%20work%20in%20networked%20envrionments,%E2%80%94%20it%E2%80%99s%20based%20on%20PostgreSQL)). The engine’s graphics pipeline was enhanced with DirectX 9 support on Windows, allowing standalone and web player games to use Direct3D in addition to OpenGL ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Benefits%20for%20Mac%20developers%20who,0)). Physics continued to leverage NVIDIA’s PhysX engine, and a new networking layer was added for multiplayer: Unity 2.0 provided a UDP-based network API with Network Address Translation (NAT) punch-through, state synchronization, and remote procedure calls ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=An%20optimized%20Networking%20Layer%20now,Unity%E2%80%99s%20Web%20site%20for%20more)). These changes laid the groundwork for more complex, networked games. -* **Editor and Workflow:** Unity 2.0’s editor remained Mac-only (authoring on macOS), but workflow saw improvements. Notably, Unity Asset Server (a version control system for game assets and scripts built on PostgreSQL) was introduced to assist team collaboration ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Developers%20work%20in%20networked%20envrionments,%E2%80%94%20it%E2%80%99s%20based%20on%20PostgreSQL)). Developers could more easily manage assets in teams and roll back changes. The editor also made UI creation more flexible – skinning custom in-game user interfaces became easier in 2.0 ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=detailed%203D%20environments%2C%20real,streaming%20and%20compression%2C%20and%20more)). While still using a single-window Cocoa UI on Mac, this version polished many editor interactions and set the stage for broader platform support. -* **Scripting and Runtime:** Unity 2.0 continued to support scripting in C#, UnityScript (JavaScript dialect), and Boo (Python-inspired) via Mono. It targeted .NET 2.0/Mono 1.x for the scripting runtime, meaning C# 2.0 features were available. There weren’t significant language or API changes in 2.0 aside from the new networking API. However, the foundation was solid – developers could write game logic in managed code that would run on web, PC, or Mac builds. Garbage-collected, component-based scripting was a core part of Unity from the beginning. (Notably, upcoming 2.x releases would start expanding .NET support.) - -## Unity 2.1 (2008) -* **Engine Features:** This release (July 2008) was so substantial it was jokingly “worthy of a full 3.0 version” by devs[^1]. Unity 2.1 became a **“MMO-capable” engine** – it introduced streaming Asset Bundles and support for multiple, stitchable terrains, allowing dynamic loading of content and huge seamless worlds ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=Unity%202,2008)). Developers could segment game assets into bundles and load them at runtime from a server, enabling open-world and MMO-style games. Terrain rendering was improved: 2.1 allowed additive scenes with multiple terrains (previously limited to one) and enabled shadows and projector effects on terrains (e.g. blob shadows) which had not been possible in 2.0 ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=gigantic%20worlds%20to%20the%20player,based%20on%20how%20they%20play)). Graphics saw the addition of per-camera shader replacement (allowing custom render effects per camera) and other tweaks for advanced rendering. -* **Editor and Workflow:** A long-requested **Undo/Redo** system was finally implemented across the Unity editor in 2.1, making the development workflow less error-prone ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=For%20everyone%20else%2C%20we%20have,Undo%20and%20a%20lot%20more)). This greatly improved level design and inspector adjustments, as changes could be reverted. Unity 2.1 also laid groundwork for console support – Unity Technologies announced **Unity for Wii** around this time[^2], marking the engine’s first console target. (Wii support was provided to select licensees, extending Unity’s “author once, deploy anywhere” vision to consoles.) Although the Unity editor was still Mac-only, 2.1’s improvements to asset management and stability benefited all users. -* **Scripting and API:** Unity 2.1’s new features came with new APIs. The **AssetBundle API** was introduced to let scripts load assets on the fly from files or URLs, which was crucial for streaming content. Likewise, procedural modifications to characters and animations became possible via scripting (an exposed API allowed adjusting skinned meshes/bones at runtime) ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=Unity%20is%20now%20a%20complete,based%20on%20how%20they%20play)). No major upgrade to the Mono runtime occurred yet – scripting was still on the .NET 2.0 profile. However, the engine additions (AssetBundles, multi-terrain support, etc.) expanded what developers could do via code. Unity 2.1 effectively set the stage for large-scale games, including early mobile and console experiments, as Unity iPhone 1.0 (a separate product based on Unity 2.1) launched in 2008 for Apple’s new App Store ([Unity (game engine) - Wikipedia](https://en.wikipedia.org/wiki/Unity_(game_engine)#:~:text=launched%20its%20App%20Store%20in,15)). This era introduced mobile development to Unity (initially via a separate iPhone license) and demonstrated the engine’s flexibility. - -[^1]: “Unity 2.1 was released, should have been 3.0, but they did not charge more” – _Miguel de Icaza’s Unite 2008 Live Blog_ (July 2008). Unity 2.1 added streaming asset bundles, multi-terrain support, procedural animation control, an Undo system, etc., making Unity “a complete MMO-capable engine” ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=Unity%202,2008)). -[^2]: Unity Technologies announcement at Unite 2008 of upcoming **Wii console support** for Unity. (By 2008, Unity’s platform list grew from Web/PC/Mac to also include iPhone and Wii.) This marked Unity’s first console deployment option, foreshadowing broader console support in Unity 3.x ([Miguel de Icaza](https://tirania.org/blog/archive/2008/Oct.html#:~:text=They%20announced%20Unity%20for%20Wii)). - -## Unity 2.5 (2009) -* **Engine Features:** Unity 2.5 (released March 2009) was less about new run-time features and more about **broadening platform support** and improving the development tools. The engine itself remained largely consistent with 2.1, but one notable addition was expanded 3D application integration: on Windows, Unity gained drag-and-drop support for Autodesk 3ds Max content, complementing the existing Maya/Blender asset pipelines ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=Even%20easier,as%20thousands%20of%20indie%20developers)) ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=,as%20revolutionary%20for%20democratizing%20game)). This made it easier to import assets from Max on the new Windows editor. Under the hood, the engine maintained its capabilities from 2.1 – developers still had PhysX physics, the same rendering pipeline, and networking, but now with more content creation workflows supported. -* **Editor and Workflow:** Unity 2.5’s headline was the long-awaited **Windows editor**. For the first time, Unity’s authoring tools could run on Windows Vista/XP/2000 with full feature parity to Mac OS X ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=revolutionary%20Unity%20development%20platform%20which,interoperability%20with%20Mac%20OS%20X)) ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=Unity%202,interoperability%20with%20Mac%20OS%20X)). The entire editor UI was rebuilt to be cross-platform, adopting a **tabbed, customizable interface** that looked and functioned identically on both OSes ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=The%20Unity%202,development%20in%20the%20truest%20sense)) ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=Even%20easier,as%20revolutionary%20for%20democratizing%20game)). Developers could dock panels, use tabs, and rearrange the workspace – a significant UX improvement. Navigation in the Scene View was enhanced with new flythrough controls (WASD-style camera navigation) and a redesigned rotation gizmo for precise object manipulation ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=Even%20easier,as%20thousands%20of%20indie%20developers)). The inspector and project window provided more info at a glance (e.g. mesh rendering stats, audio waveforms, and model previews) ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=work%20A%20gorgeous%20tabbed%20interface,as%20thousands%20of%20indie%20developers)). Unity 2.5 essentially **rewrote the editor GUI on UnityGUI/Mono** (the team built the editor on its own UI toolkit), also exposing more of the editor to customization. This enabled a “completely extensible toolset,” where developers could create custom EditorWindows and tools via scripting ([Unity 2.5 | GamesIndustry.biz](https://www.gamesindustry.biz/unity-2-5-formerly-mac-based-development-tool-now-works-with-windows-too#:~:text=,as%20revolutionary%20for%20democratizing%20game)). In short, 2.5 greatly improved editor UX and allowed Windows developers to finally join the Unity ecosystem natively. -* **Scripting and Runtime:** While the runtime engine didn’t get a big upgrade in 2.5, the scripting experience was refined. With the editor on Windows, Unity 2.5 added **integrated Visual Studio synchronization** – the editor can generate a VS project for your scripts so you get IntelliSense and debugging on Windows ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=With%20the%20newest%20release%20of,solution%20and%20IntelliSense%20is%20configured)) ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=support%20for%20external%20versioning%20tools,solution%20and%20IntelliSense%20is%20configured)). This made C# scripting more convenient on Windows using VS or MonoDevelop. Editor scripting became more powerful too: since the editor was rebuilt using Unity’s own GUI system, developers could write custom editor extensions (docking panels, custom inspectors) in C# using the UnityEditor API. Unity 2.5 still used the same Mono runtime (no new C# features yet), but the editor-side scripting API grew. The engine’s core API (for gameplay scripting) stayed consistent, so Unity 2.1 projects upgraded to 2.5 without code changes. Overall, 2.5’s impact was enabling a larger developer base and better tools rather than new in-game APIs. - -## Unity 2.6 (2009) -* **Engine Features:** Unity 2.6 (October 2009) continued the 2.x line with both polish and a couple of advanced engine features. Graphics saw an upgrade for high-end uses: render-to-texture “offscreen” effects gained full **anti-aliasing** support, and Unity added a built-in **screen-space ambient occlusion (SSAO)** post-processing effect (available in Unity Pro) ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=In%20order%20to%20cement%20Unity,screen%20space%20ambient%20occlusion%20effect)). This was one of Unity’s first forays into deferred rendering techniques, improving visual quality with smoother edges and ambient shading. Under the hood, Unity 2.6 introduced fully threaded background asset streaming, allowing games to **load assets on a background thread**, reducing hiccups and improving load times during scene streaming ([Unity 2.6 Released And Now Free!](https://unity.com/news/unity-2-6-released-and-now-free#:~:text=A%20key%20focus%20of%20Unity,com)). This meant large web player games (like EA’s Tiger Woods PGA Tour Online) could stream data progressively without stalling the main thread. Physics and animation systems saw performance optimizations as well, to handle bigger projects. -* **Editor and Workflow:** A major theme of 2.6 was integration into professional pipelines. Unity 2.6 added **external version control support**, allowing developers to use Subversion, Perforce, or other VCS instead of (or in addition to) Unity’s Asset Server ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=With%20the%20newest%20release%20of,solution%20and%20IntelliSense%20is%20configured)). This was enabled by the introduction of text-based asset metadata (.meta files), making it possible to manage Unity project assets in standard VCS. Additionally, on Windows, Unity 2.6 fully integrated with **Visual Studio**: the editor can sync script files into a VS solution automatically, streamlining the edit-compile cycle for Windows C# users ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=With%20the%20newest%20release%20of,solution%20and%20IntelliSense%20is%20configured)) ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=support%20for%20external%20versioning%20tools,solution%20and%20IntelliSense%20is%20configured)). These changes greatly benefitted large teams and projects. For artists and designers, the editor experience was further refined with stability fixes and small UX tweaks. (Notably, Unity 2.6 was the last release before Unity 3, and Unity Technologies made the bold move to **make Unity 2.6 free** for all users, retiring the $199 indie license, though Unity Pro remained paid – reflecting their focus on accessibility[^3].) -* **Scripting and API:** Unity 2.6 did not introduce sweeping new APIs, but it set the stage for the next generation. The engine’s **Mono runtime was still 1.x** (.NET 2.0 subset), so C# 3.0 features were not officially in use yet. However, by this point Unity’s .NET integration was extremely stable, and thousands of developers were building games with C# or UnityScript. Some new APIs in 2.6 included hooks for the threaded loading (e.g., `Application.backgroundLoadingPriority`) and other performance-tuning options. Also, Unity 2.6 improved interoperability with external .NET libraries in anticipation of future Mono upgrades. In summary, 2.6 was a “stability and polish” release that added pro-oriented features (VCS, profiling improvements, etc.) and squeezed the last capabilities out of the 2.x architecture before the leap to Unity 3.0. - -[^3]: **Unity 2.6 press release (Oct 28, 2009)** – Unity 2.6 introduced external version control integration and Visual Studio sync support, and marked the debut of Unity as a free indie engine ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=With%20the%20newest%20release%20of,solution%20and%20IntelliSense%20is%20configured)) ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=support%20for%20external%20versioning%20tools,solution%20and%20IntelliSense%20is%20configured)) (Unity 2.6 “feature-packed Unity… is now available at no cost”). It also added upgraded graphics effects like full-screen SSAO with anti-aliasing ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=In%20order%20to%20cement%20Unity,screen%20space%20ambient%20occlusion%20effect)) and threaded asset streaming for smoother web gameplay ([Unity 2.6 Released And Now Free!](https://unity.com/news/unity-2-6-released-and-now-free#:~:text=A%20key%20focus%20of%20Unity,com)). - -## Unity 3.0 (2010) -* **Engine Features:** Unity 3.0 (released September 2010) was a **massive overhaul** that expanded Unity’s graphics and platform reach. Rendering got a huge boost with the introduction of a **deferred lighting/shading pipeline**, enabling many realtime lights and advanced effects on higher-end hardware ([Unity (game engine) - Wikipedia](https://en.wikipedia.org/wiki/Unity_(game_engine)#:~:text=Unity%203,audio%20filters%2C%20among%20other%20features)). Unity partnered with Illuminate Labs to integrate the **Beast lightmapping tool**, bringing baked global illumination and ambient occlusion to static scenes (Beast provided photorealistic lightmaps for indoor scenes, with automatic UV unwrapping) ([Unity (game engine) - Wikipedia](https://en.wikipedia.org/wiki/Unity_(game_engine)#:~:text=Unity%203,audio%20filters%2C%20among%20other%20features)). In addition, Unity 3.0 fully integrated **Umbra occlusion culling** middleware for performance: large scenes with lots of geometry could be occlusion-culled efficiently at runtime, which was crucial for consoles and big worlds ([Unity Technologies Unveils Third Generation of Its Powerful Development Platform](https://unity.com/news/unity-technologies-unveils-third-generation-its-powerful-development-platform#:~:text=systems%20to%20make%20targeting%20multiple,Pro%20at%20no%20additional%20cost)) ([Unity Technologies Unveils Third Generation of Its Powerful Development Platform](https://unity.com/news/unity-technologies-unveils-third-generation-its-powerful-development-platform#:~:text=games%20such%20as%20the%20highly,Pro%20at%20no%20additional%20cost)). Other graphics additions included **HDR rendering support**, realtime **render-to-cubemap reflections**, and a built-in **Tree Creator** for generating foliage and trees ([Unity (game engine) - Wikipedia](https://en.wikipedia.org/wiki/Unity_(game_engine)#:~:text=Unity%203,audio%20filters%2C%20among%20other%20features)). The physics engine was upgraded (PhysX 2.8.x), improving performance and stability for complex simulations. Audio got an update as well, with a new **audio filters/effects pipeline** (high-pass, low-pass filters, reverb zones, etc.) available to script and tune sound ([Unity (game engine) - Wikipedia](https://en.wikipedia.org/wiki/Unity_(game_engine)#:~:text=addition%20to%20Android%20support%2C%20Unity,contributed%20as%20much%20to%20the)). Importantly, Unity 3.0 dramatically broadened platform support: it added out-of-the-box support for **Android** and **iOS (iPhone/iPad)** within the main editor (previously iOS was separate), and introduced deployment to **PlayStation 3** and **Xbox 360** for licensed developers ([Unity Technologies Unveils Third Generation of Its Powerful Development Platform](https://unity.com/news/unity-technologies-unveils-third-generation-its-powerful-development-platform#:~:text=Mar%208%2C%202010)) ([Unity Technologies Unveils Third Generation of Its Powerful Development Platform](https://unity.com/news/unity-technologies-unveils-third-generation-its-powerful-development-platform#:~:text=Technologies%20announced%20today%20that%20it,platforms%20in%20the%20mobile%20space)). This made Unity 3.0 the engine with one of the widest platform reaches at the time. In summary, Unity 3.0’s engine was prepared for big-budget games – with rendering and optimization features geared toward desktop and console quality, while also embracing the mobile revolution (Android/iPad). -* **Editor and Workflow:** With so many new systems, Unity 3.0’s editor introduced new workflows. A **Lightmapping panel** was added for baking GI via Beast, giving fine control over bake settings and previews. Likewise, an **Occlusion Culling window** allowed baking and visualizing Umbra’s occlusion volumes in the editor. The Editor itself continued to improve in usability: for example, Unity 3 brought a fully integrated **Profiler window** (in Unity Pro) so developers could profile CPU, GPU, memory, and rendering performance of their game inside the editor – a critical tool for optimizing for mobile and consoles. The editor GUI saw minor tweaks and performance improvements, but largely built on the 2.5/2.6 redesign. Unity 3.0 also unified the previously separate “Unity iPhone” into the main editor – developers could now switch the build target to “iOS” or “Android” inside Unity, simplifying multi-platform development. Another notable workflow enhancement was **Unity Remote 3** for testing on devices and improved asset import pipeline for mobile textures. All these changes made the editor suitable for developing more complex, multi-platform projects. -* **Scripting Improvements:** Unity 3.0 made a **major upgrade to the Mono runtime**, moving from Mono 1.2.5 to **Mono 2.6**, which corresponds roughly to .NET 3.5 support ([Unity - Mono Upgrade Details](https://docs.unity3d.com/420/Documentation/Manual/MonoUpgradeDetails.html#:~:text=In%20Unity%203%20we%20upgraded,lists%20some%20of%20the%20highlights)). This meant C# 3.0 language features — including LINQ queries, lambda expressions, extension methods, and type inference — became available to Unity developers for the first time ([Unity - Mono Upgrade Details](https://docs.unity3d.com/420/Documentation/Manual/MonoUpgradeDetails.html#:~:text=C)). (Under the hood, Unity still used a modified .NET 2.0 subset for API compatibility, but many .NET 3.5 features were now usable in scripts.) The Unity API itself expanded significantly to expose new engine features: e.g., **LightProbe** and **LightmapSettings** classes for the GI system, **OcclusionArea** and related culling APIs, and **NavMesh** stub classes (though fully realized in 3.5). Unity also added the ability to integrate **native code plugins** on Windows and Mac, enabling C/C++ libraries to be called from C# (useful for advanced users and middleware). Another important addition (though initially undocumented) was support for **managed code stripping and assembly compilation** – developers could drop in pre-compiled .NET DLLs that contained gameplay code or third-party libraries, and Unity would include them (this was confirmed around Unity 3.1[^4]). All told, Unity 3.0 empowered developers with more expressive C# and the hooks needed to drive the new rendering and platform features. It marked Unity’s transition into a truly extensible, high-end engine while retaining its ease of use. - -[^4]: Unity 3.x scripting upgrade – Unity 3.0/3.1 upgraded Mono from 1.2.5 to 2.6, enabling C# 3.5 features (like LINQ and lambdas) and even parts of C# 4.0 ([Unity - Mono Upgrade Details](https://docs.unity3d.com/420/Documentation/Manual/MonoUpgradeDetails.html#:~:text=In%20Unity%203%20we%20upgraded,lists%20some%20of%20the%20highlights)) ([Unity - Mono Upgrade Details](https://docs.unity3d.com/420/Documentation/Manual/MonoUpgradeDetails.html#:~:text=C)). Additionally, Unity 3.1 officially allowed managed .NET DLLs in projects (MonoBehaviours defined in external assemblies could be used), easing code sharing and use of middleware ([unity 3.1 released](https://lesterbanks.com/2010/11/unity-3-1-released/#:~:text=,that%20access%20the%203D%20device)). These improvements significantly enhanced Unity’s scripting power compared to 2.x. - -## Unity 3.1 (2010) -* **Engine Features:** A minor update (Nov 2010), Unity 3.1 focused on stability and few new features since 3.0 had just shipped. There were no groundbreaking engine changes; rather, 3.1 included **bug fixes** and performance tweaks for the new systems (rendering, physics, etc.). One notable engine-level addition was actually on the services side: Unity 3.1 launched the **Unity Asset Store**, which, while an editor service, indirectly expanded what engines could do by making assets/plugins available to projects with a few clicks. The runtime didn’t change except for improved reliability of the new lightmapping and occlusion culling from 3.0. (Any engine feature additions here were relatively small, e.g. slight improvements to cloth physics or video playback stability, as indicated in release notes.) -* **Editor and Workflow:** The biggest highlight of Unity 3.1 was the introduction of the **Asset Store panel directly inside the editor**. This in-editor marketplace allowed developers to download both free and paid assets, scripts, and editor extensions without leaving Unity ([Unity launches Unity Asset Store - MCV/DEVELOP](https://mcvuk.com/development-news/unity-launches-unity-asset-store/#:~:text=Engine%20outfit%20Unity%20has%20used,marketplace%20called%20Unity%20Asset%20Store)) ([Unity launches Unity Asset Store - MCV/DEVELOP](https://mcvuk.com/development-news/unity-launches-unity-asset-store/#:~:text=for%20free)). The Asset Store dramatically improved workflow by providing a library of pre-made content (shaders, models, plugins) that could be imported in seconds, making Unity’s ecosystem even more powerful for developers and reverse-engineers alike. Aside from the Asset Store (accessible via *Window → Asset Store*), Unity 3.1’s editor got minor refinements. For example, Unity 3.1 improved editor stability on long-running sessions (fixing some memory leaks in the new Profiler and Occlusion windows) and fixed asset pipeline issues on Mac vs. Windows. It was largely a quality update for the editor experience after the big 3.0 changes. -* **Scripting Improvements:** While 3.0 laid the groundwork with Mono 2.6, Unity 3.1 officially documented and supported some new scripting workflows. Notably, Unity 3.1 fully enabled use of **precompiled managed DLLs** in Unity projects: developers could move code into a .NET assembly and drop it into Assets, and Unity would recognize the contained classes (including custom `MonoBehaviour` or editor classes) ([unity 3.1 released](https://lesterbanks.com/2010/11/unity-3-1-released/#:~:text=New%20Features%3A)). This made it easier to reuse code libraries and for middleware vendors to ship Unity-compatible SDKs without source. Unity 3.1 also exposed a few new script APIs that weren’t ready in 3.0 – for example, a new `GL.InvalidateState()` function was added for native plugin developers to reset Unity’s GL state when rendering externally ([unity 3.1 released](https://lesterbanks.com/2010/11/unity-3-1-released/#:~:text=without%20sharing%20the%20source%20code,GetSpectrumData)). Additionally, an `AudioSettings.outputSampleRate` property was added for audio scripting, useful for music apps to get the DSP rate ([unity 3.1 released](https://lesterbanks.com/2010/11/unity-3-1-released/#:~:text=,GetSpectrumData)). These were relatively niche, though. For most developers, 3.1’s scripting felt the same as 3.0, just more robust. Under the hood, Unity 3.1 fixed many issues from 3.0’s huge merge – for instance, it resolved some memory leaks in the **Undo system for large terrains** and a “too many open files” bug when importing many shaders on Mac ([unity 3.1 released](https://lesterbanks.com/2010/11/unity-3-1-released/#:~:text=Fixes%3A)). All in all, 3.1 was a housekeeping update that also debuted the game-changing Asset Store feature for the community. - -## Unity 3.2 (2011) -* **Engine Features:** Unity 3.2 (February 2011) introduced several new high-level features, especially in visual effects. A new **Water rendering system** was added as a standard asset: the Water prefab included realistic waves and automatic foam generation at shorelines ([Unity 3.2 adds new animated water, depth of field effects | CG Channel](https://www.cgchannel.com/2011/02/unity-3-2-adds-new-animated-water-dof-effects/#:~:text=Unity%20Technologies%20has%20released%20a,to%20the%20Unity%20game%20engine)) ([Unity 3.2 adds new animated water, depth of field effects | CG Channel](https://www.cgchannel.com/2011/02/unity-3-2-adds-new-animated-water-dof-effects/#:~:text=Major%20new%20features%20in%20Unity,Bokeh%20effects%3B%20and%20%E2%80%98bugfixes%20galore%E2%80%99)), significantly improving the look of water for environments. This water system was an upgrade over the older simple water, providing better shaders and interactions. Additionally, Unity’s **Image Effects** got an upgrade with a new **Depth of Field (DoF)** effect that included **bokeh** (out-of-focus blur shapes) for more cinematic visuals ([Unity 3.2 adds new animated water, depth of field effects | CG Channel](https://www.cgchannel.com/2011/02/unity-3-2-adds-new-animated-water-dof-effects/#:~:text=Major%20new%20features%20in%20Unity,Bokeh%20effects%3B%20and%20%E2%80%98bugfixes%20galore%E2%80%99)). This improved DoF (along with tweaks to motion blur and other effects) allowed developers to achieve higher-quality post-processing on supported hardware. Aside from these, Unity 3.2 mainly optimized what was introduced in 3.0/3.1 – for example, graphics performance and Beast lightmapping speed were improved. There were also “bugfixes galore” in physics and networking as per Unity’s notes, indicating increased engine stability ([Unity 3.2 adds new animated water, depth of field effects | CG Channel](https://www.cgchannel.com/2011/02/unity-3-2-adds-new-animated-water-dof-effects/#:~:text=Major%20new%20features%20in%20Unity,Bokeh%20effects%3B%20and%20%E2%80%98bugfixes%20galore%E2%80%99)). -* **Editor and Workflow:** Unity 3.2 included small editor enhancements and new example content. The editor came with the new Water prefab and example scene demonstrating the shoreline foam and better underwater effects. Some UI polish was done on the Editor to accommodate the new image effects (for instance, a convenient dropdown to add the new DoF effect on camera). The Scene View also got a **rendering stats overlay** toggle in 3.2, showing triangle counts, FPS, etc., which helped in optimization (this was an improvement building on 3.0’s profiler). Another workflow change was improved *Editor Gizmo*. Unity 3.2 fixed some gizmo picking issues and introduced an option to visualize lightmapping resolution in the Lightmap UV charts. Overall, 3.2 made it easier to achieve and preview certain visual effects directly in the editor. -* **Scripting and API:** On the scripting side, Unity 3.2 did not bring new language features (still on C# 3.0/Mono 2.6), but it did add API support for the new water and image effects. For example, the Water component had script hooks to adjust wave speed/size at runtime, and the DepthOfFieldScatter (bokeh DoF) effect had properties for focal distance and aperture that could be tweaked via script for dynamic focus effects. Unity 3.2 also improved the `MonoBehaviour.OnDrawGizmos()` performance for editors, making custom gizmos in scene view smoother for tools. Another noteworthy detail for reverse-engineers: Unity 3.2’s build outputs and file structures became more standardized as the engine matured (e.g., inclusion of `mainData` and `Managed\Assembly-CSharp.dll` in builds as usual). Essentially, 3.2’s scripting environment was a stabilized version of 3.0/3.1, with the bonus of a few new toy APIs to control the water and depth-of-field behaviours. - -## Unity 3.3 (2011) -* **Engine Features:** Unity 3.3 (March 2011) was a relatively small update, but historically important for platform support. It marked Unity’s **full launch of Android support** – whereas Android publishing was in “preview” before, Unity 3.3 officially supported building games for Android phones and tablets at parity with other platforms ([Unity 3.3 adds support for the Android - InfoQ](https://www.infoq.com/news/2011/03/Unity-Android/#:~:text=Unity%20technologies%20announced%20March%201,and%20scripting%20tools%20are%20available)). This included finalizing input handling (touch, accelerometer, gyro), Android-specific optimizations, and integration with the Android NDK for plugins. Essentially, any Unity project could now be deployed to Android with the click of a button, opening Unity development to a massive new audience. Aside from Android, engine changes were minor. Unity 3.3 improved rendering on mobile (better fallbacks for older GPUs) and added support for **Nvidia Tegra** chipsets optimizations ([Unity 3.3 adds support for the Android - InfoQ](https://www.infoq.com/news/2011/03/Unity-Android/#:~:text=Unity%20uses%20the%20fmod%20audio,Net%20libraries)). It also brought further physics and audio tweaks to run efficiently on mobile hardware. In terms of visuals, no new big feature like 3.2’s water was added, but Unity 3.3 ensured that features like Beast lightmapping could work on mobile targets by baking for OpenGL ES contexts. -* **Editor and Workflow:** With Android as a new build target, the Unity editor in 3.3 streamlined the multi-platform workflow. The Build Settings now listed Android alongside Web Player, PC, Mac, iOS, etc., and switching platform auto-adjusted player settings (like graphics API and resolution) appropriate to Android. Unity 3.3 also likely updated the SDK/NDK tools integration – the editor could detect installed Android SDKs and facilitate signing APKs for deployment, making the build-and-test cycle easier. On the usability front, 3.3 fixed some annoyances: for instance, a bug with scene view sometimes showing objects in wireframe was resolved, and the “Save Project” dialog behavior was improved (less frequent or intrusive) as per user reports. There were no major UI overhauls; rather, Unity 3.3 was about solidifying the pipeline for the new platform. -* **Scripting and API:** Scripting in Unity 3.3 remained consistent with 3.2. The primary changes were new APIs or modifications to support Android. Unity introduced, for example, the `Handheld` class (with `Handheld.Vibrate()` for vibration on mobile) around this era, and improved the `Input` class to report device orientation and acceleration uniformly on Android and iOS. Also, Unity 3.3 exposed certain low-level graphics APIs to help devs optimize for mobile, like the `Shader.isSupported` flag checking for shader support on GLES devices. If a project targeted Android, scripts could now call `Application.platform` to distinguish Android at runtime. Another subtle update: the managed assemblies in Unity 3.3 builds for Android were AOT-compiled (since Android used IL2CPP later, but back then it was Mono with ahead-of-time compilation due to no JIT on iOS/Android), which reverse-engineers might note in how code is stored. In summary, Unity 3.3’s scripting additions were all about **mobile support** – giving developers the tools to tailor their games to handheld platforms. - -## Unity 3.4 (2011) -* **Engine Features:** Unity 3.4 (July 2011) continued the 3.x trajectory with a mix of new features and optimizations. A standout addition was the integration of **Allegorithmic’s Substance** technology for **procedural textures** ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=Unity%203,and%20optimize%20their%20texturing%20pipeline)). Unity 3.4 could import “.sbsar” Substance files, allowing textures that are generated dynamically from parameters. These procedural materials could be adjusted in the editor or even at runtime, with the engine only needing to download a tiny set of data and then streaming in textures as needed ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=Unity%203,and%20optimize%20their%20texturing%20pipeline)). This dramatically reduced download sizes for rich visual content and let games tweak material properties (like dirt amount, hue, etc.) in real-time. Unity 3.4 also introduced **streaming asset download caching**: asset bundles or entire scenes downloaded at runtime could be cached on the end-user’s device, so that subsequent loads were faster or offline-capable ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=renderers%20to%20animation%20components%20result,player%20experience%20across%20all%20platforms)). This was great for web players and any games with downloadable content, reducing repeated downloads. In terms of rendering and performance, Unity 3.4 brought numerous optimizations – shadows were refined (with options to adjust directional light shadow fade for quality), the animation system was optimized under the hood, and overall rendering performance improved across the board ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=,complete%20scenes%20and%20asset%20bundles)). It also quietly added preliminary support for *HDR textures on mobile* and other forward-looking tweaks. No new “marquee” rendering feature (like deferred in 3.0 or HDR in 3.5) was introduced, but the engine became faster and more flexible. -* **Editor and Workflow:** Unity 3.4 came as a **free update to all 3.x users** and delivered several editor improvements for productivity. One of the most user-visible was the ability to assign **custom icons to GameObjects** in the scene hierarchy and scene view ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=,player%20experience%20across%20all%20platforms)). This meant, for example, you could mark important objects or scripts with unique icons, making large scenes easier to navigate. Another nice addition was that **primitive colliders became editable** visually – you could move/scale the gizmos for box, sphere, and capsule colliders directly in the Scene View (prior to this, adjusting colliders was more numeric). This sped up level collision setup ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=,player%20experience%20across%20all%20platforms)). Unity 3.4 also improved the editor’s handling of very large projects (hundreds of assets), partly via the caching feature mentioned above and partly via optimizing asset import times. There was also a new **memory profiler** view in 3.4 (as an extension of the Profiler) to help track asset memory usage, which big studios appreciated. In terms of platform workflow, 3.4 added support for building to **Google Native Client (NaCl)** as an experimental feature (though fully announced in 3.5), exposing it in the editor’s build targets for the first time. Overall, the Unity 3.4 editor was more polished and geared toward bigger team collaboration and faster iteration. -* **Scripting and API:** Unity 3.4 did not dramatically change the scripting landscape like 3.5 would, but it brought useful new APIs. For example, with Substance integration, a new `ProceduralMaterial` class was introduced, with scripting interfaces to set procedural material parameters at runtime (letting you animate a material’s look or respond to game events). The **AssetBundle caching** got a corresponding API (`Caching` class in UnityEngine) so scripts could manage cached AssetBundle versions – crucial for patchers or DLC systems ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=renderers%20to%20animation%20components%20result,player%20experience%20across%20all%20platforms)). There were also improvements to the animation scripting: Unity 3.4’s optimized animation components meant better performance for state machines, and it exposed a bit more of the animation state via scripting to tune blending. Editor scripting gained some additions too, such as `EditorGUIUtility.SetIconForObject` to support the new custom icons feature. Under the hood, the Mono runtime was unchanged (still 2.6 at this point), but the UnityEngine and UnityEditor API grew slightly. For reverse engineers, Unity 3.4 builds are recognizable by the inclusion of the new **Substance DLLs** and references in data files to “ProceduralMaterials.” Unity 3.4 was essentially a feature refinement release that set the stage for the huge 3.5 update to come. - -## Unity 3.5 (2012) -* **Engine Features:** Unity 3.5 (February 2012) was one of the most significant updates in Unity’s history, packing dozens of major features and paving the way for “AAA” level development on Unity. One headline feature was the brand-new **Shuriken particle system**, a highly optimized, modular system for particle effects ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,finding%20and%20crowd%20simulation%20take)). Shuriken brought a curve-driven editor with layered emitters, sub-emitters, and precise control over particle properties (velocity, size, color over lifetime, etc.), far surpassing Unity’s older particle system. Another huge addition was **built-in pathfinding and navigation meshes**: Unity 3.5 introduced a **NavMesh baking** tool in the editor and a runtime navigation system for AI agents ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=synchronized.%20,simulation%20take%20over%20at%20runtime)) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=Improvements%20to%20AI%20provide%20accurate,simulation%20take%20over%20at%20runtime)). Developers could bake walkable surfaces and have NPCs navigate with automatic pathfinding and local avoidance, enabling complex AI behaviors without third-party libs. In rendering, Unity 3.5 delivered **Linear color space lighting** and **HDR** support across the engine, resulting in more physically correct lighting and better looking high-brightness effects ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,characters%20and%20other%20dynamic%20objects)). Along with this came a new **multi-threaded rendering pipeline** that could leverage multiple CPU cores to submit draw calls, greatly improving performance in large scenes ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,New%20Platforms)). To complement Beast lightmaps, **Light Probes** were added – these allow characters and dynamic objects to receive baked lighting from the environment via interpolated probe points, adding realism to mixed static/dynamic lit scenes ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=lighting%20and%20HDR%20rendering%2C%20and,characters%20and%20other%20dynamic%20objects)). Unity 3.5 also fundamentally improved performance for huge scenes by completely rewriting the **Umbra occlusion culling** integration: the new occlusion system worked with terrains and even dynamic obstacles, and it was paired with a new **Level-of-Detail (LOD)** system for rendering ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=of%20the%20Flash%20deployment%20add,performance%20boost%20that%20they%20need)) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,performance%20boost%20that%20they%20need)). With LOD groups, developers could assign multiple models to an object at different detail levels, and Unity would automatically switch them based on camera distance – essential for large, open-world games. Furthermore, Unity 3.5 officially added **Google Native Client** as a deployment platform (Native Client lets Unity web games run in Chrome without a plugin) and shipped a **preview of Flash Player deployment** ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,and%20works%20with%20terrains%20and)). The Flash add-on could compile Unity games to ActionScript bytecode, allowing Unity content to run in Adobe Flash (an experimental feature used by tens of thousands of developers during the 3.5 cycle) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,and%20works%20with%20terrains%20and)). In short, Unity 3.5’s engine was at a new level: advanced particle FX, AI navigation, better lighting, better culling, level-of-detail, and broader platform reach (Flash, NaCl) – all in one release ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=allows%20for%20near%20native%20speeds,the%20performance%20boost%20that%20they)). -* **Editor and Workflow:** Given the monumental engine changes, the Unity 3.5 editor had to support a lot of new workflows. The editor now included a **NavMesh bake window** and a visualization of navmeshes in the Scene View (with tools to define walkable areas, off-mesh links, etc.), plus a new component type – `NavMeshAgent` – that could be attached to characters for navigation. There was also a **LOD Group inspector** that let artists assign multiple LOD models and preview transition distances, making LOD setup straightforward. For particles, the Shuriken system came with an all-new **curve editor and module UI** inside the Particle System component inspector – multiple modules (emission, shape, velocity, color over lifetime, etc.) could be tuned in a single interface, and it supported copying modules between systems. This was a huge workflow improvement for VFX artists. Unity 3.5 also introduced the concept of **Asset Cache Server** for teams: this was a license add-on (Team License) that let large teams share asset import results on a local cache server to dramatically speed up import and platform switch times ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,on%20for%20all%20Unity%20users)). Along with that, Unity provided a **Version Control API** so that third-party version control (like SVN or Perforce) could be more deeply integrated ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,on%20for%20all%20Unity%20users)). The existing Asset Server was improved and renamed to “Unity Team License,” reflecting these collaboration enhancements. In the editor UI, one subtle but powerful addition was the **Integrated GPU Profiler** (for Unity Pro): developers could now profile GPU usage in addition to CPU, seeing draw call timings, etc., which is critical for optimizing graphics ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,additions%20and%20improvements%2C%20please%20visit)). The editor’s Scene View got an improved gizmo for directional light shadows (to visualize cascades and coverage). And for the first time, Unity added a **Social API** – not an editor feature per se, but the editor exposed settings to hook into social platforms (e.g., to integrate with Facebook or Game Center, hinting at the coming multi-platform social gaming push) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,additions%20and%20improvements%2C%20please%20visit)). Unity 3.5’s editor was arguably the most feature-rich and complex Unity editor up to that point, supporting high-end use cases (large team collaboration, complex levels, advanced effects) while still keeping the interface unified. -* **Scripting and API:** The Unity 3.5 release expanded the Unity API surface area tremendously. New classes like `ParticleSystem` (and a whole namespace of `ParticleSystem.*Module` classes) exposed Shuriken to scripting – allowing complete control of particle emitters via code (for example, adjusting emission rates, bursts, or even procedural emission shapes on the fly). For the pathfinding features, Unity added the `NavMeshAgent` and `NavMeshObstacle` components, with script APIs to set destinations, query paths, avoid obstacles, etc. (e.g., `agent.SetDestination()` and `agent.remainingDistance`). The `NavMesh` class also allowed certain runtime queries like raycasting on the navmesh. With the rendering improvements, scripts gained the ability to switch **lighting modes** between Linear and Gamma via project settings (not at runtime), and could take advantage of the new LOD system through the `LODGroup` component (which had API hooks to force a certain LOD or get the current LOD level). The **Light Probe** system introduced new objects and APIs for sampling lighting – e.g., the `LightProbeGroup` component and static methods to interpolate probe data for dynamic objects. Unity’s core API remained backward compatible, but many new properties and options were added to existing classes (for instance, `Camera.hdr` toggle, `Light.lightmapBakeType`, etc.). UnityScript and Boo also benefited from the Mono upgrade earlier in 3.x, but 3.5 mainly leveraged that with more engine features rather than further language changes. Another noteworthy API addition was low-level: Unity 3.5 introduced access to the audio **DSP buffer** for the first time ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,additions%20and%20improvements%2C%20please%20visit)), meaning you could get raw audio sample data or even feed it – enabling the creation of music visualizers or rhythm games via script. The new **Social API** provided a unified way to interact with platform social features (like posting scores or achievements), abstracting differences between, say, GameCenter on iOS vs others ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,additions%20and%20improvements%2C%20please%20visit)). For those reverse-engineering Unity games, Unity 3.5 builds are identifiable by the presence of new frameworks (e.g., `UnityEngine.Navigation` DLL for the pathfinding system, `UnityEngine.UI` for the new particle editor GUI, etc.) and by data files containing navmesh and light probe data. The introduction of these advanced features in Unity 3.5 firmly put Unity on the map as a engine capable of handling large, complex 3D projects with sophisticated AI, graphics, and workflows – essentially bridging the gap to what would come next in Unity 4.x. - -## References - -[^1]: Peter Cohen, **“Unity 2.0 game engine now available”**, *Macworld* (Oct. 10, 2007). Unity 2.0 added 50+ features: terrain engine, dynamic shadows (point/directional/spot lights), video playback, easier GUI skinning, web streaming, and DirectX 9 support for Windows games ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Unity%202,streaming%20and%20compression%2C%20and%20more)) ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Benefits%20for%20Mac%20developers%20who,0)). It also introduced Unity Asset Server for version control and a new networking layer with NAT punch-through and RPCs ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=Developers%20work%20in%20networked%20envrionments,%E2%80%94%20it%E2%80%99s%20based%20on%20PostgreSQL)) ([Unity 2.0 game engine now available | Macworld](https://www.macworld.com/article/187693/unity-18.html#:~:text=An%20optimized%20Networking%20Layer%20now,Unity%E2%80%99s%20Web%20site%20for%20more)). -[^2]: *Unity 2.1 Release Highlights* – Unity 2.1 (July 2008) delivered **streaming AssetBundles** and multi-terrain support, enabling MMO-scale worlds, plus **procedural character animation control**, terrain shadows, per-camera shader overrides, and a full Undo system ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=Unity%202,2008)) ([Unity 3D now on Wii - lite-C Forums](https://opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=212744&page=8#:~:text=For%20everyone%20else%2C%20we%20have,Undo%20and%20a%20lot%20more)). This update also coincided with Unity iPhone support (Unity iPhone 1.0 in 2008) and an announcement of **Unity for Wii** (Unity’s first console deployment) at Unite 2008[^2]. These features elevated Unity 2.1 to a level of functionality that rivaled what one would expect from a major version jump. -[^3]: **Unity 2.6 Press Release** – *Unity 2.6 Released and Now Free!* (Oct 28, 2009). Unity 2.6 introduced professional-grade features: external version control support (integration with SVN, Perforce, etc.) and **Visual Studio project sync** for improved Windows development ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=With%20the%20newest%20release%20of,solution%20and%20IntelliSense%20is%20configured)) ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=support%20for%20external%20versioning%20tools,solution%20and%20IntelliSense%20is%20configured)). Graphics upgrades included support for full-screen **anti-aliasing in offscreen renders** and a built-in **screen-space ambient occlusion (SSAO)** effect ([Unity Technologies Launches Version 2.6 - iClarified](https://www.iclarified.com/5801/unity-technologies-launches-version-26#:~:text=In%20order%20to%20cement%20Unity,screen%20space%20ambient%20occlusion%20effect)). Additionally, Unity 2.6 enabled fully threaded asset streaming to speed up game load times and made the Unity Indie version free for all developers ([Unity 2.6 Released And Now Free!](https://unity.com/news/unity-2-6-released-and-now-free#:~:text=A%20key%20focus%20of%20Unity,com)). -[^4]: **Mono/.NET Upgrade in Unity 3.x** – *Unity Manual: Upgrading to Unity 3 – Mono Upgrade Details*. Unity 3.0/3.1 upgraded the Mono runtime from 1.2.5 to **Mono 2.6**, bringing the C# 3.5 compiler. This enabled modern C# features such as LINQ, lambdas, and type inference in Unity scripts ([Unity - Mono Upgrade Details](https://docs.unity3d.com/420/Documentation/Manual/MonoUpgradeDetails.html#:~:text=In%20Unity%203%20we%20upgraded,lists%20some%20of%20the%20highlights)) ([Unity - Mono Upgrade Details](https://docs.unity3d.com/420/Documentation/Manual/MonoUpgradeDetails.html#:~:text=C)). Unity 3.1 also officially allowed managed .NET DLLs in projects, so developers could include precompiled assemblies with script code ([unity 3.1 released](https://lesterbanks.com/2010/11/unity-3-1-released/#:~:text=,that%20access%20the%203D%20device)). These changes gave Unity developers access to a more powerful scripting environment while maintaining backward compatibility with .NET 2.0 APIs. -[^5]: **Unity 3.4 Release Notes** – *Unity Technologies Releases Unity 3.4* (July 26, 2011). Unity 3.4 integrated Allegorithmic **Substance** for procedural textures, allowing dynamic texture generation in editor or at runtime and significantly reducing download sizes for high-quality textures ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=Unity%203,and%20optimize%20their%20texturing%20pipeline)). Other enhancements included editor improvements (assignable Scene View gizmo icons, editable primitive colliders) and **downloadable content caching** to support asset bundle streaming with caching on the end-user side ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=,player%20experience%20across%20all%20platforms)). Numerous optimizations (shadows, animation) were made for increased performance ([Unity Technologies Releases Unity 3.4](https://unity.com/news/unity-technologies-releases-unity-3-4#:~:text=,complete%20scenes%20and%20asset%20bundles)). -[^6]: **Unity 3.5 Press Release** – *Unity Technologies Releases Unity 3.5* (Feb 14, 2012). Unity 3.5 was a major milestone, introducing the Shuriken particle system and built-in pathfinding/crowd avoidance (NavMesh baking and NavMeshAgent components) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,finding%20and%20crowd%20simulation%20take)) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=synchronized.%20,simulation%20take%20over%20at%20runtime)). It added linear space lighting and HDR rendering with a new multi-threaded renderer for better performance ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,New%20Platforms)), plus **Light Probes** to light dynamic objects with baked GI ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=lighting%20and%20HDR%20rendering%2C%20and,characters%20and%20other%20dynamic%20objects)). New platforms were supported: Google Native Client deployment and a preview of Flash Player exporting ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,and%20works%20with%20terrains%20and)). Performance-wise, occlusion culling was overhauled (faster and working with terrains and dynamic objects) and a native LOD system was introduced ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=of%20the%20Flash%20deployment%20add,performance%20boost%20that%20they%20need)). Collaboration tools were enhanced via a Cache Server and third-party VCS support (Team License) ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,on%20for%20all%20Unity%20users)). Additional improvements included a GPU profiler, a Social API for social network integration, and low-level audio DSP access ([Unity Technologies Releases Unity 3.5](https://unity.com/news/unity-technologies-releases-unity-3-5#:~:text=,additions%20and%20improvements%2C%20please%20visit)), making Unity 3.5 one of the most comprehensive updates in Unity’s history. - ---- -## References -[^1]: [Unity 1.1 Enables Game Publishing on Windows- The Mac Observer](https://www.macobserver.com/news/unity-enables-game-publishing-windows/#:~:text=Other%20additions%20to%20Unity%20include,fixes%20have%20also%20been%20made). -[^2]: [Unity 1.1 Released: Windows, Big Game Workflow, C/C++ SDK - MacTech.com](https://www.mactech.com/2005/08/19/unity-1-1-released-windows-big-game-workflow-c-c-sdk/amp/#:~:text=Highlights%20of%20new%20features%20in,Unity%20is%20now%20fully%20supported). -[^3]: [How Unity built the world’s most popular game engine - TechCrunch](https://techcrunch.com/2019/10/17/how-unity-built-the-worlds-most-popular-game-engine/#:~:text=Unity%201,game%20developer%20market%20used%20PCs). -[^4]: [Unity 1.2: 3D Game Editor - MacTech.com](https://www.mactech.com/2005/12/24/unity-1-2-3d-game-editor/#:~:text=Unity%201,Big%20New%20Features). -[^5]: [Unity 3D game engine goes Universal - Macworld](https://www.macworld.com/article/180420/unity-10.html#:~:text=Unity%201,additive%20animations%2C%20layers%20and%20more) -[^6]: [Unity game engine adds new grass and tree effects - Macworld](https://www.macworld.com/article/181782/unity-11.html#:~:text=Unity%20can%20be%20used%20to,character%20animation%20and%20ragdoll%20physics) -[^7]: [Unity 1.6 is out! - News & General Discussion - Unity Discussions](https://discussions.unity.com/t/unity-1-6-is-out/375594#:~:text=Discussions%20discussions,plugin%20can%20now%20fully). -[^8]: [Unity 1.6 - Geero.net](https://www.geero.net/tag/unity/) -[^9]: [Unity game engine adds new grass and tree effects - Macworld](https://www.macworld.com/article/181782/unity-11.html#:~:text=Unity%20can%20be%20used%20to,character%20animation%20and%20ragdoll%20physics) -[^10]: [Unity 1.0.4 game engine released - Macworld](https://www.macworld.com/article/176326/unity-2.html#:~:text=Since%20Unity%201,there%E2%80%99s%20no%20need%20to%20update) diff --git a/public/consoles/Games.png b/public/consoles/Games.png new file mode 100644 index 00000000..88c55411 Binary files /dev/null and b/public/consoles/Games.png differ diff --git a/public/consoles/Introduction.png b/public/consoles/Introduction.png new file mode 100644 index 00000000..cfa17b93 Binary files /dev/null and b/public/consoles/Introduction.png differ diff --git a/public/generated/placeholders/2d-graphics.jpg b/public/generated/placeholders/2d-graphics.jpg index c2f0e9e3..3eea6908 100644 Binary files a/public/generated/placeholders/2d-graphics.jpg and b/public/generated/placeholders/2d-graphics.jpg differ diff --git a/public/generated/placeholders/3d-software.jpg b/public/generated/placeholders/3d-software.jpg index 248fd8ef..7333a16b 100644 Binary files a/public/generated/placeholders/3d-software.jpg and b/public/generated/placeholders/3d-software.jpg differ diff --git a/public/generated/placeholders/3d-studio-max.jpg b/public/generated/placeholders/3d-studio-max.jpg index 3522e0c9..7aab52e3 100644 Binary files a/public/generated/placeholders/3d-studio-max.jpg and b/public/generated/placeholders/3d-studio-max.jpg differ diff --git a/public/generated/placeholders/3do.jpg b/public/generated/placeholders/3do.jpg index f5578985..6259d38b 100644 Binary files a/public/generated/placeholders/3do.jpg and b/public/generated/placeholders/3do.jpg differ diff --git a/public/generated/placeholders/3ds.jpg b/public/generated/placeholders/3ds.jpg index 6a80c9db..1eba1d67 100644 Binary files a/public/generated/placeholders/3ds.jpg and b/public/generated/placeholders/3ds.jpg differ diff --git a/public/generated/placeholders/68k.jpg b/public/generated/placeholders/68k.jpg index c34723be..faf127dc 100644 Binary files a/public/generated/placeholders/68k.jpg and b/public/generated/placeholders/68k.jpg differ diff --git a/public/generated/placeholders/amiga.jpg b/public/generated/placeholders/amiga.jpg index bdcc5cbd..873a3ebd 100644 Binary files a/public/generated/placeholders/amiga.jpg and b/public/generated/placeholders/amiga.jpg differ diff --git a/public/generated/placeholders/android.jpg b/public/generated/placeholders/android.jpg index 767df8b9..d5015d57 100644 Binary files a/public/generated/placeholders/android.jpg and b/public/generated/placeholders/android.jpg differ diff --git a/public/generated/placeholders/arcade.jpg b/public/generated/placeholders/arcade.jpg index 720faf01..5ac5a291 100644 Binary files a/public/generated/placeholders/arcade.jpg and b/public/generated/placeholders/arcade.jpg differ diff --git a/public/generated/placeholders/atari2600.jpg b/public/generated/placeholders/atari2600.jpg index 57828194..ba6f4643 100644 Binary files a/public/generated/placeholders/atari2600.jpg and b/public/generated/placeholders/atari2600.jpg differ diff --git a/public/generated/placeholders/c64.jpg b/public/generated/placeholders/c64.jpg index 63d1bd85..c9e863f9 100644 Binary files a/public/generated/placeholders/c64.jpg and b/public/generated/placeholders/c64.jpg differ diff --git a/public/generated/placeholders/companies-codemasters.jpg b/public/generated/placeholders/companies-codemasters.jpg index 8c74c7c1..98de3005 100644 Binary files a/public/generated/placeholders/companies-codemasters.jpg and b/public/generated/placeholders/companies-codemasters.jpg differ diff --git a/public/generated/placeholders/compilers.jpg b/public/generated/placeholders/compilers.jpg index d2d8603b..24e924c8 100644 Binary files a/public/generated/placeholders/compilers.jpg and b/public/generated/placeholders/compilers.jpg differ diff --git a/public/generated/placeholders/copyright.jpg b/public/generated/placeholders/copyright.jpg index 0f9f2f5d..b5022eac 100644 Binary files a/public/generated/placeholders/copyright.jpg and b/public/generated/placeholders/copyright.jpg differ diff --git a/public/generated/placeholders/cracking-software.jpg b/public/generated/placeholders/cracking-software.jpg index f6591e2d..4a0495cf 100644 Binary files a/public/generated/placeholders/cracking-software.jpg and b/public/generated/placeholders/cracking-software.jpg differ diff --git a/public/generated/placeholders/disassemblers.jpg b/public/generated/placeholders/disassemblers.jpg index d4a9a123..8a8374b3 100644 Binary files a/public/generated/placeholders/disassemblers.jpg and b/public/generated/placeholders/disassemblers.jpg differ diff --git a/public/generated/placeholders/dos.jpg b/public/generated/placeholders/dos.jpg index ae39653b..149194c2 100644 Binary files a/public/generated/placeholders/dos.jpg and b/public/generated/placeholders/dos.jpg differ diff --git a/public/generated/placeholders/dreamcast.jpg b/public/generated/placeholders/dreamcast.jpg index 2bb97918..802586ba 100644 Binary files a/public/generated/placeholders/dreamcast.jpg and b/public/generated/placeholders/dreamcast.jpg differ diff --git a/public/generated/placeholders/ds-nitro-sdk.jpg b/public/generated/placeholders/ds-nitro-sdk.jpg index d88489c2..4f256f4d 100644 Binary files a/public/generated/placeholders/ds-nitro-sdk.jpg and b/public/generated/placeholders/ds-nitro-sdk.jpg differ diff --git a/public/generated/placeholders/ds.jpg b/public/generated/placeholders/ds.jpg index 8be2a1f9..a8bba0b0 100644 Binary files a/public/generated/placeholders/ds.jpg and b/public/generated/placeholders/ds.jpg differ diff --git a/public/generated/placeholders/dsfileformats.jpg b/public/generated/placeholders/dsfileformats.jpg index 06da6c5e..9a9375f5 100644 Binary files a/public/generated/placeholders/dsfileformats.jpg and b/public/generated/placeholders/dsfileformats.jpg differ diff --git a/public/generated/placeholders/fairchild-channel-f.jpg b/public/generated/placeholders/fairchild-channel-f.jpg index ccc8a936..855a07a1 100644 Binary files a/public/generated/placeholders/fairchild-channel-f.jpg and b/public/generated/placeholders/fairchild-channel-f.jpg differ diff --git a/public/generated/placeholders/game-architecture.jpg b/public/generated/placeholders/game-architecture.jpg index ff070e26..f24cda07 100644 Binary files a/public/generated/placeholders/game-architecture.jpg and b/public/generated/placeholders/game-architecture.jpg differ diff --git a/public/generated/placeholders/game-boy-advance-boot-rom-repository.jpg b/public/generated/placeholders/game-boy-advance-boot-rom-repository.jpg index b47527c6..5ad2d88c 100644 Binary files a/public/generated/placeholders/game-boy-advance-boot-rom-repository.jpg and b/public/generated/placeholders/game-boy-advance-boot-rom-repository.jpg differ diff --git a/public/generated/placeholders/game-boy-advance-sdk-samples.jpg b/public/generated/placeholders/game-boy-advance-sdk-samples.jpg index b0a223ac..ec88c9ec 100644 Binary files a/public/generated/placeholders/game-boy-advance-sdk-samples.jpg and b/public/generated/placeholders/game-boy-advance-sdk-samples.jpg differ diff --git a/public/generated/placeholders/game-boy-advance-tool-source-code.jpg b/public/generated/placeholders/game-boy-advance-tool-source-code.jpg index 6ed93acd..ab12d751 100644 Binary files a/public/generated/placeholders/game-boy-advance-tool-source-code.jpg and b/public/generated/placeholders/game-boy-advance-tool-source-code.jpg differ diff --git a/public/generated/placeholders/game-boy-color-boot-rom-repository.jpg b/public/generated/placeholders/game-boy-color-boot-rom-repository.jpg index 05fab444..db341981 100644 Binary files a/public/generated/placeholders/game-boy-color-boot-rom-repository.jpg and b/public/generated/placeholders/game-boy-color-boot-rom-repository.jpg differ diff --git a/public/generated/placeholders/game-maker.jpg b/public/generated/placeholders/game-maker.jpg index dace26e8..f591b349 100644 Binary files a/public/generated/placeholders/game-maker.jpg and b/public/generated/placeholders/game-maker.jpg differ diff --git a/public/generated/placeholders/gameboy.jpg b/public/generated/placeholders/gameboy.jpg index 0c44e58f..6cf8b131 100644 Binary files a/public/generated/placeholders/gameboy.jpg and b/public/generated/placeholders/gameboy.jpg differ diff --git a/public/generated/placeholders/gamecom.jpg b/public/generated/placeholders/gamecom.jpg index 08f62304..d33acebd 100644 Binary files a/public/generated/placeholders/gamecom.jpg and b/public/generated/placeholders/gamecom.jpg differ diff --git a/public/generated/placeholders/gamecube.jpg b/public/generated/placeholders/gamecube.jpg index 70890a33..6d297db7 100644 Binary files a/public/generated/placeholders/gamecube.jpg and b/public/generated/placeholders/gamecube.jpg differ diff --git a/public/generated/placeholders/gamegear.jpg b/public/generated/placeholders/gamegear.jpg index c70b02eb..89c99954 100644 Binary files a/public/generated/placeholders/gamegear.jpg and b/public/generated/placeholders/gamegear.jpg differ diff --git a/public/generated/placeholders/gamemaker-magazine.jpg b/public/generated/placeholders/gamemaker-magazine.jpg index 0b41b00b..a28d1473 100644 Binary files a/public/generated/placeholders/gamemaker-magazine.jpg and b/public/generated/placeholders/gamemaker-magazine.jpg differ diff --git a/public/generated/placeholders/games-engines.jpg b/public/generated/placeholders/games-engines.jpg index 4a81cf02..36a436dd 100644 Binary files a/public/generated/placeholders/games-engines.jpg and b/public/generated/placeholders/games-engines.jpg differ diff --git a/public/generated/placeholders/games-fileformats.jpg b/public/generated/placeholders/games-fileformats.jpg index e4930cb9..44f83c3c 100644 Binary files a/public/generated/placeholders/games-fileformats.jpg and b/public/generated/placeholders/games-fileformats.jpg differ diff --git a/public/generated/placeholders/games.jpg b/public/generated/placeholders/games.jpg index 7e650e27..9f24edf2 100644 Binary files a/public/generated/placeholders/games.jpg and b/public/generated/placeholders/games.jpg differ diff --git a/public/generated/placeholders/gba.jpg b/public/generated/placeholders/gba.jpg index bb042e71..0a5a8a10 100644 Binary files a/public/generated/placeholders/gba.jpg and b/public/generated/placeholders/gba.jpg differ diff --git a/public/generated/placeholders/ghidra.jpg b/public/generated/placeholders/ghidra.jpg index d949e6f2..57ede031 100644 Binary files a/public/generated/placeholders/ghidra.jpg and b/public/generated/placeholders/ghidra.jpg differ diff --git a/public/generated/placeholders/gigaleak-news-05.jpg b/public/generated/placeholders/gigaleak-news-05.jpg index 876df233..e4e9e841 100644 Binary files a/public/generated/placeholders/gigaleak-news-05.jpg and b/public/generated/placeholders/gigaleak-news-05.jpg differ diff --git a/public/generated/placeholders/gigaleak-news-11.jpg b/public/generated/placeholders/gigaleak-news-11.jpg index 2317c61c..1732072e 100644 Binary files a/public/generated/placeholders/gigaleak-news-11.jpg and b/public/generated/placeholders/gigaleak-news-11.jpg differ diff --git a/public/generated/placeholders/hacking.jpg b/public/generated/placeholders/hacking.jpg index 1a960a6f..b65415b6 100644 Binary files a/public/generated/placeholders/hacking.jpg and b/public/generated/placeholders/hacking.jpg differ diff --git a/public/generated/placeholders/handhelds.jpg b/public/generated/placeholders/handhelds.jpg index bbc21d1b..05cff50b 100644 Binary files a/public/generated/placeholders/handhelds.jpg and b/public/generated/placeholders/handhelds.jpg differ diff --git a/public/generated/placeholders/hardware-cheatcartridge.jpg b/public/generated/placeholders/hardware-cheatcartridge.jpg index 3858e0a7..22922dd3 100644 Binary files a/public/generated/placeholders/hardware-cheatcartridge.jpg and b/public/generated/placeholders/hardware-cheatcartridge.jpg differ diff --git a/public/generated/placeholders/hardware.jpg b/public/generated/placeholders/hardware.jpg index 809290b2..6058f891 100644 Binary files a/public/generated/placeholders/hardware.jpg and b/public/generated/placeholders/hardware.jpg differ diff --git a/public/generated/placeholders/incomplete.jpg b/public/generated/placeholders/incomplete.jpg index c5bb9c70..5d40d7b5 100644 Binary files a/public/generated/placeholders/incomplete.jpg and b/public/generated/placeholders/incomplete.jpg differ diff --git a/public/generated/placeholders/intellivision.jpg b/public/generated/placeholders/intellivision.jpg index d35a7c78..6d87374c 100644 Binary files a/public/generated/placeholders/intellivision.jpg and b/public/generated/placeholders/intellivision.jpg differ diff --git a/public/generated/placeholders/ios.jpg b/public/generated/placeholders/ios.jpg index 99062c9e..c2ab65bf 100644 Binary files a/public/generated/placeholders/ios.jpg and b/public/generated/placeholders/ios.jpg differ diff --git a/public/generated/placeholders/jaguar.jpg b/public/generated/placeholders/jaguar.jpg index 2a577afa..d9ab0ad9 100644 Binary files a/public/generated/placeholders/jaguar.jpg and b/public/generated/placeholders/jaguar.jpg differ diff --git a/public/generated/placeholders/krome-merkury-engine.jpg b/public/generated/placeholders/krome-merkury-engine.jpg index d144358e..2c8fc310 100644 Binary files a/public/generated/placeholders/krome-merkury-engine.jpg and b/public/generated/placeholders/krome-merkury-engine.jpg differ diff --git a/public/generated/placeholders/leaks.jpg b/public/generated/placeholders/leaks.jpg index 61538d5f..6005dd1f 100644 Binary files a/public/generated/placeholders/leaks.jpg and b/public/generated/placeholders/leaks.jpg differ diff --git a/public/generated/placeholders/libretro.jpg b/public/generated/placeholders/libretro.jpg index df2b5b57..31bac0dd 100644 Binary files a/public/generated/placeholders/libretro.jpg and b/public/generated/placeholders/libretro.jpg differ diff --git a/public/generated/placeholders/lucasarts-zino-and-zed.jpg b/public/generated/placeholders/lucasarts-zino-and-zed.jpg index 8906c4d7..592fd421 100644 Binary files a/public/generated/placeholders/lucasarts-zino-and-zed.jpg and b/public/generated/placeholders/lucasarts-zino-and-zed.jpg differ diff --git a/public/generated/placeholders/mame-source-code.jpg b/public/generated/placeholders/mame-source-code.jpg index 1d2e62ed..af5abbfc 100644 Binary files a/public/generated/placeholders/mame-source-code.jpg and b/public/generated/placeholders/mame-source-code.jpg differ diff --git a/public/generated/placeholders/mastersystem.jpg b/public/generated/placeholders/mastersystem.jpg index 25e111d3..929661f7 100644 Binary files a/public/generated/placeholders/mastersystem.jpg and b/public/generated/placeholders/mastersystem.jpg differ diff --git a/public/generated/placeholders/maths.jpg b/public/generated/placeholders/maths.jpg index 8ecf1001..7d45be65 100644 Binary files a/public/generated/placeholders/maths.jpg and b/public/generated/placeholders/maths.jpg differ diff --git a/public/generated/placeholders/matrix.jpg b/public/generated/placeholders/matrix.jpg index 29719b85..14ef02d2 100644 Binary files a/public/generated/placeholders/matrix.jpg and b/public/generated/placeholders/matrix.jpg differ diff --git a/public/generated/placeholders/maya.jpg b/public/generated/placeholders/maya.jpg index aa0af310..a5a74625 100644 Binary files a/public/generated/placeholders/maya.jpg and b/public/generated/placeholders/maya.jpg differ diff --git a/public/generated/placeholders/megadrive.jpg b/public/generated/placeholders/megadrive.jpg index a8262e42..906aecec 100644 Binary files a/public/generated/placeholders/megadrive.jpg and b/public/generated/placeholders/megadrive.jpg differ diff --git a/public/generated/placeholders/msx.jpg b/public/generated/placeholders/msx.jpg index b6da2817..396459a7 100644 Binary files a/public/generated/placeholders/msx.jpg and b/public/generated/placeholders/msx.jpg differ diff --git a/public/generated/placeholders/n64.jpg b/public/generated/placeholders/n64.jpg index 2989aa33..db3aefeb 100644 Binary files a/public/generated/placeholders/n64.jpg and b/public/generated/placeholders/n64.jpg differ diff --git a/public/generated/placeholders/nes-emulation.jpg b/public/generated/placeholders/nes-emulation.jpg index af22cb25..0025ddd7 100644 Binary files a/public/generated/placeholders/nes-emulation.jpg and b/public/generated/placeholders/nes-emulation.jpg differ diff --git a/public/generated/placeholders/netcard.jpg b/public/generated/placeholders/netcard.jpg index 12458207..46bb6381 100644 Binary files a/public/generated/placeholders/netcard.jpg and b/public/generated/placeholders/netcard.jpg differ diff --git a/public/generated/placeholders/nintendo-3ds-development-kit.jpg b/public/generated/placeholders/nintendo-3ds-development-kit.jpg index 2942bc4d..cb44d66f 100644 Binary files a/public/generated/placeholders/nintendo-3ds-development-kit.jpg and b/public/generated/placeholders/nintendo-3ds-development-kit.jpg differ diff --git a/public/generated/placeholders/official-playstation4-devkit.jpg b/public/generated/placeholders/official-playstation4-devkit.jpg index 8c7573d2..52a59ca9 100644 Binary files a/public/generated/placeholders/official-playstation4-devkit.jpg and b/public/generated/placeholders/official-playstation4-devkit.jpg differ diff --git a/public/generated/placeholders/official-pokemon-mini-sdk.jpg b/public/generated/placeholders/official-pokemon-mini-sdk.jpg index ebe12078..bf634e51 100644 Binary files a/public/generated/placeholders/official-pokemon-mini-sdk.jpg and b/public/generated/placeholders/official-pokemon-mini-sdk.jpg differ diff --git a/public/generated/placeholders/official-vita-sdk.jpg b/public/generated/placeholders/official-vita-sdk.jpg index fd689578..1597c865 100644 Binary files a/public/generated/placeholders/official-vita-sdk.jpg and b/public/generated/placeholders/official-vita-sdk.jpg differ diff --git a/public/generated/placeholders/pc-88.jpg b/public/generated/placeholders/pc-88.jpg index 20c5ff6c..1fae6c88 100644 Binary files a/public/generated/placeholders/pc-88.jpg and b/public/generated/placeholders/pc-88.jpg differ diff --git a/public/generated/placeholders/pc-engine.jpg b/public/generated/placeholders/pc-engine.jpg index 368b0378..9b0d619f 100644 Binary files a/public/generated/placeholders/pc-engine.jpg and b/public/generated/placeholders/pc-engine.jpg differ diff --git a/public/generated/placeholders/pc.jpg b/public/generated/placeholders/pc.jpg index 3c4798a1..824e7876 100644 Binary files a/public/generated/placeholders/pc.jpg and b/public/generated/placeholders/pc.jpg differ diff --git a/public/generated/placeholders/pdbfilereversing.jpg b/public/generated/placeholders/pdbfilereversing.jpg index cf9f23c5..c528dd77 100644 Binary files a/public/generated/placeholders/pdbfilereversing.jpg and b/public/generated/placeholders/pdbfilereversing.jpg differ diff --git a/public/generated/placeholders/pilotwings-2d-art-workspace.jpg b/public/generated/placeholders/pilotwings-2d-art-workspace.jpg index b96598c9..8d7e3492 100644 Binary files a/public/generated/placeholders/pilotwings-2d-art-workspace.jpg and b/public/generated/placeholders/pilotwings-2d-art-workspace.jpg differ diff --git a/public/generated/placeholders/pokemon-original-source-code.jpg b/public/generated/placeholders/pokemon-original-source-code.jpg index 9e59528e..bd530acc 100644 Binary files a/public/generated/placeholders/pokemon-original-source-code.jpg and b/public/generated/placeholders/pokemon-original-source-code.jpg differ diff --git a/public/generated/placeholders/pokemonredblue.jpg b/public/generated/placeholders/pokemonredblue.jpg new file mode 100644 index 00000000..82d09732 Binary files /dev/null and b/public/generated/placeholders/pokemonredblue.jpg differ diff --git a/public/generated/placeholders/powerpc.jpg b/public/generated/placeholders/powerpc.jpg index c4d5d856..83dc1e63 100644 Binary files a/public/generated/placeholders/powerpc.jpg and b/public/generated/placeholders/powerpc.jpg differ diff --git a/public/generated/placeholders/programming-languages.jpg b/public/generated/placeholders/programming-languages.jpg index ead815cf..b6f8fca0 100644 Binary files a/public/generated/placeholders/programming-languages.jpg and b/public/generated/placeholders/programming-languages.jpg differ diff --git a/public/generated/placeholders/ps2.jpg b/public/generated/placeholders/ps2.jpg index 403e0ee2..7004b143 100644 Binary files a/public/generated/placeholders/ps2.jpg and b/public/generated/placeholders/ps2.jpg differ diff --git a/public/generated/placeholders/ps3.jpg b/public/generated/placeholders/ps3.jpg index f0da54bb..86cd3dd9 100644 Binary files a/public/generated/placeholders/ps3.jpg and b/public/generated/placeholders/ps3.jpg differ diff --git a/public/generated/placeholders/ps4.jpg b/public/generated/placeholders/ps4.jpg index 9932284c..78c68000 100644 Binary files a/public/generated/placeholders/ps4.jpg and b/public/generated/placeholders/ps4.jpg differ diff --git a/public/generated/placeholders/psp.jpg b/public/generated/placeholders/psp.jpg index 0a3348fd..31b797c9 100644 Binary files a/public/generated/placeholders/psp.jpg and b/public/generated/placeholders/psp.jpg differ diff --git a/public/generated/placeholders/pspsdk.jpg b/public/generated/placeholders/pspsdk.jpg index aa16f0c1..b81da39c 100644 Binary files a/public/generated/placeholders/pspsdk.jpg and b/public/generated/placeholders/pspsdk.jpg differ diff --git a/public/generated/placeholders/quaternions.jpg b/public/generated/placeholders/quaternions.jpg index ac1a511c..9ae66488 100644 Binary files a/public/generated/placeholders/quaternions.jpg and b/public/generated/placeholders/quaternions.jpg differ diff --git a/public/generated/placeholders/retro-gamer.jpg b/public/generated/placeholders/retro-gamer.jpg index 5e1d83db..b71fdc49 100644 Binary files a/public/generated/placeholders/retro-gamer.jpg and b/public/generated/placeholders/retro-gamer.jpg differ diff --git a/public/generated/placeholders/saturn.jpg b/public/generated/placeholders/saturn.jpg index a079bc45..fea9f171 100644 Binary files a/public/generated/placeholders/saturn.jpg and b/public/generated/placeholders/saturn.jpg differ diff --git a/public/generated/placeholders/sdks.jpg b/public/generated/placeholders/sdks.jpg index a55f0a29..5b0b5901 100644 Binary files a/public/generated/placeholders/sdks.jpg and b/public/generated/placeholders/sdks.jpg differ diff --git a/public/generated/placeholders/sega-mega-drive-genesis-sdk.jpg b/public/generated/placeholders/sega-mega-drive-genesis-sdk.jpg index 22d4fffc..9d9694ba 100644 Binary files a/public/generated/placeholders/sega-mega-drive-genesis-sdk.jpg and b/public/generated/placeholders/sega-mega-drive-genesis-sdk.jpg differ diff --git a/public/generated/placeholders/sg1000.jpg b/public/generated/placeholders/sg1000.jpg index 9c8304a0..e504e167 100644 Binary files a/public/generated/placeholders/sg1000.jpg and b/public/generated/placeholders/sg1000.jpg differ diff --git a/public/generated/placeholders/simcity-snes-2d-art-workspace.jpg b/public/generated/placeholders/simcity-snes-2d-art-workspace.jpg index 1274e4c2..11f7866a 100644 Binary files a/public/generated/placeholders/simcity-snes-2d-art-workspace.jpg and b/public/generated/placeholders/simcity-snes-2d-art-workspace.jpg differ diff --git a/public/generated/placeholders/simpsons-hit-and-run-source-code.jpg b/public/generated/placeholders/simpsons-hit-and-run-source-code.jpg index e077d213..860901af 100644 Binary files a/public/generated/placeholders/simpsons-hit-and-run-source-code.jpg and b/public/generated/placeholders/simpsons-hit-and-run-source-code.jpg differ diff --git a/public/generated/placeholders/snes-file-formats.jpg b/public/generated/placeholders/snes-file-formats.jpg index 5db9910a..84da5801 100644 Binary files a/public/generated/placeholders/snes-file-formats.jpg and b/public/generated/placeholders/snes-file-formats.jpg differ diff --git a/public/generated/placeholders/snes.jpg b/public/generated/placeholders/snes.jpg index 64128600..049e1c02 100644 Binary files a/public/generated/placeholders/snes.jpg and b/public/generated/placeholders/snes.jpg differ diff --git a/public/generated/placeholders/star-fox-2-source-code.jpg b/public/generated/placeholders/star-fox-2-source-code.jpg index 220600b4..a7f4f14f 100644 Binary files a/public/generated/placeholders/star-fox-2-source-code.jpg and b/public/generated/placeholders/star-fox-2-source-code.jpg differ diff --git a/public/generated/placeholders/star-fox-source-code.jpg b/public/generated/placeholders/star-fox-source-code.jpg index 5672634d..1b9c8f66 100644 Binary files a/public/generated/placeholders/star-fox-source-code.jpg and b/public/generated/placeholders/star-fox-source-code.jpg differ diff --git a/public/generated/placeholders/starfox2-2d-art-workspace.jpg b/public/generated/placeholders/starfox2-2d-art-workspace.jpg index 2eb8d52f..ae3f13a0 100644 Binary files a/public/generated/placeholders/starfox2-2d-art-workspace.jpg and b/public/generated/placeholders/starfox2-2d-art-workspace.jpg differ diff --git a/public/generated/placeholders/stunt-race-fx-2d-art-workspace.jpg b/public/generated/placeholders/stunt-race-fx-2d-art-workspace.jpg index a4cee531..2e7beefe 100644 Binary files a/public/generated/placeholders/stunt-race-fx-2d-art-workspace.jpg and b/public/generated/placeholders/stunt-race-fx-2d-art-workspace.jpg differ diff --git a/public/generated/placeholders/super-famicom-sfx-dos.jpg b/public/generated/placeholders/super-famicom-sfx-dos.jpg index 97e276de..19860b47 100644 Binary files a/public/generated/placeholders/super-famicom-sfx-dos.jpg and b/public/generated/placeholders/super-famicom-sfx-dos.jpg differ diff --git a/public/generated/placeholders/super-mario-bros.jpg b/public/generated/placeholders/super-mario-bros.jpg index 2d2c7ed8..64585212 100644 Binary files a/public/generated/placeholders/super-mario-bros.jpg and b/public/generated/placeholders/super-mario-bros.jpg differ diff --git a/public/generated/placeholders/super-mario-collection-source-code.jpg b/public/generated/placeholders/super-mario-collection-source-code.jpg index 7c86d22c..395f09f8 100644 Binary files a/public/generated/placeholders/super-mario-collection-source-code.jpg and b/public/generated/placeholders/super-mario-collection-source-code.jpg differ diff --git a/public/generated/placeholders/super-mario-kart-2d-art-workspace.jpg b/public/generated/placeholders/super-mario-kart-2d-art-workspace.jpg index b1ee4c72..76a59674 100644 Binary files a/public/generated/placeholders/super-mario-kart-2d-art-workspace.jpg and b/public/generated/placeholders/super-mario-kart-2d-art-workspace.jpg differ diff --git a/public/generated/placeholders/super-mario-kart-source-code.jpg b/public/generated/placeholders/super-mario-kart-source-code.jpg index dc031836..1aedec64 100644 Binary files a/public/generated/placeholders/super-mario-kart-source-code.jpg and b/public/generated/placeholders/super-mario-kart-source-code.jpg differ diff --git a/public/generated/placeholders/symbols.jpg b/public/generated/placeholders/symbols.jpg index 1f121b5b..a7942822 100644 Binary files a/public/generated/placeholders/symbols.jpg and b/public/generated/placeholders/symbols.jpg differ diff --git a/public/generated/placeholders/tools.jpg b/public/generated/placeholders/tools.jpg index a1b2287f..b816a173 100644 Binary files a/public/generated/placeholders/tools.jpg and b/public/generated/placeholders/tools.jpg differ diff --git a/public/generated/placeholders/tutorials-gdb-stub-in-c.jpg b/public/generated/placeholders/tutorials-gdb-stub-in-c.jpg index f67f5446..cbd61f24 100644 Binary files a/public/generated/placeholders/tutorials-gdb-stub-in-c.jpg and b/public/generated/placeholders/tutorials-gdb-stub-in-c.jpg differ diff --git a/public/generated/placeholders/udk-ultimate.jpg b/public/generated/placeholders/udk-ultimate.jpg index a93cb8fd..6ad4e0ed 100644 Binary files a/public/generated/placeholders/udk-ultimate.jpg and b/public/generated/placeholders/udk-ultimate.jpg differ diff --git a/public/generated/placeholders/unity3d.jpg b/public/generated/placeholders/unity3d.jpg index 24d939b4..02f175a1 100644 Binary files a/public/generated/placeholders/unity3d.jpg and b/public/generated/placeholders/unity3d.jpg differ diff --git a/public/generated/placeholders/vectors.jpg b/public/generated/placeholders/vectors.jpg index 24f5c3ad..b8d8083b 100644 Binary files a/public/generated/placeholders/vectors.jpg and b/public/generated/placeholders/vectors.jpg differ diff --git a/public/generated/placeholders/vectrex.jpg b/public/generated/placeholders/vectrex.jpg index 92f3f209..6c46ae35 100644 Binary files a/public/generated/placeholders/vectrex.jpg and b/public/generated/placeholders/vectrex.jpg differ diff --git a/public/generated/placeholders/vita.jpg b/public/generated/placeholders/vita.jpg index abd92c76..81748671 100644 Binary files a/public/generated/placeholders/vita.jpg and b/public/generated/placeholders/vita.jpg differ diff --git a/public/generated/placeholders/wii.jpg b/public/generated/placeholders/wii.jpg index 36fe07fe..a145b2b7 100644 Binary files a/public/generated/placeholders/wii.jpg and b/public/generated/placeholders/wii.jpg differ diff --git a/public/generated/placeholders/wiiu.jpg b/public/generated/placeholders/wiiu.jpg index ed7075c9..b4c44f41 100644 Binary files a/public/generated/placeholders/wiiu.jpg and b/public/generated/placeholders/wiiu.jpg differ diff --git a/public/generated/placeholders/wild-trax-source-code.jpg b/public/generated/placeholders/wild-trax-source-code.jpg index 07ff0bc8..73a41649 100644 Binary files a/public/generated/placeholders/wild-trax-source-code.jpg and b/public/generated/placeholders/wild-trax-source-code.jpg differ diff --git a/public/generated/placeholders/windowsexecutables.jpg b/public/generated/placeholders/windowsexecutables.jpg index 8c48caf9..c9febd47 100644 Binary files a/public/generated/placeholders/windowsexecutables.jpg and b/public/generated/placeholders/windowsexecutables.jpg differ diff --git a/public/generated/placeholders/wonderswan.jpg b/public/generated/placeholders/wonderswan.jpg index 45bd0fe9..b3dcac07 100644 Binary files a/public/generated/placeholders/wonderswan.jpg and b/public/generated/placeholders/wonderswan.jpg differ diff --git a/public/generated/placeholders/xbox.jpg b/public/generated/placeholders/xbox.jpg index 77d9c68a..ab1ec373 100644 Binary files a/public/generated/placeholders/xbox.jpg and b/public/generated/placeholders/xbox.jpg differ diff --git a/public/generated/placeholders/xbox360.jpg b/public/generated/placeholders/xbox360.jpg index 35ba6872..10a06ead 100644 Binary files a/public/generated/placeholders/xbox360.jpg and b/public/generated/placeholders/xbox360.jpg differ diff --git a/public/generated/placeholders/yoshis-island-source-code.jpg b/public/generated/placeholders/yoshis-island-source-code.jpg index 3680c145..e1922dc8 100644 Binary files a/public/generated/placeholders/yoshis-island-source-code.jpg and b/public/generated/placeholders/yoshis-island-source-code.jpg differ diff --git a/public/generated/placeholders/zelda-a-link-to-the-past-source-code.jpg b/public/generated/placeholders/zelda-a-link-to-the-past-source-code.jpg index 2138328e..4e0c6ce2 100644 Binary files a/public/generated/placeholders/zelda-a-link-to-the-past-source-code.jpg and b/public/generated/placeholders/zelda-a-link-to-the-past-source-code.jpg differ diff --git a/public/generated/placeholders/zelda-links-awakening-art-workspace.jpg b/public/generated/placeholders/zelda-links-awakening-art-workspace.jpg index bf0419b1..6ea814a1 100644 Binary files a/public/generated/placeholders/zelda-links-awakening-art-workspace.jpg and b/public/generated/placeholders/zelda-links-awakening-art-workspace.jpg differ diff --git a/public/generated/placeholders/zelda-links-awakening-dx.jpg b/public/generated/placeholders/zelda-links-awakening-dx.jpg index a0f3d906..78ae6ccf 100644 Binary files a/public/generated/placeholders/zelda-links-awakening-dx.jpg and b/public/generated/placeholders/zelda-links-awakening-dx.jpg differ diff --git a/public/generated/placeholders/zxspectrum.jpg b/public/generated/placeholders/zxspectrum.jpg index 97c32235..65b448c3 100644 Binary files a/public/generated/placeholders/zxspectrum.jpg and b/public/generated/placeholders/zxspectrum.jpg differ diff --git a/scripts/generate-placeholder-social-images.js b/scripts/generate-placeholder-social-images.js index 267dd8a1..bd9781e8 100755 --- a/scripts/generate-placeholder-social-images.js +++ b/scripts/generate-placeholder-social-images.js @@ -324,6 +324,47 @@ function resolveCategories(metadata) { return ['Reverse Engineering']; } +function normalizeFrontmatterImageList(value) { + if (Array.isArray(value)) { + return value + .map((item) => String(item || '').trim()) + .filter(Boolean); + } + if (typeof value === 'string' && value.trim()) { + return [value.trim()]; + } + return []; +} + +function resolveRepoAssetPath(assetPath) { + const normalizedPath = String(assetPath || '').trim(); + if (!normalizedPath || /^[a-z]+:\/\//i.test(normalizedPath)) { + return ''; + } + if (normalizedPath.startsWith(ROOT_DIR)) { + return normalizedPath; + } + return path.join(ROOT_DIR, normalizedPath.replace(/^\//, '')); +} + +function resolvePlaceholderImagePaths(metadata, categoryImages, limit = 2) { + const customImagePaths = normalizeFrontmatterImageList(metadata.placeholderimages) + .map(resolveRepoAssetPath) + .filter((imagePath) => imagePath && fs.existsSync(imagePath)); + + const categoryImagePaths = resolveCategories(metadata) + .slice(0, limit) + .map((category) => { + const categoryImageRelativePath = categoryImages[category]; + return categoryImageRelativePath + ? resolveRepoAssetPath(categoryImageRelativePath) + : ''; + }) + .filter((imagePath) => imagePath && fs.existsSync(imagePath)); + + return [...new Set([...customImagePaths, ...categoryImagePaths])].slice(0, limit); +} + function wrapTitle(title, maxLineLength = 31, maxLines = 3) { const words = String(title || '').trim().split(/\s+/).filter(Boolean); if (words.length === 0) { @@ -367,10 +408,11 @@ function wrapTitle(title, maxLineLength = 31, maxLines = 3) { }); } -function getInputTimestamp(filePath, configPath) { +function getInputTimestamp(filePath, configPath, dependencyPaths = []) { return Math.max( - fs.statSync(filePath).mtimeMs, - fs.statSync(configPath).mtimeMs + ...[filePath, configPath, ...dependencyPaths] + .filter((dependencyPath) => dependencyPath && fs.existsSync(dependencyPath)) + .map((dependencyPath) => fs.statSync(dependencyPath).mtimeMs) ); } @@ -412,21 +454,21 @@ function buildGeoPatternSvg(seed) { } } -function buildSvg({ title, categories, categoryImagePaths, seed }) { +function buildSvg({ title, categories, placeholderImagePaths, seed }) { const titleLines = wrapTitle(title); const titleY = titleLines.length === 1 ? 132 : 123; const categoryText = categories .slice(0, 2) .map((category) => String(category).replace(/-/g, ' ').toUpperCase()) .join(' • '); - const categoryImageHrefs = categoryImagePaths.map((categoryImagePath) => fileToDataUri(categoryImagePath)); + const categoryImageHrefs = placeholderImagePaths.map((categoryImagePath) => fileToDataUri(categoryImagePath)); const logoImageHref = fileToDataUri(RR_LOGO_IMAGE); const geoPatternSvg = buildGeoPatternSvg(seed); const geoPatternHref = geoPatternSvg ? `data:image/svg+xml;base64,${Buffer.from(geoPatternSvg).toString('base64')}` : ''; const textX = 171; - const categoryImageLayouts = getCategoryImageLayouts(categoryImagePaths); + const categoryImageLayouts = getCategoryImageLayouts(placeholderImagePaths); const titleTspans = titleLines .slice(0, 2) @@ -474,7 +516,7 @@ function buildOutputPath(permalink) { }; } -function convertPngToJpeg(inputPath, outputPath, quality = '88') { +function convertPngToJpeg(inputPath, outputPath, quality = '80') { if (IMAGE_MAGICK_CONVERT_PATH) { execFileSync(IMAGE_MAGICK_CONVERT_PATH, [ inputPath, @@ -588,17 +630,10 @@ function main() { } const categories = resolveCategories(metadata).slice(0, 2); - const categoryImagePaths = categories - .map((category) => { - const categoryImageRelativePath = categoryImages[category]; - return categoryImageRelativePath - ? path.join(ROOT_DIR, categoryImageRelativePath.replace(/^\//, '')) - : ''; - }) - .filter(Boolean); + const placeholderImagePaths = resolvePlaceholderImagePaths(metadata, categoryImages); const outputPaths = buildOutputPath(metadata.permalink); - const inputTimestamp = getInputTimestamp(filePath, CONFIG_PATH); + const inputTimestamp = getInputTimestamp(filePath, CONFIG_PATH, placeholderImagePaths); const jpgGenerationAvailable = canGenerateJpg(); const jpgUpToDate = !jpgGenerationAvailable || isUpToDate(outputPaths.jpg, inputTimestamp); @@ -616,7 +651,7 @@ function main() { const svgContent = buildSvg({ title: metadata.shorttitle || metadata.title, categories, - categoryImagePaths, + placeholderImagePaths, seed });