6o Lugar – And So You Code

Esta encontrei por puro acaso. Eu iria fazer um top 5 e esta me fez criar um 6o lugar. Merece uma menção honrosa.

5o Lugar – Banda Djafu feat Dj Pacote TCP

Bem… A letra é melhor do que o vídeo. Mas vale a conferida!

4o Lugar – Write in C

Foi um clássico no início dos anos 90. Isto explica a ausência de Java e outras linguagens mais novas.

3o Lugar – Lady Java

Ótima! Dispensa comentários. Este vídeo já é um clássico na internet e não poderia deixar de posta-lo.

2o Lugar – Code Monkey

Não sei o que é melhor aqui: Letra, música ou vídeo?

1o Lugar – Eduardo e Monica nerd

Na minha opinião a melhor de todas! Muito bom o trabalho!
Para ver a tirinha original:
http://hacktoon.com/nerdson/os-nerds-tambem-amam-4/

Um brinde

Um outro clássico dos anos 90. Infelizmente não achei a versão musicada. Mas, para não passar em branco, segue a letra:

É pau, é bug
É o fim do programa
É um erro fatal
É o começo do drama

É o Turbo Pascal
Diz que falta um begin
Não me mostra onde,
e capota no fim

É dois, é três
É o quatro-oito-meia
Instrução ilegal
QEMM bloqueia

É o erro no boot
É um disco mordido
Hard disk estragado
Ai meu Deus tô fodido…

São as barras de espaço
Exibindo um borrão
E a promessa de vídeo
Voando pro chão

É o computador
Me fazendo de otário
Não compila o programa
Salva só o comentário

É ping; é pong
O meu micro reboota
O scan não remove o
Vírus filho da puta

O Windows não entra
Nem volta para o DOS
Não funciona Reset
Detona o CMOS

Abort, Retry
Disco mal-formatado
PCTools não resolve
Norton trava o teclado

É a impressora sem fita
Engolindo o papel
Meu trabalho moído
Cuspido pro céu

São as aulas de março
Mostrando o que são
As promessas de micros
Da Computação.

Autor Desconhecido

——

Abraços!
Renato Louro

E realmente gostaria de fazer isso com a sua ajuda. Quero que esta linguagem seja também sua. Ela está sendo pensada agora. Se você gostar da idéia geral, se achar que realmente pode ‘dar samba’, é a hora de entrar e fazer a diferença. Pense em todas aquelas coisas legais que você sempre quis ver em uma mesma linguagem de programação? Talvez Graphol seja a linguagem que poderá transformar isso em realidade até porque estou te convidando, formalmente, a fazer parte desta idealização. Convido você a conhecer o site onde estamos rascunhando a linguagem Graphol.

Mas do que se trata a linguagem?

O próprio nome Graphol já carrega um significado, já mostra à que veio. Acho que deve ser fácil perceber que o nome Graphol vem de graph (grafo).

No meu curso de faculdade eu fui ‘poluído’ pela ideia de grafo de várias maneiras. Minha iniciação científica estava relacionada ao emprego de grafos para determinar regras de negócio em sistemas munidos com IA.

No meu projeto final eu criei um CMS onde os conteúdos, os relacionamentos entre os conteúdos, e o relacionamento entre usuários, permissões e conteúdos eram representados por grafos. Pessoas e conteúdos eram nodos e seus relacionamentos eram arestas. Se um usuário altera um conteúdo, significa a criação de uma aresta com a tag ‘alteração’ ligando o nodo daquela pessoa ao nodo daquele conteúdo. Para ver todos os documentos alterados por uma pessoa, bastava perguntar ao CMS por todos os nodos ligados àquela pessoa por nós ‘alteração’.

E não muito tempo depois, comecei a pensar que, a exemplo do CMS, como seria legal implementar uma linguagem que, nativamente, atuasse sobre grafos. Uma linguagem orientada a grafos. “Graph Oriented Language”, Linguagem Orientada a Grafos. Um novo paradigma? Talvez.

Fato é que eu estou incubando esta ideia e vontade de realização a quase uma década debatendo sobre o como seria esta linguagem com pouquíssimas pessoas. Acho que com umas 5. Entre elas @Chavao e @LucasZeta que estão comigo no projeto.

Ainda não tenho nada de fato. Nem uma especificação formal. Mas acredito que tornar pública a ideia e convocar pessoas interessadas pode ser a única forma de fazer algo acontecer.

Mas antes de dizer sobre Graphol, segue alguns problemas que Graphol terá que se preocupar em solucionar para ser uma linguagem respeitada:

Composição Vs Herança

Logo quando foi lançada por Simula 67 e redescoberta por Smalltalk-80, a ideia de herança entre classes sempre foi considerada um dos principais recursos para reuso de código e uma das grandes justificativas para a própria orientação a objetos. Mas, com o tempo, percebemos que a ideia de composição/agregação entre objetos é superior em vários aspectos à ideia de herança. Vários programadores passam a preferir a ideia de composição/agregação entre objetos. A maioria dos Designer Partners dão preferência a ‘cooperação’ entre objetos e mecanismos para ‘delegação de trabalho’ entre os mesmos do que uma relação ‘cristalizada’ em tempo de definição de classes que é dado pelo mecanismo herança.

Mas é interessante perceber que a ideia focal na maioria das linguagens orientadas a objetos é a herança e não a composição. Para isso basta perceber no esforço envolvido para o programador em implementar uma herança entre classes e uma composição entre elas. Imaginemos um caso hipotético onde queremos que uma classe B reuse as funcionalidades da classe A. Na grande maioria das linguagens, quando tratamos de herança, significa colocar um simples complemento na definição de B como, por exemplo, ‘Class B extends A’. Pronto! B passará a ter acesso a todas as funcionalidades da Classe A.

Já, para implementar uma composição, salvo honrosas exceções como o Ruby, normalmente precisamos:
1- Dizer que B implementa a mesma interface que A;
2- Criar um atributo que aponte para um objeto da classe A;
3- Criar uma maneira, talvez no próprio construtor e/ou por uma função set, de informar para classe B qual é o objeto agregado; e
4- Para cada médodo de A teremos que recriá-lo em B, delegando o trabalho para o método respectivo de A de maneira semelhante à: “function metodo1(arg a, arg b){ super.metodo1(a,b);}”. Ou seja, se queremos redefinir apenas um único método, e temos vinte e um métodos em A, teremos que criar 20 construções como estas.

Dado as vantagens da composição sobre a herança, a implementação do primeiro deveria no mínimo ser tão fácil de implementar quanto o segundo.

Graphol deveria privilegiar a cooperação entre objetos e delegação de responsabilidade ao invés da implementação estrutural de relações de herança.

Ruby achou um caminho com o ‘Forwardable’. Creio realmente que este seja um caminho. Mas ainda podemos fazer ainda melhor.

Orientação a Aspectos

A orientação a objetos é ótima para definir comportamentos análogos verticalmente, isto é, comportamentos herdados via estrutura de herança. Mas, sozinha, não apresenta uma boa solução para tratamento de funcionalidades secundárias que devem se repetir ‘horizontalmente’ por esta estrutura. E, ao encontro desta questão, surgiu a orientação a aspectos.
Mas em geral a orientação a aspecto funciona através de uma extensão feita a uma linguagem hospedeira. Por exemplo temos o AspectJ para Java e o AspectC para a linguagem C.

Acredito que seria ótimo se Graphol, por estrutura, pudesse nativamente, suportar a orientação a aspecto, sem necessitar destas extensões a linguagem raiz. Algumas linguagens, com bons recursos de metaprogramação, são capazes disso. Mas estou falando de algo ainda mais natural para a linguagem.

Programação Concorrente em Geral

Acho que não há dúvidas que uma nova linguagem deve se preocupar com concorrência. Ela deve facilitar ao máximo a vida do programador neste aspecto. Podemos pensar em forks, threads, corrotinas, semáforos, memória compartilhada. Programar de forma concorrente não é fácil. Não costuma ser natural ao programador. Mas, por outro lado nunca foi tão necessário. A forma usual de aumentar a capacidade computacional tem sido multiplicar núcleos, processadores, nós de uma nuvem etc. Graphol precisa ajudar o programador a tirar proveito disso.

E, finalmente, o que é Graphol?

Introdução
Um grafo pode ser perfeitamente usado para modelar vários aspectos da realidade. Nodos modelam objetos/entidades/coisas e as arestas modelam as relações entre elas. Graphol é uma linguagem que permitirá abstrair problemas como grafos, e nos ajudará a tirar vantagens disso. Neste conceito, nodos são pedaços de código. E as arestas ligam estes pedaços de código trazendo certas propriedades a esta relação.

Inicialmente podemos entender os nós como os velhos objetos OO. Não criamos classes, criamos diretamente estes nodos. O function em Javascript é uma boa aproximação do que é um nodo. Uma característica que acho importante é que um nodo possa receber tags. Tags tem várias utilidades. Ajudarão em buscas globais a estes objetos [Para todos os nós com a tag 'documento' faça], assim como fazer as vezes de uma interface: O objeto x tem a tag ‘pessoa’?

Arestas relacionam estes nodos. Alguns também carregarão uma semântica especial, conforme veremos. Arestas também poderiam ter tipos e/ou nomes. Então, poderíamos fazer facilmente a construção:
[Para cada nó 'documento' ligado por uma aresta 'editadoPor' a este nó 'pessoa' em questão faça]

Composição Vs Herança
Determinados tipos de arestas podem unir nós com a semântica semelhante ao ‘Forwardable’ do Rubi. Ou seja, uma aresta do tipo ‘Forward’ significaria que, não encontrando uma definição interna, deveria procurá-la pelo grafo indicado pelas arestas ‘Forward’. Então poderíamos não ter herança. Poderíamos simplesmente apontar para os nós para qual um dado nó deveria redirecionar dadas requisições. Filtros sobre determinada aresta poderia prover um controle mais refinado sobre um redirecionamento em particular. Penso em várias outras coisas sobre estas relações. Mas aqui não é o melhor veículo para esgotá-las.

Orientação a Aspectos
Arestas do tipo ‘doBefore’ por exemplo poderia ligar um nó a outro que deveria ser acionado primeiro sempre um nó fosse acionado. Então poderia ser válido algo como:
[Para todo nó com a tag 'acesso'
ligue com doBefore ao nó valide_usuario]

Programação Concorrente em Geral
Que tal uma aresta startToStart para indicar que um nó será executado em paralelo sempre que um outro iniciar a execução? Imagine um gráfico de Gant. Poderiamos indicar um lag de tempo para as arestas como, por exemplo ‘comece 2 segundos depois’. Um nó poderia estar amarrado para começar uma execução em paralelo após 2 outros terminarem a execução e um terceiro já ter iniciado. startToStart, startToFinish, FinishToStart, FinishToFinish posso imaginar utilidades para todas com a idéia de procesamento paralelo.

Padrão Observer (Coração do MVC Clássico)
Nós também guardam informação. Acho que uma aresta com a semântica ‘doOnUpdate’ poderia ser muito útil.

Metaprogramação
A estrutura de um programa pode ser expressa em termos de árvore que, por sua vez, é um tipo particular de grafo. Bem, estamos criando uma linguagem cujo objetivo é criar/editar grafos. Não parece que fica trivial pensarmos em mecanismos para que um programa Graphol possa fazer referência e/ou alterar sua própria programação naturalmente, isto é, utilizando os mesmos comandos que tratam de nós e arestas que é exatamente o coração da linguagem? Me parece que a programação reflexiva em Graphol poderá ser encarada de forma ‘mais natural’ do que ocorre na maioria das linguagens. Os mecanismos para um programa alterar sua própria estrutura serão exatamente os mesmos pelos quais o programa fará qualquer outra coisa.

Conclusão

Meu objetivo não é esgotar o assunto aqui, até porque Graphol é uma linguagem que ainda será inventada! Este post é para abrir possibilidades e gerar discussão. Entendam o post como quase um início de bainstorming.
Mas para tentar dar uma melhor ideia de como eu imagino Graphol, sabe conceitualmente o que é uma rede neural? Vários nós recebendo estímulos, ponderando estes estímulos e emitindo o seu próprio estimulo para a camada seguinte? Bem, isso deveria ser trivialmente implementável com Graphol.
Sabe uma planilha eletrônica onde cada célula se atualiza dado o estímulo de algumas outras? Bem, isso também.

Abraços e, por favor, já que você leu tudo e chegou até aqui: opine!
Conheça o Manifesto Graphol!

• 1- As variáveis eram globais o que dificulta a criação de novos personagens (aventureiros/árvores) e verificar a colisão entre eles; e
• 2- A rotina de colisão verificava a área inteira da div e, esta área, era maior do que o desenho do personagem. O ideal seria detectar a colisão apenas considerando a área da ‘sola do pé’ do aventureiro ou a ‘base do tronco’, da árvore.

Em resposta a estes problemas, passei a utilizar o conceito de objetos em Javascript que encapsula os atributos básicos de um personagem (aventureiro/arvore) tornando relativamente fácil a replicação deles,i.e., arvore=new personagem(...);.

Dentro deste objeto também encapsulamos uma área interna de colisão. Assim a área de colisão não é mais obrigatoriamente toda a área da div. O efeito ficou bem melhor do que o apresentado na postagem anterior.

Como última alteração significativa, ao criar um novo objeto personagem, automaticamente o novo objeto é inserido num array de personagens. Com isso fica fácil percorrer todo o array para verificar se um objeto em movimento colidiu com algum outro. Mas, antes de ver como ficou o código, veremos a aplicação em funcionamento:

Legal?
Mas se você brincou um pouco perceberá que ainda temos um problema para definir que div ficará sobre a outra. Por exemplo o tronco e raiz da árvore fica sobre a cabeça de um destes aventureiros, quando posicionamos este aventureiro embaixo da árvore. Sem falar que a div de um dos aventureiros etá sempre sobre a div do outro. Isto causa o efeito de pé de um na cabeça do outro. Mas resolver esta questão será assunto para a próxima postagem da série. No momento vamos analisar o como o código evoluiu até agora.

A primeira grande evolução, é um array de personagens. arrPersonagens se encarregará de guardar numa única estrutura todos os personagens (arvores e aventureiros)


var arrPersonagens=new Array();


Todas as variáveis, que antes eram globais, foram reorganizadas. Destas, as variáveis que eram relativas diretamente ao personagem passaram para uma estrutura única chamada personagem. Também passamos para esta mesma estrutura as funções diretamente responsáveis por manipular a mesma.O código desta estrutura está abaixo, bem comentado, com seus atributos e funções internas.


function personagem(piAreaColX, piAreaColY, piAreaColComp, piAreaColAlt, piFrameAtual, piTiraAtual, psDivPersonagem, piTamSprites)
{
var id=-1; //identifica o objeto no arrPersonagens
this.iPosTop; //posição Y do início da div do personagem
this.iPosLeft; //posição X do início da div do personagem
this.iAreaColX; //posição X, relativa a iPosLeft do início da área de colisão
this.iAreaColY; //posição Y, relativa a iPosTop do início da área de colisão
this.iAreaColComp; //Largura da área de colisão partindo de iAreaColX
this.iAreaColAlt; //Largura da área de colisão partindo de iAreaColY
var iFrameAtual=0; //A Dupla iTiraAtual,iFrameAtual marcam em conjunto [+]
var iTiraAtual=0; // a imagem corrente do spritesheet
var divPersonagem; //Faz referência ao objeto html onde será renderizado o personagem
var iTamSprites=96; //Largura e altura de cada imagem do spritesheet e div
var leftKey; //Tecla que moverá o personagem para a esquerda
var rightKey; //Tecla que moverá o personagem para a direita
var upKey; //Tecla que moverá o personagem para cima
var downKey; //Tecla que moverá o personagem para baixo
var sStatus='stoped'; //Status do personagem e animação ('stoped'|'walking')
var cVoltadoPara='L'; //Direção para onde o personagem está voltado ('N'|'L'|'S'|'O')
this.bMove=false; //Informa se um personagem é móvel (aventureiro) ou estático (árvore)

// Verifica se existe colisão entre o objeto corrente e um outro recebido por parâmetro
this.colide = function(ppersonagem){...}

//Informa que o personagem é móvel e informa as teclas de comando
this.addMov = function( pUpKey, pRightKey, pDownKey, pLeftKey) {...}

//Modifica o background da div em função da dupla (iTiraAtual,iFrameAtual)
var paint = function() {...}

//Realiza a movimentação do personagem se sStatus=='walking'
this.anime = function() {...}

//verifica a tecla pressionada e seta iTiraAtual para a animação certa
this.initAnime = function(keyCode){...}

//Interrompe a animação setando sStatus='stoped'
this.stopAnime = function(keyCode) {...}

/***** Inicializa o Personagem *****/
divPersonagem=document.getElementById(psDivPersonagem);
this.iPosTop=parseInt(divPersonagem.style.top);
this.iPosLeft=parseInt(divPersonagem.style.left);
this.iAreaColX=piAreaColX;
this.iAreaColY=piAreaColY;
this.iAreaColComp=piAreaColComp;
this.iAreaColAlt=piAreaColAlt;
iTamSprites=piTamSprites;
id=arrPersonagens.length;
arrPersonagens[id]=this;
paint();
/***** Fim da Inicialização do Personagem *****/
}


Também merece destaque a alteração feita no nosso timeout_trigger. Agora, como ele é responsável por animar vários objetos, ele percorre o arrPersonagens e, caso o personagem tenha movimento (personagem.bMove) é chamada a função de animação do mesmo.


function timeout_trigger() {
for(i=0;i var personagem = arrPersonagens[i];
if(personagem.bMove) personagem.anime();
}
}


Ao final, a criação dos personagens propriamente dita:


perAventureiro = new personagem(20,60,26,36,0,0,'divAnime', 96);
perAventureiro2 = new personagem(20,60,26,36,0,0,'divAnime2', 96);
perArvore = new personagem(20,60,26,36,0,0,'divArvore', 96);

perAventureiro.addMov(87,68,88,65);
perAventureiro2.addMov(85,75,77,72);
timeout_init();


Querendo ver o código completo, fique a vontade para baixar o script aqui.

Pendências para a próxima postagem:

1. Variar o z-index de acordo com a div do personagem; e
2. Criar um novo personagem sem precisar, previamente, criar a div para o mesmo no html. Ou seja, automaticamente criar a div utilizando o DOM.

Abraços e até a próxima!

ATENÇÃO: O Jogo Tron não funciona no IE 7 ou 8. Para rodá-lo é necessário utilizar o Firefox, Safari, Chrome, Opera ou o IE 9 beta!

Os comandos são simples: (Q) e (W) fazem a moto vermelha virar para esquerda ou direita e (O) e (P) viram a moto azul. (Enter) inicia o jog. Quer jogar de novo? Então de (F5), desculpe.

Lembre-se apenas que os comandos viram para a esquerda e a direita da própria moto! Isto significa que se a moto estiver indo para baixo, o botão da direita irá levar a moto para o lado esquerdo da tela! Fácil não?
Então chame seu colega ao lado e bom jogo!

Para quem quer aprender a programar, aprender a programar com o canvas, ou simplesmente quer dá uma olhada, fique a vontade para baixar o código fonte do jogo tron que está bem documentado.

Quem acompanhou os últimos posts sobre programação de jogos e a programação com canvas – se é que existe alguém que ainda acompanha as postagens deste blog :/ – não deve ter problemas para entender o código que, na prática, junta tudo o que temos visto.

Mas, de qualquer forma, em caso de dúvidas, me pré-disponho a tira-las.

Forte abraço,
Renato

Mas, ao contrário do que parece, sou contra reinventar a roda. Simplate foi criado porque acredito que os que Engines que estão publicados hoje deixam de cumprir requisitos que considero como importantes para uma ferramenta do gênero. E, aparentemente, outros possuem esta mesma impressão. Dêem uma procurada em alguns fóruns e vejam o que ocorre quando alguém pergunta qual o template engine para PHP preferido. Talvez, vocês se assustem em perceber que uma parte considerável responde que prefere o próprio PHP para cuidar de seus templates, dispensando qualquer um destes sistemas.

Não parece estranho que vários programadores prefiram utilizar o próprio PHP para manipulação dos seus templates do que optar por uma das muitas ferramentas especializadas para este fim? Por que será que alguns -não poucos- tem esta opinião?

Antes de responder, devemos perguntar: Para que serve um Template Engine?

São dois motivos básicos:

• Facilitar o trabalho no layout codificado possibilitando que até pessoas não experientes em programação e, eventualmente, o próprio HTMLer ou Designer, alterem diretamente o mesmo; e
• Separar a lógica de programação e/ou código do layout.

Resta saber: Os Template Engines existentes atendem bem a estes dois requisitos? Pelo menos atendem melhor do que o próprio PHP já não poderia atender? Vamos avaliar estes itens em separado.

Facilitando o Trabalho no Layout Codificado

Veja abaixo, um exemplo hipotético de html, como ficaria ao receber os códigos em dois template engines, além do próprio PHP e o Simplate:

É verdade tanto o Smarty como o Dwoo simplificaram a marcação de início e fim do bloco PHP, alterando de <?php > para um simples { }. A conseqüência é que, em geral, se escreve menos. Mas, veja que são as mesmas 5 linhas, a mesma lógica, praticamente a mesma utilização. Mas, lógica do PHP foi de fato simplificada? Não parece que ambos fazem mímica do exemplo PHP?

É exatamente por isso que alguns programadores preferem continuar usando o próprio PHP. Grande parte dos Template Engines não simplifica o template codificado quando comparado com o próprio PHP, a ponto de justificar o aprendizado de uma nova linguagem. E a verdade é que muitos dos templates engines tem se convertido em verdadeiras linguagens paralelas.

Podemos já perceber a primeira grande vantagem do Simplate: a correspondência com o html original é direta! São as mesmas 3 linhas. E será sempre assim: correspondência linha a linha. Nenhuma tag acrescentada, nenhuma tag retirada. Sempre!

Perceba também que uma codificação Simplate pode ser aberta diretamente pelo navegador, independente de servidor Apache ou IIS. Neste caso, o HTMLer/Designer deverá ver exatamente aquilo que ele havia gerado.

Mas, e se no nosso html de exemplo o HTMLer/Designer tivesse adicionado algumas outras linhas options como exemplo? A correspondência linha a linha do Simplate continuaria? Sim! Com o – ainda não famoso – bind=fake. Esta instrução faz com que o simplate entenda que o dado referido é um mero exemplo, e deve ser retirado da compilação final. Ex.:

Isto cria muitas possibilidades. Por exemplo, um programador pode enviar por email o template codificado e perguntar ao HTMLer/Designer: O que ficou errado na montagem?

Mas, já que foi falado sobre o Smarty e o Dwoo, uma análise séria não poderia estar completa se não comentássemos sobre o TinyButStrong. Ele está numa categoria diferente dos dois chamada de ‘natural templates’. O Simplate também estaria nesta categoria. Os ‘natural tamplates’ são todos os template engines que não alteram a estrutura do html, assim como o Simplate. Mas, o Simplate vai ainda além, procurando respeitar também o conteúdo original do template, com todos os seus exemplos de utilização. O TinyButStrong- que merece muito ser conhecido-, coloca seus comandos exatamente no lugar do que seria o conteúdo. Sem falar que, na minha opinião, seus comandos são menos intuitivos. Simplate se torna assim ainda menos intrusivo!

Ser o menos intrusivo possível no Layout/HTML causa duas conseqüências diretas:

• Diminui consideravelmente os erros de montagem do HTML+(Tags PHP ou de outro Engine); e
• Caso, ainda assim, o erro surja -digamos que o fechamento de uma tag seja excluído por acidente- o HTMLer ou Designer encontrará um código muito mais limpo e familiar para ajudar na depuração, pois verá o seu próprio código com apenas alguns atributos a mais em algumas tags.

Fecharemos este tópico com a 1a Premissa do Desenvolvimento Simplate:
- O HTML original deve ser preservado. O Simplate deve permitir que o layout já codificado abra diretamente no navegador apresentando exatamente a mesma forma e conteúdo de quando foi criado.

Separando o Layout da Lógica

Isto alguns Template Engines fazem até bem. Mas, outros nem tanto. Como falado, muitos deles têm se convertido numa linguagem à parte, e até poderosa, com direito a IFs, Cases, For, manipulação de variáveis etc.
Em resumo, a lógica pode tranqüilamente aparecer no layout. O que salva isso é o cuidado do programador. E se é para depender do cuidado do programador para evitar o aparecimento da lógica no layout, segue a pergunta recorrente: Por que não utilizar o próprio PHP?

O Simplate possui um número reduzido de comandos que realmente evita o aparecimento de lógica de programação no template codificado. Por exemplo, não temos IF e não sentimos falta dele. Caso seja necessário saber se um bloco deve ou não aparecer, podemos utilizar o próprio comando bind. Um bind em qualquer valor nulo ou indefinido fará com que o bloco do mesmo não apareça.

Na verdade o bind serve para muita coisa:

• Não temos include, pois um bind em um objeto Simplate inclui outro template;
• Não temos IF, pois um bind em um valor nulo ou não pode fazer um bloco sumir ou não; e
• Não temos For, pois um bind em um Iterador, provoca a repetição.

Simples isso, não?

E segue agora a 2a Premissa do Desenvolvimento Simplate:
- Mantenha o Simplate simples!

Dois Requisitos e Duas Premissas que nos levaram ao Simplate

Resumindo, esta é a pequena história do Simplate. Encontramos com os dois requisitos que acreditamos que não estavam sendo cumpridos de forma apropriada:

• Facilitar o trabalho no layout codificado possibilitando que até pessoas não experiêntes em programação e, eventualmente, o próprio HTMLer ou Designer, alterem diretamente o mesmo; e
• Separar a lógica de programação e/ou código do layout.

Para atender estes requisitos melhor do que qualquer outro Template Engine, foram criadas as duas premissas. Cada uma indo ao encontro de um requisito:

• Os comandos Simplate devem preservar o HTML original, mantendo conteúdo e a forma do mesmo; e
• Mantenha o Simplate simples!

Estes são os dois princípios que norteiam o desenvolvimento do Simplate. Qualquer decisão de projeto que tenha que ser tomada é comparada com estes dois princípios.

E você? Gostou destes princípios? É o que você busca? Então? Que tal se juntar ao time? Ainda existe muito por fazer.

E seja bem vindo ao SIMPLATE!
Esperamos que Goste!
Simplate: http://simplate.org

Maceo, 2005

   //obtem objeto canvas
   cnv = document.getElementById(psIdCanvas);

   //obtem o contexto 2d
   ctx = cnv.getContext('2d');

   //pega os valores de altura e largura do canvas
   w=parseInt(cnv.width);
   h=parseInt(cnv.height);

//cria ou obtem o array de pixels
if (ctx.createImageData) {
   img = ctx.createImageData(w, h);
} else if (ctx.getImageData) {
   img = ctx.getImageData(0, 0, w, h);
} else {
   img = {'width' : w, 'height' :h, 'data' : new Array(w*h*4)};
}

//a variavel arrPix é o seu array de pixels
arrPix = img.data

Do exemplo acima temos um array de dimensão w*h*4, onde w*h é a quantidade de pixels e o 4 vem do fato de que cada pixel é composto de 4 canais: red, green, blue e alpha – transparência.
Tentando exemplificar um pouco, a estrutura do array é:

[componente red do pixel 1,
componente green do pixel 1,
componente blue do pixel 1,
componente alpha do pixel 1,
componente red do pixel 2,
componente green do pixel 2,
componente blue do pixel 2,
componente alpha do pixel 2,
componente red do pixel 3,
componente green do pixel 3,
...]

Onde o valor de cada componente varia de 0 à 255.

Ou seja, se, e somente se, seu canvas tiver 300px de largura, sua primeira linha será representada pelos pixels de 0 -red do 1o pixel – até 1200 – alpha do 300o pixel.
Então para colocar o pixel do meio da 2a linha como verde o código seria: arrPix[1801]=255;arrPix[1803]=255; .
Onde arrPix[1801] é a componente verde do pixel que se inicia em 1800; e
arrPix[1803] é a transparência do mesmo onde o 255 é o sólido sem transparência.

Depois de tudo devemos utilizar a instrução abaixo para atualizar o canvas:

context.putImageData(imgd, 0,0); //cria a imagem na posição 0,0 do canvas.

Convenhamos: É possível trabalhar assim. Mas não é nada prático.
Então criei a classe abaixo chamada bitMapCanvas para facilitar a nossa vida:

function bitMapCanvas(psIdCanvas)
{
   this.cnv; //canvas
   this.ctx; //context
   this.img; //imagem
   this.w;
   this.h;

   //obtem objeto canvas
   this.cnv = document.getElementById(psIdCanvas);

   //obtem o contexto 2d
   this.ctx = this.cnv.getContext('2d');

   //pega os valores de altura e largura do canvas
   this.w=parseInt(this.cnv.width);
   this.h=parseInt(this.cnv.height);

//cria ou obtem o array de pixels
if (this.ctx.createImageData) {
   this.img = this.ctx.createImageData(this.w, this.h);
} else if (this.ctx.getImageData) {
   this.img = this.ctx.getImageData(0, 0, this.w, this.h);
} else {
   this.img = {'width' : this.w,
                  'height' :this.h,
                  'data' : new Array(this.w*this.h*4)};
}

this.setPixel=function(piLeft, piTop, piRed, piGreen, piBlue, piAlpha)
{
   iPixel=piTop*this.w*4+(piLeft*4);
   this.img.data[iPixel]=piRed;
   this.img.data[iPixel+1]=piGreen;
   this.img.data[iPixel+2]=piBlue;
   this.img.data[iPixel+3]=piAlpha;
   this.ctx.putImageData(this.img, 0,0);
}

this.getPixel=function(piLeft, piTop)
{
   iPixel=piTop*this.w*4+(piLeft*4);
   return [this.img.data[iPixel],
             this.img.data[iPixel+1],
             this.img.data[iPixel+2],
             this.img.data[iPixel+3]];
}

this.clear=function()
{
   this.img = {'width' : this.w,
                  'height' :this.h,
                  'data' : new Array(this.w*this.h*4)};
   this.ctx.putImageData(this.img, 0,0);
}

this.getContext=function()
{
   return this.ctx;
}

}

Dado um elemento html canvas de id=arena de width=”300px” e height=”300px”, segue a demonstração de como utilizar o bitMapCanvas:

//obtem um novo bitMapCanvas ligado ao canvas arena.
 G_bcvArena = new bitMapCanvas('arena');  

//desenha o famigerado pixel verde no centro do canvas
G_bcvArena.setPixel(150,150,0,255,0,255);

//Querendo desenhar outras formas basta obter o contexto e utiliza-lo normalmente.
ctx = G_bcvArena.getContext();

//Como nem sempre é simples encontrar um pixel isolado na tela,
//desenharemos um círculo em volta do mesmo
ctx.beginPath();
ctx.arc(150, 150, 10, 0, Math.PI*2, true);
ctx.closePath();
ctx.stroke();

E é isso! Abraços e até a próxima!

Dropbox: Repositório de Arquivos Online

Outras Funcionalidades

1- Acesso pelo Sistema de Arquivos:

Você não precisa acessar uma página na internet ou utilizar o navegador para salvar ou obter seus arquivos. O Dropbox cria uma pasta no seu computador. Para guardar ou compartilhar determinado arquivo basta copiar para a pasta do Dropbox.

2- Acesso Web:

Mas caso esteja em um computador de terceiros no qual você não tenha o Dropbox instalado, você pode acessar seus arquivos via interface web!

3- Controlador de Versões:

Acessando pela interface web, você pode recuperar uma versão mais antiga do seu trabalho. Por exemplo que eu posso ter acesso a várias versões do projeto 3D maker. É uma ferramenta de backup online muito fácil de ser utilizada pois basta copiar para sua ‘pasta Dropbox’.

4- Compartilhamento de Arquivos/Pastas

Você pode selecionar alguns sub-diretórios do seu dropbox para manter compartilhado com uma ou mais pessoas.Eu outras palavras, o arquivo que você copiar para uma pasta

Caso você vá diretamente ao site: http://www.dropbox.com/ você começará com 2GB de espaço.
Caso você seja indicado você ganha +250Mb além dos 2GB- segue meu link de indicação: https://www.dropbox.com/referrals/NTk5Nzg5MjQ5?src=global6 (indo por este link vc ganha os +250Mb)

Cada pessoa que vc indica, ganha +250Mb até um limite de 8GB. Mais do que isso só na versão paga.

É um serviço muito bom que pode manter seus dados sincronizados entre seus computadores e te permitir acesso web. Acho que vale a pena ao menos testar!

Forte Abraço!

Desenvolvia, nas horas vagas, para treinar C e SDL, o SDLSoccer, que acabou ficando mais para um WarSoccer . Num próximo post apresentarei ele para vocês reescrito também em js. Mas o importante é que eu estava tentando utilizar a tal lógica para impedir que os jogadores entrassem um dentro do outro, dando um efeito meio ‘fantasma’. Mas com a rotina de colisão que estava usando, nada dava certo. E depois de muito depurar, afinal era madrugada, cheguei a conclusão que o erro tinha que estar nela. Então acabei fazendo um mais simples.

Se detectar colisão em retângulos é relativamente simples, mais simples ainda é detectar quando não ocorre a colisão, que foi a lógica que adotei. Mas antes vejam esta rotina funcionando no exemplo abaixo, impedindo que a div do guerreiro entre na div da árvore:

Vamos lá:

Sendo r1 e r2 os retângulos 1 e 2 podemos afirmar que não haverá colisão de r1 estiver todo a direita ou todo a esquerda de r2. Ou seja se r1.x+r1.w<r2.x ou r1.x>r2.x+r2.w conforme mostra o diagrama abaixo:

Caso contrário, ainda podemos afirmar não haverá colisão se r1 estiver totalmente acima ou totalmente abaixo de r2. Ou seja se r1.y+r1.h<r2.y ou r1.y>r2.y+r2.h conforme mostra o diagrama abaixo:

Caso contrário, se r1 não está nem totalmente acima ou totalmente abaixo ou totalmente a direita ou ainda a esquerda, então afirmamos que existe colisão!

Com isso o código que era:

bool colidiu(SDL_Rect r1, SDL_Rect r2)
{
if ((r1.x >= r2.x && r1.x <= (r2.x + r2.w) &&
r1.y >= r2.y && r1.y <= (r2.y + r2.h)) ||
((r1.x + r1.w) >= r2.x && (r1.x + r1.w) <= (r2.x + r2.w) &&
(r1.y + r1.h) >= r2.y && (r1.y + r1.h) <= (r2.y + r2.h)))
return true;
}

Transformamos em algo mais simples e, no mínimo, mais legível:

bool colidiu(SDL_Rect r1, SDL_Rect r2)
{
if((r1.x+r1.w < r2.x) || (r1.x > r2.x+r2.w)) return false;
if((r1.y+r1.h < r2.y) || (r1.y > r2.y+r2.h)) return false;
return true;
}

ou ainda, numa forma ainda mais simples:

bool colidiu(SDL_Rect r1, SDL_Rect r2)
{
if(((r1.x+r1.w < r2.x) || (r1.x > r2.x+r2.w)) ||
   ((r1.y+r1.h < r2.y) || (r1.y > r2.y+r2.h))) return false;
return true;
}

Traduzindo para Javascript:

function colide(r1_x, r1_y, r1_h, r1_w, r2_x, r2_y, r2_h, r2_w)
{
    if((r1_x+r1_wr2_x+r2_w) ||
       (r1_y+r1_hr2_y+r2_h)) return false;
	return true;
}

No nosso código, só precisamos fazer uma pequena alteração ao final da função trigger: Ao fim dela verificaremos se houve colisão. Caso tenha havido, restauramos a posição anterior da div do aventureiro, conforme vemos abaixo:

	if(!colide(iPosLeft, iPosTop, iTamSprites, iTamSprites,
        iPosLeftArvore, iPosTopArvore, iTamSprites, iTamSprites))
	{
      //não tivemos colisão, então a nova posição é aceita.
      divAnime.style.left=iPosLeft;
      divAnime.style.top=iPosTop;
      return;
	}
       //colisão detectada, posição restaurada.
	iPosLeft= iAtualLeft;
	iPosTop = iAtualTop;

Conclusões:
Embora esta função, tal qual, seja ótima para jogos 2D 'chapados', ela não fica bem em jogos que simulam perspectiva como este. Para casos como este é conveniente determinar uma área de colisão diferente da definida pela própria div. Nas próximas postagens veremos como fazer o ajuste fino na área de colisão encapsulando div, retângulo e posição do personagem num único objeto.

Abraços e até a próxima!

Para produzir o efeito acima o fundamental é entender o posicionamento absoluto e relativo de uma div. Em uma curta definição.

1. Ao aplicarmos o posicionamento absoluto ou relativo em uma div ganhamos o direito de definirmos valores para os atributos top e left e assim posicionarmos livremente esta div;
2. Uma div posicionada relativamente, ao definirmos top e left, se desloca do ponto onde ela deveria estar posicionada originalmente;
3. Uma div posicionada absolutamente se desloca do ponto (0,0) – canto superior esquerdo – do primeiro container registrado com posicionamento relativo ou absoluto no qual ela estiver inserida;
4. Se uma div absoluta não estiver inserida em nenhum container definido com posicionamento relativo ou absoluto, sua referência para deslocamento será o ponto (0,0) do documento.

Exemplificando, temos abaixo 3 estruturas idênticas. A diferença está no posicionamento da div azul definida no estilo:

Vamos voltar ao nosso problema original? O ponto central deste post é a movimentação de uma div que contém a animação do personagem vista na postagem anterior. E se queremos movimentar a div, alteraremos as propriedades top e left da div do personagem. Para isso montamos a estrutura abaixo:

E, por último, algumas poucas variações no código mostrado anteriormente. Agora precisaremos variar o top e left da div do personagem em conjunto com a própria animação.

function timeout_trigger() {
     // Guarda as posições atuais de left e top caso seja necessário restaura-las.
	 var iAtualLeft=iPosLeft;
	 var iAtualTop=iPosTop;

	 frameAtual++;
     if(frameAtual==8) frameAtual=1;
     divAnime.style.backgroundPosition="-"+(frameAtual*iTamSprites)+"px -"+(tiraAtual*iTamSprites)+"px ";
	 //Dependendo de para onde o personagem está voltado, atualizamos o top ou left
	 switch(cVoltadoPara)
     {
        case 'L':
		   iPosLeft=iPosLeft-iTamPasso;
           break;
        case 'N':
		   iPosTop=iPosTop-iTamPasso;
		   break;
        case 'S':
		   iPosTop=iPosTop+iTamPasso;
		   break;
        case 'O':
		   iPosLeft=iPosLeft+iTamPasso;
		   break;
    default:
      break;
    }

	//Evita que o personagem avance pelas bordas do campo.
	if(iPosLeft<0 || iPosLeft+iTamSprites>iWCampo ||
           iPosTop<0 || iPosTop+iTamSprites>iHCampo)
	{
	   //Neste caso a posição anterior é restaurada
	   iPosLeft= iAtualLeft;
	   iPosTop = iAtualTop;
	   return;
	}
	//As propriedades left e top da div do personagem é finalmente atualizada.
    divAnime.style.left=iPosLeft+"px";
    divAnime.style.top=iPosTop+"px";
}

Pendências

Temos pelo menos 2 pendências claras:

1. O personagem se comporta como um fantasma passando por dentro da árvore. Para evitar isso, na próxima postagem da série veremos como detectar colisões;
2. Eventualmente a div da árvore fica posicionada sobre o aventureiro, mesmo quando não deveria. Ainda nesta série veremos como utilizar a propriedade z-index para definir que div deve estar na frente da outra.

Abraços e até a próxima!

Mas antes de continuarmos veja como fica o resultado do trabalho pronto:

Se você leu o post anterior sobre animação js, conforme foi recomendado, verá que a estratégia é bem próxima. A grande diferença é que enquanto no anterior alterávamos o conteúdo de cada tag que representava uma perninha do bicho, neste temos apenas um elemento, uma div, de tamanho fixo, onde variaremos o seu background. Para ser exato, como vocês verão, não alteramos a imagem background mas sim o posicionamento da mesma.
Para realizar este efeito você precisará montar ou encontrar um arquivo chamado de sprite sheet. Um bom exemplo de sprite sheet é este que ilustra o post. Clique nele para ver a imagem ampliada. Mas é importante que seu sprite sheet – também conhecido como titleset – esteja arrumado de uma maneira lógica que permita uma programação conveniente. Recomendo que:
1o Cada linha do seu sprite sheet represente uma animação. Ex.: Andando para a esquerda ou, bebendo água etc;
2o Cada coluna seja um frame da animação específica;
3o Cada frame tenha um mesmo tamanho. No meu caso todos os ‘bonequinhos’ tem 96x96PX.

O sprite sheet que estou usando é quase isso. Apenas o primeiro frame de cada linha que é o personagem parado naquela direção. Sem problemas. Na prática você irá ajustar a programação ao seu sprite sheet. Veja duas linhas do que estou utilizando:

—-	Parado Frame 0	Frame 1	Frame 2	Frame 3	Frame 4	Frame 5	Frame 6	Frame 7	Frame 8	Frame 9
Animação 0
Animação 1

Depois de ter encontrado, montado e/ou criado seu sprite sheet, teremos que criar uma div para conter o personagem. Esta div deverá ter o mesmo tamanho de uma imagem isolada do seu sheet. No meu caso, isto significa que a div terá 96px por 96px.

Os mais atentos logo perceberão que a imagem de fundo inteira tem 960×768 pixels. Simplesmente não cabe inteira como fundo de uma div de 96×96 pixels. E é aí que está o segredo!

A idéia é posicionar o background com posições negativas de modo que no div, que funcionará como uma espécie de janela, mostre exatamente o frame escolhido da animação corrente.
Então, de cara, temos uma pequena fórmula para solucionar: Dada uma animação – linha – e um frame – coluna – qual a posição que o background deve ter para mostrar no div o frame correto?

No caso de frames de 96 por 96 pixels a fórmula para o posicionamento do background é:
top: -96*Animação
left: -96*Frame

Com isso o código inicial fica:

//Define o frame inicial como o 0 da animação(tiraAtual) 0. Isto significa
//   'Parado para a direita'
var frameAtual=0;
var tiraAtual=0;
//Obtém a referência para a div do personagem
var divAnime=document.getElementById('divAnime');
//Inicializa a variável que conterá a referência para o temporizador.
var timeout=null;

//Iniciamos o background da div em (0, 0) Isto fará que apenas a primeira
//   figura seja mostrada.
divAnime.style.backgroundPosition="-"+(frameAtual*96)+"px -"+(tiraAtual*96)+"px ";

Assim como no post anterior definiremos as funções temporizadoras. A timeout_init e a timeout_clear ficam praticamente idênticas as do outro post com animação de caracteres. Já a timeout_trigger muda um pouco já que agora reposicionaremos o background de uma div em vez de modificarmos o conteúdo de uma tag.

/*******************************************************
*  timeout_init():
*  Inicia o temporizador. Agenda a função timeout_trigger() para executar
*     a cada 100 milisegundos
*******************************************************/
function timeout_init() {
   if(timeout==null) timeout = setInterval('timeout_trigger()', 100);
}
/*******************************************************
*  timeout_trigger():
*  Faz a animação. Sempre que chamada varia o frame atual entre 1 e 7.
*  Neste caso o frame 0 é o personagem parado.
* Após atualizar o frame, reposiciona o background.
*******************************************************/
function timeout_trigger() {
	 frameAtual++;
     if(frameAtual==8) frameAtual=1;
     divAnime.style.backgroundPosition="-"+(frameAtual*96)+"px -"+(tiraAtual*96)+"px ";
}
/*******************************************************
*  timeout_clear():
*  Para o temporizador interrompendo também a animação.
*******************************************************/
function timeout_clear() {
    if(timeout!=null){
	   clearTimeout(timeout);
	   timeout=null;
	}
}

O próximo passo é tratar os eventos do teclado para que iniciem ou interrompam a animação. Primeiro pegaremos o evento keydown, ou seja, quando a tecla é pressionada. Neste momento, nós devemos redefinir a animação, tiraAtual, corrente e reiniciar o timer.

document.onkeydown = function(event) {
  var keyCode; 

  if(event == null)
  {
    keyCode = window.event.keyCode;
  }
  else
  {
    keyCode = event.keyCode;
  }
  switch(keyCode)
  {
	// left
    case 37:
      tiraAtual=7;
	  if(frameAtual==0) timeout_init();
      break;
    // up
    case 38:
      tiraAtual=1;
	  if(frameAtual==0) timeout_init();
      break;
    // right
    case 39:
      tiraAtual=0;
	  if(frameAtual==0) timeout_init();
      break;
    // down
    case 40:
      tiraAtual=4;
	  if(frameAtual==0) timeout_init();
      break;
    default:
      break;
  }
}

E, por último, quando retiramos o dedo da tecla, definimos o frameAtual como 0 – personagem parado – e paramos o temporizador.

document.onkeyup = function(event) {
  var keyCode; 

  if(event == null)
  {
    keyCode = window.event.keyCode;
  }
  else
  {
    keyCode = event.keyCode;
  }
  switch(keyCode)
  {
    case 37:
    case 38:
    case 39:
    case 40:
	  timeout_clear();
      frameAtual=0;
	  divAnime.style.backgroundPosition="-"+(frameAtual*96)+"px -"+(tiraAtual*96)+"px ";
      break;
    default:
      break;
  }
}

E é isso, espero que tenham gostado da postagem!
Um forte abraço!

Créditos e Uma Ótima Dica

Um ótimo lugar para arranjar personagens, monstros e tiles em geral é no blog/site Reiner`s Tilesets – FREE GAMEGRAPHICS AND FREEWAREGAMES. Foi lá que arrumei este e vários outros!