Ok, estou usando C ++ com OpenGL e vou criar um carregador para carregar texturas para o meu jogo em 3D. (Mas as texturas são 2D). Quero a opção de transparência, mesmo que decida não usá-la. Preciso de qualidade decente, embora não precise ser de primeira qualidade. O que vocês sugerem para o formato (PNG, TGA, etc.). Além disso, talvez seja algo fácil de criar um carregador (não vou usar um já criado). E também, se você tiver links / dicas para ajudar com o carregador, isso seria apreciado.
Respostas:
Não entendo por que você não gostaria de usar um carregador de prateleira. PNG , por exemplo, é uma boa opção para um formato, mas é complexo escrever um carregador de uso geral (e provavelmente não vale a pena escrever um que carregue apenas o subconjunto específico de formatos PNG de seu interesse).
Dado esse requisito um tanto incomum, o TGA é provavelmente a sua melhor aposta. O TGA 2.0 possui um canal alfa e é relativamente simples comparado ao PNG.
O formato da textura da imagem também é uma opção de desempenho. Eu recomendo que você use texturas compactadas, tanto quanto possível. Em plataformas móveis, pode melhorar bastante o desempenho (40% ou mais), uso de memória e carregamento de tempo.
Considere uma textura 1024 * 1024:
Nos nossos jogos, temos ativos (texturas) em vários formatos:
Por fim, usamos o formato bruto para compatibilidade, mas isso é para elementos de compatibilidade ou GUI
As texturas ETC1 não possuem canal alfa, portanto, usamos um sombreador especial com duas texturas (textura rgb e textura alfa). Formato compactado é muito fácil de carregar (100 ou 200 loc).
Na área de trabalho, o DXTC (S3TC) está presente em muitos cartões. Então, você deve usá-lo.
Texturas compactadas
Pró
Vigarista
Texturas são coleções de uma ou mais imagens. Isso significa que uma textura pode ser representada por um TGA ou PNG, mas nenhum formato é capaz de representar todos os recursos possíveis das texturas. Por quê?
Porque cada um só pode conter uma única imagem. Não há mipmaps. Não há texturas 3D possíveis. Sem texturas de matriz. Nenhum cubemaps. Cada um desses arquivos é apenas uma única imagem 2D. Eles podem fazer parte de uma textura, mas, a menos que você não esteja usando o mipmapping (e eu recomendo fortemente não usar mipmaps, a menos que você tenha necessidades específicas), um único arquivo de imagem nesses formatos não poderá ser uma textura.
Eles são bons formatos de imagem, mas produzem formatos de textura ruins .
O DDS é o líder dos formatos de textura, porque realmente suporta as necessidades de texturas. Ele suporta mipmaps e cubemaps. Ele suporta texturas 3D. O DDSv10 suporta texturas de matriz. Você pode empacotar uma única textura dentro de um DDS de uma maneira que não poderia com PNG ou TGA.
O DDS suporta dados de textura não compactados e compactados. Desde que o formato de textura compactado seja um dos formatos de textura DXT / BC.
O PKM é útil para empacotar imagens compactadas pelo ETC1, mas, como no PNG, não suporta recursos de textura reais.
Os arquivos PVR parecem ser o equivalente móvel do DDS (embora, por que eles não pudessem usar apenas o DDS, eu não sei). Eles suportam várias técnicas de compactação, mas não possuem recursos avançados do DDSv10, como texturas de matriz, além de suporte de textura 3D.
Portanto, o DDS vence em termos de suporte abrangente à textura.
O Khronos Group recomenda o formato de arquivo KTX para armazenar texturas para aplicativos OpenGL e OpenGL ES. Você pode usar a libktx para trabalhar com este formato.
Recursos:
Parece que o DDS (DirectDraw Surface) é a escolha mais popular para texturas no momento. É tem diferentes formatos de pixel, transparência e compactação. É suportado no OpenGL através da extensão GL_ARB_texture_compression.
Por exemplo, há um carregador OpenGL aqui .
Há várias considerações aqui:
O TGA é uma boa escolha, porque nos casos descompactados de 24 e 32 bits, você pode ler os dados em um único tamanho / píxeis e enviar o resultado diretamente através do glTexImage2D sem processamento adicional. É uma péssima escolha, pois pode ter o maior tamanho de arquivo e, se a E / S do disco for um gargalo, suas leituras serão lentas.
PNG é uma boa opção, pois preserva a qualidade das imagens com um tamanho de arquivo razoavelmente pequeno. É uma má escolha porque os PNGs podem demorar a descomprimir - se esse for o seu gargalo -, você sabe.
O JPG é uma boa opção, pois geralmente possui o menor tamanho de arquivo e sai do disco muito rápido (duplamente bom se você precisar enviar o arquivo pela rede). É uma má escolha devido às etapas intermediárias de descompressão de software e perda de qualidade (embora você possa ajustar as configurações de qualidade para atenuar isso). Nenhum canal alfa também.
DDS (ou outros formatos compactados) são boas opções devido ao tamanho menor do arquivo e à capacidade de incluir uma cadeia de mipmap pré-construída. Se for um formato que é nativamente suportado em hardware (e o DDS é suportado nativamente na maioria dos hardwares para PC de consumo - também já existe há muito tempo), você obtém o mesmo benefício que o TGA - um pouco, um cutucão no cabeçalho para descobrir algumas propriedades da imagem e envie os dados diretamente, sem etapas intermediárias. Texturas compactadas também tornarão o seu programa mais rápido e usarão menos RAM de vídeo. São más escolhas porque usam compactação com perdas (que às vezes pode ser realmente perceptível) e podem não ser suportadas em todo o hardware.
Se fosse eu, eu criaria suporte para todos esses 4 formatos (TGA e DDS são bastante triviais para escrever carregadores, com JPG e PNG eu usaria uma biblioteca de imagens) para que os criadores de conteúdo possam escolher o formato mais adequado em por textura.
E, é claro, você sempre pode usar o antigo BMP de 32 bits, que é realmente fácil de carregar (especialmente se o tamanho for uma potência de 2 (na verdade, um múltiplo de 8 bytes IIRC)).
Caso contrário, parece estranho que você queira apenas um formato, o jpg é muito legal para texturas de alta resolução no mundo real (o jpeg se maravilha com o espaço em disco e os tempos de carregamento (para baixo)), png para a transparência e o ocasional BMP de 32 bits para as texturas de controle (fácil de criar a partir de um script ou de uma ferramenta 'rápida e suja').