Jeux ST du niveau Demos ? - Page 2

Kochise :
Another Worl : Vectoriel avec rotoscoping (capture de mouvement d'Eric Chahi)
Prince of Persia : Raster avec rotoscoping (capture de mouvement du frere de Jordan Mechner, David)

Kochise

Ces deux là, je les ai tellement joués que parfois j'en rêve encore la nuit !

On oubli aussi les jeux de Silmarils ! Ishar de 1 à 3 sont bluffant de part les couleurs et la palette.

Et surtout l'ultime Robinson's Requiem qui est très impressionnant. ce jeu qui nous immerge dans un univers 3D style voxel façon capacité du ST !

Captive (jeu de rôle futuriste façon Dungeon Master) lui est impressonant car il est en stéréo, et en vrai stéréo les amis, quand on tourne sur sois même on peu entendre d'où viennent les ennemis s'ils font du bruit !

IK+ était fun avant tout. Sinon il arborait une fluidité extrème qui en faisait un super hit ! Jouable à deux sans ralentissement ! Le tout avec des sons digitalisés.

Ah oui, les sons digitalisés de IK+. Alors c'est pas lui le premier jeu avec sons digitalisés ? Je sait plus, mais IK+ avec une particularité technique...

Kochise

Kochise
:

Nil
:

Another World, Prince of Persia -> 2D polygonale et/ou rotoscoping

Si je ne m'abuse, PoP c'est du sprite "simple" avec des masques, non ? Alors que AW est en vectoriel.

Another Worl : Vectoriel avec rotoscoping (capture de mouvement d'Eric Chahi)
Prince of Persia : Raster avec rotoscoping (capture de mouvement du frere de Jordan Mechner, David)

Kochise

Ah tiens, c'est marrant, je savais pas ça pour PoP

IK+ avait un mode TUROBO assé décoiffant (avec les touches de Fonctions F6 à F9 je crois).

Des jeux avec des sons digitalisés il y en a eu avant, par exemple Barbarian de chez Palace Software où l'on pouvait écouter des digit du film Kalidor. IK+ lui reprend des digits d'un film de Bruce Lee, La Fureur du Dragon il me semble.

Dans le genre très bon, il y avait Croisière pour un Cadavre avec un moteur 3D assé bien foutu. Le tout mixé au image bitmap pour donner un sublime jeu avec un scénario digne d'un Hercule Poirot

Ouais mais croisière pour un cadavre, c'était l'enfer x_x... 7 disquettes, il fallait faire attention avant de changer de pont sur le navire
Captain Blood a du JM Jarre dans l'intro, The light Corridor a une musique d'intro très sympa aussi...

Oui, Croisière pour un Cadavre sur 5 disquettes, c'était l'enfer

RickST :
Ah oui, sinon il y a Zool STE qui est en 1 VBL il me semble.

Seulement quand y a pas d'ennemis à l'écran

aaaaah j'avais pas vu!! RickST!!!!!!!!
Rhhhhaaaaaaaaaa si t'es le RickST dont je pense, et bien je te dis : bravo!

Strider :
Dans un autre style, si t'aimes les jeux de flipper, il y a Pinball Obsession qui est énorme, très bonne exploitation technique du STE et aussi une bonne jouabilité.

Obsession Pinball... je l'ai testé finalement !

Effectivement, celui là a pas mal de qualités pour lui... Full screen, beau scroll, zik bien exploitée... Beau boulot !

Idem Stardust, une des toutes meilleures versions du jeu !

pmandin :
Y'aurais bien Jim Power, mais bon, comme Shadow of the Beast, la version Amiga est plusieurs crans au-dessus.

Shadow of the beast est horrible. On dirait presque une version Spectrum. Le gars qui a fait la conversion mérite un carton jaune à mon humble avis. Ok, c'etait dur de faire aussi bien que l'original, mais là... Je n'ai jamais trop accroché sur ce jeu (je l'ai joué sur Megadrive, mais jamais fini, trop dur et un peu chiant), mais le design, la musique et la realisation n'etaient pas mal du tout, sur Amiga et Sega en tout cas.

Sinon, The Killing Game Show est excellent. Dommage que l'on ne puisse pas activer en même temps les bruitages et la musique. Mais j'adore quand les concepteurs se donnent la peine de fignoler les détails, du genre le selecteur 50/60hz, ça c'est du boulot !

J'ai essayé StarioLand et même si le jeu est moche, j'ai été impressioné par le scrolling et le déplacement des sprites. Il y en a d'autres des jeux aussi fluides sur STE ? Je veux dire, à part Goal ou Kick Off

Parce que bon, les ralentissements observé dans des titres comme Zool rendent le jeu pas très agréable.

J'ai trouvé James Pond 2 trés bien fait à l'époque, mais je crois me souvenir que sur mon moniteur, je me retrouvais avec une petite fenêtre... Harlequin était pas mal aussi dans le genre. Elf de même mais la c'était plus la même technique. Mais trés jolie. Ivanoé possédait un scrolling relativement fluide non?

Godcedric :
Ivanoé possédait un scrolling relativement fluide non?

Exact Ivanoé était aussi une boucherie technique, je sais qu'il y a une personne qui pourra t'en parler comme personne d'autres ici



GT

Ca m'avait impressionné de voir le jeu tourner à l'époque. On me l'avait acheté dés sa sortie. Je me suis essayé hier Sensible soccer 1.2 V2 sur mon Ste. Ca tourne bien, mais Kick off2 est quand même plus véloce selon moi. Ca défile bien, mais la vitesse n'est pas la. Pourtant j'ai pas l'impression que c'est chargé graphiquement. Et niveau maniabilité, c'est pas top non plus comparé à Kick Off. Je suis peut être pas encore pro du jeu, mais j'ai l'impression de pas controler le ballon. Par contre un bon point, c'est entièrement en francais, ca propose un paquet de compets et on peut éditer les équipes. Goal est peut être mieux?

Godcedric :
Goal est peut être mieux?

Perso moi, j'ai toujours adoré Goal, meme s'il ne m'a jamais fait arreter Kick Off 2... Mais je crois me souvenir qu'il y avait des bugs dans Goal(la version à laquelle je jouai en tout cas), qui pouvaient parfois etre enervants (me souvient plus exactement quoi par contre)

Kick off 2 est le seul jeu de foot que j'ai adoré. Même sur pc, je peux pas m'y faire aux nouveaux jeux.

http://www.grospixels.com/site/ivanhoe.php

Sinon, y a aussi ce jeu qui m'avait bien plu à l'époque :

http://www.grospixels.com/site/jpond.php

vous avez etes ultra productif sur ce sujet alors je sent que je vais me faire tapper en proposant le nom de mon jeu
car j'ai eu la grosse flème de tout lire.

PINBALL OBSESSION (jeu de flipper)
HardScroll STE
son Module 5 VOIX !!! à 25khz !!!
40 couleurs affiché aulieux de 16 et sur la palette etendu du STE

mon seul regret et de ne l'avoir jamais eu et pu y jouer. :'(

okok

Pour ma part, je me souviens de Bio Challenge (premier jeu de Delphine SJMSB), très bonne anim et beaucoup de couleurs.
Dans un tout autre genre, Starglider 2 : superbe 3D, et une seule disquette originale qui fonctionnait aussi bien sur 'tari que sur 'miga...
SWIV (alias Silkworm IV) était un bon shoot 'em up qu'on pouvait (essayer de) finir sans faire la moindre pause, car tout le contenu de la disquette se chargeait en continu pendant le jeu.
Armour Geddon : bonne 3D, intro hallucinante !

Pour ce qui est des jeux tournant à la VBL, il me semble (halluciné-je ?) que Rodland en était.

GT Turbo
: Je t'arretes, Atari avait prévu cela, mais aucune règle en vigueur n'a été appliqué par les programmeurs, et oui il est écrit dans de nombreuses doc que le moyen le plus propre pour changer la palette (Par exemple) c'est la VDI (...) Mais les programmeurs on fait cela pour des raisons de vitesse

Non non ça n'a rien à voir ! Prenons par exemple le cas de la fin de la démo Arte de Sanity sur Amiga. C'est une routine 3D optimisée au maximum (qui ne passe pas par le système graphique de l'OS) et dans tous les cas les animations sont à la même vitesse quelque soit la machine. Par contre le rendu graphique est séparé du calcul des animations, ce qui fait que si la machine est plus puissante, le rendu s'effectue plus rapidement et donc qu'il y a plus d'images par seconde (donc, une meilleure fluidité). Si je prends le cas de Hard Driving, qui me vient à l'esprit parce que je l'ai testé sur des configs plus musclées qu'un simple ST, quand la machine est plus puissante le jeu ne gagne pas en fluidité mais en vitesse car le calcul de la 3D et le rendu s'effectuent invariablement l'un après l'autre, séquentiellement (1 calcul, 1 rendu, 1 calcul, 1 rendu). C'est le cas de tous les jeux 3D que j'ai testé, mais il est vrai que je n'ai pas testé les simulateurs de vol qui avaient certainement des moteurs un peu mieux foutus. En l'occurence donc quand je parlais de concepteurs, je ne voulais pas parler des concepteurs du ST mais des développeurs de jeux qui faisaient de la 3D comme ils faisaient de la 2D.
En même temps laisse-moi te dire que faire des appels VDI lorsque tu ne programmais pas en C relevait du masochisme. Par contre c'est vrai que la VDI prenait en compte tout un tas de trucs que personne n'a jamais relevé, comme la déformation de l'image due aux pixels non carrés sur un moniteur couleur.

odie_one :
Des jeux avec des sons digitalisés il y en a eu avant, par exemple Barbarian de chez Palace Software où l'on pouvait écouter des digit du film Kalidor.

Golden Axe aussi mélange musique et sons digitalisés. C'est quelque chose qui m'a longuement perturbé, quelque chose me gênait sans savoir ce que c'était. Plus tard, je me suis rendu compte que c'était parce que les bruitages étaient des digits.

GT Turbo :
Exact Ivanoé était aussi une boucherie technique, je sais qu'il y a une personne qui pourra t'en parler comme personne d'autres ici

J'ai acheté mon ST en voyant les images d'Ivanhoé dans un mag. Malheureusement ce jeu à énormément de lacunes - notamment l'animation très rudimentaire des sprites qui étaient jolis, comme tout le reste - et au final il n'est pas très intéressant. C'était très dommage.

CloudHead :
Shadow of the beast est horrible. On dirait presque une version Spectrum. Le gars qui a fait la conversion mérite un carton jaune à mon humble avis.

Shadow of the Beast 2 est très honnête sur ST. Je n'y ai pas beaucoup joué mais techniquement il tenait la route. Leander aussi était bien.

arklif :
PINBALL OBSESSION (jeu de flipper)
HardScroll STE
son Module 5 VOIX !!! à 25khz !!!
40 couleurs affiché aulieux de 16 et sur la palette etendu du STE

5 voix ? T'es sûr ?
Il y avait aussi un overscan bas pour l'afficheur.

Puisqu'on est dans le technique, je tenais juste à préciser que la musique du menu de Turrican 2 est en TFMX 7 voix, même sur la version ST. Par contre la qualité de replay est assez horrible.

Et puis quand même, merde, y'a Rainbow Islands aussi qui déchirait tout à l'époque. Andrew Braybrook avait écrit un moteur qui permettait d'intégrer les 9 arc-en-ciels (max possible dans le jeu) au décor de fond pour éviter de les traiter comme des sprites. Par contre au niveau du jeu proprement dit, il manque les trois îles secrètes et la vraie fin du jeu pour des raisons de place disque (cf une interview de Joystick de l'époque).

Harlequin arait pu être une tuerie s'il n'avait pas eu une maniabilité exécrable (les programmeurs ne jouaient-ils jamais à leurs jeux ?). Je n'en ai jamais vu le bout tellement il était énorme.

Il y a aussi Crapman (Pacman à deux joueurs dans la Synergy demo). Très bon concept, bonne réalisation, le tout détruit par un level design merdique. Dommage, à part ça c'est le meilleur "pacman" auquel j'ai jamais joué... à deux.
Dans les oldies toujours, Arkanoid était en 1 VBL. Arkanoid 2 est moins fluide, je n'ai jamais compris pourquoi.

Captain Dynamo est un jeu de plateforme passé relativement inaperçu mais qui m'a laissé de très bon souvenirs. Pas de 50fps mais très fluide quand même, et bien animé.

Vroom, bien sûr, avec ses zooms en temps réel et un mode à la souris super une fois qu'on avait pris le pli. Et Lotus Esprit Turbo Challenge était en 1 VBL en mode un joueur, mais les concurrents n'avaient aucune intelligence artificielle alors que dans Vroom c'était le cas.

Et Shufflepuck café ? Hein ? Personne ne l'a relevé celui-là.

Pour finir j'ai retrouvé mon jeu de petit vaisseau en 1 VBL : c'était Outzone, de Lankhor.

jul2149 :
aaaaah j'avais pas vu!! RickST!!!!!!!!
Rhhhhaaaaaaaaaa si t'es le RickST dont je pense, et bien je te dis : bravo!

Euh, merci mais pourquoi ?

RickST
: Non non ça n'a rien à voir ! Prenons par exemple le cas de la fin de la démo Arte de Sanity sur Amiga. C'est une routine 3D optimisée au maximum (qui ne passe pas par le système graphique de l'OS) et dans tous les cas les animations sont à la même vitesse quelque soit la machine. Par contre le rendu graphique est séparé du calcul des animations, ce qui fait que si la machine est plus puissante, le rendu s'effectue plus rapidement et donc qu'il y a plus d'images par seconde (donc, une meilleure fluidité). Si je prends le cas de Hard Driving, qui me vient à l'esprit parce que je l'ai testé sur des configs plus musclées qu'un simple ST, quand la machine est plus puissante le jeu ne gagne pas en fluidité mais en vitesse car le calcul de la 3D et le rendu s'effectuent invariablement l'un après l'autre, séquentiellement (1 calcul, 1 rendu, 1 calcul, 1 rendu). C'est le cas de tous les jeux 3D que j'ai testé, mais il est vrai que je n'ai pas testé les simulateurs de vol qui avaient

C'est le gros problème de la gamme, vu qu'il a fallu attendre le TT pour avoir une machine plus puissante (et encore, personne ne l'achetait pour jouer), les développeurs sont restés sur l'idée que ST = 68000 à 8mhz (les seules choses à gérer ou non suivant la machine à partir du STE, c'était blitter + DMA) et qu'ensuite il y aurait autre chose (comme à l'époque des 8 bits, et c'est à moitié ce qu'à fait le Falcon). Commodore, avec leurs configs plus hétéroclites ont forcé les développeurs à faire plus gaffe pour ne pas se couper d'une bonne partie du marché. Dans ce sens, ils étaient plus proches de l'évolution des PC ou des Macs...

Si Atari avait sorti le STE à 16 mhz (et avec les modes graphiques étendus dont ils rabachaient les oreilles à chaque salon dès 87), ça aurait changé beaucoup de choses...

RickST :
Non non ça n'a rien à voir ! Prenons par exemple le cas de la fin de la démo Arte de Sanity sur Amiga. C'est une routine 3D optimisée au maximum (qui ne passe pas par le système graphique de l'OS) et dans tous les cas les animations sont à la même vitesse quelque soit la machine. Par contre le rendu graphique est séparé du calcul des animations, ce qui fait que si la machine est plus puissante, le rendu s'effectue plus rapidement et donc qu'il y a plus d'images par seconde (donc, une meilleure fluidité). Si je prends le cas de Hard Driving, qui me vient à l'esprit parce que je l'ai testé sur des configs plus musclées qu'un simple ST, quand la machine est plus puissante le jeu ne gagne pas en fluidité mais en vitesse car le calcul de la 3D et le rendu s'effectuent invariablement l'un après l'autre, séquentiellement (1 calcul, 1 rendu, 1 calcul, 1 rendu). C'est le cas de tous les jeux 3D que j'ai testé, mais il est vrai que je n'ai pas testé les simulateurs de vol qui avaient certainement des moteurs un peu mieux foutus. En l'occurence donc quand je parlais de concepteurs, je ne voulais pas parler des concepteurs du ST mais des développeurs de jeux qui faisaient de la 3D comme ils faisaient de la 2D.

Tu as déjà fait de l'assembleur sur un ST ? Et surtout de la démo voire du jeu ? J'ai un très gros doute.

Je penses que tous ceux qui ont fait de la 3d sur un ST, génère la 3d puis l'affichage après et ceci juste pour des raisons de vitesse. Le 68000 ne disposant que de 8 registres de données (car pour ceux qui connaissent pas ce sont des données a accès ultra rapide), ce qui fait que pour optimiser aux mieux, il faut obligatoirement séparer pour pouvoir avoir assez de registres pour utiliser a fond. Quand tu fais tourner ce genre de code sur une machine plus rapide si ton code est super optimisé il doit planter !!! et oui car quand on dispose que de 8 Mhz, pas de cache, pas de blitter, on utilise du code généré et de l'automodifiant, chose incompatible avec les caches des processeurs des générations au dessus. Sur l'Amiga ca plante pas car ils ont pas utiliser ces puissantes techniques donc on me parle pas de super optimisation. Sinon le code était déjà prévu pour tourner sur des processeurs a cache donc de la génération suivante de l'époque dont on parle. Le seul moyen d'ètre sur d'avoir un code qui tourne sur des machines plus puissantes, est d'écrire sans utiliser ces techniques. C'est possible que certains font les deux en meme temps (calcul+affichage) mais bon, je penses pas pour la majorité.

RickST :
En même temps laisse-moi te dire que faire des appels VDI lorsque tu ne programmais pas en C relevait du masochisme. Par contre c'est vrai que la VDI prenait en compte tout un tas de trucs que personne n'a jamais relevé, comme la déformation de l'image due aux pixels non carrés sur un moniteur couleur.

J'ai un très gros problème avec le C, malgré une dizaine de tentative de programmation avec ce langage, j'ai juste réussi a me faire monter ma tension. Je suis un fanatique de l'assembleur, je developpes actuellement sur Jaguar et j'avais besoin d'un éditeur de map, donc je m'en suis écrit un mais un assembleur et il est full Vdi/Aes, 22 000 lignes d'assembleur et tu sais quoi ? Meme sur un simple ST, il tourne assez vite mais sur un Falcon et alors un Falcon boosté, c'est que du bonheur. Je n'ai aucun soucis a afficher un point comme un bloc graphique avec la Vdi, c'est juste une question d'organisation de son code c'est tout. Pour ceux d'ailleurs qui sont tentés de faire des gribouillis Vdi en assembleur, je vous conseilles de lire le prochain STMag (Pour commander c'est par ici http://stmagazine.org/accueil.htm , on va vraiment croire que RayXamber me paie pour faire de la pub ) qui en parlera .

RickST :
J'ai acheté mon ST en voyant les images d'Ivanhoé dans un mag. Malheureusement ce jeu à énormément de lacunes - notamment l'animation très rudimentaire des sprites qui étaient jolis, comme tout le reste - et au final il n'est pas très intéressant. C'était très dommage.

Peu d'animations oui pourquoi ? Car utilisation de code généré, ce qui mange un maximun de mémoire mais rend possible un tel jeu a cette vitesse.

RickST :
Et puis quand même, merde, y'a Rainbow Islands aussi qui déchirait tout à l'époque. Andrew Braybrook avait écrit un moteur qui permettait d'intégrer les 9 arc-en-ciels (max possible dans le jeu) au décor de fond pour éviter de les traiter comme des sprites.

Heum..... Cela est ultra simple d'appliquer une telle technique sur un ST, car il y a juste besoin de pas effacer le sprite et oui. Tu m'excuses mais cela est pas super technique d'effacer une routine d'effacement.

RickST :
Dans les oldies toujours, Arkanoid était en 1 VBL.

Sincérement pas difficile, c'est jouable avec tout en temps réel sur un simple ST.

RickST :
Vroom, bien sûr, avec ses zooms en temps réel et un mode à la souris super une fois qu'on avait pris le pli.

Vroom est une tuerie, j'y joues encore maintenant je me demande comment cela est possible, un tel jeu sur un ST mais la je penses pas que tous les codeurs présents ici te diront que cest pas du temps réel car du fais de la super organisation mémoire du ST, zoomer un simple pixel en plus d'une couleur, nécessite un bon gros code de merde. bien lent, car il faut traiter des bits, ce que le 68000 fais pas génial génial.

Si quelqu'un me démontre que ce sont des zooms temps réel alors la, j'arretes les dragibus pendant un mois (Et pourtant j'aimes les dragibus )

GT Turbo

GT Turbo :
[...]Le 68000 ne disposant que de 8 registres de données (car pour ceux qui connaissent pas ce sont des données a accès ultra rapide), ce qui fait que pour optimiser aux mieux, il faut obligatoirement séparer pour pouvoir avoir assez de registres pour utiliser a fond. Quand tu fais tourner ce genre de code sur une machine plus rapide si ton code est super optimisé il doit planter !!! et oui car quand on dispose que de 8 Mhz, pas de cache, pas de blitter, on utilise du code généré et de l'automodifiant, chose incompatible avec les caches des processeurs des générations au dessus. Sur l'Amiga ca plante pas car ils ont pas utiliser ces puissantes techniques donc on me parle pas de super optimisation. Sinon le code était déjà prévu pour tourner sur des processeurs a cache donc de la génération suivante de l'époque dont on parle. Le seul moyen d'ètre sur d'avoir un code qui tourne sur des machines plus puissantes, est d'écrire sans utiliser ces techniques. C'est possible que certains font les deux en meme temps (calcul+affichage) mais bon, je penses pas pour la majorité.

Je comprend simplement que les codeurs sur ST sont des porcs...

GT Turbo :
[...]J'ai un très gros problème avec le C, malgré une dizaine de tentative de programmation avec ce langage, j'ai juste réussi a me faire monter ma tension.[...]

Essaye sur PC, y'a de très bons débugeurs intégrés, c'est largement plus facile. Je te conseille :

http://upp.sourceforge.net/
ou
http://www.codeblocks.org/

Télécharge les versions avec MingW intégré (le compilateur GCC)...

GT Turbo
:

RickST :
J'ai acheté mon ST en voyant les images d'Ivanhoé dans un mag. Malheureusement ce jeu à énormément de lacunes - notamment l'animation très rudimentaire des sprites qui étaient jolis, comme tout le reste - et au final il n'est pas très intéressant. C'était très dommage.

Peu d'animations oui pourquoi ? Car utilisation de code généré, ce qui mange un maximun de mémoire mais rend possible un tel jeu a cette vitesse.

Code généré ? C'est quoi ça, pour toi ? Tu veux dire du code automodifié ? Ca prend pas de place, c'est juste très très crade. Si l'animation semble sommaire, c'est juste qu'il manque des images clés dans l'animation (ex. Kasumi Ninja ou il y a 1 voire 2 images par coup, tandis que Street Fighter décompose chaque mouvement en une dizaine...)

GT Turbo
:

RickST :
Et puis quand même, merde, y'a Rainbow Islands aussi qui déchirait tout à l'époque. Andrew Braybrook avait écrit un moteur qui permettait d'intégrer les 9 arc-en-ciels (max possible dans le jeu) au décor de fond pour éviter de les traiter comme des sprites.

Heum..... Cela est ultra simple d'appliquer une telle technique sur un ST, car il y a juste besoin de pas effacer le sprite et oui. Tu m'excuses mais cela est pas super technique d'effacer une routine d'effacement.

Si si, l'intéret est de gagner les cycles CPU que tu perds à écrire en RAM pour effacer des sprites, sachant que tu vas réécrire au même endroit pour mettre autre chose. Donc autant mettre le 'autre chose' direct dessus... Une sorte d'algo du peintre pour les sprites, sans 'clipping'

Kochise

Kochise :
Je comprend simplement que les codeurs sur ST sont des porcs...

Oui et non cela prouve leur ingéniosité, et nous a permis de voir des choses impossibles sur un ST normalement.

Kochise :
Essaye sur PC, y'a de très bons débugeurs intégrés, c'est largement plus facile. Je te conseille :

http://upp.sourceforge.net/
ou
http://www.codeblocks.org/

Mon PC sert juste de browser internet, c'est trop instable comme machine et tu rajoutes mes progs par dessus, t'est sur que cela se finira très mal pour la machine et moi meme.

Kochise :
Code généré ? C'est quoi ça, pour toi ? Tu veux dire du code automodifié ? Ca prend pas de place, c'est juste très très crade. Si l'animation semble sommaire, c'est juste qu'il manque des images clés dans l'animation (ex. Kasumi Ninja ou il y a 1 voire 2 images par coup, tandis que Street Fighter décompose chaque mouvement en une dizaine...)

Code généré : une routine qui en écrit des spécifiques pour des gains de temps.
Exemple sur des 'flexiscrollers', chaque lettre a un bout de code spécifique qui fera qu'il ne pourra écrire que la lettre pour laquelle il a été écrit mais a une vitesse supérieure. L'exemple marrant c'est pour du 'biggy' sprite, lorsque tu as un trou au milieu de ton sprite, cas des noms de groupe par exemple 'Vector' (V très grand, trou dans le E, le O) le code généré ne génère rien et donc tu gagnes du temps la ou une routine standard aurait recopier du noir. Ou pour les routines de remplissage de polygones, tu génère une routine pour chaque longueur de ligne, cela mange un peu de place, mais qu'est ce que cela pousse !! Et cela permet aussi de 'dérouler' les boucles, sans recopier comme un ane des lignes de code.


GT Généré !!!

Quand on confond le code generé et automodifié, on evite les declarations tel que :
"Je comprend simplement que les codeurs sur ST sont des porcs..."

Heureusement que GT est la pour vous instruire

on est la pouraprecier ce qu'on lit et ne pas ce prendre la tete.
la g l'impression que ca va tourné en tempete du désert dans pas longtemps... et je trouve ca dommage

Pas de soucis, rassure toi ce sont juste des avis techniques, et on ce prend souvent la tête la dessus (Vieille habitude ) alors pour ceux qui connaissent pas, pas de panique, faut le prendre au second degré c'est de l'humour de codeur c'est tout.


GT Codeur

qu'eau chease: les codeurs sur ST sont des porcs...

J’ai toujours trouvé que gt avait une tronche de jambon, maintenant je comprends pourquoi !

...Et puis quand même, merde, y'a Rainbow Islands aussi qui déchirait tout à l'époque. Andrew Braybrook avait écrit un moteur qui permettait d'intégrer les 9 arc-en-ciels (max possible dans le jeu) au décor de fond pour éviter de les traiter comme des sprites.

TURBIN GT: Cela est ultra simple d'appliquer une telle technique sur un ST...
Ko chease :... Une sorte d'algo du peintre pour les sprites, sans 'clipping'

En effet, d’ailleurs il y avait une option dans le STOS pour gérer ce genre de situation. En fait les arcs en ciels étaient géré comme des sprites seulement lorsqu’ils apparaissaient et qu’ils se brisaient (c’est pour cela que le jeu ramait lorsque bub en faisait tomber un max),seul les coordonnées étaient sauvées, bref une astuce d'une simplicité désarmante mais diablement efficace dans ce jeu.

TURBEAU Jeté i quelqu'un me démontre que ce sont des zooms temps réel alors la, j'arretes les dragibus pendant un mois

J’avais lu un interview du codeur, si mes souvenirs sont bon.... il y’avait deux ou trois sprites dessinés ( technique du LOD en fait) avec un zoom entre chaque, les calculs d’expansions étaient sans doute précalculées, mais le sprite était bien dessiné en temps réel, c’est pour cela qu’ils zoom avec une fluidité parfaite !

Roule à deux km/h et tu veras que les sprites zoom au pixel. Maintenant réalise la même opération avec super burn-out sur jag et ses sprites non zoomé et tu verras qu’ils sont tres sacadés !
Qui a dit que le st était plus fort qu’une jag ? hein ? kiki ?

Maintenant la grande question du jour...pourras-tu tenir 1 mois sans dragibus ?



TOBE

tobe :
Quand on confond le code generé et automodifié, on evite les declarations tel que :
"Je comprend simplement que les codeurs sur ST sont des porcs..."

Heureusement que GT est la pour vous instruire

Evidement je disais ça pour taquiner un peu la 'pouasquaille'. N'empèche la plupart des codeurs ST trouvent des 'super' optimisations de la mort (c'est bien), mais chialent ensuite que ça passe pas sur les autres configs genre Falcon030 (c'est moins bien) en accusant le vilain cache ou la vilaine pipeline (c'est carrément pas bien)...

Donc je RECTIFIE : Les codeurs ST sont TRES BONS, mais sur ST uniquement ! Dès qu'il sagit de prendre en compte des configs différentes, ils sont perdus, là où sur Amiga ils réussissent plutôt mieux (j'ai pas dit qu'ils réussissent à tous les coups) !

Pour le code généré, c'est qu'en fait je n'en ai quasiment jamais fait, et encore moins de l'automodifié Que ce soit en GFA, en ASM ou en C, je tache toujours de me démerder autrement, et tant pis pour la perte de vitesse, si au moins je garanti la portabilité...

Kochise