Aldebaran a écrit 250 commentaires

Pareil pour ça : FSR 4.1 (extension programmée aux cartes 7000 et 6000)
Et ça : The 'Fake' Geometry of Crimson Desert: How it Really Works

Je viens de voir ça chez Videocardz, je l'aurais bien ajouté à la partie impact sur le développement : SIGGRAPH 2025 Advances in Real-Time Rendering in Games: Fast as Hell: idTech8 Global Illumination (Youtube)

Bon bah, je vois ce qu'il me reste à faire.
Merci pour le lien des images, je savais pas que c'était accessible !

je portais mon polo LinuxFr.org
Mon dieu, y a des produits dérivés LinuxFR ?! Ou puis je en acheter ?

Arf, non Godot ne supporte pas le raytracing en l'état (pas sans le fork nvidia et une carte nvidia, ou via le code de J.E.N.O.V.A qui est non distribué (quand je lui ai demandé si ça serait libéré, le dev (Architect) m'a dit que non, apparemment il veut faire un fork du moteur mais je ne sais pas ou ça en est et comme c'est proprio ça m’intéresse moins, le pathtracer serait libéré à terme mais bon on verra bien).

Je suis moins au fait de blender, je sais juste que l'import dans Godot du roughness d'un matériau PBR est buggé en GLTF (fixé à 0.5).

Je vois, perso je m'amuse pas mal avec Godot, j'aimerais bien tester le raytracing uniquement sur les réflexions passé une certaine valeur de roughness.

Ça permettrait d'avoir de beaux reflets potentiellement moins consommateurs que les réflexions planaires (même si on peut vraiment bien tricher avec le FSR2 sur la caméra des planaires) et surtout plus simplement (une caméra par surface planaire affichée, ça limite forcément).

J'avoue, le titre est un peu clico-raccoleur ;)

On peut très bien faire des jeu non photo réaliste, j'en parle plusieurs fois d'ailleurs. Et même si je suis très intéressé par cette méthode de rendu (parce que la technique c'est cool quand même), je privilégie la rastérisation quand je joue perso.

Je n'ai pas encore trouvé de titre me faisant préférer le raytracing en me faisant oublier l'impact sur les perfs.
Après même sur des direction artistique non photo réalistes, ça peut avoir un intérêt (pour avoir de belle réflexions temps réel). C'est une méthode rendu, une technique quoi.

Ce qui me chiffonne (et je pense que c'est ressortit dans la dépêche), c'est l'emballement qu'il y a eu sur ce sujet au niveau des AAA. Mais bon, les AAA ont de plus en plus de problèmes, c'est seulement un de plus et à mon avis pas le pire.

Je serais très curieux d'avoir dans les mains des choses comme ça et une analyse par rapport à ce que je connais (Intel et AMD en gros, un peu de soc ARM, mais c'est tout niveau archi dans mes étagères).

J'aimerais bien avoir un proc en Risc V, mais ça reste un peu délicat pour mon usage et niveau qualité prix.

C'est pour le boulot ou en perso que tu as ce matos ?

J'avoue qu'un peu de concret au niveau européen serait appréciable. Ce serait formidable d'avoir des usines en europe capable de produire des puces et de la mémoire.

Bon, les acteurs actuels ne sont pas bien indépendants non plus, il me semble que la pluspart des fabriques utilisent des machines de lithographie venant de chez ASML basé en hollande.

Je ne sais pas si des taxes sur les produits étrangers serait un bienfait ou une bétise.
Ce n'est malheureusement pas la seule dépendance que l'on a.

Merci à vous deux (et aux relecteurs qui m'ont aidés à corriger mes fautes) !

Ça veut dire qu'on aura de quoi graver des AMD Ryzen en europe ?
Bon on gravera peut être du Risc ou autre mais ce serait déjà génial ^{^}

2nm c'est tout petit.

J'ai vu ça, mais une RX 6400 par exemple supporte 2 écrans en 7680x4320 (je crois que c'est ça 6K) pour de l'affichage simple c'est pour ça. Pour 20W de moins qu'une Arc Pro B50 et en dessous de 150 euros.

Je parle des pilotes graphique, à mon avis (pas forcement le plus fin) le pilote libre pour amd est vraiment bon. Intel a naturellement encore du chemin a faire, une carte graphique dédiée n'étant pas un circuit graphique intégré. Mais ça avance bien aussi. Le plus gros point noir étant nvidia.

Juste sur l'aspect technique, rien que le proc consomme jusqu'à 600w, donc bon en cumulant le reste et surtout en ajoutant un belle marge de sécurité, tu te retrouve avec une très grosse alim. Ça ne veut pas dire qu'elle va consommer ça. Vu qu'elle est surdimentionnée elle va sortir des tensions et courant plus stables aussi. Pareil avec son noctua, ça fait un bon refroidissement solide et durable.

Il compile des kernels toute la journée il faut bien un truc qui tourne quoi.

Y a juste la cg intel que je ne comprend pas, y a des models amd qui font mieux pour moins cher pour moins de conso et avec de meilleurs drivers.

Après niveau écologie, l'informatique de toute façon ça ne n'est pas très propre.
Quant à l'ia, il a parlé d'une bulle qui va se dégonfler mais il est lucide, le diable est hors de la boite faut faire avec.

Et c'est bien triste. Rien que pour le prix de la ram, des cartes graphiques et en premier lieu de l'impact écologique.

Mais bon, depuis que je m'intéresse à l'écologie, notre planète, au vivant et à notre espèce, je suis de plus en plus convaincu qu'on y arrivera pas.

L'espèce va bien finir par s'éteindre faut juste voir comment. En attendant on peut toujours se réfugier dans la drogue.

Certes, je suis obligé de revoir mon jugement car les arguments ne manquent pas de logique.

In fine, il me faudra définitivement des widgets avec des trucs de haut niveau genre menu, boîte de dialogue "Ouverture de fichiers", etc.

Hehe, j'en veux aussi de ça ;)
C'est dans mes plans de faire un panoplie de widgets définis en RML, j'ai les boutons là (trolilol). Blague à part, j'aimerais implémenter le maximum de choses en RML pur, avec le minimum vital en dur, même les layouts etc, ça doit se faire (j'ai des layouts maison dans certaines apps en QML ça fonctionne pas mal et c'est moins dingo que je ne l'avais imaginé).

Ça viendra sûrement quand j'aurais terminé les Repeater et la base des Column, Row.
Parce que sinon c'est quand même vachement dur. J'ai un peu avancé sur les Repeater, il faut encore que je diversifie correctement les id des instances. J'en ai profité pour ajouter $.this et $.parent quand j'ai constaté que je les avais zappés.

Pourquoi pas : MLM -> "A Markup Language for Macroquad" ? 😉
Ou sinon, tu gardes MLM -> "My Markup Language" et un jour éventuellement…. (car s'ils acquiescent chez Macroquad, pas impossible que ça s'accompagne d'une respo de maintenance !)

N'hésites pas à ouvrir une issue sur le github pour ce genre de proposition, ça permettra d'ouvrir la discussion ;)

cela dit, il est certain que je vais essayer ton DSL ; et je te ferai des retours assurés 😀 !

J'ai hâte d'avoir tes retours de bugs ! Il doit y en avoir pleins !

À la limite, un modèle publié avec tout son jeu de données d’entraînement et la méthodologie et les outils pourrait être qualifié de libre non ?

Si t'arrives à coder ton truc avec mon DSL chapeau bas, à mon avis en l'état ce sera bien plus simple (et stable) directement avec macroquad si tu veux rester bas niveau, ou bien avec Slint.

Mais y en a plein dans l'écosystème Rust. Egui est top aussi, mais c'est un autre paradigme. Et si jamais tu veux donner une chance à mon DSL ça me ferait hyper plaisir, je pourrais même trouver du temps pour implémenter des trucs dont t'aurais besoin en terme d'UI ^{^}

C'est carrément un "ML déclaratif pour Macroquad", au début je voulais rester au maximum agnostique du moteur de rendu (j'ai fais mes premier essais avec FloDraw qui est vraiment top aussi), mais entre les type font et texture et les events systèmes de macroquad, plus les appels de rendu ça devient de plus en plus lié.

Je peux toujours bazarder macroquad, mais en l'état, ouais, ML déclaratif pour Macroquad ça colle. Ça ferait Macroquad Markup Language, MML, c'est pas mal comme nom (je pensais changer). Faut que je vois si ça pose pas pb aux gens de macroquad.

Y a pas de mal.

Ce qui a fait réagir BAud, c'est que tu a grillé des étapes et que tu as visiblement exécuté des commandes sans en comprendre le but (ce qui est très dangereux, surtout dans un cas de récupération de donnée).

Ça a fonctionné dans ce cas là et c'est très bien, mais ça aurait pu être plus grave.
De manière général, n'exécute jamais des commandes ou des programmes dont tu ne peux pas garantir l'origine, ou qui n'ont pas été certifié part ta distribution, sauf si tu comprend ce que tu fais, ça évite déjà pas mal de problèmes.

Et pour les pannes de courant, un onduleur ça sauve des vies ;)

Le formulaire à l'air de ne pas fonctionner, je n'arrive pas à commander :

https://web.archive.org/web/20041009182732/http://www.gnulinews.org/elegance-du-geek.php

J'ai fais vite fais le test pour voir.

Avec une conf full AMD en AM4 et DDR4, ça me semble un poil plus perf que la config Xeon.

AMD Ryzen 5 3500X et ventirad 45 euro Lien

Carte Mère HP ELITEDESK 705 G3 (AM4) + Alimentation 20 euros Lien

Mémoire RAM SAMSUNG 4Go M378A5244CB0 10 euros Lien

Boitier PC SilverStone 25 euros Lien

AMD Radeon RX550 4 Go 50 euros Lien

Mais ça monte à 150 euros du coup.
Et j'ai aucune idée de la fiabilité de la config (la carte mère + l'alim à 20 euro quoi)

Je lis les péripéties de sudo-rs sur Phoronix depuis son intégration à Ubuntu, là bas ça tire à balle réelle sur le langage, comme une bonne blague pour dire que le rust, au final ça pu la merde.

Alors qu'en soit, c'est assez normal d'avoir des bugs avec une ré-écriture d'un truc aussi sensible que sudo; la blague à mon avis aura été de l'inclure par défaut dans un truc aussi mainstream qu'Ubuntu.

Mais ça reste un bon rappel de ce que fait le rust et de ce qu'il ne fait pas ;)

Je trouve de plus la promesse de uutils coreutils plus intéressante en terme de ré-écriture, avec des benchs, des suites de tests de conformités et le fait de tourner directement sur pleins d'OS pour avoir à terme une panoplie vraiment multiplate-forme.

Et sur l'inclusion dans le noyau, je suis également partagé.
Y a de belles choses, comme les drivers des mac m1 (une super aventure de code à lire sur le blog de Asahi), mais ça à l'air de briser les parties génitales d'un paquet de devs c quand ils doivent s'adapter aux changements demandés par les dev rust.
J'espère que c'est un cap à passer, parce que j'aimerais bien voir le Rust briller, mais l'avenir nous le dira. Ça à l'air costaud de mêler du C et du Rust dans un projet de cette échelle quand même.

Et sinon il restera Redox ;)

Bah à la base j'y pensais comme au markup language dans HTML;
Et je pensais que QML venait de là (Qt Markup Language), mais en fait c'est Qt Meta-object Language… Donc bon…

QML reste un langage à balise après, DSL c'est un peu plus ouvert encore, ça peut englober tout et n'importe quoi.

Mais si tu as des propositions de nom ou de signification de l’acronyme je suis ouvert au truc ;)

Ah merci Gof ;)
En passant et si ça n'est pas clair, je ne veux en aucun cas faire une concurrence de quoi que ce soit avec Slint (de toute façon Slint est à des années lumière de mon machin), c'est vraiment par jeu et pour comprendre comment ça marche que je fais ça.

En fait la macro s'occupe de 99% du parsing et je la trouve assez lisible; mais je n'ai pas trouvé mieux que de faire une opération en string pour traduire ma notation $element.property en rust classique;

J'ai une méthode transform_dollar_notation(), qui essaye de faire le taf, mais comme elle est appliquée avant la macro elle doit "deviner" le type des propriété concernées, pour les cas limites (l'initialisation par callback par exemple) ou je n'arrive pas à deviner facilement le type, j'ai une notation :

$root.value = $test.testValue:f32; <= ça permet à ma méthode de déterminer que testValue doit être castée en f32.

C'est un peu dommage, parce que mon abstract value "sait" de quel type elle est, mais je ne pense pas qu'il me soit possible de faire une fonction get qui retourne des type différents, même pas une proc macro; et ça se comprend hein.

Sinon j'ai pensé à générer des structures à la fin de mon code de macro (une par noeud d'ihm) pour servir d'accesseur / setter et remplacer ma notation, avec des champs correspondants à mes propriétés, et des getter / setter.

Genre :

struct root {
value : f32
}

struct test {
testValue: f32
}

Pour pouvoir écrire :

root.value = test.testValue; <= et ça reste du rust classique au final

Mais la partie synchro avec mon engine est un peu lourdingue; soit je passe par des méthodes prégénérées (get / set; et du coup la syntaxe devient root.set_value(test.get_testValue); classique) soit je trouve le moyen de redéfinir le comportement de l'accesseur et du = en rust; soit je resynchronise toutes mes structs avec mon back à chaque boucle d’évènement.

Et je pense que je dois toujours déterminer au préalable le type de mes propriétés, et du coup je me tate à rendre leur type obligatoire à la déclaration.

Comme ça :

Node {
id: root
number value: 0.
}

Ça serait le plus simple pour s'assurer du type de mes propriétés.

J'ai bien essayé de lire le code de Slint, pour voir comment ça fonctionne, mais le code de macro doit être trop bien écrit, ça a l'air tellement simple et naturel que je ne rencontre aucunes des problématiques qui sont les miennes :)

Si tu as des idées ou des pistes concernant mes interrogations je serais ravi de les entendre, ça me ferait plaisir d'avoir l'avis de quelqu'un qui sait ce qu'il fait !
Et sinon pas de soucis, je comprend si tu as autre chose à faire, comme par exemple t'occuper de Slint ;)

Salut; oui je suis pas au point sur le nom on est d'accord ;)

Alors pour répondre à ta question, oui et non, c'est fortement inspiré du QML, mais la syntaxe est différente et il n'y a pas de js.
À la limite ça peut servir de base pour une qml en rust, mais c'est un taf terrible pour la compatibilité.

Slint par exemple de mon point de vue, remplis vachement mieux cet objectif. Là non plus on est pas sur du QML, mais ça reste proche, et surtout ça fonctionne bien.