Vinicius Cole

Linkar não é rodar: um jogo C++ com OpenGL no navegador

2026-11-01T00:00:00Z

O jogo de rolagem lateral deste site foi um trabalho de Computação Gráfica: C++, OpenGL em modo imediato, GLUT e uma arena lida de um arquivo SVG. Portar ele foi o oposto do port do jogo da velha. Lá, um emulador de 1,4 MB roda um programa DOS de 3 KB. Aqui não tem emulador: os 181.051 bytes do jogo.wasm são o meu C++, compilado pelo Emscripten.

Compilar foi um comando só:

em++ -std=c++11 -O2 main.cpp arena.cpp tinyxml2.cpp character.cpp \
     hero.cpp enemy.cpp shot.cpp \
     -sLEGACY_GL_EMULATION=1 -lGL -lglut \
     --preload-file arena_teste.svg -o jogo.js

Linkou limpo. Eu quase anotei “OpenGL em modo imediato funciona”. Aí abri no navegador e o jogo morreu no primeiro quadro:

Aborted(unsupported immediate mode 9)

Modo 9 é GL_POLYGON, que o jogo usa para desenhar a cabeça de cada personagem. A emulação do OpenGL antigo no Emscripten não implementa esse modo. Trocar por GL_TRIANGLE_FAN desenha a mesma coisa para uma forma convexa, então o patch é de uma palavra.

O patch não me incomodou. O que me incomodou foi que o compilador, o linker e uma olhada no tamanho dos arquivos tinham dado sinal verde para um programa que não desenhava um quadro sequer. Só rodando de verdade para pegar aquilo.

Então montei uma bancada: um script que abre o jogo num Chromium de verdade (headless, dentro da imagem Docker do Playwright), aperta teclas, clica o mouse e confere o que aparece na tela. Quase tudo que aprendi com esse port veio dos erros da própria bancada.

Não dá para ler um canvas WebGL

A primeira pergunta da bancada é “desenhou alguma coisa?”. O óbvio é ler os pixels do canvas. Isso devolve preto, sempre, porque o WebGL joga fora o buffer de desenho assim que o quadro vai para a tela, a menos que você peça o contrário.

O que funciona é dar a volta. Tira um screenshot pelo Playwright, carrega num <img>, desenha num canvas 2D e chama getImageData. Toda medida da bancada passa por esse caminho.

Um teste que passa com o teclado desligado

A primeira versão de “apertar D move o jogador” comparava dois screenshots do canvas inteiro, um antes da tecla e outro depois, e passava se fossem diferentes.

Eles são sempre diferentes. A arena tem sete inimigos que andam e atiram sozinhos desde o primeiro quadro, então a imagem muda entre dois instantes quaisquer, com ou sem teclado. O teste passaria com a entrada completamente quebrada, o que é pior do que não ter teste, já que tudo depois dele confiava nele.

No lugar disso, a bancada mede a coisa que deveria se mexer. O herói é a única coisa verde na tela, então a bancada acha o centro horizontal dos pixels verdes e afirma que D empurra ele mais de 20 px para a direita e A traz de volta. E tem que medir perto do ponto de partida: a câmera acompanha o herói, e depois de alguns passos ele fica centralizado e o deslocamento na tela quase some.

O pulo era um problema de tempo. Um toque rápido no W levanta o herói 21 px e ele aterrissa em menos de 90 ms. Minha primeira medida rodava 250 ms depois de soltar a tecla, via o herói no chão e acusava uma falha que não existia. Segurar W por 900 ms chega a 147 px. Hoje a bancada tira três amostras logo depois de soltar e fica com o ponto mais alto.

`exit(0)` não sai

O jogo original fecha no ESC com exit(0). No desktop, tudo bem. Numa página não existe para onde sair, então o port transforma o ESC em nada. A bancada conferia isso apertando ESC e vendo se o herói continuava visível.

Essa checagem não servia para nada, e só descobri quebrando a proteção de propósito e recompilando. Com o -sEXIT_RUNTIME=0 do Emscripten, exit(0) não para coisa nenhuma. Ele lança uma exceção ExitStatus não capturada dentro do handler de tecla, a página registra um erro, e o laço de requestAnimationFrame que já estava agendado segue rodando. O herói nunca saiu da tela, então minha checagem testava justamente a única coisa que a regressão não quebra.

A afirmação que pega a regressão conta os erros da página antes e depois do ESC. “O herói ainda anda depois do ESC” ficou como segunda linha de defesa, para o caso de o build mudar um dia para EXIT_RUNTIME=1.

Isso virou a regra da bancada inteira: toda afirmação tinha que ser vista falhando. Coloca o bug de volta, vê a checagem ficar vermelha, desfaz. No caso do GL_POLYGON, isso significou editar o patch de volta para glBegin(GL_POLYGON), recompilar e ver a bancada pegar o abort. Uma checagem nem sobreviveu à regra: “segurar W pula mais alto que tocar” comparava contra o Math.min de uma lista que podia vir vazia. Math.min() de nada é Infinity, então qualquer altura passava.

O que o jogo fez com a página

O GLUT do Emscripten escuta keydown e keyup na janela inteira e chama preventDefault em Tab, Enter e Espaço. O jogo não usa nenhuma das três. Depois que alguém clicava em Jogar, quem navega por teclado ficava preso no canvas: o Tab não chegava ao rodapé, nem ao botão de tema, nem ao “jogar de novo” da tela de fim do próprio jogo. Agora um listener em captura na janela, registrado antes de o módulo do jogo carregar, segura essas três teclas antes de o GLUT ver.

E essa tela de fim também estava quebrada. As fontes bitmap do GLUT não existem no Emscripten, então “Você venceu” e “Você perdeu” agora são HTML por cima do canvas. O C++ chama a página a cada quadro enquanto o jogo está acabado. Quando o R reinicia, ele simplesmente para de chamar, e nada avisava a página para esconder a mensagem. O overlay ficava por cima de um jogo rodando e engolia todos os cliques. Agora o restartGame() avisa a página quando o jogo volta.

O último só apareceu no site de verdade. A bancada servia os três arquivos do build de um diretório só. No site, a página mora em /projects/... e o jogo em /demos/.... O loader do Emscripten procura o jogo.data (a arena SVG empacotada) relativo à página, não ao jogo.js, então no site real era 404 toda vez. Uma opção locateFile no loader resolveu, e a bancada ganhou um segundo modo que carrega a página construída de verdade, porque a versão de diretório único não tem como ver esse tipo de bug.

Três patches, e muita bancada

O jogo em si quase não mudou: três patches pequenos sobre um commit fixo do repositório original, e o próprio make do trabalho ainda gera a versão de desktop com o texto original do GLUT.

Entrei achando que a parte difícil seria o OpenGL. Foi a bancada.

Ensinando um programa em C a mostrar o raciocínio

2026-11-01T00:00:00Z

O projeto de rotas começou como um trabalho de 2023 que fiz com dois colegas: ler um mapa, achar a rota mais rápida e replanejar quando o trânsito muda no meio do caminho. É C puro. Você dá um arquivo e ele devolve três linhas: o caminho, os quilômetros e o tempo.

Para o professor corrigir, essa resposta basta. Para uma página web, não serve para nada. Eu queria que o leitor visse o Dijkstra abrindo e fechando nós, o carro saindo, uma via travando e o carro mudando de ideia. O C sabia tudo isso enquanto rodava. Só nunca falava.

Reescrever o algoritmo em JavaScript transformaria o C num link para o repositório, e animações gravadas tirariam do leitor a chance de criar o próprio engarrafamento. Então o C ia ter que aprender a narrar.

Ganchos que não custam nada quando ninguém escuta

O C ganhou uma struct de ponteiros de função, um por evento, todos NULL por padrão:

typedef struct {
  void (*pop)(int node, double time);
  void (*relax)(int from, int to, double new_time);
  void (*plan)(const int *path, int length, double eta);
  void (*move)(int from, int to, double t0, double t1);
  /* ...update, replan, unreachable, done */
} TraceHooks;

O dijkstra e o laço de replanejamento só chamam cada um se ele estiver preenchido. O programa de linha de comando original nunca preenche, então para ele a mudança custa umas poucas comparações com NULL.

Antes de mexer em qualquer linha, salvei a saída do programa para alguns mapas de teste como resultado esperado. Qualquer mudança dali em diante tinha que reproduzir esses arquivos exatamente. Na primeira execução dessa base, um deles saiu assim:

1;2;4;6
3.000000
00:02:60.000000

Dois minutos e sessenta segundos. A rota está certa, são exatamente 180 segundos. Em ponto flutuante a soma dá algo como 179,99999, o código trunca com (int) para tirar os minutos, chega em 2, e imprime o resto, que o printf arredonda de volta para 60. Isso vinha sendo impresso desde 2023. A correção arredonda para milissegundos antes de quebrar o tempo em partes. Foi a única linha da base que o projeto teve permissão de mudar.

Uma linha por evento

Com os ganchos no lugar, uma função nova, run_trace, imprime uma linha para cada coisa que acontece. Esta é a saída real para o mapa da página do projeto, onde a via 2→4 cai para 5 km/h aos 30 segundos:

pop 1 0.000
relax 1 2 60.000
relax 1 3 90.000
pop 2 60.000
relax 2 4 120.000
relax 2 5 210.000
...
plan 1 2 4 6 180.000
move 1 2 0.000 60.000
update 2 4 5.000 60.000
replan 2 60.000
pop 2 0.000
...
plan 2 5 6 180.000
move 2 5 60.000 210.000
move 5 6 210.000 240.000
done 240.000 4.000

Repare nos tempos depois de replan 2 60.000. O pop 2 seguinte diz 0.000, o plano novo diz que a viagem leva 180.000, mas o carro chega em 240. Os dois estão certos. Quando o carro replaneja, o Dijkstra recomeça do nó 2 com o relógio zerado, então tudo que ele imprime é relativo àquele momento. Já move, update e done usam o relógio de verdade. Minha própria spec errou isso: ela tinha o segundo plano em 240.000, e só corrigi depois que o C de verdade imprimiu 180. O JavaScript guarda o relógio do último replan e soma em todo evento do Dijkstra que vem depois.

O trace também mostra coisas que o código não diz em lugar nenhum. O nó 5 é relaxado duas vezes, com 210 e depois com 156, porque o nosso heap não tem decrease-key: ele só insere o nó de novo e deixa a cópia velha na fila. E o pop 4 720.000 aparece depois de o destino já estar fechado, porque o laço não para antes. Os dois comportamentos sempre estiveram no código. Eu só vi quando eles apareceram impressos, um por linha.

Lendo um arquivo que não é arquivo

O programa original lê o mapa com fscanf de um FILE *. Uma página web não tem arquivo nenhum para entregar, e eu não queria um segundo parser só para o navegador. O fmemopen resolveu: ele abre uma string como FILE *, então o run_trace recebe o mapa como texto e passa para as mesmas três funções de leitura que o programa de linha de comando usa. O único custo foi compilar com -std=gnu99.

Para o navegador, o Emscripten compila todos os arquivos menos o main.c. Sem main, o módulo carrega e fica esperando. A página chama run_trace com o mapa em forma de string, junta tudo que ele imprime pelo callback print do módulo e recebe a execução inteira como texto. São 49.687 bytes de WebAssembly, carregados uma vez por página, e uma execução nesses mapas leva poucos milissegundos. Quando você cria um engarrafamento no editor de trânsito, a página monta uma entrada nova e chama o C de novo.

Entrada de desconhecidos

Antes do editor de trânsito, a única entrada que esse programa já tinha lido eram arquivos que nós três escrevemos. Agora ele lê o que qualquer leitor monta clicando. Três coisas quebraram na hora:

o read_updates lia cada linha num char aux[50], então uma linha comprida escrevia além do fim do buffer;
uma atualização para uma via que não existe andava a lista de adjacência até passar do fim e derrubava o programa;
um destino inalcançável também derrubava, em vez de avisar.

Teve uma quarta, mais quieta. O dijkstra dimensiona os vetores pelo número de nós da primeira linha do arquivo, então um cabeçalho dizendo que o mapa tem um bilhão de nós estouraria a pilha. O run_trace recusa qualquer coisa acima de um milhão.

Nenhum desses era bug para o trabalho da faculdade, porque a gente nunca deu arquivo ruim para ele. Hoje cada um tem um teste, e a saída do programa para os mapas originais continua batendo byte a byte com a base, fora aquela linha.

Reproduzindo

No lado do JavaScript, o trace passa por um reducer que transforma cada evento num retrato completo: quais nós estão abertos ou fechados, o plano atual, onde está o carro. Todos são calculados de uma vez, então tocar, pausar, avançar um passo e mudar a velocidade são só uma posição num array. O canvas lê as cores das variáveis CSS do site a cada quadro, e é por isso que o grafo acompanha a troca de tema claro/escuro no meio da animação sem código extra.

O C em si ainda imprime três minutos como 00:03:0.000000, com os segundos sem o zero à esquerda. O README documenta isso agora, e vou deixar assim.

Portando assembly de DOS para o navegador

2026-08-16T00:00:00Z

Meu jogo da velha é escrito em assembly x86 de 16 bits, em modo real. Não existe compilador que transforme isso em WebAssembly. O conjunto de instruções, o modelo de memória segmentada e as interrupções do DOS não têm alvo equivalente.

Então o plano é emulação: montar o código original com o NASM, linkar num executável DOS e rodar esse executável dentro do DOSBox compilado para WebAssembly. O WebAssembly aqui é o emulador, não o meu código, e eu acho que essa honestidade importa mais do que o rótulo.

O build já funciona: o nasm -f obj monta os dois arquivos-fonte sem uma única mudança, e o linker do Open Watcom produz um executável DOS de 3.244 bytes.

O que o jogo realmente faz

São 1.740 linhas em dois arquivos. O vca.asm guarda o jogo: o interpretador de comandos, o tabuleiro, a detecção de vitória. O draw.asm guarda as primitivas gráficas.

O estado inteiro do jogo são nove bytes:

tabuleiro    db    '         '

Nove espaços ASCII. Uma jogada sobrescreve um deles com X ou C, e uma partida nova são nove espaços de novo. Não tem struct, não tem bitboard, não tem empacotamento. O tabuleiro é literalmente a string que você desenharia no papel.

A detecção de vitória é toda desenrolada. Oito linhas vencedoras, dois jogadores, dezesseis blocos de cmp byte [tabuleiro + n], al escritos um atrás do outro, sem laço e sem tabela de índices. Essa decisão sozinha responde por boa parte das 1.187 linhas do vca.asm.

Tudo que aparece na tela chega por um de dois caminhos, e os dois não têm nada em comum. Os rótulos de posição são texto da BIOS: int 10h com AH=02h para posicionar o cursor e AH=09h para escrever um caractere na fonte da ROM, direto sobre uma tela em modo gráfico. O tabuleiro, os xis e os círculos são pixels, traçados um a um pelas rotinas de Bresenham que o próprio jogo implementa.

Uma interrupção por pixel

O draw.asm tem 553 linhas e exatamente três chamadas int 10h. A terceira é a camada gráfica inteira:

plot_xy:
        ; ... prologo: salva o bp e todos os registradores que ele toca
        mov     ah,0ch
        mov     al,[cor]
        mov     bh,0
        mov     dx,479
        sub     dx,[bp+4]
        mov     cx,[bp+6]
        int     10h

AH=0Ch é o serviço de escrever pixel da BIOS. Toda linha, todo círculo, todo X do tabuleiro passa por ele, um pixel por interrupção. Nada é escrito direto na memória de vídeo em A000h, e nenhum dos truques de planos da VGA que faziam o modo 12h ser rápido aparece no fonte.

O mov dx,479 / sub dx,[bp+4] é o outro detalhe de que eu gosto. A VGA conta as linhas de cima para baixo; o jogo pensa a partir do canto inferior esquerdo, como papel quadriculado. Em vez de converter em cada ponto de chamada, ele inverte o eixo uma vez só, dentro da única rotina que toca num pixel.

O custo é fácil de medir. A grade vazia são duas linhas horizontais de 313 pixels e duas verticais de 297: cerca de 1.220 chamadas à BIOS antes de qualquer jogada. Um círculo de raio 40 são mais uns 250. No navegador, cada uma dessas interrupções cai dentro do emulador em vez de cair numa ROM de verdade.

Não faz diferença (um tabuleiro de jogo da velha são alguns milhares de pixels, e a coisa desenha na hora), mas deixa claro o que a emulação está comprando aqui. Não é velocidade. É a fidelidade de uma BIOS que não existe em hardware há décadas.

O formato do bundle

O js-dos recebe um arquivo .jsdos, que no fim das contas é um zip comum. O meu tem dois arquivos: o VCA.EXE e um .jsdos/dosbox.conf de 77 bytes que manda o DOSBox subir a máquina como vgaonly, montar o bundle como C: e rodar o executável. É esse o passo de empacotamento inteiro.

O bundle inteiro tem 2.236 bytes. O emulador que roda ele são 1,4 MB de wdosbox.wasm mais 315 KB de carregador. Só o WebAssembly é 450 vezes o tamanho do programa de 3.244 bytes que ele existe para rodar. É por causa dessa assimetria que a demo carrega sob clique e não junto com a página: quem veio ler sobre o projeto não deveria pagar por um DOS que nunca pediu para ligar.

Duas coisas que a metade do navegador me custou

O js-dos usa a CDN dele como padrão do pathPrefix. Deixe como está e a página baixa 1,4 MB de WebAssembly do servidor de um terceiro, que é exatamente o que este site foi feito para não fazer. A falha é silenciosa: tudo funciona, e a página só não é o que eu disse que ela era. A minha verificação de requisições a terceiros lia atributos src e href do HTML gerado, então ela era cega por construção: essa requisição nasce em tempo de execução, dentro do JavaScript. A verificação nova varre o JavaScript publicado atrás de URLs fora da nossa origem.

A segunda foi mais barulhenta. O js-dos traz uma folha de estilo, e essa folha abre com um reset completo do Tailwind: h1..h6{font-size:inherit}, a{color:inherit;text-decoration:inherit}. Ela carrega depois da minha, com a mesma especificidade. Clicar em Jogar achatava todos os títulos e apagava a cor de todos os links da página de uma vez só. A correção foi parar de servir aqueles 118 KB e escrever à mão as poucas regras de que o DOM do emulador realmente precisa, escopadas sob .demo-screen.

O readme estava errado

O readme do jogo manda digitar OLC para jogar o círculo. O código compara com 'C', no vca.asm:80, e foi C22 que funcionou quando rodei o jogo pela primeira vez no DOSBox. As mensagens nunca mudaram: o jogo ainda escreve O Venceu e Vez do O. Em algum momento a tela ficou com o O e o parser ficou com o C, e o readme seguiu a metade que era mais fácil de ver.

Então a demo documenta C, e existe um teste que falha se alguém “corrigir” isso de volta para O lendo o readme. É uma coisa pequena, mas é o tipo de coisa que só aparece quando se roda o programa em vez de descrever ele. Sete anos depois, é para isso que esse porte serviu.