Le topic de la programmation, string, chaînes, cuir et compagnie

[vectra]

C'est violent l'API Mantle quand même.

La vache.
J'ai l'impression d'être un gros bébé avec mes applis Qt ou OpenCV, genre qu'on prend par la main de A à Z...

En tous cas j'ai rien compris, ni même le langage dans lequel que c'était écrit pour qu'on lise.

[rOut]

La vache.
J'ai l'impression d'être un gros bébé avec mes applis Qt ou OpenCV, genre qu'on prend par la main de A à Z...

En tous cas j'ai rien compris, ni même le langage dans lequel que c'était écrit pour qu'on lise.

T'as pas suivi le topic toi, Tomaka == Rust.

[vectra]

Mantle en Rust?

[rOut]

Ben il s'est fait des bindings et pis ouala.

Par contre, je viens de jeter un œil à la spec, y'a quand même 435 pages à se bouffer...

---------- Post added at 01h18 ---------- Previous post was at 00h41 ----------

https://github.com/Microsoft/msbuild/pull/1

Olol

[oks2024]

C'est certain qu'il vaut peut être mieux commencer par DirectX11, c'est bien plus simple à appréhender. En tout cas c'est bien qu'ils aient rendu la doc dispo, dommage qu'ils donnent pas le SDK avec, ça aurait été sympa en attendant DirectX12 et Vulkan.

[Tomaka17]

Mantle en Rust?

Il n'y a aucun SDK ni même de header file de disponible de toute façon, donc tous les langages sont à égalité.

[rOut]

C'est certain qu'il vaut peut être mieux commencer par DirectX11, c'est bien plus simple à appréhender. En tout cas c'est bien qu'ils aient rendu la doc dispo, dommage qu'ils donnent pas le SDK avec, ça aurait été sympa en attendant DirectX12 et Vulkan.

Non mais surtout c'était censé être plus simple, plus bas niveau et plus élémentaire qu'OpenGL par exemple. La partie utile de la spec OpenGL fait genre 550 pages (pas la même mise en page, certes).

[Kalimmba]

Salut les canards,

Débutant en prog, je me suis lancé dans le C++ parce que bon voila faut bien commencer quelque part
Bref, c'etait le pourquoi du comment.
La situation est la suivante : j'ai un main.cpp et un fonction.cpp
Le fonction.cpp se termine avec un return value qui est un int
Ma question : Comment puis je récupérer le value en question dans mon main.cpp ?
Merci par avance
Suite à la remarque de Gronours j'ai la question suivante : peut on passer en argument le résultat de ma fonction ? Je suis pas sûr d'être super clair là...

[nephyl]

Salut les canards,

Débutant en prog, je me suis lancé dans le C++ parce que bon voila faut bien commencer quelque part
Bref, c'etait le pourquoi du comment.
La situation est la suivante : j'ai un main.cpp et un fonction.cpp
Le fonction.cpp se termine avec un return value qui est un int
Ma question : Comment puis je récupérer le value en question dans mon main.cpp ?
Merci par avance
Suite à la remarque de Gronours j'ai la question suivante : peut on passer en argument le résultat de ma fonction ? Je suis pas sûr d'être super clair là...

je te conseille.

http://openclassrooms.com/courses/pr...e-en-fonctions

Les fonctions, c'est un concept de base à bien comprendre.

[Kalimmba]

Merci nephyl
C'est justement de là que j'ai commencé :D. Et les fonctions je connais deja (un peu) via les scripting vbs
Mais j'aime bien corsé un peu les trucs du coup j'en suis là
http://forum.canardpc.com/threads/96...58#post8727858
J'ai 2 fichiers, un main et un fonction
Le main fait appel à la fonction qui va sortir un résultat
Je veux récupérer ce résultat dans le main
Le code en lui meme n'est pas interessant, je cherche à comprendre la logique, la structure du truc disons. Ce n'est pas le probleme d'ailleurs. Si je mets ma fonction dans le main c'est bon, j'ai mon resultat qui s'affiche.
Mais bon voici le code
Main.cpp

f_Random(nDifficulte);
cout<<nbHasard<<endl;

f_Random.cpp

nLimit = nDifficulte + 3;
srand(time(0));
nbHasard = rand()%nLimit;
return nbHasard;

Pas un truc de ouf hein, mais ça m'affiche -2 alors que si je mets un cout dans la fonction, j'ai bien un nb aleatoire entre 0 et la limite

J'espere avoir été plus clair.

Ah et oui j'ai bien un header qui contient le prototype de la fonction

[Tramb]

Poste tout ton code stp, chaque caractère est important

[Kalimmba]

Bon beh voila

main.cpp

#include <iostream>
#include <stdlib.h>
#include <time.h>
#include <vector>
#include "random.h"
using namespace std;
//f_Random(nDifficulte);
int main()
{

cout<<"Choix de la difficulté "<<endl;cout<<"1 - Facile"<<endl;cout<<"2 - Moyen"<<endl;cout<<"3 - Difficile"<<endl;cout<<"4 - IMPOSSIBLE !!"<<endl;
int nChoix, nDifficulte, nLimit, nbHasard, nResult;
cin>>nChoix;
nDifficulte = nChoix;
cout<<"difficulte = "<<nChoix<<endl;



switch(nChoix)
    {

        case 1:
            cout<<"Easy"<<endl;
            f_Random(nDifficulte);
            cout<<nDifficulte<<endl;
            cout<<nbHasard<<endl;
            break;
    }
}

f_Random.cpp

#include <iostream>
#include <time.h>
#include <windows.h>
#include "random.h"
using namespace std;
int f_Random (int nDifficulte)

{
    int nLimit, nbHasard;
    cout<<"DEBUT fonction RANDOM"<<'\n'<<"+++++++++++++++++++++"<<'\n';
    nLimit = nDifficulte + 3;
    srand(time(0)); // Initialisation des nombres aleatoires
    nbHasard = rand()%nLimit; // quantité de nombre
    cout<<"nb aleatoire est compris entre 0 et "<<nLimit<<endl;
    cout<<"nb aleatoire dans la fonction est "<< nbHasard<<endl;
    cout<<nDifficulte<<endl;
    cout<<"+++++++++++++++++++++"<<endl<<"FIN fonction RANDOM"<<endl;
    return nbHasard;

}

f_random.h

#ifndef RANDOM_H_INCLUDED
#define RANDOM_H_INCLUDED

int f_Random (int nDifficulte);

#endif // RANDOM_H_INCLUDED

[vectra]

Non mais surtout c'était censé être plus simple, plus bas niveau et plus élémentaire qu'OpenGL par exemple.

Mes souvenirs en OpenGL sont quand-même de quelque chose de nettement plus concis, en effet.

[Tramb]

Bah ton problème c'est que le nbHasard dans la fonction main n'a rien à voir avec celui dans f_Random

[Tomaka17]

Mes souvenirs en OpenGL sont quand-même de quelque chose de nettement plus concis, en effet.

Mantle/Vulkan et OpenGL, c'est un peu comme l'assembleur et le Java (ou un quelconque autre langage).
Comme OpenGL a des problèmes niveau performances, bugs et complexité, ils ont décidé de sortir Mantle/Vulkan. Forcément un hello world est plus long et plus compliqué, mais on repart sur des bases plus saines et on laisse la possibilité aux gens de construire par dessus ça.

---------- Post added at 11h30 ---------- Previous post was at 11h28 ----------

Et je suis en train de me gratter la tête pour trouver un moyen de rendre l'API Mantle/Vulkan safe en compile-time.
Parce que si ton moteur fait les mêmes vérifications au moment du runtime que ce que faisait OpenGL, ça limite l'intérêt niveau performances.

[war-p]

Hmm, en gros tu reviens 10 ans arrière... Qui se souvient des fragment shader et autres joyeuseté...

[Kalimmba]

Ok solution trouvée
merci qd memem

[Tomaka17]

Hmm, en gros tu reviens 10 ans arrière... Qui se souvient des fragment shader et autres joyeuseté...

T'es pas censé programmer directement un jeu ou une application avec Mantle/Vulkan, tout comme t'es pas censé programmer directement en assembleur.
Mais c'est le fait de laisser la possibilité aux barbus de manipuler directement le hardware qui fait que les couches plus faciles à utiliser sont rapides.

[vectra]

Je comprends un peu mieux en effet.

J'ai jamais, jamais touché ni les shaders (sauf par CUDA mais bon, c'est totalement masqué et détourné), ni la programmation DirectX ni rien d'autre, ce qui explique mon désarroi.

[war-p]

T'es pas censé programmer directement un jeu ou une application avec Mantle/Vulkan, tout comme t'es pas censé programmer directement en assembleur.
Mais c'est le fait de laisser la possibilité aux barbus de manipuler directement le hardware qui fait que les couches plus faciles à utiliser sont rapides.

Ouais, mais je veux dire que si on a inventé des couches d'abstractions de plus en plus perfectionnées depuis 10ans, c'est pas pour repartir de zéro, et en général, quoi que t'en dise, opengl et directx, ça a été pensé assez intelligemment. Après, si réinventer la roue, c'est ton truc, pourquoi pas hein, mais bon. Enfin, bon courage à toi quand même, si t'arrives à avoir un truc qui marche correctement, ça peut être sympa!

[Lazyjoe]

Le GPGPU manuel avec CG

Encoder les valeurs dans les pixels.

Débugguer les valeurs avec des filtres de couleurs.

Ne pas réussir son projet de TER parceque la carte ATI à la maison n'acceptait pas de shaders avec suffisamment d'instructions.

[Tramb]

Ouais, mais je veux dire que si on a inventé des couches d'abstractions de plus en plus perfectionnées depuis 10ans, c'est pas pour repartir de zéro, et en général, quoi que t'en dise, opengl et directx, ça a été pensé assez intelligemment.

Assez intelligemment, oui, mais il y a plein de décisions très critiquables. Y a plein de trucs que tu ne peux pas faire en OpenGL (que je ne détaillerai pas) parce que l'abstraction ajoute un overhead de perf qui te fait sortir de l'enveloppe.
Et c'est hyper important, utile, et libérateur de pouvoir aller bosser sous le capot.

Et surtout, ça n'empêche personne de continuer à utiliser des abstractions de plus haut niveau !

[Tomaka17]

Ouais, mais je veux dire que si on a inventé des couches d'abstractions de plus en plus perfectionnées depuis 10ans, c'est pas pour repartir de zéro, et en général, quoi que t'en dise, opengl et directx, ça a été pensé assez intelligemment. Après, si réinventer la roue, c'est ton truc, pourquoi pas hein, mais bon. Enfin, bon courage à toi quand même, si t'arrives à avoir un truc qui marche correctement, ça peut être sympa!

Absolument tous les changements apportés à OpenGL ces dernières années vont dans le sens de Vulkan : l'utilisation de buffers pour tes blocs d'uniforms afin d'écrire directement les valeurs de tes uniforms en mémoire plutôt que d'appeler des fonctions OpenGL, les textures bindless qui te permettent d'obtenir des pointeurs bruts vers les textures en mémoire afin de les manipuler plus facilement, les buffers mappés de façon persistante qui nécessitent que tu gères manuellement les synchronizations à l'aide de barrière, le storage immutable de buffers, le dessin indirect pour stocker les commandes de dessin dans la mémoire du GPU plutôt que d'appeler des fonctions OpenGL, etc.

Plutôt que de continuer dans cette direction et de bidouiller pour supporter à la fois le vieux et le nouveau, ils ont juste décidé de faire table rase.

---------- Post added at 13h09 ---------- Previous post was at 13h05 ----------

Il est d'ailleurs probablement beaucoup plus facile pour Unity ou l'Unreal Engine de switch de OpenGL 4.5 vers Vulkan que de switch de OpenGL 3 à OpenGL 4.5.

[vectra]

Le GPGPU manuel avec CG

Encoder les valeurs dans les pixels.

Débugguer les valeurs avec des filtres de couleurs.

Ne pas réussir son projet de TER parceque la carte ATI à la maison n'acceptait pas de shaders avec suffisamment d'instructions.

Han t'as connu CG d'avant CUDA?
J'ai vu un pote faire dans les années 2004-2005 je crois, ça faisait un peu peur.

[Tramb]

Le GPGPU manuel avec CG

Encoder les valeurs dans les pixels.

Débugguer les valeurs avec des filtres de couleurs.

Ne pas réussir son projet de TER parceque la carte ATI à la maison n'acceptait pas de shaders avec suffisamment d'instructions.

Check, check, check, pas check

[Lazyjoe]

Un pauvre calcul de croisement entre un triangle et un rayon qui ne passait pas pour faire un petit raytraceur.

Mais bon j'avais déjà réussi à faire le parcours de la grille englobante, c'est mieux que rien.

---------- Post added at 14h02 ---------- Previous post was at 14h01 ----------

Han t'as connu CG d'avant CUDA?
J'ai vu un pote faire dans les années 2004-2005 je crois, ça faisait un peu peur.

"Merde j'ai des pixels rouges par endroit, ça veut dire que le calcul est pas bon"

Les erreur d'arrondi sur le calcul d'indices de tableau ("des entiers dans un gpu ? mais pour quoi faire ?").

[oks2024]

Non mais surtout c'était censé être plus simple, plus bas niveau et plus élémentaire qu'OpenGL par exemple. La partie utile de la spec OpenGL fait genre 550 pages (pas la même mise en page, certes).

Pas plus simple, non, mais en effet plus bas niveau. Par exemple tout ce qui est synchronisation entre ressources, qui est normalement géré automatiquement par DirectX/OpenGL doit maintenant être défini explicitement. En gros si ta texture lors d'un draw call est utilisé en écriture et qu'au suivant elle est utilisé en input, il va falloir mettre des genre de fence pour bien être sûr que le GPU a bien fini son travail avant de la réutiliser.
L'avantage c'est que si on est certain de pouvoir se passer de synchronisation on a pas à payer l'overhead.

T'es pas censé programmer directement un jeu ou une application avec Mantle/Vulkan

Pourquoi ? L'API PS4 est assez similaire, et les jeux sont codés entièrement avec, je pense que les jeux vont progressivement switcher vers du DirectX12 (parce que ça sera aussi supporté par la xbox).
Pour ce qui est de Vulkan j'avoue que j'ai un peu de doutes, mais au final vu que les API seront similaire, le portage DX12->Vulkan sera sans doutes beaucoup plus simple que le portage DX11->OpenGL.

Ouais, mais je veux dire que si on a inventé des couches d'abstractions de plus en plus perfectionnées depuis 10ans, c'est pas pour repartir de zéro, et en général, quoi que t'en dise, opengl et directx, ça a été pensé assez intelligemment.

Oui, ça a été bien pensé, mais pas dans un sens qui plait à tout le monde, surtout dans le monde du jeu vidéo.
Disons que l'objectif premier était de rendre le GPU plus simple à utiliser, mais forcément en cachant plein de fonctionnalités, de possibilités, et forcément de performances parce qu'on ne peut pas lui dire explicitement ce qu'on veut.

Et la majorité des développeurs (AAA, ou du moins quand les perfs importent) ne veulent pas échanger des performances contre de la simplicité (du moins à ce point), et c'est ces gens là qui ont poussé pour avoir des APIs console-like sur PC. Après OpenGL et DirectX11 vont rester vivant (enfin pour DirectX11 il a pas bougé depuis un bail), et ensuite les développeurs pourront chacun faire le choix entre "simplicité" et perfs (caricaturale, mais c'est l'idée).

[Tramb]

Et la majorité des développeurs (AAA, ou du moins quand les perfs importent) ne veulent pas échanger des performances contre de la simplicité (du moins à ce point), et c'est ces gens là qui ont poussé pour avoir des APIs console-like sur PC. Après OpenGL et DirectX11 vont rester vivant (enfin pour DirectX11 il a pas bougé depuis un bail), et ensuite les développeurs pourront chacun faire le choix entre "simplicité" et perfs (caricaturale, mais c'est l'idée).

Et à juste titre. Si on laissait les fabricants de logiciel de CFAO driver ça on aurait toujours un pipeline fixe.

[oks2024]

Et des jeux en wireframe .

[Tramb]

Rhoo tu exagères monsieur Gouraud est français tout de même