discussão sobre sprites

[RodrigoDornelles]

Porque ainda não foi implementado?

Bom, alguns recursos mais avançados na engine estão passando primeiro que coisas essenciais como possibilidade de mostrar imagens, o motivo é no qual que é uma decisão dificil de design e não de implementação, não pretendo voltar altrás removendo alguma feature após disponiblizar API.

Existe limitações?

A engine tenta nivelar as plataformas com algo que seja possivel com Ginga.

• ginga não tem restrições quanto a profundidade e tamanho (inclusive ser 4K HDR)
• ginga consegue renderizar imagens que estão no storage local (limitado a 6MB)
  • contéudo de 6MB vem por via de sinal digital esse recurso é compartilhado não só com o game.
    • código engine
    • código base do launcher
    • conteúdo de anunciantes: fotos, audios, videos... (geralmente em alta qualidande e solitar grande parte da banda)
    • aplicativo da empresa que contém o launcher
  • quando alterado o contéudo do storage o aplicativo de todos os usuários fecham
• existem alternativas para tentar utilizar imagens sob demanda, mas ainda não foram testadas a fundo.
  • geração em tempo real
    • pode ser um recurso iteressante apenas para QR Code, que seria uma thread separada para renderizar uma imagem, e mostrar apenas 1 frame statico, pois é muito demorado a renderização pixel a pixel de imagens grandes ou fazer decoders complexos como JPEG, PNG, BPM... e qualquer formato que não seja RAW pixel a pixel.
  • composição de surface
    • não é certo a compatibilidade disso com as televisões
    • não existe documentação sobre a liberação de canvas gerados dinamicamente
      • pode ser que seja algo possivel de se fazer em lua, como limpar uma table
      • pode ser que seja algo não implementado e/ou não especificado
      • a falta desse recurso impacta na longevidade de apps abertos em vista que imagens não utilizadas não podem ser liberadas
  • provavelmente os sprites viriam em um formato próprio da engine
    • seria necessário a existencia de um conversor
    • poderia ser usado o formato já existente de um console antigo (como mastersystem), ou um fantasy console (tic80)
    • deve ser definida uma profundidade de cor baixa por sprite

Decisões de Design

Sou a favor da limitação de cores na engine, isso força ao desenvolvedor aproveitar melhor os recursos e focar melhor no design do que um leque muito aberto de opções como RGB, mas também existe a questão de marcas, e como marcas poderiam usar suas próprias cores.

• Utilizar um sistema de paleta?
  • a utilização de paletas de cores pode permitir a possibilidade de sprites sob demanda, assim não limitado ao storage do ginga.
  • é a limitação da quantidade de cores em uma tela ou sprite, você pode enumerar as cores e trabalhar inclusive com alteração dinamica dos sprites em tempo de jogo.
    • utilizar paletas reduz o tamanho de armazenamento dos sprites
    • utilizar paletas também otimiza o renderizador da engine
    • utilizar é uma boa decisão para game design, pois força o artista a manter uma tematica visual
  • existem basicamente dois tipos da paletas em engines.
    • FIXAS (grande número de cores)
      • engine que utilizam paletas fixas como PICO8, possuem uma variedade de opções de cores pre-selecionadas
      • exemplo: 0 branco 1 preto 2 azul 3 vermelho ...
      • geralmente é um número próximo de 128 cores, que podem ser exibidas simultaneamente.
      • os graficos ficam bem caracteristicos já que não é possivel escolher uma cor em especifico.
        • ponto contra é que é marcas não podem usar suas próprias cores
          • pode haver exceções para parceiros, onde seria diretamente adiconada a cor na engine.
      • engines que usam paletas fixas costumam ter uma identidade visual caracteristica e unica.
    • DINAMICAS (cores limitadas, personalizadas)
      • paletas dinamicas são comuns em consoles antigos como nintendo, mastersystem, gameboy... basicamente você tem uma quantidade de paletas disponivel e cada paleta uma quantidade de sprites, mas você pode escolher as cores individualmente (ou não)
      • exemplo paleta 1 cor 1 paleta 1 cor 2 paleta 1 cor 3 paleta 2 cor 1...
      • geralmente 4 a 8 paletas de 8 a 32 cores
      • sprites feitos em paletas dinamicas podem ser ainda menores que paletas fixas
      • não existe vantagens em relação ao desempenho de paletas fixas (em teoria mais lento, mas é imperceptivel)
      • é facil de trabalhar com modos de acessibilidades para quem tem deficiencias visuais
      • reaproveitamento de cores e spriteshift é algo essencial
• limites de sprites?
  • devem existir quantidade maxima de sprites na tela?
    • omitir sprites quando estiver pesado para engine renderizar todos ao mesmo tempo.
  • sprites devem ter limite de tamanho?
    • 128x128, 64x64?
• perimtir sprites venham sob demanda?
  • deve existir auditoria desses sprites?
  • todo o sprite deve vir sob demanda depois que carregado na plataforma?
• Fotos devem ser consideradas ou apenas sprites?
  • suportar JPEG super comprimidos?
    • jogos como buckshot roulette apelam para um visual mais saturado, o que pode ser tirado proveito de imagens de baixa qualidade serem armazenados.
  • se utilizar imagens, deveria existir algum sistema de "fuel" para o storage? exemplo jogo tal consome 50 fuel, que seria equivalente ao espaço disponivel no storage, e para jogos novos entrar, todos que possuem imagens devem caber na transmissão.
    • deveria existir algum tipo de votação para os jogos que entrariam no próximo dia
    • foi feito uma pesquisa, e desde de que os jogos fossem legais, não se importariam que na plataforma da TV tivesse uma pequena lista disponivel por dia
    • jogos que não usam imagens (focados em wireframe), não precisam demandar já estarem pré alocados no storage.

Porque Bitmap?

• https://gibberlings3.github.io/iesdp/file_formats/ie_formats/bmp.htm

Lua não é a melhor linguagem para escerever um encoder/decoder ou ferramenta de compressão, além disso o algumas televisões tem péssimo desempenho em executar o código, dito isso, um formato sem compressão seria o melhor a se optar, algo bruto, raw, como .bmp, mas para ainda oferecer o recurso de transparencia, pode se escolher uma cor arbtraria em tempo de execução para ser o fundo.

Sobre interfaces?

• as imagens deveriam ser pré carregas? isso facilitaria o trabalho do lado da engine pois seria mais próximo de um cenário real.

exemplo 1

local function init(std, game)
 game.spr_player = std.img.create('./assets/player.png')
end

local function draw(std, game)
  std.img.draw(x, y, game.spr_player)
end

exemplo 2

local function init(std, game)
 game.spr_player = std.load.spr('./assets/sprites/player.raw')
 game.pal_player = std.load.pal('./assets/palette/player.raw')
end

local function draw(std, game)
  std.draw.spr(x, y, game.spr_player, game.pal_player)
end

exemplo 3

algo que pensei seria suportar apenas o formato BMP, por limtações de velocidade no ginga, seria um formato facil de decodiar em apenas LUA, mas poderia ter a melhoria, que pudesse escolher uma cor arbtrariamente para ser transparente.

local function init(std, game)
 game.spr_player = std.load.image('./assets/sprites/player.bmp', 0x00FF00FF)
end

local function draw(std, game)
  std.draw.image(game.spr_player, x, y)
end

examplo 4

std.img.load('file://asdsadas')
std.img.load('blob://' + buffer)
std.img.load('http://' + buffer)
std.img.free()

---

a medida que eu pensar em mais detalhes irei adicionar nesse tópico.

[RodrigoDornelles]

Atualmente existe a api std.image.draw() estou pensando em investir nesse namespace e muitas funçoes relacionadas.

std.image.load(src)             -- inicia o carregamento da imagem
std.image.unload(src)           -- descarrega a imagem da memória
std.image.unload_all()          -- descarrega todas as imagens
std.image.draw(id, x, y)        -- desenha se estiver carregada
std.image.measure(src)          -- retorna largura e altura da imagem
std.image.get_id(src)           -- retorna o ID da imagem (carregada ou em cache)
std.image.get_error(src)        -- retorna mensagem de erro, se houver
std.image.is_available(src)     -- true = carregada, false = erro, nil = carregando
std.image.count()               -- total de imagens carregadas
std.image.count_loading()       -- total de imagens ainda carregando

minhas sugestoes sobre o suporte formatos, primariamente sempre PNG, mas JPG e BMP (opcionais mas importantes), outros formatos nao seriam assegurados pela engine.

[RodrigoDornelles]

@joaorovera @bnopacheco

[RodrigoDornelles]

outra ideia que tive, e que para HTML5, poderia existir um preload antes da engine da imagem se baseando nos assets = {} que sao .png, .bmp e .jpeg... so apos isso o jogo/aplicativo e iniciado, e entao n existe queue, ou sao opcionais, com uma API dedicada.

[RodrigoDornelles]

std.image.draw()
std.image.exist()

deveria existir algo como std.image.download() mas nao sei quanto as APIS para verificar se foi um sucesso ou nao, ou se pode ser a propria funcao de download. deve suportar entao primariamente BMP