Triple buffering - Page 3

Oui, mais entre mes essais et lees niveaux de gris de TIGCCLIB ou ceux de genlib, il y a une grosse différence
Changer la hauteur logique de l'écran ne ma paraît de toute façon pas envisageable sur 92+/V200, si ?

Sinon, GrayAdjust change la fréquence de rafraichissement du LCD.
[edit] : Tu as raison, GrayAdjust change la hauteur logique

Sasume
: 1. Impossible avec les programmes utilisant les float

Faux!!! Ce problème est corrigé depuis GCC 3.3.3-tigcc-1 (TIGCC 0.95 Beta 6):

2004-02-19  Kevin Kofler  <Kevin@tigcc.ticalc.org>

	* config/m68k/m68k.c (output_move_double): Fix 10-byte fp stack pushes.

Il n'y a aucune excuse de ne pas utiliser -fomit-frame-pointer de nos jours.

2. Et tu oses dire que ça ne ralentit pas... Franchement, tu es vraiment de mauvaise foi, c'est réellement insupportable

Tu n'es pas obligé d'utiliser USE_FLINE_ROM_CALLS, -fomit-frame-pointer suffit largement. Mais USE_FLINE_ROM_CALLS est le futur, c'est de loin la méthode la plus efficace en taille.

Pourquoi tu n'en dis pas plus ?

Parce que ça montre bien qu'on peut libérer ces registres, donc que ton problème n'existe pas.

Et le fait que ça pessimise le code appelant ?

Pas si on libère assez de registres.

Et le fait que ça peut gêner l'allocateur de registres ?

Pas si on libère assez de registres.

Je te trouve de plus en plus de mauvaise foi...

Sasume
: Sinon, pour revenir au sujet (ou presque) : quelqu'un peut-il expliquer comment faire pour stabiliser les niveaux de gris sur HW2 (sur HW1 c'est compliqué ou non ?) ?

C'est écrit dans gray.s... Indice: 0x70001D.

GoldenCrystal :
Ben, il y a un port qui te permet de mofifier la hauteur virtuelle de l'écran (on peut faire pas mal de conneries avec d'ailleurs ) Si tu diminues cette hauteur virtuelle, le rafraîchissement sera plus fréquent et les gris scintilleront peut-être un peu moins. Je crois que c'est ce que fait GrayAdjust, donc essaye là avant de tenter un accès direct au hardware.

C'était la vieille méthode, qui peut être utilisée en plus de la nouvelle, mais qui toute seule n'est pas satisfaisante.

Sasume :
Oui, mais entre mes essais et lees niveaux de gris de TIGCCLIB ou ceux de genlib, il y a une grosse différence

Y'a pas 50 méthodes pour faire des nvg pourtant
Faudrait demander à PpHd comment il s'y prend

Il n'a pas utilisé 0x70001D, donc c'est normal que ça foire.

Heu, on me parle ?

Rappel historique:
Les HW2 sortent: ca fout la merde pour les niveaux de gris.
PpHd se met au boulot et sort les premiers niveaux de gris pour HW2 -merdiques- (Oue c'est moi ) utilises par un jeu.
JM apres beaucoup de travail reussit a sortir des niveaux de gris potables sur HW2.
PpHd ameliore encore une fois son boulot en synchronisant mieux l'interruption sur HW1 et HW2.
JM ressort une nouvelle version, excellente ! (l'actuelle).
PpHd apres avoir discute par e-mail avec lui reimplante ses niveaux de gris avec la meme methode de JM (mais reimplantee par recopiee).
Thomas Nusbaumer desassemble les routines de niveaux de gris de JM et les file a tigcclib sous la licence tict (a savoir licence ou on ne sait pas trop qui a droit a quoi).

Kevin Kofler
:

Sasume
: 1. Impossible avec les programmes utilisant les float

Faux!!! Ce problème est corrigé depuis GCC 3.3.3-tigcc-1 (TIGCC 0.95 Beta 6)

OK, désolé, je n'ai que la beta 1 sur mon PC (ce n'était pas de la mauvaise foi, je ne savais vraiment pas que c'était corrigé).

2. Et tu oses dire que ça ne ralentit pas... Franchement, tu es vraiment de mauvaise foi, c'est réellement insupportable

Tu n'es pas obligé d'utiliser USE_FLINE_ROM_CALLS, -fomit-frame-pointer suffit largement. Mais USE_FLINE_ROM_CALLS est le futur, c'est de loin la méthode la plus efficace en taille.

Je ne te suis pas trop. En tout cas, ce que je voulais dire, c'est que c'est bien plus lent que d'appeler les ROM_CALLs de la façon classique, donc dans un jeu gourmand, ce n'est même pas la peine d'y penser (mais bon, en général, on n'appelle pas trop de ROM_CALLs dans un jeu gourmand).

Et le fait que ça pessimise le code appelant ?

Pas si on libère assez de registres.

Si puisque de toute façon, le code appelant se retrouve avec un registre utilisable en moins par rapport à la version non patchée, donc il aura forcément une gêne...

Sasume
:

2. Et tu oses dire que ça ne ralentit pas... Franchement, tu es vraiment de mauvaise foi, c'est réellement insupportable

Tu n'es pas obligé d'utiliser USE_FLINE_ROM_CALLS, -fomit-frame-pointer suffit largement. Mais USE_FLINE_ROM_CALLS est le futur, c'est de loin la méthode la plus efficace en taille.

Je ne te suis pas trop. En tout cas, ce que je voulais dire, c'est que c'est bien plus lent que d'appeler les ROM_CALLs de la façon classique, donc dans un jeu gourmand, ce n'est même pas la peine d'y penser (mais bon, en général, on n'appelle pas trop de ROM_CALLs dans un jeu gourmand).

Je ne vois pas non plus en quoi ça serait le futur (et surtout, si c'était si génial que ça, ça ne serait pas le futur, mais le présent ), et même si ça ne va pas ralentir un jeu (qui s'en tape complètement du TIOS, et donc pas de gain en taille non plus), ça risque de ralentir un truc qui fait appel aux rom calls intensivement (parcours de la VAT ? SymFindNext/HeapDeref/HeapGetLock/HeapLock/HeapUnlock)

PpHd :
Rappel historique: Les HW2 sortent: ca fout la merde pour les niveaux de gris.

Il manque: Scott Noveck réussit à obtenir de l'information sur le nouveau matériel directement d'un ingénieur de TI.

PpHd se met au boulot et sort les premiers niveaux de gris pour HW2 -merdiques- (Oue c'est moi ) utilises par un jeu.

Il manque: Peu de jours après, Scott Noveck et Niklas Brunlid sortent un portage de graphlib utilisant les informations obtenues de TI par Scott et les optimisations vitesse brutales de Niklas (qui sont restées: copier-coller de movem).

Thomas Nusbaumer desassemble les routines de niveaux de gris de JM et les file a tigcclib sous la licence tict (a savoir licence ou on ne sait pas trop qui a droit a quoi).

Non, il les file à TIGCCLIB tout court, et on les a mis sous la licence de TIGCCLIB.

Quant à USE_FLINE_ROM_CALLS, je l'utilise dans Backgammon (avec l'émulateur interne à TIGCC) et Gosper89 (avec MIN_AMS=204) et ça marche très bien. Et Gosper89 utilise beaucoup de ROM_CALLs.

et il avait l'autorisation de JM ?

Non.

Merci de ne pas réaborder ce sujet, c'est fini en flamewar à chaque fois. JM a voulu que la discussion soit close, donc même si vous ne respectez que lui, arrêtez-en là s'il vous plaît.

Au fait Kevin, faut-il t'expliquer la différence entre un jeu genre "F-Zero" et "Backgammon" ?

et après tu gueules comme quoi je viole tes droits d'auteurs quand je cite ta propre convention

Si un jeu genre F-Zero appelle des ROM_CALLs tout le temps, il y a un autre problème que la F-Line...

Ximoon > de toute façon, l'optimisation chez Kevin, ce n'est valable que pour les programmes des autres

Kevin, tu as subtilement oublié de t'excuser pour avoir diffusé des informations fausses : ta version du tilemap engine n'est pas plus rapide que la mienne. Tu n'as pas remplacé de 3840(an) par (am).

Il y a un lea en moins.

Arrête ta mauvaise foi, ce n'est pas un lea de 8 cycles sur une routine de plusieurs dizaines milliers de cycles qui changera quelque chose

Non, non. C'est TRES important. Que dis-je ? Absolument indispensable.

PpHd :
>Sur HW1/VTI, avec le double-buffering par échange de pointeurs, on est obligé de faire un GrayWaitNSwitches(2); après le GrayDBufToggle(); avant de pouvoir dessiner quoi que ce soit sur le plan caché. Pas si on s'y prend correctement.

Comment ?
C'est possible de forcer le LCD à recommencer à rafraichir l'écran (sur HW1) ?

je pense qu'il parle de réorganiser le code... mais c pas toujours possible, malheureusement.

A mon avis tu n'es pas obligé de réorganiser le code... Juste le modifier un peu
Si tu as par exemple tes deux plans dans "void *plane0, *plane1;"...

GrayDBufToggle();
if (_GrayIsRealHW2())
  plane0 = GrayDBufGetHiddenPlane(0),
  plane1 = GrayDBufGetHiddenPlane(1);
else
  plane0 = GrayDBufGetActivePlane(0),
  plane1 = GrayDBufGetActivePlane(1);

...ce code devrait fonctionner

euh non, carrément pas... (à moins que ta boucle tourne à bien plus de 90 fps, mais à ce moment-là t'as bien plus simple ^^)
le buffer affiché peut changer à tout moment dans les deux 90è de seconde qui suivent le chgt de buffer.

Bah alors comment tu réorganises ton code ?

Tu fais un calcul intermédiaire pendant les cycles qui suivent la synchro, tu regardes si tu as encore besoin d'attendre, et tu commences le dessin seulement après. Sauf qu'évidemment si tu as un gros truc de dessin à faire dès le début, c plus chaud (surtout si tu dois le faire en plusieurs couches).

Peut-être que PpHd voulait dire autre chose, mais on ne peut pas dire qu'il ait été très loquace

Et l'IA de tes adversaires, et la physique des voitures ? deja ca de gagne.
Sans parler du reste.

IA : y en a pas, mais ça va pas bouffer énormément si j'en mets une.
La physique des voitures : même avec mon truc trop pas optimisé, ça prend à peine qqs milliers de cycles...

Ca suffit

pas vraiment :/ je préfère le triple buffering, de toute façon je crois pas être trop serré en termes de RAM...