WrathOfThePixel a écrit 366 commentaires

Je vais voir ça merci :)

Va falloir pas mal d'entrainement pour prendre des notes rapidement à mon avis =D

Le bon lien

Y a vraiment rien de sorcier. Faut bien nettoyer l'ancienne (j'utilise de l'acool isoprpylique perso), sur la puce comme sur le dissipateur, et mettre vraiment une mini goute de la nouvelle, en évitant soigneusement de choisir du bas de gamme.

Sinon il parraît que les pads thermique ça marche bien aussi, beaucoup plus facile à appliquer apparament.

Et encore avant ça, il y avait le moteur Freescape d'Incentive Software sur 8/16 bits, et son outil de création 3D Construction Kit rendu disponible par les développeurs.

Et si une bonne réponse au devoir était justement de pointer le risque de biais par rapport aux images et à leur légende ?

Le lien fonctionne bien chez moi.

Merci ça à l'air chouette.

Plus qu'à réflechir si je crée une dépendance de plus juste pour ça =D

(en anglais désolé)

System settings -> Workspace Behavior -> Screen Edges -> cocher Tile : Windows dragged left or right edge

Pulsaudio ne remplace pas Alsa. C'est une interface entre Alsa et les applications. Alsa est toujours nécessaire pour assurer le pilotage bas niveau du matériel.

En effet; à ma connaissance, Inkscape, en tant que logiciel artistique, n'a pas vocation à répondre à ce genre d'exigence.
Il est bien possible que dans ton cas, te "cogner les calculs" soit au final plus efficace qu'apprendre un vrai logiciel de CAD cependant. Je ne sais pas quel volume de carrés tu as à produire.

Pour aller plus vite avec moins de calculs, faire un carré de la taille désirée, sans contour, puis un autre à l'interieur, 2mm plus petit, centré, puis coloré differement ou découpé avec un opération booléenne serait peut-être mieux.

Oui, je cherchais à me compliquer inutilement la vie…
Merci !

Oui tout à fait. Alors on ne copie pas pixel par pixel, mais plutôt par autant de mémoire qu'on peut à la fois, mais c'est l'idée. Sur CPC, la zone de mémoire graphique est en RAM donc ça va bien (et relocalisable si on veut faire du double buffer), mais il faut faire une petite gymnastique parce que, arrivé en fin de ligne, on saute de 8 pixels verticaux donc c'est relou, mais ça marche.

Bah oui forcément, avoir des sprites hards facilite et accelère les choses. Mais les meilleurs programeurs arrivent à faire des animations tout à fait étonnantes avec juste du soft et beaucoup d'intelligence.
Des jeux avec des dizaines de sprites, ou avec des gros sprites qui font la moitié de l'écran, il y en à eu. Surtout vers la fin de vie des machine quand les démo makers se sont mis à faire des jeux. Il ont eu du mal avec la jouabilité à mon sens, mais c'est un autre débat.

Quant aux FPS c'est simple, sur 8 et 16 bits, il faut que ça soit un diviseur entier du rafraichissement de l'écran, sinon il y a du tearing. Sur les vieux ordis 8 et 16 bits, l'affichage se faisait en suivant de près le balayage du moniteur. En inserant des NOP dans les boucles si besoin pour syncroniser. Donc le chiffre de 15 FPS n'à pas de sens. La plupart des jeux tournaient à 50FPS sans soucis, 25 restait acceptable s'il y avait vraiment beaucoup de choses à afficher. En dessous de ça, il y en a eu quelques uns bien sûr, mais généralement c'était des jeux vendu 10 balles que personne voulait ^'

Mon premier ordinateur était un ZX Spectrum, ensuite un Amstrad CPC, et ensuite un Atari ST.
Toutes ces machines n’ont pas de hardware sprites donc pendant des années j’ai joué avec un framerate 15fps.

Je ne sais pas trop pour le Spectrum, mais les deux autres etaient tout à fait capables d'afficher pleins de sprites à 50fps. 25 au pire pour les jeux les plus gourmands/mal optimisés.

Merci je garde le lien sous le coude =D

Oui j'ai pensé aux plugins ;)
Dans ma reflexion, c'est pour le moment résumé à juste un bouton pour charger un patch, et laisser le travail d'automation se faire via le DAW, par Midi. La création du patch se faisant à part.

Côté perf, justement le moteur de synthèse sera completement décorélé de l'UI, dans son thread à lui, dans un langage bas niveau. Rien dans la synthèse elle-même ne dépendrait du thread UI. Avec possibilité encore une fois de le lancer en mode headless et ne jamais executer une ligne de Python.

Pas con l'histoire du controleur Midi… Faut voir si des messages Midi seraient suffisant à le création d'un patch (sans trop de bricolage non plus). Je suis pas encore assez documenté pour ça, merci pour l'idée.

Je peux plus éditer alors je m'auto-réponds.
J'ajouterais que si un jour quelqu'un veut refaire une UI en rust/gtk, javascript/web ou brainfuck/motif, il n'y aurait pas de raison de se trimbaler une dépendance à Qt.

J'avoue que ces questions font encore partie de la réflexion actuelle.
Dans l'idéal, il faudrait pouvoir utiliser Qt et X/Wayland quand ils sont là et si désiré par l'utilisateur, ou pouvoir être en mode headless pur, pour tourner sur un Pi sans serveur graphique par exemple. Dans ce cas une ligne de commande spécifierais le patch à charger et les parametres de connexion au serveur son éventuellement pour écouter des message midi et évidement sortir l'audio.

Merci, avec Inkscape tout bêtement.

Non, Python ne serait chargé que de l'UI dans son propre thread, tout le reste serait en C.

Je vais étudier la question oui.
L'autre bonne raison (dont je n'ai pas parlé, j'aurais dû) de ne pas vouloir tout faire en Qt, mais le cantonner vraimement à l'UI, c'est qu'un utilisateur pourrait avoir envie de lancer le soft en mode headless, pour juste lire son patch sur une machine pas forcément très performante, sans s'encombrer du poids de l'interface. Pour une session live par exemple. Du coup l'approche synthèse en C au plus bas niveau possible semble plus pertinente. Après je ne sais pas trop ce qui est possible de faire en pur Qt à ce niveau. Faut que je me renseigne serieusement.

Merci pour cet avis.
Justement, dans la balance "se faire chier", il y a d'un côté "me contenter de mes compétences actuelles" vs. "en acquérir de nouvelles".

Et Qt (le vrai, en C++), je n'y ai à peu près jamais touché, et j'ai aucune idée du temps que ça va me prendre pour m'y former, vs. donc, le temps que ça va me prendre pour faire ça comme je l'ai prévu. J'avais pas prévu de me mettre serieusement au C++ en tout cas… Mais ça peut être envisageable, je ne sais pas.

Amsdos pour le 464 n'était pas dans la machine, mais dans le contrôleur DDI-1 vendu à part.
Amstrad et les économies de bouts de chandelle…

Merci. Je ne trouve de définition de b nulle part dans le code, mais ça compile quand même, du coup je comprenais pas… (et toujours pas d'ailleurs)

Faudrait le faire tourner sur KDE, ça leur montrerait ce que sont des options de configuration.

Je ne savais pas s'il était possible d'utiliser OSM hors ligne.