Demo : le monde des 64, 4 et 1 ko

Je ne peux m'empêcher de citer scene.org dans la rubrique "award" pour ceux qui voudrait faire tourner des superbes demo sur leur propre machine.

C'est vrai que c'est impressionnant ce qu'on peut faire dans 4ko d'exe.

Il faudrait plus de précisions sur les dll utilisées ou non, et leur taille. Et aussi la quantité de mémoire utilisée, qui frise peut-être plus avec les 100mo. En tout cas ça éveille toujours la curiosité ce genre de démo.

euh si la machine utilisé c'est un commodore ca va etre dur de taper dans les 1OOmégas de mémoire vive...

pyer4> Les démos 1/4/64Ko ne sont qu'un unique executable, pas de DLL. Mais effectivement, comme tout executable cela va utiliser quelques DLL du système d'exploitation voire de Direct3D/OpenGL (c'est peut-être à ça que tu faisais référence ?) pour ceux qui passe par Direct3D/OpenGL (ceux qui ont leur propre moteur 3D software rend le défi encore plus impressionnant).
D'autre part, toutes ces méthodes de "compression" ne font pas spécialement exploser la conso mémoire, c'est surtout le CPU qui va bosser bien plus (et les perfs qui vont avec), avec notamment des temps de chargement qui peuvent parfois durer plusieurs dizaines de secondes sur un PC récent.
C'est d'ailleurs pour ça que tout ça n'est que peu applicable dans les jeux vidéo où l'on privilégie les performances et le temps de développement que la place pris sur le HDD (petit pic à tous qui balance "ha ben regarde que que peux faire une démo de 64Ko, nos jeux d'aujourd'hui ne sont vraiment pas optimisés !").

Foudge> je pense qu'il y a pas mal de choses intéressantes et exactes dans ton post, mais je tiens tout de même à relativiser certains aspects de la réflexion. Etant développeur (pas dans le jeu vidéo), je peux confirmer que l'on privilégie certaines pistes concernant le délai de livraison, ainsi que certaines performances apparentes. Dans les faits c'est plus compliqué: comment s'octroyer du temps pour améliorer le moteur graphique/IA (par exemple) pour le rendre moins gourmand en ressources, tout en respectant les plannings déjà serrés?

Ces défis techniques n'ont majoritairement pour but que de démontrer que l'occupation disque n'est pas forcément la solution (c'est vrai), que de développer "proprement" est faisable (c'est vrai aussi), mais comme tu le dis aussi pas pour faire la leçon aux développement de jeux. Je serais moins tranché: il faut un équilibre entre un programme gourmand et qui marche, et un autre ultra optimisé d'un point de vue élégance du code... mais qui finit par ramer. Entre les deux il y a de quoi faire pour obtenir des moteurs de rendu graphique moins gourmands tout en restant aussi sympa, si ce n'est plus.

D'ailleurs, c'est aussi pour cela que nombre de développeurs consoles sont impressionnants, car ils doivent composer avec les limitations de la machine, gérer les spécificités hard et soft, et faire en sorte que ça marche "du premier coup" (quoique, avec les consoles connectées, on en arrive à des jeux consoles qui se voient patchés. Pas cool). Dans le monde PC, on peut avoir des exigences hard en collant un sticker "jeu pas fait pour les prolos, Crossfire mini avec Quad pro de rigueur".

urschuca : j'avais pas compris que c'était sur une telle machine
Foudge : c'est à ça que je pensais effectivement, j'ai du mal à croire que l'api graphique tienne dans si peu de place. Pour la mémoire je ne faisais qu'une supposition, principalement basée sur le fait que vu la faible puissance du cpu, ça devait probablement être du précalculé (gros temps de chargement donc), mais qu'il fallait bien stocker les résultats. Ca reste encore un mystère pour moi tout ça !

C'est donc pour çà que Duke Nukem Forever prend tant de temps :
ils essayent sûrement de faire tenir le jeu dans 512 octets,
moteur graphique compris...
Pfiouuu, çà en fait du nettoyage de code !