Lib graphique sur VESA ? - Page 1

Bon, j'ai redessiné mon interface VESA (peeww, pmode, rmode, int 10, pmode, je vous hais) et par dessus j'aurais voulu coller kekchoz de portable. L'idée était de mettre la SDL comme interface, c'est connu et reconnu. Mais la SDL n'est qu'un wrapper vide qui ne fait l'interface qu'avec les libs de l'OS sous jacent. Or là y'en a pas. Enfin pas encore...

Y'a Allegro qui semble encore plus bas niveau et propose directement une lib graphique pas trop dégueux. Sinon Clutter mais il me faut d'abord un front-end OpeGL cohérent... P'tain, l'informatique !

Coud'gueule

Ah oui, et en matière de front-end OpenGL software, z"avez quoi à me conseiller ? Evitez Mesa, SVP... TinyGL semble trop limité, Vincent c'est de l'OPENGL ES, Swift3D c'est pas de l'OpenGL :/

Kochise

Pas pigé, tu cherches quoi exactement ?

Une API cohérente avec librairie graphique pour du développement bas niveau x86

Kochise

Mais plus précisément ?

Concrètement, t'as quoi de codé actuellement, et tu veux arriver à quel niveau (primitives graphiques, toolkit graphique...) ?
Tu cherches du code déjà fait ou juste la description d'une API que tu réimplémenterais toi-même ?

sous linux c'est fbdev. ça peut être adaptable.

Pour mon OS, je suis en train de coder un multiboot graphique (on commence par le début, bien que je m'inspire de XOSL) avec djgpp et nasm. J'ai donc la lib io, mouse, kb et les différents fs (ext2, ext3, fat32 mais pas ntfs) j'aurais aimé une lib graphique prêt à l'emploi pouvant accéder au frame buffer, mais sans avoir encore accès à un kernel...

Kochise

Y'a bien SVGALib mais c'est orienté Linux. Cependant il doit y avoir des choses intéressantes à récupérer dedans.

Sinon, si tout ce qu'il te faut c'est changer de mode graphique et avoir accès au frame buffer pour dessiner 2 ou 3 trucs, c'est facile à coder soi-même, je l'avais fait à une époque (l'inconvénient c'est que si tu manipules la carte graphique à travers VESA, tu ne pourras pas changer le taux de rafraîchissement, il me semble. Mais sur un LCD c'est pas dramatique). Demande si tu as besoin de détails...

C'est dommage pour SDL, parce qu'on peut utiliser OpenGL à travers, mais je ne sais pas s'il manque beaucoup du support sous-jacent à ton niveau.

disons qu'avant de porter SDL, faut qu'il y ait un minimum de code dessous ^^

@0² : Nan mais qui utilise encore du CRT de nos jours ? Tu peux changer la fréquence, y'a un hack pour ça (sans tomber dans la manipulation de registre de carte vidéo, c'est pas FBE non plus, hein) Coder des primitives graphiques ? J'ai passé l'age de jouer à touche pisse-code avec Bresenham

@Folco : Heu, avant d'utiliser SDL, il faut avoir des primitives natives à linker. OpenGL est un set de primitives graphiques bas niveau, que ce soit par un pieline software (Mesa, TinyGL, Vincent) soit par un driver pour carte 3D (Catalyst, Nouveau, ...) Donc là aussi je suis bloqué par l’inexistence d'un framework graphique sur lequel greffer SDL qui servirait d'API interface (et même sous SDL il te faut quand même ouvrir un viewport OpenGL à la main, que tu colles ensuite à la Surface)

@squalyl : ouaip, c'est ça...

Kochise

Pour l'OpenGL logiciel, le backend softpipe de Gallium3D m'a l'air très prometteur:

The softpipe driver is a software implementation of the Gallium3D interface. It will be used as a reference implementation and as a fallback driver when a hardware driver isn't available. The softpipe driver will make extensive use of run-time code generation to efficiently execute vertex, fragment and rasterization operations.

The softpipe driver is basically feature complete and runs most OpenGL programs. There is limited support for SSE and LLVM code generation, but that's still under development.

J'ai lu des premiers résultats du générateur de code LLVM il y a quelques semaines, il paraît que ça éclate totalement tout ce qui était rendering logiciel auparavant. Apparemment, sur un CPU récent, c'est même comparable avec un vieux GPU, du moins pour certaines applications.

First, je veux pas d'un truc "prometteur" mais qui tourne, tu connais la chanson, pour hier. Donc des trucs pas finis qui réclament un toolchain à base de GCC 4.4 et 200 MiB de dépendances, pour écrire un multiboot de 200 KiB, tu repasseras.

Ensuite LLVM pour l'OpenGL, "l'éclate totale" tu dis ? Hmmmm, c'est pas ce que je me suis laissé entendre : http://www.phoronix.com/scan.php?page=article&item=gallium3d_llvmpipe_june10&num=1

Kochise

L'éclate totale par rapport à Mesa (classique). Évidemment que tu ne peux pas t'attendre d'un CPU les performances graphiques d'un GPU haut de gamme! Ce n'est pas sans raison qu'on conçoit des GPUs. Ce serait vraiment le comble si le backend Nouveau n'arrivait pas à battre le backend purement logiciel.

Et au passage, GCC 4.4, c'est vieux, on en est à la 4.5.

Kochise : concrètement c'est assez simple :

- tu vérifies le support de VESA 2 ou supérieur avec la fonction 0x4F00
- tu énumères les modes vidéos avec la fonction 0x4F01 jusqu'à en trouver un qui corresponde aux paramètres que tu attends, et tu récupères l'adresse physique du framebuffer au passage
- tu changes de mode graphique avec la fonction 0x4F02
- si tu as activé la pagination, tu mappes la zone mémoire du framebuffer dans l'espace d'adressage logique

Pouf, t'a plus qu'à dessiner sur l'écran.

Zerosquare (./14) :
Pouf, t'a plus qu'à dessiner sur l'écran.

Jusque là ça va (quoique le faire avec les fonctions SDL idoines, ce serait mieux) mais c'est justement après que ça se corse, j'ai pas de primitives graphiques :/ Bon je vais voir ce que je peux faire en collant SGE à une micro SDL de base...

Merki des conseils en tous les cas

Kochise

Kochise (./15) :
quoique le faire avec les fonctions SDL idoines, ce serait mieux

Kochise (./15) :
j'ai pas de primitives graphiques

La SDL a une extension pour les primitives.

Tu veux parler de SDL_draw ou SDL_gfx ? Moi je comptait partir sur SGE, voire sinon AntiGrain :/

Kochise

Je pensais à SDL_gfx effectivement, je ne connaissais pas SDL_draw.