---
title: "A pergunta não é 'roda Doom?' e sim 'onde ainda não rodaram?'; agora foi a vez de fones de ouvido e software CAD"
author: "Gabriela P. Torres"
date: "2026-01-27 09:13:00-03"
category: "Games & Cultura Digital"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/01/27/a-pergunta-nao-e-roda-doom-e-sim-onde-ainda-nao-rodaram-agora-foi-a-vez-de-fones-de-ouvido-e-software-cad/md"
---

# Análise de Caso: O Limite da Execução de 'Doom'

No léxico da cultura digital, a pergunta "Mas roda Doom?" transcendeu o status de meme para se tornar um teste de Turing informal para qualquer dispositivo com um processador. A premissa é simples: **se um aparelho possui capacidade computacional, então, em tese, ele deve ser capaz de rodar o jogo Doom de 1993**. Recentemente, duas novas provas de conceito levaram essa premissa a extremos lógicos fascinantes. A questão não é mais 'o que' pode rodar Doom, mas sim 'o que ainda não o fez'. Vamos analisar os fatos apresentados por Arin Sarkisan e Mike Ayles, que portaram o jogo para fones de ouvido e software de CAD, respectivamente.

## Caso 1: 'Doombuds' - A Execução em Hardware de Áudio

O primeiro objeto de nossa análise é o projeto "Doombuds" de Arin Sarkisan. A plataforma: os fones de ouvido sem fio PineBuds Pro. O desafio fundamental é autoevidente: fones de ouvido não possuem tela.

**O 'Bug' (O Problema):**

**Ausência de Display:** O dispositivo não foi projetado para saída de vídeo.**Memória Flash Limitada:** Os 4MB de memória flash dos PineBuds são insuficientes para os 4.2MB do jogo original.**RAM Escassa:** Com menos de 1MB de RAM, a execução padrão do jogo é inviável.**A Solução Lógica (O 'Desbugado'):**

Sarkisan abordou o problema com uma sequência lógica irrefutável. **Se** não há tela nativa, **então** uma saída de vídeo externa deve ser criada. A solução foi usar os pads de contato UART (uma interface de comunicação serial, comumente usada para depuração) para enviar um fluxo de vídeo MJPEG comprimido a um servidor web, efetivamente transformando o fone em um transmissor de vídeo. Para o problema de armazenamento, a solução foi pragmática: usar uma versão "squashware" de 1.7MB do Doom, que comprime o jogo removendo quadros de animação e encurtando músicas. Para a restrição de RAM, foi necessário reescrever partes do código para otimizar o uso da memória, pré-gerando tabelas e removendo variáveis desnecessárias. O resultado é um sistema que roda o jogo a 18 quadros por segundo, um fato verificável e funcional.

## Caso 2: 'OpenSCAD-Doom' - O Jogo Renderizado como Modelo 3D

O segundo caso vem do engenheiro Mike Ayles, que se propôs a rodar Doom dentro do OpenSCAD, um software de modelagem 3D por script. Ayles descreve seu trabalho como "P&D disfarçado de entretenimento".

**O 'Bug' (O Problema):**

**Natureza da Ferramenta:** OpenSCAD é um modelador CAD, não um motor de jogo em tempo real. Ele gera modelos 3D estáticos a partir de código.**Ausência de Texturas:** O software não suporta o mapeamento de imagens em superfícies, impossibilitando o uso das texturas originais do jogo.**Performance de Renderização:** A renderização de cenas complexas não é otimizada para a velocidade exigida por um jogo.**A Solução Lógica (O 'Desbugado'):**

Ayles construiu um motor em Python que atua como tradutor. Ele lê os arquivos WAD do Doom (os pacotes de dados do jogo) e gera, em tempo real, código OpenSCAD que representa o ambiente do jogo como um conjunto de sólidos geométricos. **Se** o software não suporta texturas, **então** as superfícies são renderizadas com cores sólidas. O desafio de performance foi superado quando Ayles descobriu e corrigiu um problema em uma dependência de software (`openscad-wasm`) que reduziu o tempo de renderização de minutos para segundos. O resultado é Doom, reconhecível e jogável, rodando entre 10 e 20 quadros por segundo dentro de uma ferramenta de engenharia.

## Conclusão: A Caixa de Ferramentas da Criatividade

A análise forense desses dois projetos revela uma verdade fundamental sobre tecnologia: as limitações são catalisadoras para a inovação. O que Arin Sarkisan e Mike Ayles demonstram não é apenas um feito de programação, mas uma mentalidade de resolução de problemas.

Sua caixa de ferramentas para levar para casa contém dois conceitos principais:

**Otimização Extrema:** A necessidade de caber em hardware restrito força um entendimento profundo de como o software funciona, levando a soluções como versões "squashware" e código reescrito.**Tradução de Domínios:** A habilidade de fazer sistemas diferentes se comunicarem, como traduzir dados de jogo para scripts de modelagem 3D, é a base da interoperabilidade e da inovação.Esses projetos provam que a pergunta "Roda Doom?" é, na verdade, uma investigação sobre os limites da computação e a engenhosidade humana. O próximo passo é aplicar essa lógica: qual ferramenta no seu dia a dia pode ser usada para um propósito para o qual ela decididamente não foi criada?