SheatNoisette's Warehouse - rambling

The Game Porting Paradox

2025-11-07T00:00:00+01:00

Please note that I'm not professional game developer and this is based on my own observations and similar issues I encountered while working on my past released and unreleased projects.

We live in a world where a game can sell ten million copies, spawn a Netflix series and still never see a port because someone, somewhere, signed a broken contract. Imagine, that you've just finished building a house. It's awesome: It has a pizzeria-grade pizza oven and a secret passage to Skyrim. Now imagine someone walks up and says: "Cool Bro ! Now rebuild this house, brick for brick, but the bricks are made of wool and the foundation has to be rotated 90 degrees and also the wool are on fire. If you don't do this we're calling a demolition company to tear legally your house down bruh".

That's basically porting a game on some platform with a custom engine if you don't plan portability early, use portable engines or if you don't fully own the intellectual property of your game.

Every single platform has its own proprietary graphics APIs, certification rules and hardware quirks. A game written for PlatformBlue's graphics API can't just hop over to Xbox's DirectX 12 Ultimate without a near full rewrite of rendering backend (if they have remotely the same calls). And don't think about bringing that code to macOS where Apple made their own API Metal, which works only on i/mac-devices.

How you can say the same about Audio APIs, Filesystem hierarchies (Linux it's /usr/bin, Windows uses C:\Program Files), Binary formats, Input handling...

If your game uses a middleware (See my old post on that) like a physics engine, an audio library or a networking stack: you may need to re-license every single one of those for the new platform. And if the middleware company went out of business and shipped only a binary to you in 2011? You're stuck. Maybe that the game engine is tightly coupled to a middleware, a specific architecture or simply breaks on other compilers.

Let's talk about exclusivity deals, you know that JRPG that's been locked to PlayStation since 2010? The one that would may sell a million copies on Steam in a week? Maybe someone probably paid for permanent exclusivity on their platform and no amount of begging, petitions or sacrifices to the gaming gods will free it.

The publisher owns the IP, but the developer owns the engine / game code, the soundtrack may be licensed, but only for console releases.

delistedgames.com - Transformer Devastation, apparently delisted for IP rights

Maybe the voice actors have clauses that prevent reuse of their lines on PC because someone may want use them for another thing. And sometimes, just sometimes, the game's source code is just gone (Silent Hills 3).

Not metaphorically gone. Not "we misplaced it behind the couch". May it be deleted to save server space. Lost in a studio bankruptcy. Or threw across hard drives in a storage unit in Auvergne-Rhone Alpes. Some classic games cannot be ported because the literal raw instructions for building them no longer exist and reverse engineering to rebuild a source tree is as long as making a remake for 60€.

decomp.dev - A tracker for game reverse engineering and recompilation

You can't just "recompile" a game from the disc to make few changes. That's like trying to reconstruct a cake from the half-eaten crumbs. You need the source code (or reconstruct an editable "code"), the raw assets (If they are packed), the tools, the documentation (If any) and the knowledge of the original team to recontextualize everything, who have all moved on, changed careers or sells crypto.

Now, a game can be wildly profitable on one platform and still never see a port because:

The porting and validation budget would cut into the sequel budget,
The porting cost would exceed the revenue,
The publisher doesn't want to "dilute the brand" by making it too available,
The platform holder offers a bigger check for exclusivity than the port would earn,
The studio would rather make new games than old games work on new systems.

And let's not forget piracy which is a bogus reason: "We can't port to PC, it'll just get pirated!", while ignoring the fact that every game gets pirated anyway (Even on console, Denuvo has a Switch port) and legitimate customers outnumber pirates (see the GoG initiative).

And so on Reddit you will read: "I WILL GIVE YOU MONEY PLEASE TAKE MY MONEY JUST LET ME PLAY THE GAME I DON'T WANNA BUY A PLATFORMBLUE".

Now, let's go on a tangent, you thought console-to-PC was bad? I limited PC to Windows/x86, but what about Linux / MacOS ?

Windows has DirectX and is the most supported graphics API, but also the most proprietary. Want to use Vulkan? Sure, good luck!. And don't even think about OpenGL to rebuild your next-gen low-level graphic pipeline around...

https://alain.xyz - Short list of other headers for Graphics API

Linux has Vulkan, OpenGL and a hundred different window managers, audio servers and driver combinations. Your game might run perfectly on Ubuntu 24.04 with an AMD GPU and PipeWire, but crash instantly on Arch with an Nvidia card and JACK. And the community will blame the dev for not supporting their obscure setup. Also, the market share is tiny, so publishers ignore it entirely and rely on Proton/Wine, because Win32 API is a more stable API/ABI.

Like I said before, Apple has Metal, which is fast and tuned for their chip but only works on macOS. No Vulkan. No OpenGL. No DirectX. Just Metal. And if you want to use a compatibility layer like MoltenVK? Apple won't endorse it, so you're on your own if it breaks unfortunately. The macOS OpenGL supports up to OpenGL 4.1 and, from the Asahi Linux team, the implementation is not conformant.

So now you're not just porting a game. You're building three different versions, each with its own graphics pipeline, audio backend, input handling and certification process. And for what? A player base that's fractioned, hostile and some are really convinced you're part of a dumb conspiracy to destroy their platform.

And if we still have the source code, no expensive middleware, custom IP and that player wants the game, it may not still happen.

Games still don't get ported because someone, somewhere, decided it wasn't worth the effort. It's not always some technical or legal obstacle. Sometimes laziness or short sightedness. A publisher looks at a classic and says: "Heh, let's make a live service battle royale instead" (Unreal Tournament?).

What's left ? Console exclusives that die with their hardware and communities begging for ports that will never never come.

We could demand better preservation, we could push for definitive cross-platform standards, we could refuse to buy exclusivity deals that lock games behind gates. We won't, because we're too busy arguing about frame rates and DLCs while the games we love may disappear forever.

Maybe that's why your favorite game will never get a port. Not because it's impossible, not because it's unprofitable. But because the system is broken and nobody with the power to fix it cares enough to try. At least, some emulators and compatiblity layers exists for this, even if they are imperfect: emulation, Proton/Wine on Linux, MoltenVK for an 90% substitute of Vulkan for macOS, ANGLE/BGFX for graphics backend layer, SDL for input/window management, ...

That's it for me folks, I should tone down the salt one day.

See you next time.

Designing a Hardware Product

2025-10-25T00:00:00+02:00

Usual disclaimer: I professionally work in embedded systems and have had the chance to see products made from the ground up. I'm not an expert on this subject (far from it), see this as an educated guess. Do not use this post as a reference for designing products. It was written for those who have no experience making hardware products.

Few days ago, I read someone saying in a server:

Guys, I would kill for an fully open-source GNU/Linux smartwatch... Why someone doesn't do it?

After going back and forth to tell them that making a physical product is really hard and it would take at least 150K€+ to make a fully working near production ready prototype. It is not the first time I saw someone asking why someone does not "make a physical product", so there am I. Heh, at least this would avoid repeat myself and I would just link this article.

As a thought exercice, let's attempt to design a GNU/Linux based smartwatch from scratch, from the prototype to the full on-the-shelve release.

For this experiment, I will skip a lot of details and simplify much of the process. Doing a simple but in-depth analysis would take multiple months, a multi-part series and many documents. Documenting the full journey of taking a product to shelves would take years. Also, let's put the market analysis aside and not worry about a small chance of being profitable.

For this example, we will be using the POC-EVT-DVT-PVT model. To avoid writing a lengthy post on it, there's the short version:

POC (Proof Of Concept): Validates your idea - You test your idea
EVT (Engineering Validation Test): Make a production worthy unit - You iterate on your product with mutiple versions (EVT-1/EVT-2 and more),
DVT (Design Validation Test) Assesses scaling feasibility - You freeze your product (minor small touchups and fixes), do validation and final certification,
PVT (Product Validation Test): Mass production readiness - You tweak the mass production with your suppliers, check the quality of the first products you build, production line tests, etc.

Now, how to design a GNU/Linux (Not Android based) smartwatch from (near) scratch to be released to the shelves ?

Specifications

Before even working on anything, what are the specifications we would want for a smart watch ? What do we need ? What do we want ?

For the first pass, what someone would maybe tell you at the first glance may be this:

The smartwatch must be able to recieve notifications, tell time, could install apps and have health sensing capabilities.

Most would take that this is a great specification, now let's put it on a Word document and let's go prototyping! Absolutely not.

Let's do another pass on it.

Now:

The smartwatch must be able to recieve notifications, tell time, have a tiny touch screen, tell notifications, tell the time, vibrate when a notification is done, having 24h of battery life and be able to measure BPM.

This is better but not sufficient, maybe for a meeting or a pitch. Let's switch for a more objective technical checklist. Now, let's port the specifications to this list, which better than a long document in my view.

I will leave for the reader more surface level brainstorming methodologies based around the functional design principle (APTE method, ...). Please note that there's standards for this kind of analysis (NF X50-100 came to mind).

ID	Type	Description
SW-01	Software	The product must be Linux-based.
SW-02	Software	The product should integrate only open-source software
EE-01	Electrical	The product must have a 2 inch touch screen.
GN-01	General	The product must make a haptic feedback when a notification is recieved
ME-01	Mechanical	The product must have a adjustable wirstband.
EE-02	Electrical	The product must have at least 512MB of RAM
EE-03	Electrical	The produst must have at least 1GB of non-volatile flash.
GE-02	General	The product must be able to connect to WiFi
GE-03	General	The product must be able to connect to bluetooth devices
GE-04	General	The product must be able to read the heath rate with a PPG sensor
EE-04	Electrical	The product should be able to read the heart rate within 5+- BPM range
SW-03	Software	The product must be able to detect an oritentation
GE-05	General	The product must contains a motor for haptic feedback
EE-05	Electrical	The product must use a ERM haptic motor.
ME-02	Mechanical	The product should be IP-XX resitant.
EE-06	Electrical	The product must be able to detect if the battery is being charged
EE-07	Electrical	The product must be able to power up under deep discharge
GN-06	General	The product must be able to tell the battery capacity
GN-07	General	The product must have a battery allowing 6 hours of battery life
EE-08	Electrical	The product must contain at least a 100mAh battery
...	...	....
LG-01	Legal	The product must be CE / FCC compliant

This list would be long, with constant back-and-forth among multiple engineers, designers and possibly every party or subcontractor working on this product. As development progresses, this list will evolve. It is not shocking that this kind of document has hundreds of items, ranging from software and electrical to legal, mechanical design and more. This list, though very incomplete, gives a good idea of what it looks like. At the first stage, the list may be wrong and overly ambitious.

Attentive readers might see in this checklist that I say few technical specifications: "512MB of RAM", "2 Inch touch-screen", "ERM motor"...

While doing the analysis, the need will be translated into a reasonable and factual technical element. We know that we want "a GNU/Linux smartwatch". We know that to have haptic feedback, we need some kind of motor.

The first questions that will came to mind for an engineer is:

What do we need to run a Linux distribution ?
What's the bare minimum we would get away to make this idea working ?
What's the core component required to make it work in theory ?

For running Linux, doing a rough estimate would be a 100MB for the kernel, drivers, Busybox and few basic services. To have some kind of haptic feedback using the most common and cheapest motor you can get away with.

Of course you could change every component to a better one, but keep in mind that you can go with the most obvious and cheapest way to fill the required functions first and change later if needed. These kinds of changes could be upgrading the motor, adding more RAM, etc.

Doing some napkin research-math, we could identify few key components we need to find to make our smartwatch:

SoC (System On Chip): CPU + GPU + IO combo
RAM
Flash
Battery
Modem: Wifi + Bluetooth
Haptic motor
Screen + Screen controller
Battery Controller / Switching regulator
Passive component
IMU (Gyroscope + Accelerometer combo)
Heartrate sensor

These kind of pre-production phase may take from anywhere from few days to few weeks (Or months for huge projects).

Proof-of-Concept

Let's build our first imaginary prototype, we have our basic list of everything we need to make a smartwatch. Where do we begin ?

For a prototype, we mostly source from off-the-shelf component that can be bought seperately from a broker (Mouser/RS/...) or from a potential manufacturers directly if the component cannot be found.

The objective is to make a working unit that is as close as possible to the design specifications. Always keep in mind our design documents and, in our case, the checklist!

At this stage, we do not care about how the product looks like at this stage. The top priority is to make something that work and could be made quickly without too much engineering effort to verify if we could even pull the project off the ground.

You don't start with the component itself; you focus effort on identifying potential components and use a special circuit board (PCB) that embeds the component to start working on it. This special PCB can be a simple breakout board or a complete plug-and-play PCB solution called a development/prototype board (devboard). If the component is common enough, you can quickly find either type of PCB online. If it's a bit niche, you need to work with a specialized company that makes these boards, ask the manufacturer directly, or make it yourself.

If the component is not critical, you may get away at this stage with Amazon or Aliexpress boards that implement the functionnality you need if it exists of course.

In this stage, know that most of what that will be developed here will be thrown out. You only keep the knowledge you have acquired, few tools, a better vision of our product and maybe the critical component devkits. Sadly, this is the step that may decide if a product may get canned depending of the resources at your disposal.

SoC

Let's start with the most hardest one to choose, the core of our product : the SoC (System on a chip). This piece of silicon is a combination of a CPU, a GPU and everything you need to make it interact with the real world in a single chip: peripherals, Input-Output, etc.

This is the brain in our smartwatch.

In our case, we know that we can't use every SoC we want in the conceptual smartwatch. We need something low power, with a strong open source software ecosystem and that we can purchase in quantity.

The first thing I will look at is the software support and license of the supported board in the Yocto Project/OpenEmbedded, which avoid proprietary elements. To keep it simple, the Yocto Project (Yocto) is a collection of tools enabling custom Linux distributions in a modular fashion. OpenEmbedded provides recipes targeted for tiny computers compatible with Yocto. You could also look into integrating the interface of AsteroidOS or a similar system.

The information will be compiled on a document listing everything found about it that we need to know to make a choice: features, supply, support and if possible feedback online.

RAM and Flash

This will not be that much relevant in the prototyping phase but will be in EVT: Most of the core component to make it work on a devboard will be present and will be preconfigured with instruction to boot a simple Operating System (OS).

After considering the SoC, most of the information will be found in the datasheet of this SoC: what is support, what it can boot from and what type of RAM (LPDDR/DDR) it can.

There's a special case which you can find RAM and Flash merged in a single package to increase component density, which may be considered later.

Battery and Battery Controller

Batteries are a mess and this is the one I personally hate the most.

At the prototyping phase, only the battery controller and the switching logic from battery to power brick may be integrated. As the prototype doesn't focus on running autonomously and doesn't have a fixed architecture, this would be omitted, as we can't reliably know the prototype's power draw.

Most of the batteries will be sourced from China and will have widely different properties. They will include a basic protection circuit (PCM) or an advanced one like a BMS and the cells themselves. It is your job to make them charge, report their charge and handle them properly.

Screen and Display Controller

The display controller will certainly be based around the MIPI DSI standard. Imagine a "standard" such as HDMI or DisplayPort as an internal connector. If the screen has a low resolution or low framerate, an SPI display may have enough bandwidth for the specified requirements.

Most displays contain a display controller with a precise power up and power down sequence. If the display doesn't have an integrated controller, you need one too. Did you know that you need a backlight controller to dim your LCD display?

This will get messy and is terrible to get right sadly.

Haptics

Fortunately there's multiple approach to this. The cheapest to use and the easiest to drive is the ERM type, which is a cutted piece of metal which spins around. You may find dedicated controllers to it which interface on it using I2C or SPI, you would need to expose it proprely via a driver which a user app do some filtering.

If you want to get a bit fancy, you could go around LRA, similar to modern phones. As again, depends of your specification and budget allocated.

Modem

To make your smartwatch connect to a phone or to browse the internet on a 2 inch screen, you need something that is called a "modem". The modem contains nearly what you need to throw some waves into the air: Wifi/4G+/Bluetooth. Sometimes the SoC or SIP (A chip which integrates multiple different chips and components within a single package) contains already a modem, which you don't need to add.

If the SoC doesn't have one, you need to choose one yourself. It needs to be tiny (I believe Rockchip makes some) and have some good drivers or a generic plug-and-pray interface. In our case, we would need something that could work on ModemManager/NetworkManager/BlueZ depending of your use case.

You could convince a big player that you will order 1M units to give you a good modem but chance that you will get flooded with NDAs and binary blobs (Which goes against your libre smartwatch manifesto).

Modems are notorious to enforce patents and royalities too, so this would be a difficult selection.

Heartrate sensor

The gold standard of this kind of sensor is the PPG sensor: it's a green LED and a photodiode. Everything oscillates within a precise range to detect blood moving.

Similar to haptics, all‑in‑one sensors exist (Maxim or others) that can do everything you need if you require maximum precision. Your only job is to orient and protect it correctly and to correct the values based on motion, skin tone, placement and what the embedded ASIC tells you.

Finally, you need to build a driver that exposes the data via Linux IIO or similar and do basic post-processing in user space to filter out noise.

Don't mix it up with the oximeter, which can estimate how much oxygen is present in the blood.

EVT

Okay, we have a prototype which works and respect more or less your design specification (Except the Weight, the size and the looks).

Now, you iterate.

You swap out the Off-the-shelf component and do a proper hardware sourcing. In short, you search components you need to make the product work. A hardware sourcing takes quite a while, you need to check each datasheet you can find, comparing multiple component by the price, features, availability and footprint. You make a listing of everything you need, calculate the power draw required, the price, the End-of-life etc. This listing is a BOM (Bill-of-materials) and a ping-pong will be done between all of the different engineers working on the project. Most of the hardware sourcing will be done by the electrical engineer. After this step get validated, a first PCB design will be done based around these components using a specialized CAD software.

In parallel, a mechanical engineer will try to to make a proper casing and everything you need to make, well, what a smartwatch would look like. In this stage, 3d printing would be used to test basic tolerances and the rough assembly. You coordinate with the electrical engineer(s) for the size available to make the design happen.

For the software engineer, it will start to work using devboards of the selected component on a similar patchwork similar to the PoC phase doing the software bringup (Drivers, Configuration, IO layout) before the completion of the first PCB.

After a while, you will get the first EVT milestone: EVT-1

The first EVT-1 may not match the acceptance criteras of the expected performance you wanted: wrong casing, too big, a buggy PCB with patch cable everywhere with a rough OS + drivers.

iPhone 1 EVT-2 - Editoy CC-BY-SA

You continue to modify and improve this prototype until every hardware and software pass on your own defined acceptance critera. You may select better components, validate other techniques or even design choices. This may require few informal tests like software test tools, a LTT certified by-hand drop tests (material deformation), submerge the devices or more shenanigans.

While reaching for the EVTs, it's time to start talking with possible suppliers, test differents suppliers for the general quality (samples of their work, see them, send mails), look for injection molding companies and talk with differents labs to certify your product (Check ISO requirements, Check CE / FCC marking, batteries regulations are a mess), RF, body exposure tests and more. You may also sent some of them the one of a advanced EVT prototype for a consulting round.

When you have a clear vision of which path you will take to make your product, you may switch to the DVT phase.

DVT

Okay, so now you've got a smartwatch that mostly works. It's not pretty, but it's getting there. Time to move into DVT!

This phase might start while you're still wrapping up EVT or may overlap completely but anyway. You begin by running basic in-house, checking how the product behaves under different conditions, catching edge cases and validating that everything still works after the last-minute hardware tweaks. Let's the fun begin (and do a lot of paperwork and declare any issues you see also).

You handle motherboard revisions, maybe you found a cheaper PMIC, or the antenna placement needs to change (Don't forget to have a way to detect this in software). You optimize the PCB layout to reduce component count, shrink the board and of course improve manufacturability. Every resistor, capacitor and trace may be questioned if you need to build a lot of your product: do we really need this? Can we combine these two functions into one chip ? One of the thing that we see a lot online is "Why does they don't add this .5 c component?". The sad truth is that I'm sure we wanted to add it, but unfortunately at scale, it's 0.05c x 20 000 = 1k€ (or even more).

At the same time, the mechanical team is refining the casing. You need to remove some plastic where it's not needed (same principle), adjust wall thickness for injection molding, tweak the assembly if you can to make it faster and cheaper. You test new prototypes, test fits and iterate until everything snaps just right and make the machine gods happy. At this point the product will not change that much.

Now, certification labs come into play now. You need the product to be certified to be released (Remember the CE/FCC/Tomato/Salad/Onion on the box?). You should not wait until the end if your product fails EMC, CE or FCC tests, you might have to redesign the board or add some shielding. If you don't do this means that your product is illegal to be sold and big fines will comes. That's horrible and time consuming this late into the product developement. Like said in the EVT you pay some labs to run some pre tests on prototypes, run pre compliance tests and fix issues before the final version.

You also build test tools which will be better, jigs, scripts and fixtures to automate the testing. These may be adapted on the PVT stage to make sure every unit that leaves the factory works as expected on the surface and you don't have a huge pile of recalls.

Also, you test your product as much as possible in a controlled way:

Drop tests
Water resistance
Thermal cycling
Battery aging
Button fatigue

And then you talk to suppliers, the OG real ones. You're not ordering 10 components anymore, you're talking thousands or millions. Lead times are brutal because some parts have weeks of lead times (Amazon Prime doesn't exists for these kind of things).

Negotiate, plan and buffer (with small calculated YOLO too).

PVT

There's the part that will sunk most of your precious eurodollars.

Now, how do we turn our intelligent wearable trashcan but working EVT unit into something that a factory can spit out on demand? PVT is where we build the machine that builds the machine that sometimes build the machine. It is also where budgets get annihilated, machines are freaking expensive.

You build the supply line: incoming parts, storage, kitting, assembly (robots or meat robot!), test, outgoing. You design this with your intermediaries (Or "DIY" at a rented building) and try to lock the path from A to Z. Maybe the casing will be injection molded by company A, the PCB will be made and assembled by company B and final assembly will be done by company C (it depends). If your batch is tiny, you might decide to do final assembly in-house but you still need some insane discipline, interns (I will not elaborate) and good Excel sheets.

The first pre-production run will be horrible (Yup): misaligned displays, undercured glue, bad reflow, scratched bezels, rotated motors or wrong screws. Tweak, patch, reprint, yell, you chase a supplier for a change and you accept that your plan will break, fix the line, etc.

You write the assembly manual and the test manual, step-by-step, with a ton of photos, torque values, notes, how to press the gasket without tearing it, which order the flex cables go, how long should the the functional test lasts and what constitutes a pass. You build fixtures and jigs which claps to test point on the PCB. You adapt your EVT/DVT test tools to the benches (Or make more!) and make them idiot-proof (or at least idiot-resistant) and then you iterate again and again. This part takes AGES and is not the most interesting.

Quality and consistency also: You set incoming inspection criterias, in-process checks and outgoing sampling plans. You pick serial number formats and traceability (lot codes/serials matters when something breaks and track down supply issues). You measure yields and scrap rates, you track which step produces the most defects and you fix that step. You run small lots, tune the process, run. Only when the line can repeatedly produce units that pass your acceptance criterias without you being there THEN you can say you are close to mass production readiness. Until then, you walk the floor, you talk, you listen, you mop, you have a mental breakdown, you document, you validate, you repeat, you sleep on the bench.

This part reads like Technologic from Daft Punk.

Releasing to the masses

This is the point where I have not a lot of experience with. Take this as a big grain of salt.

Okay, you have boxes of watches that look like watches and behave like watches. Where do they sleep? How do they fly (figuratively)? Storage is not just your bedroom. Batteries hate heat, humidity ruins cardboard and condensation kills. You pick a warehouse, you pick shelves, you pick plastic bags (shrinking film is not just for the unboxing experience, ya know) or not, you write handling notes (which will not be read) and you make sure that everything actually happens. Shipping is not a button either: pick carriers, pick packaging, pick insert foam, think about customs paperwork if you ship outside your country (tariffs/stuck at borders), think about insurance, returns and the sadly inevitable damaged-in-transit units. You create RMA steps (or don't if you don't care) and go.

If you promised a GNU/Linux watch with apps, your job does not end at shipping a binary. You need an SDK and documentation. A developer quickstart, some sample code, how to talk to the sensors, how to draw on the screen, how to vibrate the ERM proprely without killing the battery.

You need to tell users how to update safely and how to recover from a bad flash. Warranties are important and are a legal obligation if your company is in a country that cares about them.

Open Source component release is a legal and ethical requirement too, not a marketing point. If you ship a modified linux kernel and drivers, you need to release the source. You need to prepare repos, tarballs and build instructions (Yocto/Buildroot or whatever you used), you add license files, attributions and you keep them updated when you change something (Please).

Packaging is a art too, it's litterally the physical face of your product: design the box, the inserts, the manual, the stickers, the recycling marks, the CE / FCC logos and the tiny texts that nobody reads but which must be correct of some suits will knock at your door.

Marketing is another can of worms which are another can or worms. But yeah, is what gets eyes on it: photos, a simple website, clear copy, do not oversell what you do not have (I HOPE). Show the thing, explain what it does, be honest about what it does not do yet, ads, I don't know I don't have a MBA.

Final Thoughts

Now, if you read everything in this post, you are a bit more knowledgeable on this subject. I would remind you that I am not an expert on this domain.

I could also point out some issues that may arise with this product, like creating an open-source hardware platform, low-power optimizations with asymmetric multiprocessing like the TicWatch Pro and more.

Open-sourcing hardware for a company may be dangerous, as clones may arise quickly (Arduino, for example) and kill your company. The moment your file are online, someone can cut the BOM, do the bare minimum to make it work and undercut you with a clone. You can now defend yourself with supply line quality, support and the community you build around it.

Also, sometimes the rational answer is, damn, boring: just buy a compatible watch running AsteroidOS or port it yourself.

I could also point out that if your goal is to wear a GNU/Linux smartwatch rather than to learn how to make one, this is the shortest path, just saying...

Anyway.

There's a ton of other things I could talk about, but it's only a cute blog post (Don't look at the reading time of more than 30 minutes).

See you next time.

Q: Did you make a blog post on it to just give it to one person which told you "Too Long - Didn't read" ?

A: Yes, I did.

The AAA Industry and Modding Tools

2025-10-05T00:00:00+02:00

Please note that I'm not a AAA game developer and this is based on my own observations. When referring "AAA game developers and studios", I mean their public stance or combination of behaviors, not individual employees within these studios.

A few days ago, I fired up an Unreal Engine 2 game. I didn't made a direct shortcut to the executable (being lazy is really hard these days), so I had to dig through the game files and launch it manually. While scrolling and clicking too fast, I accidentally launched UnrealEd 3.0.

UnrealEd 3.0 Editor with a empty scene - Epic Games 2003

Damn, I nearly forgot about that chunky wxWidget app.

Just before closing the app, I asked myself "Do the big studios provide these kinds of tools anymore?". Mods still exist, sure, go to Nexus Mods or ModDB to see a fraction of what game modding can offer. But many of these modifications aren't supported by the game natively and the modifications aren't made using exactly what the game developers used to make the game.

Let's rewind a bit. In 1983, Lode Runner was released. It's a puzzle-platformer, nothing fancy compared for today games. You have to collect all the gold in a blocky 2D level full of enemies and get out. What's interesting there? The gameplay? The graphics? The maps?

Not really, in our case, it was one of the first games featuring a level editor. While we experimented with byte-level editing, the game's editor made it easier to create custom levels. Fast-forward to 1993: Doom was released. Nothing fancy, just one of the biggest games of its time. What's interesting in our case is that John Carmack separated the assets from the game. Fans began building custom editors and hacks for the game and most importantly, did so without sharing the game executable and WAD. Modding exploded after the source code was released later in 1997.

Released in 1996, Quake was the first big game to allow gameplay modifications. It embedded a bytecode virtual machine with an external script compiler, QuakeC, which gave players greater modding freedom (Team-Fortress is classic example, pun intended).

Quake - Level Selection Map - Id Software 1996

A small company named Valve Software released Half-Life, a direct descendant of the Quake and Quake 2 engine. It expanded the game SDK concept by releasing a mapping SDK in 1999, one year after its release. The SDK included model conversion tools, mapping tools, the very-stable Hammer level editor, some map sources and a few 3D Studio Max models from the game. If you wanted more, you could ask Valve (after signing an NDA unfortunately) for nearly the full game source code. The code for non-commercial use was released later in 2002 for everyone. In the same year Half-Life launched, Epic released Unreal. It shipped with UnrealEd 1 with the game's official toolkit: a level editor, model and texture viewer with an embedded scripting environment powered by Java-like UnrealScript.

Official Half-Life SDK - Github

Game developers took notes of the modding aspect of the game and started to add modding support baked in their games: Battlefield 1942, Half-Life 2, Max Payne 1 and 2, FarCry 1 and Serious Sam to name a few.

Then it began to slow down, it didn't disappear, no, but it became less and less common. It wasn't a day-one feature on the box, but something like an add-on.

What happened ? Why are tools for current-gen titles rarely shipped with them anymore ?

In my view, the industry shifted as game engines grew increasingly complex and consoles and mobile platforms became a top priority.

Let's start with the most oblivious one, the middlewares. A middleware is in simple terms a simple extensions that could be integrated inside games and game engines. They simplify and sped up the developpement process. Havok, FaceFX, WWise, Umbra to name a few. Most of these forbid the redistribution of tools, headers and static libraries without permission. If you want to add facial animation or tweak one of these features more deeply, you're out of luck if the engine doesn't expose these features via scripting or custom tools.

Did you checked once what these logo meant ? - Doom Eternal, Zenimax / Id Software 2020

To go even further, IP protection hits the hardest. Game developers are afraid to expose anything that could help somehow the competition. Innovation slowed down, we're no longer in the early 2000s, when rapid improvements arrived every two or three months-ish. If a studio wants to ship a powerful external editor and SDK, assuming they expose only what was developed in-house, it has to scrub, redact, stub or cripple everything it can to be license compilant. They could release a basic editor like Doom (2016)'s SnapMap but they're really limited.

I really wonder what PlatformBlue™ is... - Jolt Physics Github

Another point is that the tools are getting bigger and bigger. Not just a few megabytes, but gigabytes bigger. The editor is no longer a 5 Mb executable made with WinForms. It's a complete, suite of tools: from the level editor, to the lightmapper, animation, cinematic tools to multiple connectors to other expensive software which cost a car. It's now a behemoth that needs at least 32 GB of RAM to open a blank scene. Take Unreal from 1998 for example, UnrealEd 1 was a editor written in Visual Basic with a embedded level preview and .UNR files with the associated precompiled UnrealScript files. The game can then read them. Nowadays, you can play literally the game inside the editor.

The "Play" button inside the editor - Godot Engine

Even if the studios cleared out all of these issues, what then? Do you just export an archive and upload it to your website as is? If your game is dead and will no longer be maintained with a prominent disclaimer asking users not to request support, ""maybe"". If that's not the case, it must be kept up to date alongside the supported game. What does this mean? You need developers, writers, quality assurance, legal time and some degree of community management. This is a non-negligible expense, especially if the game isn't based on player-generated content.

For some studios, the PC is already an afterthought, as most of the industry focuses on console versions of their games. Some developers don't have time to implement proper mouse support, FOV sliders or graphical tweaks. A public, complete, legally clear and well documented SDK unfortunately falls in priority somewhere between "ultrawide support" and "Linux support". Console manufacturers forbid external resource sideloading at all, so any editor release would be PC only (Super Mario Maker if you consider somehow as a SDK).

In my opinion, the democratization of hobbyist-level game engines, such as Unity, Unreal 4+, Godot and GameMaker 2 may have slowed things down. Paradoxically, it reduced the pressure on AAA studios to provide tools. Why bother releasing custom content support when an aspiring developer can make their own game? The 15 year old who in 2000, would have spent two months making the best CS bunny hop map can now build a bunny hop simulator in Unity and release it on Steam in the same time span.

Mods should and will never die. Some games are litteraly based around the concept of mods and user generated content like Roblox, Garry's Mod or S&Box to name just a few. Players still want for mod support for their favorite game. Cyberpunk 2077 launched without any modding support whatsoever. Players had to reverse engineer the REDEngine to hook, inject code and scripts that may get broken at every update of the game. The madlads did it. Why you may ask ? Personalization, add more content or fixing a game's quirk (Bethesda Softworks, anyone, no?).

Indies understood this. When David Szymanski announced that Dusk would get a level SDK, players were on board. When Teardown shipped the Voxel Editor, you can bet that players made a Blue Hedgehog®, more levels and a spooky skeleton on wheels. I could talk about Ready-or-Not or Minecraft, but you get the point I believe.

The release of mod support for Dusk - Steam Community, Dusk - David Szymanski

Not all hope is lost, I think. Some AAA studios surely know this, but it's the exception, not the rule unlike a few decades ago. Id Software released a version of its idStudio suite for Doom Eternal, Battlefield 6 appears to support a custom version of the Godot engine for creating custom levels and Bethesda Softworks still releases the Creation Engine Toolkit. What some of these companies don't understand is that if you trust your players, they may repay you with immortality. Players still make Doom mods and total conversions (with enhanced engines !), newer games still ship with custom Quake engines and so on and so forth. Releasing source code may be impossible now, I get it, but I believe the minimum should be done to natively support user-created content by providing tools where possible.

idStudio for Doom Eternal - Id Software

Counter-Strike was a Half-Life mod, Killing Floor was an Unreal Tournament 2004 mod and PUBG was an Arma mod. Entire games and genres were born from other studios toolboxes and players haven't forgotten where the originals were from.

So here we are, the tools get bigger and more inaccessible for everyone modding, platforms get more locked down and modding support is seen as a quirky expense. Perfect! I just hope this doesn't get any worse...

I don't rant because I remember like "Pepperidge Farms remember" meme. I rant because I fear the future will be smaller, sterile and a lot more less interesting than the past. If you read my previous posts, you see what I mean.

See you next time.

The Unseen life of Alphas and Beta games

2025-09-30T00:00:00+02:00

Once upon a time, there was a game that will never be seen. We treat a game like a house, assembled piece by piece: Level 1 complete, "texture_452_brick.png" done, until the game is complete. It's more like building a car without specs, realizing midway that the wheel is welded onto the left passenger door and that suddenly we're told we need a scooter. Did I tell you that the market analysis team says we need a bus?

What happens to the half-baked car? The broken scooter?

We delete it and sometimes reuse parts here and there.

A lot of the time, this version of this car, the game, even if broken, is rarely archived. It's a distant memory for the developers, lost in a Perforce/Git branch or just deleted. Sometimes we catch a glimpse of these versions in a trailer at the (defunct) E3, a playable demo at another convention, or a screenshot sent to game journalists.

Unreal looked very different in 1997 - Epic Games - TCRF

We need a proper museum of unfinished hearts. I want to wander through every version of Half-Life 2 from 1998. I want to be able to play every version of Duke Nukem Forever that existed. I want to be able to play the original versions of Cyberpunk 2077.

At the very least, I could see some breadcrumbs from the digital archaeologists of Unseen64 and TCRF or some unauthorized leaks lost around the internet of these games. Many of these builds are gone, deleted or overwritten, sitting on nearly dead hard-drives in some developer's basement, assuming they aren't nuked out of fear of breaking NDAs.

1995 version of Prey (2006) - Does this feel like a 2006 game ? - 3D Realms / Human Head Studios / 2K Games - Unseen64

We archive movie outtakes, early music demos or even sketches naturally. Games? Rarely. If the publisher's milestone or the objectives of the vertical slice are not met, it's erased. The final product is the ONLY product.

Here's my hot take: the best version of a game may be the one that never shipped.

See you next time.

Other examples cited:

Where have the fun architectures of the arcade gone?

2025-09-28T00:00:00+02:00

I loved reading about arcade boards, how they worked and the madness designers embraced to make arcades run. A lot of people remember arcades for the games, me too, but I was equally intrigued by the hardware. When I was a kid, the nearest pub to my childhood home had a cabinet of Cruis'n USA. I thought it was an old PC with a CRT and a steering wheel. Nope, it was a Midway V unit built around a Texas Instruments TMS32031 DSP + CPU combo with a few VLSIs for glue. Not your standard PC CPU from Intel or AMD.

TMS320 Series - Konstantin Lanzet - CPU collection, CC BY 3.0

Now take any newer arcade board and I bet you'll find Windows Embedded/LTSC with a common x86_64 CPU.

What happened to these cool architectures?

After the electromechanical arcades of the '70s, the arcade industry shifted to pure electronics. It was an arms race to impress players around the world. Personal computers and home consoles were not common and the only way to play something interesting was the arcade.

For years, the arcade was the only way to see raw computational power. To make you feel a sense of speed like Sega's Hang-On or Space Harrier, you needed two Motorola 68000s and SIXTEEN graphic coprocessors, just to get speedy sprite scrolling with scaling and rotations. I could also tell you about more boards, like Namco's NB-1: four graphics chips with three motion coprocessors. Pre-2000 solutions were crazy: custom processors, DSPs and a hefty amount of RAM.

Midway V - Toby Broyad - system16.com

Then the arcade fell off, slowly but surely, with more powerful consoles and PCs. Console-based arcades made their entry and became the norm for major manufacturers. Sure, PlayStation 1 and 3DO hardware existed before this shift, but most used custom hardware to handle the game. A retrofitted console was enough, no more parallelization, no more custom ASICs for the target hardware. Why would you spend millions designing and debugging a custom board? Why would you build a custom SDK for your own platform?

Sega Naomi motherboard, based on the Dreamcast - Toby Broyad - system16.com

Call me dramatic, but the white flag waved at the rising tide of cheap, powerful and boring PC hardware in the 2000s. Sega launched their Lindbergh platform based on a Pentium 4 and a GeForce 6 GPU. More manufacturers followed: Taito with the Type X, Konami with the Bemani PC platform, to name a few. Custom hardware started to fade. SH-4, MIPS or console-derived architectures still existed, sure, but such systems became harder to find. No more sprawling motherboards with weird chips you can't identify without reverse engineering. Just a PC with FPGAs/MCUs to handle the I/O. The only truly custom parts, if you squint hard, are the DRM systems with lockouts or dongles.

Midway Graphite System, based on a Pentium III/3DFX - Toby Broyad - system16.com

At least it makes the MAME Team's life a bit easier, even if hardware and money donations are rare. Now that the game is a Windows/Linux app, you "only" need to defeat the DRM and make wrappers to handle the custom inputs or fix problems (TeknoParrot, Spice2x).

Initial D Arcade Stage 8 Infinity, running on Sega RingEdge, Pentium Dual Core + GeForce 8800GS - arcadeclub.co.uk - CC-BY-SA

So yes, we know why exotic architectures died. Custom silicon is a billion-dollar business. The PS2's Emotion Engine cost millions for Sony. Namco, Taito, Konami and others could not justify that cost for a few thousand units. Meanwhile, Nvidia, AMD and Intel (hopefully) amortize their R&D costs across the datacenter and consumer PCs.

The economy is a steamroller, heh?

I think the worst part is that we'll never get it back. The talent is gone. The engineers who lived for this kind of stuff have retired or moved to other companies. Now the hardware lore is rotting away in landfills or if you're lucky, on eBay auctions.

The PC won and in doing so, it may have erased an ocean of alien architectures along the way. Now it's x86_64, DirectX/Vulkan and Windows. If you want some action, the embedded systems world might interest you.

See you next time.

In Defense of Fixed Function Pipelines...

2025-09-25T00:00:00+02:00

Every time I boot up a game from before 2002, something feels right. I'm from a generation which embraced next gen games, "Can it runs Crysis???" was the ultimate joke in my friend circle at the time. Still, I stick to older titles from the DX7/OpenGL 1.x era. I think that the visual are a lot more cohesive, like this era shaped a visual language that a modern engines did not support out-of-the-box anymore.

Yes, you can absolutely attempt to recreate the same design with vertex‑lit or unlit materials, exponential fog, low‑res textures, limited palettes, no normal/specular, dithering, mip bias, clamped UVs, retro post‑FX things (ULTRAKILL, Amid Evil, Cruelty Squad are great examples) but you are not enforced by the constraints that made such a distinctive look in my opinion.

Cruelty Squad, Steam Page - Consumer Softproducts, 2021

Fixed function pipeline enforced uniformity, every object looked the same, models too. Every pixels obeys the same rules : fog equations, bilinear filtering and gouraud shading (Drivers aside). You could attempt multi-pass techniques to cover some quirks like Unreal 1 (Go play it, it's on InternetArchive!).

Unreal, GOG Page - Epic Games 1998

Artists knew this limitation was a real problem and attempted as the best as they could by iterating on the art style. They had to pack details, mood and storytelling onto a square that gets blurry using bilinear filtering, a function which interpolate pixels. This gradient make the texture seems almost painterly.

Next time you dismiss an older pre-2002 games graphics as "dated" or "ugly" at least try to take a close look. Maybe, just maybe, you may find a visual that speak to you.

Until then, I'll drop my pink tainted nostalgia glasses with rainbow unicorns and I'll continue to mess around on modern titles.

See you next time.