[MC613] Sobre o VGA.
10 views
Skip to first unread message
Caio
Jun 15, 2012, 6:21:17 PM6/15/12
to mc613_2012_s1
Pessoal,
infelizmente a placa tem uma memória limitada. Isso é ruim do ponto de vista do potencial que vocês poderiam explorar, mas didaticamente eu encaro como uma oportunidade. Vocês como profissionais vão acabar lidando com situações assim novamente.
O que dá para fazer para lidar com as limitações:
1) Usar o máximo possível da memória, mas com o risco de ficar sem espaço para outras utilizações. A placa tem 212992 bits para memória, então, é possível trabalhar com resoluções como 320x220 e 3 bits de cores ou 352x200 e 3 bits cores.
2) Diminuir o número de bits de cores. Você pode usar 320x240 com 2 bits de cores.
3) Usar memória externa. É a melhor opção de todas, contudo, não costumam ser fáceis de trabalhar. A SRAM provavelmente é a mais simples. A SDRAM eu não sei como é implementada na placa, mas se vocês tiverem que fazer o controlador dela, isso seria um projeto a parte, portanto, ela seria inviável. Na época do meu projeto, também havia me deparado com esse problema de resolução. Eu tentei usar as memórias externa, mas depois uma tarde inteira sem sucesso e correndo contra o tempo, optei pela opção 2.
4) Remover do VGACON a dependência de uma memória. Você pode fazer um controlador vídeo que use a memória interna junto de registradores e assim alcançar o número de bits que você deseja.
Agora o mais importante é, antes de vocês gastarem seu tempo precioso tentando uma dessas soluções, preocupem-se em deixar o projeto funcional. Com todo grupo que eu tenho conversado eu tenho insistido para usarem uma matriz (na memória) para lógica do jogo. Essa matriz será lida pelo controlador de vídeo do seu jogo e ele enviará ao vgacon os pixels que devem ser escrito na tela.
Se essa ideia for implementada, uma vez que o projeto esteja ok, vocês só precisarão mudar os componentes que lidam com os pixels e o vga, para melhorar o gráfico e nada mais.
Outra coisa é a demonstração do jogo. Um jogo que os tiros atravessam o alvo, sendo que deviam detruí-lo, objetos que mudam de posição sozinhos, mas não deviam, pontos que não contam e outras bizarrices, mostram um jogo imaturo. As vezes mostram erros conceituais, máquinas de estados erradas, latches inferidos, etc. Isso é pior do que um jogo com gráfico simples, mas que esteja plenamente funcional.
Quem tiver dúvidas, envie e-mail para a lista, talvez uma resposta ajude mais do que apenas um grupo. Semana que vem que quiser ajuda fora do horário de atendimento mande e-mail para marcar um horário.
--
Atenciosamente,
Caio.
infelizmente a placa tem uma memória limitada. Isso é ruim do ponto de vista do potencial que vocês poderiam explorar, mas didaticamente eu encaro como uma oportunidade. Vocês como profissionais vão acabar lidando com situações assim novamente.
O que dá para fazer para lidar com as limitações:
1) Usar o máximo possível da memória, mas com o risco de ficar sem espaço para outras utilizações. A placa tem 212992 bits para memória, então, é possível trabalhar com resoluções como 320x220 e 3 bits de cores ou 352x200 e 3 bits cores.
2) Diminuir o número de bits de cores. Você pode usar 320x240 com 2 bits de cores.
3) Usar memória externa. É a melhor opção de todas, contudo, não costumam ser fáceis de trabalhar. A SRAM provavelmente é a mais simples. A SDRAM eu não sei como é implementada na placa, mas se vocês tiverem que fazer o controlador dela, isso seria um projeto a parte, portanto, ela seria inviável. Na época do meu projeto, também havia me deparado com esse problema de resolução. Eu tentei usar as memórias externa, mas depois uma tarde inteira sem sucesso e correndo contra o tempo, optei pela opção 2.
4) Remover do VGACON a dependência de uma memória. Você pode fazer um controlador vídeo que use a memória interna junto de registradores e assim alcançar o número de bits que você deseja.
Agora o mais importante é, antes de vocês gastarem seu tempo precioso tentando uma dessas soluções, preocupem-se em deixar o projeto funcional. Com todo grupo que eu tenho conversado eu tenho insistido para usarem uma matriz (na memória) para lógica do jogo. Essa matriz será lida pelo controlador de vídeo do seu jogo e ele enviará ao vgacon os pixels que devem ser escrito na tela.
Se essa ideia for implementada, uma vez que o projeto esteja ok, vocês só precisarão mudar os componentes que lidam com os pixels e o vga, para melhorar o gráfico e nada mais.
Outra coisa é a demonstração do jogo. Um jogo que os tiros atravessam o alvo, sendo que deviam detruí-lo, objetos que mudam de posição sozinhos, mas não deviam, pontos que não contam e outras bizarrices, mostram um jogo imaturo. As vezes mostram erros conceituais, máquinas de estados erradas, latches inferidos, etc. Isso é pior do que um jogo com gráfico simples, mas que esteja plenamente funcional.
Quem tiver dúvidas, envie e-mail para a lista, talvez uma resposta ajude mais do que apenas um grupo. Semana que vem que quiser ajuda fora do horário de atendimento mande e-mail para marcar um horário.
--
Atenciosamente,
Caio.
Henrique Massao Sato
Jun 16, 2012, 3:38:09 PM6/16/12
to mc613_...@googlegroups.com
Caio, por acaso tem algum jeito de ter 2 clocks com mesma frequência, mas fases diferentes?
Como a SRAM só lê ou só escreve, preciso sincronizar a leitura da vga com a escrita
Caio
Jun 16, 2012, 9:54:28 PM6/16/12
to mc613_...@googlegroups.com
Use a escrita na borda de descida e a leitura na borda de subida. Talvez isso resolva?
--
Atenciosamente,
Caio.
2012/6/16 Henrique Massao Sato <satom...@gmail.com>
--
Atenciosamente,
Caio.
Henrique Massao Sato
Jun 17, 2012, 12:58:34 AM6/17/12
to mc613_...@googlegroups.com
Eu tentei isso, mas parece que vou precisar de variáveis e mudar bastante o controlador então...
Celso Cardoso
Jun 17, 2012, 9:28:20 AM6/17/12
to mc613_...@googlegroups.com
Eu tentei fazer assim, ele reclama q "nao consegue inferir o tipo de registrador para SRAM_ADDR"
Pensei em fazer um clock 2x mais rapido pra leitura e uma fila de espera pra escrita, por enquanto nao deu. Vou partir para memoria codificada em SPRITES.
Caio
Jun 17, 2012, 10:31:36 AM6/17/12
to mc613_...@googlegroups.com
2012/6/17 Celso Cardoso <celso...@gmail.com>
Eu tentei fazer assim, ele reclama q "nao consegue inferir o tipo de registrador para SRAM_ADDR"
Pensei em fazer um clock 2x mais rapido pra leitura e uma fila de espera pra escrita, por enquanto nao deu. Vou partir para memoria codificada em SPRITES.
Essa da fila é uma boa idéia.
O que vocês podem tentar fazer é um buffer de leitura e escrita com 10 posições por exemplo. Vocês usam instanciações de memória interna da placa. As escritas bufferizam endereço e dado, as leituras os endereços. As leituras são sempre executadas e só vão ser bufferizadas quando o buffer da escrita estiver cheio, quando isso ocorrer vocês fazem um burst de escritas até esvaziar o buffer, seguido de um burst de leituras até esvaziar o buffer de leituras e o processo reinicia.
É um pouco chato, mas eu acho que isso pode ajudar.
Outra coisa que pode ser tentado é uma compressão. Mas mesmo uma codificação de huffman pode dar trabalho.
Enfim, eu vou repetir o que eu disse no outro e-mail, não gastem o tempo de vocês com isso. Façam um gráfico básico e terminem o resto do projeto.
--
Atenciosamente,
Caio.
Reply all
Reply to author
Forward
0 new messages