Kevin Kofler (./147) :
TiEmu reconnaît les routines de gris courantes (y compris la version standard de Grib) pour ses "gris parfaits",
Kevin Kofler (./147) :
PpHd dans sa sagesse infinie a ignoré tous mes arguments,
PpHd (./150) :
Il ne reconnait toujours pas celle de genlib qui va trop vite pour lui
Solution de Kevin -> Passer à 10 ou 7.5 fps 
DispDot(void*,Misc*); DispDot(void*,struct Misc*);
void DispDot(void* Planes,struct Misc* Data)
{
PortSetPlane(Planes);
DrawPix(Data->CursX0,Data->CursY0,Data->CursModePlane0);
PortSetPlane(Planes+3840);
DrawPix(Data->CursX0,Data->CursY0,Data->CursModePlane1);
}
PpHd (./150) :
Il ne reconnait toujours pas celle de genlib qui va trop vite pour lui
Kevin Kofler (./147) :
PpHd dans sa sagesse infinie a ignoré tous mes arguments,
Merci pour ces compliments. Ca fait plaisir de se savoir devenu sage
(Mais je pense quand-même que tu es suffisamment sage pour avoir compris. )Folco (./151) :
Quant à la routine de gris de Grib, la version supportée par TiEmu est celle que j'utilise. Mes propositions avaient déjà été mergées quand Sasume t'as proposé le patch.
Folco (./152) :
DispDot(void*,struct Misc*);
Le débogueur sert à ça!
Lionel Debroux (./156) :
Kevin, tu sais très bien comment le debugger fonctionne chez moi
).09/02
R 09:46 Lionel Debroux » Kevin Kofler: Tel que TIEmu est actuellement, j'ai l'impression d'être revenu trois à cinq ans en arrière. En fait, au temps où ExtendeD, toi et moi (principalement) avons fait pas mal de beta-testing et feature requests pour TIEmu.
C'était en effet à cette époque qu'on avait des bugs de la classe d'un crash (ici, avec libération d'adresses invalides, me dit glibc dans la console) quand on fait une opération courante, du genre valider l'adresse qu'on veut aller voir dans la mémoire ou cliquer sur un ROM_CALL dans la liste des ROM_CALLs...
Et encore, à l'époque, la source additionnelle de complexité (je sais que tu en as chié pour faire un truc qui fonctionne à peu près), bugs et lenteur qu'est GDB/Insight n'existait pas...
Dans l'état actuel des choses, un truc est clair: si VTI permet de faire ce que je veux (ce n'était pas le cas pour un des trucs que j'ai faits ce week-end, mais pour l'autre, c'était le cas), c'est VTI sous Wine que je vais probablement utiliser, puisque TIEmu sans GDB et TIEmu avec GDB (si je les compile moi-même) sont tous les deux complètement inutilisables, comme décrit dans le topic des feature requests.
Le package tiemu-gdb n'est pas inutilisable, mais moins stable que VTI sous Wine. Pour désassembler & exécuter des ROM_CALLs du CAS ou autres, on n'a pas besoin d'un debugger symbolique... J'ai utilisé VTI bien plus qu'il n'en suffit pour savoir ce qu'il permet et ne permet pas de faire, et avec quelles limitations.
(en fait, j'utilise parfois VTI sous Wine, et parfois TILP+TIEmu sous Vista virtualisé avec Virtualbox)
Aider à debugger (et peut-être implémenter) une fois de plus pour faire avancer les choses, je veux bien... mais je serais plus motivé si tu montrais plus de respect, en particulier envers Romain. Tu es injuste avec lui, puisque le gros des problèmes NE VIENT PAS du packaging. Et comme il l'écrit, il n'a non seulement pas le temps, mais aussi pas d'ordinateur...
ta description du problème est trop vague pour le résoudre
quand on fait une opération courante, du genre valider l'adresse qu'on veut aller voir dans la mémoire ou cliquer sur un ROM_CALL dans la liste des ROM_CALLs...
void DispDot(void*,struct Misc*); void DispLine(void*,struct Misc*);
Its scope is only this definition or declaration, which is probably not what you want.
De plus, il ne me sort ça que pour un seul proto. 
)
Le débogueur sert à ça! 
