Recapitulatif des jeux en préparation - Page 2

Nerick : l'ajout de fonctions de lignes dans GX, ça dépend de Pen^2

Comment ça, ça dépend de PenPen?

Pen^2 : combien pour ta routine de tracé de ligne ?
Elle est en niveau de gris ? Et clippée ?

Pen²: avec ce bench:
OSFreeTimer(USER_TIMER);
OSRegisterTimer(USER_TIMER,20);
while (!(OSTimerExpired(USER_TIMER))) {
FastDrawLine(LCD_MEM,0,0,159,49,A_NORMAL);
i++;
}

j'obtiens:
sans OSSetSR(0x0400): 454, 462, 472, 471, 455, 475, 455, 475, 469, 474, 455.
Avec: 520 à 545, surtout < 535 (au moins 4 valeurs > 535 sur environ 15 essais).

Je précise que la routine ne fait aucun clipping, même si ce n'est pas ça qui joue énormément sur la vitesse...

Les variations entre les différentes mesures sont peu significatives.

La fonction de Pen^2 est carrément plus rapide : 930 tracés par seconde

sauf que les coordonnées de la ligne n'ont pas été prises au hasard

essayez plutôt avec (0,0)-(99,99) et même ExtGraph vous battra


Le seul bench à peu près significatif est le tracé successif de rayons d'un disque...

En utilisant le bench, sans OSSetSR(0x400), avec ma routine (qui suit le standard d'ExtGraph) :

sur une 92+ HW2 (notez l'HW, c'est important) : 1593, 1582, 1556, 1576, 1571, 1623, 1562, 1611, 1618, 1614, 1552.

Je précise que la routine ne fait aucun clipping, même si ce n'est pas ça qui joue énormément sur la vitesse...

Je pense quand même que ça pourrait pas mal influencer.

Dans le cadre des jeux ****** on peut rajouter **** ***** de moi fonctionnant grace a ***** basé sur Xlib et aussi un ********* de *** de moi aussi

Pour bien bencher le tracé de ligne dans toutes les positions, la méthode de pphd n'est pas mal du tou:

on met un point fixe au centre et l'autre, il tourne autour de l'écran, avec cette méthode, j'arrive (XLib dans sa version ASM.. pas celle en C ) a ~1000/seconde sur HW1 (et sur 89, j'en ai moins a tracé...)
si je me rappelle bien, pphd était à 1200 avec genlib...

bien vu
mais il tourne dans ou hors de l'écran?

Pollux a écrit :
sauf que les coordonnées de la ligne n'ont pas été prises au hasard
essayez plutôt avec (0,0)-(99,99) et même ExtGraph vous battra

1 - oué, g pris ds le premier octant, et pas trop proche de la diagonale :] (mais c pas un cas tellement favorable non plus vu la longueur reduite des segments)
2 - ba il suffit de le gerer aussi (ct prevu)

[b]Le seul bench à peu près significatif est le tracé successif de rayons d'un disque...

je sais, et c pour ça que j'av pas encore donné mon bench, vu que ma fn n'est pas encore finie.


PS
moi ct sur vti.
et je testerai ac les conditions de XDanger qd elle sera finie, et seulement qd ce sera fini.

PPS
Thibaut : ct passé à 960, j'av oublié de virer une ligne ds la boucle principale..

PPPS
ma fn n'est pas clippée.

PPPPS
ExtendeD : bouhhh, va falloir que j'accelere tout ça si mon bench se confirme

t'as deroulé les boucles ou pas ?
moi, non.

> moi ct sur vti.
Moi aussi. VTI 89 AMS 2.03.

Mes boucles sont enroulées aussi.

Voici les resultats du bench de ma fonction, en faisant la moyenne sur 5 secondes :

Sur VTI à 100%
. 914.6 ; 911.6 ; 914.6 ; 914.8 ; ...
Sur ma 89 HW2
8 1280.6 ; 1286.2 ; 1280.6 ; 1285.2 ; 1273.8 ; 1284.6 ; 1283.6 ; 1282.

code utilisé pour le bench :

;© 2002 By Julien MONVILLE



	Include	"tios.h"
	Include	"filelib.h"
	Include	"graphlib.h"
	Include	"userlib.h"
	Include	"ziplib.h"

	Xdef	_main
	Xdef	_ti89
	Xdef	_ti92plus
	Xdef	_comment
	Xdef	_install_preos





;#######################################

BENCH Set 1
_89 Set 1
;_92 Set 1



USER_TIMER Equ 6
NB_SEC Equ 5

XI	Equ	0
YI	Equ	0
	IfD _89
XF	Equ	159
YF	Equ	49
	EndIf
	IfD _92
XF	Equ	239
YF	Equ	127
	EndIf

ADJUP	Equ	$FF		;$FF pour eviter l'optimisation en moveq.. ça ferait planter ac le code auto modifié :o
ADJDOWN	Equ	$FF
LMIN	Equ	$FF
LMAX	Equ	$FF

;#######################################


_main:;	bra.s *
	
	IfD BENCH
		move.w		#$400,d0
		trap		#1
		move.w		d0,oldsr
		moveq		#0,d7
		pea		NB_SEC*20
		move.w		#USER_TIMER,-(a7)
		jsr		tios::OSFreeTimer
		jsr		tios::OSRegisterTimer
	bench_loop:
	EndIf

	move.w		#XI,d0	;xi
	move.w		#YI,d1	;yi
	move.w		#XF,d2	;xf
	move.w		#YF,d3	;yf
	bsr		drawLine

	IfD BENCH
		addq.w		#1,d7
		jsr		tios::OSTimerExpired
		tst.w		d0
		beq.s		bench_loop
		
	exit:	jsr		graphlib::clr_scr
		addq.w		#6,a7
		move.w		oldsr,d0
		trap		#1
		move.l		d7,-(a7)					;d7.w = nb de segments
		pea.l		output
		pea.l		buffer
		jsr		tios::sprintf
		lea		12(a7),a7
		SetFont		#1
		WriteStr	#2,#40,#4,buffer				;89
		jsr		tios::GKeyFlush				;ras le bol de quitter trop vite #mad#
		jsr		userlib::idle_loop
	EndIf
	
	rts
		
	IfD BENCH
		oldsr:		dc.w	0
		output:		dc.b	"nb de segments : %lu !",0
		buffer:		ds.b	32
		Even
	EndIf

XDanger : moi c VTI, AMS 2.05.

ça doit pas changer grand chose au niveau ROM Call, mais on sait jamais

Precision : au debut je benchais à la barbare sur VTI : je lançais le prog et le chrono de ma montre *en meme temps*, j'incrementais d7 à chaque boucle et je breakais VTI ac F11 au bout de 30 sec (ac les TOUTES les ints désactivées)

Il ne faut jamais bencher avec VTI ! 3 raisons à mon avis :

1- Il tourne sur un OS multitâches, donc d'une seconde à l'autre il n'y a pas le même nombre de cycles émulés.

2- En plus, rien ne dit que l'émulateur du processeur exécute bien toutes les instructions pendant le nombre de cycles préconisé par Motorola

3- Sur vraie TI HW1, l'accès à la RAM vidéo est plus lent que l'accès à la RAM tout-court.

oué mais c pour se faire une id.
Et puis on a tous le meme emu

Pen^2 :

Bizarre, avec ton bench, je trouve avec ma routine :
VTI 100% : 4669, 4662, 4645, 4672, 4661
92+ HW2 (mais avec le test pour 89) : 8595, 8573, 8616, 8586, 8638, 8618

Je trouve ma routine un peu trop nerveuse, tu es sûr de tes constantes ?

Et il faut que ta routine supporte A_REVERSE, A_NORMAL/A_REPALCE, et A_XOR (qui est pas forcément facile à implenter)

Ma routine fait dans les 450 octets non déroulée.

ben ça correspond à peu pres pour la 92+ hw2 : 8618/5 = 1723 segments/secondes.
tu étais à 1600 sans desactiver les ints, donc c pas si incohérent.

pour vti, c vti 92+ ou vti 89 ?
moi vti 92+ me retourne une valeur à la c**.

sinon g des nouvelles valeurs pour des coordonnées differentes :

pour 0,0 et 159,99,
- vti : 917 ; 924
- 89 hw2 : 1280.8 ; 1278.4 ; 1278.2 ; 1282.6

>Et il faut que ta routine supporte A_REVERSE, A_NORMAL/A_REPALCE, et A_XOR (qui est pas forcément facile à implenter)
oué, oué, je sais, mais à la base g pas ecrit cette routine pour le *concours*, mais pour tout autre chose, et j'av pas besoin des differents modes de dessin..
bon, je v voir ça tout à l'heure.

quel concours ?

Pen^2 : les 3 points restent valables (c'est fait pour être exécuté sur calto au final), surtout le 1

g rajouté le support de A_NORMAL/A_REPLACE, A_REVERSE et A_XOR.
Voici les nouveaux benchs : (pour 0,0 & 159,99)

	- VTI 100%	: 919.6 ; 921.2 ; 914 ; 915.6
	- 89 HW2	: 1271.6 ; 1280.6 ; 1281.6 ; 1271.6 ; 1273

nouvelle src (ac le passage du mode de dessin) :

;© 2002 By Julien MONVILLE


	Include	"tios.h"
	Include	"filelib.h"
	Include	"graphlib.h"
	Include	"userlib.h"
	Include	"ziplib.h"

	Xdef	_main
	Xdef	_ti89
	Xdef	_ti92plus
	Xdef	_comment
	Xdef	_install_preos





;#######################################

BENCH Set 1
_89 Set 1
;_92 Set 1



USER_TIMER	Equ 6
NB_SEC		Equ 5
A_NORMAL	Equ $F0
A_REPLACE	Equ $F0
A_REVERSE	Equ $B0
A_XOR		Equ $70


XI	Equ	0
YI	Equ	0
XF	Equ	159
YF	Equ	99

;#######################################



_main:
	
	IfD BENCH
		move.w		#$400,d0
		trap		#1
		move.w		d0,oldsr
		moveq		#0,d7
		pea		NB_SEC*20
		move.w		#USER_TIMER,-(a7)
		jsr		tios::OSFreeTimer
		jsr		tios::OSRegisterTimer
	bench_loop:
	EndIf

	move.w		#XI,d0	;xi
	move.w		#YI,d1	;yi
	move.w		#XF,d2	;xf
	move.w		#YF,d3	;yf
	move.b		#A_XOR,d6 ;A_XXXXX
	bsr		drawLine

	IfD BENCH
		addq.w		#1,d7
		jsr		tios::OSTimerExpired
		tst.w		d0
		beq.s		bench_loop
		
	exit:	jsr		graphlib::clr_scr
		addq.w		#6,a7
		move.w		oldsr,d0
		trap		#1
		move.l		d7,-(a7)					;d7.w = nb de segments
		pea.l		output
		pea.l		buffer
		jsr		tios::sprintf
		lea		12(a7),a7
		SetFont		#1
		WriteStr	#2,#40,#4,buffer				;89
		jsr		tios::GKeyFlush				;ras le bol de quitter trop vite #mad#
		jsr		userlib::idle_loop
	EndIf
	
	rts
		
	IfD BENCH
		oldsr:		dc.w	0
		output:		dc.b	"nb de segments : %lu !",0
		buffer:		ds.b	32
		Even
	EndIf

PS
ExtendeD>qui est pas forcément facile à implenter
heu, soit g pas compris qq chose, soit on n'a pas implementé ça de la meme manière : ça m'a pris exactement 2 lignes de plus (hors de la boucle principale) :
A_XOR <=> inversion du pixel
A_NORMAL/A_REPLACE <=> armement du pixel
A_REVERSE <=> desarmement du pixel
C bien ça que vous entendez par A_XXX ?

Thibaut a écrit :
1- Il tourne sur un OS multitâches, donc d'une seconde à l'autre il n'y a pas le même nombre de cycles émulés.

2- En plus, rien ne dit que l'émulateur du processeur exécute bien toutes les instructions pendant le nombre de cycles préconisé par Motorola

3- Sur vraie TI HW1, l'accès à la RAM vidéo est plus lent que l'accès à la RAM tout-court.

1 - sur 30 secondes la moyenne est assurement representative
2 - on a tous la meme version (quoique.. enfin au moins à ce niveau je pense)
3 - g pas de HW1, donc ..

fabetal
a écrit : quel concours ?

je voulais juste parler des differents bench postés ici.

heu, soit g pas compris qq chose, soit on n'a pas implementé ça de la meme manière : ça m'a pris exactement 2 lignes de plus (hors de la boucle principale)

Mmm, j'ai dû faire du code auto-modifiant, c'était pas facile à faire. Et il y avait tellement de patchs que j'ai fait une table de patchs.

Finalement, quelle taille fait ta routine ?

Pen^2 : bon et ******* c'est pour quand ?