Re: GUERRE ST-AMIGA, FIGHT !!!

par **Zarnal** Jeu 9 Mar 2017 - 20:04

Ya un volontaire compétant pour une version st ? Mr. Green

GUERRE ST-AMIGA, FIGHT !!! - Page 4 517947

par dlfrsilver Jeu 9 Mar 2017 - 20:33

Zarnal a écrit:Ya un volontaire compétant pour une version st ?

Arrête, tu vas avoir des problèmes lol

par ryosaeba Dim 12 Mar 2017 - 8:14

Stapha92(ou quelqu'un d'autre) a-t-il confirmé l'optimalisation de SOS sur Amiga ?

par ryosaeba Dim 12 Mar 2017 - 8:15

Zarnal a écrit:Ya un volontaire compétant pour une version st ?

Je pense qu'il faudrait poser la question sur Atari-forum. Mais je doute que quelqu'un s'y emploi. Trop de travail pour aucun return a part le fait de l'avoir fait.

Peut-être voir avec les demomakers encore actif sur cette machine. Je pense que j'avais lu que SEB était en contact avec certains d'entre eux.

par **TotOOntHeMooN** Dim 12 Mar 2017 - 8:23

babsimov a écrit:C'est bien ce que je pensais, si un programmeur développe directement sur Amiga, c'est qu'il a une bonne connaissance de la machine et son architecture.

Et c'est pareil sur n'importe qu'elle autre machine.
Faire du cross dev, c'était surtout une histoire de moyen et de confort pour faire du multi-plateforme.

par babsimov Dim 12 Mar 2017 - 12:47

TotOOntHeMooN a écrit:
babsimov a écrit:C'est bien ce que je pensais, si un programmeur développe directement sur Amiga, c'est qu'il a une bonne connaissance de la machine et son architecture.
Et c'est pareil sur n'importe qu'elle autre machine.
Faire du cross dev, c'était surtout une histoire de moyen et de confort pour faire du multi-plateforme.

Je préfère quand même quand c'est développé sur la machine, c'est "plus authentique".

par Invité Dim 12 Mar 2017 - 12:49

Ouai mais c'est plus long(a moins d'avoir un amiga de guerre) .

par **TotOOntHeMooN** Dim 12 Mar 2017 - 12:49

babsimov a écrit:Je préfère quand même quand c'est développé sur la machine, c'est "plus authentique".

Ca, c'est une préocupation d'aujourd'hui... Pas de l'époque. Wink

par babsimov Dim 12 Mar 2017 - 12:50

TOUKO a écrit:Ouai mais c'est plus long .

Ouais, mais le résultat est mieux en général on dirait Wink

TotOOntHeMooN a écrit:
babsimov a écrit:Je préfère quand même quand c'est développé sur la machine, c'est "plus authentique".
Ca, c'est une préocupation d'aujourd'hui... Pas de l'époque.

Mais, pas du tout, c'était un choix du programmeur à l'époque qui préférait travailler sur sa machine préférée. Il suffit de voir Another World, il a tout fait sur Amiga, parce que la machine lui plaisait.

par **TotOOntHeMooN** Dim 12 Mar 2017 - 13:41

Il a tout fait sur Amiga parce qu'il était comme monsieur tout le monde chez lui et que la machique qu'il avait entre les mains et qu'il aimait lui permettait de faire son jeu dessus. Il n'y avait rien de professionnel dans sa modeste démarche et c'était loin d'être une généralité dans l'industrie, déjà dans les années 80/90 ou l'on segmentait les machines par architecture pour réaliser les différentes versions avec des kit de dev génériques.

par babsimov Dim 12 Mar 2017 - 14:04

TotOOntHeMooN a écrit:Il a tout fait sur Amiga parce qu'il était comme monsieur tout le monde chez lui et que la machique qu'il avait entre les mains et qu'il aimait lui permettait de faire son jeu dessus. Il n'y avait rien de professionnel dans sa modeste démarche et c'était loin d'être une généralité dans l'industrie, déjà dans les années 80/90 ou l'on segmentait les machines par architecture pour réaliser les différentes versions avec des kit de dev génériques.

Ben on dirait que non, il travaillait déjà chez Delphine Software et avait une bonne expérience de programmation depuis plusieurs années :

https://fr.wikipedia.org/wiki/%C3%89ric_Chahi

Pour le multiplateforme, ce n'est pas ce qui permet d'exploiter au maximum telle ou telle machine, en général c'est nivelé par le bas (la moins puissante de la même génération, comme on l'a finalement vu souvent sur Amiga avec les portages ST).

par **TotOOntHeMooN** Dim 12 Mar 2017 - 15:32

Le fait qu'il ait travaillé en freelance sur "Another World" n'exclus pas d'avoir eu un travaill précédemment... On se demande où tu vas chercher cet argument. De plus, il était graphiste sur un jeu cross-dev ST/Amiga !

Another World, n'est en rien "optimisé" pour l'Amiga, puisque les outils ont été créés en GFA BASIC sur Atari ST, machine sur laquelle il a commencé le jeu, avant d'acheter un "Amiga HD" pour plus de confort de travail.

Du coup, le fait que TU préfères que les jeux Amiga soient programmés sur Amiga est juste un jugement personnel qui ne reflète pas la pensé de l'époque... (passage de ST à Amiga ou Amiga à PC par besoin de perf)

par babsimov Dim 12 Mar 2017 - 15:51

TotOOntHeMooN a écrit:Le fait qu'il ait travaillé en freelance sur "Another World" n'exclus pas d'avoir eu un travaill précédemment... On se demande où tu vas chercher cet argument. De plus, il était graphiste sur un jeu cross-dev ST/Amiga !

Another World, n'est en rien "optimisé" pour l'Amiga, puisque les outils ont été créés en GFA BASIC sur Atari ST, machine sur laquelle il a commencé le jeu, avant d'acheter un "Amiga HD" pour plus de confort de travail.

Du coup, le fait que TU préfères que les jeux Amiga soient programmés sur Amiga est juste un jugement personnel qui ne reflète pas la pensé de l'époque... (passage de ST à Amiga ou Amiga à PC par besoin de perf)

C'est juste que j'avais mal compris ton propos, tu semblait dire que c'était son premier jeu.

Je me souvenais plus non plus qu'Another World avait été fait à partir d'outils en GFA.

Mais là, on nous dit que le moteur du jeu est en assembleur :

https://fr.wikipedia.org/wiki/Another_World_(jeu_vid%C3%A9o)

Je suis d'accord qu'à toutes les époques c'est le multiplateforme qui est privilégié. Mais, on voit bien quand même qu'un jeu programmé exclusivement pour une machine en tirait, en général, le meilleur (Shadow of the beast, les jeux Team 17 etc...). Ils ont ensuite été porté sur d'autres plateformes avec plus ou moins de succès, sauf erreur de ma part.

par **TotOOntHeMooN** Dim 12 Mar 2017 - 15:56

Je suis entièrement d'accord, ces jeux étaient en quelque sorte les AAA de l'époque, parce qu'ils étaient optimisés pour un hardware précis. Bref... Amiga sur Amiga, ça aide beaucoup, forcément.

par babsimov Dim 12 Mar 2017 - 16:11

TotOOntHeMooN a écrit:Je suis entièrement d'accord, ces jeux étaient en quelque sorte les AAA de l'époque, parce qu'ils étaient optimisés pour un hardware précis. Bref... Amiga sur Amiga, ça aide beaucoup, forcément.

Je pense que c'est valable un peu sur toutes les machines. Par exemple le Sword Of Sodan sur IIGS, je ne sais pas comment ils ont fait, mais le portage est très impressionnant, peut être que le programmeur à tout réécrit pour le IIGS (ce n'est pas du tout le même processeur que l'Amiga). En tout cas, c'est bluffant.

par Seb Dim 12 Mar 2017 - 17:05

Faire le test de Sword of Sodan sur ST n'aurait aucun intéret, on sait que ca serait plus lent sur ST que sur Amiga et ca serait beaucoup de travail.

Par contre essayer de refaire en plus rapide sur Amiga ce qui avait été fait à l'époque peut être intéressant avec les connaissances actuelles. Cela dit il ne faut négliger aucun élément de l'époque: RAM disponible, tests de collision, contraintes gameplay (certes vraiment faibles sur ce jeu) etc... Juste afficher le même nombre de sprites avec le scroll en disant "voilà on fait mieux" ne serait pas 100% probant, un jeu est un ensemble de contraintes, parfois nombreuses.

Pour ce qui est du dev en utilisant une autre plateforme, ca n'est ni élite, ni nul, c'est juste un choix avec ce qu'on a de disponible sur le moment pour être plus productif ou travailler avec un environnement de dev plus confortable.

Sur ST des demomakers et gamedev développaient leurs demos et jeux sur PC vers la fin de la grande époque, quand le PC a commencé à se démocratiser et que les tools ont progressé. C'était un gros gain de temps de compiler / assembler sur PC et envoyer le tout sur le ST, surtout que peu de gens sur ST avaient un disque dur, ce qui ralentissait aussi le processus.

Leonard d'Oxygene fait d'ailleurs comme ca, il a développé sa chaine d'outils pour faire ses demos sur PC si j'ai bonne mémoire.

par Seb Dim 12 Mar 2017 - 17:51

Un autre élément intéressant de développer sur PC une app ST ou Amiga: la mémoire.

Si on développe sur la machine cible, l'environnement de dev prend de la place en RAM (éditeur, debugger etc), place qui devient alors inutilisable pour la dite application (jeu, demo ou autre). On ne peut alors plus utiliser toute la RAM de facon optimale.

Par contre en développant sur une autre machine, on peut retrouver toute la mémoire disponible pour l'application qu'on développe puisque tout l'environnement de développement ne prend (presque) aucune place sur la machine cible.

C'est d'ailleurs pour ca qu'aujourd'hui encore, les devkits de consoles ont plus de mémoire que la vraie console. Ca permet d'avoir de la place additionnelle pour y mettre tout ce dont on a besoin sans que ca vienne manger de la mémoire qui deviendrait alors inutilisable pour le jeu. D'ailleurs même si le jeu est écrit et compilé sur PC avec Visual Studio en général, on a besoin de mémoire additionnelle sur le devkit pour diverses choses quand même.

Sur ST beaucoup de demomakers avaient 1 MB de RAM et faisaient leur demo ciblant les machines de base qui avaient 512 kb. De cette facon ils pouvaient en utiliser chaque octet disponible des 512 kb et avoir quand même de la place pour Devpac.

par babsimov Dim 12 Mar 2017 - 19:36

Merci Seb pour toutes ses précisions intéressantes.

par ryosaeba Dim 12 Mar 2017 - 19:49

Seb a écrit:Faire le test de Sword of Sodan sur ST n'aurait aucun intéret, on sait que ca serait plus lent sur ST que sur Amiga et ca serait beaucoup de travail.

Par contre essayer de refaire en plus rapide sur Amiga ce qui avait été fait à l'époque peut être intéressant avec les connaissances actuelles. Cela dit il ne faut négliger aucun élément de l'époque: RAM disponible, tests de collision, contraintes gameplay (certes vraiment faibles sur ce jeu) etc... Juste afficher le même nombre de sprites avec le scroll en disant "voilà on fait mieux" ne serait pas 100% probant, un jeu est un ensemble de contraintes, parfois nombreuses.

Pour ce qui est du dev en utilisant une autre plateforme, ca n'est ni élite, ni nul, c'est juste un choix avec ce qu'on a de disponible sur le moment pour être plus productif ou travailler avec un environnement de dev plus confortable.

Sur ST des demomakers et gamedev développaient leurs demos et jeux sur PC vers la fin de la grande époque, quand le PC a commencé à se démocratiser et que les tools ont progressé. C'était un gros gain de temps de compiler / assembler sur PC et envoyer le tout sur le ST, surtout que peu de gens sur ST avaient un disque dur, ce qui ralentissait aussi le processus.

Leonard d'Oxygene fait d'ailleurs comme ca, il a développé sa chaine d'outils pour faire ses demos sur PC si j'ai bonne mémoire.

Sur St, le jeu aurait-il été similaire à la version apple 2 GS ?

par Seb Dim 12 Mar 2017 - 19:56

Je ne sais pas pour 2 GS, je n'ai pas suivi tout le thread et je ne connais pas la machine, mais il aurait été significativement plus lent sut ST par rapport à la version Amiga, c'est certain, sauf si les dev Amiga ont fait une grosse erreur d'optim, ce dont je doute.

Je suis très surpris que ca tourne en 4 vbl, mais sans avoir essayé soi-même c'est difficile de porter un jugement, il peut y avoir plein de raisons, à commencer par la mémoire.

Pour donner un comparatif un peu éloigné mais qui donne une idée des problématiques mémoire / perf, sur Atari ST Enchanted Land tournait à 50 FPS en bouffant toute la mémoire "au delà du raisonnable". Résultat le jeu n'avait plus assez de mémoire pour avoir du double buffering donc les sprites étaient affichés dans un ordre bien précis et au bon moment pour éviter qu'ils clignotent. Ce genre de magouille bien chiante à gérer fonctionne sur un jeu avec des petits sprites comme ceux de Enchanted Land mais ne fonctionnerait jamais pour un jeu comme Sword Of Sodan.

Perf et mémoire sont généralement 2 éléments qui tirent sur la couverture dans des directions opposées Wink

Ca reste très vrai dans les jeux actuels d'ailleurs, je vois le problème presque tous les jours dans tous les domaines, graphique, gameplay, engine etc...

par Invité Dim 12 Mar 2017 - 20:30

Je ne sais pas pour 2 GS, je n'ai pas suivi tout le thread et je ne connais pas la machine, mais il aurait été significativement plus lent sut ST par rapport à la version Amiga, c'est certain, sauf si les dev Amiga ont fait une grosse erreur d'optim, ce dont je doute.

Erreur non, mais vu la sortie (88/89) je suis persuadé que l'on peut faire mieux .
L'année de sortie correspond avec le début de l'utilisation correcte du hardware amiga .
surtout qu'il tourne avec presque 1MO de RAM sur 2 GS et 512ko sur le mig .

par ryosaeba Dim 12 Mar 2017 - 21:22

je crois qu'une version C64 était également prévue.

par dlfrsilver Dim 12 Mar 2017 - 22:53

Seb a écrit:Je ne sais pas pour 2 GS, je n'ai pas suivi tout le thread et je ne connais pas la machine, mais il aurait été significativement plus lent sut ST par rapport à la version Amiga, c'est certain, sauf si les dev Amiga ont fait une grosse erreur d'optim, ce dont je doute.

Je suis très surpris que ca tourne en 4 vbl, mais sans avoir essayé soi-même c'est difficile de porter un jugement, il peut y avoir plein de raisons, à commencer par la mémoire.

Pour donner un comparatif un peu éloigné mais qui donne une idée des problématiques mémoire / perf, sur Atari ST Enchanted Land tournait à 50 FPS en bouffant toute la mémoire "au delà du raisonnable". Résultat le jeu n'avait plus assez de mémoire pour avoir du double buffering donc les sprites étaient affichés dans un ordre bien précis et au bon moment pour éviter qu'ils clignotent. Ce genre de magouille bien chiante à gérer fonctionne sur un jeu avec des petits sprites comme ceux de Enchanted Land mais ne fonctionnerait jamais pour un jeu comme Sword Of Sodan.

Perf et mémoire sont généralement 2 éléments qui tirent sur la couverture dans des directions opposées

Ca reste très vrai dans les jeux actuels d'ailleurs, je vois le problème presque tous les jours dans tous les domaines, graphique, gameplay, engine etc...

Disons-le très honnêtement, la programmation de SOS sur Amiga est franchement crade, et j'irais même jusqu'à dire que le programme tout en utilisant le chipset, n'exploite absolument pas au mieux l'Amiga.

Quand j'ai vu les pauvre étapes d'animation (20 à tout péter pour les ennemis et autant pour les persos, et mal foutus (pas assez d'étapes d'animation), sérieusement, oui je pense qu'il y a de la marge pour que le jeu tourne mieux sur Amiga.

Si Stapha jette un coup d'oeil, je suis sur qu'il confirmera ce que je dis.

par Seb Dim 12 Mar 2017 - 23:30

dlfrsilver a écrit:

Disons-le très honnêtement, la programmation de SOS sur Amiga est franchement crade, et j'irais même jusqu'à dire que le programme tout en utilisant le chipset, n'exploite absolument pas au mieux l'Amiga.

Quand j'ai vu les pauvre étapes d'animation (20 à tout péter pour les ennemis et autant pour les persos, et mal foutus (pas assez d'étapes d'animation), sérieusement, oui je pense qu'il y a de la marge pour que le jeu tourne mieux sur Amiga.

Si Stapha jette un coup d'oeil, je suis sur qu'il confirmera ce que je dis.

C'est toujours très facile de critiquer, surtout quand on n'a pas fait le jeu et qu'on en a d'ailleurs jamais codé, voire jamais codé tout court.

20 étapes pour le perso principal, ca peut paraitre peu mais avec un rapide calcul approximatif et simpliste on peut mieux comprendre les contraintes d'un jeu:

- si le sprite du perso est genre 112 x 180 en 4 plans, ca fait 10ko par étape, donc 200ko pour 20 étapes.
- ajoutons 20 sprites pour les enemis et on ajoute 200 ko de plus.

Ils sont peut être en 3 plans et peut-être construits autrement, je n'ai pas regardé le code, juste les screenshots, mais on arrive déjà à 400 ko avec ce calcul simpliste, sans compter les graphisme du fond qui prennent certainement beaucoup, la taille du programme et le data audio. On dépasse déjà de beaucoup la mémoire d'un A500 de base si on ajoute tout ca. Visiblement, les gens qui ont fait ce jeu ne seraient pas si nuls que ca.

Donc oui on peut effectivement critiquer dans le vent, dire que 20 étapes d'anim c'est nul, dire que le code est nul et tout ca, mais ca reste évidemment du vent...

par dlfrsilver Dim 12 Mar 2017 - 23:57

Seb a écrit:
dlfrsilver a écrit:

Disons-le très honnêtement, la programmation de SOS sur Amiga est franchement crade, et j'irais même jusqu'à dire que le programme tout en utilisant le chipset, n'exploite absolument pas au mieux l'Amiga.

Quand j'ai vu les pauvre étapes d'animation (20 à tout péter pour les ennemis et autant pour les persos, et mal foutus (pas assez d'étapes d'animation), sérieusement, oui je pense qu'il y a de la marge pour que le jeu tourne mieux sur Amiga.

Si Stapha jette un coup d'oeil, je suis sur qu'il confirmera ce que je dis.
C'est toujours très facile de critiquer, surtout quand on n'a pas fait le jeu et qu'on en a d'ailleurs jamais codé, voire jamais codé tout court.

20 étapes pour le perso principal, ca peut paraitre peu mais avec un rapide calcul approximatif et simpliste on peut mieux comprendre les contraintes d'un jeu:

- si le sprite du perso est genre 112 x 180 en 4 plans, ca fait 10ko par étape, donc 200ko pour 20 étapes.
- ajoutons 20 sprites pour les enemis et on ajoute 200 ko de plus.

Ils sont peut être en 3 plans et peut-être construits autrement, je n'ai pas regardé le code, juste les screenshots, mais on arrive déjà à 400 ko avec ce calcul simpliste, sans compter les graphisme du fond qui prennent certainement beaucoup, la taille du programme et la musique. On dépasse déjà de beaucoup la mémoire d'un A500 de base si on ajoute tout ca. Visiblement, les gens qui ont fait ce jeu ne seraient pas si nuls que ca.

Donc oui on peut effectivement critiquer dans le vent, dire que 20 étapes d'anim c'est nul, dire que le code est nul et tout ca, mais ca reste évidemment du vent...

Rah mais tout de suiteuhhh !!! Sword of Sodan utilise 1mo de ram. Ce que tu dis est valable pour une config à 512ko. Mais avec 512ko de plus, on est plus à l'aise, et je parlais du programme.

Ce jeu n'est pas optimisé.

par cryodav76 Lun 13 Mar 2017 - 8:37

dlfrsilver a écrit:
Seb a écrit:
dlfrsilver a écrit:

Disons-le très honnêtement, la programmation de SOS sur Amiga est franchement crade, et j'irais même jusqu'à dire que le programme tout en utilisant le chipset, n'exploite absolument pas au mieux l'Amiga.

Quand j'ai vu les pauvre étapes d'animation (20 à tout péter pour les ennemis et autant pour les persos, et mal foutus (pas assez d'étapes d'animation), sérieusement, oui je pense qu'il y a de la marge pour que le jeu tourne mieux sur Amiga.

Si Stapha jette un coup d'oeil, je suis sur qu'il confirmera ce que je dis.
C'est toujours très facile de critiquer, surtout quand on n'a pas fait le jeu et qu'on en a d'ailleurs jamais codé, voire jamais codé tout court.

20 étapes pour le perso principal, ca peut paraitre peu mais avec un rapide calcul approximatif et simpliste on peut mieux comprendre les contraintes d'un jeu:

- si le sprite du perso est genre 112 x 180 en 4 plans, ca fait 10ko par étape, donc 200ko pour 20 étapes.
- ajoutons 20 sprites pour les enemis et on ajoute 200 ko de plus.

Ils sont peut être en 3 plans et peut-être construits autrement, je n'ai pas regardé le code, juste les screenshots, mais on arrive déjà à 400 ko avec ce calcul simpliste, sans compter les graphisme du fond qui prennent certainement beaucoup, la taille du programme et la musique. On dépasse déjà de beaucoup la mémoire d'un A500 de base si on ajoute tout ca. Visiblement, les gens qui ont fait ce jeu ne seraient pas si nuls que ca.

Donc oui on peut effectivement critiquer dans le vent, dire que 20 étapes d'anim c'est nul, dire que le code est nul et tout ca, mais ca reste évidemment du vent...

Rah mais tout de suiteuhhh !!! Sword of Sodan utilise 1mo de ram. Ce que tu dis est valable pour une config à 512ko. Mais avec 512ko de plus, on est plus à l'aise, et je parlais du programme.

Ce jeu n'est pas optimisé.

peu etre mais le probleme c'est surtout qu'on voit pas de différence avec un jeu en 16 couleurs alors que ça a couté tres cher en ressource d'etre en 32 couleurs , je crois que le jeu fonctionne en 512 d'ou "l'exploit"

par Invité Lun 13 Mar 2017 - 11:54

Quand j'ai vu les pauvre étapes d'animation (20 à tout péter pour les ennemis et autant pour les persos, et mal foutus (pas assez d'étapes d'animation),

N'oublies pas que ça doit tourner dans 512ko de RAM, c'est le même souci qu'a rencontré le codeur de FF .
Sans parler du fait que ce sont pas des sprites, mais des bobs .

par Seb Lun 13 Mar 2017 - 17:14

dlfrsilver a écrit:
Rah mais tout de suiteuhhh !!! Sword of Sodan utilise 1mo de ram. Ce que tu dis est valable pour une config à 512ko. Mais avec 512ko de plus, on est plus à l'aise, et je parlais du programme.

Ce jeu n'est pas optimisé.

Le jeu tourne aussi sur les machines de base avec 512 ko.

C'est quand même amusant qu'un gars qui n'a jamais pondu une ligne de code ni jamais fait un jeu et qui poste régulièrement des faits erronés ici se permettent de juger de la qualité du code de ce jeu...

Tout ce que j'ai expliqué plus haut te passe au dessus de la tête visiblement, comme toujours.

par Templeton Lun 13 Mar 2017 - 23:27

Seb: Par contre essayer de refaire en plus rapide sur Amiga ce qui avait été fait à l'époque peut être intéressant avec les connaissances actuelles. Cela dit il ne faut négliger aucun élément de l'époque: RAM disponible, tests de collision, contraintes gameplay (certes vraiment faibles sur ce jeu) etc... Juste afficher le même nombre de sprites avec le scroll en disant "voilà on fait mieux" ne serait pas 100% probant, un jeu est un ensemble de contraintes, parfois nombreuses.

Je n'aurais pas dit mieux. salut

Seb : Perf et mémoire sont généralement 2 éléments qui tirent sur la couverture dans des directions opposées Wink

A qui le dis tu! J'en ai fait la douloureuse expérience il y a peu... et apparemment le codeur de SOS aussi (voir plus bas).

Seb : 20 étapes pour le perso principal, ca peut paraitre peu mais avec un rapide calcul approximatif et simpliste on peut mieux comprendre les contraintes d'un jeu:

Bien vu!

20 étapes pour le perso principal (ou 10 pour un monstre), vu leurs tailles colossales c'est vraiment bien en fait. La plus part des Biped dans Shadow of the Beast n'ont que 5 frames max et sont 10 fois plus petit...

Après un dump de la mémoire, on peut remarquer que le codeur a fait rentrer les gfx au chausse pied. Certains sprites(et pourtant pas les plus larges et plus gros) ont eu un petit bout coupé et rangé dans un espace mémoire qui fait pil poil sa taille.
Du coup il a fallut rassembler un puzzle en temps réel à l'écran sur certaines frames. Bonjour le taf en plus pour le codeur (et la relance du Blitter...).
Des sprites aussi gros et toutes ces frames avec seulement 512k... Sacré challenge pour le programmeur quand même! Shocked

Enfin, il ne faut pas oublier l'infographiste. Dessiner 20 ou 10 sprites par personnage en 32 couleurs avec une taille gigantesque, et un max de détails et de nuances à du prendre un temps fou à faire! Sans compter les décors qui sont des "toiles" sur deux écrans larges. En plus, il y a une très grande variété graphique dans ce jeu !
Ça sent les soirées nocturnes en solitaire devant l'écran tout ça... pale

Plus d'étapes dans les animations auraient sans doutes trop rallonger le temps de développement pour le graphiste (et obliger le codeur à utiliser une extension mémoire en plus).

par stapha92 Mar 14 Mar 2017 - 12:15

@babsimov,
Garde à l'esprit que, comme je l'ai dit, je ferais un truc vite fait uniquement si je me remonte un environnement de dev complet sous WinUAE...
Et ça me prendrait quand même du temps (faut s'y remettre, surtout que je n'ai pas gardé la moindre routine...), vu les faibles dispo dont je dispose. Pour un truc qui n'en vaut pas vraiment le coup...

Pour ce qui est des remarques sur le code de SOS : je suis bien d'accord avec ce qui a été dit au sujet des contraintes techniques. Et c'est même pire que ce qui est annoncé : Seb parle des étapes du perso principal avec un calcul qui se base sur 4 plans. Mais il semble que ce soit 6 ! Il faut donc ajouter 50% aux nombres qu'il a donné (les perso sont en en 32 couleurs, donc 5 plans et il faut un plan de plus pour le masque) ! Et il n'y a pas que les contraintes techniques : il y a les contraintes de délai, de cout, etc...

De plus il faut resituer ça dans le contexte : quand ce jeu est sorti, est-ce qu'il y a eu des critiques sur le fait qu'il était en 4-5 vbl ? Pas dans mon souvenir. Personnellement je n'ai jamais apprécié ce jeu mais ce n'est pas du tout à cause de ça. Et il me semble qu'il avait impressionné à l'époque, non ? Bien sur, de nos jours, on préférerait des perso plus petits mais avec plus d'étapes. Mais c'est parce que la taille ne nous impressionne plus mais à l'époque c'était inédit.

Et j'ai regardé la vidéo du jeu : il y a des parties ou le fond n'est pas géré de la même façon. Ce qui signifie que pour apporter de la variété le codeur a fait des routines différentes. Il ne faut pas rever : le temps qu'il passe à faire ça ne peut pas être employé à autre chose.

D'ailleurs, si le jeu tournait en 2 vbl, je ne pense pas qu'il se serait mieux vendu...

par Seb Mar 14 Mar 2017 - 12:39

Stapha92: pareil, je n'avais pas du tout accroché le game play à l'époque mais il me semble bien qu'il m'avait quand même impressionné, il avait un coté Neo Geo pour la taille des sprites le scroll etc, c'etait inedit sur un ordi