Ouais, bon, encore une phrase/mythe à la con. A moins de n'utilisez que les interruptions pour faire coucou au Kernel, vous utilisez TOUJOURS au moins une librairie (et encore, faut oublier malloc et consort). Win32, c'est une librairie, et ce n'est même pas l'API Native de Windows, qui est la NT API depuis plus de 20 ans.
>Si ca n'existe pas j'aimerais que quelqu'un m'explique comment la SDL
Parce que ses implémenteurs n'ont pas été bornés et ont lus et compris la documentation des librairies qui permettent de faire efficacement leur boulot, comme DirectX, le GDI (mais pas comme un goret, ça se lock une mémoire vidéo), etc...
Maintenant que les GPU ont plus de puissance de calcul brut que le CPU, si vous voulez afficher rapidement un pixel, c'est via des shaders. Mais pour un pixel, c'est un peu overkill.
Utilisez les bons outils pour les bons usages, et arrêtez de croire que les librairies c'est le mal, putain.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
-vous dîtes que DirectX ou GDI sont des librairies que les implémenteurs de la SDL (ou autre) ont utilisés, mais je n'ai pas compris est-ce qu'elles se basent sur WinApi (ou NT API)?
-Et je reformule la question: est-ce que il ya des fonctions plus rapides que SetPixel() dans la GDI pour afficher un pixel sans utiliser de librairies externes?
Tout dépend ce que tu appelles une lib externe. Généralement, on considère que Win32 est une lib externe, parce qu'elle ne fait pas partie du standard C++.
DirectX et GDI sont des libs de Win32. Mais plus grand monde utilise directement Win32.
Il y a des fonctions plus rapide que setPixel, comme par exemple les fonctions d'accès a un bitmap, les fonctions d'accès au buffer mémoire. Ou encore mieux, toutes les fonctions bas niveau d'accès aux GPU. Regarde DirectX, OpenGL, Vulkan (mais c'est du bas niveau, c'est plus complexe a utiliser que setPixel)
Quand on fait un simple malloc, le compilateur utilise une librairie "externe" qui est la C-Runtime, qui appelle elle-même une ou plusieurs fonctions la librairie Win32 qui est chargé des appels du sous-système "Windows" ( à l'instar des sous-système comme POSIX ou OS/2 de Windows) (c'est généralement dans la Kernel32.dll que cela se passe), qui appellent elles-même une ou plusieurs fonctions dans les librairies de la NTAPI, qui elles appelles les services du Kernel via des interruptions logicielles. Puis le Kernel fait sa tambouille sur un empilement de drivers en stack pour gérer chaque aspect du Kernel, mémoire comprise (la gestion de la mémoire virtuelle, c'est pas totomatique).
Donc, 'pas de librairie "externe"', LOL, on n'est plus à l'époque où on faisait des peek et des poke à une adresse mémoire au petit bonheur la chance d'un AMSTRAD.
On utilise SetPixel quand c'est pertinent pour le cas d'usage, on l'utilise pas quand ce n'est pas pertinent.
Des moyens pour changer la couleur d'un Pixel au pif sur un moniteur, c'est pas le genre de truc qui est un besoin "fondamental", c'est la conséquence d'une action plus complexe.
Et c'est ces actions plus complexes qui ont été optimisées. Si vous vous bornez à vouloir changer un photophore d'une moniteur à matrice LCD random, c'est pas très "optimisé".
Concrètement, un pixel, ça s'affiche pas. C'est juste une triplette de bidule qu'on demande de faire de la lumière.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Le problème de la fonction SetPixel() est que ce qu'elle doit faire est en fait extrêmement complexe, entre l'idée d'allumer un pixel et le fait que le pixel soit visible demande de passer à travers de nombreuses couches de transfert comme l'a indiqué bacelar. Donc même si tu utilisais la plus optimale des fonctions SetPixel() elle resterait du même ordre de grandeur que SetPixel(). Supposons que l'on veuille transférer non pas 1 mais un rectangle de 100 pixels. La traversée des couches est alors similaire n'ajoutant que quelques conversions. Autrement dit, modifier 100 pixels est à peine plus lourd qu'en modifier un seul! Le problème n'est pas dans la fonction elle-même mais dans l'utilisation que tu en fais. N'as-tu pas d'autres pixels à modifier au même moment, ne peux-tu pas grouper ces actions et transmettre le tout en une fois vers l'écran?
Ouais, bon, encore une phrase/mythe à la con. A moins de n'utilisez que les interruptions pour faire coucou au Kernel, vous utilisez TOUJOURS au moins une librairie (et encore, faut oublier malloc et consort). Win32, c'est une librairie, et ce n'est même pas l'API Native de Windows, qui est la NT API depuis plus de 20 ans.
>Si ca n'existe pas j'aimerais que quelqu'un m'explique comment la SDL
Parce que ses implémenteurs n'ont pas été bornés et ont lus et compris la documentation des librairies qui permettent de faire efficacement leur boulot, comme DirectX, le GDI (mais pas comme un goret, ça se lock une mémoire vidéo), etc...
Maintenant que les GPU ont plus de puissance de calcul brut que le CPU, si vous voulez afficher rapidement un pixel, c'est via des shaders. Mais pour un pixel, c'est un peu overkill.
Utilisez les bons outils pour les bons usages, et arrêtez de croire que les librairies c'est le mal, putain.
C’est le mal par définition. Déjà il suffit d’utiliser quelques librairies pour se rendre compte que c’est soit lent soit pourri et ensuite ce sera toujours moins bien que notre propre code qui est optimisé pour ce qu’on veut faire précisément sans prendre en compte tous les cas possibles
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
En recherche d'emploi.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html