1

Bonsoir,
Je suis actuellement en train de porter ma librarire PSP pour PC (avec OpenGL), mais je rencontre un problème: sur PSP on peut utiliser des textures indexées en 8 ou 4 bits, mais sur PC c'est plus vraiment supporté. sad
Est-ce que quelqu'un pourrait m'indiquer comment je pourrais remplacer ça? (convertir la texture en RGBA à la main n'est pas une bonne solution car c'est très lent).
Merci d'avance smile
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

2

Edited_790

3

Oui, c'est lent, parce que je le fais au niveau de la PSP, et c'est pas comme en OpenGL où tu génères tes textures et après tu n'y touches plus.
Sur PSP déjà t'accèdes à tes textures comme tu veux, qu'elles soient en VRAM ou pas, et après tu dis juste de sélectionner une texture (dont tu donnes la taille, l'adresse et le format) et de dessiner.
Donc c'est à ce moment là qu'il faut la convertir, et ça arrivera beaucoup de fois par frame, parce qu'on sait pas si elle a été modifiée depuis contrairement à un glBindTexture... sad
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

4

J'allais poster un truc dans ton autre topic, mais je l'ai effacé par mégarde...
Ce que tu dois faire c'est sallouer au maximum pour chaque texture (ce n'est pas possible en considérant les diverses tailles de mémoire vidéo qui existent, donc tu devras gérer cela dynamiquement) un espace en mémoire vidéo que tu ne mettra a jour que quand celà sera nécéssaire...
Je vois dans ta documentation void oslUncacheImage(OSL_IMAGE *img) ça me parrait excellent comme moyen de déterminer quelle texture mettre a jour... Il suffit que tu mettes un flag "update" dans ta table de correspondance mémoire système <=> mémoire vidéo pour indiquer au processus de rendu de réactualiser l'image en mémoire vidéo, c'est nickel.
Pour ce qui concerne la conversion, il suffit d'optimiser ta routine. Avec des tables 8 => 32 et 4 => 32 pour la conversion ça peut être très rapide... Tu peux posser l'optimisation a bout, en prenant des blocs de 16 bits d'image source (aussi bien en 8 qu'en 4 bits), et en ayant des tables qui te donnent direct le bloc de 64 ou 128 bits correspondant. (Du coup copie presque 2 fois plus rapide en 4 bits) A voir également si tu es obligé d'utiliser des textures RGBA, car en 16 bits tu peux gagner en taille et en vitesse pour la conversion.
la conersion dans le sens inverse, elle, ne se fait a l'aide de tables que si tu as des textures 16 bits maximum, sinon bah faut se débrouiller.
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

5

Oui merci je vois le truc smile
Bon le problème c'est que transférer les images c'est ultra lent avec ma Radeon 9800pro, c'est hallucinant (glTexImage2D et cie transfèrent à un taux du style 5-10 Mo/seconde), donc c'est pas vraiment possible sad
J'ai cherché mais j'ai pas trouvé de solution à ça, et c'est logique, normalement on n'est pas censé faire ça, on génère une fois les textures et puis go...
Y'aurait moyen de transférer plus rapidement les images? Avec un blit GDI depuis une DIB, j'ai déjà plus de 500 Mo/sec, mais bon GDI pour la 3D, c'est pas le top cheeky
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

6

Après avoir fait quelques recherches sur internet, je n'ai pas su trouver mieux que glTexImage2D... sad Je sais qu'avec DirectX (aussi bien Direct3D que DirectDraw) ce dont je te parle est possible, mais mes connaissances au niveau de OpenGL sont bien trop limitées pour que je puisse t'aider de ce côté là sorry
Seul chose intéressante que j'ai trouvée: les pbuffer qui semblent être similaires aux surfaces en DirectX, mais je n'ai pas réussi a savoir si tu pouvais toi même modifier les données contenues a l'intérieur... :/
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

7

Alors :
1) OpenGL supporte les textures indexées via l'extension EXT_paletted_texture, disponible sur une large majorité de gpu.

2) si tu veux rendre de la 2d en opengl, tu as deux possibilités :
=> glDrawPixels
=> faire une texture et l'appliquer à un rectangle couvrant toute ta fenêtre

En général, la deuxième solution est plus efficace, même si certaines cartes font exception.

GC> un pbuffer est un écran virtuel et un contexte opengl à part entière. Tu ne peux pas accéder à son contenu directement vu qu'il est logé en mémoire vidéo. Les techniques sont donc les mêmes que pour l'écran : glDrawPixels et rendu vers texture. Les deux contextes liés à ces objets peuvent partager leurs objets vidéo (textures, listes, ...).


Il faudrait regarder aussi, il y a peut-être moyen de faire la conversion indexé => rgba dans un pixel shader. [edit: non en fait toutes les cartes supportant les pixel shaders supportent le EXT_paletted_texture qui existe depuis bien avant].

8

Hm je vois, mais à ce que j'ai lu EXT_paletted_texture est de moins en moins supporté... sad
OSLib ne fait pas de la 2D simple comme DrawPixels wink
Merci. Finalement je vais convertir moi même la texture avant de l'afficher.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

9

Normalement, de toutes façons, l'utilisation de glDrawPixels et le rendu vers texture te permettent de bénéficier de toute l'accélération matérielle.
Fais gaffe quand même : sous windows, le opengl livré par microsoft est un opengl logiciel. Regarde bien quelle version de OpenGL tu as, et installe la version du fabricant de ta carte si besoin.

10

!UP!

Brunni> Je relisais le topic, suite à la lecture de quelques articles par hasard sur le net.
Bon le problème c'est que transférer les images c'est ultra lent avec ma Radeon 9800pro, c'est hallucinant (glTexImage2D et cie transfèrent à un taux du style 5-10 Mo/seconde)

En fait, en plus des problèmes déjà évoqués, le format de ta texture est très important. Si le format n'est pas accepté nativement par la carte, le driver est obligé de mofidier la texture à la volée, ce qui ralentit énormément.
Pire, si ton format ne correspond pas à l'alignement attendu, il est obligé de padder les pixels >_<

A titre de comparaison, avec un format de texture et de buffers d'affichages bien choisis, tu peux atteindre 1700Mo/s sur une GeForce 6800 Ultra avec la fonction glTexImage2D.

11

1'700 Mo/sec??? eek
Hé ben... j'ai testé mon code sur une nVidia et c'est effectivement infiniment plus rapide, mais pas à ce point... et le meilleur de tous c'est quand même... l'Intel GMA grin*
Je ne sais pas comment être sûr que j'ai bien le même pixelformat que le buffer... je demande un buffer 32 bits, je suis en mode 32 bits alors j'imagine que GL_RGBA + GL_UNSIGNED_BYTE c'est ce qu'il faut pour qu'il n'y ait pas de conversion non? mourn
Et pour l'alignement c'est bien de savoir ça merci smile Mais comment je peux être sûr que c'est correct? hum
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

12

Faut aller voir sur le site des constructeurs des cartes.
Par exemple, nVidia indique que selon la représentation des couleurs, le RGBA peut imposer au driver d'inverser les couleurs avant d'envoyer à la carte, et précise que la carte prend dans ce cas nativement du BGRA.

Ce document est intéressant => Fast Texture Transfers (download.nvidia.com)