Pourquoi tu ne laisses pas la carte SD en priorité maximale ? Sachant que si tu enlèves la carte SD ça va passer au second périphérique.

parce que des périphériques, il y en a quatre... au moins. j'ai beaucoup de disques durs

et ça change tout seul, au hasard de la détection de périphériques au boot. il faut les remettre dans l'ordre dès qu'on retire un périphérique au démarrage

Arf, bah du coup la clef usb semble la meilleure solution.

oui mais ce n'est pas donné, surtout pour stocker les quelques centaines de Ko du grub

les constructeurs de clés usb font des clés de haute capacité, maintenant, il n'y a aucun support à dédier entièrement à ce genre d'utilisation (sauf les disquettes )

et puis, démarrer un pc en mettant une disquette dedans, c'est comme être au volant d'une de ces voitures modernes qui fonctionnent avec des cartes à puce.

« oui mais ce n'est pas donné, surtout pour stocker les quelques centaines de Ko du grub » viens raconter ta vie sur le forum linux, et on te trouvera une vraie solution à ton faux problème.

holà, du calme!! techniquement, je n'ai pas encore de problème!

on peut éditer le fstab pendant l'installation, ils fournissent un système minimaliste avec Nano. demain, je retenterai une installation avec un fstab modifié et capable de monter des disquettes, et advienne que pourra. si ca ne marche pas, il reste une autre manipulation de déplacement de GRUB que j'ai vu sur le net. et sinon, ben...

Je ne vois pas comment tu peux être amené à faire des saletés pareilles avec grub.

À mon avis, tu passes à coté de queqlue chose de simple.

la simplicité, c'est taper /dev/fd0 dans le champ de saisie quand grub demande l'endroit où on veut l'installer. mais les choses ne sont jamais si simples. ("grub n'a pu s'installer sur /dev/fd0. cette erreur est fatale.")

et puis la solution du déplacement de grub, c'est une que je garde sous le coude si d'aventure je suis suffisament motivé pour me lancer dans des manips risquées et a l'issue hasardeuse. je fais de linux une utilisation suffisament ponctuelle pour supporter un passage par le BIOS de temps à autre

la disquette, c'est pour le fun! (et aussi pour me donner envie de booter sous linux! )

caelacanthe: Je suis tombé sur ce message au cours d'une recherche sur ce forum : https://www.jeuxvideo.com/forums/1-47-51715-2-0-1-0-xna-game-studio.htm#message_51758

Tu sembles avoir un peu d'expérience avec la SDL et avec la SFML. Tu pourrais me dire ce que tu penses des deux ?

Tous ceux qui ont un avis sur le sujet sont invités à répondre aussi. J'ai lu des choses sur le net, mais je ne suis guère convaincu par les comparaisons.

"Tu sembles avoir un peu d'expérience avec la SDL et avec la SFML. Tu pourrais me dire ce que tu penses des deux ? "

un peu d'expérience. un tout petit peu!

j'ai vu des benchmark comparatifs entre la sfml et la sdl, la sfml fait un peu mieux que la SDL sur bien des points (encore que je me demande s'ils ont testé les capacités des librairies à cracher des milliards de pixels avec le petit réglage magique de SDL qui décuple ses performancess pour ça ), et énormément mieux sur des trucs comme la rotation de sprites... ça dépend du jeu qu'on veut faire, évidemment!

la SFML est aussi polyvalente, elle gère des modules de son, de réseau, on peut faire des jeux en openGL en 3D avec, elle est au moins aussi simple d'utilisation que la SDL.

par contre: si ta machine ne gère pas openGL correctement (j'ai déja eu le problème sur des PC qui n'étaient pas les miens ), ben les performances s'effondrent tellement que c'en est inutilisable

mais ce que je dis là n'est basé que des choses que j'ai appris, ou vu. oui, je n'ai pratiquement jamais utilisé SFML.

le principe de la SDL est ultrasimple, c'est un jeu de gommettes: tu colles des rectangles avec des images dedans sur d'autres de ces rectangles, qu'on appelle surfaces. l'une de ces surfaces est rendue dans la fenêtre. là où c'est énorme, c'est qu'on peut nativement coller ces surfaces sur des surfaces qu'on va elles-même coller sur d'autres surfaces. l'empilage de surfaces, et voilà un programme qui fait du multiscreen dans la même fenêtre!

pas de transformations appliquées sur les surfaces, de shaders, de mipmaps ou quoi que ce soit de haut niveau, la SDL propose une approche extrêmement primitive de la 2d. En cela, je la trouve plus "psychologiquement acceptable" que la SFML pour faire des jeux en 2d qui s'approchent de leurs ancêtres.

ensuite, un petit détail qui ne compte absolument pas, sauf quand on a des contraintes bien précises, genre un espace disque étriqué à mort: la SDL est beaucoup moins encombrante que la SFML. Elle est fournie de série avec une DLL qui compilée pèse environ 300 Ko. pour SFML, si on s'épargne les modules de moindre importance, il reste au moins 1.1 Mo d'exécutable.

naturellement, il y a des services en moins... la SFML a de nombreux modules, est capable d'ouvrir énormément de types de fichiers d'image, alors que SDL ne marche nativement qu'avec des bitmap (on peut cependant rajouter SDL_image pour diversifier), offre vaguement la gestion du son, des supports optiques, des événements clavier/souris... c'est un peu la différence entre xbox 360 et ps3, la xbox coûte moins cher, par contre elle n'a pas le wifi intégré... mais les gens qui n'ont pas peur d'enjamber les câbles ne tiendront pas compte de cet argument

" là où c'est énorme, c'est qu'on peut nativement coller ces surfaces sur des surfaces qu'on va elles-même coller sur d'autres surfaces. "

J'utilise la SDL mais je ne vois pas exactement ce que tu veux dire par là.

ben c'est tout simple. t'as un sprite, appelons-le A. tu le colle sur un autre sprite nommé B. ensuite, tu peux coller B sur ta fenêtre de rendu, et dessus seront dessinés A et ce qu'il y avait à l'origine sur B.

tu n'est pas obligé de coller les surfaces uniquement sur la surface de rendu! tu peux faire des hierarchies! c'est ainsi qu'on peut faire des jeux avec rendu stéréoscopique, sans multiplier les fenêtres

Ah oui je vois de quoi tu parles maintenant, la surface de destination de SDL_BlitSurface.

Autrement depuis quelques temps j'utilise OpenGL (mais toujours avec la SDL) et franchement je trouve que tu as tort de t'en priver.

Un simple programme en SDL qui affiche juste une fenêtre 800X600 et ou je blit un petit rectangle dessus (qui ne bouge pas) me pompe aux alentours de 20% du processeur (ça peut même monter a 30) alors qu'un programma en OpenGL qui fait 10 fois plus de trucs consomme... 0% avec quelques petites hausses.

Ah, limité a 60 FPS dans les deux exemples, je précise.

c'est pas que je m'en prive, c'est juste que mes projets actuels ne se servent pas d'openGL!

après IS-RV2, je me lancerai peut-être sur un truc exploitant openGL (si tanté que j'arrive au bout, quoiqu'à cause de sa petite contrainte de support, je suis obligé d'avoir un lecteur disquette quelque part, et les nouvelles cartes mères ont tendance à faire abstraction du port dédié... pour faire simple, pas de changement de PC avant d'avoir terminé ce truc, si c'est pas un motivateur efficace ça )

" c'est pas que je m'en prive "

Si, t'es comme ça des que y'a un truc qui ne convient pas à ta façon de concevoir les choses.

"Si, t'es comme ça des que y'a un truc qui ne convient pas à ta façon de concevoir les choses. "

je réclame des exemples! c'est trop facile de juger sur la base d'un seul fait

J'ai regarde un peu la SDL et SFML a plusieurs occasion. SFML est un peu jeune. Comprendre par la l'API change assez regulierement et que SFML n'a pas d'implementation pour les architectures exotiques. Alors que SDL est super standard sur tout un tas d'architectures.

On retrouve souvent l'arguement de "la SDL c'est lent". C'est un probleme de backend moisi principalement. Sous windows la SDL est implementer avec directdraw (si ma memoire est bonne) et ce n'est pas particulierement lent. mais la derniere fois que j'ai touche a la SDL sous windows c'etait au millenaire precedent.

Sous linux le back end par defaut est particulierement pourri. Cependant c'est facil de changer le backend de la SDL pour quelquechose qui a plus de peps. je me rappelle de glSDL qui corrigait tres bien les problemes de vitesse. Mais ce n'est peut etre plus tres a jour.

Et si ce n'est pas assez rapide, reecrire un back end SDL tout seul c'est pas tres difficile non plus.

apres SFML ca fait nativement plus de chose. Mais de memoire, c'est un veau de 50Mo et a porter sur une archi exotique ca va pas etre la joie.

PS: Ce message fait probablement preuve de vieuxconnerie

PS2: en meme temps, je dis ca et j'utilise cairo...

Longue vie a C++2011 !

http://developers.slashdot.org/story/11/03/26/1949225/ISO-C-Committee-Approves-C0x-Final-Draft