Logicielsmoto.com

Grosse question du jour : Teo, en l'état, fonctionne-t-il sur Windows Vista et Windows 7 ?

Up!

Je me cramponne toujours à XP, donc je ne sais pas pour Vista ni Win7.
Par contre, il fonctionne bien sous XP mais il fait turbiner ma machine: le ventilo tourne autant qu'il peut. Ma config' n'est pas basse pourtant: Pentium IV 2,8 GHz (portable, Sony Vaio).
Mais sinon ça marche très bien.
Voila qui ne répond pas du tout à ta question.

Sin.

Oui, je ne sais pas pour l'instant pourquoi Teo utilise 100% du CPU sous Windows. C'est d'autant plus gênant que ça pourrait être évité, du moins au repos...

J'ai trouvé. Le problème vient du while() sur get_audio_stream_buffer() dans asound.c

L'idée du programmeur est, je crois, d'attendre la fin de la période de 1/50sec du driver son pour la synchro. Ca marche bien, sauf quand la fenêtre n'est plus active, car dans ce cas pour un raison que j'ignore get_audio_stream_buffer() vaut tout le temps NULL et la boucle mange 100% du cpu.

Perso j'ai ajouté un petit usleep(1000) pour pauser le système pendant 1ms entre 2 appels:Et ca marche beaucoup mieux! Cela dit c'est pas la meilleur solution car si on joue du son, alors il part quand même en boucle (sans manger du cpu cependant).

sam.

Le meilleur moyen serait effectivement d'éliminer cette boucle. Après tout, il s'agit d'une boucle dans une boucle, puisque la fonction est appelée par la boucle dans RunTo8(). Un "if" devrait donc suffire. Il faudrait voir quel taille de buffer pour le son devrait être employé pour devenir confortable, même pour des ordinateurs "lents"...

Je suis pas certain que virer la boucle while() soit une bonne idée. En fait la bouche principale de l'emul s'execute en 1/50 secs.. Si elle s'exécute plus vite parce que le CPU natif est puissant, la boucle du while() dans asound.c est là pour le pauser de sorte à être synchro avec un vrai TEO. Donc si on vire cette boucle dans le asound, on ira trop vite.

Si tu veux je peux te filer le sources de TEO que j'ai un peu retravaillé. J'ai allongé les buffers son pour être moins saccadés sur ma machine. J'ai aussi ajouté quelques goodies (ligne de cmd, drop de fichier SAP sur l'exe, possibilité de monter un dossier PC en disk TO, support FD 320ko ou 640ko en lecture/écriture, etc). Normalement tu as du recevoir des mails de ma part à ce sujet.

Dans les cartons, mais pas pour tout de suite (car je n'en ai pas besoin).. un serveur http embarqué pour piloter le debugger depuis l'exterieur (en vue de greffer TEO à un IDE de developpement ou autre).

sam.

Effectivement, c'est sur cette boucle que repose toute la tempo.


.... mais c'est à croire que tu n'as pas reçu les miens concernant les fichiers diff.

Heu non j'ai rien reçu de mon coté.

Je me disais aussi... D'habitude, tu mettais moins de temps à répondre aux mails . Je te les renvoie.

C'est gmail qui déconne (son accès imap ne marche plus chez moi)..

sam.

Excusez-moi, j'ai peut-etre loupé un truc, mais ne serait-il pas mieux de coder "moderne" en utilisant une call-back sur un timer ou mieux sur le son, plutot qu'une boucle de tempo ? Y'a que sous DOS qu'on utilise des tempos.
La call-back est plus precise et permet d'economiser tout le temps CPU inutilise. Si j'ai correctement compris le contexte, c'est normal que l'emu prenne 100% de cpu, il n'est pas code pour un os multitache.

Fool

Malheureusement, Allegro précise bien que l'on ne doit pas mettre la fonction get_audio_stream_buffer() en interruption.

Tout à fait. Une solution possible: utiliser [url=http://www.allegro.cc/manual/api/graphics-modes/vsync[/url]vsync()[/url] quand on recoit NULL avant de retenter un nouveau get_audio_stream_buffer(). Cela dit, j'ai un peu peur qu'attendre 1vbl soit trop long (sauf si on est en 90hz). L'experience montre que usleep() marche bien jusqu'à 10ms de pause (1/2 vbl en fait).

Il faudrait voir jusqu'où tu peux descendre sans faire remonter l'occupation CPU en flèche.