Forums de Grospixels
Bienvenue sur le forum de Grospixels : [ S'Enregistrer ]
Déjà inscrit ? [ Connexion ]
 
retour sur le site
rechercher

Poster un message
Autorisation :Tous les membres Enregistrés peuvent poster de nouveaux sujets et des réponses sur ce forum
Nom d'Utilisateur :
Mot de Passe :
J'ai perdu mon mot de passe!
Corps du Message :

HTML est: Activé
BBcode est: Activé
[img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img]
Options : Désactiver HTML sur ce Message
Désactiver BBcode sur ce Message
Désactiver Smilies sur ce Message
Montrer la signature (Ceci peut être modifié ou ajouté à votre profil)
 -   - 

Rappel des 10 derniers messages du topic (les plus récents en haut)
Tramboi
Pixel de bonne taille
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

Alain Fernandes
Pixel visible mais rikiki
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

Tramboi
Pixel de bonne taille
Du coup on perd juste un peu en fiabilité et en correction d'erreurs potentielle, j'imagine?

Alain Fernandes
Pixel visible mais rikiki
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

Tramboi
Pixel de bonne taille
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é?

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

Alain Fernandes
Pixel visible mais rikiki
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"...



mickmils
Gros pixel
La question la plus fondamentale est :

Ont ils racheté les droits de la Zoubida ?

Alain Fernandes
Pixel visible mais rikiki
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

Alain Fernandes
Pixel visible mais rikiki
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




Forum www.grospixels.com (© 2011-2019 Grospixels)