Bonjour à tous,

Comme vous le savez, "Anuman" a acheté les droits des jeux "Titus"... En juin 2011,

Normalement tous les jeux Titus devraient trouver une nouvelle vie sur les plateforme Apple IOS / Android et pourquoi pas Nintendo DS/ 3DS...

L'annonce : http://www.facebook.com/note.php?note_id=10150226722513153

Si une résurrection de Power Piggs est prévue, je prends direct.
_________________

Salut Alain,

Ça fait toujours plaisir d'avoir un post de ta part sur GP ^__^ !
Merci pour l'info !
_________________

JPB,
tombé dans les jeux vidéo depuis TRON

Houlà, je sais pas comment réagir, parce que pour l'instant j'ai pas eu de bonne expérience avec les jeu estampillé "Anuman".

Donc j'espère qu'ils feront pas n'importe quoi avec.
_________________

Alain j'ai fait une petite remontée dans le temps en lisant la page de ton parcours professionnel



La lecture de ce genre de chose me laisse songeur. Je regrette amèrement cette époque où la réalisation d'un jeu passait (presque) forcément par l'écriture de routines en assembleur soignées aux petits oignons et qui donnait à chaque jeu un caractère original. Aujourd'hui, rien que de penser au nombre de couches logiciel qu'il faut "traverser" pour allumer le moindre pixel à l'écran, ça me coupe toute envie d'écrire la moindre ligne de code.

Bon je sais que je suis complétement hors sujet donc je m'arrête là mais ça serait interessant d'avoir un topic sur la transition du Jeu Vidéo, de l'artisanat vers l'industrie.

Pour "Youpla"...

En fait aujourd'hui c'est 100 fois plus simple "d'allumer un pixel" , d'afficher un "sprites" , de faire un effet "alpha" ( Surtout sur IPhone / IOS )....

Franchement c'est un peu plus facile aujourd'hui de faire un jeu en OpenGL ( IPhone / Mac ) ou
en DirectX ( PC / XBOX )

Et en plus de nos jours, les studio utilisent des outils comme "Unity 3D"... pour eviter de se prendre
la tête avec DirectX / OpenGL... ( J'ai aussi l'outils Unity 3D PC / Mac / Iphone )

EDIT: Pour "Youpla"
Si vous aimez programmer "low level", developper sur PS3.. Les sociétés recherchent toujours
des programmeurs qui peuvent tirer le maximum en utilisant la programmation en assembleur...

Oui, mais je n'ai pas dit le contraire.
Ton exemple illustre bien ma remarque avec d'un coté un code assembleur certes fastidieux mais qui est ton code à toi (donc sur lequel tu as un contrôle total et qui a un rendu graphique typique de ta façon de programmer), et qui attaque directement la hardware (dans cet exemple la mémoire vidéo je suppose).
De l'autre coté un unique appel à une fonction qui va engendrer une cascade de sous-appels longue comme mon bras avant de pouvoir attaquer le hardware. Et là je déplore plusieurs choses : tu es dépendant de la fiabilité des différentes couches que ton appel traverse, ton contrôle sur le rendu final se fait exclusivement par le biais des paramètres des fonctions, et enfin que de ressources gaspillées !


Je ne doute pas une seule seconde que ce genre d'outil soit hyper efficace en terme de productivité... une chaîne de montage pour jeu vidéo quoi.

Hop hop hop, je profite de la présence de monsieur Fernandes pour voir s'il peut répondre à une question qui me taraude depuis plus de 6 ans :


Etant donné que vous avez travaillé sur la version Spectrum (donc Z80 aussi), pourriez-vous expliquer en quoi consistait ce bug ? D'avance merci !

Merci beaucoup pour l'info monsieur. Je me sens un peu gêné pour le vouvoiement, vu que je VOUS ai tutoyé tout du long

Pour "Youpla"..

1) Si tu "tapes" directement le hardware... les fabriquants comme Apple ou Nintendo ne valideront pas ton jeu... ( Car ils veulent pouvoir changer de hardware sans que des jeux plantent )

2) Il y a des centaines de carte graphiques, donc il faut faire un dev spécifique... Déjà au début du PC.... on faisait la version CGA , EGA , VGA , Hercule , XGA... Donc cela fait autant de routines a écrire et le graphiste va t'éxpliquer qu'il ne veux pas passer sa vie a faire le même graphisme x fois ....

3) Entre 2005 et 2007 , j'ai programmer pas mal sur téléphone J2ME / IMode...Tu dois faire 17 versions de ton jeux avec différents tailles de graphisme , différentes routines pour le clavier , pour l'affichage ... puis les 17 source code de ton jeu sont envoyé en Inde, ou des programmeurs vont faire une centaines de versions... pour les 1000 téléphones cibles...Donc beaucoup d'heures.... ( Le probléme revient avec Android et les centaines d'appareils qui n'ont pas les même caractéristique Résolution / Vitesse / Version d'API )

4) Même quand tu tapes directement le hardware tu ne le fais pas réellement ou tu ne peux pas , car un processeur graphique contient son propre micro code, parfois il faut "discuter" avec le processeur graphiques car tu n'as pas acces aux registres du système ( Le cas du Matra Alice 90 )

Et une 5 eme raison... Quand on tape directement dans les registres vidéo/ram vidéo, on risque de planter facilement le systeme , donc cela oblige a sauvegarder ton jeux a chaque essai.. sauvegarde sur K7 le plus souvent... Bonjour le temps perdu ... de plus après avoir planter , il faut tout recharger... tout cela pour une mauvaise instructions ... En fait a l'époque on utilisait des émulateurs de microprocesseurs on déssoude le microprocesseur de la machine et on place un cordon x pins qui correspond au cablage du processeur, et au bout de se câble il y a un "ordinateur" qui va simuler le comportement du Z80 / 6502 etc etc ... Tu peux donc "déplanter" la machine esclave facilement..... On faisait beaucoup d'essais a l'epoque pour gratter quelque cycle pour les jeux qui devaient tourner a 50/60 fps...( Pas d'internet, on n'avais pas acces aux sources de jeux "open" et encore de bouquin pour gagner du temps )

Aujourd'hui coder sur les anciennes machines c'est plus facile , on trouve même des compilateurs C pour GameBoy... et des librairies "SDL" pour beaucoup de machines.....

Alain Fernandes
http://www.inthepockets.com

Pour "Al-Kashi"

Le bug de l'Amstrad , qui à permis a Philippe Pamart de créer Titan, n'est pas un bug , mais la possibilitée d'accéder aux registres machine qui gère l'affichage, donc cela ne vient pas du Z80, mais de la partie vidéo...Faire de l'overscan...pour la vitesse du jeux c'est le fait qu'il tourne a 60 fps, cela vient bien sur que le jeu est écrit en assembleur, que Philippe Pamart est un très bon programmeur, et que le jeu n'est pas réafficher entierement a chaque fps en utilisant la technique du buffer circulaire multi-directionnel...on n'affiche que les briques qui "rentre" et pour deplacer le jeu aux pixels on modifie le pointeur de l'adresse
de la ram vidéo.


Donc malgré que le ZX Spectrum soit équipé d'un Z80, les "bugs" de l'Amstrad n'était pas transportable.. vue que c'était le hardware de la vidéo... Je parle de l'overscan, sinon c'est la même technique pour le buffer circulaire. Même si le code est différent.

Mais par exemple la version ZX Spectrum K7, a un loader qui charge très vite le jeu et qui remplace le "loader" qui se trouve dans la rom du sprectrum... Il lieu de charger a x bauds par seconde, je crois
que je devais charger le jeux a 2400 bauds... Et on l'entend.... Les premieres secondes du chargement
de la K7 sont aigues avec des bandes bleues et jaunes plutot espacés... Et une fois que le loader est
chargé et lancer... la suite du chargement aura un son bien plus aigue et des bandes bleues et jaunes
moins espacés.

Alain Fernandes...
http://www.inthepockets.com

La question la plus fondamentale est :

Ont ils racheté les droits de la Zoubida ?
_________________

Retropudding : du rétrogaming en moins bien
Journalisme total ?

Pour "mickmils"...

Le communiqué officiel parle de "l’exploitation du catalogue Titus sur PC, Mac, iOS, Android et les nouvelles plateformes de jeu."

Se sera peut-être "Titus the Fox" la version international de la "Zoubida"...

Merci beaucoup de répondre aux questions des forumeurs de Grospixels, tout ceci est passionnant !

Pour Youpla,

Ouais, c'est plus facile de faire un jeu qui blitte de la 2D de nos jours certes.
Mais faut voir que les jeux font bien plus de trucs de nos jours.
On a la concurrence et le parallélisme qu'il n'y avait pas autant avant (sauf dans les handlers d'interruption et dans les transferts DMA par exemple). On a des algos de compression de données bien plus complexes. Et j'en passe. Bref tout est plus compliqué.
Tu ne vas pas mettre autant de soin de grattage de cycles dans les 2 kilos de code qui décompressent tes textures en ondelettes que dans les 30 bytes de ton code de RLE
Donc au final, y'a toujours des jeux mieux programmés que d'autres, et c'est ça qui fait la différence
Oui, il y a des gens qui s'embêtent plus que d'autres sur la partie technique.
C'était déjà le cas y'a 20 ans, finalement!
Quant à attaquer directement le hardware maintenant... si tu savais tout ce qu'il faut faire pour piloter un GPU... impossible pour un studio. T'as vu le nombre de bugs dans les drivers, déjà?

Pour Alain,

Bordel j'aurais jamais pensé qu'un loader sur K7 était CPU-bound! Mais plus rien ne m'étonne
Ou alors c'était pour faire tourner le hard au dessus de la vitesse nominale au péril de sa longévité?

_________________

Ended up in a stranglehold on a PVC chair

Tramboi

En fait on enregistre le jeux en 2400 bauds au lieu de 1200 par exemples avec une routine maison...
qui n'ai pas inclus dans le code du jeux, dans le code du jeux il y a que le "loader" 2400... qui est lancé
aprés son chargement...

On ne "booste" pas le hardware... en fait c'est le temps en millisecondes qui correspond a un 1 ou a un 0
ou a un blanc qui est réduit....

Cela signifie que si ton code tourne pas assez vite... tu perdras des bits.

Alain Fernandes
http://www.inthepockets.com

Du coup on perd juste un peu en fiabilité et en correction d'erreurs potentielle, j'imagine?
_________________

Ended up in a stranglehold on a PVC chair

Tramboi

On ne perd pas trop en fiabilité car on utilise toujours un 1 bit de contôle , afin de prévenir le joueur
que le jeu n'a pas réussie a se charger..

La duplication de K7 était assez fiable pour garantir une bonne fiabilité...

Avant de balancer la fabrication, la société de duplication envois une dizaines de K7 / CD / DVD pour
test.... ( Le BAT Bon a tirer )

Si les test sont concluant on lance la fabrication...

Parfois on trouve un bug, pendant cette phase de test ... on perd un master... mais au moins on n'a
eviter le pire...


Alain Fernandes
www.inthepockets.com

Merci Alain pour ton anecdote, je suis rentré dans l'industrie du dev de jeu beaucoup plus tard que toi (2000), donc le mastering numérique que j'ai connu n'a pas les mêmes blagues potentielles on va dire

_________________

Ended up in a stranglehold on a PVC chair