Caracteríticas do Console Entendo®


Parte I - Divisão da memória

   A memória vai estar dividida nas seguintes áreas:

   a) Imagem (2,4 Mega)
   b) Som    (500K)
   c) Código (1 Mega) 
   d) Pilha  (100K)
   e) Dados  (4 Mega)

   1-a) Imagem

      Cada tela no Modo I (640x480x256) ocupa 300K. Usando até
      4 planos de tela, teremos 1,2 Mega de memória. Permitindo o
      uso de "double-buffering", esse limite sobe para 2,4 Mega.
      Temos, portanto, 2,4 Mega de memória para video. No Modo I,
      isso significa, como vimos, 4 planos com "dubble buffering".
      Ou mesmo 2 planos com "triple-buffering" e 1 com "double-buffering".
      De forma mais crua, são 8 planos ao todo. 

   1-b) Som

      Trilhas sonoras serão, em sua maioria, em MID, o que não
      ocupa muito espaço. Sons digitalizados (efeitos sonoros)
      são de curta duração. Quaisquer conversas digitalizadas
      ou sons maiores deverão ser carregados de forma alternativa
      caso ultrapassem o limite. Um limite razoável seria algo
      em torno de 500K.

   1-c) Código

      Nesta área estão armazenados os dados do código objeto
      do programa principal. Como dito anteriormente, o limite
      é de 1 Mega de código.

   1-d) Pilha
 
      Área da memória reservada para a pilha. A princípio, poderia
      ser algo em torno de 100K.

   1-e) Dados
  
      Nesta área serão armazenadas as variáveis e outros valores do
      programa em tempo de execução (variáveis do sistema, por exemplo).
      Como dificilmente serão usados os 4 Mega para dados, essa área
      pode ser usada como "propósito geral" pelo emulador (por exemplo,
      para carregar sons e imagens temporárias etc.)


Parte II - Tratamento de Imagens


   2-a) Sprites

      Como todos devem saber, "sprites" são as unidades que formam os
      cenários do jogo. Por exemplo, o bonequinho do Mario é um sprite,
      a nave do Space Invaders é um sprite, assim como cada invasor é.

      Os sprites são parte fundamental do jogo. Por isso, deve haver
      alguns mecanismos embutidos no console para facilitar sua manipulação.
      Além de características relativamente simples e óbvias (cores vazadas,
      estruturas para armazenamento) que serão tratadas dentro da linguagem
      e da especificação dos programas, vamos tratar de funções que devem
      ser próprias da "máquina".

      Antes de mais nada, os sprites devem ser armazenados de forma a garantir
      a maior rapidez possivel. Como são muito mais movimentados que o fundo 
      e outros tipos de imagem, eles devem ter a máxima prioridade. Isso
      significa que DE FORMA ALGUMA os sprites devam ser armazenados na memória
      compactados. Por isso, caso os arquivos de imagem contenham alguma
      compactação (PCX, GIF etc.) o emulador, ao copiá-lo para a memória, deverá
      OBRIGATORIAMENTE descompactá-lo antes, e guardá-lo assim. Quanto aos
      demais componentes (como fundos, letras etc.) poderão ser ou não guardados
      assim. Uma boa opção é permitir a escolha ao programador. Outra opção seria
      divir: sprites não são guardados compactos, tipos normais sim. E, para 
      guardar um fundo sem compactação, bastaria declará-lo como sprite. Esse
      método não é muito aconselhável, além de ser pouco elegante.