Quake C é licenciado pela GPL

Certa vez ouvi (ou li, não tenho certeza) em algum lugar que se os humanos fossem peixes, a última coisa a ser descoberta seria a água. Pois bem. Me recordo desta frase pelo seu forte conteúdo didático. Procuramos demais, em todos os lugares errados, quando o que procuramos está bem debaixo de nosso nariz. Pouco tempo atrás expus minha preocupação sobre o fato de não encontrar explicitamente informação sobre o licenciamento da linguagem quake c. Fiz uma peregrinação considerável pela net - incluíndo uma infrutífera busca pelo archive em sites mortos. Quando tudo que eu precisava era abrir alguns arquivos.

Bom fazendo a estória curta. Finalmente encontrei o "maledito" licenciamento. Onde estava? Dentro do arquivo q1tools_gpl.zip. Dentro de cada arquivo com a extensão qc na pasta v101qc. É chato pra c@#@lh* admitir um erro tão primário, mas tenho alguns fatos em minha defesa.

Existem milhares de códigos qc de mods espalhados pela net. Alguns datam da época do qtest, outros não tem mais que alguns dias de digitados. E quando digo que quake recebeu um número incontável de mods eu não estou brincando. Nos tempos em que o jogo foi lançado, existiam seções inteiras de ftps dedicados exclusivamente a hobistas exporem seus projetos. Coisa na casa dos Gigas já naquela época (idos de 1996-1997). E a criação de novos mods não parou até hoje.

Outro fator que aliado à quantidade massiva de mods contribui para essa zorra toda diz respeito à forma tosca com que a maioria dos programadores (ou hobistas, já que quake c não é uma linguagem "no sentido estrito da palavra") documentam seus projetos. Alguns nem mesmo colocam no readme uma descrição inteligível de seu mod, quanto mais algo complexo como licenciamento.

Neste sentido inclusive projetos que objetivam ser condizentes com os ditames da GPL (openquartz é o mais gritante neste sentido) não são cuidadosos com detalhes simples. Em todos seus arquivos qc os cabeçalhos com a nota de copyright foram sumariamente suprimidas. Isso foi o que me deixou no escuro por todos estes anos até a simples questão do licenciamento me despertar para o óbvio. E acreditem quando digo que é uma tarefa tirana filtrar toda essa massa de informação e encontrar algo que seja minimamente bem documentado.

Dito isso resta apenas declarar que a GPL é um bom instrumento, mas exige alguns cuidados quando do seu uso. Como se diz por aí "o diabo está nos detalhes" e esses detalhes negligênciados pode causar problemas bem maiores que algumas horas perdidas no google, archive e outros locais de limbo na net (meu caso). A FSF (Free Software Foundation) tem toneladas de manuais e páginas contendo informações úteis sobre como licenciar software. Mas basta apertar delete no local errado, zipar o arquivo e enviá-lo para um repositório de arquivos qualquer para causar confusão. Não estou querendo aqui levantar a bandeira do software livre ou dar uma de xiita. Apenas quero construir um mod da maneira que acho coerente. E essa é a maneira que encontrei para isso: sendo coerente com seu licenciamento.

Bom depois desta agora é hora de trabalhar de verdade e fazer o War Z finalmente ver a luz do dia.

Criando programas/jogos para o Sega Mega Drive/ Genesis

Nos idos dos anos 90 o universo dos jogos estava polarizado entre a Sega e a Nintendo. A Sega vinha com a força dos arcades e jogos de esporte - que ainda hoje fazem muito sucesso no mercado norte americano. E sua aposta era no primeiro console de 16 bits do mercado, o Mega Drive, também conhecido como Genesis em alguns países. A Nintendo por sua vez trazia a reputação adquirida com o Nes e grandes parceiros como Capcom, Konami, somente para citar alguns. O seu cavalo de batalha era na época o poderoso Super Nintendo, conhecido no Japão como Super Famicom. Não vou tecer comentários sobre quem venceu a guerra dos consoles, mas posso garantir, como alguém que a viu de perto, que foi um conflito dos mais divertidos da industria do entretenimento - e que deixou imensas saudades.

Mas voltando ao assunto, a Sega lançou o Mega Drive/Genesis e criou uma geração de jogadores facinados pelo aparelho e seu potencial. Alguns cresceram e começaram a projetar meios de criar programas - leia-se também jogos - para o console. Algumas tentativas deram certo, outras não, com variados graus de complexidade. As primeiras experiências exigiam que código fosse escrito em assembler 68K (o processador central do console era um Motorola 68000) e caso houvesse a necessidade, mais assembler, desta vez na variedade Z80 (desta vez o processador de som, o Zilog Z80). Posteriormente surgiram compiladores C, como o obscuro SGCC (Sega Genesis C Compiler) e mesmo métodos para fazer uso do famoso compilador GNU GCC. Tais opções são bacanas para quem tem experiência de programação ou tempo para aprendê-las. Mas os reles mortais do teclado também tem uma opção para criar seus programas para o Mega Drive. Mostraremos hoje como criar e rodar dois programas simples para o Mega fazendo uso da ferramenta Basiegaxorz.

Este bicho acima é o mascote do Basiegaxorz.

Antes de iniciarmos as seguintes ferramentas são necessárias. a) um computador com Basiegaxorz instalado (instalação padrão Windows, isto é, "clic, next, next, clic"); b) um emulador de Mega Drive instalado. Recomendo o Kega Fusion ou o Gens. Feito isso podemos iniciar a criação de programas. Mas é melhor proceder com algumas explicações de antemão. O Basiegaxorz é um compilador basic escrito em Visual Basic, que produz código compatível com Mega Drive, 32x e Sega CD. Isto é, você escreve código no dialeto basic e o Basiegaxorz converte tal código em algo semelhante a rom de um cartucho ou CD, de tal forma que um emulador pode ser utilizado para verificar o resultado ou, se houver alguém afortunado de ter um dos raros flash carts do mercado cinza (os da Tototek, por exemplo), testar no próprio console.

Sob o aspetco técnico o basiegaxorz permite utilizar joysticks (manipulação de entrada) de 03 e 06 botões, tanto para player 1 quanto player 2, criar e movimentar sprites, scroll de planos, manuseio de paletas de cores e criação/gerenciamento de psg de forma muito simplificada.

Reza a lenda que todo primeiro programa a ser escrito, não importa a linguagem, tem de ser o Hello World". Não fugiremos a regra. Com o Basiegaxorz aberto, dê um espaço da margem ou simplesmente aperte tab, e digite o seguinte comando:

print "Ola mundo!"

Aperte F5. Surgira uma mensagem em uma janela informando se a compilação deu certo ou não. Clique em OK. Agora com o emulador aberto procure o arquivo basic.bin, que deve estar em algo como c:/arquivos de programas/basiegaxorz (caso você tenha deixado a instalação padrão). O resultado no emulador é esse:

Bacana não? Agora vamos brincar um pouco com as cores dos textos. O basiegaxorz vem com alguns comandos já prontos para manipular texto, no caso trataremos do comando ink. Novamente com o programa aberto digite o seguinte código (não esqueça do espaço ou de apertar tab antes de cada comando):

ink 0
print "este texto esta em branco"
ink 1
print "este texto esta em azul"
ink 2
print "este texto esta em verde"
ink 3
print "este texto esta em roxo"

Aperte F5. Dê ok na caixa de informações após a compilação e procure novamente o arquivo basic.bin com o emulador. O resultado agora é este:

Legal não? Isso é apenas uma porção ínfima do que é possível criar com o programa. Sugiro uma olhada no manual html que acompanha o programa. Também é recomendável, e muito por que o manual é um tanto árido, dar uma olhada no código fonte de alguns demos criados com esta ferramenta. E por fim fazer muitas tentativas e erros, pois somente assim é possível aprender.

Nas próximas semanas vejo se consigo montar um tutorial com mais detalhes sobre a linguagem e algumas demonstrações de programas.

QuakeC licenciado sob a GPL ou não?

Surgiu uma questão interessante enquanto estava fazendo experiências para o mod War Z (título provisório, como já afirmei aqui). Nada envolvendo a programação em si mas o licenciamento dos pacotes da linguagem quake c disponíveis na rede, que são a base para War Z. Para quem não sabe a ID Software ao criar Quake desenvolveu um subconjunto da linguagem C denominado simplesmente de quakec. Este subconjunto é chamado pela engine sempre que o programa é iniciado com a finalidade de fornecer dados sobre a lógica interna do jogo.

Por exemplo, que armas existem, que tipo de munição utilizam, quanto é possível carregar de cada munição, quanto dano produzem, etc. A inteligência dos mostros, sons ambientais, efeitos de interação como as portas e botões, mensagens entre outras coisas são controladas via quakec e compiladas em um arquivo denominado progs.dat.

Até aqui nada demais. O ideal seria simplesmente pegar o pacote disponível no ftp da ID Software ou em um dos projetos derivados, licenciados sob a GPL como o Openquartz, por exemplo, eu pensei. O objetivo desse "preciosismo legal" tem haver com a coerência desejada. Não é meu interesse criar e lançar um mod com licenças diferentes, ou pior intrinsecamente conflitantes. Assim para manter esta coerência a premissa que adotei foi seguir o mesmo licenciamento da ID ao lançar o código-fonte da engine (GPL versão 2).

O problema realmente aparece agora. Dentro do pacote licenciado sob a GPL, contendo o código-fonte da engine, encontrado no ftp da própria ID não existe nada acerca do quakec. Uma leitura do readme incluso no pacote q1source.zip é bem esclarecedor. Em resumo, temos apenas o código-fonte para construir as versões winquake (modo software), glquake, quakeworld (modo software) e glquakeworld. Sob os auspícios da GPL e nada mais. Nem um vírgula sequer sob o quakec. Ou melhor no meio do código para o Quakeworld existe o qc referente ao código qwprogs.dat.

Depois desta constatação, o próximo movimento foi, ainda dentro do ftp da ID procurar alguma coisa sobre o licenciamento do quakec dentre as ferramentas lançadas pela empresa. As ferramentas são os programas de suporte necessários para a criação de conteúdo, tais como modelos, texturas e o próprio compilador do quake c (qcc). Minhas esperanças era que junto ao compilador existisse algum readme que explicitamente indicasse o licenciamento da linguagem. Encontrei o arquivo q1tools_gpl.tgz com duas pastas, a primeira com o nome de qcc/send. Examinei com atenção e novamente nada sobre o licenciamento do quakec. Sequer sobre o licenciamento do compilador qcc!. Outro fato curioso é que há uma sub-pasta denominada v101qc neste pacote. Presumo que seja a versão 1.01 do código que posteriormente teve bugs corrigidos com o lançamento da versão 1.06 (versão comercial e última lançada ao público).

Passemos então ao readme da outra pasta, chamada de qutils. Mais uma vez nada sobre o licenciamento do quakec ou sobre estas ferramentas estarem licenciadas sob a GPL. Porem, encontrei um arquivo de nome Copying contendo a licença GPL versão 2. Isto levanta algumas hipóteses. A primeira é que todo o pacote é licenciado sob a GPL. O que encerraria a questão e me permitiria trabalhar com base na versão 1.01 do quakec. Mas não é o caso, porque o licenciamento deve, repito deve, ser explícito por parte do autor/criador/desenvolvedor. A segunda hipótese é que apenas as ferramentas estão licenciadas sob a GPL, por esta razão a divisão entre as pastas. O outro pacote então estaria licenciada de maneira diferente, tal como a licença comercial que se adquire ao comprar o jogo. Em suma o problema persiste.

Outros arquivos do ftp, como qcc.tar.gz e qutils.zip, o primeiro contendo o compilador qcc e o segundo outro pacote de utilitários para construir conteúdo, aparentemente foram lançados antes da liberação do código-fonte da engine. Estão, portanto, licenciados sob licença comercial. Ou seja, é inútil ao meu propósito de ser coerente.

Como se as dores de cabeça não já não fossem suficientemente grandes, outros projetos, como o Openquartz (basta ler o readme deles para ver que iniciaram com a versão 1.01 do qc e depois mudaram para a versão 1.06), ou mesmo o repositório de informações QIP (que lançou seus patches para o quakec da ID sob GPL), são baseados na versão 1.06 do código, a versão comercial, do quakec ou não explicitam a origem do código com a qual trabalham.

Soluções? A primeira possível seria utilizar apenas o código quake c do quakeworld existente no pacote q1source.zip. O readme deste pacote explicita que todo o código existente lá é de fato licenciado sob GPL. Assim ao menos seria possível utilizar tutoriais do inside 3D e fazer uso de código com a qual eu já estou relativamente familiarizado. Muito embora o código relativo aos monstros e a inteligência artificial tenham ficado de fora – o que é uma perda e tanto.

A segunda solução possível seria abandonar todo o código quakec escrito pela ID e reescrever tudo do zero. Existe uma série de tutoriais no inside 3D (scratch tutorials) que explica o básico. Reduzindo tudo ao essencial, coisas simples como carregar mapas, o modelo do jogador, sons e a iluminação. O problema é que nunca recebi educação formal em programação e criar tudo do zero seria no mínimo um trabalho considerável para meus conhecimentos.

A terceira solução possível seria novamente abandonar todo o código escrito pela ID e adotar o código qc do Nexuiz. O projeto é todo licenciado sob a GPL e aparentemente a condição para que alguém contribua com este projeto é seguir com o mesmo licenciamento. O problema neste caso é que o código é extremamente diferente daquele concebido pela ID e seria, novamente, um esforço considerável para apreender sua natureza e criar as alterações necessárias ao mod.

Agora respondendo a pergunda formulada no post a resposta é simplesmente que não se sabe. A ID fez uma confusão não lançando um pacote à parte ou simplesmente colocando em um readme no diversos pacotes licenciados sob GPL qual seria a situação da sua linguagem. Uma pena.

Ufa. E eu achava que seria complicado apenas criar conteúdo para o mod...

Quake rodando sob DirectX

Uma coisa sempre me incomdou com as engines derivadas do Quake: O fato de todas, tirando algumas notáveis exceções, serem baseadas na API OpenGL. Não consegui em todos este anos mexendo em meu tempo livre descobrir o por quê, da ID Software ignorar completamente a API DirectX. A Valve, quando produziu Halflife, não se fez de rogada. Embora, houvesse suporte, para os modos software e OpenGL, também disponibilizou renderização via DirectX. A título de lembrança, caso a referência não tenha sido clara, Halflife é baseado na engine do QuakeWorld.

Porém o resultado dessa "predileção" da ID Software eu conhecia bem: Se a placa de vídeo do PC não fosse compatível com o OpenGL, como uma velha Rage Pro 3D que me assombrou por anos, ou simplesmente tivesse um chipset gráfico vagabundo (coisa comum aqui no Brasil) e sem poder de processamento, o jeito pra ter velocidade era jogar no modo software mesmo. Imagine Quake, ainda hoje rei indisputado da velocidade rodando quadro a quadro, algo como 5 fps, e você tem uma vaga noção da tortura.

Atendendo a minhas preces não proferidas em voz alta, o programador MH já vem a algum tempo trabalhando em uma engine substituindo a API OpenGL pela API DirectX. Tirando as controvérsias acerca do potencial de cada API, o objetivo de MH não é simplesmente criar mais um wrapper em torno do código da ID Software. Isto já foi feito e sua forma atual é esta, mas sim atualizar todo o sistema de renderização da engine sob o DirectX.

E devo dizer que os resultados são bastante promissores. A engine de MH, batizada com o singelo nome de DirectQ, é bastante estável e roda de modo impecável. Aparentemente suporta mods, testei como o Openquartz e não houve problemas. Outro diferencial é o fato que MH é cuidadoso com sua cria. O DirectQ tem atualizações constantes e aprimoramentos - como o recente suporte para luzes coloridas, via arquivos .lit, entre outras mais técnicas - mostram o potencial do programador em trabalhar sua engine pro mundo.

Fica a dica para quem gosta de jogar Quake, netquake lembrem-se, e anda tendo problemas com OpenGL ou quer experimentar um engine nova e sólida como um rocha em termos de desempenho.