Bienvenue sur le forum de Grospixels : [ S'Enregistrer ] Déjà inscrit ? [ Connexion ] |
|||
|
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)