Re: Supa Zazai Da sur atari ST, STe, Falcon030 !!!

[Zarnal]

Great!!! C'est pas sur Amiga que ça tournerait, tellement ya des boulettes ! 

Ironique la remarque ou l'Amiga ne peut il réellement égaler ou faire mieux ?

Great!!! C'est pas sur Amiga que ça tournerait, tellement ya des boulettes ! 

Je ne peux pas encore poster de lien, mais datastorm sur amiga affiche bien plus de choses et est à 50 fps contant .

Merci pour avoir parlé de ce jeu, je le connaissais pas. Ca date de 1988/89 : 
http://www.mobygames.com/game/datastorm
Je n'en avais aucun souvenir, surement que n'y avais pas joué à l'époque (ou pas eut pour être plus précis ).

@templeton: bravo pour ta version STE .

Pareil, mais j'ajoute aussi le Doc qui semble t il, si j'ai bien compris, à créé le moteur utilisé pour le jeu ?

En tout, la lecture de ce sujet était très intéressante, comme je m'en doutais.

Je ne peux pas encore poster de lien, mais datastorm sur Amiga affiche bien plus de choses et est à 50 fps contant .

@templeton: bravo pour ta version STE .

Merci toaster.
Par contre je ne suis pas persuadé que Datastorm affiche bien plus de choses, mais ce qui est certain... c'est qu'il tourne seulement en 25 FPS et pas constant en plus! 
Je viens d'y jouer sur mon miga, plus on progresse dans le jeu, et plus on observe des ralentissements. Le vaisseau n'est pas réactif, on sent bien qu'il y a une latence à cause des 25 images par secondes, et c'est amplifié par son inertie.
En plus, les particules de Datastorm ne collisionnent pas avec le joueur.

SupaZazai Atari/PC mouline comme un jeu d'arcade, c'est du 50 FPS constant ! C'était l'objectif.

Datastorm est verrouillé par le programmeur en 2VBL, donc 25 FPS, et en plus il n'arrive pas un maintenir le frame rate, on est pas dans l'esprit Arcade/Console   

Bref, Datastorm est disqualifié ! 25FPS pas constant pour un jeu d'arcade rapide, ce n'est pas acceptable! :p

Oui, enfin, c'est quand même pas juste, ce jeu date de 1989. La vidéo que j'ai vu sur youtube il avait l'air pas mal rapide quand même.

A propos, donc Supa Zazai Da version Amiga (avec peut être encore plus de tout) ça te parait possible ? Si un STE le fait, pourquoi un Amiga ne pourrait pas le faire ?

Je ne veux pas répondre, j'ai déjà fâché un codeur Amiga l'année dernière en donnant mon avis.
Mais tout le monde sait que sur Amiga tout est possible (essentiellement sur le papier).

Je sors mon seka ------->

[babsimov]

Je refuse que mon jeu soit porté sur Amiga, question d'honneur.

Un clone like alors ça passera ? Comme Zool avait été fait pour Sonic ?

C'est dommage ça te ferait des royalties, le marché Amiga est autrement plus conséquent...   

Autrement sérieusement, sans parler de portage, ça te parait techniquement réalisable sur Amiga ? Je suppose que tu connais quand un peu la programmation sur Amiga, c'est un 68000 aussi.

 @Zarnal

A propos, donc Supa Zazai Da version Amiga (avec peut être encore plus de tout) ça te parait possible ? Si un STE le fait, pourquoi un Amiga ne pourrait pas le faire ?

Je ne veux pas répondre, j'ai déjà fâché un codeur Amiga l'année dernière en donnant mon avis.
Mais tout le monde sait que sur Amiga tout est possible (essentiellement sur le papier).   

Je sors mon seka ------->

Tu veux donc sous entendre que ce n'est pas possible ? Si la routine est au 68000 et blitter, sachant que le blitter de l'Amiga est mieux, je vois pas en quoi ce serait impossible ? 

J'ai plus souvent vu des choses faites sur Amiga qui ne sont pas faisables sur Atari que l'inverse ? Sans vouloir offenser personne, c'était une simple question qui me semble légitime ?

EDIT : c'est peut être trop hors sujet ici, peut être sur le sujet VS alors ? Je m'excuse.

[chiss]

Bordel, Chiss, un 1040 STE 4Mega...  

en...é de riche  

acheté il y a 12 ans dans un cash avec son moniteur couleur stéréo , état comme neuf pour 60euros...

j'etait pas peu fier sur ce coup la !!

je lui ai rajouté 3 meg de ram venant d'un vieux pc.

[Templeton]

Pareil, mais j'ajoute aussi le Doc qui semble t il, si j'ai bien compris, à créé le moteur utilisé pour le jeu ?

Pour la version PC uniquement. Le ''Whittaker Engine 4,0'' est une blague du doc que j'ai conservé dans la version Atari, mais son moteur n'a rien à voir avec le mien, c'est le Tempinator engine 0.9b qui a été utilisé sur ST  

Tu veux donc sous entendre que ce n'est pas possible ? Si la routine est au 68000 et blitter, sachant que le blitter de l'Amiga est mieux, je vois pas en quoi ce serait impossible ? 

Dans Supa Zazai da sur Atari ,c'est le 68000 qui gère et affiche pratiquement tout. J'ai surtout utilisé le Blitter du Mega ST pour afficher les Boss et effacer un biplan, mais j'aurai très bien pu m'en passer.
J'avais planifié de faire tout au CPU à la fin du projet, mais lorsque j'ai terminé le ''sprite engine'', j'ai manqué de motivation... Je devais faire un petit outil pour transformer les datas graphiques des boss en code généré pre-shifté, mais avec mon poil dans la main...
Une bonne routine de sprite pré-décalé sera toujours plus rapide que le Blitter ST/Amiga.
Et pour afficher des petits sprites, il faut toujours bannir le Blitter sur ces deux machines.

Concernant le Blitter de l'Amiga meilleur que celui du ST, c'est une légende entretenue par certains fanboys de l'Amiga. En réalité, même si ils sont très différents, leurs performances sont très proches, parfois c'est à l'avantage de l'Atari parfois l'inverse.

Il y a certains domaines ou l'Atari sera toujours devant l'Amiga à cause de son CPU plus rapide comme l'affichage de points ou  les routines de tracées de lignes obliques par exemple. Il y a aussi l'organisation mémoire qui permet d'effectuer des C2P beaucoup plus efficace sur Atari que sur la machine de commodore, ou bien l'Overscan Horizontal en basse def plus large sur ST à cause de son pitch plus fin.
Mais quand il s’agit de faire des jeux 2D, l' Amiga battra toujours le ST à cause de ses sprites hardwares, ses 2 Biplans supplémentaire, le scroll Hardware, les canaux PCM , etc...

Supa Zazai est un cas particulier qui nécessite un usage très intensif du CPU, le seul domaine ou le ST est meilleur que l'Amiga.
Le problème dans ce jeu, c'est la gestion du nombre d’élément et des trajectoires, les collisions et l'effacement, l'affichage n'est pas la problématique (sur micro en tous cas ).

[babsimov]

Pareil, mais j'ajoute aussi le Doc qui semble t il, si j'ai bien compris, à créé le moteur utilisé pour le jeu ?

Pour la version PC uniquement. Le ''Whittaker Engine 4,0'' est une blague du doc que j'ai conservé dans la version Atari, mais son moteur n'a rien à voir avec le mien, c'est le Tempinator engine 0.9b qui a été utilisé sur ST   

Comment comment l'un des plus grand fan du ST ne programme pas sur ST, mais sur PC.. déception  (je plaisante)

Le tempinator 0.9b, j'aime bien le nom... avec en sous titre "i'll be back" ou "hasta la vista baby".

Tu veux donc sous entendre que ce n'est pas possible ? Si la routine est au 68000 et blitter, sachant que le blitter de l'Amiga est mieux, je vois pas en quoi ce serait impossible ?  

Dans Supa Zazai da sur Atari ,c'est le 68000 qui gère et affiche pratiquement tout. J'ai surtout utilisé le Blitter du Mega ST pour afficher les Boss et effacer un biplan, mais j'aurai très bien pu m'en passer.
J'avais planifié de faire tout au CPU à la fin du projet, mais lorsque j'ai terminé le ''sprite engine'', j'ai manqué de motivation... Je devais faire un petit outil pour transformer les datas graphiques des boss en code généré pre-shifté, mais avec mon poil dans la main...
Une bonne routine de sprite pré-décalé sera toujours plus rapide que le Blitter ST/Amiga.
Et pour afficher des petits sprites, il faut toujours bannir le Blitter sur ces deux machines.

"Excuses acceptées capitaine Needa"



C'est ma soirée référence cinéma on dirait  

Les excuses c'était pour ne pas avoir fait une version uniquement 68000 et te donner de la motivation, sinon tu vois ce qui risque d'arriver .
Alors peut être un jour une version ST alors, ou un autre jeux à la place ?   

Merci pour tes précisions sur les petits sprites et le blitter.

Concernant le Blitter de l'Amiga meilleur que celui du ST, c'est une légende entretenue par certains fanboys de l'Amiga. En réalité, même si ils sont très différents, leurs performances sont très proches, parfois c'est à l'avantage de l'Atari parfois l'inverse.

Tu me l'avais déjà dit d'ailleurs, mea culpa 

Il y a certains domaines ou l'Atari sera toujours devant l'Amiga à cause de son CPU plus rapide comme l'affichage de points ou  les routines de tracées de lignes obliques par exemple. Il y a aussi l'organisation mémoire qui permet d'effectuer des C2P beaucoup plus efficace sur Atari que sur la machine de commodore, ou bien l'Overscan Horizontal en basse def plus large sur ST à cause de son pitch plus fin.
Mais quand il s’agit de faire des jeux 2D, l' Amiga battra toujours le ST à cause de ses sprites hardwares, ses 2 Biplans supplémentaire, le scroll Hardware, les canaux PCM , etc...

Supa Zazai est un cas particulier qui nécessite un usage très intensif du CPU, le seul domaine ou le ST est meilleur que l'Amiga. 
Le problème dans ce jeu, c'est la gestion du nombre d’élément et des trajectoires, les collisions et l'effacement, l'affichage n'est pas la problématique (sur micro en tous cas  ).

Donc si je comprends bien, selon tes connaissances, une version Amiga seraient moins réussies ? Les sprites de l'Amiga ne pourraient pas aider et compenser les quelques hz en moins de l'Amiga ?

[Invité]

super boulout templeton

[Templeton]

super boulout templeton

Merci :)

Donc si je comprends bien, selon tes connaissances, une version Amiga seraient moins réussies ? Les sprites de l'Amiga ne pourraient pas aider et compenser les quelques hz en moins de l'Amiga ?

Contrairement à ce qu'on pourrait croire, les 8 sprites en 3 couleurs de l'Amiga bouffent des cycles.
Avant d'arriver au boss, les sprites hard seront moins utiles, mais en les utilisant pour afficher les boss on pourrait gratter des cycles, ça pourrait aider la perte du nombres de boulettes et de particules.
Faudrait essayer pour voir si ca compense une grosse partie.
Mais le problème c'est qu'il faut réécrire tout le ''sprite engine'', l'affichage des boulettes +particules ( et l'effacement de ces dernières) au 68000 est lié aussi à l'entrelacement spécial de la mémoire du ST. Ça se trouve, cette partie serait encore moins efficace sur Amiga une fois réécrite... ou pas !

Enfin c'est juste un nœud du problème (et le plus petit). Sur Néo Géo, lorsque Last Resort ralenti, ce n'est pas à cause de sa capacité à afficher des sprites, mais à cause du 68000. C'est bien beau de pouvoir afficher presque 400 sprites, faut-il encore pouvoir les gérer.  
Le principal problème dans un Manic Shooter c'est le CPU.

En tous cas, rassures toi, l'Amiga restera toujours devant l'Atari (même le STe) pour les jeux 2D, c'est juste un cas particulier.
Ceux qui pensent qu'ont pourrais faire un Shadow of the beast sur ST avec 1 mo aussi bien que sur Amiga se trompent lourdement (même sur STe). Faut pas croire tout ce que racontent les programmeurs

[Tryphon]

C'est quoi la différence entre les boulettes et les particules au niveau affichage ?

[drfloyd]

Vu les débats passionnés autour du jeu, je pense faire une pause de 1 mois sur COSMOS apres la sortie de la version 0.7 pour pondre SUPA ZAZAI FOREVER... car je ne suis pas du tout allez au bout de ce que je voulais faire, il faut que je me lache 

[babsimov]

Donc si je comprends bien, selon tes connaissances, une version Amiga seraient moins réussies ? Les sprites de l'Amiga ne pourraient pas aider et compenser les quelques hz en moins de l'Amiga ?

Contrairement à ce qu'on pourrait croire, les 8 sprites en 3 couleurs de l'Amiga bouffent des cycles.
Avant d'arriver au boss, les sprites hard seront moins utiles, mais en les utilisant pour afficher les boss on pourrait gratter des cycles, ça pourrait aider la perte du nombres de boulettes et de particules.
Faudrait essayer pour voir si ca compense une grosse partie.

Mais le problème c'est qu'il faut réécrire tout le ''sprite engine'', l'affichage des boulettes +particules ( et l'effacement de ces dernières) au 68000 est lié aussi à l'entrelacement spécial de la mémoire du ST. Ça se trouve, cette partie serait encore moins efficace sur Amiga une fois réécrite... ou pas !  

Je savais pas pour les cycles. Mais, je voudrais pas trop poser de questions pour pas être trop hors sujet et laisser tout sa place à ton travail et au jeu. 
Te tracasse pas trop, Doc a refusé tout net un portage   

Cet entrelacement à l'air en tout cas bien pratique pour faire des prouesses sur ST (notamment en chunky to  planar), c'est un point positif pour le ST.

Enfin c'est juste un nœud du problème (et le plus petit). Sur Néo Géo, lorsque Last Resort ralenti, ce n'est pas à cause de sa capacité à afficher des sprites, mais à cause du 68000. C'est bien beau de pouvoir afficher presque 400 sprites, faut-il encore pouvoir les gérer.   
Le principal problème dans un Manic Shooter c'est le CPU.

Il y a aussi peut être la taille des sprites qui entre en compte ? 

En tous cas, rassures toi, l'Amiga restera toujours devant l'Atari (même le STe) pour les jeux 2D, c'est juste un cas particulier.

Je commençais à avoir des sueurs froides... 
Merci en tout cas, j'ai appris plein de choses en lisant ce sujet. 

Ceux qui pensent qu'ont pourrais faire un Shadow of the beast sur ST avec 1 mo aussi bien que sur Amiga se trompent lourdement (même sur STe). Faut pas croire tout ce que racontent les programmeurs 

Ah oui y aurais des programmeurs qui racontent n'importe quoi ? 

[drfloyd]

adaptez mon jeu sur Amiga et on en parle plus, bordel de sprites !!!!! 

[Invité]

si j'ai bien tout compris ce qu'a dit templeton c'est du tout 68000. ce serait réutilisable sur une MD, par exemple?

[babsimov]

adaptez mon jeu sur Amiga et on en parle plus, bordel de sprites !!!!! 

Tu vois tu t'y fait à l'idée au final 

[babsimov]

si j'ai bien tout compris ce qu'a dit templeton c'est du tout 68000. ce serait réutilisable sur une MD, par exemple?

Non, surement pas, le ST n'est pas une console voyons !  

(c'est une plaisanterie, je précise, j'ai rien contre la MD...) et ta question est très intéressante en fait.

[Tryphon]

Non. L'affichage n'est pas du tout organisé de la même façon.

La MD est conçue pour afficher des tiles et des sprites.

Le ST, je suppose, fonctionne avec un framebuffer (une "copie" de l'écran dans la RAM) où tu peux adresser les pixels un par un.

C'est pas impossible sur MD, mais beaucoup plus coûteux en temps CPU et en temps de transfert RAM -> VDP. Ajoute à ça que le 68000 de la MD est un poil plus lent que celui du ST, et je doute vraiment que ça soit réalisable.

Peut-être à demi-résolution (160x224). J'essaierai un jour...

[babsimov]

Non. L'affichage n'est pas du tout organisé de la même façon.

La MD est conçue pour afficher des tiles et des sprites.

Le ST, je suppose, fonctionne avec un framebuffer (une "copie" de l'écran dans la RAM) où tu peux adresser les pixels un par un.

C'est pas impossible sur MD, mais beaucoup plus coûteux en temps CPU et en temps de transfert RAM -> VDP. Ajoute à ça que le 68000 de la MD est un poil plus lent que celui du ST, et je doute vraiment que ça soit réalisable.

Peut-être à demi-résolution (160x224). J'essaierai un jour...

Il est vraiment super intéressant ce sujet, j'ai bien fait de venir le lire. On y apprend plein de choses.

[Templeton]

Le ST, je suppose, fonctionne avec un framebuffer (une "copie" de l'écran dans la RAM) où tu peux adresser les pixels un par un.

Pour le frame Buffer, Tryphon a raison, c'est le principe.
Par contre, tu n'as pas d'adresse pour chaque pixel mais... une adresse pour 16 pixels !
Donc 20 adresses sur une ligne de 320 pixels pour 1 biplan.

[Invité]

Le SGDK possède un mode "BitMap" avec double Frame Buffer, par contre, ça coute 40 Ko RAM à la pesée !
Mais on peut faire des trucs sympa :

[Stef]

SGDK propose effectivement un mode bitmap "software" mais bon du coup c'est plutot assez lent, on ne peut pas dépasser 20 FPS en NTSC et 25 FPS en PAL juste à cause de la conversion du frame buffer et le transfert en VRAM (et ce, avec une résolution de 256x160 seulement).

Sinon il y a une belle curiosité sur MD, c'est la compilation Williams :




C'est une compilation des hits d'arcade de Williams, de vieux jeux d'arcade dont le rendu est très basé sur le pixel et non sur les plans + sprites, du coup pour réaliser ça sur MD ils n'ont eu d'autres choix que de réaliser un moteur de rendu sur le pixel (plus ou moins) et il faut admettre que le résultat est assez convainquant :)
Il vaut mieux l'essayer sur la vraie console ou émulateur pour se rendre compte, mais le rendu est vraiment fluide, le frame rate oscille entre 60 FPS et 20 FPS selon la charge en sprites / particules mais globalement on retrouve bien les sensations de l'arcade !
Contrairement à SGDK, je pense qu'ils adressent directement la VRAM sans passer par un frame buffer en mémoire centrale, ce qui leur permet d'atteindre 60 FPS quand il n'y a pas trop de charge mais plus les scènes deviennent lourdes et plus ça coute forcément...

[Tryphon]

Peut-êter un système de "Dirty Rects" (enfin ici des dirty mots de 4 pixels), qui permettent de mettre à jour uniquement les zones modifiées.

[Stef]

Oui ça doit être ce genre de méthode... tu ne mets à jour que les parties modifiées, mais dans certains jeux (comme robotron ou les defender) il y a parfois beaucoup de zones à mettre à jour et ça tourne plutot bien, je trouve que cette méthode est un bon compromis pour ce genre de rendu :)
Pour un super ZaiZai sur MD, je pense que ça serait aussi le plus efficace pour la gestion des particules et des bullets, le reste pouvant être en sprite.

[Tryphon]

C'était mon idée (sprites pour vaisseaux et joueur, éventuellement deuxième bg pour les gros boss, et dirty rects pour particules et bullets ; c'est pour ça que je demandais à Templeton s'il gérait les bullets et les particules différemment). En plus je peux me servir du "framebuffer" pour tester rapidement les collisions. J'ai quand même peur que ce soit pas suffisant... (même en pur assembleur)

Edit : et merci pour la compil Williams, typiquement le genre de jeu qui ne m'intéressait pas du tout en tant que joueur, mais qui en effet valent le détour niveau codage. Idem pour le titre que tu as cité sur MegaCD dans le topic de la Mort !

[Zarnal]

J'ai une question : les boulettes sont à la vbl ? Je viens de faire un peu mumuse avec (hatari cyclé) et il semble que les boulettes toussent. C'est assez notable quand le boss explose : juste après, là, les boulettes sont à la frame. Je le remarque également sur la vidéo Youtube. Par contre je n'ai pas essayé sur du hard.

[drfloyd]

Par contre je n'ai pas essayé sur du hard.

ca serait pas l'explication ? 

[Templeton]

>>C'est quoi la différence entre les boulettes et les particules au niveau affichage ?

La routine d'affichage est globalement la même (code généré pré-décalé et optimisé à la main), par contre les routines d"effacements et les tests de collisions sont complètement differents.
Pour les 128 boulettes il n'y a que 8 tests de collisions au total (le rond central vert sur la blouse du doc), c'est une collision via une pseudo C2P au pixel près (un peu obligatoire pour le slalom devant les boss).
Les suppos, le starfield et les boulettes sont affectés au même biplan et sont effacés tous en même temps en une seul passe (ainsi qu'une partie des "sprites"), pas besoin de boucles du coup.
Pour les 128 particules qui sont isolées sur un autre plan, les tests de collisions concernent toute la surface utile du joueur et sont gérés en deux temps, c'est assez proche de la technique utilisé par Vetea.
Par contre, l'effacement de ces particules est effectué en même temps que l'affichage donc en une seul passe, elles s'auto-effacent en quelque sorte, bref une seul boucle au lieu de deux et deux fois moins de passage sur le buffer d'affichage.

>>Le SGDK possède un mode "BitMap" avec double Frame Buffer, par contre, ça coute 40 Ko RAM à la pesée ! Wink
Mais on peut faire des trucs sympa :

Frame buffer + zoom (rapide en plus), deux choses contre nature pour la Mégadrive, tu as l'âme d'un démomaker Vétéa dit donc!
Il est super ce zoom, c'est le genre d'effet qui impressionne toujours, il faudrait que tu l'utilises dans pépé commando, genre contre un boss qui tire des grenades en cloche ou avec un mortier ! même en 25 FPS ça peut le faire.  

>>Sinon il y a une belle curiosité sur MD, c'est la compilation Williams :

Vraiment intéressant, je pense que le programmeur n'avait pas le choix en fait car avec des sprites il y aurait eu surement des saturations par ligne, et les clignotements dans ce genre de jeux pourraient pénaliser vachement le joueur.

[Templeton]

J'ai une question : les boulettes sont à la vbl ? Je viens de faire un peu mumuse avec (hatari cyclé) et il semble que les boulettes toussent. C'est assez notable quand le boss explose : juste après, là, les boulettes sont à la frame. Je le remarque également sur la vidéo Youtube. Par contre je n'ai pas essayé sur du hard.

Alors tout est à la vbl dans le jeu et sans ralentissement, j'ai verrouillé le moteur pour ça.
Tu peux vérifier avec Steem plus facilement. En cliquant sur le bouton play avec le bouton droit tu peux faire défiler le jeu frame par frame.

Concernant les passages devant le boss, c'est une subtilité du gameplay et, qui montre à quel point le doc est sadique !
Le Boss arrive et envoie les boulettes lentement (ça facilite le déplacement du joueur entre les boulettes). Pendant cette phase, les boulettes se déplacent à chaques frames d'un pixel seulement. Mais dès que le Boss explose, le pas de déplacement des boulettes est accéléré par deux et donc elles se déplacent de deux pixels par frame.

Le doc  a voulu rajouter du stress au joueur, il faut gérer sont placement avant l'explosion du Boss, et augmenter sa vitesse de réaction. C'est vache je sais, moi je l'aurai bien retiré ce truc mais je ne voulais pas trahir la philosophie du doc.

[drfloyd]

tu as analysé à fond mon jeu c'est dingue !

[Templeton]

Je suis rentré dans ton cerveau, t'es un gros cochon dis donc !

[drfloyd]

Quoi t'es choqué par la Maria W. Engine 4.0 ? 

[JSR]

Je ne sais pas si cela a été mis ici (ou ailleurs)mais voici un peu de "pub".

http://mag.mo5.com/actu/132573/supa-zazai-da-un-shoot-em-up-delirant-sur-atari-st-et-falcon/

[Templeton]

Je ne sais pas si cela a été mis ici (ou ailleurs)mais voici un peu de "pub".

http://mag.mo5.com/actu/132573/supa-zazai-da-un-shoot-em-up-delirant-sur-atari-st-et-falcon/

Très cool, vive Guillaume Verdin !    
Je vais finir par rougir !