Afficher une image sur l'écran sans dépendre du driver de la carte graphique ni de l'OS.

Salut.

Je cherche une librairie en c++ qui est capable d'afficher une image directement sur l'écran (et donc, sans dépendre du driver de la carte graphique, ni de XServeur (de l'implémentation de l'OS donc.) pour le fenêtrage.

Je voudrais également récupérer les événements souris.

Est ce possible de faire cela ?

Merci.

J'ai vu qu'il existe une librairie (fbi) qui est capable d'afficher des images dans la console mais y a t'il moyen de gérer les événements clavier et souris dans la console ? (Ainsi que le redimentionnement de la console ?)

Merci.

je croyais que tu quittait développez.com à cause de l'humour de certains développeur.

(Pas encore, mais a force de lui faire remarquer qu'il se ridiculise, cela finira par arriver. Peut être)

Tu penses que la console n'est pas OS dépendant ? C'est mignon...

Pas grand chose bas niveau est OS indépendant. Quelque chose de portable, c'est quelque chose qui va faire le boulot d'abstraction de l'OS à ta place. Par exemple OpenGL fournit une API commune quelques soit l'OS, la partie OS spécifique est dans les drivers. Mais comme tu n'arrives pas à utiliser OpenGL correctement, il te faut autre chose. J'ai bien peur qu'une grande partie des libs graphiques utilisent l'accélération matérielle à moment donné ou un autre, histoire d'être performant. Si tu veux être totalement indépendant du GPU, il te reste plus qu'a prendre une lib sans accélération matérielle. Voir donc du côté des archives du web, par exemple Anti-Grain Geometry.

C'est pas très performant, mais comme de toutes façon tu pars sur des techniques peu performantes, cela ne changera pas grand chose (Et puis comme tu penses être assez bon pour créer un moteur de jeux en ray casting, cela devrait pas poser de problèmes pour les performances)

Je pense que tu ne saisis pas très bien comment fonctionne un ordinateur, hop petit cours de rattrapage:

Un ordinateur c'est quoi? De base: Une carte mère, un processeur, de la ram, et un disque dur (la carte graphique est en option, on en a pas forcément besoin).

Ensuite qu'est-ce qu'un système d'exploitation?
C'est un système qui va permettre l’interaction entre l'utilisateur et la machine. Suivant l'architecture du processeur, on utilise différent langage machine (les 0 et les 1). Ce langage machine est compréhensible par le processeur mais pas par les humains. On a donc inventé le compilo, qui va traduire le langage assembleur (identique pour toute les machines) en langage binaire (spécifique à un processeur). Mais comme le langage assembleur n'est pas très compréhensible finalement, bah on a créer le C/C++, qui est traduit en assembleur puis en langage machine.

(J'ai simplifier au maximum pour que tu puisses comprendre).

Sans système d'exploitation, pas de compilo, donc pas de programme. C'est un peu la base de la programmation. Donc faire un programme qui ne soit pas dépendant du système d'exploitation ni de rien, bah c'est pas possible. A la limite, avec java tu pourras faire un programme qui fonctionne partout, car lancer dans une machine virtuelle, qui va s'occuper de traduire au processeur, mais ce n'est pas ce que tu veux faire.

En gros tu as besoin d'une lib qui:
_ affiche des pixels
_ récupère les événements clavier et souris
_ portable sur windows et linux

Donc tu prends SFML ou SDL. Il y a pas besoin de réfléchir plus que ça.
Ensuite si tu n'arrives pas à utiliser ces lib là correctement, bah change de branche, c'est que tu n'as pas les compétences pour y arriver.

moi j'ai bien une idée pour répondre au cahier des charges : une feuille de papier et un peu de scotch, directement sur l'écran :roll: :weird:

Citation:

---

langage assembleur (identique pour toute les machines)

---

il me semblait qu'il dépendant du processeur ou quelque chose comme ça ? ou bien il s'agit que de certaines instructions spécifiques ?

Le langage assembleur est identique pour toute les machine, c'est un langage de plus haut niveau que le langage machine, il est donc pas lié au processeur, mais s'y rapproche énormément par rapport au C.

Si j'ai bien compris mes cours, chaque instruction en assembleur correspond à une instruction en langage machine. Et tout les processeurs utilisent les même instructions (modification de registre, déplacement de registre etc ....) mais utilisent un code d'instruction différent, d'où la nécessité de passé par un compilo pour le traduire en langage machine ;).

Attention tout de même, l'assembly est une traduction un pour un du jeu d'instruction binaire.
Chaque langage d'assembly est différent.

L'assembleur ne peut pas être identique... normalement. Sauf si on ne parle pas de la même chose.
(confère les désassembleurs)

Citation:

---

Envoyé par leternel

Attention tout de même, l'assembly est une traduction un pour un du jeu d'instruction binaire.
Chaque langage d'assembly est différent.

L'assembleur ne peut pas être identique... normalement. Sauf si on ne parle pas de la même chose.
(confère les désassembleurs)

---

Ah? Je croyais qu'un hello word en C traduit en assembleur était pareil sous windows et linux? Mais je peux me tromper, peut-etre qu'il est le même pour un processeur sous deux OS différent mais différent pour le même OS sous deux processeur différent :). Je vais rechercher un peu :).

J'étais persuader que la différence entre les différent langage machine était uniquement le code d'instruction et non pas les instructions elle-même.

Edit après foetus:
Effectivement, je raconte des bétise, le langage assembleur est propre à l'architecture du processeur. Autant pour moi :).

Citation:

---

Ainsi, le langage assembleur, représentation exacte du langage machine, est spécifique à chaque architecture de processeur.

---

source

Citation:

---

Envoyé par skeud

Le langage assembleur est identique pour toute les machine, c'est un langage de plus haut niveau que le langage machine, il est donc pas lié au processeur, mais s'y rapproche énormément par rapport au C.

Si j'ai bien compris mes cours, chaque instruction en assembleur correspond à une instruction en langage machine. Et tout les processeurs utilisent les même instructions (modification de registre, déplacement de registre etc ....) mais utilisent un code d'instruction différent, d'où la nécessité de passé par un compilo pour le traduire en langage machine ;).

---

Pas d'accord :mrgreen:

En assembleur il y a les mnémoniques (ADD, MOV, ...) qui sont juste des alias d'instructions (avec paramètres) en binaire.

Mais chaque chaque plateforme (x86, ARM, PowerPC, ...) a son propre jeu de mnémoniques, et pour une plateforme donnée, chaque CPU peut avoir ses propres mnémoniques (AMD et son 64 bits, les instructions MMX+ SSE....)


Sinon, je pensais justement à passer par les interruptions: j'ai le souvenir du Mode X :oops: :vieux:

Citation:

---

Envoyé par skeud

Ah? Je croyais qu'un hello word en C traduit en assembleur était pareil sous windows et linux? Mais je peux me tromper, peut-etre qu'il est le même pour un processeur sous deux OS différent mais différent pour le même OS sous deux processeur différent :). Je vais rechercher un peu :).

---

Je ne vois pas de raison pour qu'il soit réellement différent en fonction des OS.
Le langage d'assemblage (assembly) est destiné au processeur lui-même.

Après, des assembleurs (les programmes qui assemblent) différents peuvent utiliser des mnémoniques différentes, mais ca serait franchement tordu.
On peut imaginer qu'un assembleur utiliserait une notation add(r1, r2, r3), tandis qu'un autre préfererai R1 R2 R3 add.

Citation:

---

Envoyé par leternel

Je ne vois pas de raison pour qu'il soit réellement différent en fonction des OS.

---

À mon avis, un code qui ne fait que du calcul doit être à peu près indépendant. Mais un code qui fait des entrées/sorties, comme un Hello World! doit fortement dépendre de l'OS...

C'est exact, je n'avais pas pensé à ce problème-là.

Même si ce n'est pas le langage lui-même qui change.

L'assembleur change entre les OS, dès qu'il y a un appel de fonction, car les ABI changent.

Moi, lorsque j'ai lu la question première de Lolilolight, j'ai pensé au framebuffer (fbdev) et un accès assez brut. Mais bon, cela repose toujours sur Linux, mais c'est ce qu'il y a de plus bas niveau. Enfin non, le plus bas niveau, c'est de faire un bootloader soit même et de faire de l'ASM pur, sans rien de plus. Par contre, c'est limité à 320x240x8, je crois. Donc ça craint.

On va revenir au problème du PO.

Une bibliothèque qui n'utilise pas les fonctionnalités d'un OS, ça n'existe, à ma connaissance, que dans les environnements pour développement de software embarqué, les drivers ou de construction de firmware/bios.

Aucun de ces systèmes/environnement n'est trivial. C'est largement plus complexe que maitriser les problèmes de portabilité d'une lib sur les OS mainstream (Windows, Linux, OSX).

Resimentionner une console ? Une console d'OS sans OS ? ou l'affichage en mode caractère pilotable par le BIOS ??

Je ne pense pas que les cartes graphiques sur architecture Intel supportent encore l'affichage en mode caractère, à moins d'avoir 20 ans d'âge (et les cartes graphiques, c'est pas comme le wisky).

fbi ? pour FrameBuffer ? Ceci est une technologie éminemment lié à Linux et à ces drivers. On n'attaque pas le hardware en direct, même si l'API peut le laisser croire.

On va arrêter la mise en boite, c'est quoi le véritable et initial besoin, Lolilolight ?

P.S.: Les mecs, faire de la mise en boite en considérant que l'assembleur est indépendant de l'architecture, ou d'un éventuel OS, ou même du programme de génération du binaire (MASM et "Assembleur GCC" qui inversent quasiment leur syntaxe l'un de l'autre ), c'est largement se décrédibiliser.

(@bacelar: tu as loupe quelques discussions avec Lolilolight. On est censé avoir affaire avec un gars qui a 10 ans d’expérience, qui a "une maîtrise totale des mathématiques, de la physique, et de la programmation" (je cite), mais qui a abandonne OpenGL et le multithreading parce que c'est bugé (les drivers et l'OS, pas son code bien sur) et c'est plus performant de faire de la 3D en raycasting sur CPU en mono-core. La "mise en boite" arrive très vite dans ces conditions...)