'Drag and drop' sur n'importe quel Atari ? - Page 2

de toute façon au niveau dev y'a pas besoin de se torturer les méninges : il y a du public à tout niveau. Certains ont un falcon de base, les jeux codés "à la demomaker" sont
biens pour eux. D'autres ont des falcons boostés (ct60/63, Eclipse), et des bureaux de la mort qui tue. Ces derniers préfèrent ce qui est Gem (et compatible si
possible).

Nous connaissons tous la lenteur du Gem et des bureaux dérivés (affichage par ex). Alors pourquoi vouloir tenter de lutter contre ça ? Rendons à César ce qui
est à César, et développons ce que bon nous semble, soit sous Gem, soit sous Tos de base. Faudra voir dès l'arrivée du supervidel (s'il arrive) si l'on peut inverser
cette tendance, mais pour le moment ce n'est (à mon avis) pas le cas. Je le pète et le repète, il y a des users sur falc de base, sur STe, ou sur Falcon boosté. Donc
codons -au moins- pour une partie d'entre eux

Ce n'était que mon petit point de vue.

GT en train de réunifier tout le monde

Sinon, on peut faire des jeux en reseau qui nécessitent un Falcon 14Mo de STRAM, 512Mo de TTRAM boosté avec une CT60@100Mhz et un 520 ST de base histoire de faire jouer tout les utilisateurs en même temps

Zorro270 :
Petite parenthése, NE JAMAIS utiliser GCC si on ne compile pas pour minimum un 68020 avec bus 32 bits!

Je n'ai absolument aucun problème pour compiler du code 68000 avec gcc. SDL est compilé pour 68000 pour la version de base.

Meme sur Falcon j'avais laissé tombé Pure C devant la faible qualité du code assembleur produit, je préférais avoir un meilleur code avec gcc, meme si la compilation etait beaucoup plus longue.

En plus, Pure C contient des relents du TurboC X86:
- limite la taille d'un tableau à 64Ko.
- Si on lit un cookie (entier long), et qu'on le place dans un pointeur (void *), la valeur est multipliée par 16. Je ne sais plus si c'est dans ce cas ou un autre, mais j'avais halluciné en voyant ça dans le Pure Debugger.

pmandin :
Je n'ai absolument aucun problème pour compiler du code 68000 avec gcc. SDL est compilé pour 68000 pour la version de base.

Le problème, ce n'est pas qu'il y ait des 'problémes' mais que ce n'est pas du tout approprié parceque:

1) GCC passe ses paramétre par la pile et non pas les registres ce qui fait que si tu as un truc du genre:

int32 faire_calcul( int32 x, int32 y)
{
return ((x+y) >> 2);
}

void toto ( void)
{
register int32 i;

for( i = 0; i <= 1000
{
i += faire_calcul( 16L, 32L);
}
}

C'est BEAUCOUP plus rapide avec PureC.

Sur CT60, on ne voit pas trop la différence, mais sur machine avec RAM lente et interfacé en 16bits comme un falcon de base, on sent vraiment une lourdeur dans le code généré.


2) un 'int' standard fait 4 bytes avec GCC contre 2 sur PureC. Outre le probléme d'occupation mémoire lorsqu'on a beaucoup de variables, il y a une légére perte de performance si l'on joue beaucoup avec celles-ci. (minime, certe)

3) les executables pondus avec GCC sont, AU BAS MOT, 4 fois plus gros qu'avec PureC.
A titre d'exemple, mon JPG.LDG fait plus ou moins 130Ko avec GCC et 37Ko avec PureC.

Juste à cause du point 1, si ton code est exclusivement destiné à tourner sur falcon de base, il est impossible d'engendrer une application plus rapide avec GCC que PureC.

Maintenant, si tu parles de machines avec bus mémoire 32 bits et CPU puissant, on est d'accord, GCC est largement supérieur à PureC. c'est pour celà que je l'ai choisit d'ailleur.

pmandin :
Meme sur Falcon j'avais laissé tombé Pure C devant la faible qualité du code assembleur produit, je préférais avoir un meilleur code avec gcc, meme si la compilation etait beaucoup plus longue.

N'ayant jamais utilisé de debugger de ma vie, je ne connais pas le code asm produit par PureC mais il est l'air trés bon vu que la boucle que je t'ai mis plus haut est plus rapide avec PureC.

Maintenant, chaque code à ses spécificité, si l'on parle de calculs lourd genre decodage JPG, oui, le code généré par GCC est meilleurs ( de l'ordre de 20% sur une CT60).

pmandin :
En plus, Pure C contient des relents du TurboC X86:
- limite la taille d'un tableau à 64Ko.
- Si on lit un cookie (entier long), et qu'on le place dans un pointeur (void *), la valeur est multipliée par 16. Je ne sais plus si c'est dans ce cas ou un autre, mais j'avais halluciné en voyant ça dans le Pure Debugger.

Je suis d'accord avec toi, PureC a beaucoup de default; c'est d'ailleur la raison qui m'a fait passé à GCC ( la CT60 surtout).

Pour la taille des tableaux, tu parles de tableaux statique ou dynamique?

A+
Zorro

cooper :
de toute façon au niveau dev y'a pas besoin de se torturer les méninges : il y a du public à tout niveau. Certains ont un falcon de base, les jeux codés "à la demomaker" sont
biens pour eux. D'autres ont des falcons boostés (ct60/63, Eclipse), et des bureaux de la mort qui tue. Ces derniers préfèrent ce qui est Gem (et compatible si possible).

Je suis d'accord avec tout ce que tu dis sauf je suis contre les jeux "d'action" GEM ( sauf dans le cas d'un démineur ou d'un emulateur bien sur).

Non vraiment, le code "qui tape dans le hard" ne me dérange pas du tout mais il faut le faire proprement... comme les démos de DHS par exemple.

Patrice Mandin fournit du code pour comprendre comment taper proprement dans le hard, il suffit de ce servir.

Quand je dis "proprement", je pense surtout que lorsque l'on quitte le jeu/demo, on revient sur le bureau tel que l'on l'a laissé, aussi bien dans la résolution que niveau mémoire.

C'est toujours trés chiant de devoir rebooter aprés avoir essayé une demo.

Maintenant, encore une fois, chacun fait ce qu'il veut, je donne juste mon avis.. si je puis me le permettre

A+
Zorro

Zorro270 :

Tu as vu le petit film de Xerus?

http://falcon060.free.fr/

Mouaif, Quake à 5fps avec deux ennemis à l'écran, c'est pas probant probant, si vous voulez mon humble avis.

C'est déjà ça, au moins on peut dire qu'on a Quake sur Atari, plutôt que de baisser continuellement la tête face au Amigaïstes et leurs cartes PPC (qui fait tourner Quake plus vite, certes)... C'est déjà un départ !

Kochise

Zorro270 :
1) GCC passe ses paramétre par la pile et non pas les registres ce qui fait que si tu as un truc du genre:

int32 faire_calcul( int32 x, int32 y)
{
return ((x+y) >> 2);
}

void toto ( void)
{
register int32 i;

for( i = 0; i <= 1000
{
i += faire_calcul( 16L, 32L);
}
}

C'est BEAUCOUP plus rapide avec PureC.

Compilation standard avec gcc:

_faire_calcul:
	link a6,#0
	movel a6@(8),d0
	addl a6@(12),d0
	asrl #2,d0
	unlk a6
	rts
_toto:
	link a6,#-4
	clrl a6@(-4)
L3:
	cmpl #1000,a6@(-4)
	jle L6
	jra L2
	.even
L6:
	pea 32:w
	pea 16:w
	jbsr _faire_calcul
	addql #8,sp
	addl d0,a6@(-4)
	jra L3
	.even
L2:
	unlk a6
	rts

Compilation avec -O2 -fomit-frame-pointer (flags standards pour optimisation sur m68k):

_faire_calcul:
	movel sp@(4),d0
	addl sp@(8),d0
	asrl #2,d0
	rts
_toto:
	movel d2,sp@-
	moveq #0,d2
	pea 32:w
	pea 16:w
	jbsr _faire_calcul
	addql #8,sp
	.even
L7:
	addl d0,d2

	cmpl #1000,d2
	jle L7
	movel sp@+,d2
	rts

Je trouve le code plus que convenable dans ce cas. Pourrais-tu donner le source Pure C correspondant, pour comparer ?

2) un 'int' standard fait 4 bytes avec GCC contre 2 sur PureC. Outre le probléme d'occupation mémoire lorsqu'on a beaucoup de variables, il y a une légére perte de performance si l'on joue beaucoup avec celles-ci. (minime, certe)

Normalement, les variables se trouvent soient dans les registres, donc la taille n'est pas un problème, ou bien sur la pile (où là il y a effectivement plus grande consommation de mémoire).

3) les executables pondus avec GCC sont, AU BAS MOT, 4 fois plus gros qu'avec PureC.
A titre d'exemple, mon JPG.LDG fait plus ou moins 130Ko avec GCC et 37Ko avec PureC.

Est-ce que tu as comparé la taille des fichiers objets générés, plutot que le fichier final, qui contient le code des librairies utilisées ? Un simple printf() dans un programme ajoute 90Ko de code venant de la mintlib.

Pour la taille des tableaux, tu parles de tableaux statique ou dynamique?

Tableau statique. Dans Doom (la version originale), il y avait une table de cosinus, qui faisait 64Ko. PureC ne voulait pas le compiler, tableau trop gros.

cooper :
de toute façon au niveau dev y'a pas besoin de se torturer les méninges : il y a du public à tout niveau. Certains ont un falcon de base, les jeux codés "à la demomaker" sont
biens pour eux.
.

GT en train de réunifier tout le monde

Salut Coopy,

Pendant un moment je pensais que t'étais mort, j'ai failli t'appelé ce week end !

Deux questions Coopy :

- meme si certain on des Falcon boostés ne pas oublié une chose, ce n'est toujours que 100 Mhz, et on adapte des jeux PC qui tourne sur des machines a la base avec une vitesse minimun de presque 1 Giga (Je peux me trompé sur la vitesse mini, veuillez m'en excusé je ne connais pas trop le monde PC !). Donc utilisation du jeu en fenetre, genre ma machine est trop puissante, c'est limite a avalé !!

Imagine un vrai jeu Falcon CT60 a 100 Mhz, a la façon démomaker, tu crois pas que cela donnerai autre chose ?

- tu te vois pourrir les dessins des graphistes en les encadrant d'une superbe fenetre ? Comme mettre un Van gogh dans un cadre en plastique acheté chez Gifi.
Meme si ont avait les machines qui permettrait d'évité le style démo, hors de question de mettre cela dans une fenetre !!

Dans certains cas cela peut se faire et meme très bien (Voir Dgem de notre ami Rajah) mais dans beaucoup de cas non ! Prend un autre truc concernant les fenetres, excepté en True Colour, si tu changes la palette, la bordure de la fénètre change de couleur, un super graphe encadré par une fénètre rose Twingo, cela détend un peu !!


GT Turbo ( )

Et si tu ouvres une fenêtre sans attributs à la résolution de ton écran ?
Pas de bordures qui changent de couleurs, pas de bureau dans le fond...
Un vieil exemple, c'est le casse brique Walz, en jouant en 320x200, il prend tout l'écran (sauf le menu peut-être), dans une résolution supérieure, il est dans une fenêtre de 320x200 (avec attributs). L'exemple n'est pas forcément bon, car qui irait jouer à un casse-brique 320x200 dasn une résolution 1600x1200, mais bon, c'est pour illustrer le plein écran.
Ou comme l'a dit Zorro plus haut : tu fais ce que tu veux, mais tu rends le bureau comme tu l'as pris.

pmandin :

_faire_calcul:
	movel sp@(4),d0
	addl sp@(8),d0
	asrl #2,d0
	rts
_toto:
	movel d2,sp@-
	moveq #0,d2
	pea 32:w
	pea 16:w
	jbsr _faire_calcul
	addql #8,sp
	.even
L7:
	addl d0,d2

	cmpl #1000,d2
	jle L7
	movel sp@+,d2
	rts

Voilà avec PureC compilé en mode 68000.

faire_ca:
		move.l	D0,D2
		add.l		D1,D2
		asr.l		#2,D2
		move.l	D2,D0
		rts         
main:	
		move.l	D3,-(SP)
		moveq		#0,D3
		bra.b		T_192
T_188:
		moveq		#$20,D1
		moveq		#$10,D0
		bsr.w		faire_ca
		add.l		D0,D3
T_192:	
		cmp.l		#$3E8,D3
		ble.b		T_188
		clr.w		D0
		move.l	(SP)+,D3
		rts     

Voilà, comme un con, j'ai donné un mauvais exemple parceque si les entrées de faire_calcul() ne change pas, cette fonction renvoie toujours la même valeur.. et GCC a la décence de s'en rendre compte.

Qu'en est-il si faire_calcul() utilise des données de type random? je ne sais pas... mais tu ne peux pas nier que le fait que tout se passe dans les registres avec PureC lui procure un certain avantage sur machine avec RAM lente.

Est-ce que tu as comparé la taille des fichiers objets générés, plutot que le fichier final, qui contient le code des librairies utilisées ? Un simple printf() dans un programme ajoute 90Ko de code venant de la mintlib.

A ma connaissance, la GEMLIB n'utilise aucune fonction Libc et elle fait 183Ko dans sa version GCC et 61Ko pour PureC.

Tableau statique. Dans Doom (la version originale), il y avait une table de cosinus, qui faisait 64Ko. PureC ne voulait pas le compiler, tableau trop gros.

C'est un probléme... mais quelle idée d'utiliser un tableau statique de cette taille ! comme quoi, même les meilleurs code parfois comme des gorets

A+
Zorro

RaZ :
Mouaif, Quake à 5fps avec deux ennemis à l'écran, c'est pas probant probant, si vous voulez mon humble avis.

Etant donné que la CT60 de Xerus n'est pas à sa pleine vitesse ( 72Mhz), étant donné qu'il y a du C2P entre chaque image et étant donné que le videl est d'une lenteur exaspérante, je trouve ça techniquement TRES probant.

Hier soir, j'ai fait le test avec Xerus sur ma CT60@100 + eclipse.. en 320*200, j'ai une MOYENNE de 51 images/seconde...

Et oui, dés qu'on ne joue plus avec la ST_RAM et qu'on a plus besoin du C2P, c'est nettement mieux.

Tu trouves ça probant ou pas?

A+
Zorro

C'est dans ce genre de cas qu'on voit tout suite que la SuperVidel sera d'un grand secours, en espérant qu'elle sorte bien sûr...
Sinon sur la vidéo c'est pas du 5 FPS en moyenne, à 72 MHz ça doit osciller entre 7 (le pire des cas) et 20 FPS, enfin de tête.

Et puis selon les players le mpg peut pedre des frames, sur mon PC ça passe bien avec Mplayer et mal avec WindowsMediaPlayer.

Zorro270 :
Voilà, comme un con, j'ai donné un mauvais exemple parceque si les entrées de faire_calcul() ne change pas, cette fonction renvoie toujours la même valeur.. et GCC a la décence de s'en rendre compte.

Oui si on utilise inline pour la fonction, gcc remplace l'appel par le code de la fonction, et comme on a des constantes, il ne reste plus que le résultat.

Qu'en est-il si faire_calcul() utilise des données de type random? je ne sais pas... mais tu ne peux pas nier que le fait que tout se passe dans les registres avec PureC lui procure un certain avantage sur machine avec RAM lente.

En fait ça dépend de la convention d'appel: gcc utilise la convention cdecl. Si tu déclares cdecl ta fonction, Pure C devrait empiler les paramètres dans la pile.

Xerus :
Sinon sur la vidéo c'est pas du 5 FPS en moyenne, à 72 MHz ça doit osciller entre 7 (le pire des cas) et 20 FPS, enfin de tête.

Et puis selon les players le mpg peut pedre des frames, sur mon PC ça passe bien avec Mplayer et mal avec WindowsMediaPlayer.

Je n'ai pas dis parler de moyenne, je signalais un détail et je ne me basais pas sur la vitesse de lecture du player, je travaille à l'oeil, moi môssieur. La preuve.

J'ai déjà voulu donner mon point de vue à propos de ce débat mais j'ai tendance à ne pas me meler de ce genre d'échanges en général. Surtout vu mes lacunes techniques.
Toujours est il que je trouve le débat bancal actuellement.

C'est partie d'un énième troll sur le C de mon coder de frère et ça à basculé sur le fait de privilégier une certaines visions de la programmation avec d'un coté les défenseurs du plus petit dénominateur commun et de l'autre les super-élitistes... Sans basculer dans la pirouette des gouts et des couleurs, tout cela reste à voir.

Je voulais, à la base, juste répondre à la remarque de Kochise :

C'est déjà ça, au moins on peut dire qu'on a Quake sur Atari, plutôt que de baisser continuellement la tête face au Amigaïstes et leurs cartes PPC (qui fait tourner Quake plus vite, certes)... C'est déjà un départ !

En faisant remarquer que faire tourner Quake à 5fps, c'est risquer d'autant plus les quolibets des défenseurs des autres plate-formes...
Mais on me signalait ensuite que le jeu pouvait tourner à 51fps, c'est beaucoup mieux, mais sur du matos que je ne connais même pas. Ca me laisse circonspect.

Le matos que tu ne connais pas existe depuis des années sur Falcon, avant même que le PCI fasse son apparition dans le monde Amiga, comme quoi on était pas à la bourg à tous les niveaux.
Le package de Zorro fait en sorte partie des solutions existantes sur Falcon pour se passer du Videl, comme les cartes Nova mais sans le pont PCI pour ces dernières.
Après de quolibets je pense qu'à part des ignorants il y en aurait pas simplement parce qu'il n'existe pas d'équivalent en perfs sur une architecture 68K; j'ai rien vu de tel (pour un portage) avec des cartes 060 sur Amiga ou celle existante sur X68000.

Maintenant pour m’immiscer dans le débat je dirais que c'est très bien de penser à faire un jeu multi-plateforme mais le plus judicieux est à mon avis, quand on a les moyens (Falcon) et les capacités (comme votre groupe) c'est de se baser sur celles qui offrent le plus de possibilités (ça aide aussi à la créativité), celle qui permet d'en mettre plein la vue !

Si pour un jeu comme Pooz ça n'a pas vraiment d'incidence, pour un shoot (si vous avez envie de mener à bien ce "projet") je trouve ça dommageable de partir sur une base STE.
On va se retrouver comme un Chuchu Rocket des RG, un très bon jeu, plus fluide sur Falcon vu son Blitter à 16MHz mais avec du son et des gfx qui font tout sauf penser à un jeu pour le rapace (une énième frustration) alors qu'ils auraient pu faire avec un peu plus de temps quelque chose approchant la version originale sur Dreamcast (on ne tenant pas compte de la 3D).
Par exemple rien que pour les GFX aujourd'hui on a des outils qui facilitent grandement le passage de graphismes en hi color ou 256 couleurs vers du 16 couleurs.
Il y a tout à prouver sur Falcon (ça peut-être une motivation) alors que sur STE pas grand chose à mon sens, excepté peut-être un shoot horizontal ou un jeu de plateforme et encore, on arrivera jamais au niveau d'un jeu sur un Amiga; alors qu'avec un Falcon il y a tout ce qui faut pour s'approcher d'une borne d'arcade et encore plus si on tient compte de ceux qui sont accélérés (la plupart de ceux qui utilisent encore un Falcon).

on attend la démonstratiion de maître avec Chrome